{"id":34825,"date":"2019-10-31T22:00:35","date_gmt":"2019-10-31T19:00:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah\/"},"modified":"2019-10-31T22:00:35","modified_gmt":"2019-10-31T19:00:35","slug":"kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-soedinit-klastery-kubernetes-v-raznyh-data-tsentrah","title":{"rendered":"Comment connecter des clusters Kubernetes dans diff\u00e9rents centres de donn\u00e9es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Comment
\nBienvenue dans cette s\u00e9rie de guides rapides sur Kubernetes.<\/strong> C'est une chronique r\u00e9guli\u00e8re avec les questions les plus int\u00e9ressantes que nous recevons en ligne et lors de nos formations. R\u00e9pond \u00e0 l'expert Kubernetes.<\/p>\n

<\/p>\n

L'expert d'aujourd'hui est Daniele Polencic (Daniele Polencic<\/a><\/noindex>). Daniele travaille comme instructeur et d\u00e9veloppeur logiciel chez Learnk8s<\/a><\/noindex>.<\/p><\/blockquote>\n

Si vous souhaitez obtenir une r\u00e9ponse \u00e0 votre question dans le prochain post, contactez-nous par e-mail<\/a><\/noindex> ou sur Twitter : @learnk8s<\/a><\/noindex>.<\/p>\n

<\/p>\n

Vous avez manqu\u00e9 les posts pr\u00e9c\u00e9dents ? Cherchez-les ici<\/a><\/noindex>.<\/p>\n

<\/p>\n

Comment connecter des clusters Kubernetes dans diff\u00e9rents centres de donn\u00e9es ?<\/h3>\n

<\/p>\n

En r\u00e9sum\u00e9<\/strong>: Kubefed v2 sortira bient\u00f4t<\/a><\/noindex>, et je vous recommande \u00e9galement de lire sur le projet Shipper<\/a><\/noindex> et multi-cluster-scheduler<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Il est assez courant que l'infrastructure soit r\u00e9pliqu\u00e9e et distribu\u00e9e sur diff\u00e9rentes r\u00e9gions, surtout dans des environnements contr\u00f4l\u00e9s.<\/p><\/blockquote>\n

Si une r\u00e9gion est inaccessible, le trafic est redirig\u00e9 vers une autre pour \u00e9viter les interruptions.<\/strong><\/p>\n

<\/p>\n

Avec Kubernetes, vous pouvez utiliser une strat\u00e9gie similaire et r\u00e9partir les charges de travail sur diff\u00e9rentes r\u00e9gions.<\/p>\n

<\/p>\n

Vous pouvez avoir un ou plusieurs clusters par \u00e9quipe, r\u00e9gion, environnement ou une combinaison de ces \u00e9l\u00e9ments.<\/p>\n

<\/p>\n

Vos clusters peuvent \u00eatre h\u00e9berg\u00e9s dans diff\u00e9rents clouds et dans un environnement local.<\/p>\n

<\/p>\n

Mais comment planifier l'infrastructure pour un tel \u00e9talement g\u00e9ographique ?
\nFaut-il cr\u00e9er un grand cluster sur plusieurs clouds via un r\u00e9seau unique ?
\nOu cr\u00e9er de nombreux petits clusters et trouver un moyen de les contr\u00f4ler et de les synchroniser ?<\/em><\/p>\n

<\/p>\n

Un cluster centralis\u00e9<\/h3>\n

<\/p>\n

Cr\u00e9er un seul cluster sur un r\u00e9seau unique n'est pas si simple.<\/em><\/p>\n

<\/p>\n

Imaginez, vous avez un incident, la connectivit\u00e9 entre les segments du cluster est perdue.<\/p>\n

<\/p>\n

Si vous avez un serveur ma\u00eetre, la moiti\u00e9 des ressources ne pourra pas recevoir de nouvelles commandes, car elles ne parviennent pas \u00e0 se connecter au ma\u00eetre.<\/p>\n

<\/p>\n

Et \u00e0 cela, vous avez des anciennes tables de routage (kube-proxy<\/code> ne peut pas charger de nouvelles) et aucun pod suppl\u00e9mentaire (kubelet ne peut pas demander de mises \u00e0 jour).<\/p>\n

<\/p>\n

Ce qui est encore pire, c'est que si Kubernetes ne voit pas un n\u0153ud, il le marque comme perdu et r\u00e9partit les pods manquants sur les n\u0153uds existants.<\/p>\n

<\/p>\n

En fin de compte, vous avez deux fois plus de pods.<\/strong><\/p>\n

<\/p>\n

Si vous faites un serveur ma\u00eetre pour chaque r\u00e9gion, il y aura des probl\u00e8mes avec l'algorithme d'atteinte du consensus dans la base de donn\u00e9es etcd. (note de l'\u00e9diteur \u2014 En r\u00e9alit\u00e9, la base de donn\u00e9es etcd n'a pas besoin d'\u00eatre sur les serveurs ma\u00eetres. Elle peut \u00eatre lanc\u00e9e sur un groupe s\u00e9par\u00e9 de serveurs dans une m\u00eame r\u00e9gion. Cela dit, cela cr\u00e9e un point de d\u00e9faillance pour le cluster. Mais c'est rapide.<\/em>)<\/p>\n

<\/p>\n

etcd utilise l'algorithme raft<\/a><\/noindex>, pour parvenir \u00e0 un consensus sur la valeur avant de l'\u00e9crire sur le disque.
\nEn d'autres termes, la majorit\u00e9 des instances doivent parvenir \u00e0 un consensus avant que l'\u00e9tat puisse \u00eatre \u00e9crit dans etcd.<\/p>\n

<\/p>\n

Si le temps de latence entre les instances etcd augmente rapidement, comme dans le cas de trois instances etcd dans diff\u00e9rentes r\u00e9gions, il faut beaucoup de temps pour parvenir \u00e0 un consensus et \u00e9crire la valeur sur le disque.
\nCela se refl\u00e8te \u00e9galement sur les contr\u00f4leurs Kubernetes.<\/p>\n

<\/p>\n

Le gestionnaire de contr\u00f4leurs a besoin de plus de temps pour d\u00e9tecter le changement et \u00e9crire la r\u00e9ponse dans la base de donn\u00e9es.<\/p>\n

<\/p>\n

Et comme il n'y a pas un seul contr\u00f4leur, mais plusieurs, cela entra\u00eene une r\u00e9action en cha\u00eene et tout le cluster commence \u00e0 fonctionner tr\u00e8s lentement.<\/strong>.<\/p>\n

<\/p>\n

etcd est si sensible \u00e0 la latence que la documentation officielle recommande d'utiliser des SSD au lieu de disques durs classiques.<\/a><\/noindex>.<\/p>\n

<\/p>\n

Il n'existe actuellement pas de bons exemples de grands r\u00e9seaux pour un seul cluster.<\/strong><\/p>\n

<\/p>\n

Principalement, la communaut\u00e9 des d\u00e9veloppeurs et le groupe SIG-cluster essaient de comprendre comment orchestrer des clusters comme Kubernetes orchestre des conteneurs.<\/p>\n

<\/p>\n

Option 1 : f\u00e9d\u00e9ration de clusters avec kubefed<\/h3>\n

<\/p>\n

La r\u00e9ponse officielle du SIG-cluster est \u2014 kubefed2, la nouvelle version du client open source et de l'op\u00e9rateur de kube federation.<\/a><\/noindex>.<\/p>\n

<\/p>\n

La premi\u00e8re tentative de gestion d'une collection de clusters comme un objet unique a \u00e9t\u00e9 r\u00e9alis\u00e9e \u00e0 l'aide de l'outil kube federation.<\/p>\n

<\/p>\n

Le d\u00e9but \u00e9tait prometteur, mais finalement, kube federation n'est pas devenu populaire car il ne prenait pas en charge toutes les ressources.<\/p>\n

<\/p>\n

Il prenait en charge les d\u00e9ploiements combin\u00e9s et les services, mais, par exemple, pas les StatefulSets.
\nDe plus, la configuration de la f\u00e9d\u00e9ration \u00e9tait transmise sous forme d'annotations et manquait de flexibilit\u00e9.<\/p>\n

<\/p>\n

Imaginez comment d\u00e9crire le partage des r\u00e9plicas pour chaque cluster dans la f\u00e9d\u00e9ration \u00e0 l'aide d'annotations uniques.<\/em><\/p>\n

<\/p>\n

Cela a donn\u00e9 un v\u00e9ritable fouillis.<\/strong><\/p>\n

<\/p>\n

Le SIG-cluster a accompli un grand travail apr\u00e8s kubefed v1 et a d\u00e9cid\u00e9 d'aborder le probl\u00e8me sous un autre angle.<\/p>\n

<\/p>\n

Au lieu d'annotations, ils ont choisi de publier un contr\u00f4leur qui s'installe sur les clusters. Celui-ci peut \u00eatre configur\u00e9 \u00e0 l'aide de d\u00e9finitions de ressources personnalis\u00e9es (Custom Resource Definition, CRD).<\/strong><\/p>\n

<\/p>\n

Pour chaque ressource qui fera partie de la f\u00e9d\u00e9ration, vous avez une d\u00e9finition CRD personnalis\u00e9e en trois sections :<\/p>\n

<\/p>\n