Bienvenue dans la série de didacticiels rapides Kubernetes. Ceci est une chronique régulière avec les questions les plus intéressantes que nous recevons en ligne et lors de nos formations. L'expert de Kubernetes répond.
L'expert d'aujourd'hui est Daniele Polencic . Daniel est instructeur et développeur de logiciels chez Learnk8s .
Si vous souhaitez répondre à votre question dans le prochain post, veuillez nous contacter par email ou sur Twitter: @ learnk8s .
Messages précédents ignorés? Cherchez-les ici .
Comment connecter les clusters Kubernetes dans différents centres de données?
En bref : Kubefed v2 arrive bientôt , et je vous conseille également de lire Shipper et le projet multi-cluster-scheduler .
Très souvent, l'infrastructure est répliquée et distribuée dans différentes régions, en particulier dans des environnements contrôlés.
Si une région n'est pas disponible, le trafic est redirigé vers une autre pour éviter les interruptions.
Avec Kubernetes, vous pouvez utiliser une stratégie similaire et répartir les charges de travail entre différentes régions.
Vous pouvez avoir un ou plusieurs clusters par équipe, région, environnement ou une combinaison de ces éléments.
Vos clusters peuvent être hébergés dans différents clouds et dans un environnement local.
Mais comment planifier l'infrastructure pour une telle répartition géographique?
Besoin de créer un grand cluster dans plusieurs environnements cloud sur un seul réseau?
Ou démarrer un grand nombre de petits clusters et trouver un moyen de les contrôler et de les synchroniser?
Un cluster principal
La création d'un cluster unique sur un seul réseau n'est pas si simple.
Imaginez que vous ayez un accident, une perte de connectivité entre les segments du cluster.
Si vous avez un serveur maître, la moitié des ressources ne pourront pas recevoir de nouvelles commandes, car elles ne pourront pas contacter le maître.
Et en même temps, vous avez d'anciennes tables de routage ( kube-proxy ne peut pas en charger de nouvelles) et aucun pod supplémentaire (kubelet ne peut pas demander de mises à jour).
Pour aggraver les choses, si Kubernetes ne voit pas le nœud, il le marque comme perdu et distribue les pods manquants aux nœuds existants.
En conséquence, vous avez deux fois plus de pods.
Si vous créez un serveur maître pour chaque région, il y aura des problèmes avec l'algorithme de consensus dans la base de données etcd. ( environ Ed. - En fait, la base de données etcd n'a pas besoin d'être située sur les serveurs maîtres. Elle peut être exécutée sur un groupe distinct de serveurs dans la même région. Cependant, en même temps, elle a reçu un point de défaillance de cluster. Mais rapidement. )
etcd utilise l'algorithme raft pour négocier la valeur avant de l'écrire sur le disque.
Autrement dit, la plupart des instances doivent parvenir à un consensus avant que l'État puisse être écrit sur etcd.
Si le délai entre les instances de etcd augmente considérablement, comme c'est le cas avec trois instances de etcd dans différentes régions, il faut beaucoup de temps pour réconcilier la valeur et l'écrire sur le disque.
Cela se reflète dans les contrôleurs Kubernetes.
Le gestionnaire du contrôleur a besoin de plus de temps pour en savoir plus sur la modification et écrire la réponse dans la base de données.
Et comme le contrôleur n'est pas un, mais plusieurs, une réaction en chaîne est obtenue et l'ensemble du cluster commence à fonctionner très lentement .
etcd est si sensible à la latence que la documentation officielle recommande d'utiliser des SSD au lieu des disques durs ordinaires .
Il n'existe actuellement aucun bon exemple de grand réseau pour un seul cluster.
Fondamentalement, la communauté de développement et le groupe de clusters SIG tentent de comprendre comment orchestrer les clusters de la même manière que Kubernetes orchestre les conteneurs.
Option 1: fédération de clusters avec kubefed
La réponse officielle de SIG-cluster est kubefed2, une nouvelle version de la fédération kube client et opérateur d'origine .
Pour la première fois, ils ont essayé de gérer la collection de clusters en tant qu'objet unique à l'aide de l'outil de fédération kube.
Le début a été bon, mais au final, la fédération kube n'est pas devenue populaire car elle ne supportait pas toutes les ressources.
Il a soutenu les livraisons et les services communs, mais pas, par exemple, les StatefulSets.
Et la configuration de la fédération a été transmise sous forme d'annotations et n'était pas flexible.
Imaginez comment vous pouvez décrire la séparation des répliques pour chaque cluster dans une fédération en utilisant uniquement des annotations.
Cela s'est avéré être un gâchis complet.
SIG-cluster a fait un excellent travail après kubefed v1 et a décidé d'aborder le problème de l'autre côté.
Au lieu d'annotations, ils ont décidé de libérer un contrôleur installé sur les clusters. Il peut être configuré à l'aide de la définition de ressource personnalisée (CRD).
Pour chaque ressource qui fera partie de la fédération, vous disposez d'une définition CRD personnalisée de trois sections:
- définition standard d'une ressource, telle que déploiement;
- section de
placement , où vous déterminez comment la ressource sera distribuée dans la fédération; override section, où, pour une ressource particulière, vous pouvez remplacer le poids et les paramètres du placement.
Voici un exemple de livraison combinée avec des sections de placement et de remplacement.
apiVersion: types.federation.k8s.io/v1alpha1 kind: FederatedDeployment metadata: name: test-deployment namespace: test-namespace spec: template: metadata: labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster2 - cluster1 overrides: - clusterName: cluster2 clusterOverrides: - path: spec.replicas value: 5
Comme vous pouvez le voir, l'approvisionnement est réparti sur deux clusters: cluster1 et cluster2 .
Le premier cluster fournit trois répliques, tandis que le second est défini sur 5.
Si vous avez besoin de plus de contrôle sur le nombre de répliques, kubefed2 fournit un nouvel objet ReplicaSchedulingPreference, où les répliques peuvent être pondérées:
apiVersion: scheduling.federation.k8s.io/v1alpha1 kind: ReplicaSchedulingPreference metadata: name: test-deployment namespace: test-ns spec: targetKind: FederatedDeployment totalReplicas: 9 clusters: A: weight: 1 B: weight: 2
La structure et l'API de CRD ne sont pas encore prêtes et un travail actif est en cours dans le référentiel officiel du projet.
Attention à kubefed2, mais n'oubliez pas qu'il n'est pas encore adapté à l'environnement de travail.
En savoir plus sur kubefed2 dans l' article officiel de kubefed2 sur le blog de Kubernetes et dans le référentiel de projets kubefed officiel .
Option 2: clustering de clusters de style Booking.com
Les développeurs de Booking.com n'ont pas traité de kubefed v2, mais ils ont trouvé Shipper, un opérateur pour la livraison sur plusieurs clusters, dans plusieurs régions et dans plusieurs nuages.
Shipper est quelque chose de similaire à kubefed2.
Les deux outils vous permettent de configurer la stratégie de déploiement pour plusieurs clusters (quels clusters sont utilisés et combien de réplicas ils ont).
Mais l'objectif de Shipper est de réduire le risque d'erreurs de livraison.
Dans Shipper, vous pouvez définir une série d'étapes qui décrivent la séparation des répliques entre le déploiement précédent et actuel et la quantité de trafic entrant.
Lorsque vous soumettez une ressource à un cluster, le contrôleur Shipper déploie cette modification étape par étape sur tous les clusters combinés.
Et l'expéditeur est très limité.
Par exemple, il accepte les graphiques Helm en entrée et ne prend pas en charge les ressources vanilla.
De manière générale, l'expéditeur fonctionne comme suit.
Au lieu de la livraison standard, vous devez créer une ressource d'application qui inclut le graphique Helm:
apiVersion: shipper.booking.com/v1alpha1 kind: Application metadata: name: super-server spec: revisionHistoryLimit: 3 template: chart: name: nginx repoUrl: https://storage.googleapis.com/shipper-demo version: 0.0.1 clusterRequirements: regions: - name: local strategy: steps: - capacity: contender: 1 incumbent: 100 name: staging traffic: contender: 0 incumbent: 100 - capacity: contender: 100 incumbent: 0 name: full on traffic: contender: 100 incumbent: 0 values: replicaCount: 3
Shipper est une bonne option pour gérer plusieurs clusters, mais sa relation étroite avec Helm n'interfère que.
Et si nous passions tous de Helm à kustomize ou kapitan ?
En savoir plus sur Shipper et sa philosophie dans ce communiqué de presse officiel .
Si vous souhaitez vous plonger dans le code, accédez au référentiel officiel du projet .
Option 3: rejoindre un cluster «magique»
Kubefed v2 et Shipper fonctionnent avec la fédération de clusters, fournissant aux clusters de nouvelles ressources via des définitions de ressources personnalisées.
Mais que se passe-t-il si vous ne souhaitez pas réécrire toutes les fournitures, StatefulSets, DaemonSets, etc. à combiner?
Comment inclure un cluster existant dans une fédération sans changer YAML?
multi-cluster-scheduler est un projet Admirality qui gère la planification des charges de travail dans les clusters.
Mais au lieu de proposer une nouvelle façon d'interagir avec le cluster et d'envelopper les ressources dans des définitions définies par l'utilisateur, le planificateur multi-cluster est intégré dans le cycle de vie Kubernetes standard et intercepte tous les appels créés par les pods.
Chacun créé sous immédiatement remplacé par un mannequin.
multi-cluster-scheduler utilise des crochets Web pour modifier l'accès pour intercepter l'appel et créer un mannequin de pod inactif.
Le module source passe par un autre cycle de planification, où après une enquête auprès de l'ensemble de la fédération, une décision est prise sur le placement.
Enfin, le pod est livré au cluster cible.
En conséquence, vous avez un pod supplémentaire qui ne fait rien, prend juste de l'espace.
L'avantage est que vous n'avez pas eu à écrire de nouvelles ressources pour combiner les fournitures.
Chaque ressource créant un module est automatiquement prête à être fusionnée.
C'est intéressant, car vous avez soudainement des livraisons réparties sur plusieurs régions, mais vous ne l'avez pas remarqué. Cependant, c'est assez risqué, car ici tout repose sur la magie.
Mais si Shipper essaie principalement d'atténuer les effets des fournitures, le planificateur multi-cluster effectue des tâches plus générales et est probablement mieux adapté aux travaux par lots.
Il ne dispose pas d'un mécanisme d'approvisionnement progressif avancé.
Vous pouvez en savoir plus sur le planificateur multi-cluster sur la page officielle du référentiel .
Si vous souhaitez en savoir plus sur le planificateur multi-cluster en action, Admiralty a un cas d'utilisation intéressant avec Argo - workflows, événements, CI et CD Kubernetes.
Autres outils et solutions
Connecter et gérer plusieurs clusters est une tâche complexe, il n'y a pas de solution universelle.
Si vous souhaitez en savoir plus sur ce sujet, voici quelques ressources:
C'est tout pour aujourd'hui
Merci d'avoir lu jusqu'au bout!
Si vous savez comment connecter plus efficacement plusieurs clusters, dites-le-nous .
Nous ajouterons votre méthode aux liens.
Un merci spécial à Chris Nesbitt-Smith et Vincent De Smet (ingénieur en fiabilité chez swatmobile.io ) pour avoir lu cet article et partagé quelques informations utiles sur le fonctionnement de la fédération.