How to Remove a Control-Plane Node from OpenShift

Learn how to safely remove an extra control-plane node from a Red Hat OpenShift cluster with step-by-step commands and deep validation checks.

Managing a Red Hat OpenShift Cluster is not just about scaling up—it also requires knowing how to safely scale down. One of the most sensitive operations is removing an extra control-plane node, especially when etcd quorum and cluster stability are at stake.

In this guide, you’ll learn how to remove a control-plane node from an OpenShift Cluster using a real-world scenario, validated with deep checks to ensure cluster health.

Why Would You Remove a Control-Plane Node?

There are several legitimate reasons to remove a control-plane node from an OpenShift Cluster:

• Accidental over-provisioning during UPI installation
• Hardware failures or VM decommissioning
• Migrating to a supported odd-numbered control-plane topology
• Cost or resource optimization

Best Practice: Always maintain an odd number of etcd members (3 or 5) to preserve quorum.

Prerequisites Before Removing a Node

Before you remove a node from a Red Hat OpenShift Cluster, ensure:

• etcd operator is Available and Healthy
• Cluster operators are stable
• You have cluster-admin access
• You identify the correct control-plane node

Validate etcd health:

oc get co etcd

Expected state:

AVAILABLE=True
DEGRADED=False

Step 1: Identify the Control-Plane Node

List all nodes in the cluster:

oc get nodes

In this example, hpc-ctrln1.ocp.arkit.co.in is the additional control-plane node to be removed.

Step 2: Drain the Control-Plane Node

Safely evict workloads from the node:

oc adm drain hpc-ctrln1.ocp.arkit.co.in \
--ignore-daemonsets \
--delete-emptydir-data \
--force \
--timeout=10m

Why this matters

• Prevents workload disruption
• Ensures pods are rescheduled gracefully
• Required before node removal

Step 3: Verify etcd Membership

Check current etcd members:

oc -n openshift-etcd exec -it \
$(oc -n openshift-etcd get pods -l app=etcd -o name | head -1) \
-- etcdctl member list

Locate the member ID associated with the node being removed.

Step 4: Remove the Node from etcd Cluster

Set a healthy etcd pod and remove the member:

ETCD_POD=etcd-hpc-ctrlvn1.ocp.arkit.co.in

oc -n openshift-etcd exec -it $ETCD_POD -- \
etcdctl member remove 6063b47df1f308c7

Confirm removal:

oc -n openshift-etcd exec -it $ETCD_POD -- \
etcdctl member list

The removed node must no longer appear.

Step 5: Validate Cluster Health (Deep Validation)

Kubernetes API Endpoints

oc get endpoints kubernetes -n default

Ensure only active control-plane IPs are listed.
API Services Health

oc get apiservices | grep False || echo "All API services OK"

Final etcd Confirmation

oc -n openshift-etcd exec -it \
$(oc -n openshift-etcd get pods -l app=etcd -o name | head -1) \
-- etcdctl member list

This confirms the node is fully removed from etcd.

Practical Tips and Best Practices

✔ Always remove the node from etcd first, then decommission the host
✔ Never remove multiple control-plane nodes at once
✔ Monitor oc get co until all operators stabilize
❌ Do not delete the VM before etcd removal

Key Takeaways

• Removing a control-plane node from an OpenShift Cluster requires precision
• etcd quorum protection is critical
• Deep validation ensures zero hidden failures
• Proper node removal keeps Red Hat OpenShift production-ready

Conclusion & Call to Action

Removing an additional control-plane node from a Red Hat OpenShift Cluster is a controlled, safe operation when done correctly. By draining the node, removing it from etcd, and validating cluster health, you protect your platform from instability.
👉 If you manage OpenShift in production, bookmark this guide and share it with your platform team.
👉 Want more OpenShift troubleshooting and Linux deep-dives? Follow and subscribe for advanced OpenShift content.
Happy clustering! 🚀