Join us
@dineshparvathaneni ă» Dec 20,2021 ă» 2 min read ă» 5686 views
Some guidelines for Kubernetes operator developers on how to version their CRDs
CRDs are similar to K8s built-in types and the expectation for operator developers is to follow same guidelines when it comes to their versioning. But k8s doesnât enforce them.
CRD basics:
K8s recommended approach for versioning
CRD Examples
I looked at the CRDs for some of the operator deployed apps. Many of them doesnât have a conversion webhook. This is because either many of them donât make any schema changes or donât understand the need for conversion hooks when there are schema changes across crd versions. Even if the old versions are not actively served conversion hooks are still needed to support converting already stored old version CRs in the etcd to latest version.
Percona
crd: https://github.com/percona/percona-xtradb-cluster-operator/blob/main/deploy/crd.yaml
While Percona application strive to always make backward compatible changes(all crd versions are served), it doesnât follow k8s approach. This is because
CertManager
crd: https://github.com/jetstack/cert-manager/blob/master/deploy/crds/crd-certificaterequests.yaml
This is one CRD where conversion webhook is used. Looks this is because of api field renaming from âcsrâ to ârequestâ. Although a breaking api change not a backward incompatible change, so they continued to serve both versions and the conversion is handled by webhook. This operator follows the k8s guidelines.
Join other developers and claim your FAUN account now!
Influence
Total Hits
Posts
Only registered users can post comments. Please, login or signup.