Description
Motivation
Presently, the GITOPS pattern is widely considered a best-practise to deploy to kubernetes. But it is not without its flaws because it requires a lot of additional tooling (repository, gitops server, password store) that a) needs to be operated and b) effectively introduces vendor lock-in and need for plugins to pupoulate chart values with secrets. This unfortunate situation could be fully aleviated by implementing chart repositories natively in kubernetes as proposed in this KEP.
ETCD already supports revisions
etcd supports retrieving object revisions
via etcdctl get --rev= and can be configured to keep full object history by disabling autocompaction, i.e. --auto-compaction-retention 0. See https://etcd.io/docs/v3.5/op-guide/configuration/.
But kube-apiserver does not
Unfortunately, kube-apiserver does not yet support retrieval of object revisions. This would however be desirable because it would open up the possibility of implementing source code repositories natively in kubernetes.
Vision in Practice
- A k8s operator could define a CRD
repositoryand offer diff, merge, commit operations - GITOPS style pipeline operations could run natively in kubernetes by executing pipeline code as pods
- Kubernetes secrets could be used to fill in helm chart values that otherwise would have to be retrieved from a secret store like Vault.
- Most relevant use-case is implementation of helm chart repositories with GITOPS operations natively in kubernetes.
- Could be extended to full-blown git repositories by adding an external blob-store to etcd (which does not work well for files larger than ~ 1MB)