Remarque perev. : Dailymotion est l'un des plus importants services d'hébergement vidéo au monde et, par conséquent, un utilisateur notable de Kubernetes. Dans cet article, l'architecte système David Donchez partage les résultats de la création d'une plate-forme de production pour l'entreprise basée sur K8, qui a commencé par une installation cloud dans GKE et s'est terminée comme une solution hybride, qui a permis d'obtenir un meilleur temps de réaction et d'économiser sur les coûts d'infrastructure.Lorsque nous avons décidé de reconstruire l'API
Dailymotion de base il y a trois ans, nous voulions développer un moyen plus efficace d'héberger des applications et de faciliter
les processus de développement et de production . Pour cela, nous avons décidé d'utiliser la 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 au niveau de la production dès que possible à l'aide de Google Cloud
Été 2016
Il y a trois ans, juste après le rachat de Dailymotion par
Vivendi , nos équipes d'ingénierie se sont concentrées sur un objectif global: créer un tout nouveau produit Dailymotion.
Sur la base de l'analyse des conteneurs, des solutions d'orchestration et de notre expérience passée, nous nous sommes assurés que Kubernetes est le bon choix. Certains développeurs avaient déjà une idée des concepts de base et savaient comment les utiliser, ce qui était 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 natives du cloud. Nous avons choisi de rester dans le cloud au début de notre voyage afin de construire sereinement la plateforme locale la plus fiable. Ils ont décidé de déployer leurs applications à l'aide de Google Kubernetes Engine, bien qu'ils savaient que tôt ou tard nous passerions à nos propres centres de données et appliquerions une stratégie hybride.
Pourquoi choisir GKE?
Nous avons fait ce choix principalement pour des raisons techniques. En outre, il était nécessaire de fournir rapidement une infrastructure qui réponde aux besoins de l’entreprise. Nous avions certaines exigences d'application, telles que la distribution géographique, l'évolutivité et la tolérance aux pannes.
Clusters GKE dans DailymotionDailymotion étant une plateforme vidéo disponible partout dans le monde, nous voulions vraiment améliorer la qualité de service en réduisant la
latence . Auparavant,
notre API 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 États-Unis.
Cette sensibilité aux retards signifiait que nous devions sérieusement travailler sur l'architecture réseau de la plateforme. Alors que la plupart des services cloud les ont obligés à créer leur propre réseau dans chaque région, puis à les connecter via un VPN ou un certain service géré, Google Cloud a permis de créer un réseau unifié 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 redirige les utilisateurs vers le cluster le plus proche). De toute évidence, en cas de panne, le trafic ira automatiquement vers une autre région sans aucune intervention humaine.
Surveillance de l'équilibrage de charge GoogleNotre plateforme utilise également activement des processeurs graphiques. Google Cloud rend extrêmement efficace leur utilisation directe dans les clusters Kubernetes.
A cette époque, l'équipe d'infrastructure se concentrait principalement sur l'ancienne pile déployée sur les serveurs physiques. C'est pourquoi l'utilisation d'un service managé (y compris les composants principaux de Kubernetes) a répondu à nos exigences et nous a permis de former des équipes à travailler avec des clusters locaux.
En conséquence, nous avons pu commencer à accepter le trafic de production sur l'infrastructure Google Cloud seulement 6 mois après le début des travaux.
Cependant, malgré un certain nombre d'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é utilisé, dans l'espoir de les implémenter sur site à l'avenir. En effet, l'introduction de clusters locaux a débuté fin 2016 et en parallèle une stratégie hybride a été initiée.
Lancement de la plateforme d'orchestration de conteneurs locaux Dailymotion
Automne 2016
Dans des conditions où toute la pile était prête pour la production et où le travail sur l'API s'est
poursuivi , 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 sûr, nous exploitons notre propre réseau de distribution de contenu depuis des années. Nous voulions profiter de cette circonstance et déployer des clusters Kubernetes dans les centres de données existants.
L'infrastructure Dailymotion a totalisé plus de 2,5 mille serveurs 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ître et travailleur, ainsi qu'un cluster etcd.
Partie réseau
Notre réseau est entièrement routable. Chaque serveur annonce son IP sur le réseau à l'aide d'Exabgp. Nous avons comparé plusieurs plug-ins de réseau et
Calico était le seul à satisfaire tous les besoins (en raison de l'approche utilisée au niveau L3). Il s'intègre parfaitement dans le modèle d'infrastructure réseau existant.
Étant donné que je voulais utiliser tous les éléments d'infrastructure disponibles, j'ai d'abord dû faire face à notre utilitaire de réseau local (utilisé sur tous les serveurs): utilisez-le pour annoncer les plages d'adresses IP sur un réseau avec des 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 l'équipement 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'atteindre n'importe quel pod à partir du réseau interne (et en particulier des équilibreurs de charge).
Comment nous gérons le trafic entrant
Pour rediriger les demandes 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 de Kubernetes.
Il y a trois ans, nginx-ingress-controller était le contrôleur le plus mature: Nginx est utilisé depuis longtemps et est 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é à l'extrémité du kube-apiserver du cluster correspondant. Exabgp a également été utilisé sur ces serveurs pour annoncer des adresses IP publiques ou privées. La topologie de notre 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 améliore l'efficacité.
Le mouvement du trafic d'Internet vers les podsMaintenant que vous avez compris notre plateforme hybride, vous pouvez vous plonger dans le processus de migration du trafic.
Migration du trafic de Google Cloud vers l'infrastructure Dailymotion
Automne 2018
Après presque deux ans de création, de test et de configuration, nous avons finalement obtenu une pile Kubernetes complète, prête à recevoir une partie du trafic.
La stratégie de routage actuelle est assez simple, mais répond tout à fait aux besoins. En plus de l'IP publique (dans Google Cloud et Dailymotion), AWS Route 53 est utilisé pour définir des politiques et rediriger les utilisateurs vers le cluster de notre choix.
Exemple de stratégie de routage utilisant Route 53Avec Google Cloud, c'est facile, car nous utilisons une seule adresse IP pour tous les clusters, et l'utilisateur est redirigé vers le cluster GKE le plus proche. La technologie est différente pour nos clusters car leurs adresses IP sont différentes.
Lors de la migration, nous avons cherché à rediriger les demandes régionales vers les clusters respectifs et évalué les avantages de cette approche.
Étant donné que nos clusters GKE sont configurés pour évoluer automatiquement à l'aide de mesures personnalisées, ils augmentent / diminuent la puissance 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 bilans de santé sont effectués par la Route 53).
...
À l'avenir, nous voulons automatiser entièrement les politiques de routage pour obtenir une stratégie hybride autonome qui améliore constamment l'accessibilité des utilisateurs. Quant aux avantages: le coût du cloud a été considérablement réduit et a même réussi à réduire le temps de réponse de l'API. Nous faisons confiance à la plate-forme cloud résultante et sommes prêts à y rediriger plus de trafic si nécessaire.
PS du traducteur
Vous pourriez également être intéressé par une autre publication récente de Dailymotion sur Kubernetes. Il est dédié au déploiement d'applications Helm sur de nombreux clusters Kubernetes et a
été publié il y a environ un mois.
Lisez aussi dans notre blog: