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

Graceful eviction umbrella issue #2281

Closed
7 of 8 tasks
RainbowMango opened this issue Jul 29, 2022 · 2 comments
Closed
7 of 8 tasks

Graceful eviction umbrella issue #2281

RainbowMango opened this issue Jul 29, 2022 · 2 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@RainbowMango
Copy link
Member

RainbowMango commented Jul 29, 2022

What would you like to be added:
We hope to introduce a graceful way to delay the removal until the resource is available on the substitute cluster.

Iterated task:

  • API change #2273
  • Introduce GracefulEviction feature gate. #2340
  • Make changes to karmada-scheduler to mark schedulerObservedGeneration (RB) #2330
  • Make changes to karmada-scheduler to mark schedulerObservedGeneration (CRB) #2345
  • Introduce grace-eviction-controller to implementers the API. (#2319)
  • Make changes to binding controller to adopt the changes. (#2339)
  • Make changes to taint manager to trigger graceful eviction. (#2346)
  • Introduce a documentation to https://karmada.io/docs/next/ (under Multi-cluster scheduling)

Why is this needed:
#1762 addresses the eviction feature that focuses on trigger eviction based on taints toleration and introduces a taint manager to perform the eviction.

Once the taint manager performs the eviction (means remove a specific cluster from the RB(ResourceBinding) target list(.spec.clusters)), the resource referenced by the RB will be `removed immediately from the target cluster.

For example, there is an online workload(like an Nginx server) that was running on cluster-1, and then a network broken issue happens, Karmada starts to evict it from cluster-1 and probably karmada-scheuler scheduled it to cluster-2. The thing is the workload would be removed immediately and no service available until the workload runs on cluster-2.

@XiShanYongYe-Chang
Copy link
Member

I will continuously improve failover.
/close

@karmada-bot
Copy link
Collaborator

@XiShanYongYe-Chang: Closing this issue.

In response to this:

I will continuously improve failover.
/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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants