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 !

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.

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.

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='

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='

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

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 :

• 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.

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

A bientôt !

Thomas