Add --cascade or --force flag to kubectl delete namespace, for non-empty namespaces

[johanot]

Today, if you drain a node, kubectl will prompt you for confirmation in the form of --ignore-daemonsets and --delete-local-data if applicable. This is fine and a nice guard for doing something dangerous.

Along the same lines, I would like some sort of --force or --cascade flag for deleting namespaces, in case the namespace contains objects. This would imply kubectl get -n <namespace> all before the actual delete is executed.

/kind feature
/sig cli

What happened:
My namespace and all objects within it was deleted without confirmation or questioning.

What you expected to happen:
A warning or bail out asking for a confirmation or a "I-know-what-I'm-doing-flag` before proceeding.

How to reproduce it (as minimally and precisely as possible):
kubectl delete ns <any-namespace>

[rctl]

This looks like a nice feature to prevent accidental deletion of namespaces that have objects, I like this. I would like to take a look at implementing this.

[juanvallejo]

We expect the kubectl delete command to behave generically with any resource.
It would not make sense to special-case it to behave differently with a specific resource.

A solution that has been discussed in the past would consist of leveraging annotations on resources as a means of marking them "not safe to delete", similar to the work in kubernetes/kubernetes#17740 (comment)

An immediate workaround would involve using admission webhooks to create this protection

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[seans3]

/remove-lifecycle rotten

[seans3]

/area kubectl

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.