Kubeadm on Zwindler's Reflection

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

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

Il bouge encore

Depuis la sortie de l’interface web du projet début février, le projet a continué à évoluer. Ajout de solutions manquantes, petites améliorations de l’UI, contributions externes, optimisations de performances… Bref, un bon petit mois bien rempli pour ce gros side project que j’aimerais faire grossir.

101-ways-to-deploy-kubernetes

Note : si vous n’avez pas suivi les épisodes précédents :

93 façons de déployer Kubernetes — le Google Sheet original
101 façons de déployer Kubernetes (v2) — passage sur GitHub
Une nouvelle UI pour explorer les 118+ solutions — l’appli Astro + Tailwind

7 nouvelles solutions

Le catalogue est passé de 118 à 125 solutions. Voici les ajouts depuis le dernier article :

Xen Orchestra - ajouté pendant un stream de Cuistops => Déploiement de clusters Kubernetes (MicroK8s) via les “recettes” de Xen Orchestra, la plateforme de management de Vates. Catégorie ManagementPlatform.
Charmed Kubernetes - suite à un commentaire sur LinkedIn, j’ai remplacé l’entrée “Juju” par Charmed Kubernetes, qui est le vrai nom du produit Canonical pour déployer Kubernetes via Juju.
kubeaver - découvert en scrollant bluesky sans but => un installateur Kubernetes offline/online avec une GUI, basé sur Kubespray et Ansible. Certifié CNCF conformance (pour ce que ça vaut…).
talos-bootstrap - script interactif de Cozystack pour bootstrapper des clusters Kubernetes sur Talos OS.
boot-to-talos - Outil de Cozystack (encore) qui convertit n’importe quel OS existant en Talos Linux, complètement depuis le userspace. Partiellement utilisé par Quentin dans un contexte que je ne peux révéler ;-)
TOPF - Talos Orchestrator by PostFinance, un CLI pour gérer des clusters Kubernetes basés sur Talos. Découvert sur le discord de Cuistops
Talhelper - Outil CLI pour créer des clusters Talos en mode GitOps, à partir d’un seul fichier YAML déclaratif. Je l’avais initialement mis de côté mais à y réfléchir, pourquoi pas le mettre.

On notera qu’au même titre que kubeadm et k3s, il y a beaucoup de solutions qui s’appuient sur Talos Linux. De mon point de vue, ça valide l’OS et ça confirme l’adoption croissante de cet OS immutable pour Kubernetes.

Refonte complète des tags

Un gros chantier a été la refonte de tous les tags du catalogue. Ils étaient incohérents : des noms d’outils utilisés comme tags (openshift, rancher…), des tags redondants (on-premise + self-hosted), des tags manquants ou parfois faux (par ex. “lightweight” sur des outils qui lancent des VMs).

J’ai nettoyé les tags de toutes les catégories :

Desktop : suppression des noms d’outils comme tags, ajout de gui pour Docker Desktop, Orbstack, Podman Desktop, Rancher Desktop
Selfhosted : suppression du tag redondant on-premise (29 solutions), ajout de tags pertinents (automation, edge, lightweight, bare-metal…)
ManagementPlatform : toutes les solutions ont maintenant 3 tags (multi-cloud, managed, gui, automation…)
KubernetesInKubernetes : correction de vcluster (virtualization → lightweight)

De nouveaux filtres dans l’UI

J’ai ajouté un filtre par nombre d’étoiles GitHub qui n’apparaît que quand le filtre “Open Source only” est activé. Plutôt pratique pour identifier rapidement les projets les plus populaires (> 100, > 1k, > 10k stars).

L’occasion aussi de réorganiser la barre de filtres : le sélecteur de statut (Active/Abandoned) est passé en dropdown compact, et le layout général a été retravaillé pour rester lisible même avec plus de filtres.

Dernier point, lorsque vous faites une recherche dans la barre principale, une variable vient d’ajouter à l’URL : pratique pour partager des solutions directement avec le lien.

Les contributions d’Antoine Caron (Slashgear)

Un grand merci à Antoine Caron (@slashgear) qui, au-delà de m’avoir aidé sur les performances et la sécurité de ce blog, a aussi contribué directement au projet 101 ways avec plusieurs PRs !

Hiérarchie des headings - les cartes utilisaient des <h3> sans <h2> dans la page. Antoine a corrigé ça pour une hiérarchie correcte (h1 → h2), ce qui améliore la navigation pour les lecteurs d’écran.
Accessibilité du champ de recherche - ajout d’un vrai <label> (en sr-only) et passage du type="text" à type="search" pour une meilleure sémantique.
Skip links - ajout de liens “skip to content” pour la navigation au clavier (WCAG 2.1, critère 2.4.1). Trois liens : vers la recherche, les filtres, et le contenu principal.

Amélioration des performances

En parlant de performances, le site s’est aussi amélioré côté PageSpeed. Voici un avant/après sur Lighthouse mobile :

De 82 à 99 en performances mobiles, avec du 100/100 en bonnes pratiques et SEO.

Ces gains viennent d’un ensemble de corrections, notamment la résolution du clipping des cartes au hover, un bug CSS assez vicieux lié à content-visibility: auto qui impliquait contain: paint et coupait le haut des cartes quand elles se soulevaient au survol. Antoine avait identifié le problème avec l’overflow-hidden, et Copilot a trouvé la cause racine dans le CSS containment.

Merci !

Un grand merci à tous ceux qui contribuent, que ce soit en me mentionnant les outils manquants, en soumettant des PRs, ou simplement en partageant le projet.

Merci spécial à Antoine Caron pour ses PRs sur l’accessibilité et la CI - c’est vraiment chouette de voir quelqu’un prendre le temps d’améliorer un projet open source qui n’est pas le sien. Et c’est d’autant plus appréciable qu’Antoine m’avait déjà aidé sur ce blog avec l’optimisation des images en AVIF et les security headers HTTP. 🙏

Le projet compte maintenant 125 solutions. Si vous en connaissez d’autres, n’hésitez pas à ouvrir une issue ou une PR (ou juste à me ping, en cas de flemme) !

👉 zwindler.github.io/101-ways-to-deploy-kubernetes

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

Mon, 09 Feb 2026 18:00:00 +0200

De Google Sheet à une vraie application web

Vous vous souvenez peut-être de mes précédents articles sur ce projet : d’abord un simple Google Sheet avec 93 méthodes, puis un dépôt GitHub avec plus de 100 entrées.

Aujourd’hui, je peux présenter la dernière itération de ce projet : une vraie interface web pour explorer toutes ces solutions !

👉 101-ways-to-deploy-kubernetes

Pourquoi une UI ?

Le tableau Markdown sur GitHub, c’était déjà mieux que le Google Sheet pour la collaboration, mais à peine. Difficile à parser, difficile de rajouter des colonnes sans que ça devienne trop le bazar (c’était déjà le cas, ahah), et surtout, ultra MOCHE.

J’ai donc décidé de transformer tout ça en une interface moderne et intuitive, avec l’aide d’un LLM.

Stack technique : Astro + Tailwind

Pour ce projet, j’ai choisi une stack simple mais efficace :

Astro : un framework moderne qui génère des sites statiques ultra-rapides
Tailwind CSS : pour un design responsive sans prise de tête

Le résultat ? Un site léger, plutôt rapide, et qui fonctionne aussi bien sur desktop que sur mobile (même si l’expérience desktop reste plus confortable vu la quantité de données).

Les fonctionnalités

Des cartes pour chaque solution

Fini le tableau digne d’un dev back (non, pire, un ingé kube…) ! Chaque outil dispose maintenant de sa propre “carte” animée avec :

Le logo du projet
Le type de licence (OSS ou propriétaire)
Le nombre d’étoiles GitHub
Des liens directs vers le projet et des ressources tierces (blogs indépendants, REX, tutos…)

Des filtres puissants

Vous cherchez uniquement des solutions open source ? Des outils pour le développement local ? Des plateformes de management ?

Les filtres par catégories permettent de naviguer facilement :

Desktop (développement local)
Managed (offres cloud)
Self-hosted (automatisation on-premise)
Infra As Code
Kubernetes OS (systèmes spécialisés)
Management Platform
Kubernetes in Kubernetes

Et vous pouvez aussi filtrer par statut (actif, abandonné) ou afficher uniquement les solutions open source ou production ready.

Une barre de recherche

Vous savez ce que vous cherchez ? Tapez directement le nom dans la barre de recherche pour trouver la solution en un instant.

Des tags pour affiner

Au-delà des catégories, les tags permettent d’identifier rapidement les technologies sous-jacentes (kubeadm, k3s, k0s…).

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

En compilant toutes ces données, j’ai découvert quelque chose de fascinant : au moins 18 outils utilisent kubeadm comme backend pour déployer Kubernetes ! 🤯

Et ce n’est même pas en comptant les offres managées des cloud providers !

C’est typiquement le genre d’information qu’on peut maintenant visualiser instantanément grâce à cette nouvelle interface.

Un projet collaboratif

Le projet reste 100% open source et collaboratif. Les données sont toujours stockées dans le dépôt GitHub, et l’UI est générée automatiquement à partir de ces données (j’ai même rajouté des previews pour les PRs).

Il manque un outil ou un provider ? Vous avez repéré un bug ? N’hésitez pas à ouvrir une issue ou à soumettre une Pull Request !

Le projet compte maintenant 118 solutions (et je sais qu’il en manque certainement), avec pour chacune :

Des liens à jour
Le statut du projet
Des références externes (tutoriels, retours d’expérience…)

Essayez, commentez, partagez

Rendez-vous sur zwindler.github.io/101-ways-to-deploy-kubernetes pour explorer toutes ces solutions !

OK, c’est un infâme “call to action” comme on en voit sur tous les réseaux sociaux. Soit.

Cependant, je ne peux pas savoir si c’est utile (ou non) si vous ne le faites pas. Je peux le laisser en l’état (ça n’est pas génant en soit, j’ai plein d’autres side projects qui n’attendent que mon temps libre) ou le faire vivre, si ça vous plait / sert.

Et si vous trouvez ce projet utile, n’hésitez pas à :

Star le projet sur GitHub
Partager avec vos collègues de la communauté Cloud Native
Contribuer en ajoutant des outils manquants ou en corrigeant des erreurs

Merci d’avance ! 🙏

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Sun, 04 Jan 2026 10:00:00 +0200

Une nouvelle version, une nouvelle maison

Il y a quelques mois, je vous présentais mon tableau recensant 93 façons différentes de déployer Kubernetes, sur Google Sheets.

À la suite de la remarque de Ludovic Piot qui aurait aimé contribuer un ou deux outils manquants, j’ai pris un peu (beaucoup, en vrai) de temps pendant ces vacances pour déménager tout ça sur Github : 101-ways-to-deploy-kubernetes

Pourquoi sur un dépôt git plutôt que sur un Google Sheet comme au début ? Parce que ça me permet facilement de rendre ce projet vraiment collaboratif, notamment via des PRs (et surtout leur validation ou non).

Google Sheets, c’était bien pour commencer, quand c’était un outil perso pour m’aider à écrire mon livre, mais pour la collaboration, c’était pas viable.

Quoi de neuf dans cette v2 ?

Contributions facilitées

Le projet dispose maintenant d’un CONTRIBUTING.md qui explique comment participer.

Vous connaissez une solution qui n’est pas listée ? Vous avez repéré une erreur ? Un lien cassé ? Il vous suffit de faire une Pull Request !

De nombreuses nouvelles méthodes (j’ai pas compté mais probablement une douzaine)

Le projet est passé de 93 à plus de 100 méthodes ! J’ai continué mes explorations et ajouté une douzaine de nouvelles solutions, dont certaines que vous m’aviez suggérées.

Informations sur les licences

J’ai enrichi le tableau avec des détails sur les licences de chaque projet. C’est particulièrement important pour identifier d’un coup d’oeil si un produit est réellement open source ou si c’est une solution à licence propriétaire ou commerciale.

J’ai eu le débat avec Ludovic justement, qui voulait comprendre pourquoi je n’avais pas listé “MKE (Mirantis Kubernetes Engine)”. Je lui avais répondu à l’époque que c’était parce que je ne pouvais pas avoir accès à une version d’essai en tant que “random des Internets” sans passer par un commercial, mais l’argument n’était pas hyper solide.

Pour trouver une règle “unique” à indiquer dans le CONTRIBUTING.md, j’ai donc réintégré une partie des solutions que j’avais “censurées”.

While the heart of the cloud native ecosystem is open source, both open source and closed source (proprietary) tools are accepted in this list. What matters is whether the tool helps deploy Kubernetes clusters, not its licensing model.

Nombreuses références externes

J’ai fait un important travail sur la partie “références externes”. L’idée du répo, au delà de juste fournir une liste à la prévert, est de référencer des articles de tiers indiquant comment mettre en place ces solutions et bénéficier des retours d’expérience de la communauté.

Dans l’idée de rendre le projet plus international (ça sera tout aussi utile aux anglophones qu’aux petits frenchies de ma communauté), j’ai récupéré en priorité des liens en anglais, pour le plus de solutions possibles de cette liste. Il en reste encore qui n’en ont pas, mais ça progresse.

Note importante : au-delà de la documentation officielle (qui existe très souvent pour la grande majorité des projets), j’ai en priorité voulu recenser :

Des tutoriels de qualité de la communauté
Des articles de blog détaillés
Des retours d’expérience concrets

Un projet toujours sous CC BY-SA 4.0

Le contenu reste sous licence CC BY-SA 4.0 (Attribution - Share Alike).

Cela signifie que vous êtes libre de :

Partager : copier et redistribuer le contenu
Adapter : remixer, transformer et créer à partir de ce matériel

Sous les conditions suivantes :

Attribution : vous devez créditer le projet
Partage dans les mêmes conditions : si vous adaptez le contenu, vous devez le distribuer sous la même licence

Comment contribuer ?

C’est simple :

Forkez le dépôt 101-ways-to-deploy-kubernetes
Ajoutez ou modifiez le contenu (en suivant le format du tableau)
Soumettez une Pull Request

Lisez le CONTRIBUTING.md pour plus de détails sur le processus et les bonnes pratiques.

Toutes les contributions sont les bienvenues : nouvelles entrées, corrections, enrichissements, suggestions…

Et la suite ?

Le projet va continuer à évoluer au fil des découvertes et de vos contributions.

Je continue aussi à explorer de nouvelles solutions et à enrichir les informations existantes. Et qui sait, peut-être qu’on dépassera les 150 méthodes d’ici la fin de l’année ? 😄

C’est le moment où je fais mon influenceur et que je vous demande de ne pas hésiter à :

Star le projet sur Github si vous le trouvez utile ⭐⭐⭐
Contribuer en ajoutant vos découvertes
Partager autour de vous si vous le trouvez utile

Rendez-vous sur github.com/zwindler/101-ways-to-deploy-kubernetes !

93 façons de déployer Kubernetes : j'ai recensé (presque) toutes les méthodes existantes

Sun, 02 Nov 2025 18:00:00 +0200

Un projet documentaire un peu fou

Quand j’ai commencé à écrire mon livre “Kubernetes : 50 solutions pour les postes de développement et les clusters de production”, je me suis rapidement rendu compte d’un problème : il existe une infinité de façons de déployer Kubernetes.

Bon, pas littéralement une infinité, mais quand même… beaucoup. Trop ?

Pour structurer mon livre et choisir quelles solutions j’allais couvrir, j’ai fait ce que tout bon nerd ferait : j’ai créé un tableau.

Un très grand tableau.

Un Google Sheet qui recense actuellement 93 méthodes différentes pour déployer Kubernetes. Comme je n’aime pas “gâcher”, je le partage avec vous aujourd’hui en CC BY-SA 4.0 (Attribution - Share Alike) :

93 façons de déployer Kubernetes

Que contient ce tableau ?

Le tableau est structuré avec plusieurs colonnes pour vous aider à naviguer dans cette jungle :

Nom du produit (et éditeur quand c’est intéressant)
URL du produit : j’ai essayé de restreindre aux produits open source (ou aux services managés publics) même s’il y a quelques exceptions
Type de solution (j’y reviendrai)
“Basé sur” : là, c’est un truc assez rigolo… beaucoup de projets sont des surcouches de kubeadm, k3s ou k0s. Tous ne le disent pas ouvertement, et je m’en suis rendu compte en les essayant

Et peut-être un peu moins intéressant (peut-être que ça disparaîtra)

Est-ce que j’en parle dans mon livre ?
Est-ce que j’en parle sur mon blog ?

Les différentes catégories d’outils

Pour structurer d’abord ma pensée, et ensuite mon livre, j’ai essayé de classer ces méthodes en catégories.

Certaines sont assez évidentes (une offre managée, on voit tout de suite de quoi il s’agit), d’autres, un peu plus personnelles (et donc discutables).

Kubernetes sur desktop (Local Development)

Les outils pour développer en local sur votre machine. On parle ici des Minikube, kind et autres Docker Desktop

Infrastructure as Code (IaC)

Les outils qui vous permettent de décrire le déploiement de Kubernetes via du code (opentofu, crossplane, pulumi…)

Kubernetes in Kubernetes

Parce que pourquoi faire simple quand on peut faire… recursif ? 🤯. Ca se limite pour l’instant à vCluster et k3k.

OS spécialisés

Des systèmes d’exploitation conçus spécifiquement pour faire tourner Kubernetes. Je pense bien sûr à Talos Linux, mais pas que ;-P.

Kubernetes managés (les offres cloud clés en main)

Pas besoin de faire un dessin, on pense direct à la triplette EKS / AKS / GKE, mais aussi aux solutions françaises (OVHcloud Managed Kubernetes, bientôt Clever Cloud :smirk:)

Plateformes de management de clusters

Là, c’est une catégorie un peu à part, qui vont nous permettre de gérer plein de clusters Kubernetes et même de générer de nouveaux clusters gérés par des clusters… Souvent des bonnes usines à gaz comme Gardener ou pire Kubermatic Kubernetes Platform. On a quand même des trucs un peu plus funs comme Kamaji.

Outils d’automatisation pour self-hosted

Les solutions qui automatisent le déploiement sur vos propres machines, comme kubeadm, k3s et k0s (la triplette, base d’à peu près 50% des autres solutions du marché).

La révélation : tout le monde copie sur son voisin

En remplissant ce tableau, j’ai découvert quelque chose de marrant : une grande majorité des outils ne réinventent pas la roue.

Beaucoup de projets sont en fait des surcouches ou des wrappers autour de trois solutions de base que je cite juste avant (kubeadm, k3s et k0s). Et parfois, on a aussi des surcouches de solutions un peu plus confidentielles.

L’info n’est pas toujours disponible, j’ai parfois découvert ça au détour d’un blogpost, ou même en allant fouiller les entrailles de la solution.

C’est typiquement le genre de colonne intéressante pour bien se rendre compte qu’au delà de l’apparente diversité de ces solutions de déploiement, il y a en fait un gros standard et quelques variations.

J’espère réussir à dénicher plus d’indices similaires pour remplir encore un peu plus cette colonne :).

Un document vivant

Ce tableau n’est pas figé. Le nombre d’outils évolue régulièrement (j’en découvre de nouveaux presque chaque semaine).

Si vous connaissez une méthode qui n’est pas listée, n’hésitez pas à commenter sur les réseaux.

Note : je rappelle que je vise en priorité les solutions open source ou services managés publics (je viens de virer Mirantis Kubernetes Engine pour cette raison).

Et sinon, il me reste quoi à tester ?

J’ai déjà teasé sur les réseaux sociaux fréquentables, dans la liste des trucs que je n’ai pas encore testé mais qui pourraient me motiver, il y a :

ClusterConfiguration : introduction aux APIs de kubeadm pour installer vos clusters

Sun, 17 Dec 2023 12:00:00 +0200

Créer des clusters Kubernetes avec `kubeadm`, mais sans CLI à rallonge

Un des premiers articles que j’ai écrits sur Kubernetes était l’installation d’un cluster avec kubeadm. A l’époque, j’avais testé avec les options de bases et ça marchait très très bien déjà.

Mais quand on commence à avoir des clusters un peu plus proches de la production, on se retrouve rapidement à rajouter plein d’options dans la CLI.

Pire, à un certain niveau de complexité, certaines options ne fonctionnent pas ensemble !

Note: c’est ce qui m’est arrivé quand j’ai essayé d’automatiser l’installation de kubeadm avec Ansible. On pourra débattre de l’intérêt d’automatiser une install kubeadm avec Ansible alors que Kubespray existe, cf cet autre article que j’ai écrit en 2017 mais c’est au-delà du scope de cet article…

Pour faire propre, arrêtez de passer la terre entière en arguments

Clairement, à partir de 5 ou 6 options, c’est le moment de se demander s’il ne serait pas préférable d’utiliser un fichier de configuration pour gérer nos clusters.

Et ça tombe bien, kubeadm dispose d’une API (plusieurs en fait), on va donc pouvoir écrire du YAML avant même d’avoir notre cluster Kubernetes opérationnel. YAY ! (font les YAML engineers)

Concrètement comment ça se présente ?

Plutôt que de passer tous nos arguments dans notre commande kubeadm, on va remplir un fichier kubeadmcfg.yaml qui va nous servir de configuration. En vrai, on va même en avoir plusieurs, puisque les nodes n’ont pas tous le même rôle dans notre workflow de création de cluster.

Le premier fichier sera un fichier qui contiendra la ClusterConfiguration (cf doc officielle)

A noter, vous pouvez récupérer le fichier des valeurs par défaut avec la commande :

$ kubeadm config print init-defaults
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
bootstrapTokens:
- groups:
 - system:bootstrappers:kubeadm:default-node-token
 token: abcdef.0123456789abcdef
 ttl: 24h0m0s
 usages:
 - signing
 - authentication
localAPIEndpoint:
 advertiseAddress: @IP
 bindPort: 6443
nodeRegistration:
 criSocket: unix:///var/run/containerd/containerd.sock
 imagePullPolicy: IfNotPresent
 name: node
 taints: null
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
 timeoutForControlPlane: 4m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: {}
etcd:
 local:
 dataDir: /var/lib/etcd
imageRepository: registry.k8s.io
kubernetesVersion: 1.28.0
networking:
 dnsDomain: cluster.local
 serviceSubnet: 10.96.0.0/12
scheduler: {}

A partir de là, on va pouvoir customiser notre control plane, via des sections correspondant à chaque composant du control plane :

apiServer
controllerManager
scheduler
etcd

A quoi ça peut bien servir ?

Forcément les possibilités sont très nombreuses et je ne vais pas toutes les lister. Mais je vais vous donner quelques exemples.

L’exemple le plus parlant est évidemment l’ajout d’arguments aux différents composants. Ici, j’ajoute l’authentification OIDC au cluster et mes feature gates pour activer les APIs alpha :

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
[...]
apiServer:
 extraArgs:
 feature-gates: {{ kube_feature_gates }}
 oidc-issuer-url: {{ kube_oidc_issuer_url }}
 oidc-client-id: {{kube_oidc_client_id }}
 oidc-username-claim: email
 oidc-groups-claim: groups
[...]

Si vous avez plusieurs virtual IPs qui permettent de vous connecter à votre cluster Kubernetes, il sera probablement nécessaire de supporter plusieurs certSANs pour la partie TLS :

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
[...]
apiServer:
 certSANs:
 - "{{ control_plane_endpoint_ip }}"
 - "{{ control_plane_endpoint_ip_for_humans }}"
[...]

Dans le cas où vos machines ont plusieurs IPs, il pourra être nécessaire d’indiquer au cluster les bonnes IPs pour le contacter. Petit piège, il faut modifier dans une autre API que j’ai omis pour l’instant : InitConfiguration !

---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
[...]
localAPIEndpoint:
 advertiseAddress: {{ app_ip }}
 bindPort: 6443
[...]

Si vous avez suivi mon précédent article sur mon petit souci de prod avec etcd qui était spammé par Kyverno, vous saurez qu’il faut tuner la base etcd. Comme ceci par exemple :

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
[...]
etcd:
 local:
 extraArgs:
 quota-backend-bytes: "5368709120"
 auto-compaction-retention: "1"
 auto-compaction-mode: periodic
[...]

Et de mon côté, j’ai besoin de changer le nom de domaine des services Kubernetes. Je le fais comme ceci :

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
[...]
networking:
 dnsDomain: {{ kube_dns_domain }}
[...]

Une fois que c’est bien configuré comme on en a envie :

/usr/bin/kubeadm init --config=/etc/kubernetes/kubeadmcfg.yaml --upload-certs --skip-certificate-key-print

Et ensuite ?

La ClusterConfiguration, c’est cool, mais il existe d’autres API utiles avec kubeadm, je le disais plus haut.

Lorsqu’on va ajouter des nodes au control plane, on ne va pas pouvoir réutiliser la ClusterConfiguration et l’InitConfiguration, car elles servent pour TOUT le cluster et sont unique. On les a déjà configurées quand on a fait l’init du premier node de control plane.

On va donc utiliser la JoinConfiguration, qui nous permet là aussi de définir des trucs importants comme :

localAPIEndpoint.advertiseAddress si on a plusieurs IPs sur la machine (exemple ci dessus).
discovery.bootstrapToken.token (et caCertHashes) qui va permettre de faciliter l’automatisation du join des nodes

---
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinConfiguration
caCertPath: /etc/kubernetes/pki/ca.crt
discovery:
 bootstrapToken:
 apiServerEndpoint: {{ control_plane_endpoint }}
 token: {{ kubeadm_token }}
 caCertHashes:
 - sha256:{{ kubeadm_cacert_hash }}
 unsafeSkipCAVerification: false
nodeRegistration:
 name: {{ ansible_nodename }}
controlPlane:
 certificateKey: {{ kubeadm_certificate_key }}
 localAPIEndpoint:
 advertiseAddress: {{ app_ip }}
 bindPort: 6443
{% endif %}

Une fois que ce fichier est créé sur la machine du control plane qui va rejoindre la première, on peut lancer la commande kubeadm join qui devrait bien se passer ;-).

kubeadm join {{ control_plane_endpoint_ip }} --config /etc/kubernetes/kubeadmcfg.yaml

Conclusion

Utiliser les fichiers de configuration de kubeadm n’est pas trivial car assez mal documenté (je trouve, les docs sont éclatés entre plusieurs pages et les exemples pas parlants dans mon cas).

Je ne vais pas mentir, je me suis arraché les cheveux et j’ai demandé de l’aide plusieurs fois sur X.

Bien sûr, vous pouvez aller potasser la doc officielle Customizing components with the kubeadm API et kubeadm Configuration (v1beta3) mais j’ai quand même eu du mal à comprendre COMMENT l’utiliser, la première fois.

J’espère que cet article pourra aider à mieux comprendre comment les différentes API s’articulent entre elles et comment les utiliser.

Kubernetes - Error from server: etcdserver: mvcc: database space exceeded

Thu, 30 Nov 2023 12:00:00 +0200

Petite panique en prod !

Ca ne sera une surprise pour personne, j’administre des clusters Kubernetes en production (et aussi pour le fun, oui je suis bizarre). Et des fois, quand on a des workloads un peu inhabituels, on a des petites surprises rigolotes.

Pour vous situer un peu le contexte, j’ai un cluster “on-prem” d’une grosse soixantaine de nodes physiques baremetal, sur lesquels je fais tourner (entre autres) des jobs éphémères très courts.

Ca génère beaucoup de trafic sur la base de données etcd (beaucoup d’événement de création / destruction de pods) et ça nous a déjà posé des problèmes dans le passé (notamment pour tout ce qui est collecte de métriques, on effondre prometheus même avec beaucoup de RAM).

Mais ça tenait.

Et là, c’est le drame…

Depuis peu, j’ai aussi commencé à ajouter plein de nouvelles “policies” sur Kyverno (pour ceux qui ne connaissent pas j’ai fait un article sur le sujet).

Et j’ai découvert un peu à mes dépens que Kyverno ajoute BEAUCOUP de pression sur etcd, en créant énormément d’événements (évaluation des policies pour chaque objet Kubernetes, et comme j’en ai beaucoup…).

A un tel point, qu’à un moment donnée, toutes les opérations d’écriture sur l’API server renvoyaient l’erreur suivante :

Error: etcdserver: mvcc: database space exceeded

Ca pue la DB pleine 😬😬😬. Pourtant, aucune alerte sur mes espaces disques !? Bizarre.

De toute façon, pour ne rien arranger, les pods etcd n’étant plus healthy puisque la base est supposément pleine, l’API server crashe au bout d’un moment et je n’avais plus la main sur rien pour debug.

PANIK!

Remettre les gaz

Petite “astuce du pro” quand votre control plane Kubernetes est dans le mal, à un moment plus rien ne marche car les pods etcd / apiserver se mettent en crashloop backoff, étant alternativement down et pas relancé à cause du “backoff”.

Un bon moyen de contourner ça, quand vous avez la main sur le control plane (donc pas sur du managé, mais de toute façon c’est pas votre problème), c’est de restart le kubelet sur tous les nodes du control plane en même temps.

Pourquoi ? Parce que le restart du kubelet remet à 0 tous les compteurs et que vos pods ne sont donc pas dans la phase de “backoff” trop longtemps, ce qui évite les problématiques de “pas assez de membres etcd sont on, donc je me saborde” et ainsi de suite.

Source du diagramme : Substack de Natan Yellin pour robusta.dev

Nettoyer la base etcd

Maintenant que c’est fait, j’avais suffisamment de pods etcd vivants (à défaut d’être opérationnel).

Un petit coup d’oeil sur mes graphes dans Grafana me montrent qu’il s’est effectivement “passé un truc” quand j’ai activé les nouvelles policies Kyverno.

Et “CÔM PAR HASAR”, ça marche plus quand la taille de 2 des 3 bases de données etcd atteint 2 Gio

Une rapide recherche sur Internet me confirme que ma base est pleine, et que la solution à mon problème est de compacter puis défragmenter ma base.

Comme tout est un peu cassé, on trouve des commandes bash à envoyer pour récupérer la dernière révision, compacter puis défragmenter la base :

# get latest revision
REVISION=$(ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key endpoint status --write-out="json" | egrep -o '"revision":[0-9]*' | egrep -o '[0-9].*')

# compact
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key compact ${REVISION}

# defrag
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key defrag

# SUPER MEGA IMPORTANT
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key alarm disarm

J’ai rajouté SUPER MEGA IMPORTANT sur la dernière instruction parce que, comme je suis un peu neuneu, je ne l’avais initialement pas lancée.

Bah oui. L’idée de désarmer une alarme me paraissait complètement incongrue. L’alarme, je veux la garder. Non ?

Mais en fait, c’est le comportement normal. Le cluster etcd est prévu pour se bloquer, et ne plus rien faire, tant que l’alarme n’a pas été désarmé, même si le souci d’espace est résolu…

Ok, je saurais la prochaine fois

What does “mvcc: database space exceeded” mean and how do I fix it? The multi-version concurrency control data model in etcd keeps an exact history of the keyspace. Without periodically compacting this history (e.g., by setting –auto-compaction), etcd will eventually exhaust its storage space. If etcd runs low on storage space, it raises a space quota alarm to protect the cluster from further writes. So long as the alarm is raised, etcd responds to write requests with the error mvcc: database space exceeded.

To recover from the low space quota alarm:

Compact etcd’s history.

Defragment every etcd endpoint. - Disarm the alarm.

memberID:11111111111111111111111 alarm:NOSPACE

Note : comme etcd ne revenait pas à la vie, j’ai balancé 50 fois la commande de compaction et ça me renvoyait une erreur qui me laissait penser qu’il y avait un autre problème. Et non, c’est bien que la compaction a été correctement faite ;-).

error: code = OutOfRange desc = etcdserver: mvcc: required revision has been compacted"}
Error: etcdserver: mvcc: required revision has been compacted

Éviter que ça se reproduise

OK, maintenant que la DB est restaurée, comment on s’assure que ça ne se reproduise pas ?

En réalité, les paramètres par défaut de la base etcd (locale) de kubeadm ne sont pas terribles.

D’abord, on voit que j’ai tapé la limite des 2 Gio, limite par défaut dans etcd, alors que je n’ai que 60-70 nodes et quelques milliers de pods (ok, j’en crée des centaines de milliers par jour, but still).

La documentation de Rancher conseille de monter cette limite à 5 Go (Tuning etcd for Large Installations).

On va donc modifier la valeur quota-backend-bytes.

Ensuite, il faut activer la compaction automatique pour notre etcd. Comme j’utilise kubeadm et un fichier kubeadmcfg, je dois rajouter une section dans mon fichier pour tuner les paramètres

etcd:
 local:
 extraArgs:
 quota-backend-bytes: "5368709120"
 auto-compaction-retention: "1"
 auto-compaction-mode: periodic

Puis régénérer les manifests sur tous mes nodes de control plane (malheureusement, ça ne se fait pas tout seul, cf la documentation officielle de Kubernetes - Reflecting ClusterConfiguration changes on control plane nodes)

kubeadm init phase etcd local --config kubeadmcfg.yaml

Note: attention, les arguments attendus sont des strings, donc entourez bien toutes les valeurs numériques entre quotes :

json: cannot unmarshal number into Go struct field LocalEtcd.etcd.local.extraArgs of type string

Dernier point, s’il est possible de dire à etcd de réaliser la compaction tout seul comme un grand, a priori le defrag n’est pas automatique.

La plupart du temps ça n’est peut-être pas gênant mais comme je suis extrêmement bourrin avec la création / destruction de pods, j’ai dû automatiser aussi cette partie “defrag”.

En attendant de trouver mieux, j’ai donc rajouté un cron

00 */3 * * * /usr/bin/etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/peer.crt --key=/etc/kubernetes/pki/etcd/peer.key --endpoints https://@IP:2379 defrag --cluster

Bon, c’était pas l’opération la plus fun de l’année, mais maintenant ça remarche 😂.

Sources complémentaires

Installer Kubernetes avec Kubespray (Ansible)

Tue, 05 Dec 2017 12:45:25 +0000

Kubeadm quand on a pas ou mal accès à Internet

Rapidement pour resituer un peu le sujet, Kubernetes est un produit permettant de gérer des clusters de machines exécutant des containers en production. Un moyen simple d’installer cet outil complexe est d’utiliser l’outil kubeadm, qui était jusqu’à il y a peu déconseillé pour la production (la documentation de la version 1.8 ne le mentionne pas mais le message apparaît toujours lors du kubeadm init). Pour y voir plus clair, vous pouvez lire les articles que j’ai écris à ce sujet.

Dans le cadre d’un déploiement d’un cluster Kubernetes on-premise, j’ai été assez ennuyé par le proxy. En théorie, on peut utiliser kubeadm derrière un proxy mais de nombreux utilisateurs remontent des difficultés de ce côté là (je ne suis pas le seul, ouf). Si vous voulez plus d’info à ce sujet j’ai mis un paragraphe en fin d’article.

Kubespray à la rescousse

Depuis quelques mois, il existe une nouvelle manière de déployer Kubernetes, qui s’appelle Kubespray. Et cerise sur le MacDo, ce méthode utilise Ansible (et vous savez comme je suis friand d’Ansible).

J’ai donc décidé de tester et, vous vous en doutez puisque j’en fais un article, j’ai réussi à installer Kubernetes avec Kubespray derrière mon proxy capricieux ;-).

A noter, Kubespray ne se limite pas à déployer un Kubernetes on premise, puisqu’il supporte aussi AWS et OpenStack via l’utilisation de scripts Terraform (outil qui fera l’objet d’un petit article à venir).

Vous pouvez trouver la documentation sur les sites suivants :

Installation des prérequis

Un petit tour sur le Github nous donne les prérequis :

A ceci j’ajouterai le fait que Kubernetes demande maintenant que la swap soit désactivée sur tous les nœuds ! Si ce n’est pas déjà fait, il faut passer sur tous les serveurs et la désactiver (ne pas oublier la fstab aussi!)

Kubespray nécessite l’installation des outils de développements sur la machine qui exécute le script Ansible, ainsi que Python 3. Sur les CentOS / RHEL 7, la version de Python est la 2.7, qui n’est donc pas compatible avec le script Python 3 qui génère le fichier d’inventaire pour le déploiement Ansible.

En soit, ce n’est pas vital, mais ça facilite quand même le travail donc ça vaut le coup.

yum -y install yum-utils
yum -y groupinstall development
yum -y install https://centos7.iuscommunity.org/ius-release.rpm
yum -y install python36u python-netaddr
yum -y install python-pip
pip install --upgrade Jinja2

Récupération et configuration de kubespray

Les sources de Kubespray sous sur Github, on les récupère

git clone https://github.com/kubernetes-incubator/kubespray

Récupérer les dépendances pip

sudo pip install -r requirements.txt

On copie le dossier inventory d’origine pour se faire sa propre conf :

cd kubespray
cp -r inventory inventaire_kubernetes

On déclare les adresses IPs des futurs nœuds kubernetes puis on lance le script pour générer l’inventaire :

declare -a IPS=(192.168.1.101 192.168.1.102 192.168.1.103 192.168.1.104)
CONFIG_FILE=inventaire_kubernetes/inventory.cfg python3.6 contrib/inventory_builder/inventory.py ${IPS[@]}

On peut regarder le contenu de modifier le fichier inventaire_kubernetes/inventory.cfg si nécessaire :

[all]
master01 ansible_host=192.168.1.101 ip=192.168.1.101
worker01 ansible_host=192.168.1.102 ip=192.168.1.102
worker02 ansible_host=192.168.1.103 ip=192.168.1.103
worker03 ansible_host=192.168.1.104 ip=192.168.1.104

[kube-master]
master01
worker01

[kube-node]
master01
worker01
worker02
worker03

[etcd]
master01
worker01
worker02

[k8s-cluster:children]
kube-node
kube-master

[calico-rr]

[vault]
master01
worker01
worker02

Typiquement ici dans mon cas, n’ayant que 4 machines et ne souhaitant pas faire tourner de container sur les masters (bien que ce soit possible), j’ai prévu de ne mettre qu’un master et 3 workers.

Du coup, les groupes sont à adapter en fonction des rôles de chacun. J’ai retiré worker01 du groupe kube-master. Idéalement bien entendu, il aurait fallu avoir plus d’un master (3 idéalement ou au moins 2).

Idem pour la répartition du vault et du etcd sur les workers. Le mieux serait d’avoir un peu de haute disponibilité supplémentaire sur ces composants et donc de les répartir comme le propose le script d’inventaire, mais rien ne vous y oblige.

Déploiement du cluster

Maintenant que notre inventaire est prêt, Kubespray déploie le cluster avec ce oneliner :

ansible-playbook -i inventaire_kubernetes/inventory.cfg cluster.yml -b -v --private-key=~/.ssh/id_rsa

Pas mal hein ? Par rapport à l’installation avec kubeadm que je décris dans Installer un cluster Kubernetes sur des VMs CentOS 7, c’est quand même bien plus simple !

Oui oui, vous avez compris, c’est déjà fini !

Bonus : Changer le service du dashboard de kubernetes pour le publier sur un port

Contrairement à kubeadm, Kubespray installe le dashboard par défaut, pas besoin d’importer et d’appliquer le YAML.

Cependant, même si normalement on préfère accéder au dashboard de Kubernetes avec le kubeproxy, on peut vouloir dans certains cas accéder directement au Dashboard depuis un port fixe.

Pour ce faire, on remplace le ClusterIP (interne à Kubernetes uniquement) par un Nodeport en récupérant la configuration du service, en la modifiant et en la ré-appliquant :

kubectl get svc kubernetes-dashboard --namespace=kube-system -o yaml > kubernetes-dashboard-svc.yaml

vi kubernetes-dashboard-svc.yaml
apiVersion: v1
kind: Service
metadata:
 labels:
 k8s-app: kubernetes-dashboard
 name: kubernetes-dashboard
 namespace: kube-system
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 9090
 selector:
 k8s-app: kubernetes-dashboard
 type: NodePort

Une fois les modification faites, on réapplique la configuration et on vérifie que ça a fonctionné

kubectl apply -f kubernetes-dashboard-svc.yaml

kubectl get svc --namespace=kube-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns 10.233.0.3 <none> 53/UDP,53/TCP 97d
kubernetes-dashboard 10.233.33.140 <nodes> 80:30000/TCP 97d

Le Dashboard est disponible sur le port 30000 !

Bonus : Kubeadm et les proxy internet

J’en parle en début de l’article, j’ai beaucoup galéré avec kubeadm et sa gestion de proxy. Si vous n’en avez pas, ça marche très bien mais si vous avez un proxy, kubeadm fait des appels à Internet via de multiples canaux (je n’ai pas vérifié si c’était mieux en 1.8) :

docker pull pour récupérer les images
un accès direct

J’ai eu beau ajouter ‘with_proxy’, configurer les variables HTTP_PROXY/HTTPS_PROXY/NO_PROXY (et en minuscules) aussi bien au niveau de l’OS que du démon Docker mais rien n’y a fait…

Quelques pistes si vous voulez vous y essayer :

On peut même également installer un cluster Kubernetes avec kubeadm sans accès à Internet en préchargeant les images docker nécessaires, mais là encore, l’outil kubeadm se bloque au moment d’aller vérifier sur Internet s’il existe des images plus récentes à télécharger.

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

Kubeadm on Zwindler's Reflection

101 façons de déployer Kubernetes : 125 solutions, des PRs communautaires et une UI qui s'améliore

Il bouge encore

7 nouvelles solutions

Refonte complète des tags

De nouveaux filtres dans l’UI

Les contributions d’Antoine Caron (Slashgear)

Amélioration des performances

Merci !

101 façons de déployer Kubernetes : une nouvelle UI pour explorer les 118+ solutions

De Google Sheet à une vraie application web

Pourquoi une UI ?

Stack technique : Astro + Tailwind

Les fonctionnalités

Le saviez-vous ? Au moins 18 outils utilisent kubeadm !

Un projet collaboratif

Essayez, commentez, partagez

101 façons de déployer Kubernetes (v2) : maintenant sur Github avec plus de méthodes, plus de détails, plus de tout

Une nouvelle version, une nouvelle maison

Quoi de neuf dans cette v2 ?

Un projet toujours sous CC BY-SA 4.0

Comment contribuer ?

Et la suite ?

93 façons de déployer Kubernetes : j'ai recensé (presque) toutes les méthodes existantes

Un projet documentaire un peu fou

Que contient ce tableau ?

Les différentes catégories d’outils

La révélation : tout le monde copie sur son voisin

Un document vivant

Et sinon, il me reste quoi à tester ?

ClusterConfiguration : introduction aux APIs de kubeadm pour installer vos clusters

Créer des clusters Kubernetes avec kubeadm, mais sans CLI à rallonge

Pour faire propre, arrêtez de passer la terre entière en arguments

Concrètement comment ça se présente ?

A quoi ça peut bien servir ?

Et ensuite ?

Conclusion

Kubernetes - Error from server: etcdserver: mvcc: database space exceeded

Petite panique en prod !

Et là, c’est le drame…

Remettre les gaz

Nettoyer la base etcd

Éviter que ça se reproduise

Sources complémentaires

Installer Kubernetes avec Kubespray (Ansible)

Kubeadm quand on a pas ou mal accès à Internet

Kubespray à la rescousse

Installation des prérequis

Récupération et configuration de kubespray

Déploiement du cluster

Bonus : Changer le service du dashboard de kubernetes pour le publier sur un port

Bonus : Kubeadm et les proxy internet

Installer un cluster Kubernetes sur des VMs CentOS 7

Kubernetes, c’est quoi ça ?

Prérequis

Solutions de déploiement

Le plus simple : Minikube

La solution de l’article : Utiliser Kubeadm

Configuration des dépôts

SELinux

Installation des packages

Initialisation du cluster

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

Taint node

Configuration des Network Pods

Flannel

Calico

Ajout de nœuds supplémentaires

Déployer la console web

kubectl proxy

Via le serveur controlplane

Le mot de la fin

Créer des clusters Kubernetes avec `kubeadm`, mais sans CLI à rallonge