La résilience applicative avec AKS

Aujourd’hui nous parlons résilience de notre cluster AKS et SLA !

On désigne par résilience la capacité d’un service à continuer de fonctionner malgré la défaillance d’un ou plusieurs éléments d’infrastructure (base de données, serveurs Web, accès réseau, … ). La résilience désigne également la capacité du service à revenir dans un mode nominal de façon automatisée.

Voyons comment ça se matérialise avec AKS !

Azure Container Service 1024x532 - La résilience applicative avec AKS

Les régions et zones Azure

Avant de parler de régions, il faut introduire les zone géographiques. Une zone géographique correspond à une offre de déploiement de composants Azure. Par exemple France. Une zone géographique contient au minimum deux régions, qui peuvent être géorépliqué (le pairage des régions étant définis par Microsoft).

Par exemple la zone géographique France est composée de France Centre et France Sud. Celles-ci permettent de répondre à des exigences clients concernant le déploiement et le stockage des informations.

Une région est un emplacement physique de datacenter Azure. Par exemple la région France Centre est constitué de 3 datacenters situés en région parisienne.

Les zones de disponibilité sont des emplacements physiquement séparés au sein d’une région Azure comme France Centre (minimum 3). Chaque zone de disponibilité est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un refroidissement et d’un réseau indépendants.

az graphic two - La résilience applicative avec AKS

AKS et zones de disponibilité

Voyons l’application des zones de disponibilités sur AKS ! Si vous avez bien suivis, vous comprenez maintenant que les clusters AKS déployés à l’aide de zones de disponibilité peuvent répartir les nœuds sur plusieurs zones au sein d’une même région ! Par exemple, un cluster dans la région  France Centre  peut créer des nœuds dans les trois zones de disponibilité de France Centre. Il y aura des noeuds sur chaque datacenter composant la région. 

Grace à cela votre cluster AKS est capable de tolérer une défaillance dans l’une de ces zones ; si un des datacenter de la région est indisponible la continuité de service est assuré. A contrario, si tout les nœuds de notre cluster était déployé au même endroit, le service serait indisponible.

aks availability zones - La résilience applicative avec AKS

SLA des Nodes AKS

Le SLA d’un node de notre cluster correspond au SLA de la VM utilisée par ce node.

Le SLA “standard” est à 99.9%. Si nous utilisons un availability set : 99.95% soit environ 4h d’indisponibilité par an.

Grace à l’availability zone, on monte à 99.99% soit moins d’une heure d’indisponibilité par an.

Limitations et disponibilité de la région

Nous pouvons actuellement créer des clusters AKS en utilisant des zones de disponibilité dans les régions suivantes :

  • USA Centre, Est, Est 2
  • USA Ouest 2
  • France Centre
  • Japon Est
  • Europe Nord
  • Asie Sud-Est
  • Sud du Royaume-Uni
  • Europe Ouest

Attention, quelques informations préalable !

  • Les zones de disponibilité se gèrent à la création du cluster. Ces paramètres ne sont pas modifiables ultérieurement.
  • Les clusters avec des zones de disponibilité activées nécessitent l’utilisation du loadbalancer SKU Standard Azure pour la distribution entre les zones.
  • Incompatible avec les pods statefulset avec un volume persistent !

Mise en oeuvre

Le paramètre permettant d’utiliser les zones de disponibilité est zones :

az aks create --resource-group aksAvailabilityZone --name aks --generate-ssh-keys --vm-set-type VirtualMachineScaleSets --load-balancer-sku standard --node-count 3 --zones 1 2 3

Je me connecte à mon cluster nouvellement créé :

az aks get-credentials --resource-group aksAvailabilityZone --name aks

Pour obtenir la description des nodes :

kubectl describe nodes | select-string -pattern '^Name:','zone='

1 1 - La résilience applicative avec AKS

J’ai bien un node de déployé dans chaque zone de la région France Centre.

Réalisons une montée en charge pour analyser la répartition des nodes :

az aks scale --resource-group aksAvailabilityZone --name myAKSCluster --node-count 5

kubectl describe nodes | select-string -pattern '^Name:','zone='

2 - La résilience applicative avec AKS

J’ai donc deux nodes sur France Centre 1 et 2, et un node sur France Centre 3. Je déploie un nginx :

kubectl run nginx --image=nginx --replicas=3

Et je demande un descriptif de mes pods.

kubectl describe pod | select-string -pattern '^Name:','^Node:'

3 - La résilience applicative avec AKS

J’ai donc un pod en zone 1 et 3.

Pour aller plus loin : le déploiement multi-région

Pour se prémunir de l’indisponibilité d’une région entière comme France Centre, on peux imaginer déployez deux clusters AKS sur deux régions différentes.

A ce moment la, on peut utiliser Traffic Manager pour contrôler la façon dont le trafic est dirigé vers les clusters dans différentes régions. On peux router le traffic suivant divers paramètres :

Azure Traffic Manager For Blog 370x193 - La résilience applicative avec AKS
  • Le temps de réponse des clusters
  • En fonction de critères géographiques (pour connecter un utilisateur à sa région la plus proche par exemple).
  • Si cette région rencontre un problème, Traffic Manager peux diriger l’utilisateur vers une autre région.
aks azure traffic manager - La résilience applicative avec AKS

Nous pouvons utiliser cette approche conjointement avec la Réplication des registry afin d’accélérer les déploiements.

A bientôt !

Thomas

2 réponses sur “La résilience applicative avec AKS”

  1. Bonjour Thomas,

    Merci pour cet article très clair et pour ce blog en général.
    Je m’intéresse à AKS depuis peu, et j’ai moi aussi réfléchi à la problématique de résilience (à mon niveau).

    Je n’avais pas connaissance de la possibilité d’utiliser les availability zones…
    Pensez-vous que l’incompatibilité actuelle entre zones de disponibilité et pods statefulset puissent disparaître à terme ?

    En terme de résilience, j’ai une petite préférence pour l’usage de 2 clusters sur 2 régions différentes, même si le Traffic Manager représente une ressource supplémentaire à configurer, et un intermédiaire supplémentaire dans l’acheminement du trafic…

    Au delà du risque d’indisponibilité d’une régions Azure (plutôt rare au vu des 99.9% promis), j’y voit une autre gârantie :
    Je pense que ça peut sécuriser les opération “de maintenance” au sein du cluster. On peut appliquer une opérations sur un cluster avant l’autre, et aiguiller le trafic sur l’autre si ça se passe mal.
    En particulier, je pense aux opérations de mises à jour: version K8s, mise à jour d’OS hôte (suite reboot ou scaling). La fonctionnement des applications dans le clusters pourrait être impactée par ces mise à jour…

    1. Hello Geoffrey,

      Merci pour ton commentaire 🙂
      Concernant l’incompatibilité entre zones de disponibilité et pods statefulset c’est une très bonne question, à laquelle je ne sais pas répondre … Mais la limitation vient de k8s en lui même et de sa gestion des persistentVolume !
      C’est sur que la gestion de deux clusters sur deux régions est plus contraignante (et coûteuse) car elle implique de gérer un TrafficManager, mais en contrepartie comme tu le dit, cela sécurise complètement les opérations sur l’un des clusters, notamment pour tout ce qui touche au master.

      Thomas

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.