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

[Tutoriel] XWiki, ma premier appli Statefull sur Kubernetes

Tue, 24 Oct 2017 11:30:52 +0000

Pourquoi déployer XWiki sur Kubernetes ?

Vous le savez surement maintenant vu le nombre d’article que j’ai écrit sur le sujet, j’aime bien XWiki. C’est un super projet mené par des gens passionnés, réactifs et surtout, c’est cet outil qui a permis à mon entreprise d’adopter ENFIN le wiki comme outil de documentation, que ce soit pour documenter les procédures, mais aussi documenter entièrement les concepts de l’outil que nous développons.

D’un outil quasi-confidentiel utilisés par quelques admins peu motivés (sous Mediawiki), nous sommes donc progressivement passés à un outil utilisé par toutes les équipes, du dev. au support en passant par les ergo. et les CPs, utilisés par plusieurs entités internes et même accepté comme document contractuel par nos prestataires. J’ai d’ailleurs documenté la migration sur cet article.

Mais j’aime aussi XWiki car c’est selon moi l’exemple parfait d’une appli 2 ou 3 tiers relativement simple pour explorer l’écosystème Docker (construction des images, les problématiques réseau et stockage, …). Je joue régulièrement avec ma propre image sur le Dockerhub pour explorer un peu plus cet écosystème riche (c’est rien de le dire).

Quelle meilleure application donc pour réellement tester mon tout nouveau cluster Kubernetes (je ne compte pas nginx ou helloworld) ?

Kubernetes ?

Pour ceux qui ont besoin d’un rappel sur Kubernetes ou des premiers concepts et/ou comment l’installer, je vous invite à lire/relire mon article précédent sur le sujet.

A noter également (j’ai pas mal communiqué là-dessus sur les réseaux sociaux), la Linux Foundation, qui gère également la Cloud Native Computing Foundation (et qui elle-même gère Kubernetes), a mis à disposition gratuitement un cour en ligne de type MOOC sur edX. Vous pouvez même vous « certifier » à la fin si vous réussissez le QCM, moyennant 100$.

A l’issue de ces lectures, vous devriez donc avoir :

la connaissance des différents concepts de Kubernetes
un cluster Kubernetes opérationnel (une ou plusieurs machines, ou simplement un minikube en local)

Ce sont les prérequis pour la suite de cet article, même si je vais essayer de détailler tout ce qui va suivre.

Plan de bataille

Je ne vais pas vous le cacher, si on veut tout faire soit même, ce n’est pas « trivial ». Mais en décomposant toutes les étapes, vous allez voir que c’est logique.

Pour faire tourner mon image Docker zwindler/xwiki-tomcat8, j’ai besoin, sur mon cluster Kubernetes, des choses suivantes :

un Deployment qui exécute la partie PostgreSQL. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne souhaite avoir qu’un seul Pod avec l’image postgresql officielle
- Un Service de type ClusterIP pour lui permettre de communiquer avec le XWiki mais pas avec le monde extérieur
- Un PersistantVolumeClaim et son PersistentVolume associé pour stocker les données de la base
- Des Secrets pour permet de configurer les mots de passes de postgres et de l’utilisateur XWiki
un Deployment qui exécute la partie XWiki. Ce Deployment contiendra :
- un ReplicaSet avec une seule instance car on ne fait tourner qu’un seul Pod avec l’image zwindler/xwiki-tomcat8, car on n’utilise qu’un tomcat à la fois pour exécuter XWiki
- Un Service de type NodePort (ou mieux si vous avez des LoadBalancers ou des Ingress à dispo.) qui permettra d’exposer le port interne au cluster Kubernetes vers le monde extérieur
- Un PersistantVolumeClaim avec le PersistentVolume pour stocker les pièces jointes car mon image Docker utilise l’option filesystem_store pour éviter de surcharger la base pour les PJ
- et aussi le Secret défini précédemment pour accéder à la BDD.

OK.

Voir ça posé dans une liste comme ça, ça peut faire peur.

Alors vous allez me dire : « c’est plus facile de lancer ton DockerCompose » (car j’ai montré qu’avec DockerCompose on peut démarrer une instance XWiki en 2 ou 3 lignes de commandes). Mais au final, tout ce que j’ai écris ici peut être concaténé dans un seul et même fichier YAML et le résultat est aussi simple dans l’absolu.

Créer les Secrets

Clairement, c’est un des gros points forts par rapport à la solution plus simple avec juste Docker / DockerCompose : la gestion des Secrets (et des configurations, dans une moindre mesure).

Ici, plutôt que d’avoir un mot de passe en clair dans mon fichier compose, le mot de passe est renseigné à part, soit via un fichier, soit via l’API. Et ces mots de passes ne pourront plus être consultés via la CLI, mais pourront être utilisés.

Pour créer un secret dans Kubernetes en CLI, il existe plusieurs méthodes. Soit on utilise la CLI directement depuis le prompt ou depuis un fichier plat (qui va se charger d’encoder le secret en base64 et de générer le YAML pour nous), soit on décide de créer le YAML nous-même. Je vous met les deux méthodes :

echo -n "xwikidb" > ./POSTGRES_USER.txt
echo -n "xwikipwd" > ./POSTGRES_PASSWORD.txt
kubectl create secret generic postgresql-xwiki-user-password --from-file=POSTGRES_USER.txt --from-file=POSTGRES_PASSWORD.txt
secret "postgresql-xwiki-user-password" created
#ou
cat > postgresql_xwiki_user_password.yaml << EOF
apiVersion: v1
kind: Secret
metadata:
name: postgresql-xwiki-user-password
type: Opaque
data:
username: $(cat POSTGRES_USER.txt| base64 -w 0)
password: $(cat POSTGRES_PASSWORD.txt| base64 -w 0)
EOF

Au final, pour un déploiement unitaire pour vous même, ça ne change pas grand-chose bien sûr. Vous avez renseigné en clair le mot de passe (ou en base64 mais c’est pareil) à un moment donné.

Cependant, dans le cadre d’un gros projet avec des développeurs qui poussent du code régulièrement d’un côté et des admins qui gèrent de l’autre les utilisateurs et les mots de passes, on peut permettre aux développeurs consommer les mots de passe sans jamais avoir à les connaitre (et laisser trainer sur Gitlab, ou pire, Github !).

kubectl describe secret postgresql-xwiki-user-password
Name: postgresql-xwiki-user-password
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 8 bytes
username: 7 bytes

Créer les Persistent Volumes

Dans mon infrastructure, j’ai déjà un cluster GlusterFS. GlusterFS étant un SDS, il est particulièrement indiqué comme stockage persistant dans le cadre d’un cluster Kubernetes (comme Ceph, Cinder, S3 ou autre). Ces types de méthodes de stockage peuvent facilement se piloter par API et sont hautement disponibles.

Création de l’endpoint GlusterFS

cat > gluster-endpoints.yaml <<EOF
apiVersion: v1
kind: Endpoints
metadata:
name: gluster-cluster
subsets:
- addresses:
- ip: 10.0.0.1
ports:
- port: 1
protocol: TCP
- addresses:
- ip: 10.0.0.2
ports:
- port: 1
protocol: TCP
EOF
kubectl apply -f gluster-endpoints.yaml
endpoints "gluster-cluster" created
kubectl get endpoints gluster-cluster
NAME ENDPOINTS AGE
gluster-cluster 10.0.0.1:1,10.0.0.2:1 39s
cat > gluster-service.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: gluster-cluster
spec:
ports:
- port: 1
EOF
kubectl apply -f gluster-service.yaml
service "gluster-cluster" created
kubectl get service gluster-cluster
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 1m

La partie GlusterFS a été configurée côté Kubernetes. On peut maintenant s’atteler à la création des PV et PVC associés. D’abord la base de données :

cat > gluster-pv-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-pg
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-pg-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-pg.yaml
persistentvolume "gluster-pv-xwiki-pg" created
cat > gluster-pvc-xwiki-pg.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-pg
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-pg.yaml
persistentvolumeclaim "gluster-pvc-xwiki-pg" created

Et maintenant l’application XWiki

cat > gluster-pv-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-pv-xwiki-app
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: gluster-cluster
path: /xwiki-app-storage
readOnly: false
persistentVolumeReclaimPolicy: Retain
EOF
kubectl create -f gluster-pv-xwiki-app.yaml
persistentvolume "gluster-pv-xwiki-app" created
cat > gluster-pvc-xwiki-app.yaml << EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: gluster-pvc-xwiki-app
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f gluster-pvc-xwiki-app.yaml
persistentvolumeclaim "gluster-pvc-xwiki-app" created

Dans le cadre d’un test, vous pouvez vous contenter de faire simplement appel à un partage NFS ou même à du stockage local (si vous n’avez qu’un worker) mais sachez que vous n’aurez pas le même niveau de résilience ni les même facilités d’administration.

Si vous voulez un exemple de PersistentVolume utilisant NFS, je vous conseille cet article qui traite d’un sujet peu plus complexe mais qui donne les étapes de base pour mettre en place le PV et PVC : Créer un cluster PostgreSQL avec un seul et même Deployment en utilisant les StatefulSets.

Créer le Deployment postgreSQL

Voilà, on a tous les prérequis ! Il ne reste plus qu’à créer dans un premier temps notre base de données, puis notre XWiki. Comme indiqué au début, le Deployment contiendra tous les éléments qu’on a créé plus tôt, dont les Secrets et le Persistent Volume. Il manquera aussi un Service, que nous verrons plus tard.

cat > xwiki-pg.yaml << EOF
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-pg
labels:
app: xwiki-pg
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-pg
application: xwiki
template:
metadata:
labels:
app: xwiki-pg
application: xwiki
name: xwiki-pg
spec:
containers:
- image: postgres:9.6
name: xwiki-pg
env:
- name: POSTGRES_DB
value: xwiki
- name: PGDATA
value: /var/lib/postgresql/data/pgdata
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 5432
name: xwiki-pg
volumeMounts:
- name: xwiki-pg-storage
mountPath: /var/lib/postgresql/data/pgdata
volumes:
- name: xwiki-pg-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-pg
EOF
kubectl create -f xwiki-pg.yaml

Normalement, un Pod devrait se créer et monter le disque Gluster, puis s’initialiser avec les variables d’environnement qu’on lui a donné.

A partir de là, on ne peut cependant pas accéder à la base de données car on a pas encore créé le Service associé au Deployment. Par défaut, on ne donne pas de type, c’est donc un ClusterIP. Pour « savoir » vers quoi le Service doit rediriger, on a ajouté un Selector, qui pointe sur le tag « app » avec la valeur « xwiki-pg » définie plus haut.

cat > xwiki-pg-svc.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: xwiki-pg-svc
labels:
app: xwiki-pg
spec:
ports:
- port: 5432
protocol: TCP
selector:
app: xwiki-pg
EOF
kubectl create -f xwiki-pg-svc.yaml
service "xwiki-pg-svc" created

Créer le Deployment XWiki

Youhou ! Plus qu’un ! Ici pas de grosses différences, le principe est le même. On doit créer un Deployment puis un Service.

cat xwiki-tomcat.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: xwiki-app
labels:
app: xwiki-app
application: xwiki
spec:
replicas: 1
selector:
matchLabels:
app: xwiki-app
application: xwiki
template:
metadata:
labels:
app: xwiki-app
application: xwiki
name: xwiki-app
spec:
containers:
- image: zwindler/xwiki-tomcat8
name: xwiki-app
env:
- name: POSTGRES_INSTANCE
value: xwiki-pg
- name: POSTGRES_DB
value: xwiki
- name: POSTGRES_USER
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: username
- name: POSTGRES_PASSWORD
valueFrom:
secretKeyRef:
name: postgresql-xwiki-user-password
key: password
ports:
- containerPort: 8080
name: tomcat-port
volumeMounts:
- name: xwiki-app-storage
mountPath: /usr/local/tomcat/work/xwiki
volumes:
- name: xwiki-app-storage
persistentVolumeClaim:
claimName: gluster-pvc-xwiki-app
kubectl apply -f xwiki-tomcat.yaml
deployment "xwiki-app" created
cat xwiki-tomcat-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: xwiki-app-svc
labels:
apps: xwiki-app
spec:
type: NodePort
ports:
- port: 8080
targetPort: tomcat-port
protocol: TCP
selector:
app: xwiki-app
kubectl apply -f xwiki-tomcat-svc.yaml
service "xwiki-app-svc" created

Est-ce que ça marche ?

kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
gluster-cluster 10.96.114.181 <none> 1/TCP 4h
kubernetes 10.96.0.1 <none> 443/TCP 10d
xwiki-app-svc 10.103.218.140 <nodes> 8080:31484/TCP 4m
xwiki-pg-svc 10.108.219.88 <none> 5432/TCP 16m

Tout d’un coup

Chose promise chose due ! Je vous ai dit en début d’article que vous pouviez tout déployer en quelques lignes de commandes. Dans l’absolu, vous pourriez tout déployer via un seul fichier. Je préfère découpler la partie stockage (qui va dépendre du stockage que vous allez utiliser) et la partie secret du reste pour les raisons que j’ai énoncé plus haut. Voilà ce que ça donne :

On récupère les sources sur github

git clone https://github.com/zwindler/docker-xwiki

A adapter en fonction de votre contexte, à minima les adresses IP si vous avez du gluster, et carrément à réécrire si vous utilisez autre chose (NFS ou CEPH par exemple) :

kubectl apply -f docker-xwiki/kubernetes/gluster-endpoints-service.yaml
endpoints "gluster-cluster" created
service "gluster-cluster" created

On injecte ensuite les secrets. A vous de les changer comme on a vu plus haut.

kubectl apply -f docker-xwiki/kubernetes/postgresql_xwiki_user_password.yaml
secret "postgresql-xwiki-user-password" created

Et on fini par… tout le reste ! Là normalement il n’y a rien à changer à part éventuellement des ports, les seules « variables » dans ce déploiement étant le stockage et les mots de passes (qu’on vient de gérer).

kubectl apply -f docker-xwiki/kubernetes/xwiki-tomcat-pg-allinone.yaml
persistentvolume "gluster-pv-xwiki-pg" created
persistentvolume "gluster-pv-xwiki-app" created
deployment "xwiki-pg" created
persistentvolumeclaim "gluster-pvc-xwiki-pg" created
service "xwiki-pg-svc" created
deployment "xwiki-app" created
persistentvolumeclaim "gluster-pvc-xwiki-app" created
service "xwiki-app-svc" created

Le mot de la fin

Voilà, avec ce tutoriel vous avez maintenant une vue détaillée, étape par étape, de ce qu’il faut mettre en place pour gérer « proprement » le déploiement d’une application java + postgreSQL via Kubernetes.

Clairement, c’est bien plus complexe qu’un simple Docker compose comme j’ai pu le présenté dans l’article sur ce sujet. Pour autant, il faut comparer ce qui est comparable, les deux installations n’ont rien à voir !

D’un côté, vous avez une application déployée sur un nœud docker simple (éventuellement avec Swarm maintenant que les deux sont compatibles).

De l’autre, vous avez une application qui est déployée sur un cluster de machines :

Si l’une tombe en panne, la haute disponibilité est gérée : pas seulement sur le runtime, mais aussi sur le stockage !
Vous pouvez segmenter votre cluster en namespaces, et donner des droits à certains namespace à certains utilisateurs avec un gestion fine des autorisations (RBAC)
Vous disposez d’un dashboard et d’une API pour automatiser tous les déploiements (via Jenkins par exemple). Si vous voulez faire une mise à jour ou besoin de modifier un paramètre, c’est une simple commande ou un fichier de conf à appliquer à nouveau.
Vous avez la possibilité de faire du scaling up/down, voire de l’autoscaling.
…

La liste est longue ! En bref, vous passez d’une bidouille à la production.

Sources additionnelles

docs.openshift.org/latest/install_config/storage_examples/gluster_example.html (lien mort, pas dispo sur Internet Archive)
coderjourney.com/using-kubernetes-persistent-volumes/
www.xenonstack.com/blog/how-to-deploy-postgresql-on-kubernetes