{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Aventure Kubernetes de Dailymotion : cr\u00e9ation d'infrastructure dans le cloud + sur site","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Aventure
\n
\nNote de traduction.<\/b>: Dailymotion \u2014 l'un des plus grands services d'h\u00e9bergement de vid\u00e9os au monde, et donc un utilisateur notable de Kubernetes. Dans cet article, l\u2019architecte syst\u00e8me David Donchez partage les r\u00e9sultats de la cr\u00e9ation de la plateforme de production de l'entreprise bas\u00e9e sur K8s, qui a commenc\u00e9 par une installation cloud dans GKE et s'est termin\u00e9e par une solution hybride, permettant d'obtenir un meilleur temps de r\u00e9ponse et de r\u00e9duire les co\u00fbts d'infrastructure.<\/i><\/p>\n

En prenant la d\u00e9cision de restructurer l'API principale Dailymotion<\/a><\/noindex> il y a trois ans, nous voulions d\u00e9velopper une m\u00e9thode plus efficace pour h\u00e9berger des applications et faciliter les processus de d\u00e9veloppement et de production<\/a><\/noindex>. Pour ce faire, nous avons d\u00e9cid\u00e9 d'utiliser une plateforme d'orchestration de conteneurs et avons naturellement choisi Kubernetes.<\/p>\n

Pourquoi cr\u00e9er sa propre plateforme bas\u00e9e sur Kubernetes ?<\/a><\/noindex><\/p>\n

API de production en un temps record avec Google Cloud<\/h2>\n

<\/p>\n

\u00c9t\u00e9 2016<\/p><\/blockquote>\n

\nIl y a trois ans, juste apr\u00e8s l'achat de Dailymotion par la soci\u00e9t\u00e9 Vivendi<\/a><\/noindex>, nos \u00e9quipes d'ing\u00e9nieurs se sont concentr\u00e9es sur un objectif global : cr\u00e9er un tout nouveau produit Dailymotion.<\/p>\n

\u00c0 l'issue de l'analyse des conteneurs, des solutions d'orchestration et de notre exp\u00e9rience pass\u00e9e, nous avons conclu que Kubernetes \u00e9tait le bon choix. Une partie des d\u00e9veloppeurs avait d\u00e9j\u00e0 une compr\u00e9hension des concepts de base et savait comment l'utiliser, ce qui \u00e9tait un \u00e9norme avantage pour la transformation de l'infrastructure.<\/p>\n

Du point de vue de l'infrastructure, un syst\u00e8me puissant et flexible \u00e9tait n\u00e9cessaire pour h\u00e9berger de nouveaux types d'applications cloud natives. Nous avons pr\u00e9f\u00e9r\u00e9 rester dans le cloud au d\u00e9but de notre parcours pour construire tranquillement une plateforme locale aussi fiable que possible. Nous avons d\u00e9cid\u00e9 de d\u00e9ployer nos applications \u00e0 l'aide de Google Kubernetes Engine, bien que nous sachions qu'\u00e0 un moment donn\u00e9, nous passerions \u00e0 nos propres data centers et appliquerions une strat\u00e9gie hybride.<\/p>\n

Pourquoi avons-nous choisi GKE ?<\/h3>\n

\nNous avons fait ce choix principalement pour des raisons techniques. De plus, il \u00e9tait n\u00e9cessaire de fournir rapidement une infrastructure r\u00e9pondant aux besoins de l'entreprise. Nous avions certaines exigences concernant le d\u00e9ploiement des applications, telles que la r\u00e9partition g\u00e9ographique, l'\u00e9volutivit\u00e9 et la tol\u00e9rance aux pannes.<\/p>\n

\"Aventure
\nClusters GKE chez Dailymotion<\/i><\/p>\n

\u00c9tant donn\u00e9 que Dailymotion est une plateforme vid\u00e9o accessible dans le monde entier, nous voulions vraiment am\u00e9liorer la qualit\u00e9 du service en r\u00e9duisant le temps d'attente (latence)<\/i>. Auparavant, notre API<\/a><\/noindex> \u00e9tait uniquement accessible \u00e0 Paris, ce qui n'\u00e9tait pas optimal. Nous souhaitions pouvoir d\u00e9ployer des applications non seulement en Europe, mais \u00e9galement en Asie et aux \u00c9tats-Unis.<\/p>\n

Cette sensibilit\u00e9 aux latences signifiait qu'il fallait s\u00e9rieusement retravailler l'architecture r\u00e9seau de la plateforme. Alors que la plupart des services cloud n\u00e9cessitaient de cr\u00e9er leur propre r\u00e9seau dans chaque r\u00e9gion et de les relier ensuite via VPN ou un service g\u00e9r\u00e9, Google Cloud permettait de cr\u00e9er un r\u00e9seau unique enti\u00e8rement routable, couvrant toutes les r\u00e9gions de Google. C'est un grand avantage en termes d'exploitation et d'efficacit\u00e9 du syst\u00e8me.<\/p>\n

De plus, les services r\u00e9seau et les \u00e9quilibreurs de charge de Google Cloud fonctionnent tr\u00e8s bien. Ils permettent simplement d'utiliser des adresses IP publiques arbitraires de chaque r\u00e9gion, et le protocole BGP magnifique s'occupe du reste (c'est-\u00e0-dire qu'il redirige les utilisateurs vers le cluster le plus proche). Il est \u00e9vident qu'en cas de d\u00e9faillance, le trafic sera automatiquement redirig\u00e9 vers une autre r\u00e9gion sans intervention humaine.<\/p>\n

\"Aventure
\nSuivi de l'\u00e9quilibrage de charge dans Google<\/i><\/p>\n

Notre plateforme utilise \u00e9galement activement des processeurs graphiques. Google Cloud permet de les utiliser tr\u00e8s efficacement directement dans les clusters Kubernetes.<\/p>\n

\u00c0 l'\u00e9poque, l'\u00e9quipe d'infrastructure se concentrait principalement sur l'ancienne pile d\u00e9ploy\u00e9e sur des serveurs physiques. C'est pourquoi l'utilisation d'un service g\u00e9r\u00e9 (y compris les composants ma\u00eetres de Kubernetes) correspondait \u00e0 nos exigences et nous a permis de former les \u00e9quipes \u00e0 travailler avec des clusters locaux.<\/p>\n

En cons\u00e9quence, nous avons pu commencer \u00e0 accepter le trafic de production sur l'infrastructure de Google Cloud seulement six mois apr\u00e8s le d\u00e9but des travaux.<\/p>\n

Cependant, malgr\u00e9 un certain nombre d'avantages, travailler avec un fournisseur cloud engendre des co\u00fbts qui peuvent augmenter en fonction de la charge. C'est pourquoi nous avons soigneusement analys\u00e9 chaque service g\u00e9r\u00e9 utilis\u00e9, en pr\u00e9voyant de les mettre en \u0153uvre \u00e0 l'avenir en mode on-premises. En r\u00e9alit\u00e9, le d\u00e9ploiement de clusters locaux a d\u00e9but\u00e9 fin 2016, et une strat\u00e9gie hybride a \u00e9galement \u00e9t\u00e9 lanc\u00e9e \u00e0 cette \u00e9poque.<\/p>\n

Lancement de la plateforme d'orchestration de conteneurs locale de Dailymotion<\/h2>\n

<\/p>\n

Automne 2016<\/p><\/blockquote>\n

\nDans un contexte o\u00f9 l'ensemble de la pile \u00e9tait pr\u00eat pour la production, et que le travail sur l'API a dur\u00e9<\/a><\/noindex>, il \u00e9tait temps de se concentrer sur les clusters r\u00e9gionaux.<\/p>\n

\u00c0 l'\u00e9poque, les utilisateurs regardaient plus de 3 milliards de vid\u00e9os par mois. Bien s\u00fbr, notre propre r\u00e9seau de diffusion de contenu \u00e9tait d\u00e9j\u00e0 en activit\u00e9 depuis plusieurs ann\u00e9es. Nous voulions tirer parti de cette situation et d\u00e9ployer des clusters Kubernetes dans nos centres de donn\u00e9es existants.<\/p>\n

L'infrastructure de Dailymotion comptait plus de 2 500 serveurs r\u00e9partis sur six centres de donn\u00e9es. Tous \u00e9taient configur\u00e9s \u00e0 l'aide de Saltstack. Nous avons commenc\u00e9 \u00e0 pr\u00e9parer toutes les recettes n\u00e9cessaires pour cr\u00e9er les n\u0153uds master et worker, ainsi que le cluster etcd.<\/p>\n

\"Aventure
\n<\/p>\n

La partie r\u00e9seau<\/h3>\n

\nNotre r\u00e9seau est enti\u00e8rement routable. Chaque serveur annonce son IP dans le r\u00e9seau via Exabgp. Nous avons compar\u00e9 plusieurs plugins r\u00e9seau, et le seul qui a satisfait \u00e0 tous nos besoins (en raison de l'approche utilis\u00e9e au niveau L3) \u00e9tait Calico<\/a><\/noindex>. Il s'est parfaitement int\u00e9gr\u00e9 dans le mod\u00e8le r\u00e9seau existant de l'infrastructure.<\/p>\n

Comme nous souhaitions utiliser tous les \u00e9l\u00e9ments d'infrastructure disponibles, il \u00e9tait essentiel de comprendre notre propre utilitaire r\u00e9seau (utilis\u00e9 sur tous les serveurs) : l'utiliser pour annoncer les plages d'adresses IP dans le r\u00e9seau avec des n\u0153uds Kubernetes. Nous avons permis \u00e0 Calico d'attribuer des adresses IP aux pods, mais nous ne l'avons pas utilis\u00e9 et ne l'utilisons toujours pas pour les sessions BGP sur le mat\u00e9riel r\u00e9seau. En r\u00e9alit\u00e9, la gestion du routage est effectu\u00e9e par Exabgp, qui annonce les sous-r\u00e9seaux utilis\u00e9s par Calico. Cela nous permet d'acc\u00e9der \u00e0 n'importe quel pod depuis le r\u00e9seau interne (et en particulier depuis les \u00e9quilibreurs de charge).<\/p>\n

Comment nous g\u00e9rons le trafic ingress<\/h3>\n

\nPour rediriger les requ\u00eates entrantes vers le service appropri\u00e9, nous avons d\u00e9cid\u00e9 d'utiliser Ingress Controller en raison de son int\u00e9gration avec les ressources ingress de Kubernetes.<\/p>\n

Il y a trois ans, nginx-ingress-controller \u00e9tait le contr\u00f4leur le plus mature : Nginx \u00e9tait utilis\u00e9 depuis longtemps et \u00e9tait connu pour sa stabilit\u00e9 et sa performance.<\/p>\n

Dans notre syst\u00e8me, nous avons d\u00e9cid\u00e9 de placer les contr\u00f4leurs sur des serveurs blade d\u00e9di\u00e9s de 10 gigabits. Chaque contr\u00f4leur se connectait au point de terminaison kube-apiserver de son cluster respectif. Sur ces serveurs, Exabgp \u00e9tait \u00e9galement utilis\u00e9 pour annoncer des adresses IP publiques ou priv\u00e9es. La topologie de notre r\u00e9seau permet d'utiliser BGP depuis ces contr\u00f4leurs pour acheminer tout le trafic directement vers les pods sans recourir \u00e0 un service de type NodePort. Cette approche permet d'\u00e9viter le trafic horizontal entre les n\u0153uds et am\u00e9liore l'efficacit\u00e9.<\/p>\n

\"Aventure
\nLe trafic Internet vers les pods<\/i><\/p>\n

Maintenant que nous avons clarifi\u00e9 notre plateforme hybride, nous pouvons approfondir le processus de migration du trafic.<\/p>\n

Migration du trafic de Google Cloud vers l'infrastructure Dailymotion<\/h2>\n

<\/p>\n

Automne 2018<\/p><\/blockquote>\n

\nApr\u00e8s pr\u00e8s de deux ans de cr\u00e9ation, de test et de configuration, nous avons enfin un stack Kubernetes complet pr\u00eat \u00e0 accueillir une partie du trafic.<\/p>\n

\"Aventure
\n
\nLa strat\u00e9gie 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\u00e9finir des politiques et rediriger les utilisateurs vers le cluster de notre choix.<\/p>\n

\"Aventure
\nExemple de politique de routage utilisant Route 53<\/i><\/p>\n

Avec Google Cloud, c'est simple, car nous utilisons une IP unique pour tous les clusters, et l'utilisateur est redirig\u00e9 vers le cluster GKE le plus proche. Pour nos clusters, la technologie est diff\u00e9rente, car leurs IP varient.<\/p>\n

Lors de la migration, nous visions \u00e0 rediriger les requ\u00eates r\u00e9gionales vers les clusters appropri\u00e9s et avons \u00e9valu\u00e9 les avantages de cette approche.<\/p>\n

\u00c9tant donn\u00e9 que nos clusters GKE sont configur\u00e9s pour le redimensionnement automatique via des m\u00e9triques personnalis\u00e9es, ils augmentent\/diminuent leurs capacit\u00e9s en fonction du trafic entrant.<\/p>\n

En temps normal, tout le trafic r\u00e9gional est dirig\u00e9 vers le cluster local, tandis que GKE sert de secours en cas de probl\u00e8me (des v\u00e9rifications de sant\u00e9 sont effectu\u00e9es par Route 53).<\/p>\n

\u2026<\/h2>\n

\n\u00c0 l'avenir, nous souhaitons enti\u00e8rement automatiser les politiques de routage afin d'obtenir une strat\u00e9gie hybride autonome qui am\u00e9liore constamment la disponibilit\u00e9 pour les utilisateurs. En ce qui concerne les avantages : les co\u00fbts li\u00e9s au cloud ont consid\u00e9rablement diminu\u00e9 et le temps de r\u00e9ponse de l'API a m\u00eame \u00e9t\u00e9 r\u00e9duit. Nous avons confiance dans la plateforme cloud qui en r\u00e9sulte et sommes pr\u00eats \u00e0 rediriger davantage de trafic vers elle si n\u00e9cessaire.<\/p>\n

P.S. de l'auteur<\/h2>\n

\nVous pourriez \u00e9galement \u00eatre int\u00e9ress\u00e9 par une autre publication r\u00e9cente de Dailymotion sur Kubernetes. Elle concerne le d\u00e9ploiement d'applications avec Helm sur plusieurs clusters Kubernetes et il a \u00e9t\u00e9 publi\u00e9<\/a><\/noindex> il y a environ un mois.<\/p>\n

Lisez aussi dans notre blog :<\/p>\n