Retour d'expérience
-
Orchestration
Du 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 monolithique
vers 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 stack
Le 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 status
calico-node container is running. Status: Up 13 days
Running felix version 1.4.0rc2
IPv4 BGP status
IP: 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 (Master
Saltstack, 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 Dailymotion
Deux couples de Gate par région AWS
Utilisation 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 notre
Shinken
Rate limit de l'API Cloudwatch
Orchestration, La stack
Overview des clusters
Orchestration, Le déploiement des
services
Orchestration, Le déploiement des services
Le process
Push du code sur
Push de l'image
sur 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 |
+----------+-----------------+---------------------------------------+----------------------------------+-------------------+-------------------+------
| k8s-01 | k8s | default.consul-6cy8p | 4f0c0e3e3eb411e6abf8549f351ac600 | 10.172.0.198/32 | 1a:66:ad:ff:88:0d | calic
| k8s-01 | k8s | default.consul-twh81 | ae58398a750a11e6abf8549f351ac600 | 10.172.24.49/32 | 86:1c:09:a3:ef:a1 | calic
| k8s-01 | k8s | default.consul2-7xlse | adbd2300750a11e6abf8549f351ac600 | 10.172.24.45/32 | ca:9d:36:4d:69:0a | calic
Orchestration, Work In Progress
Inté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 sa
la notion de Service
Orchestration, La suite
Teaser : Orchestrer la plus grosse ferme de Dailymotion
Apache (pour servir les 3 milliards de vues par
mois sur dailymotion.com)
Quel volume ?
Plusieurs centaines de serveurs high-end
Quel type de service ?
ffmpeg (pour encoder les 300 000 heures
de vidéos par mois)
Orchestration, La suite
Teaser : Orchestrer la plus grosse ferme de Dailymotion
L'idée
Machines identiques qui servent les 2 services
Priorité au service de dailymotion.com vs l'encoding
Le but
Orchestrer / autoscaler les deux services (En fonction de
paramè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

Orchestration

  • 1.
    Retour d'expérience - Orchestration Du bootstrapdes clusters au déploiement des micro-services
  • 2.
  • 3.
    Orchestration, Pourquoi ? Organisationagile Engineering composée de Tribes Changement de l'architecture historique monolithique vers une architecture orientée micro-services Autonomie des Squads dans leurs développements Domaine de responsabilité Faciliter les mises en production
  • 4.
  • 5.
    Orchestration, Le besoin Reprisede 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
  • 6.
    Orchestration, Le besoin Supportde 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
  • 7.
  • 8.
    Orchestration, La stack Choixde 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
  • 9.
    Orchestration, La stack Leré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 status calico-node container is running. Status: Up 13 days Running felix version 1.4.0rc2 IPv4 BGP status IP: 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 | +--------------+-------------------+-------+------------+-------------------------------------------+
  • 10.
    Orchestration, La stack Lesintercos 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 (Master Saltstack, Dépot de paquet, LDAP etc...)
  • 11.
    Orchestration, La stack Lesintercos : Big Picture OpenVPN
  • 12.
    Orchestration, La stack Lesintercos : En détail Un couple de Gate par datacenter Dailymotion Deux couples de Gate par région AWS Utilisation de subnet privés prédéfinis AWS Infra VPCAWS Squads VPC Solution KISS qui fait le job VPC Peering
  • 13.
    Orchestration, La stack Lemonitoring Utilisation du SaaS Datadog pour collecter toutes les métriques système ET applicatives Plugin AWS / Docker / Kubernetes Intégration dans notre Shinken Rate limit de l'API Cloudwatch
  • 14.
  • 15.
  • 16.
    Orchestration, Le déploiementdes services Le process Push du code sur Push de l'image sur le Hub Rollout du deployment via shell script
  • 17.
  • 18.
    Orchestration, Work InProgress 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 | +----------+-----------------+---------------------------------------+----------------------------------+-------------------+-------------------+------ | k8s-01 | k8s | default.consul-6cy8p | 4f0c0e3e3eb411e6abf8549f351ac600 | 10.172.0.198/32 | 1a:66:ad:ff:88:0d | calic | k8s-01 | k8s | default.consul-twh81 | ae58398a750a11e6abf8549f351ac600 | 10.172.24.49/32 | 86:1c:09:a3:ef:a1 | calic | k8s-01 | k8s | default.consul2-7xlse | adbd2300750a11e6abf8549f351ac600 | 10.172.24.45/32 | ca:9d:36:4d:69:0a | calic
  • 19.
    Orchestration, Work InProgress Inté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 sa la notion de Service
  • 20.
    Orchestration, La suite Teaser: Orchestrer la plus grosse ferme de Dailymotion Apache (pour servir les 3 milliards de vues par mois sur dailymotion.com) Quel volume ? Plusieurs centaines de serveurs high-end Quel type de service ? ffmpeg (pour encoder les 300 000 heures de vidéos par mois)
  • 21.
    Orchestration, La suite Teaser: Orchestrer la plus grosse ferme de Dailymotion L'idée Machines identiques qui servent les 2 services Priorité au service de dailymotion.com vs l'encoding Le but Orchestrer / autoscaler les deux services (En fonction de paramètres comme la charge des webs ou de l'encodage) Setup On Premise et pourquoi pas un offload dans le cloud
  • 22.
  • 23.