Change:
if o.GracePeriod >= 0 { options = metav1.NewDeleteOptions(int64(o.GracePeriod)) } <del> policy := metav1.DeletePropagationForeground </del> <ins> policy := metav1.DeletePropagationBackground </ins> if !o.Cascade { policy = metav1.DeletePropagationOrphan }

Discussion:
/kind bug What happened: hang on "kubectl delete" command on my deployer machine, but can run other commands as usual ! can run "kubectl delete" command on master node, deployer and master have the same directory. What you expected to happen: delete some resource How to reproduce it (as minimally and precisely as possible): I don't know Anything else we need to know?: Environment: Kubernetes version (use ): ! Cloud provider or hardware configuration: azure, I am not using cloud provider OS (e.g. from /etc/os-release): centos 7.5 Kernel (e.g. ): Linux cn2-k8s-deployer 3.10.0-862.3.3.el7.x8664 SMP Fri Jun 15 04:15:27 UTC 2018 x8664 x8664 x8664 GNU/Linux Install tools: installed by kubespray Others:
/sig azure
this is caused by a switch to kubectl to use "foreground deletion" in 1.11.0 that relies on server-side garbage collection being responsive to clean up the resource and its dependents, and blocks until it does. the hang means that your controller manager isn't running, or the garbage collection controller isn't responsive at the moment you are deleting the object. because of interactions like this, kubectl is returning to use background deletion in 1.11.1 (see )
fixed in , will be in 1.11.1 /close
The fix in makes me sad :( We have just found out that foreground cascade deletion is not working in kubectl again. The workaround for that would be not to wait, kubectl has a flag for that: Personally I would prefer to get a hanging kubectl in that case. was keeping a backward compatibile behavior the main reason to switch back to ? We should probably have a flag for explicit at least then... Otherwise there is no way to trigger a foreground deletion via kubectl :(
the hang means that your controller manager isn't running, or the garbage collection controller isn't responsive at the moment you are deleting the object. numerous bug reports suggest you are in the minority :) that behavior also means that with just an apiserver running, always hangs, which doesn't seem proper.

to be clear, kubectl still waits until the object you requested to be deleted is actually deleted, which was the priority for scripting compatibility (to make delete-then-recreate cases work properly) the way client-side reapers did cascading deletion in kubectl was foreground out of necessity, since client-side deletion is not re-entrant otherwise. it was only implemented that way for resources which had client-side reapers, which was a small hard-coded set. blocking client comments on controller behavior unnecessarily is problematic (as numerous reports of issues with the switch to foreground deletion revealed). I would not object to an option to run deletion in foreground mode, but it doesn't make for a good default.
the deletion mode is implemented in GC on the server side, and while understand the use case for client-side reapers, I disagree that it is only useful for some client-side blocking. The real use case we have (as I previously described in ) is building a tree of objects where deleting a root will force deletion of all its children first and will block the deletion of itself in the meantime. This has nothing to do with a client-side logic, it's just annoying that won't ever use this mode, and our users obviously deleting objects via . This is very similar to namespace behavior: deleted namespace gets blocked until all objects within it are gone. I understand the concerns of having foreground deletion mode enabled by default though.