Description
See #35234 for work items
Apply Details
To capture discussion on #1178, #1702, #13007, #17333, and other issues/PRs.
cc @jackgr @ghodss
Summary (to be transcribed into a doc):
Apply conceptually is intended to enable users to just specify a configuration and "make it so". But it's not that easy.
We represent default values explicitly in the API so that system components, ecosystem components, tools, and users don't need to reason about implicit behaviors, especially since such behaviors can change across API versions.
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#defaulting
We also want apply to work with automation, such as auto-scaling, and asynchronously filled-in values, such as node or IP assignments.
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#late-initialization
Therefore, unspecified values are (supposed to be) interpreted by apply as not managed by the user.
To do this, apply is implemented as a kind of 3-way merge, of their previous configuration, their new configuration, and the live state in apiserver/etcd. Obviously, this means that the previous configuration needs to be stored somewhere. It is currently stored in an annotation on each resource (#16543).
The diff-and-patch process has a few tricky issues. One is that we often don't want to overwrite arrays, which is standard json patch behavior, and we don't want to merge elements positionally, either. Many arrays have primary keys, similar to maps. We created a custom patch strategy to implement this behavior:
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md#strategic-merge-patch
One problem we haven't solved yet is that OneOf / union cases also need to be recognized, so that the previous value can be automatically nulled when a selection is changed (example of a OneOf issue: #24198).
We need to find a way to represent the merge strategy, merge keys, and OneOf relationships in Swagger (probably Swagger 2.0), as well. Otherwise, kubectl apply won't work properly with a cluster of a different release.
We need to clean up all cases in the API types.go files that don't properly allow us to distinguish unspecified values from default values (e.g., using pointers for optional fields).
We should ensure imperative mutations like scale, label, and annotate don't update the last-applied-configuration annotation by default, since that would cause those changes to get removed on the next apply if not added to the user's configuration file.
The user needs to be able to explicitly nil values when performing apply (so that needs to be fixed if it doesn't work).
We should detect conflicts between the live state and the applied state (#13576).
We should fix the handling of secret data (#23564, #20508).
We need a pattern to recommend for rolling out ConfigMaps (#22368). (I think changing the name of the ConfigMap should just work, once we have server-side cascading deletion.)
We should figure out how to automatically test apply #26234.
Search issues for "kubectl apply" to find other misc. bugs and features.