Kubernetes Operators — De l’enfer… au paradis

Kubernetes n’est pas compliqué.
Mais mal compris… c’est un enfer.

Kubernetes : délire d’Ops ?

On vous l’a vendu comme un truc d’infra

• Complexe
• Réservé aux DevOps
• Magie noire

Kubernetes = API + état + boucle

• API REST
• Base d’état
• Boucle de réconciliation
• Pas de mystère : des mécanismes explicites

De vos outils au noyau Linux

flowchart LR
    A[Clients] --> B[kube-api]
    B --> C[etcd]
    B --> D[Controllers]
    D --> E[kubelet]
    E --> F[containerd]
    F --> G[Kernel Linux]

• kube-api — point d’entrée
• etcd — source de vérité
• kubelet — agent sur chaque nœud
• container runtime (ex. containerd) — exécution des conteneurs

Kubernetes ne fait pas tourner vos apps

• Il orchestre
• Il délègue
• Il observe

Sous containerd : cgroups et namespaces

flowchart TD
    F[containerd] --> K[Linux Kernel]

• cgroups
• namespaces

Kubernetes vous évite de vivre dans le noyau

• Manipuler les cgroups à la main
• Gérer isolation, CPU, mémoire au niveau noyau

À côté de ça, un cluster qui râle, c’est presque du repos.

CNI, CSI, CRI : de l’infra branchable

• CNI → réseau (ex : Istio, Cilium ,Calico, Flannel, etc.)
• CSI → stockage (ex : Ceph, Longhorn , Amazon,etc.)
• CRI → runtime (ex : containerd, CRI-O,etc.)
• Ici : brancher l’infra — pas encoder la logique métier (≠ opérateur)

Brancher l’infra ou coder le métier ?

Qui écrit la logique du cluster ?

La logique vit dans les controllers

Ils ferment la boucle : observation, décision, action.

Les opérateurs : des controllers spécialisés

Automatiser le métier… en code dans le cluster

Sans opérateur : scripts, crons, humains dans la boucle

• Scripts bash
• Cron jobs
• Interventions humaines
• État incohérent

Automatisation éclatée : la logique reste dans les têtes

• Runbooks Confluence
• Scripts bash « magiques »
• Cron jobs oubliés
• Interventions humaines

Drift, pas de reproductibilité, 3 h du matin

• Drift de configuration
• Actions non reproductibles
• Dépendance aux humains
• Incidents à 3 h du matin

Vous déclarez ; le système réconcilie

kind: Database
spec:
  size: 3

Spec, opérateur, cluster : ça tourne en boucle

flowchart LR
    A[Spec] --> B[Operator]
    B --> C[Cluster]
    C --> B

Dès que le réel diverge, la réconciliation repart.

Reflector & Reloader : la puissance des annotations

• Reflector : annotations du type reflector.v1.k8s.emberstack.com/* pour autoriser la réflexion et cibler où copier.
• Reloader : reloader.stakater.com/auto: "true" (ou annotations plus fines par config) pour lier redéploiement ↔ mise à jour de config.

Cert-manager, Postgres, Keycloak : la spec devient une entité

La spec décrit l’état métier (cert, base, realm) ; le contrôleur crée / met à jour Deployments, Services, Secrets, etc.

Un certificat déclaratif, tout le cycle TLS en dessous

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-example
spec:
  dnsNames:
    - api.example.com

La suite est dérivée automatiquement :

• CertificateRequest
• Challenge ACME
• Secret TLS

Certificats : du Certbot au renouvellement automatique

Avant — sans opérateur

• Certbot manuel
• Scripts cron
• Cert expiré = prod down

Avec cert-manager

• Déclaratif
• Auto-renouvellement
• Observabilité native (Certificate, conditions, events)

Postgres répliqué sans bricoler le failover à la main

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: my-cluster
spec:
  numberOfInstances: 3

Derrière cette spec, le contrôleur s’occupe de :

• Réplication
• Failover
• Backup
• Users / rôles

Quand un opérateur est légitime

• Système complexe
• Règles claires et stables
• État critique pour l’activité
• Opérations répétitives

Keycloak Credential Manager — le même schéma, chez moi

• Objectif : réconcilier des credentials Keycloak (clients, secrets, rotation…) avec ce qui est déclaré dans le cluster (CRD, Secrets annotés, ou les deux — selon ton design).
• Intérêt conf : montrer le même schéma que les opérateurs « connus » : observe → compare → corrige sur ton domaine métier.

Ce qu’un opérateur bien choisi vous apporte

• Automatiser du répétitif
• Encapsuler de la complexité
• Stabiliser un système

Quand ne pas écrire d’opérateur

• Logique floue ou en perpétuelle négociation métier
• Processus instables (la règle change toutes les semaines)
• Dépendances externes imprévisibles
• One-shot : automatisation ponctuelle sans cycle de vie

Cinq signaux qu’un opérateur part en vrille

• Spec incompréhensible sans lire le code
• Effets implicites (créations ailleurs sans que ce soit visible)
• Couplage externe fort (APIs fragiles, ordre d’appels magique)
• Debug impossible sans les mainteneurs à côté de toi
• État non observable (pas de conditions / status utiles)

Débugger un opérateur : describe, events, status, logs

• kubectl describe (resource + events)
• Events du namespace
• Status / conditions sur la CRD
• Logs du contrôleur

Un opérateur, c’est un produit logiciel — pas un script

• Code et revues
• Tests (unitaires, intégration, e2e si possible)
• Maintenance dans la durée
• Compatibilité avec les versions Kubernetes
• Migrations de CRD / spec

Quand l’opérateur devient l’enfer

• Logique implicite
• Effets de bord
• Debugging difficile
• Couplage fort

En pratique, ça donne souvent :

• Tout mettre en opérateur
• Logique métier floue
• Effets cachés

Un opérateur mal conçu, c’est un microservice sous LSD.

Kubernetes, plateforme de programmation

• Kubernetes vous évite l’enfer de l’infrastructure bas niveau.
• Les bons opérateurs vous évitent l’enfer du manuel — les mauvais vous y renvoient autrement.

Avant d’écrire un opérateur : la checklist

• Répétitif
• Règles claires
• Déclaratif possible
• Idempotent
• Observable

Si une case importante manque, reculez : pas d’opérateur (ou pas tout de suite).

Votre logique, exécutée par le cluster au lieu d’un humain

Kubernetes simplifie l’infra — les opérateurs, ça peut simplifier ou empirer