Haute Disponibilité

Ce guide présente l'ensemble des éléments de configuration nécessaires pour améliorer la disponibilité et la continuité de service de vos applications déployées dans un cluster Kubernetes managés par cegedim.cloud.

Il s'agit d'un guide indispensable pour que votre stratégie de reprise après sinistre réponde aux exigences de cegedim.cloud.

Comment configurer les déploiements pour tirer parti des capacités HA ?

Une fois votre cluster Kubernetes configuré pour fonctionner selon la topologie de haute disponibilité (HA), certaines bonnes pratiques de configuration sont nécessaires pour permettre à vos applications :

• pour fonctionner de façon simultanée sur tous les centres de données de la région.

• de disposer d'une capacité suffisante dans tous les centres de données en cas de catastrophe sur l'un d'entre eux

Configuration du déploiement

Pour rappel, les nœuds des clusters Kubernetes sont répartis dans 3 zones de disponibilité (AZ) et 2 centres de données :

• AZ "A" et "B" fonctionnent sur le centre de données primaire.

• AZ "C" fonctionne sur le centre de données secondaire.

Nombre de répliques

Pour les services sans état qui prennent en charge la mise à l'échelle, la meilleure pratique consiste à faire fonctionner au moins trois pods :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    name: myapp
spec:
  replicas: 3

Anti-affinité

Ces 3 pods doivent être correctement configurés pour qu'au moins un pod fonctionne sur chaque zone de disponibilité :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - nginx
              topologyKey: "failure-domain.beta.kubernetes.io/zone"
      containers:
      - name: web-app
        image: nginx

Nous utilisons preferedDuringSchedulingIgnoredDuringExecution et non requiredDuringSchedulingIgnoredDuringExecution car nous voulons que cette exigence soit "souple" : Kubernetes permettra alors de programmer plusieurs pods sur la même AZ si vous exécutez plus de répliques que d'AZ, ou en cas de défaillance d'une zone.

Contraintes d'étalement pour les pods

Comment dimensionner votre cluster HA ?

Si vous utilisez la topologie de cluster haute disponibilité, votre objectif est de déployer des applications résilientes en cas de panne du centre de données.

Cette page décrit quelques bonnes pratiques pour déterminer le dimensionnement des nœuds de travail pour chaque zone de disponibilité où vos charges de travail sont exécutées.

Réfléchir au "pire des scénarios".

Pour rappel, Kubernetes Cluster est déployé dans 3 zones de disponibilité, et 2 centres de données. Dans le pire des cas, une seul zone de disponibilité fonctionnera si le centre de données primaire subit un sinistre majeur.

C'est l'hypothèse à prendre en compte pour déterminer le dimensionnement "nominal", que l'on peut appeler "Si le centre de données primaire tombe en panne, de quelle capacité de CPU / RAM ai-je besoin pour continuer à faire fonctionner mon application ?".

Définir la capacité nominale

Comprendre vos besoins

Pour déterminer cette capacité, puis les nœuds de travail déployés dans la zone de disponibilité "C" (combien, et avec quelles ressources), vous aurez besoin de 3 paramètres :

Calculer le dimensionnement

Vous avez alors deux possibilités pour calculer la taille :

• Au niveau de la granularité "Cluster Level": si vous débutez le processus et que vos charges de travail ne sont pas aussi complexes ou variables, utilisez cette option :

  • Déterminer un MBCO global pour les déploiements croisés

  • Additionner toutes les demandes de ressources des pods pour obtenir un numéro unique.

  • Additionner toutes les ressources utilisées par les pods pour obtenir un nombre unique.

• Au niveau de la granularité "Pod Level" : Si vous voulez que le dimensionnement soit parfaitement adapté et que vous en avez le temps, prenez le temps de déterminer ces paramètres pour chaque déploiement de votre cluster Kubernetes, car le MBCO peut varier ! Par exemple :

  • Une application web nécessitera un MBCO avec 100 %.

  • Un cache nécessitera un MBCO de 50%.

  • Une fonctionnalité "agréable à avoir" ou un outil interne peut être à 0 %.

Utilisation de la granularité au niveau des clusters

Si vous avez additionné toutes les demandes et l'utilisation, et que vous avez déterminé le MBCO au niveau du "cluster", vous pouvez utiliser cette formule simple pour calculer le dimensionnement requis pour l'AZ "C" dans le centre de données secondaire :

required_capacity = MBCO * max(requests, usage)

Utilisation de la granularité "Pod

Si vous avez déterminé un MBCO par déploiement, vous devrez calculer votre dimensionnement avec une formule plus complexe :

required_capacity = sum(pod.MBCO * max(pod.requests, pod.usage))

Ajustez vos descripteurs de déploiement

Une fois que vous avez calculé votre MBCO, il est important de tirer parti des capacités de Kubernetes (QoS, notamment PodDisruptionBudget) pour que votre déploiement suive votre décision.

Ajustez la taille de votre groupe

Utilisez ITCare ou demandez l'aide de notre support pour dimensionner votre cluster.

Comment utiliser la QoS et la disponibilité garantie de Kubernetes ?

Au cours de cette phase, vous devrez hiérarchiser vos actifs et définir les composants qui sont essentiels à la disponibilité de vos services.

connaître l'utilisation de vos ressources, une fois le déploiement effectué, il est bon d'observer la consommation de ressources de votre charge de travail.

vous pouvez accéder à vos métriques via l'interface utilisateur de rancher ou via un client comme Lens.

Qualité du service

Dans Kubernetes il y a 3 classes de QoS :

• Garantie

• Burstable

• BestEffort

Pour les charges de travail critiques, vous pouvez utiliser la QOS "garantie", qui définit simplement les limites de ressources égales aux demandes de ressources :

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
  replicas: 3
  template:
    spec:
      resources:
        limits:
          memory: "200Mi"
          cpu: "700m"
        requests:
          memory: "200Mi"
          cpu: "700m"

Pour les charges de travail moins critiques, vous pouvez utiliser le QOS "Burstable", qui définira les limites de ressources et les demandes.

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
  replicas: 2
  template:
    spec:
      resources:
        requests:
          memory: "200Mi"
          cpu: "700m"

Budget pour la perturbation des pods

Le budget de perturbation des pods vous permettra de configurer votre tolérance aux pannes et le nombre de pannes que votre application peut supporter avant d'être indisponible.

Stateless

Avec une charge de travail sans état, l'objectif est d'avoir un nombre minimum de pods disponibles à tout moment, pour ce faire vous pouvez définir un simple budget de perturbation des pods :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Stateful

Avec une charge de travail à état, le but est d'avoir un nombre maximum de pods indisponibles à tout moment, afin de maintenir le quorum par exemple :

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: myapp

Horizontal Pod Autoscaler

Scénarios de trafic élevé :