Kubernetes réécrit vos objets stockés

Ce qui se passe

La storage version migration (SVM) passe en disponibilité générale dans Kubernetes v1.37. L'API intégrée storagemigration.k8s.io/v1 et son contrôleur de plan de contrôle sont désormais stables et activés par défaut sur tous les clusters v1.37. L'annonce est signée Michael Aspinwall (Google).

Le problème qu'elle résout est invisible tant qu'on ne le rencontre pas : une ressource est écrite en base avec la version de schéma en vigueur au moment de l'écriture, et rien ne la réécrit ensuite. Désigner une nouvelle version de stockage ne change que les écritures à venir.

Pourquoi ça compte

Deux opérations butaient là-dessus.

Retirer une ancienne version d'une CRD. Vous promouvez crontabs.example.com pour que v1 devienne la version de stockage. Les objets créés avant restent sérialisés en v1alpha1 ou v1beta1. Tant que c'est le cas, impossible de nettoyer .status.storedVersions ni de cesser de servir l'ancienne version sans risque.

Le chiffrement au repos et la rotation de clés. Quand vous activez le chiffrement ou changez de clé, les objets déjà stockés restent en clair — ou chiffrés sous l'ancienne clé — jusqu'à ce qu'une écriture les repasse par l'API server. C'est le cas où l'illusion de protection coûte le plus cher.

Jusqu'ici, la réponse était des scripts kubectl get / kubectl replace, ou le déploiement du composant hors-arbre kube-storage-version-migrator : fastidieux, faciles à rater, difficiles à superviser.

Comment s'y prendre

La migration est un objet déclaratif. Le contrôleur StorageVersionMigrator observe ces objets et réécrit les ressources existantes vers la version de stockage par défaut de l'API concernée.

YAML

apiVersion: storagemigration.k8s.io/v1
kind: StorageVersionMigration
metadata:
  name: crontabs-migration
spec:
  resource:
    group: example.com
    resource: crontabs

Terminal

kubectl apply -f crontabs-migration.yaml
kubectl get storageversionmigration.storagemigration.k8s.io/crontabs-migration -o yaml

Le statut est lisible sur l'objet : une condition Running puis une condition Succeeded à "True", avec la raison StorageVersionMigrationSucceeded.

Comme il s'agit d'une API Kubernetes standard, un auteur de CRD peut livrer la migration dans le même manifeste que la mise à jour de la définition, séparée par un ---. La migration devient une étape de la release, pas une tâche d'exploitation à ne pas oublier.

Source : Kubernetes Blog — Kubernetes v1.37: Storage Version Migration Enabled by Default