Flannel on Zwindler's Reflection

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 :)

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.

Mettre à jour le CA de Kubernetes, « the hard way »

Mon, 15 Feb 2021 07:56:12 +0000

Les CA (Certificate Authority), ça expire !

Dans cet article, je vais vous ferai un petit retour d’expérience d’un souci un peu tricky que j’ai rencontré il y a quelques mois.

Cela concerne des clusters Kubernetes, la Certificate Authority (CA), un Vault (Hashicorp) et le tout dans un contexte opérationnel, en production, avec des millions d’utilisateurs.

Attachez vos ceintures, ça risque de secouer :)

The « automated » hard way

J’ai récemment changé de boite.

Dans ce nouveau contexte technique, Kubernetes est en production depuis plusieurs années. Aujourd’hui, il existe de très nombreuses options pour déployer un cluster Kubernetes (j’en ai déjà abondamment parlé ici, là, là, là ou encore là). Chaque a ses avantages et ses inconvénients, qui dépendent de la topologie du cluster ainsi que de vos besoins (vous êtes plutôt cloud, baremetal, edge,…).

Plot twist : Vous l’avez peut-être deviné, le titre de l’article est une référence au célèbre “Kubernetes the hard way” de Kelsey Hightower.

La raison pour laquelle j’ai choisi ce titre est que, en 2017, les clusters Kubernetes de l’entreprise dans laquelle je travaille ont été déployés avec des playbooks Ansible écrits à la main. Et d’un point de vue extérieur, ça ressemble un peu à automatiser « Kubernetes the hard way » avec Ansible 😉.

Aujourd’hui, vous (je) le feriez pas comme ça. Mais il faut se replacer dans le contexte. Au moment où le cluster a été déployé, les options étaient bien plus limitées qu’aujourd’hui en termes de déploiements. Particulièrement pour les installations de type baremetal. kubeadm par exemple, maintenant GA, affichait encore des gros messages d’avertissement « NOT PRODUCTION READY« .

It’s the final countdown

Toutes nos applications ne sont pas hébergées dans Kubernetes, mais une portion relativement significative d’entre elles y sont. Suffisamment en tout cas pour que si le cluster Kubernetes était down, nos utilisateurs finaux finiraient pas d’en rendre compte. Et c’est là où notre histoire commence :

L’autorité de certification de notre Kubernetes va expirer dans quelques mois, et avec elle, toute la chaîne de certifications

Un zwindler un peu inquiet Pour illustrer un peu mon propos, imaginez qu’à la place de ces indicateurs verts rassurants, il y avait du orange (rouge ?) partout.

Comme toutes les communications à l’intérieur du cluster Kubernetes sont chiffrées et authentifiées avec ce CA, le laisser expirer serait une très mauvaise idée. En gros, on perdrait le contrôle du cluster et de toutes les applications hébergées dedans 😱. Si vous faites des petites recherches sur Internet, vous trouverez peut-être des postmortem de ce genre de souci (je vous en mets un en fin d’article).

Donc, j’avais pour mission de trouver un moment de renouveler le certificat, sans interruption pour les utilisateurs de notre service, et AVANT la date d’expiration.

Pourquoi est ce que c’est un problème ?

Renouveler un certificat, ce n’est pas la mer à boire. Cependant, ici, comme le CA est responsable de toutes les communications des composants internes de Kubernetes, c’est un peu moins trivial.

Pour rendre les choses encore plus complexe, la documentation officielle est incomplète (et même fausse, j’ai fait une PR et il faudrait probablement en faire d’autre) et les documentations externes sont parcellaires.

Il y a plein de raisons pour ça. La première est que beaucoup d’organisations préfèrent utiliser Kubernetes via une offre managée chez leur cloud provider préféré, qui leur cache la complexité de la gestion du cluster Kubernetes pour eux. Dans ce cas-là, les clouds providers sont ceux qui s’inquiètent de ce genre de problématiques (mais s’y inquiètent ils ?).

Parmi les utilisateurs restants (on-prem donc), la plupart utilisent les outils comme Kubespray ou kubeadm, qui contiennent dans une certaine mesures des outils pour faciliter les procédures de renouvellement de certificats (mais qui n’étaient pas disponibles au moment où les clusters ont été déployés).

Enfin, pour les rares damnés qui restent, régénérer un CA à la main n’est pas quelque chose qu’on fait souvent. Les CAs sont généralement générés pour des durées allant de 3 à 10 ans (même si les bonnes pratiques préfèrent des durées courtes). Si on compare cette durée moyenne par rapport à l’adoption relativement récente de Kubernetes (un projet vieux de seulement 6 ans), on peut supposer que beaucoup de CA n’ont pas encore eu l’occasion d’expirer ;-).

Et maintenant ? Que vais-je faire ?

On doit donc trouver un moyen de modifier le CA de Kubernetes à la volée sans impact utilisateur. Heureusement, avec un peu de planification, ça devrait être possible pour la grande majorité des workloads.

La première chose à savoir est que, même si le cluster ne répond plus pendant qu’on renouvelle les certificats, les applications qui sont dans Kubernetes (les Pods) qui sont déjà déployés sont toujours opérationnels. Cependant, les nouveaux Jobs ne seront pas démarrés, les Pods en erreur ou les applications sur des nœuds HS ne seront pas redémarrés sur des nœuds en bonne santé.

La seconde chose à savoir est que toutes vos applications (dans les Pods) sont exécutées avec un contexte de sécurité qui dépend d’un ServiceAccount. Si vous n’en spécifiez pas dans le manifeste de l’application, vous hériterez par défaut de celui du Namespace (d’ailleurs, pour information, ça peut être un problème de sécurité).

Là où les choses se compliquent, c’est que le token qui authentifie ce ServiceAccount est généré par le Kubernetes Controller Manager. Et pas de bol, quand vous générez le CA, tous les tokens sont bons à jeter à la poubelle…

Donc… Le but du jeu va être de ne redémarrer que ce qui est nécessaire, dans le bon ordre, puis de régénérer tous les tokens. Et tout ça, suffisamment vite pour qu’aucune application ne plante ou qu’un Node tombe en panne pendant l’opération.

Easy peasy

MAIS !

Car bien sûr, il y a un mais car sinon ça serait trop facile :

Les applications qui ont besoin de communiquer avec l’API de Kubernetes seront perturbées dans leur fonctionnement tant qu’elles n’auront pas été redémarrées (une fois leur token régénéré). Cela inclus probablement vos applications de supervision (comme Prometheus) qui scrap l’API. Vous serez « aveugles » pendant quelques minutes.
Les applications qui maintiennent des connexions longues (typiquement des WebSockets par exemple) seront probablement coupées à un moment donné car vous devrez probablement redémarrer vos IngressControllers, qui ont souvent besoin d’accéder à l’API server (cf point précédent). Si vous avez implémenté un mécanisme de retry dans vos applications, ça devrait aller.
Toutes les applications devront à un moment donné être redémarrées pour obtenir leur nouveau token. Si vos applications n’ont pas de replicas (1 seul Pod), il y aura nécessairement une coupure. Pour éviter ça (et c’est valable pour tous les contextes, pas seulement quand on renouvelle des certificats) essayez de toujours avoir des replicas pour toutes vos applications. Dans le cas présent, si ces applications n’ont pas besoins d’accéder à l’API de Kubernetes, vous pouvez reporter le redémarrage à plus tard.

Maintenant vous savez tout, allons y 😊 !

Okééééé. On renouvelle un CA dans Kubernetes, en prod, sans interruption (visible)

Avant de faire quoique ce soit qu’on pourrait regretter, le mieux est quand même d’être certain qu’on est capable de revenir à l’état initial au cas où on devrait rollback. Cela signifie des sauvegardes et surtout tester les procédures de restauration !

Sauvegardez tous les certificats que vous utilisez actuellement (probablement dans /etc/kubernetes, mais aussi dans /var/lib/kubelet) ainsi que ceux d’etcd.

CURDATE=`date +"%y%m%d%H%M"`
tar czf /tmp/pkibackup.${CURDATE}.tgz /var/lib/kubelet/pki/kubelet.* /etc/kubernetes

Vous allez probablement vouloir aussi sauvegarder tous vos tokens actuels (dans vos ServiceAccounts). Je rappelle que ces tokens sont générés par le Kubernetes Controller Manager et qu’ils sont utilisés par les Pods pour communiquer avec l’API server de Kubernetes (mais on y reviendra).

for namespace in $(kubectl get ns --no-headers | awk '{print $1}'); do
for token in $(kubectl get secrets --namespace "$namespace" --field-selector type=kubernetes.io/service-account-token -o name); do
kubectl get $token --namespace "$namespace" -o yaml >> /tmp/token_dump.${CURDATE}.yaml
done
done

Et enfin, faire une sauvegarde complète de l’état du cluster via un dump de la base etcd est probablement une bonne idée aussi (if all else fail comme on dit).

ETCDCTL_API=3 etcdctl --cacert=yourca.pem --cert=etcd.pem --key=etcd-key.pem --endpoints 127.0.0.1:2379 snapshot save /tmp/etcd.backup.$(date +'\%Y\%m\%d_\%H\%M\%S')

Hashicorp Vault ?

Historiquement, les certificats avaient été générés à l’aide de la commande openssl, en se basant sur les recommandations officielles de la documentation de Kubernetes.

Ça fonctionne parfaitement bien (la documentation met plutôt en avant l’outil cfssl aujourd’hui, mais c’est le même principe). Cependant, cette façon de faire n’est ni efficace, ni vraiment safe (la clé privée du CA est stockée sur disque) et est également un facteur d’erreur humaine.

Parallèlement à ça, nous utilisons depuis plusieurs années l’outil Vault de Hashicorp pour stocker nos secrets. Nous avons donc profité de l’opportunité offerte par ce renouvellement pour utiliser le module « pki » d’Hashicorp Vault.

Dans cet article, je ne rentrerai pas dans les détails de Vault et de son moteur PKI (j’ai fait quelques articles sur les produits Hashicorp en revanche), mais grosso modo l’idée est :

créer un nouveau « secret engine »
générer un CA qui sera gardé au chaud dans Vault
configurer un rôle permettant de paramétrer les futurs certificats pour correspondre aux recommandations de Kubernetes
générer les certificats et les déposer sur les serveurs

vault policy write pki-policy pki-policy.hcl
vault secrets enable -path=pki_k8s pki
vault secrets tune -max-lease-ttl=43800h pki_k8s
vault write pki_k8s/root/generate/internal common_name="kubernetes-ca" ttl=43800h
vault write pki_k8s/roles/kubernetes allowed_domains="kubernetes, default, svc, example.org" allow_subdomains=true allow_bare_domains=true max_ttl="43800h"

Certs for everyone

Pour déposer de manière sécurisée et automatisée les certificats, on utilise un autre outil d’Hashicorp (décidémment) qui s’appelle consul-template. Ce binaire va nous permettre de générer des fichiers à partir de fichiers templates et des objets qu’on a stockés dans Vault (et Consul).

Là encore, sans rentrer dans les détails, un template va ressembler à ça (je vous prends l’exemple du certificat pour l’API server) :

{{- /* apiserver-cert.tpl */ -}}
{{ with secret "pki_k8s/issue/kubernetes" "common_name=kube-apiserver" "alt_names=kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.kubernetes, example.org" "ip_sans=100.64.0.1, IP.ADDRESS.MASTER.1, IP.ADDRESS.MASTER.2, IP.ADDRESS.MASTER.3" "exclude_cn_from_sans=true" "ttl=17520h" }}
{{ .Data.certificate }}{{ end}}

Le fichier de configuration de consul-template ressemblera lui à ça :

template {
source = "/etc/consul.d/templates/ca.pem.tpl"
destination = "/etc/kubernetes/pki/ca.pem"
}
template {
source = "/etc/consul.d/templates/admin-cert.tpl"
destination = "/etc/kubernetes/pki/admin.pem"
}
template {
blah blah blah
...

On lancera la commande suivante, qui remplacera d’un coup tous les anciens certificats par de nouveaux qui respectent les besoins de notre cluster et qui sont validé par notre nouveau CA :

consul-template -config /etc/consul.d/templates/consul-template-config-master.hcl

Petit bémol, cette solution ne marche pas pour tous les certificats. A chaque appel de consul-template, un nouveau certificat est produit. Pour tous les certificats individuels, comme les certificats pour chaque node, cela fonctionne très bien. Cependant, ce n’est pas vrai pour certains, par exemple pour la clé privée de l’API server qui nécessite d’être la même pour tous les serveurs. Nous avons donc fait une exception dans notre processus : tous les certificats nécessaires pour les masters ont été générés pour un seul serveur puis copiés sur les autres masters.

Ground control to Major Tom

Tous les certificats sont maintenant régénérés. Mais pour autant, tous les composants de Kubernetes ne supportent pas le renouvellement de certificats à chaud. On va devoir tout redémarrer (et dans le bon ordre, en plus…).

La première urgence est de redémarrer les serveurs etcd, tous en même temps. Une fois que c’est fait, la course commence car l’API server ne sera plus capable d’interroger etcd pour connaître (et mettre à jour) l’état du cluster. Nous avons perdu tout contrôle sur notre cluster 😱.

systemctl restart etcd

A partir de maintenant, toutes les commandes kubectl vont échouer. Toutes les fonctionnalités de Kubernetes (autoscaling, scheduling des pods, etc) vont arrêter de fonctionner.

Cela va heureusement facilement se régler, simplement en redémarrant l’api-server manuellement (soit via le service systemd soit, si c’est un Pod, envoyer un SIGKILL).

On peut ensuite s’attaquer au reste des composants du control plane qui nécessitent etcd ou l’API server.

Je vous conseille de commencer par le CNI (comme flannel par exemple), puis de supprimer la paire de certificats de vos kubelet (ils seront régénérés automatiquement) avant de les redémarrer, sur tous les Nodes.

rm /var/lib/kubelet/pki/kubelet.{crt,key}
systemctl restart kubelet

Et pour finir, on peut redémarrer tous les composants du control plane restant avec des commandes kubectl depuis un master (ça devrait remarcher).

/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-apiserver
/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-controller-manager
/usr/bin/kubectl --namespace kube-system delete pods --selector component=kube-scheduler

Notre control plane est de nouveau opérationnel 🎉.

The tokens sleep tonight

Maintenant que notre control plane fonctionne avec nos nouveaux certificats, si vous regardez ce qui se passe dans les logs de l’API server, vous remarquerez qu’il y aura beaucoup de messages pas super explicites à propos de tokens pourris.

Si vous vous souvenez bien, on avait dit qu’il allait falloir rafraîchir tous nos tokens, qui sont tous invalidés depuis qu’on a redémarré l’API server. Cette partie est heureusement gérée par le Kubernetes Controller Manager mais il va falloir lui donner un petit coup de pouce : on va supprimer les tokens contenus dans les Secrets de type service-account-token relatifs à chaque ServiceAccount grâce à cette boucle :

for ns in `kubectl get ns | grep Active | awk '{ print $1 }'`; do
for token in `/usr/bin/kubectl get secrets --namespace $ns --field-selector type=kubernetes.io/service-account-token -o name`; do
/usr/bin/kubectl get $token --namespace $ns -o yaml | /bin/sed '/token: /d' | /usr/bin/kubectl replace -f - ;
done
done

Et nous pouvons donc commencer à redémarrer nos applications.

Now, the applications

Je vous conseille de redémarrer coredns en premier (ou kubedns, selon votre installation). Sans ça, la résolution de nom à l’intérieur de votre cluster Kubernetes va commencer à échouer (et ça, ça craint).

/usr/bin/kubectl --namespace kube-system rollout restart deployment.apps/coredns

Mais vous devriez aussi redémarrer tous les applications qui vous semblent importantes pour le fonctionnement du cluster, comme notamment (mais pas uniquement) :

kube-proxy
les Ingress controllers
prometheus
toute autre application de monitoring

Enfin, redémarrer toutes les applications qui nécessitent un accès à l’API server pour fonctionner correctement. Pour les autres, vous avez le temps de le faire plus tard.

Wrapping this up

Le CA de votre cluster Kubernetes a été renouvelé. Vous devriez pouvoir de nouveau dormir tranquilles pour quelques mois 😊.

Renouveler vos CA n’est pas une tâche triviale dans Kubernetes, mais j’espère vous avoir montré que ce n’est pas impossible et que dans la plupart des cas et en le planifiant bien, il est possible de le faire sans interruption.

Toutes les tâches décrites dans cet article ont été automatisées dans des playbooks Ansible, que nous avons joué sur des environnements moins critiques autant de fois que nécessaire jusqu’à ce que nous ayons été sûr de leur exécution.

En décembre dernier, l’intervention a été planifiée sur les clusters de production. Toute la procédure a été jouée en quelques minutes, aucun impact utilisateur n’a été détecté et les services qui nécessitaient un accès à l’API n’ont pas été perturbées plus que prévu.

Sources

Github — Kelsey Hightower’s “Kubernetes the hard way”

Postmortems d’expiration de certificats CA

Vadosware — 2019–12 K8s certificate expiration outage

Construire et détruire des clusters Kubernetes à la volée

Youtube — Continuously Deliver your Kubernetes Infrastructure — Mikkel Larsen, Zalando SE

Documentation officielle de Kubernetes a propos des certificats

Hashicorp Vault

Hashicorp — Build Your Own Certificate Authority (CA) (lien mort)
Hashicorp Vault — PKI Secrets Engine (API)
Digital Ocean — Using Vault as a Certificate Authority for Kubernetes
Youtube — Streamline Certificate Management

Installer un cluster Kubernetes sur des VMs CentOS 7

Wed, 07 Jun 2017 12:00:53 +0000

Kubernetes, c’est quoi ça ?

Dans cet article, je vais vous guider pour installer pas à pas un cluster Kubernetes sur des serveurs CentOS/RHEL 7. Attention cet article est un gros morceau !

Pour ceux qui ne connaissent pas Kubernetes, il faut savoir que c’est un des leaders dans le domaine des orchestrateurs de containers Docker ou Rkt.

Un bel empilage de couches, pour au final exécuter des applications dans des containers LXC (ou Windows)

Pour ce qui est de la genèse de Kubernetes, c’est un outil dont le code provient de Borg d’un outil maison de chez Google. Au bout de 10 ans d’utilisation, quand les containers Linux ont commencés à percer, le code source a été légué en 2015 à la CNCF (Cloud Native Computing Foundation). L’outil est donc maintenant open source.

Sa couverture fonctionnelle est (pour l’instant) supérieure à celle de Docker Swarm, notamment grâce à :

une gestion de la multitenancy via les namespaces
une gestion des secrets (bien que limitée)
une gestion des replicas pour un même container, avec scale-up/down
une gestion native du loadbalancing
une gestion des rolling upgrades
…

Un article sympa d’Octo résume pas mal l’écosystème et la guerre qui fait rage dans ce domaine.

Prérequis

Avant de commencer le tutoriel, il faut déjà avoir une bonne connaissance de l’écosystème de la containerisation (sujet sur lequel j’ai écris quelques articles mais qui est bien plus vaste que ça!).
Il faut savoir que Kubernetes est aussi un outil assez complet mais complexe, avec ses propres concepts et sa terminologie associée. Je vous conseille d’abord de vous familiariser avec ces concepts sur un des tutos de Digital Ocean (ils sont souvent très biens fait).

Pour ceux qui sont extrêmement pressés, on peut dire brièvement que, dans la terminologie Kubernetes :

un Node est un serveur qui exécute les applications
le Kubelet est un service (au sens démon) présent sur tous les nodes qui leur permet de discuter et de recevoir les ordres
un Pod, généralement décrit comme « la plus petite unité de traitement de Kubernetes ». Il est composé d’un ou plusieurs containers et on le caractérise généralement comme « une application »
un Service représente un répartiteur de charge qui est conscient de la présence d’un ensemble de containers (backend) et qui permet de rediriger les flux entrants vers eux
un Deployment est un ensemble de sous éléments (comme les Pods et les Services, mais aussi d’autres que je ne présentent pas) qui permet de déployer une application avec toutes ses caractéristiques (volumes, secrets) et ses contraintes (nombres de réplicas)
toutes les interactions avec Kubernetes se font avec une seule commande : kubeadm

Source : kubernetes.io

Solutions de déploiement

D’abord, la première chose à dire est qu’il existe de nombreuses manières de déployer Kubernetes qui a donc créé un page dédiée à centraliser l’ensemble des solutions possibles. Et elle est longue !

Ceci n’est qu’une fraction des solutions actuellement proposées sur le site. Ça ne rentre pas sur mon écran 29 pouces…

Dans mon cas, je suis parti du plus simple pour moi, avec les ressources que j’ai à disposition, c’est à dire 2 machines virtuelles sous CentOS 7.3 :

controlplane01 : 192.168.100.100
worker01 : 192.168.100.101

Pour autant, les solutions avec Vagrant ou sur des clouds publics sont aussi des solutions valables pour commencer si vous maitrisez ces outils. Je vous laisserai regarder la documentation associée si ça vous intéresse.

A noter, en fonction de la solutions choisie, il existe aussi des considérations réseaux à avoir, et elles sont documentées ici.

Le plus simple : Minikube

Je ne vais pas m’attarder sur cette méthode mais celle qui me semble vraiment la plus simple si vous voulez commencer rapidement à jouer avec Kubernetes est d’utiliser minikube. Elle utilise de la virtualisation pour déployer l’environnement Kubernetes de manière automatisée sur votre poste et ça fonctionne très bien.

minikube start
Starting local Kubernetes cluster...
Running pre-create checks...
Creating machine...
Starting local Kubernetes cluster...

La solution de l’article : Utiliser Kubeadm

On ne va pas se le cacher, installer Kubernetes à la main est complexe. Tellement complexe qu’il existe de nombreuses méthodes clé en main pour automatiser le processus.

La solution que je vous présente ici est un script qui package l’installation des différents composants de Kubernetes. Ces composants sont en fait containerisés pour faciliter leur déploiement.

La documentation officielle de cette méthode est disponible à l’adresse suivante.

Configuration des dépôts

Sur les deux nœuds

A noter : Dans le cas où vous ne disposeriez pas d’un serveur DNS en propre, le plus simple est de configurer sur vos deux machines leurs noms complets dans le fichier « hosts ». Cela vous évitera des bugs et effets de bords.

echo "192.168.100.100 controlplane01.example.org
192.168.100.101 worker01.example.org" >> /etc/hosts

Configurer les repositories officiels :

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://yum.kubernetes.io/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
#yum install -y yum-utils
#yum-config-manager \
# --add-repo \
# https://download.docker.com/linux/centos/docker-ce.repo

J’ai volontairement commenté l’ajout du dépôt de Docker car à date, la dernière version de Kubernetes n’a pas encore complètement validé les dernières versions de Docker (celles depuis le grand renommage, qui sont sur le modèle YY.MM comme la 17.03). C’est pourquoi j’utilise dans ce tutoriel la version packagée par mon OS, la 1.12.6.

SELinux

A l’heure actuelle, SELinux est mal supporté par kubelet, le client de Kubernetes présent sur chaque machine. Il est donc malheureusement nécessaire de désactiver cette sécurité pour pouvoir utiliser Kubernetes, pour l’instant.

Disabling SELinux by running setenforce 0 is required in order to allow containers to access the host filesystem, which is required by pod networks for example. You have to do this until SELinux support is improved in the kubelet.

Il se peut aussi que le firewall pose des problèmes s’il est activé et mal configuré

firewalld is active, please ensure ports [6443 10250] are open or your cluster may not function correctly

Dans le cadre d’un PoC, on pourra éventuellement se permettre de désactiver le firewall et SELinux si on estime que l’environnement est suffisamment sécurisé. C’est bien entendu hors de question pour tout autre environnement non éphémère !

setenforce 0
vi /etc/selinux/config
[...]
SELINUX=disabled
systemctl disable firewalld
systemctl stop firewalld

Installation des packages

Comme dit plus haut, j’installe la version Docker de l’OS et non la dernière version. Dans les versions suivantes, Kubernetes aura probablement rattrapé ce retard (si ce n’est pas déjà le cas). On termine par démarrer Docker puis le démon kubelet.

yum install -y docker kubelet kubeadm kubectl kubernetes-cni
#yum install -y docker-ce kubelet kubeadm kubectl kubernetes-cni
systemctl enable docker && systemctl start docker
systemctl enable kubelet && systemctl start kubelet

Initialisation du cluster

Sur le controlplane

Maintenant que les prérequis sont installés, on peut démarrer Kubernetes. L’ensemble des commandes de Kubernetes utilise le binaire kubeadm et la première à utiliser est kubeadm init.

Attention cependant, la commande kubeadm init peut nécessiter des arguments complémentaires en fonction du fournisseur de réseau qui sera choisi.

kubeadm init
#ou
kubeadm init --pod-network-cidr 10.244.0.0/16 #Si on utilise flannel
#ou
kubeadm init --pod-network-cidr=192.168.0.0/16 #Si on utilise Calico

Si vous avez un proxy chez vous, n’hésitez pas d’exporter la variable http_proxy et à configurer docker pour l’utiliser (voir ce thread sur stackoverflow).

export http_proxy=http://@IP_proxy.zwindler.fr:8080/
export no_proxy=localhost,127.0.0.0,[@IP_control_plane]
mkdir /etc/systemd/system/docker.service.d
cat > /etc/systemd/system/docker.service.d/http-proxy.conf << EOF
[Service]
Environment="HTTP_PROXY=http://@IP_proxy.zwindler.fr:8080/"
EOF
systemctl daemon-reload
systemctl restart docker

On termine l’initialisation côté serveur controlplane avec les commandes suivantes (indiquées dans le retour donné par le kubeadm init) :

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

A noter, en toute fin de retour, kubeadm nous donne la ligne de commande nécessaire pour ajouter des nœuds supplémentaires au cluster via un token. Copiez et conservez cette partie pour plus tard. NE PAS LE FAIRE MAINTENANT !

#You can now join any number of machines by running the following on each node
#as root:
# kubeadm join --token <token> <ip_controlplane>:6443

A partir de là, le cluster va s’initialiser et déployer tous les containers nécessaires. Cela peut prendre un certain temps et certains containers peuvent passer par un état Fail, mais au final tout doit être dans l’état « Running », à l’exception des kube-dns*.

kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system etcd-controlplane01.example.org 1/1 Running 0 13m
kube-system kube-apiserver-controlplane01.example.org 1/1 Running 0 12m
kube-system kube-controller-manager-controlplane01.example.org 1/1 Running 0 13m
kube-system kube-dns-3913472980-gnt72 0/3 Pending 0 13m
kube-system kube-proxy-4m1nd 1/1 Running 0 13m
kube-system kube-scheduler-controlplane01.example.org 1/1 Running 0 13m

Vérifiez la présence du controlplane avec la commande :

kubectl get nodes
NAME STATUS AGE VERSION
controlplane01.example.org NotReady 12m v1.6.2

A noter : Le Nœud restera à NotReady tant que les containers « kube-dns- » ne seront pas démarrés. Or, les « kube-dns- » ne démarreront pas tant que la configuration des « Network Pods » n’est pas faite (on va voir ça plus loin), ce qui est donc normal pour l’instant.

« waiting for the control plane to become ready » qui ne rend jamais la main

En cas de blocage sur l’étape « [apiclient] Created API client, waiting for the control plane to become ready« , vérifier les logs dans /var/log/messages.

Apr 26 16:27:58 controlplane01 kubelet: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
Apr 26 16:27:58 controlplane01 systemd: kubelet.service: main process exited, code=exited, status=1/FAILURE
Apr 26 16:27:58 controlplane01 systemd: Unit kubelet.service entered failed state.
Apr 26 16:27:58 controlplane01 systemd: kubelet.service failed.

Ceci est du à un bug de kubeadm sur CentOS.

Il n’y a pas vraiment de solution à partir de là. On ne peut pas utiliser « kubeadm reset » pour désinstaller proprement car cela supprime le fichier 10-kubeadm.conf, celui qui doit être corrigé/modifié.
La seule possibilité d’est d’interrompre le processus « kubeadm init », de modifier le 10-kubeadm.conf puis de recommencer.

[CTRL-C]
sed -i 's#Environment="KUBELET_KUBECONFIG_ARGS=-.*#Environment="KUBELET_KUBECONFIG_ARGS=--kubeconfig=/etc/kubernetes/kubelet.conf --require-kubeconfig=true --cgroup-driver=systemd"#g' /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
systemctl daemon-reload
systemctl restart kubelet
#Puis relancer
kubeadm init #--pod-network-cidr 10.244.0.0/16
[kubeadm] WARNING: kubeadm is in beta, please do not use it for production clusters.
[init] Using Kubernetes version: v1.6.2
[init] Using Authorization mode: RBAC
[preflight] Running pre-flight checks
[preflight] WARNING: docker version is greater than the most recently validated version. Docker version: 17.03.1-ce. Max validated version: 1.12
[preflight] Some fatal errors occurred:
/etc/kubernetes/manifests is not empty
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
kubeadm init --skip-preflight-checks
#Là, ça devrait fonctionner

Taint node

Par défaut, Kubernetes n’utilise pas le controlplane pour faire tourner des pods. Si vous voulez changer ce comportement, on peut le faire avec la commande suivante :

kubectl taint nodes --all node-role.kubernetes.io/controlplane-

Configuration des Network Pods

La première chose à configurer sur le cluster est le « Network Pod ». On a le choix entre un certain nombre de modules, dont la liste est disponible sur cette documentation.

Flannel

La configuration la plus couramment utilisée semble être flannel (de CoreOS), donc le fichier de configuration yaml est disponible sur Github

Sur le controlplane

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
serviceaccount "flannel" created
configmap "kube-flannel-cfg" created
daemonset "kube-flannel-ds" created

Calico

On peut aussi essayer Calico. Personnellement j’ai eu des disfonctionnement avec la version Flannel et donc j’utilise Calico.

Sur le controlplane

kubectl apply -f http://docs.projectcalico.org/v2.4/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml
configmap "calico-config" created
daemonset "calico-etcd" created
service "calico-etcd" created
daemonset "calico-node" created
deployment "calico-policy-controller" created
clusterrolebinding "calico-cni-plugin" created
clusterrole "calico-cni-plugin" created
serviceaccount "calico-cni-plugin" created
clusterrolebinding "calico-policy-controller" created
clusterrole "calico-policy-controller" created
serviceaccount "calico-policy-controller" created

Les pods pour le réseaux se créent. Vérifiez que tout a bien fonctionné avant d’ajouter des nœuds dans le cluster :

kubectl get pods --all-namespaces

Ajout de nœuds supplémentaires

A partir de cette étape, le cluster Kubernetes fonctionne réellement, tous les composants sont opérationnels, à ceci près que c’est un cluster avec seulement une machine. On peut donc maintenant intégrer les machines supplémentaires.

Récupérez la commande avec le token que vous avez conservé précédemment (lors du kubeadm init) et exécutez la sur le nœud « worker ».

Sur le worker

kubeadm join --token <token> 192.168.100.100:6443

Si on obtient l’erreur suivante, il faut ajouter 2 lignes dans le fichier « sysctl.conf » et appliquer la modification.

[preflight] Some fatal errors occurred:
/proc/sys/net/bridge/bridge-nf-call-iptables contents are not set to 1
[preflight] If you know what you are doing, you can skip pre-flight checks with `--skip-preflight-checks`
echo "net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
sysctl -p

Sur le controlplane

Vérifier la présence du controlplane et de son worker avec la commande kubectl :

kubectl get nodes
NAME STATUS AGE VERSION
worker01.example.org NotReady 1m v1.6.2
controlplane01.example.org Ready 33m v1.6.2

Déployer la console web

Bravo, votre cluster Kubernetes fonctionne !

Un bon moyen de débuter est d’installer la WebUI de Kubernetes. Comme tout le reste sur Kubernetes, elle se déploie simplement avec un fichier YAML. La documentation officielle est disponible à cette adresse.

# Add kubernetes-dashboard repository
helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
# Deploy a Helm Release named "kubernetes-dashboard" using the kubernetes-dashboard chart
helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard

La console est déployée. Elle est accessible de 2 manières.

kubectl proxy

Cette sous commande kubectl permet de faire un tunnel entre le poste depuis lequel la commande est lancée et le serveur exécutant les pods. Cette commande est pratique pour tester les connexions à des pods sans avoir à travailler sur le serveur (depuis son poste par exemple).

Le Dashboard deviendra accessible via l’URL :

http://localhost:8001/ui

Cependant, dans ce cas là, l’interface ne sera disponible que depuis votre poste, ce qui peut ne pas vous convenir.

Via le serveur controlplane

On peut également accéder à la console directement depuis l’URL /ui, qui pointe sur le serveur « controlplane » (controlplane01 dans notre cas).

https://@ip_controlplane]/ui

La console demandera un login/mdp que l’on peut retrouver avec kubectl

kubectl config view

Le mot de la fin

Ça y est, vous savez tout.

Vous êtes maintenant en mesure de déployer vos premières applications avec Kubernetes, et vous amuser à Scale-up & scale-down, faire des rolling upgrades, tester la haute disponibilité et la répartition de charge !

Have fun :)