Installer et configurer un opérateur

Faire tourner PostgreSQL dans Kubernetes avec un StatefulSet, c'est facile. L'exploiter l'est beaucoup moins : réplication, bascule quand le primaire tombe, sauvegardes, mises à jour mineures, rotation des mots de passe. Un opérateur encode ce savoir-faire dans un contrôleur (leçon 2.19) : vous décrivez l'état voulu (« une base à 2 instances »), il fait le travail d'un administrateur de bases de données, en continu. Cette leçon présente un opérateur réel, CloudNativePG, à travers son installation et la base qu'on lui confie. Elle est théorique : un opérateur et sa base demandent plus de ressources qu'un cluster d'exercice ; les commandes sont celles que vous taperiez sur un vrai cluster.

Ce que vous saurez à la fin : installer un opérateur et vérifier son fonctionnement, créer une ressource personnalisée qu'il gère, lire le status qu'il entretient, observer sa réconciliation, et évaluer un opérateur avant de l'adopter en production.

1. Ce qu'apporte un opérateur

Vous écrivez	L'opérateur crée et entretient
un objet Cluster : 2 instances, 1Gi de disque	des pods (un primaire, un réplica), un disque par instance, des Services -rw (écriture) et -ro (lecture), un Secret d'accès, la réplication, la bascule automatique, la supervision

Il se compose de CRD (les nouveaux types) et d'un contrôleur qui les réconcilie. Il installe souvent aussi des webhooks pour valider vos objets et compléter leurs valeurs par défaut.

2. Installer l'opérateur

CloudNativePG est un projet de la CNCF. Il publie un manifeste par version :

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.30/releases/cnpg-1.30.1.yaml

Le manifeste crée le namespace cnpg-system, les CRD (clusters.postgresql.cnpg.io, backups, poolers…), les droits RBAC de l'opérateur, ses webhooks et son Deployment. Vérifiez qu'il est prêt avant d'aller plus loin :

Le manifeste ne fixe pas les ressources de l'opérateur. Sur un cluster avec quotas, bornez-les tout de suite, stockage temporaire compris (sinon chaque conteneur reçoit la valeur par défaut du namespace, parfois généreuse) :

kubectl -n cnpg-system set resources deployment cnpg-controller-manager \
  --requests=cpu=20m,memory=64Mi,ephemeral-storage=16Mi \
  --limits=cpu=500m,memory=256Mi,ephemeral-storage=128Mi
kubectl -n cnpg-system rollout status deployment cnpg-controller-manager
kubectl get crd | grep cnpg.io

Un opérateur a souvent besoin de droits étendus (créer des pods, des Secrets, des Services dans tous les namespaces). Lisez son ClusterRole avant de l'installer en production : c'est du code tiers avec un accès large à votre cluster.

3. Lui confier une base

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: base
spec:
  instances: 1
  storage:
    size: 1Gi
  resources:
    requests: {cpu: 50m, memory: 128Mi, ephemeral-storage: 32Mi}
    limits: {cpu: 500m, memory: 384Mi, ephemeral-storage: 256Mi}

kubectl get cluster base -w              # STATUS passe à « Cluster in healthy state »
kubectl get pods,pvc,svc,secrets -l cnpg.io/cluster=base

L'opérateur crée les pods un par un (base-1, base-2…), chacun avec son PVC, les Services base-rw (toujours le primaire) et base-ro (les réplicas), et le Secret base-app, qui contient l'utilisateur et le mot de passe de la base applicative app.

4. Lire ce que fait l'opérateur

Comme tout contrôleur, l'opérateur rend compte dans le status de l'objet et dans ses événements :

kubectl describe cluster base                       # phase, instances prêtes, primaire actuel
kubectl get cluster base -o jsonpath='{.status.readyInstances}'
kubectl -n cnpg-system logs deploy/cnpg-controller-manager | tail

5. La réconciliation en action

Modifiez l'objet : l'opérateur fait le reste. Passer de 1 à 2 instances crée un réplica, le synchronise sur le primaire et l'ajoute au Service base-ro. Supprimez le pod primaire : l'opérateur promeut le réplica et recrée l'instance manquante. Ce sont des opérations qui demandent des heures de procédure à la main.

Ce que l'opérateur ne fait pas à votre place : choisir la taille des disques, définir et tester la restauration des sauvegardes, ou surveiller que tout va bien. L'automatisation déplace le travail, elle ne le supprime pas.

6. Choisir un opérateur

Avant d'adopter un opérateur en production :

• maturité : projet actif, versions régulières, documentation de mise à jour, adoption ;
• niveau d'automatisation : simple installation, ou aussi mises à jour, sauvegardes, bascule, réglage automatique ? (le modèle des « capability levels » d'Operator Framework sert de grille) ;
• droits demandés et périmètre surveillé (tout le cluster ou certains namespaces) ;
• sortie : que deviennent vos données si vous retirez l'opérateur ?

Pour aller plus loin

Sur un cluster de test qui a de la marge (un k3s ou un kind sur votre poste, par exemple), refaites le parcours de bout en bout :

1. installez l'opérateur CloudNativePG 1.30.1 et attendez que cnpg-controller-manager soit prêt, puis bornez ses ressources (section 2) ;
2. créez le Cluster PostgreSQL base de la section 3 et attendez qu'il soit sain (kubectl get cluster base -w) ;
3. créez une table et une ligne dans la base app :

kubectl exec -it base-1 -c postgres -- psql -d app

CREATE TABLE inscriptions (id serial PRIMARY KEY, nom text);
INSERT INTO inscriptions (nom) VALUES ('Ada');
\q

4. passez instances à 2 et observez l'opérateur créer, synchroniser puis brancher le réplica ; supprimez ensuite le pod primaire et regardez la bascule.

Validez la leçon avec le questionnaire.