|
| 1 | +# WG Node Lifecycle Charter |
| 2 | + |
| 3 | +This charter adheres to the conventions described in the [Kubernetes Charter README] and uses |
| 4 | +the Roles and Organization Management outlined in [wg-governance]. |
| 5 | + |
| 6 | +[Kubernetes Charter README]: /committee-steering/governance/README.md |
| 7 | + |
| 8 | +## Scope |
| 9 | + |
| 10 | +The Kubernetes ecosystem currently faces challenges in node maintenance scenarios, with multiple |
| 11 | +projects independently addressing similar issues. The goal of this working group is to develop |
| 12 | +unified APIs that the entire ecosystem can depend on, reducing the maintenance burden across |
| 13 | +projects and addressing scenarios that impede node drain or cause improper pod termination. Our |
| 14 | +objective is to create easily configurable, out-of-the-box solutions that seamlessly integrate with |
| 15 | +existing APIs and behaviors. |
| 16 | + |
| 17 | +To properly solve the node drain, we must first understand the node lifecycle. This includes |
| 18 | +provisioning/sunsetting of the nodes, PodDisruptionBudgets, API-initiated eviction and node |
| 19 | +shutdown. This then impacts both the node and pod autoscaling, load balancing, and the applications |
| 20 | +running in the cluster. All of these areas have issues and would benefit from a unified approach. |
| 21 | + |
| 22 | +### In scope |
| 23 | + |
| 24 | +- Explore a unified way of draining the nodes and managing node maintenance by introducing new APIs |
| 25 | + and extending the current ones. This includes exploring extension to or interactions with the Node |
| 26 | + object. |
| 27 | +- Analyze the node lifecycle, the Node API, and possible interactions. We want to explore augmenting |
| 28 | + the Node API to expose additional state or status in order to coalesce other core Kubernetes and |
| 29 | + community APIs around node lifecycle management. |
| 30 | +- Improve the disruption model that is currently implemented by API-initiated Eviction API and PDBs. |
| 31 | + Improve the descheduling, availability and migration capabilities of today's application |
| 32 | + workloads. Also explore the interactions with other eviction mechanisms. |
| 33 | +- Improve the Graceful/Non-Graceful Node Shutdown and consider how this affects the node lifecycle. |
| 34 | +- Improve the scheduling and pod/node autoscaling to take into account ongoing node maintenance and |
| 35 | + the new disruption model/evictions. |
| 36 | +- Explore the cloud provider use cases and how they can hook in into the node lifecycle. So that the |
| 37 | + users can use the same APIs or configurations across the board. |
| 38 | +- Migrate users of the eviction based kubectl-like drain (kubectl, cluster autoscaler, karpenter, |
| 39 | + ...) to use the new approach. |
| 40 | + |
| 41 | + |
| 42 | +### Out of scope |
| 43 | + |
| 44 | +- Implementing cloud provider specific logic, the goal is to have high-level API that the providers |
| 45 | + can use, hook into, or extend. |
| 46 | +- Infrastructure provisioning, deprovisioning solution or physical infrastructure lifecycle |
| 47 | + management solution. |
| 48 | + |
| 49 | +## Stakeholders |
| 50 | + |
| 51 | +- SIG Apps |
| 52 | +- SIG Architecture |
| 53 | +- SIG Autoscaling |
| 54 | +- SIG CLI |
| 55 | +- SIG Cloud Provider |
| 56 | +- SIG Cluster Lifecycle |
| 57 | +- SIG Node |
| 58 | +- SIG Scheduling |
| 59 | + |
| 60 | +Stakeholders span from multiple SIGs to a broad set of end users, |
| 61 | +public and private cloud providers, Kubernetes distribution providers, |
| 62 | +and cloud provider end-users. Here are some user stories: |
| 63 | + |
| 64 | +- As a cluster admin I want to have a simple interface to initiate a node drain/maintenance without |
| 65 | + any required manual interventions. I also want to be able to observe the node drain via the API |
| 66 | + and check on its progress. I also want to be able to discover workloads that are blocking the node |
| 67 | + drain. |
| 68 | +- To support the new features, node maintenance, scheduler, descheduler, pod autoscaling, kubelet |
| 69 | + and other actors should use a new eviction API to gracefully remove pods. This should enable new |
| 70 | + migration strategies that prefer to surge (upscale) pods first rather than downscale them. It |
| 71 | + should also allow other users/components to monitor pods that are gracefully removed/terminated |
| 72 | + and provide better behaviour in terms of de/scheduling, scaling and availability. |
| 73 | +- As an end user, I cannot bear the cost of blue-green upgrades, especially with special hardware |
| 74 | + accelerators; it's far too expensive. It is more cost-effective to coordinate a drain and then |
| 75 | + upgrade. |
| 76 | +- As a cloud provider, I need to perform regular maintenance on the hardware in my fleet. Enhancing |
| 77 | + Kubernetes to help CSPs safely remove hardware will reduce operational costs. |
| 78 | +- Modelling the cost of doing accelerator maintenance in today's world can be massive. And since |
| 79 | + hardware accelerators tend to need more love and care, having software support to coordinate |
| 80 | + maintenance will reduce operational costs. |
| 81 | + |
| 82 | +## Deliverables |
| 83 | + |
| 84 | +The WG will coordinate requirement gatherthing and design, eventually leading to |
| 85 | +KEP(s)s and code associated with the ideas. |
| 86 | + |
| 87 | +Area we expect to explore: |
| 88 | + |
| 89 | +- An API to express node drain/maintenance. |
| 90 | + Currently tracked in https://github.com/kubernetes/enhancements/issues/4563. |
| 91 | +- An API to solve the problems wrt the API-initiated Eviction API and PDBs. |
| 92 | + Currently tracked in https://github.com/kubernetes/enhancements/issues/4212 |
| 93 | +- Introduce enhancements across multiple Kubernetes SIGs to add support for the new APIs to solve |
| 94 | + wide range of issue. |
| 95 | + |
| 96 | +## Roles and Organization Management |
| 97 | + |
| 98 | +This WG adheres to the Roles and Organization Management outlined in [wg-governance] |
| 99 | +and opts-in to updates and modifications to [wg-governance]. |
| 100 | + |
| 101 | +[wg-governance]: /committee-steering/governance/wg-governance.md |
| 102 | + |
| 103 | +## Timelines and Disbanding |
| 104 | + |
| 105 | +The working group will disband when the KEPs we create are completed. We will |
| 106 | +review whether the working group should disband if appropriate SIG ownership |
| 107 | +can't be reached. |
0 commit comments