Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

ADR: CRD Versioning

Offen
  • Stimmt etwas nicht?
#450 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Dokumentation
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
kubernetes, rust
Bereich
documentation

Rechercherichtung

Beginne mit der verknüpften Kubernetes-Dokumentation zu Versions in CustomResourceDefinitions und prüfe anschließend die Überlegungen zu conversion webhook, upgrade-only, release-skipping und CRD-size in diesem Issue. Ein ADR ist abgeschlossen, wenn es die Entscheidungsfaktoren und eine minimal funktionsfähige Implementierung festhält, einschließlich der Frage, ob two-way conversion und kopierte Rust-Structs erforderlich sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Below are some prelimiary thoughts on the topic of CRD versioning, mostly taken from the on-site meeting on this topic. For an ADR, my suggestion is to gather requirements about how it should work from this Kubernetes docs page: Versions in CustomResourceDefinitions - Kubernetes Documentation. It looks like a comprehensive guide on how the versioning works.

Conversion webhooks & up- and downgrading

mutating webhooks are the core mechanism required for versioning CRDs. If an old resource is applied by the user, the webhhook will convert it into the current version. Likewise, if the users requests and older version (arbirary versions can be requested) then the webhook is also used for conversion. (Note from felix: Does that mean that two way conversion is absolutely a thing that needs to be implemented?)

When you read an object, you specify the version as part of the path. You can request an object at any version that is currently served. If you specify a version that is different from the object's stored version, Kubernetes returns the object to you at the version you requested, but the stored object is not changed on disk.

We cannot remove (mandatory) fields, because their content will be required when downgrading. This means we have to rename the fields (i.e. deprecated_oldField).

Only support upgrades for now (no downgrading)
Do not skip releases - always upgrade only one version up (v1 -> v2 -> v3 not v1 -> v3)

CRD size

CRD size is a problem: etcd and the kube API both have limits on how large objects are allowed to be.

copy & paste - To have multiple versions in our CRD, we need to keep the old rust struct around. this means copy pasting the rust struct for each verison. Not ideal ....

stabilize CRDs first to reduce conversion efforts? Would be nice beause it saves a lot of work. But CRD versioning is important now.

ADR thoughts

  • What are the decision drivers?
  • What could a minimally viable implementation look like?
Vorherrschende Sprache
CSS
Sterne
13
Forks
14
Ø Merge
1 T. 13 Std.
Gemergte PRs (30 T.)
29

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus stackabletech/documentation

Alle Issues in stackabletech/documentation

Ähnliche Issues

Weitere Issues zu Documentation

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.