Note de traduction.: Dailymotion — l'un des plus grands services d'hébergement de vidéos au monde, et donc un utilisateur notable de Kubernetes. Dans cet article, l’architecte système David Donchez partage les résultats de la création de la plateforme de production de l'entreprise basée sur K8s, qui a commencé par une installation cloud dans GKE et s'est terminée par une solution hybride, permettant d'obtenir un meilleur temps de réponse et de réduire les coûts d'infrastructure.
En prenant la décision de restructurer l'API principale il y a trois ans, nous voulions développer une méthode plus efficace pour héberger des applications et faciliter . Pour ce faire, nous avons décidé d'utiliser une plateforme d'orchestration de conteneurs et avons naturellement choisi Kubernetes.
Pourquoi créer sa propre plateforme basée sur Kubernetes ?
API de production en un temps record avec Google Cloud
Été 2016
Il y a trois ans, juste après l'achat de Dailymotion par la société , nos équipes d'ingénieurs se sont concentrées sur un objectif global : créer un tout nouveau produit Dailymotion.
À l'issue de l'analyse des conteneurs, des solutions d'orchestration et de notre expérience passée, nous avons conclu que Kubernetes était le bon choix. Une partie des développeurs avait déjà une compréhension des concepts de base et savait comment l'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 cloud natives. Nous avons préféré rester dans le cloud au début de notre parcours pour construire tranquillement une plateforme locale aussi fiable que possible. Nous avons décidé de déployer nos applications à l'aide de Google Kubernetes Engine, bien que nous sachions qu'à un moment donné, nous passerions à nos propres data centers et appliquerions une stratégie hybride.
Pourquoi avons-nous 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 de l'entreprise. Nous avions certaines exigences concernant le déploiement des applications, telles que la répartition géographique, l'évolutivité et la tolérance aux pannes.
Clusters GKE chez Dailymotion
Étant donné que Dailymotion est une plateforme vidéo accessible dans le monde entier, nous voulions vraiment améliorer la qualité du service en réduisant le temps d'attente (latence). Auparavant, était uniquement accessible à Paris, ce qui n'était pas optimal. Nous souhaitions pouvoir déployer des applications non seulement en Europe, mais également en Asie et aux États-Unis.
Cette sensibilité aux latences signifiait qu'il fallait sérieusement retravailler l'architecture réseau de la plateforme. Alors que la plupart des services cloud nécessitaient de créer leur propre réseau dans chaque région et de les relier ensuite via VPN ou un service géré, Google Cloud permettait de créer un réseau unique entièrement routable, couvrant toutes les régions de Google. C'est un grand avantage en termes d'exploitation et d'efficacité du système.
De plus, les services réseau et les équilibreurs de charge de Google Cloud fonctionnent très bien. Ils permettent simplement d'utiliser des adresses IP publiques arbitraires de chaque région, et le protocole BGP magnifique s'occupe du reste (c'est-à-dire qu'il redirige les utilisateurs vers le cluster le plus proche). Il est évident qu'en cas de défaillance, le trafic sera automatiquement redirigé vers une autre région sans intervention humaine.
Suivi de l'équilibrage de charge dans Google
Notre plateforme utilise également activement des processeurs graphiques. Google Cloud permet de les utiliser très efficacement directement dans les clusters Kubernetes.
À l'époque, l'équipe d'infrastructure se concentrait principalement sur l'ancienne pile déployée sur des serveurs physiques. C'est pourquoi l'utilisation d'un service géré (y compris les composants maîtres de Kubernetes) correspondait à nos exigences et nous a permis de former les équipes à travailler avec des clusters locaux.
En conséquence, nous avons pu commencer à accepter le trafic de production sur l'infrastructure de Google Cloud seulement six mois après le début des travaux.
Cependant, malgré un certain nombre d'avantages, travailler avec un fournisseur cloud engendre des coûts qui peuvent augmenter en fonction de la charge. C'est pourquoi nous avons soigneusement analysé chaque service géré utilisé, en prévoyant de les mettre en œuvre à l'avenir en mode on-premises. En réalité, le déploiement de clusters locaux a débuté fin 2016, et une stratégie hybride a également été lancée à cette époque.
Lancement de la plateforme d'orchestration de conteneurs locale de Dailymotion
Automne 2016
Dans un contexte où l'ensemble de la pile était prêt pour la production, et que le travail sur l'API , il était temps de se concentrer sur les clusters régionaux.
À l'époque, les utilisateurs regardaient plus de 3 milliards de vidéos par mois. Bien sûr, notre propre réseau de diffusion de contenu était déjà en activité depuis plusieurs années. Nous voulions tirer parti de cette situation et déployer des clusters Kubernetes dans nos centres de données existants.
L'infrastructure de Dailymotion comptait plus de 2 500 serveurs répartis sur six centres de données. Tous étaient configurés à l'aide de Saltstack. Nous avons commencé à préparer toutes les recettes nécessaires pour créer les nœuds master et worker, ainsi que le cluster etcd.
La partie réseau
Notre réseau est entièrement routable. Chaque serveur annonce son IP dans le réseau via Exabgp. Nous avons comparé plusieurs plugins réseau, et le seul qui a satisfait à tous nos besoins (en raison de l'approche utilisée au niveau L3) était . Il s'est parfaitement intégré dans le modèle réseau existant de l'infrastructure.
Comme nous souhaitions utiliser tous les éléments de l'infrastructure, il fallait d'abord comprendre notre utilitaire réseau maison (utilisé sur tous les serveurs) : l'utiliser pour annoncer les plages d'adresses IP dans le réseau avec les nœuds Kubernetes. Nous avons permis à Calico d'attribuer des adresses IP aux pods, mais nous ne l'avons pas utilisé jusqu'à présent pour les sessions BGP sur l'équipement réseau. En fait, la 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 (en particulier depuis les équilibreurs de charge).
Comment nous gérons le trafic ingress
Pour rediriger les requêtes entrantes vers le service approprié, nous avons décidé d'utiliser Ingress Controller en raison de son intégration avec les ressources ingress de Kubernetes.
Il y a trois ans, nginx-ingress-controller était le contrôleur le plus mature : Nginx était utilisé depuis longtemps et était connu pour sa stabilité et sa performance.
Dans notre système, nous avons décidé de déployer des contrôleurs sur des serveurs blade dédiés de 10 gigabits. Chaque contrôleur était connecté à l'endpoint kube-apiserver du cluster correspondant. Sur ces serveurs, nous avons également utilisé Exabgp pour annoncer des adresses IP publiques ou privées. La topologie de notre réseau permet d'utiliser BGP depuis ces contrôleurs pour router tout le trafic directement vers les pods sans utiliser de service de type NodePort. Cette approche aide à éviter le trafic horizontal entre les nœuds et améliore l'efficacité.
Flux de trafic de l'internet vers les pods
Maintenant que nous avons clarifié notre plateforme hybride, nous pouvons approfondir le processus de migration du trafic.
Migration du trafic de Google Cloud vers l'infrastructure Dailymotion
Automne 2018
Après près de deux ans de création, de test et de configuration, nous avons enfin un stack Kubernetes complet prêt à accueillir une partie du trafic.
La stratégie actuelle de routage est assez simple, mais satisfait pleinement nos besoins. En plus des IP publiques (dans Google Cloud et Dailymotion), nous utilisons AWS Route 53 pour définir des politiques et rediriger les utilisateurs vers le cluster de notre choix.
Exemple de politique de routage utilisant Route 53
Avec Google Cloud, c'est simple, car nous utilisons une IP unique pour tous les clusters, et l'utilisateur est redirigé vers le cluster GKE le plus proche. Pour nos clusters, la technologie est différente, car leurs IP varient.
Lors de la migration, nous visions à rediriger les requêtes régionales vers les clusters appropriés et avons évalué les avantages de cette approche.
Étant donné que nos clusters GKE sont configurés pour le redimensionnement automatique via des métriques personnalisées, ils augmentent/diminuent leurs capacités en fonction du trafic entrant.
En mode normal, tout le trafic régional est dirigé vers le cluster local, et GKE sert de secours en cas de problèmes (des contrôles de santé sont effectués par Route 53).
…
À l'avenir, nous souhaitons entièrement automatiser les politiques de routage afin d'obtenir une stratégie hybride autonome qui améliore constamment la disponibilité pour les utilisateurs. En ce qui concerne les avantages : les coûts liés au cloud ont considérablement diminué et le temps de réponse de l'API a même été réduit. Nous avons confiance dans la plateforme cloud qui en résulte et sommes prêts à rediriger davantage de trafic vers elle si nécessaire.
P.S. de l'auteur
Vous pourriez également être intéressé par une autre publication récente de Dailymotion sur Kubernetes. Elle concerne le déploiement d'applications avec Helm sur plusieurs clusters Kubernetes et il y a environ un mois.
Lisez aussi dans notre blog :
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Source : habr.com
