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

Bienvenue dans cette série de guides rapides sur Kubernetes. C'est une chronique régulière avec les questions les plus intéressantes que nous recevons en ligne et lors de nos formations. Répond à l'expert Kubernetes.

L'expert d'aujourd'hui est Daniele Polencic (Daniele Polencic). Daniele travaille comme instructeur et développeur logiciel chez Learnk8s.

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

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

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

En résumé: Kubefed v2 sortira bientôt, et je vous recommande également de lire sur le projet Shipper et multi-cluster-scheduler.

Il est assez courant que l'infrastructure soit répliquée et distribuée sur différentes régions, surtout dans des environnements contrôlés.

Si une région est inaccessible, 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 sur 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 un tel étalement géographique ?
Faut-il créer un grand cluster sur plusieurs clouds via un réseau unique ?
Ou créer de nombreux petits clusters et trouver un moyen de les contrôler et de les synchroniser ?

Un cluster centralisé

Créer un seul cluster sur un réseau unique n'est pas si simple.

Imaginez, vous avez un incident, la connectivité entre les segments du cluster est perdue.

Si vous avez un serveur maître, la moitié des ressources ne pourra pas recevoir de nouvelles commandes, car elles ne parviennent pas à se connecter au maître.

Et à cela, vous avez des anciennes tables de routage (kube-proxy ne peut pas charger de nouvelles) et aucun pod supplémentaire (kubelet ne peut pas demander de mises à jour).

Ce qui est encore pire, c'est que si Kubernetes ne voit pas un nœud, il le marque comme perdu et répartit les pods manquants sur les nœuds existants.

En fin de compte, vous avez deux fois plus de pods.

Si vous faites un serveur maître pour chaque région, il y aura des problèmes avec l'algorithme d'atteinte du consensus dans la base de données etcd. (note de l'éditeur — En réalité, la base de données etcd n'a pas besoin d'être sur les serveurs maîtres. Elle peut être lancée sur un groupe séparé de serveurs dans une même région. Cela dit, cela crée un point de défaillance pour le cluster. Mais c'est rapide.)

etcd utilise l'algorithme raft, pour parvenir à un consensus sur la valeur avant de l'écrire sur le disque.
En d'autres termes, la majorité des instances doivent parvenir à un consensus avant que l'état puisse être écrit dans etcd.

Si le temps de latence entre les instances etcd augmente rapidement, comme dans le cas de trois instances etcd dans différentes régions, il faut beaucoup de temps pour parvenir à un consensus et écrire la valeur sur le disque.
Cela se reflète également sur les contrôleurs Kubernetes.

Le gestionnaire de contrôleurs a besoin de plus de temps pour détecter le changement et écrire la réponse dans la base de données.

Et comme il n'y a pas un seul contrôleur, mais plusieurs, cela entraîne une réaction en chaîne et tout le cluster commence à fonctionner très lentement..

etcd est si sensible à la latence que la documentation officielle recommande d'utiliser des SSD au lieu de disques durs classiques..

Il n'existe actuellement pas de bons exemples de grands réseaux pour un seul cluster.

Principalement, la communauté des développeurs et le groupe SIG-cluster essaient de comprendre comment orchestrer des clusters comme Kubernetes orchestre des conteneurs.

Option 1 : fédération de clusters avec kubefed

La réponse officielle du SIG-cluster est — kubefed2, la nouvelle version du client open source et de l'opérateur de kube federation..

La première tentative de gestion d'une collection de clusters comme un objet unique a été réalisée à l'aide de l'outil kube federation.

Le début était prometteur, mais finalement, kube federation n'est pas devenu populaire car il ne prenait pas en charge toutes les ressources.

Il prenait en charge les déploiements combinés et les services, mais, par exemple, pas les StatefulSets.
De plus, la configuration de la fédération était transmise sous forme d'annotations et manquait de flexibilité.

Imaginez comment décrire le partage des réplicas pour chaque cluster dans la fédération à l'aide d'annotations uniques.

Cela a donné un véritable fouillis.

Le SIG-cluster a accompli un grand travail après kubefed v1 et a décidé d'aborder le problème sous un autre angle.

Au lieu d'annotations, ils ont choisi de publier un contrôleur qui s'installe sur les clusters. Celui-ci peut être configuré à l'aide de définitions de ressources personnalisées (Custom Resource Definition, CRD).

Pour chaque ressource qui fera partie de la fédération, vous avez une définition CRD personnalisée en trois sections :

• la définition de ressource standard, par exemple un déploiement ;
• avec un commutateur de pseudo-classe placement, où vous définissez comment la ressource sera distribuée dans la fédération ;
• avec un commutateur de pseudo-classe override, où pour une ressource spécifique, vous pouvez redéfinir le poids et les paramètres du placement.

Voici un exemple de déploiement fédéré avec les sections placement et override.

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, le déploiement est réparti sur deux clusters : cluster1 et cluster2.

Le premier cluster fournit trois répliques, tandis que le deuxième en a spécifié cinq.

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 réparties en fonction du poids :

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 CRD et l'API ne sont pas encore tout à fait prêtes, et un travail actif est en cours dans le dépôt officiel du projet.

Suivez kubefed2, mais gardez à l'esprit qu'il n'est pas encore prêt pour un environnement de production.

Découvrez-en plus sur kubefed2 dans l'article officiel sur kubefed2 dans le blog Kubernetes et dans le dépôt officiel du projet kubefed.

Option 2 : fusion des clusters à la façon de Booking.com

Les développeurs de Booking.com ne se sont pas occupés de kubefed v2, mais ont créé Shipper — un opérateur pour la livraison sur plusieurs clusters, dans plusieurs régions et sur plusieurs clouds.

projet Shipper qui ressemble à kubefed2.

Les deux outils permettent de configurer la stratégie de déploiement sur plusieurs clusters (quels clusters sont utilisés et combien de répliques ils ont).

Mais la tâche de Shipper est de réduire le risque d'erreurs lors du déploiement.

Avec Shipper, vous pouvez définir plusieurs étapes décrivant la répartition des répliques entre le déploiement précédent et actuel ainsi que le volume de trafic entrant.

Lorsque vous envoyez une ressource dans un cluster, le contrôleur Shipper déploie progressivement ce changement sur tous les clusters fédérés.

Et Shipper est aussi très limité.

Par exemple, il accepte les charts Helm comme entrées et ne prend pas en charge les ressources vanilla.
En gros, Shipper fonctionne de la manière suivante.

Au lieu de la livraison standard, vous devez créer une ressource d'application, comprenant un Helm chart :

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 son lien étroit avec Helm ne fait que compliquer les choses.

Et si nous passions tous de Helm à kustomize ou kapitan?

Découvrez-en plus sur Shipper et sa philosophie dans ce communiqué de presse officiel.

Si vous souhaitez fouiller dans le code, direction le dépôt officiel du projet.

Option 3 : la "magie" de la fédération de clusters

Kubefed v2 et Shipper fonctionnent avec la fédération de clusters, fournissant aux clusters de nouvelles ressources via une définition de ressources personnalisée.

Mais que faire si vous ne souhaitez pas réécrire toutes les livraisons, StatefulSets, DaemonSets, etc. pour la fédération ?

Comment inclure un cluster existant dans la fédération sans toucher au YAML ?

multi-cluster-scheduler est un projet d'Admirality, qui s'occupe des charges de travail en matière de planification dans les clusters.

Mais au lieu de trouver un nouveau moyen d'interagir avec le cluster et d'envelopper les ressources dans des définitions personnalisées, multi-cluster-scheduler s'intègre au 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 espace réservé.

multi-cluster-scheduler utilise des webhooks pour modifier l'accès, afin d'intercepter l'appel et de créer un pod vide inactif.

Le pod original passe par un autre cycle de planification, où après sondage de toute la fédération, une décision est prise quant au placement.

Enfin, le pod est livré au cluster cible.

Au final, vous vous retrouvez avec un pod supplémentaire qui ne fait rien, juste un peu de place.

L'avantage est que vous n'avez pas eu besoin d'écrire de nouvelles ressources pour fédérer les livraisons.

Chaque ressource qui crée un pod est automatiquement prête pour la fédération.

C'est intéressant, car vous avez soudainement des livraisons réparties sur plusieurs régions, et vous ne l'avez même pas remarqué. Toutefois, c'est assez risqué, car tout repose ici sur de la magie.

Mais si Shipper essaie principalement d'atténuer les conséquences des livraisons, le multi-cluster-scheduler s'occupe de tâches plus générales et peut-être est-il mieux adapté aux travaux par lots.

Il n'a pas de mécanisme avancé de livraisons progressives.

Pour en savoir plus sur le multi-cluster-scheduler, vous pouvez consulter la page du dépôt officiel..

Si vous souhaitez lire sur le multi-cluster-scheduler en action, Admiralty a un cas d'utilisation intéressant avec Argo — des workflows, des événements, CI et CD Kubernetes.

D'autres outils et solutions

Connecter et gérer plusieurs clusters est une tâche complexe, il n'existe pas de solution universelle.

Si vous voulez explorer ce sujet plus en détail, voici quelques ressources :

• Submariner de Rancher — un outil qui connecte les réseaux overlay de différents clusters Kubernetes.
• La chaîne de magasins Target utilise Unimatrix en combinaison avec Spinnaker pour orchestrer le déploiement sur plusieurs clusters..
• Essayez d'utiliser IPV6 et un réseau unique dans plusieurs régions..
• Vous pouvez utiliser un service mesh, par exemple Istio pour connecter plusieurs clusters..
• Cilium, un plugin pour l'interface réseau des conteneurs, propose une fonction de cluster mesh, qui permet de combiner plusieurs clusters.

C'est tout pour aujourd'hui.

Merci d'avoir lu jusqu'à la fin !

Si vous connaissez une méthode plus efficace pour connecter plusieurs clusters, faites-le nous savoir..

Nous ajouterons votre méthode aux liens.

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

Source : habr.com