Skip to main content
In this lesson we cover the kube-apiserver — the central API endpoint and primary management component of a Kubernetes control plane. All clients (for example kubectl, controllers, and kubelets) communicate with the cluster by talking to the kube-apiserver. The API server authenticates and validates requests, persists cluster state in etcd, and returns responses to clients. Key concepts: kube-apiserver, Kubernetes control plane, etcd, authentication, authorization, admission controllers, TLS.

​
How the API server fits in the control plane

High-level request lifecycle:
  1. A client (e.g., kubectl) sends a request to the kube-apiserver.
  2. The kube-apiserver authenticates and authorizes the request, validates it, and reads or writes API objects in etcd.
  3. The kube-apiserver responds to the client with the requested information or the result of the mutation.
Example: listing nodes

​
Creating a Pod — step-by-step (high-level)

  1. A client (for example kubectl or a program calling the REST API) submits a Pod creation request to the kube-apiserver.
  2. The kube-apiserver authenticates and validates the request and creates a Pod object in etcd. At this point, the Pod has no Node assigned.
  3. The scheduler watches the API server, detects the new Pod without a Node, selects a Node, and updates the Pod object (via the API server) by setting spec.nodeName.
  4. The kube-apiserver updates etcd with the assigned Node.
  5. The appropriate kubelet observes the Pod spec (via the API server) and creates the Pod on the Node by talking to the container runtime.
  6. The kubelet updates the Pod status back to the API server, and the kube-apiserver persists the status into etcd.
This same client → kube-apiserver → etcd → controller/scheduler/kubelet → kube-apiserver → etcd pattern is used for most control-plane changes.

​
Calling the API directly

You can bypass kubectl and POST directly to the API (for example when scripting):
When interacting with the API directly you must handle authentication (client certificates, tokens, or other supported methods) and use HTTPS to secure communication.
Most kube-apiserver flags reference certificate files (CA, server cert/key, client certs) used to secure control-plane communication. Understanding SSL/TLS certificates and how they secure control-plane communication is important when configuring these flags.
Do not access etcd directly from external tools or custom components unless absolutely necessary. Direct access bypasses API-server admission and authorization checks and can lead to inconsistent or insecure cluster state. Prefer the kube-apiserver as the single source of truth.

​
Important operational points

  • The kube-apiserver is the only control-plane component that should talk directly to etcd in a typical setup. Other components (scheduler, controller-manager, kubelets, etc.) read and update state by calling the kube-apiserver.
  • kube-apiserver flags control authentication, authorization, admission controllers, TLS certificates, feature gates, and more. These options determine how cluster components find and secure each other.
  • When debugging control-plane connectivity or authentication, first inspect the kube-apiserver flags, logs, and certificate configuration.

​
Common kube-apiserver flags (summary)

Always verify which flags are supported in the Kubernetes version you run; some flags are deprecated or changed across releases. See Kubernetes documentation for version-specific details.

​
Obtaining the kube-apiserver binary

  • If you bootstrap with kubeadm, you usually don’t need to manage the binary manually.
  • For “hard way” or custom installs, download the binary from Kubernetes releases. Replace vX.Y.Z with the version you need:

​
Example systemd unit (kube-apiserver.service)

Below is an example systemd unit (the ExecStart with common flags) — if you use a different method (for example kubeadm), the API server might be run as a static pod manifest instead.
Note: Some flags in this example (for example --apiserver-count, --enable-swagger-ui, and certain runtime-config values) may be deprecated in newer Kubernetes releases. Always consult official docs for your version.

​
How to view runtime kube-apiserver options

How you inspect kube-apiserver depends on how Kubernetes was installed: Examples:
  • List system pods to find the api-server pod on a kubeadm cluster:
  • To inspect the static pod manifest:
  • For systemd-managed API server:
  • To inspect the running process and flags:

​
Summary

  • kube-apiserver is the central API endpoint for a Kubernetes cluster; it handles authentication, validation, authorization, admission control, and persistence of cluster state in etcd.
  • All cluster components and clients use the kube-apiserver to read and mutate state; treat it as the single entry point for control-plane interactions.
  • When deploying or troubleshooting the control plane, inspect the kube-apiserver flags, certificate configuration, and logs to understand authentication, connectivity, and authorization behavior.

Watch Video