Bienvenue dans la série de démarrage rapide Kubernetes. Il s'agit d'une chronique régulière contenant les questions les plus intéressantes que nous recevons en ligne et lors de nos formations. Réponses d’experts Kubernetes.
L'expert du jour est Daniel Polenchik (). Daniel travaille comme instructeur et développeur de logiciels dans .
Si vous souhaitez une réponse à votre question dans le prochain post, ou .
Vous avez manqué des messages précédents ? .
Comment connecter des clusters Kubernetes dans différents centres de données ?
Brièvement: , et je vous conseille également de lire sur и .
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 est indisponible, 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 ceux-ci.
Vos clusters peuvent être hébergés sur plusieurs cloud et sur site.
Mais comment planifier les infrastructures pour une telle répartition géographique ?
Avez-vous besoin de créer un grand cluster pour plusieurs environnements cloud sur un seul réseau ?
Ou avoir de nombreux petits clusters et trouver un moyen de les contrôler et de les synchroniser ?
Un pôle de leadership
Créer un cluster sur un seul réseau n'est pas si simple.
Imaginez que vous ayez un accident, la connectivité entre les segments du cluster est perdue.
Si vous disposez d'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 télécharger de nouveaux) et aucun pod supplémentaire (kubelet ne peut pas demander de mises à jour).
Pire encore, si Kubernetes ne peut pas voir un nœud, il le marque comme orphelin et distribue les pods manquants aux nœuds existants.
En conséquence, vous disposez de deux fois plus de pods.
Si vous créez un serveur maître par région, il y aura des problèmes avec l'algorithme de consensus dans la base de données etcd. (environ. éd. - En effet, la base de données etcd n'a pas besoin d'être localisée sur les serveurs maîtres. Il peut être exécuté sur un groupe distinct de serveurs dans la même région. Cependant, ayant reçu en même temps un point de défaillance d'un cluster. Mais rapidement.)
etcd utilise pour se mettre d'accord sur une 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 dans etcd.
Si la latence entre les instances etcd monte en flèche, comme c'est le cas avec trois instances etcd dans différentes régions, il faut beaucoup de temps pour se mettre d'accord sur une valeur et l'écrire sur le disque.
Cela se reflète également dans les contrôleurs Kubernetes.
Le responsable du contrôleur a besoin de plus de temps pour prendre connaissance du changement 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 .
Il n’existe actuellement aucun bon exemple de grand réseau pour un seul cluster.
Fondamentalement, la communauté des développeurs et le groupe SIG-cluster tentent de comprendre comment orchestrer les clusters de la même manière que Kubernetes orchestre les conteneurs.
Option 1 : fédérer les clusters avec kubefed
Réponse officielle du cluster SIG - .
Pour la première fois, nous avons essayé de gérer une collection de clusters comme un seul objet à l'aide de l'outil de fédération Kube.
Le début était bon, mais à la fin, la fédération Kube n'est pas devenue populaire, car elle ne prenait pas en charge toutes les ressources.
Il prenait en charge les fournitures et services fédérés, mais pas les StatefulSets, par exemple.
De plus, 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 division des réplicas pour chaque cluster dans une fédération à l'aide d'une seule annotation.
Cela s’est avéré être un désastre total.
Le cluster SIG a fait un excellent travail après Kubefed v1 et a décidé d'aborder le problème sous un angle différent.
Au lieu d'annotations, ils ont décidé de publier un contrôleur installé sur des clusters. Il peut être configuré à l'aide de définitions de ressources personnalisées (Custom Resource Definition, CRD).
Pour chaque ressource qui sera fédérée, vous disposez d'une définition CRD personnalisée en trois sections :
- une définition standard d'une ressource, telle que déployer ;
- section
placement, où vous définissez comment la ressource sera distribuée dans la fédération ; - section
override, où pour une ressource spécifique, 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: 5Comme vous pouvez le constater, l’offre est divisée en deux clusters : cluster1 и cluster2.
Le premier cluster fournit trois réplicas et le second a une valeur de 5.
Si vous avez besoin de plus de contrôle sur le nombre de réplicas, kubefed2 fournit un nouvel objet ReplicaSchedulingPreference dans lequel les réplicas peuvent être pondérés :
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: 2La structure du CRD et l'API ne sont pas encore tout à fait prêtes et un travail actif est en cours dans le référentiel officiel du projet.
Gardez un œil sur kubefed2, mais gardez à l'esprit qu'il n'est pas encore assez performant pour un environnement de production.
En savoir plus sur kubefed2 à partir de sur le blog Kubernetes et .
Option 2 : regroupement du style Booking.com
Les développeurs de Booking.com n'ont pas traité de Kubefed v2, mais ils ont proposé Shipper, un opérateur de livraison sur plusieurs clusters, plusieurs régions et plusieurs cloud.
un peu similaire à kubefed2.
Les deux outils vous permettent de personnaliser votre stratégie de déploiement multicluster (quels clusters sont utilisés et combien de réplicas ils possèdent).
Mais L'objectif de l'expéditeur est de réduire les risques d'erreurs lors de la livraison.
Dans Shipper, vous pouvez définir une série d'étapes qui décrivent la répartition des réplicas entre les déploiements précédent et actuel ainsi que la quantité de trafic entrant.
Lorsque vous transférez une ressource vers un cluster, le contrôleur Shipper déploie progressivement cette modification sur tous les clusters fédérés.
L'expéditeur est également très limité.
Par exemple, il prend les cartes Helm en entrée et ne prend pas en charge les ressources Vanilla.
De manière générale, Shipper fonctionne comme suit.
Au lieu d'une distribution standard, vous devez créer une ressource d'application qui inclut un 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: 3Shipper est une bonne option pour gérer plusieurs clusters, mais sa relation étroite avec Helm ne fait que gêner.
Et si nous passions tous de Helm à ou ?
Apprenez-en davantage sur Shipper et sa philosophie sur .
Si vous voulez fouiller dans le code, .
Option 3 : fusion de clusters « magique »
Kubefed v2 et Shipper fonctionnent avec la fédération de clusters, fournissant de nouvelles ressources aux clusters via une définition de ressources personnalisée.
Mais que se passe-t-il si vous ne souhaitez pas réécrire toutes les diffusions, StatefulSets, DaemonSets, etc. pour les fusionner ?
Comment inclure un cluster existant dans une fédération sans changer YAML ?
, qui traite de la planification des charges de travail sur les clusters.
Mais au lieu d'inventer une nouvelle façon d'interagir avec le cluster et d'encapsuler les ressources dans des définitions personnalisées, le planificateur multi-cluster est injecté dans le cycle de vie standard de Kubernetes et intercepte tous les appels qui créent des pods.
Chaque pod créé est immédiatement remplacé par un factice.
utilisations du planificateur multi-cluster pour intercepter l'appel et créer un pod factice inactif.
Le module d'origine passe par un autre cycle de planification au cours duquel, après avoir interrogé l'ensemble de la fédération, une décision d'hébergement est prise.
Enfin, le pod est livré au cluster cible.
En conséquence, vous disposez d’un pod supplémentaire qui ne fait rien, prend juste de la place.
L'avantage est que vous n'avez pas besoin d'écrire de nouvelles ressources pour combiner les fournitures.
Chaque ressource qui crée un pod est automatiquement prête à être fédérée.
C’est intéressant, car vous avez soudain des approvisionnements répartis dans plusieurs régions, et vous ne vous en êtes pas rendu compte. C’est cependant assez risqué, car ici tout repose sur la magie.
Mais alors que Shipper tente principalement d’atténuer les effets des expéditions, le planificateur multi-cluster est plus général et peut-être mieux adapté aux tâches par lots.
Il ne dispose pas d’un mécanisme avancé de livraison progressive.
Pour en savoir plus sur le planificateur multi-cluster, consultez .
Si vous souhaitez en savoir plus sur le planificateur multi-cluster en action, Admiralty a - workflows, événements, CI et CD Kubernetes.
Autres outils et solutions
La connexion et la gestion de plusieurs clusters sont une tâche complexe et il n'existe pas de solution universelle.
Si vous souhaitez approfondir ce sujet, voici quelques ressources :
- est un outil qui connecte les réseaux superposés de différents clusters Kubernetes.
- La chaîne de vente au détail Target utilise .
- Essayez d'utiliser IPV6 et .
- Vous pouvez utiliser un service mesh, par exemple .
- Cilium, un plugin d'interface réseau de conteneurs, propose , qui permet de combiner plusieurs clusters
C'est tout pour aujourd'hui
Merci d'avoir lu jusqu'au bout !
Si vous savez comment connecter plus efficacement plusieurs clusters, .
Nous ajouterons votre méthode aux liens.
Un merci spécial à Chris Nesbitt-Smith () et Vincent de PME () (à l'ingénieur fiabilité de ) pour avoir lu l'article et partagé des informations utiles sur le fonctionnement de la fédération.
Source: habr.com