Cas client : Cloud Azure

Fonctionnement du Cloud Azure et spécificités client

Cette semaine, dans le cadre d’une mission pour un client dont l’hébergeur est le cloud Azure de Microsoft, j’ai rencontré un problème technique, mettant en lumière les difficultés que l’on peut rencontrer avec un service managé.

Pour ce client, nous avons plusieurs clusters AKS (Azure Kubernetes Service), correspondants aux différents environnements, nécessaires au processus de déploiement.

AKS est un service complètement managé par Azure.

Les composants master (Control plane) sont donc gérés par Azure, qui met à notre disposition les nodes qui exécutent les pods.

Parfois, nous avons besoin d’interagir avec le control plane et nous pouvons le faire de différentes manières :

• En cliquant dans le portail Azure
• En utilisant l’interface de commande Azure CLI
• En utilisant le provider Terraform pour Azure (Resource Manager)

Le projet de notre client, reposant essentiellement sur l’infrastructure as code qui déclare l’infrastructure souhaitée, nous utilisons Terraform.

La flexibilité du cloud présente l’avantage de pouvoir mettre à l’échelle les éléments d’infrastructure sans se soucier, entre autres, des serveurs physiques ou de l’installation du système d’exploitation.

Il nous suffit de « demander » d’ajouter ou de supprimer des ressources, en l’occurrence des nodes AKS, pour les voir apparaître.

Sauf quand ça ne fonctionne plus…

Explication

Les cluster AKS utilisent des pools de nœuds, regroupant les machines virtuelles composant le cluster.

Chez Azure, ces pools de nœuds peuvent être de type Availability Sets (valeur par défaut lorsque nous avons créé les clusters), ou de type Scale Sets (valeur par défaut aujourd’hui).

Azure semble désormais promouvoir le Scale Sets au détriment de l’Availability Sets.

Et voilà comment on obtient une erreur, nous informant que l’API ne supporte plus que les appels API provenant d’un AgentPool VM Scale Sets, du moins lorsqu’on utilise terraform.

Après plusieurs allers-retours avec le support, il se trouve que le fait d’avoir donné un nom autre que « default » au node pool, il y a 2 ans, soit la cause du problème aujourd’hui.

Malheureusement, renommer le node pool implique de détruire le cluster aks et de le recréer, ce qui est assez gênant pour un cluster de production.

La première solution, fournie par le support, est d’utiliser autre chose que terraform (portail Azure ou Azure CLI).

C’est une fausse bonne solution car tout le projet est construit autour de l’infrastructure as code et l’automatisation du déploiement des ressources.

Dans ce contexte, une intervention manuelle dans le portail n’est pas satisfaisante, tout comme la réécriture de notre code de déploiement, en utilisant Azure CLI.

La seconde est de migrer sur un node pool Scale Set, ce qui implique encore une fois de recréer le cluster.

Cette fausse solution est celle que nous avons retenue par obligation ; mais elle implique de nombreuses heures de travail pour préparer et réaliser cette migration, avec à la clé d’éventuels coupure de service

Le cloud apporte des avantages, notamment la flexibilité, mais il n’est pas exempt de défaut, nous en avons ici un exemple concret.