Retour d'expérience : du bootstrap des clusters au déploiement des micro-services

1. Retour d'expérience
-
Orchestration
Du bootstrap des clusters au déploiement
des micro-services

2. Orchestration, Pourquoi ?

3. 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

4. Orchestration, Le besoin

5. 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

6. 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

7. Orchestration, La stack

8. 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

9. 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 |
+--------------+-------------------+-------+------------+-------------------------------------------+

10. 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...)

11. Orchestration, La stack
Les intercos : Big Picture
OpenVPN

12. 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

13. 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

14. Orchestration, La stack
Overview des clusters

15. Orchestration, Le déploiement des
services

16. 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

17. Orchestration, Les PoC en cours

18. 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

19. 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

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. Questions ?

23. @Donch_
david.donchez@{gmail,dailymotion}.com