delete-local-data was deprecated back in v1.20 with this commit:
625e47aaa2
It's about time we entirely drop the support for this flag. Users should
be already using delete-emptydir-data instead.
Kubernetes-commit: 4b5cf0a2766c02ba88b5d104a79c16b1f1f367b6
When it initially landed in kubernetes/kubernetes@c6e9ad066e (Initial
node drain implementation for #3885, 2015-08-30,
kubernetes/kubernetes#16698), the drain logic looked in a created-by
annotation for recognized kinds [1], so listing the set of recognized
kinds was a clear approach.
Sometime later, the source moved into ownerReferences, but the
hard-coded set of recognized controller kinds remained.
When kubernetes/kubernetes@2f1108451f (Remove hard-coded
pod-controller check, 2017-12-05, kubernetes/kubernetes#56864) removed
the hard-coded set of recognized controller kinds, it should have also
updated these messages to remove stale references to the previous
hard-coded values. This commit catches the message strings up with
that commit.
[1]: c6e9ad066e (diff-211259b8a8ec42f105264c10897dad48029badb538684e60e43eaead68c3d219R216)
Kubernetes-commit: 587f4f04cc5fc18f4e85ed6a4a06bbf1bfee0496
Currently, server-side dry-run fetches the OpenAPI schema for every
single object.
This change fetches the OpenAPI schema only once.
Kubernetes-commit: caa158610dfb53de3582ed6df0eb37359206fc66
The option --delete-local-data according with users is not clear.
This patch deprecate --delete-local-data in favor of --delete-emptydir-data.
Reference:
https://github.com/kubernetes/kubernetes/issues/80228
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Kubernetes-commit: 625e47aaa2769d221c59e5b9b05b4ac97212719b
* Extend --dry-run to support string values for dry run strategies
'client', 'server', and 'none'
* Ensure --dry-run is set and accessed via cmdutil
* Deprecate --dry-run (unset), --dry-run=true, and --dry-run=false
Kubernetes-commit: af52beda260257e81cc9e19e9e5108b682ee93d6
Currently, some circumstances may cause waitForDelete to
never succeed after the pod has been marked for deletion.
In particular, Nodes that are unresponsive and have
pods with local-storage will not be able to
successfully drain.
We should allow drain to ignore pods that have a
DeletionTimestamp older than a user-provided age.
This will allow controllers utilizing kubectl/drain
to optionally account for a pod that cannot be
removed due to a misbehaving node.
Kubernetes-commit: da53044abdf8c8a9771a5c3dfd861f0c4ec78c40
Currently, if eviction is supported during a drain operation,
eviction is always used.
This commit allows the user to specify disabling eviction.
This is particularly useful when you wish to ignore
PodDisruptionBudgets after a normal drain has failed for
some time.
Kubernetes-commit: 6c1d587d5142b95e6c169a198a086332a7e4d8ad
When there's a pod that can't be evicted/deleted, and apiserver
connection breaks at a wrong moment, kubectl can panic due
to nil pointer dereference. This PR also improves drain tests
to avoid confusing panics with fatal errors.
Kubernetes-commit: 37226f8e8306475895d7e68eb52c57e57f00ee28