Je vous propose dans ce nouvel article un petit tour d’horizon sur Azure Arc-enabled Kubernetes.

Au programme :

1. Un aperçu de l’architecture sous-jacente à Arc-enabled Kubernetes
2. Le processus d’onboarding d’un cluster Kubernetes dans Azure Arc
3. Arc-enabled Kubernetes cluster du point de vue de l’Ops Azure

Il existe d’autres sujets très intéressants liés à Azure Arc et Kubernetes, mais nous nous contenterons de ceux-là pour cet article.

 

Aperçu de l’architecture sous-jacente à Arc-enabled Kubernetes

 

Dans cette première partie, nous allons regarder comment fonctionne l’architecture des clusters Kubernetes Arc-enabled.

Mais tout d’abord, un rapide rappel sur Azure Arc.

 

Azure Arc : qu’est-ce que c’est ?

 

Azure Arc n’est pas un unique produit, mais une famille de produits dont le but est de faciliter l’hybridation et les approches multi-Cloud.

Parmi les membres de cette famille, nous trouvons :

• Azure Arc-enabled Servers
• Azure Arc-enabled Kubernetes clusters
• Azure Arc-enabled Data Services
• Et d’autres choses encore…

 

Maintenant, intéressons-nous aux aspects Kubernetes.

 

Focus sur le cluster Kubernetes

 

Un cluster Kubernetes peut être hébergé virtuellement n’importe où. Quand ce cluster est transformé en Arc-enabled cluster, son équivalent logique le représentant dans Azure est créé.

Là où le cluster est localisé, il est toujours géré avec les mêmes outils, comme kubectl ou helm, ou encore une solution GitOps.

Cependant, puisqu’il existe à présent également comme une ressource Azure, il peut être également géré dans le plan de contrôle Azure avec des outils Azure.

 

Puisque nous avons mentionné l’architecture, comment cela fonctionne-t-il à l’intérieur de notre Arc-enabled cluster ?

En fait, très simplement, par l’intermédiaire d’un agent (l’Arc-enabled Kubernetes Agent), qui se charge de communiquer avec la plateforme Azure en poussant des informations depuis le cluster ou en en récupérant depuis la plateforme Azure.

Une fois le cluster connecté, c’est l’agent qui est responsable du maintien de l’état du cluster connecté par rapport à son état connu dans Azure.

Lorsqu’un Ops Azure change la configuration du cluster dans le plan de contrôle Azure, l’agent, de manière asynchrone, récupère l’état en se connectant à Azure et met à jour la configuration en téléchargeant des images de conteneurs sur la registry Azure.

 

Le gros avantage de cette configuration est le fait que, par design, la connexion est uniquement initiée par l’agent, depuis le cluster. Le cluster connecté n’est jamais accédé directement depuis Azure. Bien entendu, il a besoin de flux sortants pour communiquer avec la plateforme Cloud.

L’agent responsable de cette hybridation a différents états dans son cycle de vie, qui sont résumés ci-dessous :

 

Statut	Description
Connecting	La ressource Azure Arc-enabled Kubernetes a été créée dans Azure, mais le service n’a pas encore reçu d’information de l’agent.
Connected	Le service Azure Arc-enabled Kubernetes a reçu un signal (heartbeat)  de l’agent au cours des 15 minutes précédentes.
Offline	La ressource Azure Arc-enabled Kubernetes était connectée, mais le service n’a pas reçu de mise à jour de l’agent depuis 15 minutes.
Expired	Le certificat d’identité du cluster a expiré. Dans cet état, les fonctionnalités Azure Arc ne fonctionnent plus sur le cluster.

 

 

Processus d’onboarding d’un cluster Kubernetes dans Azure Arc

 

Comme vu dans la partie précédente, il n’y a finalement qu’un seul élément dans l’architecture, et cet élément est l’agent Azure Arc-enabled Cluster Agent.

Pour déployer cet agent, et initier le processus de connexion à Azure, nous avons quelques prérequis :

• Avoir kubectl installé sur la machine servant à faire la connexion
• Le fichier kube/config pointant vers le cluster à connecter
• Le rôle cluster-admin sur le cluster à connecter
• la ligne de commande az installée, avec l’extension connectedk8s, et une session authentifiée vers l’abonnement Azure ou l’on souhaite connecter le cluster Arc.
• helm
• Le trafic sortant requis autorisé pour la connexion, depuis le cluster.

 

Bien que cela ne soit pas spécifié dans la documentation Azure Arc, si le cluster à connecter est un cluster GKE ou EKS, il est également utile d’avoir les outils cli du Cloud provider associé, pour faciliter la récupération des crédentials dans le fichier config.

Par rapport aux flux sortants, la documentation nous fournit tous les fqdns requis pour la connexion et le cycle de vie du cluster :

 

https://management.azure.com (pour le Cloud Azure), https://management.usgovcloudapi.net (pour les régions Azure réservées au gouvernement américain)	Obligatoire pour que l’agent se connecte à Azure et enregistre le cluster.
https://region.dp.kubernetesconfiguration.azure.com (Azure Cloud), https://region.dp.kubernetesconfiguration.azure.us (Azure gouvernement US )	Endpoint du Data Plane pour que l’agent pousse le statut et récupère les informations de configuration. ​​
https://login.microsoftonline.com, https:// https://login.microsoftonline.us,	Obligatoire pour récupérer et mettre à jour les tokens de l’Azure Resource Manager.​​
https://mcr.microsoft.com, https://*.data.mcr.microsoft.com​	Obligatoire pour extraire les images des conteneurs pour les agents Azure Arc.
https://gbl.his.arc.azure.com (pour le Cloud Azure), https://gbl.his.arc.azure.us (pour le gouvernement américain Azure)	Obligatoire pour obtenir le endpoint régional pour récupérer les certificats d’Identité Manager attribués par le système.
https://*.his.arc.azure.com (for Azure Cloud), https://usgv.his.arc.azure.us (for Azure US Government)	Requis pour récupérer les certificats d’Identité Manager attribués par le système.
https://k8connecthelm.azureedge.net​	az connectedk8s connect utilise Helm 3 pour déployer les agents Azure Arc sur le cluster Kubernetes. Ce endpoint est requis pour le téléchargement des Helm Charts.
guestnotificationservice.azure.com, *.guestnotificationservice.azure.com, sts.windows.net, https://k8sconnectcsp.azureedge.net​	Utilisé pour les scénarios impliquant des Custom Locations
*.servicebus.windows.net​	Utilisé pour les scénarios impliquant des Custom Locations

 

 

Avant de réaliser la connexion, il est recommandé de consulter la liste des distributions Kubernetes supportées. Cette liste inclut notamment les cluster EKS et GKE.

Bien entendu, ce n’est pas parce qu’un cluster n’est pas supporté que la connexion ne fonctionne pas. Néanmoins, certaines choses pourraient « moins bien marcher ». Nous en verrons un exemple plus tard.

Commençons à présent à onboarder des clusters Kubernetes sur Arc !

A ce sujet, notons l’excellent travail des équipes Arc sur le site Azure Arc Jumpstart, qui contient même des configurations Terraform pour aider les Ops Azure à coder un cluster GKE ou EKS par exemple.

En ce qui nous concerne, nous allons tester dans la suite de cet article des clusters Azure Arc-enabled avec les versions suivantes :

• EKS
• GKE
• Microk8s

Commençons avec un cluster GKE.

 

Connexion d’un cluster GKE

 

Pour commencer, récupérons les credentials de notre cluster, à l’aide de la commande gcloud :

 

Une fois que le fichier de configuration de kubectl pointe vers le cluster, la connexion peut être initialisée :

 

Le cluster est à présent connecté. Que s’est-il passé lorsque la commande az a été complétée ?

 

Le cluster connecté observé d’un peu plus près

 

Maintenant que le cluster est connecté, il est visible dans le portail Azure :

 

 

Derrière cette commande az connectedk8s connect, il s’agit en fait du déploiement de l’agent à travers helm (d’où le besoin de helm localement sur la machine réalisée pour la connexion).

Avec la commande helm list, nous pouvons identifier les charts qui ont été déployées.

On peut voir une release azure-arc et une azurepolicy. La release azure-arc est associée default namespace, alors que les ressources déployées ne sont clairement pas dans ce namespace :

 

 

On voit dans les outputs le déploiement pour clusterconnect-agent, mais également d’autres objets intéressants comme le kube-aad-proxy, qui dépend du projet OSS Guard.

Sur ce sujet, la documentation n’est pas très extensive, mais ce n’est pas surprenant, puisque l’idée ici est de se simplifier le déploiement d’un point de vue Azure. En parcourant la documentation AKS, on peut lire toutefois que les logs associés à Guard sont associés à l’intégration AAD.

Voilà pour l’onboarding de notre cluster GKE. Regardons à présent notre cluster EKS.

 

Connexion d’un cluster EKS

 

Dans cette courte partie, nous n’allons pas détailler à nouveau l’onboarding, mais juste constater une addition inattendue dans Azure Arc, très certainement due à la nature de l’architecture EKS.

En effet, nous pouvons voir les instances EC2 du cluster sous la forme de Arc-enabled servers :

 

Voilà, passons maintenant au point de vue Ops Azure.

 

Arc Enabled Kubernetes cluster du point de vue de l’Ops Azure

 

Une fois le cluster connecté à Azurer Arc, quelles sont les possibilités de l’Ops Azure ?

Tout d’abord, les clusters sont visibles dans le portail. Nous avons donc un genre d’inventaire.

Ensuite, comme nous l’avons schématisé dans une précédente partie, il est possible d’interagir de manière asynchrone avec le cluster, depuis le portail.

Nous avons vu que l’agent déploie des charts helm pour installer l’agent.

Nous avons la possibilité d’ajouter des fonctionnalités additionnelles à travers la ligne de commande az k8s-extension create :

 

Extension	Description
Azure Monitor for containers​	Fournit une visibilité des performances des charges de travail déployées sur le cluster Kubernetes. Collecte les métriques d’utilisation de la mémoire et du processeur à partir de contrôleurs, de nœuds et de conteneurs.
Azure Policy​	Azure Policy étend Gatekeeper, un webhook de contrôleur d’admission pour Open Policy Agent (OPA), afin d’appliquer des mises en œuvre et des protections à grande échelle sur vos clusters d’une manière centralisée et cohérente.
Azure Key Vault Secrets Provider​	Le fournisseur Azure Key Vault pour le pilote CSI du magasin de secrets permet d’intégrer Azure Key Vault comme magasin de secrets à un cluster Kubernetes via un volume CSI.
Microsoft Defender for Cloud​	Collecte des informations liées à la sécurité, telles que les données du journal d’audit du cluster Kubernetes. Fournit des recommandations et des alertes de menace basées sur les données collectées.
Azure Arc-enabled Open Service Mesh​	Déploie Open Service Mesh sur le cluster, et active des fonctionnalités telles que la sécurité mTLS, le contrôle d’accès affiné, le déplacement du trafic, la surveillance avec Azure Monitor ou des modules complémentaires open source de Prometheus et Grafana, le suivi avec Jaeger, et l’intégration avec la solution de gestion de certification externe.
Flux (GitOps)​	Utilisez GitOps avec Flux pour gérer la configuration du cluster et le déploiement d’applications.
Dapr extension for Azure Kubernetes Service (AKS) and Arc-enabled Kubernetes​	Élimine la surcharge du téléchargement des outils Dapr ainsi que l’installation et la gestion manuelles du runtime sur vos clusters.

 

Le déploiement de ces fonctionnalités est toujours orchestré par des helm release sur le cluster connecté. Regardons quelques-unes de ces extensions.

 

L’extension Azure Monitor for containers

 

Pour déployer l’extension Azure Monitor, comme pour toutes les extensions d’ailleurs, nous utilisons la commande az k8s-extension create :

 

Nous avons bien une release helm, dont nous pouvons récupérer les informations depuis le cluster avec la commande helm get :

 

On peut noter que dans ce cas, tout est déployé dans le namespace kube-system, ainsi que quelques CRDs ajoutés par l’extension.

Avec cette extension, l’Ops Azure chevronné sur Azure Monitor pourra disposer de vues sur ce qui se passe sur le cluster connecté :

 

L’extension Azure Defender for Cloud

 

Un autre outil du (Sec)Ops Azure est Defender for Cloud. Comme on pourrait s’y attendre, cette extension remonte des informations dans le CSPM d’Azure.

 

Defender for Cloud, et l’hybridation du CSPM, constitue un sujet à part entière, que nous approfondirons dans un prochain article.

 

L’extension Azure Policy

 

Dernière dans les extensions que nous parcourons ici, mais non des moindres, l’extension Azure Policy.

Celle-ci permet un contrôle depuis le plan Azure dans le cluster connecté, à travers le langage Rego utilisé par OPA, et un mix de json auquel l’Ops Azure est plus familier. L’utilisation de cette extension, si elle est potentiellement puissante, impose un certain skillset de l’Ops dans le plan Kubernetes.

Pour aller un peu plus loin, nous allons à présent prendre le cluster Microk8s et regarder ce qui arrive quand l’installation de l’extension est initialisée :

 

Ici, l’erreur est tout simplement liée à la version d’un objet Kubernetes.

Dans les distributions supportées, on peut s’attendre à une roadmap connue de la version de Kubernetes, et donc par corollaire, de la version de l’API.

Dans le cas présent, parce que la version Kubernetes de Microk8s est 1.26, l’objet PodSecurityPolicy dans la version policy/v1beta1 n’existe plus, d’où l’échec.

 

Tunneling vers un cluster connecté

 

Avant de conclure cet article, mettons-nous dans un cas ou l’Ops Azure aurait besoin d’interagir directement avec le cluster.

Comme nous l’avons vu, par défaut, il n’y a pas d’ouverture de flux entrant depuis Azure vers le cluster.

Malgré tout, l’agent intègre une fonction de tunneling qui permet d’interagir avec l’API server depuis le plan Azure.

Ce point est notamment décrit dans la documentation Azure Arc. On peut y lire notamment que, pour un cluster de type GKE ou EKS, il faudra créer un service account et un token sur le cluster :

par la suite, en stockant le token dans un key vault par exemple, il devient possible de lire les objets vivants sur le cluster à travers le portail Azure :

 

On notera dans l’extrait de code le rôle cluster-admin associé au service account. A priori, il devrait être possible de se limiter à un rôle moins permissif.

 

Pour aller plus loin sur le cluster K8S et l’offre Azure Arc

 

L’offre Azure Arc évolue en permanence, et la partie Kubernetes permet à présent de donner une vue opérationnelle pour tout cluster connecté à Arc.

L’idée d’un chemin facilité vers le multi-Cloud pour les équipes opérationnelles déjà présentes sur Azure devient à présent très concrète. D’autant que les custom locations couplées à des clusters Kubernetes Arc-enabled permettent de déployer des services Azure partout.

Un point restant à approfondir est le coût induit par les logs d’un cluster Arc-enabled, puisque le coût des logs d’un cluster AKS est déjà l’un des principaux freins à la généralisation de l’usage d’Azure Monitor comme solution d’observabilité des solutions Kubernetes dans Azure.

Sur ce sujet, les récentes sorties autour des stacks Grafana et Prometheus managés vont probablement redessiner le paysage.