L'article décrit comment modifier la taille du bloc d'adresses IP alloué à chaque nœud (PodCIDR) dans un cluster Kubernetes utilisant Cilium en mode cluster-pool pour la gestion des adresses IP. L'objectif est d'augmenter la capacité de planification de nouveaux pods sur des nœuds performants qui atteignent rapidement la limite de 254 adresses par défaut (/24).
La procédure implique la modification de la configuration de Cilium pour définir un masque de sous-réseau plus large (par exemple, /22) via les valeurs Helm, puis une réallocation manuelle du PodCIDR pour chaque nœud. Cela se fait en supprimant l'entrée actuelle du CIDR du nœud dans l'objet CiliumNode, ce qui déclenche l'opérateur Cilium pour en attribuer un nouveau selon la nouvelle configuration.
Le processus de rollout s'effectue nœud par nœud, en s'assurant que le cluster reste opérationnel. Il faut drainer le nœud, patcher l'objet CiliumNode pour forcer la réallocation, supprimer le pod Cilium et les pods résiduels utilisant l'ancien bloc d'adresses, puis désactiver le draining du nœud. Un script est fourni pour automatiser cette opération sur chaque nœud.
L’auteur partage son expérience pour déployer un cluster Kubernetes managé (MKS) avec Cilium sur OVH Cloud, en comparant les approches CLI et interface web. Il explique que la version gratuite utilise Calico par défaut, tandis que Cilium n’est disponible qu’avec le plan standard payant, nécessitant aussi une gateway. L’interface graphique simplifie la création du réseau privé et du cluster, contrairement à la CLI qui s’avère complexe pour cette configuration.
Le tutoriel détaille ensuite les étapes techniques : configuration de l’authentification via la CLI OVH, récupération du Kubeconfig, et création d’un cluster avec un nodepool de deux nœuds. L’auteur souligne l’importance de bien préparer l’environnement (région compatible, réseau privé, gateway) avant de procéder à l’installation, et recommande des outils comme Terraform pour des déploiements plus sérieux.
Enfin, il explore les fonctionnalités de Cilium, comme l’observation du réseau, la gestion des Pods et des CRD, ainsi que la configuration avancée via CiliumNodeConfig, incluant l’activation de WireGuard pour le chiffrement. L’article sert de guide pratique pour intégrer Cilium dans un cluster OVH, avec des conseils concrets pour surmonter les défis techniques.
Ce billet explique une limitation rencontrée avec la nouvelle fonctionnalité de Cilium 1.18, qui permet d’ajouter un champ log aux CiliumNetworkPolicies pour marquer les flux avec des étiquettes personnalisées et ainsi filtrer le trafic bloqué attendu dans les tableaux de bord de monitoring.
L’équipe souhaitait bloquer explicitement le trafic de télémétrie d’une application tierce vers des domaines externes, sans déclencher d’alertes inutiles dans Hubble. La solution idéale aurait été d’utiliser egressDeny combiné à toFQDNs et un champ log personnalisé pour exclure ces flux du monitoring. Cependant, ils ont découvert que Cilium ne supporte pas toFQDNs dans les règles egressDeny, ce qui rend impossible le blocage ciblé par nom de domaine dans ce contexte. De plus, un bug empêche actuellement l’affichage du champ policy_log pour les flux bloqués ou audités, limitant encore l’utilité de cette fonctionnalité.
Les solutions de contournement proposées incluent le blocage au niveau DNS, le blocage par IP (avec la maintenance que cela implique), ou la désactivation directe de la télémétrie dans l’application. L’auteur espère que ces limitations seront corrigées dans de futures versions de Cilium.
La KubeCon 2025 a souligné l'importance de la sécurité dans Kubernetes avec des solutions innovantes :
- Policy as Code : Automatisation de la conformité.
- Sécurité Réseau : Avancées avec Cilium et Hubble.
- Kyverno : Évolutions pour une gestion des politiques améliorée.
Ces innovations visent à sécuriser et rendre conformes les clusters Kubernetes.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre