Noter. trad.: Dailymotion est l'un des plus grands services d'hébergement vidéo au monde et donc un utilisateur notable de Kubernetes. Dans ce document, l'architecte système David Donchez partage les résultats de la création de la plate-forme de production de l'entreprise basée sur K8, qui a commencé par une installation cloud dans GKE et s'est terminée par une solution hybride, qui a permis de meilleurs temps de réponse et des économies sur les coûts d'infrastructure.
Décider de reconstruire l'API principale il y a trois ans, nous souhaitions développer un moyen plus efficace d'héberger des applications et le rendre plus simple . Pour cela, nous avons décidé d’utiliser une plateforme d’orchestration de conteneurs et avons naturellement choisi Kubernetes.
Pourquoi vaut-il la peine de créer votre propre plateforme basée sur Kubernetes ?
API de niveau production en un rien de temps grâce à Google Cloud
Été 2016
Il y a trois ans, immédiatement après le rachat de Dailymotion par , nos équipes d'ingénierie se concentrent sur un objectif global : créer un tout nouveau produit Dailymotion.
Sur la base de notre analyse des conteneurs, des solutions d'orchestration et de notre expérience passée, nous sommes convaincus que Kubernetes est le bon choix. Certains développeurs maîtrisaient déjà les concepts de base et savaient comment les utiliser, ce qui constituait un énorme avantage pour la transformation de l'infrastructure.
Du point de vue de l'infrastructure, un système puissant et flexible était nécessaire pour héberger de nouveaux types d'applications cloud natives. Nous avons choisi de rester dans le cloud au début de notre parcours afin de pouvoir construire en toute sérénité la plateforme sur site la plus robuste possible. Nous avons décidé de déployer nos applications à l'aide de Google Kubernetes Engine, même si nous savions que tôt ou tard, nous passerions à nos propres centres de données et appliquerions une stratégie hybride.
Pourquoi avez-vous choisi GKE ?
Nous avons fait ce choix principalement pour des raisons techniques. De plus, il était nécessaire de fournir rapidement une infrastructure répondant aux besoins métiers de l’entreprise. Nous avions certaines exigences pour l'hébergement d'applications, telles que la répartition géographique, l'évolutivité et la tolérance aux pannes.
Clusters GKE dans Dailymotion
Dailymotion étant une plateforme vidéo disponible dans le monde entier, nous souhaitions vraiment améliorer la qualité du service en réduisant le temps d'attente. (latence). plus tôt n'était disponible qu'à Paris, ce qui n'était pas optimal. Je voulais pouvoir héberger des applications non seulement en Europe, mais aussi en Asie et aux USA.
Cette sensibilité à la latence impliquait un travail sérieux sur l'architecture réseau de la plateforme. Alors que la plupart des services cloud vous obligeaient à créer votre propre réseau dans chaque région, puis à les connecter via un VPN ou une sorte de service géré, Google Cloud vous permettait de créer un réseau unique entièrement routable couvrant toutes les régions de Google. C’est un gros plus en termes de fonctionnement et d’efficacité du système.
De plus, les services réseau et les équilibreurs de charge de Google Cloud font un excellent travail. Ils vous permettent simplement d'utiliser des adresses IP publiques arbitraires de chaque région, et le merveilleux protocole BGP s'occupe du reste (c'est-à-dire redirigeant les utilisateurs vers le cluster le plus proche). Bien évidemment, en cas de panne, le trafic se dirigera automatiquement vers une autre région sans aucune intervention humaine.
Surveillance de l'équilibrage de charge Google
Notre plateforme utilise également beaucoup de GPU. Google Cloud permet de les utiliser très efficacement directement dans les clusters Kubernetes.
À l’époque, l’équipe infrastructure se concentrait principalement sur la pile existante déployée sur les serveurs physiques. C'est pourquoi le recours à un service managé (incluant des masters Kubernetes) répondait à nos exigences et nous permettait de former des équipes à travailler avec des clusters locaux.
En conséquence, nous avons pu commencer à recevoir du trafic de production sur l'infrastructure Google Cloud seulement 6 mois après le début des travaux.
Cependant, malgré de nombreux avantages, travailler avec un fournisseur de cloud est associé à certains coûts, qui peuvent augmenter en fonction de la charge. C'est pourquoi nous avons soigneusement analysé chaque service géré que nous avons utilisé, dans l'espoir de les mettre en œuvre sur site à l'avenir. En effet, la mise en place de clusters locaux a débuté fin 2016 et la stratégie hybride a été initiée au même moment.
Lancement de la plateforme locale d'orchestration de conteneurs Dailymotion
Automne 2016
Dans des conditions où l'ensemble de la pile était prêt pour la production et travaillait sur l'API , il était temps de se concentrer sur les clusters régionaux.
À cette époque, les utilisateurs regardaient plus de 3 milliards de vidéos chaque mois. Bien entendu, nous disposons de notre propre réseau de diffusion de contenu étendu depuis de nombreuses années. Nous voulions profiter de cette circonstance et déployer des clusters Kubernetes dans les centres de données existants.
L'infrastructure de Dailymotion comprenait plus de 2,5 XNUMX serveurs répartis dans six centres de données. Tous sont configurés à l’aide de Saltstack. Nous avons commencé à préparer toutes les recettes nécessaires pour créer des nœuds maîtres et ouvriers, ainsi qu'un cluster etcd.
Partie réseau
Notre réseau est complètement acheminé. Chaque serveur annonce son IP sur le réseau à l'aide d'Exabgp. Nous avons comparé plusieurs plugins réseau et le seul qui satisfaisait tous les besoins (en raison de l'approche L3 utilisée) était . Il s’intègre parfaitement dans le modèle d’infrastructure réseau existant.
Puisque nous voulions utiliser tous les éléments d'infrastructure disponibles, la première chose que nous devions faire était de trouver notre utilitaire réseau maison (utilisé sur tous les serveurs) : utilisez-le pour annoncer les plages d'adresses IP sur le réseau avec les nœuds Kubernetes. Nous avons autorisé Calico à attribuer des adresses IP aux pods, mais nous ne l'avons pas utilisé et ne l'utilisons toujours pas pour les sessions BGP sur les équipements réseau. En fait, le routage est géré par Exabgp, qui annonce les sous-réseaux utilisés par Calico. Cela nous permet d'accéder à n'importe quel pod depuis le réseau interne (et notamment depuis les répartiteurs de charge).
Comment nous gérons le trafic entrant
Pour rediriger les requêtes entrantes vers le service souhaité, il a été décidé d'utiliser Ingress Controller en raison de son intégration avec les ressources d'entrée Kubernetes.
Il y a trois ans, nginx-ingress-controller était le contrôleur le plus mature : Nginx existait depuis longtemps et était connu pour sa stabilité et ses performances.
Dans notre système, nous avons décidé de placer les contrôleurs sur des serveurs lames dédiés de 10 Gigabits. Chaque contrôleur était connecté au point de terminaison kube-apiserver du cluster correspondant. Ces serveurs utilisaient également Exabgp pour annoncer des adresses IP publiques ou privées. Notre topologie réseau nous permet d'utiliser BGP à partir de ces contrôleurs pour acheminer tout le trafic directement vers les pods sans utiliser un service comme NodePort. Cette approche permet d'éviter le trafic horizontal entre les nœuds et d'améliorer l'efficacité.
Mouvement du trafic depuis Internet vers les pods
Maintenant que nous comprenons notre plate-forme hybride, nous pouvons approfondir le processus de migration du trafic lui-même.
Migration du trafic de Google Cloud vers l'infrastructure Dailymotion
Automne 2018
Après près de deux ans de construction, de tests et de réglage, nous disposons enfin d'une pile Kubernetes complète, prête à accepter une partie du trafic.
La stratégie de routage actuelle est assez simple, mais suffisante pour répondre aux besoins. En plus des IP publiques (sur Google Cloud et Dailymotion), AWS Route 53 permet de définir des politiques et de rediriger les utilisateurs vers le cluster de notre choix.
Exemple de stratégie de routage utilisant Route 53
Avec Google Cloud, c'est simple car nous partageons une seule adresse IP sur tous les clusters et l'utilisateur est redirigé vers le cluster GKE le plus proche. Pour nos clusters la technologie est différente, puisque leurs IP sont différentes.
Lors de la migration, nous avons cherché à rediriger les demandes régionales vers les clusters appropriés et évalué les bénéfices de cette approche.
Étant donné que nos clusters GKE sont configurés pour effectuer une mise à l'échelle automatique à l'aide de métriques personnalisées, ils évoluent vers le haut ou vers le bas en fonction du trafic entrant.
En mode normal, tout le trafic régional est dirigé vers le cluster local, et GKE sert de réserve en cas de problème (des contrôles de santé sont effectués par Route 53).
...
À l’avenir, nous souhaitons automatiser entièrement les politiques de routage pour parvenir à une stratégie hybride autonome qui améliore continuellement l’accessibilité pour les utilisateurs. Du côté positif, les coûts du cloud ont été considérablement réduits et les temps de réponse des API ont même été réduits. Nous faisons confiance à la plate-forme cloud qui en résulte et sommes prêts à y rediriger davantage de trafic si nécessaire.
PS du traducteur
Vous pourriez également être intéressé par un autre article récent de Dailymotion sur Kubernetes. Il est dédié au déploiement d'applications avec Helm sur de nombreux clusters Kubernetes et il y a environ un mois.
A lire aussi sur notre blog :
- «».
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «».
Source: habr.com