OpenShift Control Plane Components

In OpenShift, the correct term is control plane, not control panel.

The control plane is the “brain” of the OpenShift cluster. It manages:

• Cluster configuration
• Workload scheduling
• API requests
• Cluster state
• Controllers and Operators
• Authentication and authorization
• Node and workload lifecycle

A typical highly available OpenShift cluster has three control-plane nodes.

                    Users and Administrators
                             │
                         oc / Console
                             │
                             ▼
                      API Load Balancer
                             │
          ┌──────────────────┼──────────────────┐
          ▼                  ▼                  ▼
      master-0            master-1           master-2
          │                  │                  │
          ├── kube-apiserver ├── kube-apiserver ├── kube-apiserver
          ├── etcd           ├── etcd           ├── etcd
          ├── scheduler      ├── scheduler      ├── scheduler
          ├── controller     ├── controller     ├── controller
          └── Operators      └── Operators      └── Operators

1. kube-apiserver

The kube-apiserver is the main entry point into the cluster.

All administrative and platform operations go through it.

Examples:

oc get pods
oc apply -f deployment.yaml
oc delete pod mypod

Request flow:

oc client
   │
   ▼
API load balancer
   │
   ▼
kube-apiserver
   │
   ├── Authentication
   ├── Authorization
   ├── Admission controls
   ├── Resource validation
   └── etcd read/write

The API server handles:

• Kubernetes API requests
• Authentication
• RBAC authorization
• Admission webhooks
• Object validation
• Communication with etcd

It listens on:

TCP 6443

Check it with:

oc get pods -n openshift-kube-apiserver -o wide
oc get co kube-apiserver

2. etcd

etcd is the distributed key-value database that stores the authoritative cluster state.

It stores:

• Deployments
• Pods and desired state
• Services
• Secrets
• ConfigMaps
• Routes
• RBAC
• Nodes
• Operators
• CRDs
• MachineConfig objects

API Server
    │
    ▼
   etcd
    │
    ▼
Cluster state

A standard OpenShift cluster normally has three etcd members:

master-0
master-1
master-2

Quorum requirement:

3 members → 2 required for quorum

If one member fails, the cluster can usually continue.

If two members fail, etcd loses quorum and control-plane operations stop.

Check etcd:

oc get co etcd
oc get pods -n openshift-etcd -o wide

3. kube-scheduler

The scheduler decides which node should run a new Pod.

It evaluates:

• CPU requests
• Memory requests
• Node selectors
• Taints and tolerations
• Affinity and anti-affinity
• Topology spread constraints
• Persistent-volume topology
• Host ports
• Node readiness

Pending Pod
     │
     ▼
Scheduler filters nodes
     │
     ▼
Scheduler scores eligible nodes
     │
     ▼
Pod assigned to worker-2
     │
     ▼
kubelet starts Pod

The scheduler does not start the container. It only assigns the Pod to a node.

Check it with:

oc get co kube-scheduler
oc get pods -n openshift-kube-scheduler -o wide

4. kube-controller-manager

The kube-controller-manager runs multiple Kubernetes controllers.

Controllers continuously compare:

Desired state
      vs
Actual state

and take action to correct differences.

Important controllers include:

• Deployment controller
• ReplicaSet controller
• Node controller
• Job controller
• Service account controller
• EndpointSlice controller
• Namespace controller
• Persistent-volume controller

Example:

Deployment requests 3 replicas
          │
          ▼
Controller sees only 2 Pods
          │
          ▼
Creates another Pod

Check it with:

oc get co kube-controller-manager
oc get pods -n openshift-kube-controller-manager -o wide

5. OpenShift Controller Manager

OpenShift also includes OpenShift-specific controllers.

These manage platform-specific resources and behavior beyond standard Kubernetes.

Examples include:

• OpenShift project behavior
• Build-related resources
• Image resources
• OpenShift authorization functions
• Platform-specific reconciliation

It runs separately from the Kubernetes controller manager.

Check:

oc get co openshift-controller-manager
oc get pods -n openshift-controller-manager

6. OpenShift API Server

The OpenShift API Server provides OpenShift-specific APIs that extend Kubernetes.

Examples include APIs related to:

• Projects
• Routes
• Builds
• Images
• OpenShift-specific authorization
• Security extensions

Architecture:

Client
   │
   ▼
Kubernetes API aggregation layer
   │
   ├── Kubernetes APIs
   └── OpenShift APIs

Check:

oc get co openshift-apiserver
oc get pods -n openshift-apiserver

7. Cluster Version Operator

The Cluster Version Operator, or CVO, manages the overall OpenShift release version.

It is responsible for:

• Installing platform components
• Coordinating upgrades
• Applying release manifests
• Monitoring ClusterOperators
• Ensuring components match the desired release

New OpenShift release
         │
         ▼
Cluster Version Operator
         │
         ▼
Platform Operators upgraded
         │
         ▼
Control-plane and worker updates

Check:

oc get clusterversion
oc get co

8. Machine Config Operator

The Machine Config Operator, or MCO, manages the operating-system configuration of RHCOS nodes.

It controls:

• RHCOS updates
• CRI-O configuration
• kubelet configuration
• Kernel arguments
• Systemd units
• CA certificates
• Registry configuration
• Node files

MachineConfig
      │
      ▼
Machine Config Operator
      │
      ▼
Machine Config Daemon
      │
      ▼
Drain → Apply → Reboot → Ready

Check:

oc get mcp
oc get machineconfig
oc get co machine-config

9. Authentication Operator

The Authentication Operator manages OpenShift OAuth and login services.

It handles:

• Identity providers
• OAuth server
• Login flow
• Authentication certificates
• Token configuration

Example:

User
  │
  ▼
Corporate identity provider
  │
  ▼
OpenShift OAuth
  │
  ▼
OpenShift access token

Check:

oc get co authentication
oc get oauth cluster -o yaml

10. Ingress Operator

The Ingress Operator manages the OpenShift router.

It controls:

• Router Pods
• IngressControllers
• Wildcard certificates
• Router replicas
• Publishing strategy
• Public and private ingress

External client
      │
      ▼
Load balancer
      │
      ▼
Router Pods
      │
      ▼
Route
      │
      ▼
Service
      │
      ▼
Application Pods

Check:

oc get co ingress
oc get ingresscontroller -n openshift-ingress-operator
oc get pods -n openshift-ingress

11. DNS Operator

The DNS Operator manages CoreDNS for cluster Service discovery.

It allows Pods to resolve names such as:

payments-api.banking.svc.cluster.local

Architecture:

Application Pod
      │
      ▼
DNS Service IP
      │
      ▼
CoreDNS
      │
      ├── Internal Service names
      └── External upstream DNS

Check:

oc get co dns
oc get pods -n openshift-dns
oc get dns.operator/default -o yaml

12. Network Operator

The Cluster Network Operator manages the OpenShift network plugin, usually OVN-Kubernetes.

It manages:

• Pod networks
• Service networks
• OVN components
• GENEVE tunnels
• MTU
• Egress features
• NetworkPolicies
• Node networking components

Pod A
  │
  ▼
OVN virtual network
  │
  ▼
Pod B

Check:

oc get co network
oc get network.operator cluster -o yaml
oc get pods -n openshift-ovn-kubernetes

13. Cloud Controller Manager

On cloud platforms, the cloud controller integrates OpenShift with AWS, Azure, or GCP.

It manages functions such as:

• Cloud node information
• Load balancers
• Routes
• Instance metadata
• Cloud volumes, depending on the driver architecture

Example:

Service type LoadBalancer
          │
          ▼
Cloud Controller
          │
          ▼
AWS / Azure / GCP load balancer

14. Machine API Operator

The Machine API Operator manages infrastructure machines on supported platforms.

It handles:

• Machine objects
• MachineSets
• MachineHealthChecks
• Worker creation
• Worker replacement
• Autoscaling integration

MachineSet replicas: 5
         │
         ▼
Machine API Operator
         │
         ▼
Create cloud VMs
         │
         ▼
New OpenShift workers join

Check:

oc get machines -A
oc get machinesets -A
oc get machinehealthchecks -A

15. Monitoring Components

The control plane is monitored by the OpenShift monitoring stack.

Main components include:

• Prometheus
• Alertmanager
• kube-state-metrics
• Node Exporter
• Prometheus Operator
• Thanos components

They monitor:

• API latency
• etcd latency
• Scheduler health
• Operator status
• Node health
• Resource utilization

Check:

oc get pods -n openshift-monitoring

Static Pods on Control-Plane Nodes

Several critical control-plane components run as static Pods:

• etcd
• kube-apiserver
• kube-controller-manager
• kube-scheduler

A static Pod is managed directly by the kubelet on the node.

Static Pod manifest
        │
        ▼
kubelet reads manifest
        │
        ▼
Control-plane Pod starts

This allows core components to start even when the scheduler is unavailable.

Control Plane Request Flow

When you run:

oc create deployment nginx --image=nginx

the full sequence is:

1. oc sends request to API load balancer
2. Load balancer selects a kube-apiserver
3. API server authenticates the user
4. RBAC authorizes the request
5. Admission controls validate the object
6. Deployment is stored in etcd
7. Controller Manager creates a ReplicaSet
8. ReplicaSet controller creates a Pod
9. Scheduler selects a worker node
10. kubelet asks CRI-O to start the container
11. OVN configures Pod networking
12. Pod becomes Running

High Availability

A production OpenShift control plane normally uses three control-plane nodes.

master-0
master-1
master-2

Availability is maintained through:

• Three API server instances
• Three etcd members
• Scheduler leader election
• Controller-manager leader election
• API load balancing
• Rolling upgrades
• Static Pods
• Operator reconciliation

Only one scheduler and controller-manager instance is active as leader at a time, while others remain ready to take over.

Control Plane vs Worker Nodes

Control Plane
     │
     ▼
Decides what should run
Worker Node
     │
     ▼
Runs the actual workload

Important Commands

oc get nodes
oc get clusteroperators
oc get clusterversion
oc get pods -A

Control-plane Pods:

oc get pods -n openshift-etcd
oc get pods -n openshift-kube-apiserver
oc get pods -n openshift-kube-controller-manager
oc get pods -n openshift-kube-scheduler

Operator health:

oc get co

Healthy status:

AVAILABLE=True
PROGRESSING=False
DEGRADED=False

Troubleshooting Control Plane

Use this sequence:

API unavailable or slow
        │
        ▼
Check API load balancer and DNS
        │
        ▼
Check kube-apiserver
        │
        ▼
Check etcd health and latency
        │
        ▼
Check control-plane nodes
        │
        ▼
Check scheduler and controllers
        │
        ▼
Check ClusterOperators

Useful commands:

oc get co
oc get nodes
oc get --raw='/readyz?verbose'
oc get pods -n openshift-etcd -o wide
oc get pods -n openshift-kube-apiserver -o wide

For node-level investigation:

oc debug node/<control-plane-node>
chroot /host
systemctl status kubelet
journalctl -u kubelet
iostat -x 1 10

Interview Answer

The OpenShift control plane is responsible for managing the cluster’s desired state and making all scheduling, API, and lifecycle decisions. Its key components are the kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and OpenShift-specific API and controller services.

The API server receives all requests, authenticates and authorizes them, and stores the resulting state in etcd. The controller managers continuously reconcile resources, while the scheduler selects suitable worker nodes for new Pods. OpenShift Operators such as the Cluster Version Operator, Machine Config Operator, Ingress Operator, DNS Operator, Network Operator, and Authentication Operator manage the platform components around the core Kubernetes control plane.

In a highly available cluster, these components run across three control-plane nodes. The API servers are load balanced, etcd maintains quorum, and the scheduler and controller managers use leader election. For troubleshooting, I start with oc get co, check API readiness, etcd health, control-plane Pods and nodes, and then review Operator conditions and logs.