Comment connecter des clusters Kubernetes dans différents centres de données

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 (Daniele Polenčić). Daniel travaille comme instructeur et développeur de logiciels dans Apprendrek8s.

Si vous souhaitez une réponse à votre question dans le prochain post, contactez-nous par email ou Twitter : @learnk8s.

Vous avez manqué des messages précédents ? Cherchez-les ici.

Comment connecter des clusters Kubernetes dans différents centres de données ?

Brièvement: Kubefed v2 bientôt disponible, et je vous conseille également de lire sur Expéditeur и projet de planification multi-cluster.

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 algorithme de radeaupour 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 la documentation officielle recommande d'utiliser un SSD au lieu de disques durs classiques.

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 - kubefed2, une nouvelle version du client et opérateur original de Kube Federation.

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: 5

Comme 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: 2

La 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 article officiel sur kubefed2 sur le blog Kubernetes et dépôt officiel du projet kubefed.

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.

Expéditeur 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: 3

Shipper 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 à personnaliser ou kapitan?

Apprenez-en davantage sur Shipper et sa philosophie sur ce communiqué de presse officiel.

Si vous voulez fouiller dans le code, aller au dépôt officiel du projet.

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 ?

multi-cluster-scheduler est un projet Admirality, 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 webhooks pour modifier l'accèspour 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 page du référentiel officiel.

Si vous souhaitez en savoir plus sur le planificateur multi-cluster en action, Admiralty a cas d'utilisation intéressant avec Argo - 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 :

• Sous-marinier par Rancher 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 Unimatrix associé à Spinnaker pour orchestrer le déploiement sur plusieurs clusters.
• Essayez d'utiliser IPV6 et réseau unique dans plusieurs régions.
• Vous pouvez utiliser un service mesh, par exemple Istio pour connecter plusieurs clusters.
• Cilium, un plugin d'interface réseau de conteneurs, propose fonction de maillage de cluster, 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, dites-nous.

Nous ajouterons votre méthode aux liens.

Un merci spécial à Chris Nesbitt-Smith (Chris Nesbitt Smith) et Vincent de PME (Vincent De Smet) (à l'ingénieur fiabilité de swatmobile.io) pour avoir lu l'article et partagé des informations utiles sur le fonctionnement de la fédération.

Source: habr.com