* kubectl: use %w for error wrapping and remove redundant .Error() calls
Replace fmt.Errorf with %s and err.Error() with idiomatic %w wrapping
in kubectl's polymorphichelpers, wait, and drain packages. This enables
proper error chain inspection via errors.Is/As and follows Go best
practices.
Also fixes a typo: "Statefulset" -> "StatefulSet" in history.go.
* Address review: use %w for error wrapping in extendErrWaitTimeout
Use fmt.Errorf with %w instead of %v to preserve the error chain,
allowing wait.Interrupted() to correctly detect timeout errors.
Signed-off-by: supermario_leo <leo.stack@outlook.com>
* Fix lint: wrap both errors with %w in cordon error path
The linter flags err used with %v when it is an error type. Since
Go 1.20+ supports multiple %w verbs in a single fmt.Errorf call,
wrap both err and patchErr to preserve both error chains.
Signed-off-by: supermario_leo <leo.stack@outlook.com>
---------
Signed-off-by: supermario_leo <leo.stack@outlook.com>
Kubernetes-commit: d916c320deb859cd264354c48f3bd5419f7a2950
TestEvictDuringNamespaceTerminating intentionally exercises the retry path
but only allows 10ms of total time. The production loop sleeps, refreshes
state, and retries under that same deadline, so a single retry plus
scheduler jitter is enough to exhaust the budget under -race or on busy
CI workers.
Keep the retry interval small so the test still covers the retry behavior,
but widen the overall timeout so the assertion measures semantics instead
of machine speed.
Tested:
go test -race ./staging/src/k8s.io/kubectl/pkg/drain -run TestEvictDuringNamespaceTerminating -count=100
Kubernetes-commit: 77f8d7c2a9571dd9a76ee1be8b234a4dddd2ad35
Replace the context.TODO with getContext to prefer the Helper's context
when it is set. This is consistent with the rest of the package now.
Since contextual logging or timeouts may be included as part of the
Helper's context, using context.TODO will silently ignore these
features, producing unexpected behaviors.
Signed-off-by: Kirsten Laskoski <klaskosk@redhat.com>
Kubernetes-commit: 7022a626607be602b2e3577cef5882933f42a516
* fix using stale pod when evict failed and retry
* simplify pod refresh process
* use activePod at getPodFn
* fix lint check
* add ut
* introduce EvictErrorRetryDelay
Kubernetes-commit: 66fdbe105831e08b588dd01039a7e3130fd2d36f
Fixed a bug where kubectl drain would consider a pod as having been deleted if an error occurs while calling the API.
Kubernetes-commit: 4aecb151b8301a6fc69f63c08f640c7b2b4289fc
And also in the terminating-namespace log output. This makes it
easier to track down drain-blocking pods, without having to hunt
around in earlier logs for 'evicting pod ...' messages. Before this
change, caller logs might look like:
evicting pod {namespace}/{name}
...
error when waiting for pod "{name}" terminating: global timeout reached: 20s
With this change, they will look like:
evicting pod {namespace}/{name}
...
error when waiting for pod "{name}" in namespace "{namespace}" to terminate: global timeout reached: 20s
Kubernetes-commit: b6318d4e5b9b8eb0d2e2d5a8568df14817733f26
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
Enables the PatchOrReplace call for the cordon helper to accept a
user-supplied context to be used for the client.Patch/Update calls to
alter the node status while cordoning/uncordoning the node.
Signed-off-by: Sagar Muchhal <muchhals@vmware.com>
Kubernetes-commit: 017eaa519de5926fd75a9ddc61bedf2398b69653
It took me a while to spot this subtlety.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Kubernetes-commit: 7c764c8550121b48a6e2678700b6a80fa7d3e2f0
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
Currently, there is no way to supply custom pod filters to
exclude pods meeting arbitrary criteria when using drain
as a library.
This commit adds the ability for developers to add custom
filters to the drain operation when utilizing drain
as a library.
This commit exports certain types that were previously
private to allow for better code reuse.
This commit also adds appropriate unit tests.
Kubernetes-commit: 85004f030dc3dceb9d15f41fdd607545758d5da2
If a pod is already marked deleted, and the eviction
api returns an unauthorized response, ignore that
error since the pod is marked for deletion already.
If the pod is not already marked deleted, retry.
Kubernetes-commit: 8d2a2ffe014ed06b5f8971e7f3dc25ec155e44d4
Most of these could have been refactored automatically but it wouldn't
have been uglier. The unsophisticated tooling left lots of unnecessary
struct -> pointer -> struct transitions.
Kubernetes-commit: 76f85943787a5901a34a314a935712177edd2db0
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
This commits allows specifying a context.Context
in the Helper type. This context is utilized to
cancel waitForDelete.
Kubernetes-commit: 8682e902f5487e04b893da7230125db0d7ae66b4
