Cilium on Zwindler's Reflection

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 1)

Tue, 12 May 2026 12:00:00 +0200

La suite de ma saga avec Clever Cloud

Ça fait maintenant quelques années que je teste les produits de Clever Cloud sur ce blog. En 2022, j’avais testé le Clever Kubernetes Operator, qui permet de provisionner des services managés (MySQL, Redis, Pulsar…) directement depuis un cluster Kubernetes via des CRDs. En 2025, j’ai réessayé leur offre d’hébergement de sites statiques, et j’ai même poussé le délire jusqu’à déployer un control plane Kubernetes sur leurs apps Linux, pour rigoler en attendant leur offre managée.

Bref, à la fin de cet article, je concluais avec un trollface et un “j’attends mon accès au k8s managé de Clever Cloud”. Et bien… c’est maintenant !

Clever Cloud a lancé CKE (Clever Kubernetes Engine) en bêta publique. J’ai eu accès en avant-première pour tester et je leur ai fait quelques retours. Maintenant que le produit est public, j’ai enfin le droit de vous partager mes impressions.

CKE c’est quoi exactement ?

CKE est l’offre Kubernetes managée de Clever Cloud. Le positionnement est clair : Vanilla Kubernetes, pas de lock-in, le plus standard possible dans l’usage du cluster.

Ce qui distingue CKE des offres plus conventionnelles, c’est ça :

Materia etcd : leur implémentation maison de l’API etcd, construite sur FoundationDB (pas d’etcd VM à provisionner ou dimensionner, c’est serverless). C’était pas gagné, cf cet article de Pierre Zemb “Diving into Kubernetes’ Watch Cache”
Infrastructure souveraine et isolée des autres clients : tout tourne sur des VMs dédiées, en France. Rien de mutualisé entre tenants.
Cilium + eBPF natif, avec WireGuard pour le chiffrement inter-nodes.

Activation : c’est un peu caché

CKE est en bêta publique, mais l’accès n’est pas actif par défaut. Il faut l’activer, soit via la CLI :

clever features enable k8s

Note : les commandes clever k8s sont disponibles dans la CLI à partir d’une version récente de leur CLI, idéalement version 4.9+.

Soit depuis l’interface web, dans l’onglet Labs de votre compte : https://console.clever-cloud.com/users/me/feature-list

L’onglet Labs n’est pas particulièrement mis en avant dans la console (il faut savoir où chercher). Une fois le feature flag activé, un nouveau menu apparaît dans la console.

Création d’un cluster

Depuis la CLI, voici la commande minimale pour créer un cluster :

clever k8s create moncluster --watch

--watch suit le déploiement jusqu’à ce que le cluster soit ACTIVE. En pratique, ça ressemble à ça :

⏳ Cluster status: DEPLOYING. Waiting for 10s before checking again...
✓ Cluster moncluster (kubernetes_01KRDDW6YNMDE7ZT0RYD3MY0GE) deployed successfully

On peut passer tout un tas d’options : version K8s (--cluster-version 1.36), topology, flavor du control plane, replication factor, autoscaling, CSI… On y reviendra.

Mais il est aussi possible, depuis peu, de créer un cluster via formulaire de création, avec un récapitulatif en temps réel.

On y retrouve tous les paramètres : version K8s, topology, flavor, replication factor, autoscaling, persistent storage. C’est bien fait, les topologies sont expliquées inline. Le nom de cluster est généré aléatoirement (style cunning-arcane-runic-corsair, modifiable bien sûr).

Les 3 topologies : Essential, Business, Enterprise

C’est l’un des aspects les plus inhabituel de CKE. Trois topologies sont disponibles à la création (et immutables après, ce qui oblige à bien choisir dès le départ).

Topology	Offre	Ce que vous payez	Usage typique
`ALL_IN_ONE`	Essential	rf (replication factor) × VM bundle (CP + worker intégré)	Dev, test, petits clusters
`DEDICATED_COMPUTE`	Business	rf × VM CP + chaque worker VM	Prod avec isolation CP/workers
`DISTRIBUTED`	Enterprise	5 composants × rf × VM + workers	Prod HA fine par composant

ALL_IN_ONE est la topologie par défaut. Le control plane et un worker node partagent la même VM (c’est le mode k3s-style, pour reprendre la description de la console). Ça a une conséquence concrète : kubectl get nodes liste le node du control plane comme worker disponible pour les pods.

DEDICATED_COMPUTE isole le CP sur ses propres VMs, les workers sont dans des node groups séparés. Avec un replication factor de 3, les VMs sont réparties sur les 3 datacenters parisiens de Clever Cloud (un datacenter peut tomber sans impacter le control plane).

DISTRIBUTED pousse l’isolation plus loin : chaque composant du CP (apiserver, controller-manager, scheduler, cloud-controller-manager, node-group-operator) tourne sur sa propre VM, avec sa propre flavor et son propre replication factor. J’ai du mal à voir dans quel cas c’est utile, mais pourquoi pas.

Un mot sur la tarification

Contrairement à certains cloud providers (de moins en moins cela dit…) qui offrent parfois le control plane quand il est mutualisé et ne facturent que les workers, Clever Cloud facture une vraie VM dédiée par cluster (rien de mutualisé entre tenants).

En ALL_IN_ONE, cette VM fait aussi office de worker, ce qui en fait paradoxalement l’option la moins chère. La flavor S (8 vCPU / 12 GB RAM) revient à 64 €/mois, CP et workers inclus sur la même machine. L’isolation se paye davantage : DEDICATED_COMPUTE commence à 96 €/mois pour le CP seul (+ workers séparés), DISTRIBUTED à 180 €/mois minimum pour 5 composants CP en 2XS.

Ce n’est pas donné pour du dev, mais le prix s’explique par le choix architectural : vous avez vraiment 8 vCPU / 12 GB de RAM rien que pour vous, pas un dixième de VM partagée entre dix clients.

Note : pendant la bêta publique, le CSI (Ceph) et les LoadBalancers ne sont pas encore facturés. Seuls le CP et les workers le sont.

Récupérer le kubeconfig

clever k8s get-kubeconfig moncluster > ~/.kube/clever.yaml
kubectl --kubeconfig ~/.kube/clever.yaml get nodes

Un détail à noter : l’API server écoute sur un port non standard (1032 ou 1022 selon les clusters). Ce n’est pas bloquant dans la plupart des environnements, mais j’ai eu la surprise de me retrouver bloqué depuis un réseau qui filtre les ports non-standards. À garder en tête si vous devez accéder au cluster depuis un réseau d’entreprise restrictif.

Anatomie du cluster

Une fois connecté, quelques observations :

$ kubectl get nodes -o wide
NAME STATUS VERSION OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
control-plane-be4e3383-...-node Ready v1.36.0 Exherbo Linux 6.19.14-clevercloud-vm-dirty (amd64) containerd://2.3.0

Exherbo Linux : on retrouve bien la marque de fabrique de Clever Cloud. Pour celleux qui ne connaissent pas, Exherbo est une distro minimaliste et source-based, peu connue en dehors de cercles très spécialisés. Le kernel est un build custom Clever Cloud (clevercloud-vm-dirty), et le container runtime est containerd 2.3.0.

Les composants pré-installés dans kube-system :

$ kubectl get pods -A
NAMESPACE NAME READY
kube-system cilium-tv9m7 1/1 # CNI
kube-system cilium-operator-7db7f998d7-z5zq8 1/1
kube-system coredns-5986bf5c44-wkzb9 1/1
kube-system konnectivity-agent-l26kl 2/2 # proxy CP->workers
kube-system kube-state-metrics-75b86d74f6-6slx8 2/2
kube-system kubelet-csr-approver-68d5bfcb6b-kgz5c 1/1
kube-system metrics-server-559c9b85f9-wflvk 1/1
kube-system cc-collector-wwpld 1/1 # collecteur OTel Clever Cloud

Quelques absences notables par rapport à une install classique : pas de kube-proxy (remplacé par Cilium en mode eBPF kube-proxy replacement).

Pour la petite histoire, les premiers teasers de CKE avaient montré l’usage de flannel. Heureusement que les équipes de clever ont écouté la communauté et migré vers cilium.

Konnectivity : l’isolation réseau du control plane

Le pod konnectivity-agent mérite une mention. C’est un composant qu’on retrouve assez souvent sur les Kubernetes managés et certaines distribution de Kubernetes. Il tourne sur chaque node (2 containers : proxy-agent + haproxy) et sert de proxy entre le control plane et les workers. Le CP ne parle pas directement aux pods : tout le trafic CP->workers (logs, exec, port-forward, métriques) passe par ce tunnel.

Pour un service managé, c’est la bonne pratique : le control plane n’a pas besoin d’accès réseau direct aux pods, et les workers n’ont pas besoin d’exposer kubelet directement au CP.

Materia etcd

Pas de pod etcd dans le cluster : c’est normal. Clever Cloud utilise Materia etcd, leur implémentation serverless de l’API etcd construite sur FoundationDB. C’est transparent pour vous.

Cilium

Le CNI est Cilium v1.19.1. Pour aller plus loin sur l’intégration Cilium/CKE, je vous recommande l’article de Joseph qui est le premier à en avoir parlé publiquement et qui s’y connaît bien mieux que moi sur le sujet.

Les NodeGroups

Les workers sont gérés via une CRD custom NodeGroup (groupe api.clever-cloud.com/v1).

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
 name: mes-workers
spec:
 flavor: S
 nodeCount: 3

kubectl apply -f nodegroup.yaml

Les nodes apparaissent dans kubectl get nodes environ 35-40 secondes après la création du NodeGroup. La CRD supporte le subresource scale, ce qui permet de faire :

kubectl scale nodegroup mes-workers --replicas=5

Les flavors disponibles en ALL_IN_ONE : S (8 vCPU / 12 GB), M (10 vCPU / 16 GB), L (12 vCPU / 24 GB), XL (16 vCPU / 32 GB). Un quota global s’applique au niveau de l’organisation (40 vCPU / 40 GB RAM par défaut, tous clusters confondus). Ca peut probablement être augmenté en faisant une demande au support, mais j’ai pas assez d’argent à crâmer pour justifier une telle demande 😅.

En cas de dépassement de quota, le NodeGroup passe en phase QuotaExceeded avec un message d’erreur très lisible :

'Quota exceeded: RAM max: limit = 40.0 GB | actual = 48.0 GB | excess = 8.0 GB'

C’est appréciable : on sait exactement ce qui bloque et de combien.

La CLI propose aussi une gestion des node groups :

clever k8s nodegroups create moncluster workers M:3
clever k8s nodegroups update moncluster workers --count 5
clever k8s nodegroups update moncluster workers --autoscaling --min 2 --max 10

Combien de temps pour booter ?

Un des points forts mis en avant par Clever Cloud. J’ai mesuré avec un script de benchmark (3 runs) et via la commande clever k8s activity qui expose les timestamps précis de chaque étape :

clever k8s activity moncluster --format json

[
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "STARTED", "createdAt": "2026-05-12T06:27:11Z" },
 { "operation": "CREATE", "stepName": "Deploy Control Plane", "status": "COMPLETED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "STARTED", "createdAt": "2026-05-12T06:27:28Z" },
 { "operation": "CREATE", "stepName": "Install Plugins", "status": "COMPLETED", "createdAt": "2026-05-12T06:28:01Z" }
]

activity détaille chaque étape du bootstrap : création du réseau, déploiement de Materia LogicalDB, déploiement du control plane, configuration du load balancer, installation des plugins. Elle couvre aussi les opérations sur les NodeGroups.

Résultats mesurés (K8s 1.35, 3 runs, 5 nodes S) :

Étape	Moyenne
Cluster DEPLOYING -> ACTIVE	~57s
NodeGroup -> 1er node Ready	~38s
NodeGroup -> tous les nodes Ready	~46s (donc 8s après le premier node)
Suppression du cluster (API)	~244ms

Pour comparaison, SKS d’Exoscale bootstrappe le control plane en ~2 minutes (on me souffle dans l’oreille que ça a peut être baissé depuis). Et à la bonne époque où je faisais du AKS, c’était carrément 20+ minutes (j’espère qu’ils se sont améliorés depuis). Clever Cloud se place très haut sur ce critère.

Réseau, services, sécurité

LoadBalancer: chaque service de type LoadBalancer provisionne un L4 LB avec deux IPs publiques dédiées.

Ingress : pas d’ingress controller préinstallé. Traefik s’installe sans problème via Helm.

NetworkPolicies : Cilium étant le CNI natif, les NetworkPolicies sont enforced nativement. Pas besoin d’installer quoi que ce soit en plus.

Note pour ceux qui auraient lu mon article de mars sur le CNI chaining Flannel/Cilium : cet article était né des tests sur la bêta privée de CKE, qui utilisait Flannel à l’époque. Depuis le passage en bêta publique, CKE livre Cilium nativement (les NetworkPolicies fonctionnent out of the box).

Pod Security Admission : aucun namespace n’a de labels PSA par défaut (ni kube-system, ni default). Ça signifie que les pods sont en mode privileged implicite, sans restriction. On peut bien sûr configurer ça soi-même, mais sur un cluster managé on s’attendrait à avoir au minimum des profils baseline ou restricted préconfigurés sur les namespaces utilisateur.

RBAC : pas de surprise, le kubeconfig fourni donne un accès cluster-admin. A ne pas utiliser au delà de l’administration initiale ;-).

Stockage (CSI)

Le CSI n’est pas activé par défaut. Pour l’activer :

clever k8s add-persistent-storage moncluster

Activation en ~1 minute. Une StorageClass csi-rbd-sc (défaut) est créée, provisionnée par rbd.csi.ceph.com (Ceph RBD), filesystem XFS, volume expansion activée.

Les tests complets du cycle de vie (PVC, resize, snapshots) feront l’objet de la partie 2.

Un vrai déploiement : GroROTI

Histoire de valider que tout fonctionne de bout en bout, j’ai déployé GroROTI (ma propre application web en golang de ROTI) via Helm, avec Traefik en ingress controller et un certificat TLS.

helm install traefik traefik/traefik -n traefik --create-namespace
helm install groroti oci://ghcr.io/zwindler/groroti-chart \
 -f values-clever.yaml \
 --namespace groroti --create-namespace

Au bout de quelques minutes, l’application tourne sur groroti.zwindler.fr, accessible publiquement, TLS inclus. Ça fonctionne.

Bugs rencontrés (alpha / bêta oblige)

LoadBalancer : lors de mes premiers tests (alpha / bêta privée), j’avais eu un cas où l’EXTERNAL-IP restait en <pending> pendant… 32 heures. Ce problème semble avoir disparu en bêta publique.

Cluster FAILED sans diagnostic : lors de mes tests, j’ai eu plusieurs clusters qui passaient en FAILED ~25 secondes après la création, sans aucun message d’erreur exploitable. clever k8s get <ID> retourne juste Status: FAILED, même avec --verbose. Aucune commande logs ou events pour un cluster n’existe dans la CLI.

C’est d’autant plus frustrant que le status QuotaExceeded des NodeGroups est, lui, extrêmement bien documenté dans le message d’erreur. Il y a une belle asymétrie là.

Le bug a été résolu côté Clever Cloud dans la nuit. Mais le manque de diagnostic reste un point à améliorer. L’UI est aussi encore clairement en bêta, avec un petit bug graphique que j’ai pu remonter.

Conclusion (partie 1)

Première impression globalement positive. CKE est impressionnant pour une bêta :

Boot time excellent : ~57s pour le cluster (CP à part ou All in one), ~38s pour le premier node quand on ajoute des NodeGroups (dans le haut du panier des Kubernetes managés que j’ai testé au fil des années)
Cilium natif avec WireGuard inter-nodes, NetworkPolicies out of the box
Materia etcd sur FoundationDB : une approche originale pour gérer les problématiques etcd (scalabilité, multi tenancy) d’un cloud provider
Design CRD propre pour les NodeGroups, compatible kubectl scale
Konnectivity : isolation réseau du CP comme chez les grands cloud providers

Les points à améliorer : diagnostic du status FAILED, PSA non configurée par défaut, pas d’ingress controller inclus.

J’ai aussi une petite feature que j’ai demandé à Antoine chez Clever, l’audit logging, c’est en cours. Wait and see ;-).

La tarification du control plane me parait un poil élevée, typiquement face à des concurrents européens comme SKS ou Kapsule (mode mutualisé), mais elle s’explique par le choix architectural (VMs dédiées, rien de mutualisé). Pour une équipe déjà sur Clever Cloud, l’intégration avec le Clever Kubernetes Operator et les add-ons managés est un vrai argument.

Dans la partie 2, on creusera sûrement plus de fonctionnalités, comme le CSI (lifecycle PVC, resize, snapshots), les upgrades de cluster, l’intégration avec Clever Cloud operator (justement). Peut être aussi qu’on testera vCluster ou k3k ?

Flannel et NetworkPolicies : comment ajouter le support avec Cilium en CNI chaining

Sun, 15 Mar 2026 18:00:00 +0200

Flannel, flannel, flannel…

Flannel est un CNI simple et populaire 😢.

C’est le CNI par défaut de k3s, celui que la moitié des tutos kubeadm utilisent, et on le retrouve aussi dans pas mal d’offres managées.

OK, il est simple, il route les paquets entre les pods, il supporte VXLAN et WireGuard, il se configure en 2 minutes. Que demander de plus ?

Ben justement. Il y a un truc que flannel ne fait pas : les NetworkPolicies. (Et c’est très grave).

Flannel is focused on networking. For network policy, other projects such as Calico can be used.

[Edit] Contrairement à ce que j’écris ici, flannel supporte en fait les NetworkPolicies depuis au moins 2 ans, via l’implémentation de référence kube-network-policies du projet Kubernetes. L’option n’est pas mise en avant dans le README et ce n’est probablement pas plus recommandé en production, mais elle existe. Voir la documentation officielle.

Et le piège, c’est que si vous n’avez pas lu cette petite ligne dans le README.md, rien ne vous le dit explicitement.

Vous pouvez parfaitement créer des objets NetworkPolicy dans votre cluster, kubectl apply ne bronchera pas, kubectl get netpol vous les listera gentiment. Sauf que… elles ne sont pas enforced. Le trafic passe quand même. Votre deny-all ne deny rien du tout.

On vérifie pour être bien sûr

Avant de résoudre quoi que ce soit, vérifions que le problème existe. En partant du prérequis qu’on a un cluster Kubernetes qui a flannel comme CNI et que tout est fonctionnel, on va déployer deux pods dans deux namespaces différents : un client (curl) et un serveur (nginx).

On vérifie que le client peut joindre le serveur :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

On obtient la page d’accueil nginx. Jusque-là, tout est normal. Maintenant, on applique une NetworkPolicy deny-all sur le namespace du serveur :

# 01-deny-all-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: deny-all-ingress
 namespace: netpol-test-b
spec:
 podSelector: {}
 policyTypes:
 - Ingress

kubectl apply -f 01-deny-all-ingress.yaml

Et on re-teste :

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : la page nginx s’affiche toujours. La NetworkPolicy est bien créée (kubectl get netpol -n netpol-test-b la montre), mais elle n’est pas enforced. Le trafic passe comme si de rien n’était.

C’est le comportement attendu avec flannel (par défaut). Flannel ne fait que du routage L3 (overlay VXLAN ou WireGuard). Il n’implémente pas de contrôleur NetworkPolicy. Les objets existent dans etcd, mais personne ne les traduit en règles de filtrage.

On nettoie la policy avant de passer à la suite :

kubectl delete -f 01-deny-all-ingress.yaml

Les alternatives pour ajouter le support

Pendant longtemps j’ai pensé que c’était une fatalité. Je pense toujours que n’est pas un bon choix pour n’importe quelle production.

MAIS récemment, j’ai découvert qu’il était possible de chaîner les CNI au sein d’un même cluster, et ainsi d’avoir un CNI qui gère la majorité des tâches (ici Flannel) et un autre qui se charge d’autres tâches, comme par exemple enforcer des Netpols.

C’est d’ailleurs le principe de Canal, que je connaissais de nom mais que je n’avais jamais exploré. En fait, c’est ni plus ni moins qu’un manifeste qui déploie Flannel comme CNI principal avec Calico pour l’enforcing des NetOK fine, it’s truepols !

Canal was the name of Tigera and CoreOS’s project to integrate Calico and flannel.

Note : le projet GitHub a été archivé en octobre 2025 mais en théorie ça devrait encore fonctionner, si on trouve la doc correcte (pas trouvé, les liens sont KO, mais j’ai pas vraiment cherché non plus).

Vous avez donc compris le principe, on va ajouter un composant qui va watch les objets NetworkPolicy et les traduire en règles de filtrage effectives (iptables, eBPF, nftables…), sans toucher au flannel existant. C’est ce qu’on appelle le “CNI chaining” ou le mode “policy-only”.

Il existe plusieurs solutions :

Calico (Canal), Historiquement, la combinaison flannel + Calico s’appelle “Canal”, dont je viens de parler. Mais le manifeste Canal officiel embarque son propre flannel dans le même DaemonSet que calico-node. Si votre flannel est déjà installé et géré (par vous, par un opérateur, par un provider…), vous ne voulez probablement pas le remplacer. Et l’opérateur Tigera (la méthode Helm “officielle”) ne supporte pas non plus le déploiement en mode policy-only sur un flannel existant. Bref, c’est faisable mais ça nécessite un peu d’effort. Flemme.

kube-router, kube-router peut fonctionner en mode firewall-only (--run-firewall=true) et n’a besoin que d’iptables/ipset. C’est d’ailleurs ce que k3s utilise par défaut pour les NetworkPolicies. C’est la solution la plus légère (a priori ~50 Mo de RAM par node). Vérifiez que votre kernel dispose du module ip_set, sinon ça ne fonctionnera pas.

Cilium en mode CNI chaining, C’est la solution que j’ai retenue et qu’on va détailler. Cilium s’attache aux interfaces veth créées par flannel et ajoute ses programmes eBPF pour le policy enforcement. Pas de dépendance à iptables ou ipset, et en bonus on récupère Hubble pour l’observabilité réseau.

Installer Cilium en mode CNI chaining

Prérequis

Un cluster Kubernetes fonctionnel avec flannel
helm v3+
Un kernel >= 4.19 (idéalement >= 5.10 pour toutes les features eBPF)

Récupérer la configuration CNI de flannel

Cilium en mode chaining doit connaître la configuration CNI existante. On va la récupérer depuis un node :

kubectl debug node/$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') \
 -it --image=busybox -- cat /host/etc/cni/net.d/10-flannel.conflist

Sur mon cluster, ça donne :

{
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 }
 ]
}

Notez le champ name (ici cbr0). On en aura besoin.

Créer le ConfigMap de chaining

On va créer un ConfigMap qui reprend la config flannel et y ajoute le plugin cilium-cni en chaining :

apiVersion: v1
kind: ConfigMap
metadata:
 name: cni-configuration
 namespace: kube-system
data:
 cni-config: |-
 {
 "name": "cbr0",
 "cniVersion": "0.3.1",
 "plugins": [
 {
 "type": "flannel",
 "delegate": {
 "hairpinMode": true,
 "isDefaultGateway": true
 }
 },
 {
 "type": "portmap",
 "capabilities": {
 "portMappings": true
 }
 },
 {
 "type": "cilium-cni",
 "chaining-mode": "generic-veth"
 }
 ]
 }

Attention : le champ name doit correspondre à celui de votre conflist flannel. Si le vôtre s’appelle cni0 ou autre chose, adaptez.

Avant d’appliquer, vérifiez aussi que votre CNI utilise bien des interfaces veth (c’est le cas par défaut avec flannel, mais mieux vaut s’en assurer). Depuis un node :

ip -d link | grep veth

Vous devriez voir des interfaces de type veth correspondant à vos pods, par exemple :

103: lxcb3901b7f9c02@if102: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
veth addrgenmode eui64 numtxqueues 1 numrxqueues 1

Si c’est bien le cas, le mode generic-veth de Cilium fonctionnera. On applique :

kubectl apply -f cilium-cni-configmap.yaml

Installer Cilium via Helm

helm repo add cilium https://helm.cilium.io/
helm repo update

Voici les values pour le mode chaining :

# cilium-values.yaml
cni:
 chainingMode: generic-veth
 customConf: true
 configMap: cni-configuration
 install: true

routingMode: native
enableIPv4Masquerade: false
enableIPv6Masquerade: false

hubble:
 enabled: true
 relay:
 enabled: true
 ui:
 enabled: true

Les points importants :

cni.chainingMode: generic-veth, c’est le mode chaining, Cilium s’attache aux interfaces veth existantes
cni.customConf: true + cni.configMap, on fournit notre propre config CNI
routingMode: native, flannel gère le routage, pas Cilium
enableIPv4Masquerade: false, flannel gère le masquerading
hubble.enabled: true, l’observabilité réseau, c’est le gros bonus de Cilium

helm install cilium cilium/cilium --version 1.19.1 \
 --namespace kube-system \
 -f cilium-values.yaml

On attend que tout soit prêt :

kubectl rollout status daemonset/cilium -n kube-system --timeout=120s

Vérification

kubectl exec -n kube-system ds/cilium -- cilium status

Ce qui nous intéresse :

Kubernetes: Ok 1.35 (v1.35.0) [linux/amd64]
CNI Chaining: generic-veth
Cilium: Ok 1.19.1
Hubble: Ok

La ligne CNI Chaining: generic-veth confirme que Cilium fonctionne en mode chaining et ne remplace pas flannel.

Important : les pods qui existaient avant l’installation de Cilium ne sont pas automatiquement gérés par Cilium. Il faut les redémarrer pour que Cilium attache ses programmes eBPF. Pensez à faire un kubectl rollout restart de vos workloads de test (ou à les recréer).

Tester les NetworkPolicies

C’est le moment de vérité. On re-applique notre deny-all :

kubectl apply -f 01-deny-all-ingress.yaml

kubectl exec -n netpol-test-a client -- \
 curl -s --max-time 5 http://server.netpol-test-b.svc.cluster.local

Résultat : timeout ! Cette fois, la NetworkPolicy est bien enforced. Le trafic est bloqué.

J’ai enchaîné avec les autres scénarios classiques de NetworkPolicy, et tout fonctionne :

Allow ingress sélectif par namespace, en ajoutant une policy qui autorise le trafic depuis netpol-test-a uniquement, le curl passe depuis ce namespace mais reste bloqué depuis default. L’isolation par namespace fonctionne.
Deny-all egress, en bloquant tout le trafic sortant du client, même la résolution DNS est bloquée (timeout immédiat).
Allow egress sélectif, en autorisant uniquement le DNS (port 53) et le serveur (port 80 dans le namespace netpol-test-b), le curl vers le serveur passe mais curl http://example.com reste bloqué.

Bref, ingress, egress, sélectif par namespace, tout marche comme attendu.

Bonus : Hubble, l’observabilité réseau

C’est pour moi le vrai atout de Cilium par rapport aux alternatives. Hubble permet de voir en temps réel les flux réseau et les verdicts de policy :

kubectl exec -n kube-system ds/cilium -- \
 hubble observe --namespace netpol-test-b --last 5

Mar 15 13:20:42.287: netpol-test-a/client:40066 (ID:9745) ->
netpol-test-b/server:80 (ID:22271)
policy-verdict:none ALLOWED (TCP Flags: SYN)

On voit le pod source, le pod destination, le port, l’identité Cilium, et le verdict de policy. Quand vous debuggez une NetworkPolicy qui ne se comporte pas comme prévu, c’est vraiment pratique.

Combien ça coûte en ressources ?

Sur mon cluster (3 nodes), voici ce que Cilium consomme juste après installation :

Composant	Par node	RAM
cilium agent	oui (DaemonSet)	~160 Mo
cilium-envoy	oui (DaemonSet)	~22 Mo
cilium-operator	non (2 replicas)	~42 Mo
hubble-relay	non (1 replica)	~16 Mo
hubble-ui	non (1 replica)	~21 Mo

Soit environ 180 Mo par node pour l’agent + envoy. J’ai pas de point de comparaison par rapport à Calico ou kube-router, mais ça me semble acceptable, et le fait de pouvoir avoir une vision complète sur la totalité des flux avec Hubble justifie largement le surcoût (à mon avis).

Conclusion

Si jamais vous n’avez pas le choix et que vous devez composer avec flannel, et que vous voulez boucher le trou béant de sécurité que représente l’absence d’enforcement des Netpols, sachez donc qu’il est maintenant possible :

d’activer l’ajout de l’implémentation officielle (même si je ne l’ai pas testée, ça doit marcher)
de chaîner un autre CNI pour le faire

À défaut de l’avoir en CNI pour tout (tout bon cluster Kubernetes a Cilium comme CNI), Cilium en mode CNI chaining (generic-veth) est une solution plutôt sympa pour combler ce manque. Il ne touche pas au flannel existant, il s’y greffe. Et en bonus, vous récupérez Hubble pour l’observabilité réseau, ce qui est franchement appréciable.

Have fun :)

Un nouveau champ `log` pour les network policies Cilium : une idée de use case

Mon, 03 Nov 2025 12:00:00 +0200

TL;DR

Cilium 1.18 a ajouté un champ log aux CiliumNetworkPolicies pour taguer les verdicts de flux (FORWARDED, DROPPED, AUDIT, …) avec des labels personnalisés. Dans l’idée, c’est la fonctionnalité parfaite pour éviter de logger le trafic bloqué que l’on connait dans nos dashboards de monitoring !

Mais il y a un hic, sans rapport avec cette fonctionnalité, qui rend cette idée inutilisable : on ne peut pas l’utiliser avec egressDeny + toFQDNs.

ET, il y a un bug, qui fait que le “log” n’est visible que sur le trafic “autorisé”.

Je vous raconte…

Le problème : monitor all the things (mais pas trop)

Comme toute bonne équipe “ops” qui se respecte, nous monitorons/loggons les flux réseau de notre cluster Kubernetes avec Hubble pour une analyse ultérieure et de l’alerting. Nous (en particulier mon collègue Nicolas Nativel) poussons tous les flux AUDIT et DROPPED vers un dashboard Grafana pour pouvoir rapidement repérer quand quelque chose est bloqué et décider :

C’est légitime ? → On ouvre le flux
C’est suspect ? → On déclenche l’alarme 🚨

Ça fonctionne plutôt bien… jusqu’à ce qu’on commence à bloquer explicitement des choses qu’on sait devoir être bloquées.

Dans notre cas, nous voulions empêcher une application tierce d’envoyer les données de “télémétrie” (ouais, appelons ça comme ça 😏). On parle d’appels HTTPS vers des domaines de tracking externes.

Le problème ? Si on bloque simplement ces flux, ils apparaîtront comme DROPPED dans Hubble, déclencheront notre monitoring, et on se retrouvera avec des alertes pour quelque chose qu’on a intentionnellement bloqué.

C’est du bruit dont on ne veut pas.

Et donc, ce champ log des network policies de Cilium 1.18 ?

Bonne nouvelle ! Cilium 1.18 a introduit exactement ce dont nous avions besoin : la possibilité d’ajouter des champs de log personnalisés aux verdicts sur les network policies.

Cf. l’annonce dans le blogpost officiel.

L’idée est simple : vous ajoutez un champ log.value à votre CiliumNetworkPolicy :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: my-policy
spec:
 endpointSelector:
 matchLabels:
 app: my-app
 egress:
 - toFQDNs:
 - matchName: "example.com"
 log:
 value: "my-custom-log-tag"

Ensuite, quand vous observez les flux dans Hubble, vous pouvez les filtrer en utilisant CEL (Common Expression Language) :

hubble observe \
 --verdict AUDIT \
 --not \
 --cel-expression "(_flow.policy_log.endsWith('my-custom-log-tag'))" \
 --print-raw-filters

Output :

allowlist:
- '{"verdict":["AUDIT"]}'
denylist:
- '{"experimental":{"cel_expression":["(_flow.policy_log.endsWith(''my-custom-log-tag''))"]}}'

Parfait ! Vous savez maintenant taguer les calls que vous avez explicitement bloqués et les exclure de votre monitoring. 🎉

Le plan : bloquer la télémétrie élégamment

À l’aide de cette nouvelle fonctionnalité, nous avons élaboré notre stratégie :

Utiliser egressDeny pour bloquer explicitement les domaines de télémétrie
Ajouter un champ de log personnalisé : app-explicit-traffic-blocked
Configurer Hubble pour filtrer les verdicts de flux avec ce tag
Profit ! 🎉

Voici ce que nous avons essayé :

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
 name: app-external-block-policy
 namespace: my-namespace
spec:
 endpointSelector:
 matchLabels:
 app.kubernetes.io/name: my-app
 # note: egressDeny prend la précédence sur les règles egress
 # https://docs.cilium.io/en/stable/security/policy/language/#deny-policies
 egressDeny:
 # Bloquer tout le trafic externe et le logger avec un champ de log arbitraire
 # Ceci est utilisé pour empêcher l'app d'envoyer des données de télémétrie à l'extérieur
 # sans déclencher d'alerte AUDIT/DROPPED
 # fonctionnalité ajoutée dans cilium 1.18.0 https://github.com/cilium/cilium/pull/39902
 - toFQDNs:
 - matchPattern: "*.telemetry.example.com"
 toPorts:
 - ports:
 - port: "443"
 protocol: TCP
 - port: "80"
 protocol: TCP
 log:
 value: "app-explicit-traffic-blocked"

Ça devrait fonctionner, non ? On utilise egressDeny (qui prend la précédence sur les autres règles, ce qui est une bonne chose !), et on le tague avec notre log personnalisé.

Retour à la réalité

Et puis… patatra.

En lisant la documentation Cilium sur les deny policies, nous sommes tombés sur cette petite note de rien du tout :

Deny policies do not support:

policy enforcement at L7, i.e., specifically denying an URL

toFQDNs, i.e., specifically denying traffic to a specific domain name.

Attendez, quoi ?

On ne peut pas utiliser toFQDNs avec egressDeny. Tout notre plan vient de s’effondrer 😱.

Pourquoi c’est un problème, déjà ?

Le problème, c’est le modèle de précédence dans Cilium :

Les règles egressDeny prennent la précédence sur les règles egress (by design, et c’est bien !)
Mais si on utilise egressDeny, on ne peut pas utiliser toFQDNs pour cibler intelligemment le domaine incriminé, on doit bloquer par IP ou CIDR
Ces services de télémétrie utilisent probablement des IPs dynamiques pour leurs endpoints (bonne chance pour maintenir une liste…)
Et si on bloque tout le trafic 80/443 dans egressDeny, on ne peut pas faire d’exceptions pour le trafic légitime dans les règles egress car… deny prend la précédence sur allow !

On est coincé entre le marteau et l’enclume :

Utiliser egress avec toFQDNs → ça marche, mais on ne peut pas bloquer, seulement autoriser
Utiliser egressDeny avec des IPs → on va jouer au chat et à la souris avec des plages IP qui changent
Utiliser egressDeny pour bloquer tout le 80/443 → on bloque tout, y compris le trafic légitime

Solutions de contournement potentielles

En attendant que Cilium supporte toFQDNs dans les policies egressDeny, voici quelques approches alternatives que vous pourriez envisager :

Trouver un moyen de désactiver la télémétrie directement dans l’app

C’est la meilleure option, mais malheureusement pas toujours sur la table.

Blocage basé sur le DNS

Configurer le serveur DNS pour retourner NXDOMAIN pour les domaines de télémétrie, comme un serveur pi-hole personnel le ferait avec les pubs. L’application échouera à résoudre le domaine et n’enverra pas de données.

Utiliser egressDeny basé sur les IPs (avec un overhead de maintenance)

Résoudre les FQDNs de télémétrie vers leurs plages IP actuelles et les bloquer avec egressDeny :

egressDeny:
 - toCIDRSet:
 - cidr: 203.0.113.0/24  # Exemple de plage IP de télémétrie
 toPorts:
 - ports:
 - port: "443"

Si la liste n’évolue pas trop souvent, c’est une bonne option.

OK, mais imaginons qu’il n’y ait pas de trafic légitime. Peut-on utiliser la fonctionnalité pour ajouter un log sur le trafic droppé ?

Malheureusement non, pas pour le moment.

Il y a un bug dans cette nouvelle fonctionnalité de Cilium qui ne log le champ policy_log que sur les flux “autorisés”, pas sur les flux audit/dropped.

Policy log does not work for DROPPED/AUDIT flow ouverte par mon collègue Nicolas :

When defining a CiliumNetworkPolicy with the spec.log field configured, I expect the relevant hubble flows to have the policy_log field. It works for allowed flow.

But for denied/audited flow resulting from the rule (implicit or explicit), policy_log is never available.

Note: I observe the same issue with --print-policy-names option of hubble, the k8s:io.cilium.k8s.policy.derived-from label is not set for denied flows (but correctly set for allowed flows).

et une autre issue [Hubble CLI] –print-policy-names flag does not do anything ouverte par quelqu’un d’autre.

Puisque 2 tickets sont ouverts et que les mainteneurs ont commencé à répondre dessus, on peut espérer que ce soit corrigé un jour.

Conclusion

Dans notre cas d’usage, nous n’avons finalement pas utilisé cette nouvelle fonctionnalité de Cilium. Mais donner la possibilité d’ajouter des détails (et permettre de filtrer dessus également) est toujours une feature sympa.

Un grand merci à mon collègue Nicolas Nativel, qui a fait la majorité du travail autour des CiliumNetworkPolicies, incluant les dashboards, le travail exploratoire sur cette fonctionnalité, et a pris le temps de créer l’issue sur le repo Cilium.

Références

J'ai testé pour vous : k8e (Kubernetes Easy Engine)

Fri, 19 Sep 2025 16:00:00 +0000

Tu ne faisais pas un livre sur Kubernetes, toi ?

Oui ! Et j’ai une bonne nouvelle : mon livre “Kubernetes : 50 solutions pour les postes de développement et les clusters de production”, édité par Eyrolles, sortira le 16 octobre 2025 ! Vous pouvez suivre l’état d’avancement du projet sur 50ndk.zwindler.fr. Je ferai une annonce propre quand j’aurai la couverture définitive à vous montrer :3.

En attendant la sortie, je “libère” un autre chapitre qui avait été abandonné lors de la sélection finale du livre : celui sur k8e (Kubernetes Easy Engine). Si vous suivez le blog attentivement, vous vous souviendrez peut-être que j’avais fait pareil pour k8s-tew (K8S : the easier way), qui n’avait aussi pas eu la chance de figurer dans la liste des 50 méthodes qui ont leur place dans mon livre :-P.

Mais revenons à k8e !

k8e est un wrapper pour k3s qui permet d’installer facilement un cluster multi-nodes avec Cilium configuré comme CNI et en mode kube-proxy replacement. Dans la philosophie, c’est vraiment pas beaucoup plus que k3s avec un gros preflight check. On est même pas sur le niveau fonctionnel d’un k3sup ou d’un k0ctl…

Les développeurs mettent en avant plusieurs fonctionnalités clés :

✅ Key Features

Supports airgap images package for k8s components

10-year valid certificate, supports cluster backup and upgrade

No dependency on Ansible, HAProxy, or Keepalived; a binary tool with zero dependencies

Natively supports Cilium network

No kube-proxy component

Le projet se présente donc comme une alternative simplifiée pour déployer k3s avec Cilium directement intégré, ce qui évite les étapes manuelles de configuration post-installation. J’ai d’ailleurs écrit un article fin 2023 sur ces fameuses opérations manuelles, toujours disponible ici : k3s et cilium rapide et facile

Prérequis

Comme k8e s’appuie sur k3s, les prérequis sont globalement les mêmes que pour k3s. Cependant, il y a une exigence supplémentaire importante : Cilium utilisant eBPF pour ses fonctionnalités de bas niveau, il faut un noyau Linux relativement récent

Bon, ça c’était ce qu’on disait pour les premières versions de cilium. Maintenant Linux kernel >= 4.19.57 c’est un vieux vieux kernel !

Pour mes tests, j’ai utilisé 4 machines virtuelles dans le même LAN :

k8e1 (control plane, 192.168.1.11)
k8e2 (control plane, 192.168.1.12)
k8e3 (control plane, 192.168.1.13)
k8e4 (worker, 192.168.1.14)

L’installation nécessite un accès SSH avec des privilèges sudo/root sur tous les nœuds.

Installation du premier nœud

Le Getting started est un peu rude car on tombe sur une page en chinois simplifié par défaut…

L’installation de k8e se fait via un script bash, comme beaucoup d’outils de la CNCF (RIP la sécurité). Pour le premier nœud (qui sera notre premier node control plane), on utilise la commande suivante :

denis@k8e1:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | API_SERVER_IP=192.168.1.11 K8E_TOKEN=superSecureToken INSTALL_K8E_EXEC="server --cluster-init" sh -

Le script réalise plusieurs vérifications préalables (“preflight checks”) pour s’assurer que l’environnement est compatible. C’est notamment là qu’il vérifie la version du noyau Linux pour la compatibilité eBPF.

[2025-09-19 12:28:45] [WARN] System memory is less than 4GB. This may affect performance.
Finding latest version from GitHub
v1.31.2+k8e1
Downloading package https://github.com/xiaods/k8e/releases/download/v1.31.2+k8e1/k8e as /home/denis/k8e
...

À la fin du processus, on obtient un message de confirmation :

[...]
[2025-09-19 12:35:33] [INFO] systemd: Starting k8e
[2025-09-19 12:35:41] [INFO] Installing cilium network cni/operator
ℹ️ Using Cilium version 1.15.6
🔮 Auto-detected cluster name: default
🔮 Auto-detected kube-proxy has not been installed
ℹ️ Cilium will fully replace all functionalities of kube-proxy
[2025-09-19 12:35:42] [INFO] Installation completed successfully
[2025-09-19 12:35:42] [INFO] Performing cleanup...

Point qui a été amélioré depuis la dernière fois que j’avais testé, k8e copie lui-même le kubeconfig, il n’y a plus besoin d’aller le récupérer dans /etc/k8e/k8e.yaml (idem k3s, il est traditionnellement dans /etc/rancher/k3s/k3s.yaml)

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 62m v1.31.2+k8e1

Cependant, un rapide coup d’œil permet de voir “comment” k8e le fait :

denis@k8e1:~$ env
...
KUBECONFIG=/etc/k8e/k8e.yaml

denis@k8e1:~$ ls -l /etc/k8e/k8e.yaml
-rw-r--r-- 1 root root 2961 Sep 19 12:35 /etc/k8e/k8e.yaml

Et là, je suis désolé, mais c’est :

Le kubeconfig cluster-admin à poil en 644, c’est NON. La doc de k8e est même encore pire, elle conseille du 666 (toujours plus).

Ajout des nœuds supplémentaires

Une fois le premier nœud installé, on peut ajouter les autres membres du control plane. Pour les nœuds supplémentaires du control plane :

denis@k8e2:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

denis@k8e3:~$ curl -sfL https://getk8e.com/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 INSTALL_K8E_EXEC="server" sh -s -

Et pour le worker node :

denis@k8e4:~$ curl -sfL https://getk8e-site.pages.dev/install.sh | K8E_TOKEN=superSecureToken K8E_URL=https://192.168.1.11:6443 sh -

On peut ensuite vérifier que tous les nœuds sont bien présents :

denis@k8e1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8e1 Ready control-plane,etcd,master 72m v1.31.2+k8e1
k8e2 Ready control-plane,etcd,master 2m30s v1.31.2+k8e1
k8e3 Ready control-plane,etcd,master 2m18s v1.31.2+k8e1
k8e4 Ready <none> 75s v1.31.2+k8e1

Vérification de Cilium

Une des particularités de k8e est donc l’intégration native de Cilium. On peut vérifier que Cilium fonctionne correctement en utilisant sa CLI directement sur un des nœuds du control plane (installée par défaut) :

denis@k8e1:~$ cilium status
 /¯¯\
 /¯¯\__/¯¯\  Cilium: OK
 \__/¯¯\__/ Operator: OK
 /¯¯\__/¯¯\  Envoy DaemonSet: disabled (using embedded mode)
 \__/¯¯\__/ Hubble Relay: disabled
 \__/ ClusterMesh: disabled

DaemonSet cilium Desired: 4, Ready: 4/4, Available: 4/4
Deployment cilium-operator Desired: 1, Ready: 1/1, Available: 1/1
Containers: cilium Running: 4
 cilium-operator Running: 1
Cluster Pods: 3/3 managed by Cilium
Helm chart version: 1.15.6
Image versions cilium quay.io/cilium/cilium:v1.15.6: 4
 cilium-operator quay.io/cilium/operator-generic:v1.15.6: 1

Avantages et Inconvénients

Les plus	Les moins
➕ Installation automatisée de Cilium sur k3s	➖ Permissions `/etc/k8e/k8e.yaml` en “world readable” dans la doc officielle (dangereux !)
	➖ Version de Kubernetes en retard par rapport aux dernières versions
	➖ N’apporte pas énormément de valeur ajoutée par rapport à k3s seul
	➖ Documentation limitée par rapport aux projets plus matures

Conclusion

Dans les points positifs, le projet, sans être populaire, est quand même plutôt suivi avec pas mal de contributions externes et une “vie” (commits réguliers). k8e est un outil pour les fainéants qui veulent installer un cluster k3s avec Cilium plus rapidement (oui c’est un point positif).

Mais, à quel prix ?

Un kubeconfig à 644, lisible par tous les utilisateurs unix des control planes
Une installation en curl | bash (exactement comme k3s, à ceci près que j’ai plus confiance en Rancher labs qu’en xiaods)
Des versions datées (kube 1.31, cilium 1.15)

Pas la peine que je vous dise ce que j’en pense, je pense que vous avez compris.

Migration du routage de cilium de iptables vers eBPF... à chaud !

Fri, 20 Oct 2023 06:00:00 +0200

Contexte

Il se pourrait que j’aie configuré des clusters Kubernetes de prod avec cilium en mode iptables et non pas eBPF. Mais vous n’avez aucune preuve…

Cependant, dans l’hypothèse hautement improbable où j’aurais pu faire une boulette pareille, voilà comment je m’y serai pris pour résoudre le problème.

#trollface

Imaginons donc qu’en vérifiant la configuration de Cilium, voici ce que vous avez trouvé :

kubectl -n cilium exec -it cilium-aaaaa -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]

Damned!

A y regarder de plus près, les containers cilium-agent dans vos pods cilium prennent beaucoup de CPU et de RAM et commencent à engorger vos workers…

C’est la cata.

Pourquoi ça ?

Les premières implémentations du réseau imaginaire de Kubernetes (les fameux CNI plugins) utilisaient iptables. Or, on sait depuis très longtemps, notamment dans le cas d’usage de Kubernetes, qu’iptables est assez mauvais pour gérer de grandes quantités de règles.

Dans le cas particulier de Kubernetes, le nombre de règles à tendance à augmenter de manière exponentielle avec la taille du cluster et le CPU consommé pour router des paquets réseaux avec…

À un moment donné, parcourir la liste des règles prend tout le CPU d’un nœud donné et le rend non réactif.

Allo patron ? On est mal.

C’est une des raisons pour lesquelles j’aime beaucoup cilium comme CNI plugin, les développeurs font partie des premiers à avoir misé sur eBPF comme remplacement d’iptables (même s’il existe d’autres implémentations / d’autres technos qui règles ce problème).

Comment en est on arrivé là ?

A vrai dire, j’ai juste lu la doc et fait confiance…

We introduced eBPF-based host-routing in Cilium 1.9 to fully bypass iptables and the upper host stack, and to achieve a faster network namespace switch compared to regular veth device operation. This option is automatically enabled if your kernel supports it. To validate whether your installation is running with eBPF host-routing, run cilium status in any of the Cilium pods and look for the line reporting the status for “Host Routing” which should state “BPF”.

Grosso modo, selon la doc officielle, si on dispose du kernel correct et des modules qui vont bien, l’installation de cilium est censée activer automatiquement le mode eBPF… Sauf qu’on voit bien un peu plus haut que ce n’est pas le cas, malgré un kernel récent (6.2).

En creusant un peu plus les logs, voilà ce qu’on peut trouver :

kubectl -n cilium logs cilium-7b5cp
[...]
level=info msg="BPF host routing requires enable-bpf-masquerade. Falling back to legacy host routing (enable-host-legacy-routing=true)." subsys=daemon

Bon… visiblement, il manque une option dans la chart Helm.

[...]
 kubeProxyReplacement: strict
+ bpf:
+ masquerade: true
[...]

Problem solved, fin de l’article ?

Problème

Alors oui, forcément, on peut modifier la chart comme un⋅e bourrin⋅e et fin de l’histoire.

Mais admettons qu’on ait pas envie de couper le trafic de production… Comment on fait ?

La solution la plus clean qui me vient en tête est la suivante :

on drain un node
on lui change sa configuration
on l’uncordon pour lui remettre un peu de trafic dessus
on vérifie que la nouvelle configuration fonctionne ET
on vérifie que les nodes peuvent se parler entre eux entre ceux en iptables et ceux en eBPF

Bah oui, ça serait dommage d’avoir la moitié du cluster qui peut pas communiquer avec l’autre moitié…

Vérifier la connectivité

Ce qui est cool avec cilium (je vous ai déjà dit que j’aime cilium ?), c’est qu’on a déjà du tooling pour tout tester.

La CLI cilium dispose d’une sous commande cilium connectivity test qui lance des dizaines de tests internes/externes pour tester que tout est OK.

➜ ~ cilium -n cilium connectivity test
ℹ️ Monitor aggregation detected, will skip some flow validation steps
✨ [node] Deploying echo-same-node service...
✨ [node] Deploying DNS test server configmap...
✨ [node] Deploying same-node deployment...
✨ [node] Deploying client deployment...
[...]
✅ All 32 tests (265 actions) successful, 2 tests skipped, 0 scenarios skipped.

Il existe aussi une commande cilium-health, embarquée dans le container cilium-agent, qui permet de remonter des statistiques périodiques de latences entre tous les nodes du cluster. Utile !

kubectl -n cilium exec -it cilium-ccccc -c cilium-agent -- cilium-health status
Probe time: 2023-09-12T14:47:03Z
Nodes:
 node-02 (localhost):
 Host connectivity to 172.31.0.152:
 ICMP to stack: OK, RTT=860.424µs
 HTTP to agent: OK, RTT=110.142µs
 Endpoint connectivity to 10.0.2.56:
 ICMP to stack: OK, RTT=783.861µs
 HTTP to agent: OK, RTT=256.419µs
 node-01:
 Host connectivity to 172.31.0.151:
 ICMP to stack: OK, RTT=813.324µs
 HTTP to agent: OK, RTT=553.445µs
 Endpoint connectivity to 10.0.1.53:
 ICMP to stack: OK, RTT=865.976µs
 HTTP to agent: OK, RTT=3.440655ms
[...]

Et enfin, on peut juste regarder la commande cilium status qui nous dit qui est “reachable” (là encore, dans le container cilium-agent)

➜ kubectl -n cilium exec -ti cilium-ddddd -- cilium status
[...]
Host Routing: Legacy
Masquerading: IPTables [IPv4: Enabled, IPv6: Disabled]
[...]
Cluster health: 5/5 reachable (2023-09-14T12:01:51Z)

Changer la configuration d’un node

On a de la chance, car, depuis la version 1.13 de cilium (la dernière en date est la 1.14), il est possible d’appliquer des configurations différentes pour un sous ensemble de nodes (documentation officielle du Per-node configuration).

Note : avant ça, c’était quand même possible, de manière temporaire, en éditant la ConfigMap de cilium à la main, puis en redémarrant les pods concernés pour prise en compte.

Il existe maintenant une CRD pour le faire, qui s’appelle CiliumNodeConfig. Les seules choses qu’on a à faire, c’est ajouter un label sur un node (io.cilium.enable-ebpf: “true”) et ajouter le manifest suivant sur notre cluster :

cat > cilium-fix.yaml << EOF
apiVersion: cilium.io/v2alpha1
kind: CiliumNodeConfig
metadata:
 namespace: cilium
 name: cilium-switch-from-iptables-ebpf
spec:
 nodeSelector:
 matchLabels:
 io.cilium.enable-ebpf: "true"
 defaults:
 enable-bpf-masquerade: "true"
EOF

kubectl apply -f cilium-fix.yaml

kubectl label node node-05 --overwrite 'io.cilium.enable-ebpf=true'

Si jamais on est en production, le plus propre est donc de kubectl drain le Node préalablement.

Par curiosité, j’ai quand même essayé de le faire “à chaud”, pour le fun.

J’ai déployé un daemonset contenant une app en V(lang) qui répond simplement le nom du container dans une page web :

cat > vhelloworld-daemonset.yaml << EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: vhelloworld-daemonset
spec:
 selector:
 matchLabels:
 app: vhelloworld
 template:
 metadata:
 labels:
 app: vhelloworld
 spec:
 containers:
 - name: vhelloworld
 image: zwindler/vhelloworld:latest
 ports:
 - containerPort: 8081
 imagePullPolicy: Always
EOF

kubectl apply -f vhelloworld-daemonset.yaml

kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
vhelloworld-daemonset-q4h44 1/1 Running 0 3m31s 10.0.4.87 nodekube-05 <none> <none>
vhelloworld-daemonset-w97pv 1/1 Running 0 3m31s 10.0.3.85 nodekube-04 <none> <none>

Puis j’ai créé des containers contenant un shell et curl pour vérifier périodiquement et depuis plusieurs nodes que les containers sont bien accessibles :

kubectl run -it --image curlimages/curl:latest curler -- /bin/sh
If you don't see a command prompt, try pressing enter.
~ $ curl http://10.0.4.87:8081
hello from vhelloworld-daemonset-g2zdw
~ $ curl http://10.0.3.85:8081
hello from vhelloworld-daemonset-65k2n

~ $ while true; do
 date
 curl http://10.0.4.87:8081
 curl http://10.0.3.85:8081
 echo
 sleep 1
done

Une fois le label appliqué sur un node, son pod cilium tué (via un kubectl delete), les pods sont restés accessibles

Fri Sep 15 14:05:34 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:35 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

Fri Sep 15 14:05:36 UTC 2023
hello from vhelloworld-daemonset-g2zdw
hello from vhelloworld-daemonset-65k2n

A un moment donné, cilium a redémarré, remarqué la présence de pods existants, et pris le relais avec eBPF !

evel=info msg="Rewrote endpoint BPF program" containerID=8b7be1b032 datapathPolicyRevision=0 desiredPolicyRevision=1 endpointID=1018 identity=4773 ipv4=10.0.3.85 ipv6= k8sPodName=default/vhelloworld-daemonset-w97pv subsys=endpoint
level=info msg="Restored endpoint" endpointID=1018 ipAddr="[10.0.3.85 ]" subsys=endpoint

Ca fonctionne, mais est ce que c’est mieux en termes de consommation de ressources ?

Ca, c’était la bonne nouvelle. Je m’attendais à des gains car le cluster était vraiment pas loin de souffrir.

Les containers cilium prenaient 10% des CPU de mes nodes, et plusieurs Go de RAM en mode iptables. Ca aurait rapidement pu monter bien plus haut, si j’avais agrandi le cluster au-delà des 50 nodes / 2000 pods.

Le passage au mode eBPF a permis de retrouver des niveaux totalement indolores (1% de CPU par node, 1-2% de RAM) par rapport aux configurations de mes machines.

Pas mal, hein ?

Bonus

Un tutoriel bien velu pour migrer totalement de CNI à chaud (de flannel à cilium)

k3s et cilium rapide et facile

Fri, 01 Sep 2023 10:00:00 +0200

Contexte

K3s est une distribution de Kubernetes éditée par Rancher (et certifiée par la CNCF) que je trouve super pratique car légère et supportant plusieurs plateformes (en particulier ARM):

x86_64
armhf
arm64/aarch64
s390x

Je l’ai déjà utilisée par le passé (ici) pour faire un cluster kubernetes avec des vieux Raspberry Pi. A l’époque, on pouvait même faire tourner les nodes “workers” sur des RPi 1 (je ne sais pas si c’est toujours possible).

La particularité de k3s est que tout est intégré dans un seul binaire. Nécessairement, des choix techniques ont été fais pour rendre l’installation et l’utilisation la plus légère possible. Parmi ces choix techniques, il y a l’utilisation de flannel comme “CNI plugin” (pour faire simple, le réseau virtuel qui permet aux containers de parler en eux).

Je ne suis vraiment PAS fan de flannel qui m’a posé beaucoup de soucis en production, qui ne supporte pas les “Network Policies”, qui a pendant plusieurs années utilisé comme backend etcd2 alors que ce logiciel était marqué comme obsolète (deprecated) depuis plusieurs années, …

A l’inverse, je suis très fan de cilium, qui a beaucoup de fonctionnalités sympa grâce à l’usage de eBPF en termes de performance et de sécurité et a pas mal de traction dans l’écosystème.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez installé un serveur avec Ubuntu 22.04.

Cilium est très friand d’eBPF, dont il tire la plupart de ces fonctionnalités. Et comme eBPF est quelque chose d’assez récent dans le kernel Linux, le mieux est de mettre à jour notre serveur et de lui mettre un kernel plus récent :

$ sudo apt update -y
$ sudo apt upgrade -y
$ sudo apt install curl linux-image-generic-hwe-22.04 -y

Une fois que c’est fait, on reboot le serveur pour la prise en compte du nouveau kernel.

Installation de k3s

On installe donc k3s, en remplaçant flannel par cilium (voir documentation Installation - Network options). La doc conseille de retirer le support des network-policy. Je me demande comment c’est géré puisque flannel n’est pas censé les supporter :thinking_face:.

$ curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC='--flannel-backend=none --disable "traefik"' sh -s - --disable-network-policy

On vérifie que k3s est démarré et fonctionne :

$ systemctl status k3s
● k3s.service - Lightweight Kubernetes
 Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)
 Active: active (running) since Fri 2023-09-01 12:32:55 UTC; 1min 13s ago
 Docs: https://k3s.io
 Process: 1724 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service (code=exited, status=0/SUCCESS)
 Process: 1726 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
 Process: 1727 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
[...]

Par défaut, le “kubeconfig” d’administration est déposé dans le fichier /etc/rancher/k3s/k3s.yaml, dont le propriétaire est root. Il existe un flag --write-kubeconfig-mode dans k3s pour modifier les droits de ce fichier mais cela le rendrait “world readable”.

Pour éviter de faire ça, on récupère le kube/config pour notre utilisateur “ubuntu”.

Comme le binaire k3s embarque tout, dont kubectl, on va aussi devoir lui dire de ne pas utiliser ce fichier en forçant la variable d’environnement $KUBECONFIG.

$ mkdir ~/.kube
$ sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
$ sudo chown ubuntu:ubuntu ~/.kube/config
$ chmod 600 ~/.kube/config
$ export KUBECONFIG=~/.kube/config

$ echo 'export KUBECONFIG=~/.kube/config' >> ~/.bashrc
$ echo 'source <(kubectl completion bash)' >> ~/.bashrc
$ echo 'alias k=kubectl' >> ~/.bashrc
$ source ~/.bashrc

$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
kube01 NotReady control-plane,master 70s v1.27.4+k3s1

Ici, kube01 est marqué NOTREADY. C’est normal car on a pas de CNI plugin (donc pas de réseau interne).

Ajout d’un second node

Sur le premier node, récupérez le token pour que le second puisse rejoindre le cluster :

cat /var/lib/rancher/k3s/server/node-token

Une fois que c’est fait, connectez vous sur le node à rajouter au cluster, installez le kernel hwe, rebootez

sudo apt update
sudo apt upgrade
sudo apt install curl linux-image-generic-hwe-22.04 -y
sudo reboot

Une fois que le node est à jour et prêt à rejoindre le cluster, lancez la commande suivante :

IP_MASTER=IP.DE.VOTRE.MASTER
K3STOKEN=le:token:du:master
curl -sfL https://get.k3s.io | K3S_URL=https://${IP_MASTER}:6443 K3S_TOKEN=${K3STOKEN} sh -

Au bout de quelques secondes, votre node va apparaître dans la liste des nodes.

CNI plugin + ingressController

Nos nodes sont toujours en “Not Ready”. On installe helm et on ajoute le CNI plugin :

$ curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
$ CILIUM_VERSION="1.14.2"
$ helm repo add cilium https://helm.cilium.io/
$ helm upgrade --install cilium cilium/cilium --version=${CILIUM_VERSION} \
 --set global.tag="v${CILIUM_VERSION}" --set global.containerRuntime.integration="containerd" \
 --set global.containerRuntime.socketPath="/var/run/k3s/containerd/containerd.sock" \
 --set global.kubeProxyReplacement="strict" \
 --set global.bpf.masquerade="true" \
 --set ingressController.enabled=true \
 --set ingressController.default=true \
 --namespace cilium \
 --create-namespace

Note: pour le fun, j’ai aussi ajouté le support de l’ingressController de cilium. Comme ça c’est fait :D.

Au bout de quelques secondes, notre cluster devrait devenir opérationnel. On a aussi metric server (pour les stats de base).

$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system cilium-operator-86dbc96dd6-hlgtt 1/1 Running 0 56s
kube-system cilium-operator-86dbc96dd6-h7sq6 1/1 Running 0 56s
kube-system cilium-pxrrz 1/1 Running 0 56s
kube-system cilium-psjr4 1/1 Running 0 56s
kube-system svclb-cilium-ingress-c27a13c6-x7tld 2/2 Running 0 32s
kube-system local-path-provisioner-957fdf8bc-5w9n9 1/1 Running 0 6m9s
kube-system coredns-77ccd57875-zlvpc 1/1 Running 0 6m9s
kube-system svclb-cilium-ingress-c27a13c6-8dbf6 2/2 Running 0 34s
kube-system metrics-server-648b5df564-xr29p 1/1 Running 0 6m9s

Conclusion

Voilà pour ce très court article sur k3s et cilium.

Ce setup, rapide à installer sur une install fraîche est ma base pour beaucoup d’expérimentations avec Kubernetes.

Kubeadm, Ubuntu 22.04 et cilium - mes petites galères récentes

Tue, 06 Jun 2023 12:00:00 +0200

Kubernetes, le retour de la vengeance

J’ai été pas mal pris ces derniers temps, autant côté pro que côté perso, et j’ai un peu délaissé mes clusters Kubernetes (qui vivent leur vie).

Aussi, quand j’ai eu le temps de m’y remettre, j’ai perdu pas mal de temps sur plusieurs “petites” bêtises liés, la plupart du temps à des modifications introduites dans les composants de ma stacks.

Une preuve (si c’était nécessaire) qu’il est important de se maintenir à la page, à jour et surtout de bien lire les changelogs.

Voici donc la liste des soucis que j’ai rencontrés et de comment on les corrige / contourne.

cilium et kernel Ubuntu Minimal

L’an dernier, j’ai décidé de concevoir un nouveau talk inspiré de “dessine moi un cluster” de Jérôme Petazzoni. Dans ce talk dont j’ai déjà parlé ici, je construis en live coding un “cluster” Kubernetes brique par brique, binaire par binaire.

Et pour le CNI, j’avais choisi Cilium que j’utilise par ailleurs et que j’aime bien.

Sauf que 2 jours avant de monter sur scène, j’ai changé d’hébergeur un peu en urgence (problème de disponibilité) et patatra, le talk ne marchait plus. Cilium avait l’air de s’installer correctement mais les pods finissaient par crasher, rendant toute communication avec les Pods / Services de mon cluster impossible…

En creusant un peu, je suis tombé sur ces logs dans le container de l’agent cilium sur mon node :

level=warning msg="+ tc qdisc replace dev cilium_vxlan clsact" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="+ true" subsys=datapath-loader
level=warning msg="++ grep -v 'pref 1 bpf chain 0 $\\|pref 1 bpf chain 0 handle 0x1'" subsys=datapath-loader
level=warning msg="++ tc filter show dev cilium_vxlan ingress" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="Dump terminated" subsys=datapath-loader
level=warning msg="+ '[' -z '' ']'" subsys=datapath-loader
level=warning msg="+ cilium bpf migrate-maps -s bpf_overlay.o" subsys=datapath-loader
level=warning msg="+ tc filter replace dev cilium_vxlan ingress prio 1 handle 1 bpf da obj bpf_overlay.o sec from-overlay" subsys=datapath-loader
level=warning msg="RTNETLINK answers: Operation not supported" subsys=datapath-loader
level=warning msg="We have an error talking to the kernel" subsys=datapath-loader
level=warning msg="+ cilium bpf migrate-maps -e bpf_overlay.o -r 1" subsys=datapath-loader
level=warning msg="+ return 1" subsys=datapath-loader
level=fatal msg="Error while creating daemon" error="error while initializing daemon: failed while reinitializing datapath: exit status 1" subsys=daemon

Et le message important là dedans, c’est RTNETLINK answers: Operation not supported, qui m’a permis de trouver cette issue sur le dépôt github de cilium.

Lorsque j’avais changé d’hébergeur, je n’avais pas fait attention mais les machines Ubuntu livrées l’étaient avec une install “minimal” sur laquelle il manque des capabilities, en particulier CONFIG_NET_CLS_ACT=y qui est un des prérequis de cilium.

Cependant, l’installation échoue silencieusement (ou alors c’est discret). Un gros warning aurait été le bienvenu…

L’erreur disparaît quand on change de kernel ou d’image de base.

containerd et cgroups systemd

En essayant de créer un nouveau cluster Kubernetes avec kubeadm sur des machines Ubuntu 22.04, je me suis retrouvé assez vite avec un problème bizarre et très vite bloquant : les noeuds de mon cluster etcd tombaient les uns à la suite des autres, provoquant on crash du cluster.

Alors que tout semble ok, le container s’arrête avec un laconique received signal; shutting down :

2022-02-05T00:46:42.582666628Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"embed/serve.go:188","msg":"serving client traffic securely","address":"172.31.58.179:2379"}
2022-02-05T00:46:42.582757689Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"etcdmain/main.go:47","msg":"notifying init daemon"}
2022-02-05T00:46:42.58276643Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"etcdmain/main.go:53","msg":"successfully notified init daemon"}
2022-02-05T00:46:42.582906352Z stderr F {"level":"info","ts":"2022-02-05T00:46:42.582Z","caller":"embed/serve.go:188","msg":"serving client traffic securely","address":"127.0.0.1:2379"}
2022-02-05T00:56:02.302978572Z stderr F {"level":"info","ts":"2022-02-05T00:56:02.302Z","caller":"osutil/interrupt_unix.go:64","msg":"received signal; shutting down","signal":"terminated"}

En réalité, il s’agit d’une modification d’un paramètre de containerd que je n’avais jamais eu besoin de modifier lors de mes installations précédentes mais qui semble nécessaire maintenant.

En effet, quand on génère la configuration par défaut de container avec la commande containerd config default, la valeur SystemdCgroup est à false.

J’ai perdu un peu de temps mais heureusement je suis assez vite tombé sur cette issue, ainsi que sur la documentation officielle qui indique bien la bonne configuration à faire.

`kubeadm` et plusieurs interfaces

Jusqu’à présent, je n’avais travaillé qu’avec des nodes qui n’avaient qu’une seule IP principale. Récemment, j’ai dû configurer kubeadm sur des machines avec plusieurs IPs/VLAN.

Lorsque j’ai commencé à essayer de configurer kubeadm pour qu’il en tienne compte, je me suis emmêlé les pinceaux

J’avais bien remarqué la présence d’un flag --api-advertise dans la commande kubeadm init mais je ne pouvais pas utiliser ce flag car j’utilise des fichiers de configuration kubeadmcfg de manière à pouvoir customiser de manière plus poussée mes clusters, et l’usage de flags conjointement avec le --config n’est pas supporté

Mon erreur avait été d’insérer un le bloc localAPIEndpoint (l’équivalent du --api-advertise mais dans la config) dans la ClusterConfiguration alors qu’il faut créer un autre manifest dans le même fichier avec pour kind InitConfiguration.

---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
 advertiseAddress: 10.0.0.4
 bindPort: 6443
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controlPlaneEndpoint: 10.10.10.10
[...]

Cette valeur qui a priori semble ne concerner que l’API server override en fait tous les composants dans votre control plane (etcd, scheduler, controller manager) donc pas besoin de les configurer en plus.

A noter, pour tout ce qui est utilisation d’une Virtual IP qui loadbalancerait les requêtes vers vos APIservers, c’est bien controlPlaneEndpoint qu’il faut utiliser.

Et alors, `kubelet` et plusieurs interfaces ?

Si jamais vous voulez modifier les IPs des composants du control plane, il est probable que vous voudrez aussi modifier celle du kubelet.

Pour modifier l’InternalIP de vos nodes, il est nécessaire de modifier les paramètres dans le kubelet.conf.

A partir de là, vous avez deux possibilités. La plus simple si vous avez plusieurs hostnames pour chaque IP, est d’utiliser le paramètre --hostname-override qui va permettre d’à la fois changer le hostname par défaut de la machine quand elle s’enregistre dans Kubernetes, mais aussi L’InternalIP.

Dans mon cas, ça ne m’aidait pas car l’IP qui m’intéressait n’avait pas de résolution DNS et je ne voulais pas modifier le hostname tel qu’il était.

Pour modifier l’interface sur laquelle kubelet écoute et l’InternalIP, il est nécessaire de modifier 2 paramètres : --address (pour l’interface d’écoute) et --node-ip (modifier l’InternalIP)

kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
zwindler-01 Ready control-plane 28m v1.24.14 10.0.0.4 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-02 Ready control-plane 28m v1.24.14 10.0.0.5 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-03 Ready control-plane 27m v1.24.14 10.0.0.6 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-04 Ready node 27m v1.24.14 10.0.0.7 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21
zwindler-05 Ready node 27m v1.24.14 10.0.0.8 <none> Ubuntu 22.04.2 LTS 5.19.0-42-generic containerd://1.6.21

Ubuntu 22.04 et ManageForeignRoutes

Je ne me suis pas le seul à s’être mangé de plein fouet cette modification de systemd sur les Ubuntu récents, puisque cette modification est la “rootcause” de l’incident global de mars de Datadog (vous pouvez aller lire le postmortem ici)

Quand j’installais cilium sur des serveurs Ubuntu 22.04, instantanément, il n’était plus possible de ping et/ou contacter les IPs locale de la machine, mais aucun problème pour contacter le reste du monde.

$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4076ms
$ ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=0.285 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=0.233 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=63 time=0.248 ms
$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
1 * * *
2 zwindler-01 (10.0.0.1) 0.084 ms 0.079 ms 0.060 ms
3 * * *
4 zwindler-01 (10.0.0.1) 0.075 ms 0.097 ms 0.081 ms
5 * * *
6 zwindler-01 (10.0.0.1) 0.121 ms 0.137 ms 0.145 ms
7 * * *
[...]

Je montre avec ping, mais c’était pareil avec tous les ports. Et donc, toutes les liveness des composants du control plane crashaient puisque je ne pouvais plus contacter les IPs locales !

En réalité, si on creuse les system requirements de cilium, c’est écrit !

Par défaut, systemd-networkd supprime toutes les routes qu’il ne connaît pas et rentre en conflit direct avec cilium, d’où les problématiques de routage cheloues.

Et c’est exactement le même problème qu’a rencontré Datadog, puisqu’ils utilisent eux aussi Ubuntu 22.04 et cilium. Quand les updates sont passées, ils se sont retrouvés avec tous leurs clusters (worldwide) en vrac.

on start-up of v248, systemd-networkd flushes all IP rules it does not know about. Five months after this initial change, an additional commit introduced in v249 made it possible to opt out of this behavior using a new ManageForeignRoutingPolicyRules setting. Both these changes were backported to systemd v248 and v247.

Kubecon Europe 2021 – Récap’ du jeudi

Thu, 06 May 2021 17:00:00 +0000

Deuxième jour de Kubecon

Hier, je vous faisais un petit résumé de la première journée de Kubecon !

Si vous ne l’avez pas lu, je vous conseille de commencer par là, car je ne vais pas refaire la petite intro avec le contexte.

Aujourd’hui, les talks ont été très condensés et j’ai fait un gros focus réseau / sécu, comme vous pourrez le voir dans la suite de l’article :)

Keynotes

Aujourd’hui, c’était moins dense en termes de nombre de keynotes.

La première keynote a été réalisée par Stephen Augustus, Co-Chair & Head of Open Source chez Cisco. Il a donné quelques nouvelles sur le projet Kubernetes. Le plus gros morceau est le fait qu’il ait été acté que la release cycle allait passer à 15 semaines, ce qui fait 3 releases par an maintenant au lieu de 4. Il a également parlé du fait que les SIGs doivent opt-in les modifications qu’ils veulent inclure dans chaque release et a aussi acté le retour des community meetings.

Les deux talks qui ont suivi étaient sans intérêt, avec un talk sponsorisé de Veeam très très basique sur la sécurité et un talk sur Linkerd qui sauve le monde du COVID-19, que j’ai trouvé plus que déplacé. Je ne me suis pas privé pour le dire sur Twitter d’ailleurs (lol).

Le talk suivant (sponsorisé aussi) rattrapait un peu le niveau, avec un focus sur Knative réalisé par Brenda Chan de chez VMware. Je n’ai pas encore regardé en détail ce qu’on pouvait faire avec knative et ce talk m’a donné envie de creuser le sujet.

La dernière keynote était assez intéressante, avec un REX sur l’intégration des projets cloud native par les équipes de Deutsche Telekom. Après avoir présenté les problèmes auxquels ses équipes ont du faire face, Vuk Gojnic a présenté Das schiff, la solution qu’ils ont implémenté pour déployer des clusters Kubernetes distribués (as a service).

What Do You Mean K8s Doesn’t Have Users? How Do I Manage User Access Then?

La journée a commencé plutôt soft avec un talk assez généraliste sur l’AuthN/AuthZ pr Jussi Nummelin de chez Mirantis. Il a pointé du doigt un vrai problème dans Kubernetes : il n’y a pas de gestion des utilisateurs humains a proprement parlé.

C’est d’ailleurs écrit noir sur blanc dans la documentation officielle de Kubernetes !

It is assumed that a cluster-independent service manages normal users –kubernetes.io/docs/reference/access-authn-authz/authentication/

Tout ce qui est authentification dans Kubernetes passe soit par certificat x509, soit par des tokens de service account soit par des webhook. Tout ceci est donc plutôt réservé aux pods, comptes de services et pas du tout adapté pour des personnes en chair et en os.

Je ne parlerai même pas de l’authentification ‘static token file’ qui est un réel scandale qui ne devrait même pas être utilisée en lab.

La seule option viable est donc bien l’implémentation d’une authentification tierce via un connecter OIDC comme Dex, par exemple.

github.com/dexidp/dex

FalcOMG That’s AWESOME - New Things, Fixed Things, and YOU Panel

Page de la session
[Slides](https://static.sched.com/hosted_files/kccnceu2021/a1/FalcOMG That)

Cette session avait pour but de présenter tout un tas de choses à propos du projet Falco. Pour rappel, Falco est un cloud-native security runtime, initié par Sysdig en 2016. Il utilise eBPF (encore lui) pour détecter voire empêcher les workloads suspects sur vos machines Linux (pas que Kubernetes donc). Les dernières parties qui manquaient ont été données par sysdig en février 2021 (kernel modules + ebpf probe + runtime security).

Après une longue introduction du projet (donné à la CNCF en 2018, accepté en tant qu’Incubating en 2020), deux mainteneurs (Leonardo Grasso et Leonardo Di Donato) ont présentés le processus de release ainsi que la façon dont les artefacts (cf falco open infra) sont générés automatiquement (plus de 3500).

L’équipe de falco est également très impliquée dans l’accès à cette technologie pour tous et recherche activement des traducteurs pour traduire le site et la documentation de falco dans le plus de langues possible. Le processus d’internationalisation a été présenté par Radhika Puthiyetath, technical writer chez sysdig. C’était assez intéressant de voir que le processus mis en place était assez simple et donc accessible au plus grand nombre.

Enfin, l’outil falco sidekick a été présenté par Thomas Labarussias, SRE chez Qonto. Il s’agit d’un démon permettant de collecter l’ensemble des événements transmis par falco (présent sur tous vos nodes kube par exemple) et de les forwarder à une 30aines d’outputs différents en fonction de certaines règles.

On peut ainsi mettre en place de l’alerting ou loguer les événements dans des SIEM ou des moteurs de recherche (Elasticsearch) pour traitements ultérieurs par exemple.

Uncovering a Sophisticated Kubernetes Attack in Real-Time

Troisième talk de la journée sur la sécurité !!! Natália Réka Ivánkó (Security Engineer chez Isovalent) et Jed Salazar (Manager, Platform Security chez Tesla) nous on présenté un panel assez large de risques de sécurité et de vecteurs d’attaques accessibles depuis un cluster Kubernetes.

Après avoir balayé très rapidement les solutions classiques pour réduire les risques (Distroless base images, OPA, pas de shells pour réduire la surface d’attaques, analyse statique des images et analyse au runtime), ils ont cherché à comprendre ce qu’on pouvait faire de plus.

On peut aussi appliquer à la sécurité le mindset « devops » (on parle parfois de devsecops) en considérant que ce qu’on a mis en place en termes de sécurité doit être (1) testé et (2) observé.

Et selon eux, le meilleur outil pour le faire, c’est eBPF. Ils nous ont donc ensuite présenté plusieurs scenarii d’attaques dans lesquels Cilium (eBPF-based Networking, Observability, and Security) était utilisé pour connecter, surveiller et sécuriser les événements sur le réseau de kubernetes.

Le talk était riche et dense et il est extrêmement dur pour moi de le résumer ici. Je serais probablement amené à en reparler sur le blog tant le sujet est pléthorique.

How to Break your Kubernetes Cluster with Networking

J’ai vraiment adoré le talk précédent mais alors celui là c’est le meilleur que j’ai vu depuis le début de cet Kubecon. Thomas Graf, en plus d’être un excellent pédagogue est un excellent speaker. C’est le CTO d’Isovalent (tiens tiens tiens, encore eux !) et il est core member du projet Cilium (encore lui !).

Là aussi, le talk était extrêmement dense et Thomas Graf s’est employé à brosser toutes les façons de casser son cluster Kubernetes avec le réseau. Cela va de bête erreurs DNS à l’utilisation de kube-proxy + iptables en passant par des CRD watchers qui DDoS votre API server et en finissant par des histoires d’horreur de changement de CNI (ou double run) qui cassent tout le réseau du cluster (kids, don’t do this at home).

Une fois de plus, le talk était tellement dense qu’il est difficile de le résumer. Ce qu’on peut en retenir simplement, c’est que le mieux est encore de rester le plus simple possible dans la limite de vos besoins et de ne pas ajouter trop de couches juste parce qu’elles sont « shiny ». (Et je suis évidemment à 100% d’accord).

Oooooooh! Shiny ones!

Les talks que j’aurai voulu voir

Je l’ai déjà dit hier, choisir c’est renoncer.

Si j’avais pu, je serai également allé voir BuildKit CLI for kubectl: A New Way to Build Container Images par curiosité pour l’outil, que je ne connais pas. Mais les dieux du scheduling en ont voulu autrement (c’était pendant la présentation sur Falco).

Fin de la journée

Si on peut appeler ça la fin de la journée puisque le dernier talk a fini vers 15h ;-) mais en vrai c’était tellement intense il y avait pas mal à débriefer.

Maintenant qu’on est au 2/3 de la Kubecon, je vois 2 sujets prioritaires qu’il va falloir que j’investigue sérieusement :

la partie eBPF, avec un vrai choix technique côté CNI (test de Cilium à faire absolument) et évaluation des outils de sécus basés sur des programmes BPF
la partie CI/CD avec flux, flagger, litmus (mais plutôt réservée pour mes copains ingés CI/CD, je ne ferai que suivre le mouvement)

On verra si la journée de demain changera un peu ces priorité ou pas (probablement que non).

Et en attendant, have fun :)

Cilium on Zwindler's Reflection

Test de CKE, le Kubernetes managé chez Clever Cloud (partie 1)

La suite de ma saga avec Clever Cloud

CKE c’est quoi exactement ?

Activation : c’est un peu caché

Création d’un cluster

Les 3 topologies : Essential, Business, Enterprise

Un mot sur la tarification

Récupérer le kubeconfig

Anatomie du cluster

Les NodeGroups

Combien de temps pour booter ?

Réseau, services, sécurité

Stockage (CSI)

Un vrai déploiement : GroROTI

Bugs rencontrés (alpha / bêta oblige)

Conclusion (partie 1)

Flannel et NetworkPolicies : comment ajouter le support avec Cilium en CNI chaining

Flannel, flannel, flannel…

On vérifie pour être bien sûr

Les alternatives pour ajouter le support

Installer Cilium en mode CNI chaining

Prérequis

Récupérer la configuration CNI de flannel

Créer le ConfigMap de chaining

Installer Cilium via Helm

Vérification

Tester les NetworkPolicies

Bonus : Hubble, l’observabilité réseau

Combien ça coûte en ressources ?

Conclusion

Un nouveau champ `log` pour les network policies Cilium : une idée de use case

TL;DR

Le problème : monitor all the things (mais pas trop)

Et donc, ce champ log des network policies de Cilium 1.18 ?

Le plan : bloquer la télémétrie élégamment

Retour à la réalité

Pourquoi c’est un problème, déjà ?

Solutions de contournement potentielles

Trouver un moyen de désactiver la télémétrie directement dans l’app

Blocage basé sur le DNS

Utiliser egressDeny basé sur les IPs (avec un overhead de maintenance)

OK, mais imaginons qu’il n’y ait pas de trafic légitime. Peut-on utiliser la fonctionnalité pour ajouter un log sur le trafic droppé ?

Conclusion

Références

J'ai testé pour vous : k8e (Kubernetes Easy Engine)

Tu ne faisais pas un livre sur Kubernetes, toi ?

Mais revenons à k8e !

Prérequis

Installation du premier nœud

Ajout des nœuds supplémentaires

Vérification de Cilium

Avantages et Inconvénients

Conclusion

Migration du routage de cilium de iptables vers eBPF... à chaud !

Contexte

Pourquoi ça ?

Comment en est on arrivé là ?

Problème

Vérifier la connectivité

Changer la configuration d’un node

Ca fonctionne, mais est ce que c’est mieux en termes de consommation de ressources ?

Bonus

k3s et cilium rapide et facile

Contexte

Prérequis

Installation de k3s

Ajout d’un second node

CNI plugin + ingressController

Conclusion

Kubeadm, Ubuntu 22.04 et cilium - mes petites galères récentes

Kubernetes, le retour de la vengeance

cilium et kernel Ubuntu Minimal

containerd et cgroups systemd

kubeadm et plusieurs interfaces

Et alors, kubelet et plusieurs interfaces ?

Ubuntu 22.04 et ManageForeignRoutes

Kubecon Europe 2021 – Récap’ du jeudi

Deuxième jour de Kubecon

Keynotes

`kubeadm` et plusieurs interfaces

Et alors, `kubelet` et plusieurs interfaces ?