Kubernetes 1.37 rend la migration de version de stockage native et activee par defaut

Le projet Kubernetes a annonce la disponibilite generale (GA, statut de version finale stabilisee pour la production) de la fonctionnalite de migration des versions de stockage (SVM, pour Storage Version Migration) au sein de la version v1.37. Desormais pilote par l'API storagemigration.k8s.io/v1 et active par defaut dans le plan de controle (control plane, l'ensemble des composants d'administration du cluster), ce mecanisme natif resout un probleme historique de gestion de la persistance des objets.

Le probleme des schémas de stockage obsolètes

Dans Kubernetes, les ressources sont enregistrees dans la base de donnees sous une version de stockage specifique (la representation du schema). Lorsqu'une CRD (CustomResourceDefinition, une extension permettant d'ajouter ses propres types d'objets dans le cluster) evolue pour abandonner une ancienne version comme v1alpha1 au profit de v1, les objets existants restent chiffres ou serialises sous l'ancien schema dans la base tant qu'aucune reecriture n'a lieu. Impossible alors de supprimer sereinement la prise en charge de l'ancienne version. Un probleme identique survient lors du chiffrement des donnees au repos (encryption at rest) ou lors d'une rotation de clés de chiffrement : les objets restent bases sur les anciennes clés tant qu'ils ne sont pas reecrits via l'API server.

Jusqu'a present, les equipes devaient utiliser des scripts manuels a base de kubectl replace ou installer l'outil externe kube-storage-version-migrator. La version 1.37 automatise enfin cette operation de maniere propre et fiable.

Un fonctionnement declaratif simplifie

Pour lancer une migration, il suffit désormais de creer un objet declaratif de type StorageVersionMigration. Le controleur StorageVersionMigrator, directement integre au plan de controle, surveille ces objets et effectue automatiquement la reecriture des ressources vers la version de stockage par defaut.

Voici un exemple concret de manifeste permettant de migrer une ressource personnalisee crontabs :

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

Suivi et integration dans les manifestes

Le controleur met a jour l'etat de l'objet au fur et a mesure de la migration. Les administrateurs peuvent inspecter l'avancement via la commande kubectl get storageversionmigration.storagemigration.k8s.io/crontabs-migration -o yaml. Une migration reussie affiche la condition Succeeded definie a True.

Une fois l'operation terminee, les auteurs de CRD peuvent mettre a jour le champ .status.storedVersions pour ne conserver que la version souhaitee. Il est egalement possible d'inclure directement la ressource StorageVersionMigration au sein du meme fichier YAML que la mise a jour de la CRD afin d'automatiser le processus lors des deploiements.