Before https://github.com/kubernetes/kubernetes/pull/83084, `kubectl apply --prune` can prune resources in all namespaces specified in config files. After that PR got merged, only a single namespace is considered for pruning. It is OK if namespace is explicitly specified by --namespace option, but what the PR does is use the default namespace (or from kubeconfig) if not overridden by command line flag. That breaks the existing usage of `kubectl apply --prune` without --namespace option. If --namespace is not used, there is no error, and no one notices this issue unless they actually check that pruning happens. This issue also prevents resources in multiple namespaces in config file from being pruned. kubectl 1.16 does not have this bug. Let's see the difference between kubectl 1.16 and kubectl 1.17. Suppose the following config file: ```yaml apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: null name: foo namespace: a labels: pl: foo data: foo: bar --- apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: null name: bar namespace: a labels: pl: foo data: foo: bar ``` Apply it with `kubectl apply -f file`. Then comment out ConfigMap foo in this file. kubectl 1.16 prunes ConfigMap foo with the following command: $ kubectl-1.16 apply -f file -l pl=foo --prune configmap/bar configured configmap/foo pruned But kubectl 1.17 does not prune ConfigMap foo with the same command: $ kubectl-1.17 apply -f file -l pl=foo --prune configmap/bar configured With this patch, kubectl once again can prune the resource as before. Kubernetes-commit: 7af3b01f24edfde34e42640ee565a5a6bb66ce26 |
||
---|---|---|
.. | ||
apply.go | ||
apply_edit_last_applied.go | ||
apply_set_last_applied.go | ||
apply_test.go | ||
apply_view_last_applied.go | ||
patcher.go | ||
prune.go |