DEUX classes de stockage sont marquées (default) — tout PVC sans storageClassName est non déterministe #33

Open
opened 2026-09-03 00:50:28 +02:00 by arcodange · 0 comments
Owner

Trouvé en inventoriant Longhorn pour #31.

NAME                   PROVISIONER             ...
local-path (default)   rancher.io/local-path
longhorn (default)     driver.longhorn.io
longhorn-static        driver.longhorn.io

Les deux portent storageclass.kubernetes.io/is-default-class: "true".

Pourquoi ça compte

Un PVC qui n'écrit pas storageClassName explicitement se voit attribuer « la » classe par défaut. Avec deux candidates, le comportement dépend de la version de Kubernetes et de l'ordre de création — il n'est ni stable, ni lisible, ni reproductible. Concrètement : le même manifeste peut donner un volume répliqué sur trois nœuds ou un répertoire local sur un seul, sans que rien ne le dise.

C'est la différence entre « survit à la mort d'un nœud » et « meurt avec lui », décidée par hasard.

Ce qui est mesuré aujourd'hui

Les 15 volumes existants nomment tous leur classe explicitement (longhorn), donc rien n'est cassé en l'état. Le risque porte sur le prochain PVC écrit sans la nommer — et ça ne produira aucune erreur, juste un volume dont personne ne sait ce qu'il garantit.

Le remède

Retirer l'annotation de défaut de l'une des deux. Le choix n'est pas neutre et mérite d'être écrit :

  • longhorn par défaut — un oubli donne de la redondance. Coûteux, mais sûr. ⚠ C'est aussi ce qui a fait passer 15 volumes sur une couche dont #31 montre la fragilité.
  • local-path par défaut — un oubli donne un volume local, rapide, sans filet. ⚠ Un oubli devient alors une perte de données silencieuse.
  • AUCUNE par défaut — tout PVC DOIT nommer sa classe, sinon il reste Pending et ça se voit. Le plus verbeux, et le seul qui ne se trompe jamais en silence.

Recommandation : aucune par défaut. Un Pending visible vaut mieux qu'un volume dont la garantie dépend de l'ordre de création des classes.

Refs #31.

Trouvé en inventoriant Longhorn pour #31. ``` NAME PROVISIONER ... local-path (default) rancher.io/local-path longhorn (default) driver.longhorn.io longhorn-static driver.longhorn.io ``` **Les deux portent `storageclass.kubernetes.io/is-default-class: "true"`.** ## Pourquoi ça compte Un PVC qui n'écrit pas `storageClassName` explicitement se voit attribuer « la » classe par défaut. Avec deux candidates, le comportement dépend de la version de Kubernetes et de l'ordre de création — il n'est ni stable, ni lisible, ni reproductible. Concrètement : **le même manifeste peut donner un volume répliqué sur trois nœuds ou un répertoire local sur un seul**, sans que rien ne le dise. C'est la différence entre « survit à la mort d'un nœud » et « meurt avec lui », décidée par hasard. ## Ce qui est mesuré aujourd'hui Les 15 volumes existants nomment tous leur classe explicitement (`longhorn`), donc **rien n'est cassé en l'état**. Le risque porte sur le **prochain** PVC écrit sans la nommer — et ça ne produira aucune erreur, juste un volume dont personne ne sait ce qu'il garantit. ## Le remède Retirer l'annotation de défaut de **l'une** des deux. Le choix n'est pas neutre et mérite d'être écrit : - **`longhorn` par défaut** — un oubli donne de la redondance. Coûteux, mais sûr. ⚠ C'est aussi ce qui a fait passer 15 volumes sur une couche dont #31 montre la fragilité. - **`local-path` par défaut** — un oubli donne un volume local, rapide, sans filet. ⚠ Un oubli devient alors une perte de données silencieuse. - **AUCUNE par défaut** — tout PVC DOIT nommer sa classe, sinon il reste `Pending` et ça se voit. Le plus verbeux, et le seul qui ne se trompe jamais en silence. Recommandation : **aucune par défaut**. Un `Pending` visible vaut mieux qu'un volume dont la garantie dépend de l'ordre de création des classes. Refs #31.
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/tools#33