✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Kubernetes Control Plane Metrics Observation

Kubernetes Control Plane Metrics Observation involves monitoring key metrics to ensure the stability, performance, and security of the Kubernetes control plane.

Kubernetes Control Plane Metrics Observation is the practice of collecting and interpreting metrics emitted by the API server, scheduler, controller-manager, and etcd, revealing the health and performance of the cluster's own orchestration machinery as distinct from node-level or workload-level metrics. Because every other Kubernetes operation ultimately depends on these components functioning correctly, their metrics are often the first place to look when problems manifest cluster-wide rather than affecting a single workload or node.


API Server Metrics

Request Latency and Rate

The API server exposes detailed request latency histograms broken down by verb, resource, and response code, making it possible to identify whether slow API responses are concentrated on a specific resource type or operation rather than affecting all requests uniformly.

histogram_quantile(0.99, rate(apiserver_request_duration_seconds_bucket[5m]))

Request Rate and Error Rate

apiserver_request_total, segmented by response code, reveals overall request volume and the proportion resulting in errors, useful both for capacity planning (is the API server approaching its request-handling limits) and for detecting a client misbehaving with excessive or repeatedly failing requests.

sum(rate(apiserver_request_total{code=~"5.."}[5m])) by (resource)

Admission Webhook Latency

Because admission webhooks sit directly in the request path, apiserver_admission_webhook_admission_duration_seconds reveals how much latency each registered webhook adds, directly relevant when diagnosing overall API responsiveness degradation traced back to a slow or unhealthy webhook service.


Scheduler Metrics

Scheduling Latency and Queue Depth

scheduler_scheduling_attempt_duration_seconds and scheduler_pending_pods reveal how quickly the scheduler is processing pods and how large its backlog of unscheduled pods has grown, both important signals when pods appear to remain Pending longer than expected even when cluster capacity seems sufficient.

scheduler_pending_pods{queue="unschedulable"}

Scheduling Failure Attribution

Scheduler metrics can be broken down by the specific predicate or plugin responsible for filtering out candidate nodes, complementing scheduler logs with an aggregate, queryable view of which scheduling constraints are most frequently responsible for filtering candidates across the cluster.


Controller Manager Metrics

Reconciliation Rates and Queue Depth

Individual controllers within the controller manager expose work queue depth and processing rate metrics, revealing whether a specific controller (the Deployment controller, for instance) is falling behind on reconciliation, which would manifest as delayed rollout progress or slow response to resource changes cluster-wide.

workqueue_depth{name="deployment"}

Leader Election Status

Because controller-manager and scheduler run with leader election for high availability, metrics reporting current leadership status and the frequency of leadership transitions help distinguish a genuine controller malfunction from a normal, brief reconciliation gap during a leadership handoff.


etcd Metrics

Latency and Consensus Health

etcd exposes metrics for disk write latency (etcd_disk_wal_fsync_duration_seconds), leader election frequency, and proposal commit latency, all of which directly bound how quickly every other control plane component can read and write cluster state — elevated etcd latency is a common root cause of broad, seemingly unrelated control-plane slowness.

histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m]))

Database Size and Compaction

etcd_mvcc_db_total_size_in_bytes and related compaction metrics reveal whether etcd's storage is growing unsustainably, which can degrade performance over time if compaction and defragmentation are not occurring as expected.


Correlating Control Plane Metrics With Cluster-Wide Symptoms

Establishing a Baseline

Because control plane metrics are most useful in comparison against a known-good baseline, establishing dashboards that show typical request latency, scheduling throughput, and etcd performance under normal conditions makes it far easier to recognize a genuine degradation during an incident rather than needing to judge absolute values without context.

Managed Versus Self-Hosted Access

On managed Kubernetes offerings, control plane metrics may be exposed only through the cloud provider's own monitoring integration rather than a directly scrapable endpoint, requiring a different collection approach than a self-managed cluster where these metrics endpoints are typically reachable directly within the cluster network.