Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Support the deletion protection of service and ingress resources #1218

Closed
im-jinxinwang opened this issue Mar 13, 2023 · 6 comments
Assignees
Milestone

Comments

@im-jinxinwang
Copy link

im-jinxinwang commented Mar 13, 2023

What would you like to be added:
Support the deletion protection of service and ingress resources

Why is this needed:
When you delete Service or Ingress resources in Kubernetes, if there are other resources (such as Deployment, StatefulSet, etc.) that are using the services they provide, these resources will not function properly. Therefore, protecting the deletion of Service and Ingress resources is very important to avoid accidental deletion and to protect the stability of the application.

@im-jinxinwang im-jinxinwang changed the title [feature request] Support the deletion and protection of service and ingress resources [feature request] Support the deletion protection of service and ingress resources Mar 13, 2023
@zmberg zmberg added kind/good-first-issue Good for newcomers kind/good-idea Good Idea and removed kind/good-first-issue Good for newcomers labels Mar 13, 2023
@kevin1689-cloud
Copy link
Contributor

kevin1689-cloud commented Mar 21, 2023

Hi, I want to try this, can you assign this to me?

Also I have question about this issue:
As refer to the doc Deletion Protection , the Cascading judgement of Deployment/StatefulSet/ReplicaSet/CloneSet/UnitedDeployment is "whether the replicas is 0". But how about the Cascading judgement for Service and Ingress? For Service I think can be "whether the endpoint is 0", but I'm not yet have a good idea on Ingress.

@zmberg
Copy link
Member

zmberg commented Mar 30, 2023

Hi, I want to try this, can you assign this to me?

Also I have question about this issue: As refer to the doc Deletion Protection , the Cascading judgement of Deployment/StatefulSet/ReplicaSet/CloneSet/UnitedDeployment is "whether the replicas is 0". But how about the Cascading judgement for Service and Ingress? For Service I think can be "whether the endpoint is 0", but I'm not yet have a good idea on Ingress.

@WVenus How did you consider this question?

@im-jinxinwang
Copy link
Author

@zmberg Sorry, I just saw this information。
My development skills are limited, but I also see that the kruise project has this delete protection feature for the k8 namespace, so it meets some of the practical needs of the production environment, can you add a similar feature to the service and ingress resources.

@kevin1689-cloud
Copy link
Contributor

@zmberg Sorry, I just saw this information。 My development skills are limited, but I also see that the kruise project has this delete protection feature for the k8 namespace, so it meets some of the practical needs of the production environment, can you add a similar feature to the service and ingress resources.

@WVenus @zmberg Hi, I agree with protecting the deletion of Service and Ingress resources is important , because other resources (such as Deployment, StatefulSet or Application outside the kubernetes cluster) may using the services they provide. The deletion protect of Service and Ingress can avoid accidental deletion and to protect the stability of the application.

For the Cascading judgement of Service and Ingress, how about this solution:

  • Service: whether the endpoint of this Service is 0
  • Ingress: whether any Service mentioned in spec.rules.http.paths.backend.service of Ingress spec is exist in kubernetes cluster

@im-jinxinwang
Copy link
Author

@kevin1689-cloud I think it is a good way.
Is this function globally restricted by default or is it defined by annotations themselves?

@kevin1689-cloud
Copy link
Contributor

kevin1689-cloud commented Apr 20, 2023

@kevin1689-cloud I think it is a good way. Is this function globally restricted by default or is it defined by annotations themselves?

@WVenus As refer to the doc Deletion Protection, here is the usage of deletion protection:

Firstly, users have to enable the ResourcesDeletionProtection feature-gate during Kruise installation or upgrade.

Then, users can add the label named policy.kruise.io/delete-protection to some specific resources. The values can be:

  • Always: this object will always be forbidden to be deleted, unless the label is removed
  • Cascading: this object will be forbidden to be deleted, if it has active resources owned

It's the same for the deletion protection of service and ingress resources: user should enable the ResourcesDeletionProtection feature-gate first, and then add label policy.kruise.io/delete-protection to the specified service and ingress, the value of the label can be Always or Cascading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

4 participants