Open atiratree opened 10 months ago
/sig apps
Hello @atiratree, 1.29 Enhancements team here! Is this enhancement targeting 1.29? If it is, can you follow the instructions here to opt in the enhancements and make sure the lead-opted-in label is set so it can get added to the tracking board? Thanks!
Title suggestion: “Declarative node maintenance”
(all KEPs are implicitly improvements, or at least they aim to be)
Thanks for the suggestion. I have updated the title and the KEP.
@npolshakova this still needs to be discussed with all the interested sigs before we can target this.
this has been discussed and the KEP still needs some work and additional discussions, so we will try to target this for the next release
/sig node
@atiratree, how can people best help move this work forward?
I will revisit this one soon. I need to process the reviews and my personal notes.
The KEP should be up to date now.
Some relevance to: https://github.com/kubernetes/website/issues/44998 (about the existing docs for node maintenance)
In case it helps, Red Hat has been shipping https://github.com/medik8s/node-maintenance-operator for ~5 years. It almost certainly contains some OpenShift-isms, but I'm sure they can be addressed if there is interest.
@beekhof I am aware of this operator and it was considered when designing this feature. Please also see https://github.com/kubernetes/enhancements/blob/cd1ea31e1c09c2f4e9f6a7f35821ff14f41a2f78/keps/sig-apps/4212-declarative-node-maintenance/README.md#out-of-tree-implementation
The Declarative Node Maintenance KEP is becoming too complex and it is hard to capture all aspects and review everything in a single place. I have opened a second KEP just for the Evacuation API: https://github.com/kubernetes/enhancements/issues/4563 and it will be a prerequisite for the Node Maintenance.
@beekhof if we did prototype node maintenance out of tree, with an alpha API group, we'd want to teach Kubernetes tooling about using it (for example, kubectl drain
- but also many other in-project pieces).
To me, the value comes from that integration work more than from writing the actual controller. If you agree, we could look at rallying effort around an out-of-tree prototype. The integrations would remain valuable even after a move to in-tree implementation.
/assign @atiratree
/label lead-opted-in /stage alpha /milestone v1.31
@soltysh I would like to consider this for alpha in 1.32, not in this release. To get more feedback on the feature and to lead the way with the Evacuation API (dependency) first.
/milestone clear
Hello @soltysh @atiratree 👋, 1.31 Enhancements team here.
Now that this KEP is not targeting for release 1.31 (reference https://github.com/kubernetes/enhancements/issues/4212#issuecomment-2152097655), should we also consider removing the lead-opted-in
label too?
Yeah, I guess you're right.
/remove-label lead-opted-in
Is there a baseline of detail that we can define and merge as provisional?
This and https://github.com/kubernetes/enhancements/issues/4563 where discussed heavily again during Monday's SIG-Apps call, with the general hesitation from SIG leads we're going to hold on with these efforts in favor of looking into extending PDB and eviction API.
/label tracked/no
Enhancement Description
k/enhancements
) update PR(s): https://github.com/kubernetes/enhancements/pull/4213k/k
) update PR(s):k/website
) update PR(s):Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.