Kubernetes pour une stack open source : déployer et gérer ses services avec k8s et Helm

Kubernetes (k8s) s’est imposé comme la référence pour l’orchestration de conteneurs en production. Longtemps perçu comme réservé aux grandes équipes, il est aujourd’hui accessible à toute organisation gérant une stack open source multi-services — que ce soit pour déployer un portail CKAN, une instance Nextcloud, un service Keycloak ou une chaîne de traitement de données. Cet article présente les concepts fondamentaux et une approche concrète pour commencer avec k8s dans un contexte open source.

Pourquoi passer à Kubernetes ?

Docker Compose suffit pour un hébergement simple sur une seule machine. Kubernetes devient pertinent dès lors que l’on cherche à garantir la haute disponibilité, à scaler certains composants indépendamment, ou à gérer des déploiements sur plusieurs nœuds. Les apports concrets sont :

Redémarrage automatique des conteneurs défaillants (self-healing)
Mise à jour sans interruption de service (rolling updates)
Scalabilité horizontale par service (HPA — Horizontal Pod Autoscaler)
Gestion centralisée des secrets, ConfigMaps et volumes
Observabilité native via des sondes de liveness et readiness

Les objets essentiels de Kubernetes

Avant de déployer quoi que ce soit, il faut maîtriser quelques objets de base :

Pod

L’unité atomique de Kubernetes. Un pod encapsule un ou plusieurs conteneurs partageant le même réseau et les mêmes volumes. On ne gère généralement pas les pods directement, mais via des objets de plus haut niveau.

Deployment

Définit l’état souhaité pour un ensemble de pods — nombre de réplicas, image Docker, stratégie de mise à jour. C’est l’objet central pour tout service sans état (stateless) comme une API, un frontend, ou un reverse proxy.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ckan
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ckan
  template:
    metadata:
      labels:
        app: ckan
    spec:
      containers:
      - name: ckan
        image: ckan/ckan-base:2.10
        ports:
        - containerPort: 5000
        envFrom:
        - configMapRef:
            name: ckan-config

Service

Expose un ensemble de pods à l’intérieur du cluster (ClusterIP), sur l’hôte (NodePort), ou via un load balancer externe (LoadBalancer). Couplé à un Ingress, il permet de router le trafic HTTP/HTTPS vers les bons services.

StatefulSet

Variante du Deployment pour les services avec état (bases de données, caches persistants). Garantit l’identité stable des pods et un ordre de démarrage/arrêt contrôlé — indispensable pour PostgreSQL, Solr, ou Redis.

Ingress

Point d’entrée HTTP/HTTPS du cluster. Combiné à un contrôleur Ingress (nginx-ingress, Traefik), il route les requêtes vers les services en fonction du nom de domaine ou du chemin, et gère la terminaison TLS.

Helm : le gestionnaire de paquets pour k8s

Helm joue pour Kubernetes le rôle qu’apt joue pour Debian. Il packette les manifests YAML en « charts » réutilisables et paramétrables. Cela permet de déployer des applications complexes en une seule commande, et de gérer leurs mises à jour de façon reproductible.

# Ajouter le dépôt Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Déployer PostgreSQL avec un fichier de valeurs personnalisé
helm install my-postgres bitnami/postgresql \
  --namespace data \
  --create-namespace \
  --values postgres-values.yaml

Un fichier values.yaml permet de surcharger n’importe quel paramètre du chart — ressources CPU/mémoire, taille des volumes, mots de passe, nombre de réplicas — sans modifier les templates. C’est le pattern recommandé pour gérer différents environnements (dev, staging, production).

Structure recommandée pour une stack open source

Pour une infrastructure typique (portail open data + authentification + stockage), une organisation par namespace facilite la gestion :

namespace data : CKAN, PostgreSQL, Solr, Redis
namespace auth : Keycloak, sa base de données dédiée
namespace storage : MinIO pour le stockage objet S3
namespace monitoring : Prometheus, Grafana, Loki (via la chart kube-prometheus-stack)
namespace ingress : Contrôleur Ingress + cert-manager pour TLS automatique

Premiers pas pratiques

Pour expérimenter en local, k3s (distribution légère de Kubernetes) ou kind (Kubernetes in Docker) permettent de démarrer un cluster en quelques minutes. La progression naturelle est la suivante :

Installer kubectl et configurer le contexte du cluster
Déployer un premier service simple (ex. : Nginx) avec un Deployment + Service
Ajouter un Ingress et un certificat TLS avec cert-manager
Gérer les secrets avec des Kubernetes Secrets (puis évoluer vers External Secrets Operator + Vault)
Packager ses propres services dans des charts Helm maison
Mettre en place un pipeline GitOps avec ArgoCD ou Flux pour synchroniser l’état du cluster depuis Git

Limites et points d’attention

Kubernetes introduit une complexité opérationnelle non négligeable. Quelques points à considérer avant de se lancer en production :

La gestion des volumes persistants (PVC/PV) nécessite un CSI driver adapté à votre infrastructure de stockage
Les mises à jour de Kubernetes lui-même (nouvelle version mineure tous les 3-4 mois) requièrent une politique de maintenance active
La sécurité du cluster (RBAC, Network Policies, Pod Security Admission) demande une configuration explicite — les défauts ne sont pas sécurisés
Pour des stacks légères sur une seule machine, Docker Compose reste souvent plus pragmatique

Kubernetes est un investissement : sa courbe d’apprentissage est réelle, mais les bénéfices en termes de résilience, de scalabilité et de standardisation des déploiements sont significatifs dès lors que la stack dépasse 5-6 services distincts.