What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Step 08 of Kubernetes the Hard Way brings up the control plane on the controller machine: the API server, controller manager, and scheduler. It also configures permissions for the API server to access worker kubelet APIs. The Kubernetes project describes the API server as “the front end for the Kubernetes control plane”; the other two components schedule unassigned pods and reconcile cluster state.
What the three control-plane components do
kube-apiserver: the Kubernetes API front end
The API server exposes the Kubernetes API through which clients and cluster components interact with the control plane. In the documented architecture, the Kubernetes project calls it “the front end for the Kubernetes control plane.” etcd is the consistent, highly available key-value backing store for Kubernetes cluster data; it is distinct from the API server. A real cluster that uses etcd needs a backup plan for that data.
kube-scheduler: choosing a node for a pod
The scheduler watches for newly created pods that do not yet have an assigned node. It selects a node while taking the pod’s resource requirements and scheduling constraints into account. Scheduling is placement selection; it is not the same responsibility as handling API operations.
Recommended Free Tools
kube-controller-manager: reconciling cluster state
The controller manager runs multiple controller processes compiled into one binary. These controllers are control loops that work to bring observed state closer to the desired state. For example, the node controller responds to nodes going down, while the job controller creates pods for Job objects.
#1 Best Overall
What Step 08 sets up
The Kubernetes the Hard Way Step 08 guide installs the controller binaries and kubectl, provisions configuration and credentials, creates systemd service units, starts the services, and checks that the control plane responds. Its filesystem paths and commands describe that guide’s layout; they are not a universal Kubernetes deployment standard.
- Controller binaries and
kubectlgo in/usr/local/bin. - API-server certificates and encryption configuration go under
/var/lib/kubernetes. - Controller-manager and scheduler kubeconfig files are installed for their respective services.
- Scheduler configuration is placed under
/etc/kubernetes/config. - Systemd unit files define the services; systemd is then reloaded before the services are enabled and started.
How the API server gets worker kubelet access
The guide applies a ClusterRole and binding from kube-apiserver-to-kubelet.yaml. This RBAC setup authorizes the API server to access worker kubelet APIs for operations such as retrieving metrics and logs and executing commands in pods. The guide configures kubelet webhook authorization, which uses SubjectAccessReview requests to make authorization decisions. Kubernetes documents the role and binding model in its RBAC authorization reference.
Start and verify the services
After installing the files, the guide reloads systemd, enables and starts the API server, controller manager, and scheduler, and checks their service state. It then verifies the control plane with kubectl cluster-info --kubeconfig admin.kubeconfig. A service being active is useful, but an API request is a separate check that confirms the endpoint responds.
The guide also tests the API endpoint over TLS using the cluster CA certificate:
Rank #3
curl --cacert ca.crt https://server.kubernetes.local:6443/versionThe guide’s sample response reports Kubernetes v1.32.3, build date 2025-03-11, and platform linux/arm64. Those are metadata from that example response, not a claim about the latest Kubernetes release.
Troubleshoot an API server bind error on port 6443
In a lab note published on 2026-09-23, Luger Lex Pit-og reported that kube-apiserver repeatedly restarted after failing to bind 0.0.0.0:6443. The listener inspection identified k3s-server as already holding the port. The author had previously tried k3s on that same machine; stopping and disabling the leftover service resolved the conflict in that lab. This is one reported cause, not a universal explanation for API-server startup failures.
- Inspect the service state with
systemctl status kube-apiserver. - Read the service journal for the specific error with
journalctl -u kube-apiserver. - If the error reports an address or port already in use, inspect which process owns the listener on that port using the tools available on your system.
- Determine whether the listening service is intentional before stopping or disabling it. If it is a leftover service and you are sure it is not needed, stop it, disable it as appropriate for your setup, and check the API-server service again.
This sequence separates the observed failure from its cause: use the journal to identify a bind error, then inspect the actual listener rather than assuming another Kubernetes distribution is responsible.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
