Un cluster Kubernetes sur deux sites, une simple histoire de disponibilité, non ?

Nicolas TRAUWAEN

Ingénieur production / SRE

Sylvain MÉTAYER

Tech Lead

Contexte technique

Haute Disponibilité

Stretched cluster

Control Plane

Mono Control Plane

Multi Control Plane

En théorie, la mécanique reste la même : on bascule nos 3 control planes sur la région B. On a donc 3 control planes sur la région B.

=⇒ Attention, moi j’ai besoin d’avoir l’API disponible en continu, j’ai des opérateurs qui dépendent de l’API k8s ! Ca sert à rien ton truc de déplacer 3 nodes d’une même région, j’aurai le même downtime ?

Si on perds la région ou sont nos CP, plus rien pendant que ça remonte. Et pendant ce temps, les applications ne peuvent pas forcément être disponible. Donc, un seul CP ou 3 CP sur la mếmé région, sans hyperviseur capable de déplacer/restaurer les VMs à chaud, c’est pas vraiment la solution ?

Bon, bah on va faire du 2/1, ça doit être possible ? Qu’est-ce qu’il y a derrière ce fameux control plane qui nous en empêche de faire ça ? Voyons ça !

Raft consensus algorithm

Consensus, _subst. _masc.: Accord de plusieurs personnes, de plusieurs textes dans un domaine déterminé

https://cnrtl.fr/definition/consensus

Raft - Consensus

Network partition

# Partition Réseau - Description : Une partition réseau divise un cluster etcd en deux parties : une majorité et une minorité de membres. - Absence de "Split-brain" : etcd évite le phénomène de "split-brain" car les membres du cluster sont explicitement ajoutés ou retirés avec l’approbation de la majorité actuelle. - Split brain : quand deux membres sont leaders au même moment, créant un conflit dans les données écrites au moment de la synchro.

# Conséquences Selon la Position du Leader - Leader dans la Majorité : Si le leader est du côté majoritaire, la défaillance est perçue comme une défaillance des followers minoritaires. - Leader dans la Minorité : Si le leader est du côté minoritaire, il se retire, et un nouveau leader est élu par la majorité.

https://etcd.io/docs/v3.5/op-guide/failures/#network-partition

TODO contraintes partition / réseau / tabeau avantage/inconvénietn rapide // Corriger le schéma !

Défaillance pendant l’initialisation

Recovery

Gestion applicative

Un control plane haute disponibilité, mais un seul pod pour son application, ça n’a pas grand intérêt…

Anti-affinité

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: topology.kubernetes.io/region
  containers: # [...]

Affinité

apiVersion: v1
kind: Pod
metadata:
  name: my-bdd
spec:
  affinity:
    podAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app.kubernetes.io/name
              operator: In
              values:
              - my-redis
          topologyKey: topology.kubernetes.io/region
  containers: # [...]

Et pour du stateful ?

PostgreSQL (CNPG)

---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: database
spec:
  affinity:
    enablePodAntiAffinity: true
    podAntiAffinityType: required # or preferred
    topologyKey: topology.kubernetes.io/region
  instances: 2

⚠️

Kafka

https://strimzi.io/

Avant la version 4

Si vous êtes encore sous zookeeper, et bien déjà, sachez que vous ne pouvez plus mettre à jour vers de nouvelles versions, car Kraft est le mode par défaut pour les éléctions de leader.

Pourquoi on a besoin de Zookeeper ? Parce que c’est lui qui gère les élections de leader entre les brokers. En effet, si on perd une région, il faut élire un nouveau leader, et pour cela, il faut que Zookeeper soit accessible. Ainsi, la consommation/production dans les topics n’est possible que si Zookeeper est disponible, car c’est lui qui indiquera au broker quelle est la partition leader.

https://kafka.apache.org/documentation/

Comment on fait dans ce cas ? On doit garantir la stabilité de notre zookeeper, et dans ce cas, s’assurer qu’il soit répartir sur les 2 régions, et en cas de crash de la région ou N/2-1, rétablir manuellement l’accès au service, via provisionnement d’un nouveau node zookeeper.

À partir de la version 4

⚠️ Depuis Kafka 4.0, le mode de fonctionnement par défaut est Kraft (Kafka Raft). Il n’y a plus de fonctionnement possible avec Zookeeper ⚠️

Si vous avez déjà migré sur Kraft (ça vous rappelle quelques choses ?), vous ne devriez rien avoir à faire, si ce n’est faire attention à la configuration de vos topics, afin de s’assurer de la bonne réplications de vos données. En effet, l’election est géré par les brokers eux-mêmes et non plus par Zookeeper. Il n’y a donc plus de dépendance à Zookeeper pour l’élection des leaders, mais il faut tout de même s’assurer que les brokers sont bien répartis sur les deux régions.

Cependant, attention à la configuration applicative de vos topics, sinon, vous pourriez avoir un kafka certes disponible, mais les données de vos topics ne seront pas répliquées entre les deux régions.

⚠️ Pensez à vos topics !

---
kind: Kafka
metadata:
  name: kafka
spec:
  kafka:
    rack:
      topologyKey: topology.kubernetes.io/region
    config:
      replica.selector.class: org.apache.kafka.common.replica.RackAwareReplicaSelector
      min.insync.replicas: 2

Kubernetes sur 2 régions, on y va ?

Alternatives : Une troisième zone ?

Alternatives : Du stockage distribué ?

Rook

Longhorn

Alternatives : Externaliser le stockage ?

Alternatives : Multi cluster

Alternatives : Multi cluster federation

Liens