Retour d'expérience-

OrchestrationDu bootstrap des clusters au déploiement

des micro-services

Orchestration, Pourquoi ?

Orchestration, Pourquoi ?

Organisation agile

Engineering composée de Tribes

Changement de l'architecture historique monolithiquevers une architecture orientée micro-services

Autonomie des Squads dans leurs développements

Domaine de responsabilité

Faciliter les mises en production

Orchestration, Le besoin

Orchestration, Le besoin

Reprise de l'existant initié par nos développeurs

Déploiement des clusters via le script kube-up.sh

Déploiement sur 2 régions AWS

Trop peu de redondance

Pas de monitoring orienté système

Orchestration, Le besoin

Support de la Squad Infra

Apporter une vision complémentaire

Proposer une solution rapidement viable en production

Intégrer des fonctionnalités supplémentaires (monitoring, autoscaling)

Définir la stack technique

Ajouter de la redondance à l'existant

Industrialiser le déploiement et l'exploitation des clusters

Orchestration, La stack

Orchestration, La stack

Choix de l'outil de déploiment

Déjà utilisé auparavant : Ça marche

Bootstrap de clusters rapide aussi bien sur AWS que On-Premise

Installation de plusieurs masters possible + redondance ETCD

Communauté réactive

Quelques bugs facilement contournables

Utilise Ansible (SSH) et peut-être assez long en cas de latence importante

Switch sur Saltstack à terme

Orchestration, La stackLe réseau

Approche layer 3

Solution prometteuse et déjà utilisée auparavant

Pas de magie : règles iptables - facile à debug

CLI calicoctl intuitive et efficace

Utilisation sur AWS ET On-Premise

root@ip-10-212-3-250:/home/admin# calicoctl statuscalico-node container is running. Status: Up 13 daysRunning felix version 1.4.0rc2

IPv4 BGP statusIP: 10.212.3.250 AS Number: 64511 (inherited)+--------------+-------------------+-------+------------+-------------------------------------------+| Peer address | Peer type | State | Since | Info |+--------------+-------------------+-------+------------+-------------------------------------------+| 10.212.3.111 | node-to-node mesh | up | 2016-09-26 | Established || 10.212.3.112 | node-to-node mesh | start | 2016-09-26 | Active Socket: Host is unreachable || 10.212.3.113 | node-to-node mesh | up | 2016-09-26 | Established || 10.212.3.225 | node-to-node mesh | up | 2016-10-03 | Established || 10.212.3.226 | node-to-node mesh | up | 2016-10-03 | Established || 10.212.3.227 | node-to-node mesh | up | 2016-10-03 | Established || 10.212.3.84 | node-to-node mesh | up | 2016-10-06 | Established |+--------------+-------------------+-------+------------+-------------------------------------------+

Orchestration, La stack

Les intercos

Rappel

Kubernetes sur différentes régions AWS

Plusieurs datacenters "Dailymotion"

Besoin

Centraliser les logs des clusters à un endroit (Ici une région AWS)

Utiliser nos services internes depuis nos régions AWS (MasterSaltstack, Dépot de paquet, LDAP etc...)

Orchestration, La stack

Les intercos : Big Picture

OpenVPN

Orchestration, La stack

Les intercos : En détail

Un couple de Gate par datacenter DailymotionDeux couples de Gate par région AWSUtilisation de subnet privés prédéfinis

AWS Infra VPCAWS Squads VPC

Solution KISS qui fait le job

VPC Peering

Orchestration, La stack

Le monitoring

Utilisation du SaaS Datadog pour collecter toutes les métriques

système ET applicatives

Plugin AWS / Docker /Kubernetes

Intégration dans notreShinken

Rate limit de l'API Cloudwatch

Orchestration, La stack

Overview des clusters

Orchestration, Le déploiement desservices

Orchestration, Le déploiement des services

Le process

Push du code sur

Push de l'imagesur le Hub

Rollout du deployment

via shell script

Orchestration, Les PoC en cours

Orchestration, Work In Progress

Utilisation de calico On-Premise

Solution interne existante basée sur exabgp

Pas de BGP avec Calico

Chaque "Pod subnet" alloué par noeud est exporté via exabgp

Calico en charge de l'IPAM

DC3|k8s-01:~# calicoctl endpoint show --detailed+----------+-----------------+---------------------------------------+----------------------------------+-------------------+-------------------+--------------------+--------+| Hostname | Orchestrator ID | Workload ID | Endpoint ID | Addresses | MAC | Profiles +----------+-----------------+---------------------------------------+----------------------------------+-------------------+-------------------+--------------------+--------+| k8s-01 | k8s | default.consul-6cy8p | 4f0c0e3e3eb411e6abf8549f351ac600 | 10.172.0.198/32 | 1a:66:ad:ff:88:0d | calico-k8s-network | k8s-01 | k8s | default.consul-twh81 | ae58398a750a11e6abf8549f351ac600 | 10.172.24.49/32 | 86:1c:09:a3:ef:a1 | calico-k8s-network | k8s-01 | k8s | default.consul2-7xlse | adbd2300750a11e6abf8549f351ac600 | 10.172.24.45/32 | ca:9d:36:4d:69:0a | calico-k8s-network

Orchestration, Work In ProgressIntégration de Consul

Consul est déjà utilisé en production et dynamiquement intégré à notre

solution de load balancing

Pouvoir s'abstraire des services Kubernetes (mode headless) pour certains

use-cases

Test de différent bridge Kube / Consul pour pouvoir alimenter notre

système d'auto-discovery

Ajout des IPs de Services

Ajout des IPs des Pods

Intérêt : Pouvoir adresser les Pods directement depuis nos load balancers sansla notion de Service

Orchestration, La suite

Teaser : Orchestrer la plus grosse ferme de Dailymotion

Apache (pour servir les 3 milliards de vues parmois sur dailymotion.com)

Quel volume ?Plusieurs centaines de serveurs high-end

Quel type de service ?

ffmpeg (pour encoder les 300 000 heuresde vidéos par mois)

Orchestration, La suite

Teaser : Orchestrer la plus grosse ferme de Dailymotion

L'idée

Machines identiques qui servent les 2 servicesPriorité au service de dailymotion.com vs l'encoding

Le but

Orchestrer / autoscaler les deux services (En fonction deparamètres comme la charge des webs ou de l'encodage)

Setup On Premise et pourquoi pas un offload dans le cloud

Questions ?

@Donch_david.donchez@{gmail,dailymotion}.com