Aujourd’hui, nous allons nous pencher sur Azure Kubernetes Services et Cilium.

À moins d’avoir vécu dans une grotte ces derniers temps, vous avez probablement entendu parler de Cilium et des nombreux avantages qu’il apporte en tant que Container Network Interface (CNI), entre autres, grâce à l’usage de eBPF.

Cet article se veut une introduction sur le sujet, dans un cadre Azure. Il y aura très probablement d’autres articles autour de Cilium, puisqu’il serait impossible de tout regarder en une seule fois.

Au sommaire :

• (Re-)introduction à Cilium
• Une histoire d’amour naissante entre AKS et Cilium
• Déployer AKS avec Cilium comme CNI
• Tour d’horizon de quelques fonctionnalités de Cilium

 

(Re-)Introduction à Cilium

 

Comme nous l’avons mentionné en introduction, Cilium est avant tout un CNI (Container Network Interface).

Avec l’augmentation de l’adoption des conteneurs et de Kubernetes, des standards ont dû être définis, tels que l’Open Container Initiative (OCI), qui, comme son nom l’indique, définit un standard dans la description des containers, ou encore la Container Storage Initiative (CSI), qui, comme pour l’OCI, définit un standard vis-à-vis des interfaces de stockages pour les conteneurs.

Ce qui nous amène au CNI, qui s’intéresse aux considérations réseaux dans des environnements Kubernetes.

Sur la page GitHub qui lui est dédiée, on peut lire les objectifs de l’initiative :

• Définir un format pour les administrateurs pour décrire la configuration réseau ;
• Définir un protocole pour les container runtimes pour créer et gérer les requêtes au plugin réseau ;
• Définir une procédure pour exécuter les plugins basés sur une configuration donnée ;
• Définir une procédure pour le plugin pour déléguer les fonctionnalités à d’autres plugins ;
• Définir des types de données pour les plugins pour renvoyer leurs résultats aux container runtimes.

Nous n’irons pas plus loin, puisque l’idée ici n’est pas d’aller en profondeur dans les spécifications du CNI. Nous noterons juste quelques CNI plugins bien connus :

• Azure
• Calico
• Et évidemment Cilium

 

Ces bases étant posées, parlons un peu de Cilium.

 

Son principal intérêt réside dans la nouvelle approche qu’il propose. En effet, il s’appuie sur eBPF (pour Extended Berkley Packet Filter).

C’est bien eBPF qui apporte un nouveau paradigme dans les plugins réseaux. En effet, il permet d’exécuter des programmes en mode sandbox à l’intérieur de l’OS. Avec un Just-In-Time compiler et un vérification engine, l’OS est ainsi capable de garantir une exécution sécurisée de ces programmes, comme s’ils étaient compilés nativement dans le noyau.

eBPF est utilisé pour de nombreux cas d’usage, incluant le réseau, l’observabilité, et la sécurité, c’est-à-dire à peu près tout le spectre des fonctionnalités de Cilium.

 

 

Avec ces informations sur Cilium, regardons maintenant comment nous pouvons avoir celui-ci comme CNI pour AKS.

 

Une histoire d’amour naissante entre AKS et Cilium

 

Dans notre précédent article à propos des considérations réseaux pour AKS, nous avons parlé de nos choix initiaux, à savoir kubenet et Azure CNI.

Tandis qu’Azure CNI est le choix recommandé par Microsoft pour les environnements de production, il implique des difficultés pour la gestion du pool d’adresses IP dans les ranges de la RFC 1918 entre autres. Concernant kubenet, l’un des principaux problèmes est la latence induite par le NAT built-in de l’overlay réseau.

 

Pour résoudre ces problèmes, l’équipe produit AKS a beaucoup travaillé, et nous a proposé deux nouvelles options :

• Azure CNI powered by Cilium
• Bring your own CNI

 

La première option, comme son nom l’indique, nous propose un Azure CNI (avec overlay) et (hypothétiquement) la puissance de Cilium. Malheureusement, dans son état actuel, cette option ne nous apporte pas encore l’ensemble des fonctionnalités de Cilium, comme on peut le lire dans la documentation Azure.

La seconde option n’est pas spécifiquement dédiée à Cilium, mais puisqu’elle nous offre la possibilité de choisir n’importe quel CNI, Cilium devient un choix possible. Il est cependant nécessaire de l’installer, et la responsabilité de son MCO incombe alors à l’équipe qui l’a déployé. Dans la suite de cet article, nous allons surtout nous attarder sur cette option.

Enfin, parce qu’il y a toujours une dernière option, nous devons mentionner Cilium Enterprise par Isovalent. Un post sur le blog d’Isovalent documente cette possibilité. À travers la version Enterprise, il est possible de bénéficier de toutes les fonctionnalités de Cilium et d’un support, payant bien entendu.

 

Le tableau ci-dessous illustre l’intérêt de Cilium, version communautaire ou Enterprise, par rapport à Azure CNI powered by Cilium :

 

Features	Azure CNI Powered by Cilium	Cilium Open Source	Isovalent Enterprise for Cilium
Container Networking (CNI)	✅	✅	✅
Kubernetes Network Policy & Services	✅	✅	✅
Collaborative Support Agreement	✅	✅	✅
Advanced Network Policy & Encryption (DNS, L7, TLS/SNI, …)	❌	✅	✅
Ingress, Gateway API, & Service Mesh	❌	✅	✅
Multi-Cluster, Egress Gateway, BGP, Non-Kubernetes Workloads	❌	✅	✅
Hubble Network Observability (Metrics, Logs, Prometheus, Grafana, OpenTelemetry)	❌	✅	✅
SIEM Integration & Timescape Observability Storage	❌	❌	✅
Tetragon Runtime Security	❌	✅	✅
Enterprise-hardened Cilium Distribution, Training, 24×7 Enterprise Grade Support	❌	❌	✅

 

Davantage de détails sont disponibles sur le comparatif des versions Cilium sur le site d’Isovalent.

Il existe donc plusieurs options pour Cilium, comme on pouvait s’y attendre. Intéressons-nous à présent au déploiement.

 

Déployer AKS avec Cilium comme CNI

 

Comme vu dans la section précédente, nous pouvons avoir une version de Cilium, soit avec Azure CNI powered by Cilium, soit avec l’option Bring Your Own CNI.

AKS byo cni parameters	AKS Azure CNI powered by cilium parameters
–network-plugin none	–network-plugin azure –network-plugin-mode overlay –network-dataplane cilium

 

 

Azure CNI Powered by Cilium

 

Créer un cluster avec Azure CNI Powered By Cilium avec Azure CLI peut se faire avec la commande ci-dessous :

 

Une fois le cluster déployé, il est possible de regarder le statut de Cilium. Il est nécessaire d’avoir kubectl configuré sur le cluster, ainsi que le CLI Cilium, qui peut être obtenu ici.

 

On notera le statut désactivé de hubble, ce qui correspond à ce que l’on pourrait attendre d’après la documentation Azure. Si l’on essaye de l’activer avec le CLI cilium, malheureusement, cela ne fonctionne pas.

 

Bring your own CNI

 

Dans le cas d’un cluster créé avec l’option Bring Your Own CNI, les nodes du cluster sont dans un état NotReady.

 

Il nous faut installer Cilium avec les paramètres suivants :

 

Il y a d’autres options disponibles, mais pour le moment celles-ci suffiront.

Une fois Cilium installé, la commande cilium status affiche ceci :

 

Cette fois-ci, nous avons bien hubble activé. Regardons ce que l’on peut faire avec ce cluster à présent.

 

Tour d’horizon de quelques fonctionnalités de Cilium

 

La première chose que nous voulons regarder est justement hubble. Hubble est un outil d’observabilité du réseau dans Kubernetes et inclus avec Cilium, si nous pouvons l’activer.

 

Pour faire quelques tests, nous allons ajouter quelques ressources.

 

Une fois le déploiement prêt, et exposé par un service, on peut commencer à utiliser Hubble, avec l’interface utilisateur (UI) intégrée.

 

Cela est fait avec la commande cilium hubble ui. En arrière-plan, la commande associe l’UI à un port local de la machine, et l’on peut donc y accéder depuis un navigateur.

 

Il est possible de choisir un namespace, et d’obtenir une vue graphique des flux dans celui-ci.

 

Ainsi qu’une liste des flux :

 

Si l’on ajoute un nouveau pod, pour tester l’accès au déploiement, on peut voir le trafic rendu dans l’UI :

 

Essayons un peu avec le CLI à présent. Comme pour l’UI, il est possible d’accéder à hubble depuis un terminal avec une commande cilium.

 

Le résultat étant très verbeux, nous allons essayer de regarder comment l’affiner. Les options suivantes sont affichées par l’aide :

 

On peut utiliser ces filtres pour avoir une meilleure vue du trafic :

 

Maintenant, si l’on souhaite identifier le trafic en fonction du verdict, nous allons avoir besoin de Network policies pour faire un peu de filtrage. Cilium nous donne des options intéressantes à ce sujet, et cela constituera notre seconde fonctionnalité de Cilium pour cet article.

 

Une Network Policy native de Kubernetes pour bloquer tout le trafic entrant sur un namespace ressemble à ceci :

 

Le podSelector configuré avec la valeur {} signifie que l’on sélectionne tous les pods du namespace, et l’argument ingress avec la valeur [] signifie que nous n’autorisons aucun trafic. Plutôt que d’utiliser cette policy native, regardons plutôt une policy Cilium :

 

On remarquera que l’argument ingress est conservé, mais que la sélection des cibles est faite avec l’argument endpointSelector. Appliquons cette policy et regardons ce que hubble nous affiche.

 

On peut voir la mention Policy denied DROPPED.

Ajoutons un nouveau pod, dans un namespace client :

 

Et une policy Cilium pour permettre le trafic depuis ce pod :

 

Toujours avec Hubble, nous pouvons voir cette fois-ci le trafic autorisé :

 

A ce stade, cependant, il s’agit juste d’une policy écrite différemment. Passons au niveau supérieur et ajoutons un peu de niveau 7 dans notre policy. Commençons avec une policy interdisant le trafic sortant :

 

On peut voir le trafic vers kube-dns :

 

 

 

Essayons de rétablir l’accès vers kube-dns :

 

À présent, le trafic est bien envoyé vers kube-dns, bien que le reste du trafic sortant soit toujours bloqué.

 

 

Avec la policy suivante, nous pouvons autoriser le trafic vers un choix de fqdn :

 

Depuis le pod, google.com peut être atteint, mais pas un autre fqdn comme par exemple github.com :

 

Pour finir, jetons un dernier coup d’œil à Hubble pour confirmer ces flux :

 

Synthèse sur Cilium et AKS

 

Dans cet article, nous avons vu :

• Les concepts de base autour de Cilium et eBPF
• Cilium dans le paysage Azure

 

Ainsi que quelques fonctionnalités :

• Les capacités niveau 7 des network policies de Cilium.
• Les capacités natives d’observabilité réseau à travers Hubble.

 

Il y a bien entendu encore beaucoup à voir, notamment :

• Les capacités de cluster mesh
• L’authentification
• Le chiffrement

Ces sujets feront l’objet d’un autre article à venir. D’ici là, contactez-nous si vous souhaitez en savoir plus, être accompagné dans vos projets de transformation numérique ou nous rejoindre !