-
Couldn't load subscription status.
- Fork 15.1k
Add docs for ApplySet-based pruning in kubectl apply #39818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 5 commits
be6f319
9eccf9d
2d00945
0a4e016
0207e38
eb007f2
1b58266
07b2089
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
KnVerey marked this conversation as resolved.
Show resolved
Hide resolved
|
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -371,44 +371,82 @@ to result in the user deleting something unintentionally: | |||||||||
| kubectl delete -f <filename> | ||||||||||
| ``` | ||||||||||
|
|
||||||||||
| ### Alternative: `kubectl apply -f <directory/> --prune -l your=label` | ||||||||||
| ### Alternative: `kubectl apply -f <directory/> --prune` | ||||||||||
|
|
||||||||||
| Only use this if you know what you are doing. | ||||||||||
| As an alternative to `kubectl delete`, you can use `kubectl apply` to identify objects to be deleted after | ||||||||||
| their manifests have been removed from a directory in the local filesystem. | ||||||||||
|
|
||||||||||
| {{< warning >}} | ||||||||||
| `kubectl apply --prune` is in alpha, and backwards incompatible | ||||||||||
| changes might be introduced in subsequent releases. | ||||||||||
| {{< /warning >}} | ||||||||||
| In Kubernetes {{< skew currentVersion >}}, there are two pruning modes available in kubectl apply: | ||||||||||
| - Allowlist-based pruning: This mode has existed since kubectl v1.5 but is still in alpha due to usability, correctness and performance issues with its design. The ApplySet-based mode is designed to replace it, and upon its graduation, allowlist-based pruning will be deprecated using beta timelines. | ||||||||||
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||
| - ApplySet-based pruning: An ApplySet is a server-side object (by default, a Secret) that kubectl can use to accurately and efficiently track set membership across `apply` operations. This mode was introduced in alpha in kubectl v1.27 as a replacement for allowlist-based pruning. Unlike allowlist-based pruning, it is under active development and is expected to ultimately become generally available. | ||||||||||
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||
|
|
||||||||||
| {{< tabs name="kubectl_apply_prune" >}} | ||||||||||
| {{% tab name="Allowlist" %}} | ||||||||||
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||
|
|
||||||||||
| {{< feature-state for_k8s_version="v1.5" state="alpha" >}} | ||||||||||
|
|
||||||||||
| {{< warning >}} | ||||||||||
| You must be careful when using this command, so that you | ||||||||||
| do not delete objects unintentionally. | ||||||||||
| Only use this if you know what you are doing. You must be careful when using this command, so that you do not delete objects unintentionally. For more information on the problems with this command, see the [Current Implementation](git.k8s.io/enhancements/keps/sig-cli/3659-kubectl-apply-prune#current-implementation) section of the ApplySet KEP. | ||||||||||
|
||||||||||
| Only use this if you know what you are doing. You must be careful when using this command, so that you do not delete objects unintentionally. For more information on the problems with this command, see the [Current Implementation](git.k8s.io/enhancements/keps/sig-cli/3659-kubectl-apply-prune#current-implementation) section of the ApplySet KEP. | |
| Take care when using `--prune` with `kubectl apply` in allow list mode. The kubectl command must dynamically discover | |
| and infer which objects should be removed as part of the prune operation, and the heuristics for this | |
| can sometimes mean that kubectl deletes objects that did not require pruning. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reverse is also true--it can orphan objects that should have been pruned. And user choices regarding the allowlist and labels flags can also cause and/or exacerbate either issue.
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional extra fix:
containing the object manifests. Running against sub-directories
KnVerey marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a note or a caution here. Warning is for “this could break your cluster if you don't get it right”; if that's really the casefor apply set pruning, I think we should probably revert it until we're more confident.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just intended as a standard alpha warning, so I'll switch it to caution I guess? This feature is more dangerous than others not because it is incomplete or particularly immature or anything like that; simply because its purpose is to perform destructive actions (deletions), which makes misunderstandings/misuse more consequential. Our unit test coverage is very good (MUCH better than what's there for allowlist-based pruning), and we have a basic multi-step e2e in place as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This warning is why I'd probably not document the labels in the other file, not yet. If we decide to go with a resource, rather than label it'll be confusing and we'll have users relying on alpha feature, which is not plainly obvious in that other file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine documenting it here, under the alpha tag, if there's a desire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We register labels or annotation as soon as released code might either set them or heed them.
If someone sees a label set on an object and we've not documented that label, it doesn't leave as good an impression.
There's another aspect too: keys are “insta-durable” in as much as the first use we make of them, we're on the hook forever to explain what that label does or did mean. Plenty of the well-known labels are documented as deprecated, but a bit like with stable APIs, once they're registered we never delete the registration.
If it's helpful to, we can:
-### applyset.k8s.io/tooling
+### applyset.k8s.io/tooling (alpha) {#applyset-k8s-io-tooling}and similar, to mark that the key is alpha. No problem there. Notice how I overrode the fragment identifier so that bookmarks etc still work after graduation to beta or stable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to document
kubectl.kubernetes.io/last-applied-configuration(used for legacy pruning) too.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should got in my other PR against main, or maybe even its own PR. I'm quite shocked that it isn't already documented; that one has been in use since the very beginning AFAIK. Pruning hijacks it, but it is critical to the functioning of
applyitself (the old client-side implementation; SSA works differently).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Help welcome here. This PR can merge, anyway.