Bonjour à tous, Faisant suite à notre dernier post à propos de l’exposition des applications sur Kubernetes, ce nouvel article...
22 octobre 2024
Cilium Cluster Mesh dans AKS
Dans un précédent article, nous avons commencé à explorer les capacités proposées par le Container Network Interface (CNI) Cilium, dans un environnement AKS.
Aujourd’hui, nous allons nous attacher particulièrement à la fonctionnalité de cluster mesh.
Au programme de cet article :
- Concepts de cluster mesh
- Préparer le lab
- Tester cluster mesh sur Azure
Concepts de cluster mesh
Le principe derrière un cluster mesh est de connecter plusieurs clusters ensemble, de façon à obtenir une vue globale des workloads hébergés sur nos clusters en mesh.
On notera que par défaut, il y a déjà un niveau de connectivité entre les clusters AKS dans Azure, au niveau du réseau Azure, spécifiquement si nous avons une approche Hub & Spoke.
Toutefois, ici, nous voulons obtenir une vue non plus uniquement au niveau du plan de contrôle Azure, mais directement dans le plan de contrôle Kubernetes. Et donc un mesh de cluster AKS avec Cilium.
En lecture de référence, il faut mentionner l’excellent article sur le blog Cilium qui explicite la technologie sous-jacente.
En exemples d’utilisation, nous pouvons mentionner :
- Haute disponibilité multicluster (et donc potentiellement multirégion) ;
- Services partagés globaux ;
- Séparation des services ;
Pour cela, on utilisera notamment les fonctionnalités du cluster mesh ci-dessous :
- Routage des IP des pods à travers les clusters en mesh ;
- Découverte transparente de services ;
- Network policies sur plusieurs clusters ;
- Chiffrement, également sur plusieurs clusters.
Maintenant, pour pouvoir évaluer ces fonctionnalités, nous avons besoin a minima de :
- Connectivité entre les nodes des clusters en mesh ;
- Garantir l’absence de recouvrement des IPs des pods entre les clusters.
Ce dernier point implique que la planification d’adressage des clusters inclut, en plus des adresses dans Azure, un espace d’adressage suffisant pour permettre la communication des pods « inter-cluster ».
D’autre part, considérant Cilium, il est également important de prendre connaissance des options disponibles pour le routage. Cela s’avèrera important pour permettre la communication des pods entre les clusters.
Le mode par défaut est l’encapsulation. La documentation Cilium indique que tous les clusters forment un mesh en tunnel utilisant une encapsulation UDP. Dans ce cas, il est nécessaire de tenir compte des flux suivants sur les différents éléments de filtrage :
| Mode d’encapsulation | Ports / Protocole |
| VXLAN (Default) | 8472/UDP |
| Geneve | 6081/UDP |
Le principal avantage de cette configuration est sa simplicité. Sa principale limitation est l’impact sur le MTU.
Bien qu’il soit relativement aisé de corriger cet impact dans un réseau classique, cela devient un peu plus complexe sur le réseau Azure, du fait de son aspect managé.
Sur Azure, la valeur du MTU est de 1500, et les modifications sont faites au niveau de la carte réseau. Dans le cadre AKS, cela impliquerait qu’il faut réaliser ces modifications au niveau des scale sets, à la création du cluster et/ou des node pools.
Une autre option de routage est le routage natif. Dans cette configuration, le réseau des nodes et le réseau des pods sont routés, ce qui est équivalent à ne pas avoir d’overlay, et rappellera peut être à certains la configuration Azure CNI par défaut.
Enfin, d’autres configurations, plus spécifiques à des plateformes Cloud en particulier, sont listées dans la documentation.
Pour finir, on notera que la chart Helm inclut un paramètre « routingMode » dont la valeur par défaut est « tunnel ». C’est la valeur que nous garderons pour nos tests.
Préparation du lab
Nous utiliserons un environnement Hub & Spoke avec Virtual WAN pour notre test. Pour le moment, nous n’inclurons pas de Firewall, mais cela pourra être ajouté plus tard.
Nous aurons donc besoin des ressources suivantes pour réaliser notre lab :
| Nom | Description |
| azurerm_virtual_network | Virtual network for AKS clusters |
| azurerm_subnet | Subnets for AKS clusters |
| azurerm_kubernetes_cluster | AKS clusters to be meshed |
| azurerm_virtual_hub_connection | Network connection on a virtual hub to |
| azurerm_virtual_hub | A virtual hub to allow connectivity between spokes |
| azurerm_virtual_wan | A virtual WAN containing the virtual hub |
Une fois nos clusters AKS disponibles, nous aurons besoin d’installer Cilium, puisque nous utilisons ici l’approche byocni.
Nous devrons également désactiver kube-proxy.
La gestion de kube-proxy dans AKS est mentionnée sur une page de la documentation. Il est possible d’utiliser une commande az aks update, à l’aide d’un fichier de configuration json.
az aks update --resource-group <resourceGroup> --name <clusterName> --kube-proxy-config kube-proxy.json
Le fichier kube-proxy.json, dans notre cas, spécifie uniquement de désactiver kube-proxy et ressemble donc à ceci :
Enfin, les arguments suivants doivent être spécifiés dans la chart helm :
Les quatre premiers arguments sont les paramètres basiques de configuration de Cilium.
Ceux dont nous avons besoin pour la configuration du cluster mesh sont les arguments 8 à 11. Entre les deux, les arguments 5 à 7 sont relatifs au remplacement de kube-proxy.
L’argument « ipam.operator.clusterPoolIPv4PodCIDRList » nous permet de changer la valeur par défaut du cidr des pods.
Les arguments « cluster.name » et « cluster.id » sont tous les deux requis pour la partie configuration mesh.
L’argument « azure.resourceGroup » spécifie le groupe de ressource du cluster AKS.
Lorsque Cilium est installé sur chaque cluster, nous pouvons vérifier l’état de Cilium avec la commande « cilium status ».
Comme indiqué dans la documentation de configuration du cluster mesh, il est nécessaire de propager le certificat à travers l’ensemble des clusters.
Il faut pour cela supprimer le secret sur tous les clusters sauf un :
Et ensuite propager le secret restant :
L’étape suivante est l’activation du mesh :
En regardant sur le cluster, l’on trouvera un service pour le cluster mesh, comme attendu après la commande précédente :
Si l’on regarde dans le groupe de ressources du cluster AKS en question, nous pouvons voir un internal load balancer, dont l’IP correspond à celle du service « clustermesh-api-server ».
Avec les commandes « cilium status » et « cilium clustermesh status », nous devrions avoir un output ressemblant à ceci :
À présent, il ne nous reste plus qu’à connecter les clusters ensemble, avec la commande « cilium clustermesh connect ». Il faut également spécifier le cluster cible du mesh avec l’argument « –destination-context ».
Après répétition sur les autres clusters, nous obtenons un mesh de 3 clusters. Nous pouvons à présent tester quelques-unes des fonctionnalités du cluster mesh.
Tester cluster mesh
La première chose à tester est la découverte de service sur le cluster mesh. Pour cela, nous allons créer quelques applications.
Afin de ne pas faire exactement ce qui est proposé dans les tutoriels Cilium, nous allons créer un déploiement sur chaque cluster avec une application de démonstration AKS :
Pour chaque cluster, nous changerons la valeur de la variable d’environnement TITLE.
Ensuite, nous exposons les applications avec un service. Pour rendre ce service global, nous utilisons l’annotation « service.cilium.io/global » et spécifions la valeur « true ».
Avec l’accès au contexte de nos trois clusters, nous pouvons déployer nos ressources en spécifiant l’argument « –context ».
Enfin, pour rendre nos tests plus visuels, plutôt que de nous contenter de curl, nous allons utiliser un client à base d’un conteneur Firefox :
Nous pouvons déployer cette application sur chaque cluster et faire ensuite quelques tests.
On notera qu’il peut parfois y avoir un certain temps avant que la connexion ne soit rafraichie.
L’approche via curl nous donne l’output ci-dessous :
En nous connectant à hubble, nous pouvons voir le diagramme ci-dessous :
Avec notre service global, nous pouvons regarder un peu nos annotations.
Si « service.cilium.io/shared » est configuré sur « true », le service global est partagé, et de fait accessible depuis tous les clusters du mesh. En revanche, s’il est configuré sur « false », le service est uniquement accessible localement.
Une autre annotation disponible est « service.cilium.io/affinity » qui, comme on peut le supposer, gère l’affinité d’un service global. L’affinité peut être configurée avec les valeurs « local|remote|none ».
Pour illustrer ceci, configurons :
- Sur le cluster1, l’annotation « service.cilium.io/shared » à « false ».
- Sur le cluster2, l’annotation « service.cilium.io/affinity » à « remote ».
Puisque le service sur le cluster 1 n’est plus partagé, nous devrions obtenir des réponses en majorité depuis le cluster 3.
L’essentiel à retenir
Dans cet article, nous avons exploré la mise en œuvre de Cilium cluster mesh sur des clusters AKS en mode hub & spoke dans un environnement VWAN.
Nous avons identifié les prérequis, mis en œuvre un service partagé, et joué un peu sur les affinités.
Il y a bien sûr d’autre choses à tester, comme l’usage de network policies sur un contexte cluster mesh, ou encore la gestion du chiffrement, qui feront l’objet d’une prochaine publication.
Vous souhaitez en savoir plus sur le sujet ? Être accompagné dans vos projets de transformation numérique ? Contactez-nous !
