Also, kustomize appends content-based hashes to the suffixes of ConfigMap names in order to facilitate rollouts:
kubernetes/kubernetes#22368

However, there's no mechanism in Kubernetes to garbage collect them.
https://groups.google.com/g/kubernetes-sig-apps/c/d_zV4esoNF8
https://github.com/kubernetes/community/pull/1163/files

Previous versions should not be pruned immediately because they are used by previous ReplicaSets during rolling updates, so that requires special pruning logic to not delete them too soon, and perhaps to delete them when they are no longer used.

We may want to look at approaches that handle this at run time.
kubernetes/enhancements#948
https://github.com/mattmoor/boo-maps
gardener-attic/gardener-resource-manager#104
https://www.tigera.io/blog/solving-kubernetes-configuration-woes-with-a-custom-controller/
https://github.com/gopaddle-io/configurator

Without changes to the core workload controllers, though, a runtime mechanism that changed the pod template would conflict with GitOps controllers, but there's no other way to make pod template revisions point at specific ConfigMap revisions. Changing an underlying ReplicaSet out of band would fight with the Deployment controller.

This could be done client-side, as kustomize does. Garbage collection could also be done client-side, by keeping the same number of ConfigMap revisions as the history setting on the workload controllers that consume them. That would avoid a change to the pruning mechanism, also.

ConfigMap generation #3119

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions