Retour — 02 Production & SRE

SIOPS — plateforme Kubernetes de production

Cluster RKE2 sur OpenStack opéré à cinq, quatre clients hébergés, et les incidents qui vont avec.

Rôle

Product Owner

Équipe

5 personnes

Plateforme

RKE2 v1.32 / OpenStack

Méthode

Kanban, Linear

La plateforme

SIOPS est l'équipe DevOps/SRE interne de la majeure SIGL. Elle opère un cluster Kubernetes réellement en production : d'autres équipes y hébergent leurs applications, s'y connectent tous les jours et remontent quand ça casse. Ce n'est pas un lab qu'on reconstruit le lundi matin.

Mon rôle — Product Owner

Je tiens le backlog de l'équipe et j'arbitre ce qui passe. Concrètement : traduire une demande client en incrément livrable, décider ce qu'on ne fait pas ce sprint, et défendre cet arbitrage devant les clients comme devant l'équipe.

Ce n'est pas un rôle de façade : je suis dans les logs et sur les post-mortems. C'est précisément pour ça que les arbitrages tiennent — je sais ce que coûte réellement une demande qui paraît anodine.

Cassiopée — portail self-service GitOps

Avant Cassiopée, chaque demande d'environnement passait par un membre de l'équipe plateforme. Le portail transforme ce parcours en self-service piloté par Git.

Un utilisateur demande une application, une base de données, un bucket S3 ou une ingress. Le portail écrit le values.yaml correspondant dans le dépôt GitOps ; ArgoCD réconcilie. Les credentials sont générés à la volée et stockés dans Vault — ils ne transitent jamais par le dépôt. Les quotas sont appliqués par groupe.

FastAPI · ArgoCD · Helm · HashiCorp Vault · Swift / RGW

Résultat : un environnement complet déployé par commit, sans intervention de l'équipe plateforme. [TODO: métrique] nombre d'environnements provisionnés via le portail.

Incidents & post-mortems

INC-01 — Le cluster se bloque lui-même au redémarrage

Symptôme. master-1 injoignable, API server instable, cluster en fonctionnement dégradé.

Diagnostic. Le nœud était sous-dimensionné. Sous pression mémoire, l'OOM killer tue etcd et le quorum tombe à 2/3. Pire, la remise en route se bloque elle-même : rke2-server attend kubelet, kubelet attend le static pod etcd, et etcd ne redémarre plus. Interblocage à trois.

Correctif. rke2-killall pour casser la boucle, puis redémarrage propre du nœud — et redimensionnement du master pour que la cause ne revienne pas.

Leçon. Un control plane ne se dimensionne pas comme un worker. Les ressources d'etcd sont une contrainte de disponibilité, pas une ligne de facture qu'on rogne.

INC-02 — Trois semaines sans sauvegarde, et les jobs étaient verts

Symptôme. Plus aucun snapshot récent dans le dépôt. Les jobs de sauvegarde, eux, remontaient en succès.

Diagnostic. Le quota S3 de 500 GiB était saturé. Le dépôt restic pesait 486 GiB pour 349 snapshots jamais purgés : le nom de dump embarquait la date, donc chaque sauvegarde créait son propre groupe et la politique de rétention ne s'appliquait à rien. Le nettoyage n'avait jamais rien eu à nettoyer.

Correctif. Montée de version de restic, puis forget --group-by host suivi de prune : le dépôt passe de 486 GiB à 48 GiB. Script de sauvegarde durci avec set -euo pipefail et un nom de dump stable.

Leçon. Un job vert ne prouve rien. Ce qu'il faut surveiller, c'est l'âge du dernier snapshot restaurable — pas le code de sortie du cron. Et un script sans set -e ment sur son propre statut.

INC-03 — La chaîne de descellement Vault se mord la queue

Symptôme. Audit de la chaîne de démarrage de Vault, mené après un redémarrage de la plateforme.

Diagnostic. L'auto-unseal transit du Vault principal s'appuie sur un Vault secondaire, lui-même scellé en Shamir et déployé en réplique unique. Si le secondaire tombe, plus rien ne se descelle — y compris les secrets dont on a besoin pour le remonter. Un SPOF, avec une dépendance circulaire au démarrage.

Correctif. SPOF identifié, documenté et porté au backlog avec ses options de sortie. [TODO: statut de la remédiation]

Leçon. Une dépendance circulaire au démarrage est invisible en régime nominal. Elle se voit le jour où tout redémarre en même temps — c'est-à-dire le pire jour possible.

Mutualisation des ressources — une décision produit

Chaque groupe disposait d'un quota fixe, calibré au plus juste. Le résultat était le pire des deux mondes : de la capacité réservée qui dormait d'un côté, des équipes bloquées à livrer des maquettes de l'autre.

J'ai porté le passage à un pool commun. La capacité va là où il y a de la demande réelle, au lieu d'être gelée par un tableau de quotas. Le pari est assumé : on accepte un risque de contention pour que les équipes mènent de vrais projets plutôt que des démonstrations.

[TODO: métrique] taux d'utilisation du pool avant et après la bascule.

Ce que j'en retire

La partie technique s'apprend. Ce qui s'apprend moins vite, c'est d'arbitrer sous contrainte : dire non à une demande légitime parce que la capacité n'est pas là, assumer un SPOF connu le temps de le traiter proprement, et expliquer les deux à un client sans se cacher derrière du jargon.