NMO Feature Request: Support cordon-only mode

[David Haja]

Hello Team,

I was wondering if you would be open to extending the NMO functionality to support a cordon-only mode — allowing the operator to cordon nodes without draining the associated Pods.

My proposal is to enhance the `NodeMaintenance` CRD by adding an optional field, for example `drain`, which would default to `true`. The operator could then check this field before executing the RunNodeDrain step.

Please let me know if this is something you’d consider accepting upstream — I’d be happy to work on a contribution and submit a PR.

Best Regards,

David

[Or Raz]

Hi David,

What is the reason for allowing the operator to cordon nodes without draining the associated Pods?
Can you share more background? I am trying to understand the use case here.

Best regards,
Or Raz

--
You received this message because you are subscribed to the Google Groups "medik8s" group.
To unsubscribe from this group and stop receiving emails from it, send an email to medik8s+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/medik8s/d3edab87-06f2-41f1-aada-19697705c259n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Haja]

Hello,

Thanks for your response. 

Sure thing. Here’s some additional context and use cases where allowing the operator to cordon nodes without draining can be useful for us:

- Pre-Maintenance Preparation: About to perform maintenance on a node but don’t want to disrupt existing workloads yet.

- Node health related investigations: investigating node-level issues without affecting currently running pods.

- Graceful Decommissioning: prevent new workloads from landing there while waiting for existing jobs to finish naturally.

- Resource Pressure: Node is low on disk, CPU, or memory, but workloads are stable. Cordoning only gives time to investigate or add capacity elsewhere.

Instead of simply executing `kubectl cordon <node>`, we would also like to rely on the `reason` field of the NodeMaintenance custom resource as part of our workflows, since this field can clearly communicate why a node is under maintenance, which is particularly useful for automation and observability in our system.

I hope this helps clarify things.

Best regards,

David

[Or Raz]

Hi David,

Thank you for the detailed explanation and interesting use cases. This clarifies the request, and it sounds like a valuable feature for NMO that we would consider accepting upstream.

Apologies for the delayed response.

Best regards,

Or Raz

To view this discussion visit https://groups.google.com/d/msgid/medik8s/05da775b-d86e-48d0-9e84-91157d36d0b8n%40googlegroups.com.