Hello,
Aujourd’hui je vous propose un moyen de réduire la latence réseau entre les nodes de votre cluster Azure Kubernetes Services avec les proximity placement groups !
Concept
Un proximity placement group (abrégé en PPG par la suite) est un regroupement logique permettant de garantir la proximité physique de machines virtuelles les unes par rapport aux autres. Grâce à ce mécanisme elles seront positionnées au sein d’un même datacenter avec une distance physique limitée. Cette fonctionnalité est utile si vous avez besoin d’une latence réseau la plus faible possible dans les échanges entre les nodes de votre cluster.
Attention, quelques règles à respecter :
-
- Pour un même nodepool il n’est, en toute logique, pas possible de combiner l’utilisation d’un proximity placement group avec les availability zones.
- Le pool de nœud doit être créé en configurant l’utilisation de Virtual Machine Scale Sets.
- L’utilisation du PPG n’est configurable qu’à la création du nodepool. Il n’est pas paramétrable pour un pool existant.
Mise en oeuvre
Creation du ressource group
az group create --name rg-aks --location francecentral
Creation du proximity placement group
az ppg create --name ppgAks --resource-group rg-aks --location francecentral
En sortie de cette commande vous trouverez l’id du PPG tout juste créé. Vous devrez le renseigner dans la commande suivante.
Création du cluster en utilisant le ppg pour le nodepool système
az aks create --resource-group rg-aks --name clusterAks --ppg ppgAksId
Et mes zones de disponibilités alors ?
La haute disponibilité restant fondamentale je conseille tout de même d’intégrer la notion d’Availability Zones même pour un cluster nécessitant les PPG.
Pour cela l’organisation suivante est préconisée par Microsoft :
- Créez un cluster avec le nodepool principal (system) configuré pour utiliser les zones de disponibilité (sans PPG donc). Ainsi les pods Kubernetes seront déployés dans un pool de nœuds dédié qui s’étendra sur plusieurs zones. Mon cluster sera ainsi résiliant à la défaillance d’un datacenter.
- Ajoutez ensuite des pools de nœuds “user” supplémentaires positionnés sur une zone unique avec un ppg associé à chaque pool. Vous aurez alors :
- nodepool1 dans l’AZ 1 avec PPG1
- nodepool2 dans l’AZ 2 avec PPG2
- nodepool3 dans l’AZ3 avec PPG3.
On s’assure ainsi qu’au niveau d’un cluster, les nœuds sont répartis entre plusieurs zones de disponibilité. Toutefois chaque pool de nœuds individuels est localisé dans une zone avec un proximity placement group dédié pour l’optimisation réseau.
Il faudra ensuite jouer sur les taints and tolerations pour garantir qu’un même type de pods peut être déployé sur les différents nodepools et donc les différents AZ. Cette gestion sera indispensable pour conserver une haute disponibilité au niveau des pods “applicatifs”.
Démonstration
Creation du ressource group
az group create --name rg-aks --location francecentral
Creation du cluster avec zones de disponibilité pour le nodepool system
az aks create --resource-group rg-aks --name clusterAks --zones 1 2 3 --nodepool-name npsystem
Creation des proximity placement group
az ppg create --name ppgZone1 --resource-group rg-aks --location francecentral
az ppg create --name ppgZone2 --resource-group rg-aks --location francecentral
Ajout d’un nodepool sur une zone unique avec un ppg
az aks nodepool add --resource-group rg-aks --cluster-name clusterAks --name nodepool1 --node-count 2 --ppg myPPGResourceID1 --zones 1
az aks nodepool add --resource-group rg-aks --cluster-name clusterAks --name nodepool2 --node-count 2 --ppg myPPGResourceID2 --zones 2
Executez maintenant :
az aks get-credentials --resource-group rg-aks --name clusterAks
Pour vous connecter à votre cluster et la commande suivante pour détailler vos nodes disponibles :
kubectl describe nodes | select-string -pattern '^Name:','zone='
Vous constatez ici la présence du premier nodepool sur la zone francecentral-1 et le second nodepool sur francecentral-2. Quant au nodepool system (npsystem) il est constitué de 3 nodes répartis sur les 3 Availability Zones disponibles. Nous respectons donc ici les recommandations de Microsoft au sujet des proximity placement group !
A bientôt,
Thomas