Configuring Core Cluster Components

Kubernetes is an open-source system for managing software workloads across multiple computers (called nodes). Think of it as an operating system for a data centre. Just like your laptop has a kernel that manages processes and hardware, Kubernetes has a set of core components that manage containers (lightweight software units) across a cluster (group of machines).

The absolute centre of everything is the kube-apiserver. This is a single program that expose an API (Application Programming Interface) — a set of rules that allow other programs to talk to it. Every single action in Kubernetes goes through the kube-apiserver: when you run a command like 'kubectl create deployment', your command is sent as a request to the kube-apiserver. It validates that your request is correctly formatted and that you have permission to make it. If everything is fine, it stores your request in a database called etcd. No other component can write to etcd; they all must go through the api-server. Configuring the kube-apiserver means setting its command-line flags. You can set things like which encryption keys to use for secrets, which authentication methods to accept (e.g., client certificates, bearer tokens, or identity services like Microsoft Entra ID), and what port number it listens on. The default configuration is fine for learning, but in a real business you need to lock it down. For example, you might set the '--authorization-mode' flag to 'RBAC' (Role-Based Access Control) to restrict who can see what.

The kube-controller-manager is a single binary that bundles many smaller controllers into one program. Each controller is a loop that constantly watches the current state of the cluster and tries to move it toward the desired state. For example, the Node Controller watches each machine: if a machine stops sending heartbeats (signals of life), the Node Controller marks it as dead. The Replication Controller ensures the correct number of pod copies (called replicas) are running. If someone accidentally kills a pod, the Replication Controller sees that the current count is lower than the desired count and creates a new pod to replace it. The Deployment Controller manages rolling updates — changing a software version without downtime. Configuring the kube-controller-manager involves setting flags like '--node-monitor-period' (how often it checks for dead nodes) and '--leader-elect' (for high availability clusters where multiple machines act as one).

The kube-scheduler is responsible for deciding which node should run a new pod. It does not actually start the pod; it just makes a decision and writes that decision to the api-server. The scheduler works in two phases: filtering and scoring. Filtering removes nodes that cannot run the pod (e.g., they are full, or do not have enough memory). Scoring ranks the remaining nodes based on various criteria, like how many other pods they are running, or how close the pod's data is. The node with the highest score wins. Configuring the scheduler means setting flags like '--policy-config-file' to load custom rules, or using '--kubeconfig' to point it to a specific cluster. For the CKA exam, you often need to know how to use taints and tolerations with the scheduler: you can mark a node with a taint so that only pods that explicitly tolerate that taint are scheduled there.

The kubelet is the node agent — it runs on every machine in the cluster, even the master. It acts as the bridge between the control plane (the api-server, controller, scheduler) and the container runtime (like Docker or containerd). The kubelet takes the pod specification it receives from the api-server and ensures the containers described in that spec are actually running. It constantly reports the health of the node and its pods back to the api-server. Configuring the kubelet is done through a configuration file or command-line flags. Key settings include '--node-ip' (the IP address of the node), '--cluster-dns' (the IP of the DNS service for the cluster), and '--register-node' (whether this node should automatically join the cluster). One critical configuration is authentication: the kubelet needs a certificate to talk securely to the api-server. If you set '--anonymous-auth' to 'false', only authenticated requests are processed.

These four components work together in a loop: you send a desired state (like "run 3 copies of my app") to the api-server, which stores it in etcd. The controller-manager notices the desired state and creates a pod record. The scheduler assigns that pod to a node. The kubelet on that node sees the assignment and starts the container. The controller-manager keeps checking the actual state until it matches the desired state. Each component has its own configuration file or set of flags, and changing any one of them can dramatically change cluster behaviour.

An IT professional managing a Kubernetes cluster for a financial services company spends significant time configuring these core components to meet security and reliability requirements.

The first task is securing the kube-apiserver. The company policy requires that all administrative access be authenticated through Microsoft Entra ID. The engineer starts by enabling OIDC (OpenID Connect) authentication on the api-server. They set the '--oidc-issuer-url' flag to their Microsoft Entra ID tenant, and '--oidc-client-id' to the registered application ID. This means when the engineer runs 'kubectl get pods', their identity token is validated by the api-server against Microsoft Entra ID. They also set '--authorization-mode=RBAC' and create a Role that grants only read access to a specific namespace. They set '--enable-admission-plugins=PodSecurityPolicy' to prevent developers from running containers as root.

Next, they configure the kube-controller-manager. They set '--node-monitor-grace-period=40s' so that the cluster marks a node as unhealthy if it hasn't reported for 40 seconds. They also set '--pod-eviction-timeout=5m' — if a node goes down, the controller waits 5 minutes before evicting its pods and recreating them elsewhere. For a financial application that cannot afford data loss, they set '--terminated-pod-gc-threshold' to handle cleanup carefully. The engineer configures the controller to use a leader election flag for high availability, ensuring a backup controller takes over if the primary fails.

The kube-scheduler is configured with custom priorities. The company runs GPU-intensive machine learning workloads alongside regular web servers. They create a custom scheduler policy that gives higher weight to nodes with GPU devices. They also set resource quotas via the api-server bindings. To isolate sensitive workloads, they apply a taint to a dedicated set of nodes: 'kubectl taint nodes gpu-nodes dedicated=gpu:NoSchedule'. Only pods with a matching toleration can land there.

Finally, each node's kubelet is configured. The engineer sets '--kubelet-extra-args' during bootstrap to specify the node's internal IP (--node-ip) for secure communication behind a firewall. The '--cluster-dns' is set to the IP of the CoreDNS service. They enable node status updates every 10 seconds with '--node-status-update-frequency'. To make the node non-schedulable for maintenance without killing pods, they set '--register-schedulable=false' temporarily.

All of these configurations are deployed as static pod manifests or via configuration files passed to the kubeadm tool. The outcome is a production cluster that meets PCI-DSS compliance, enables secure multi-tenancy, and guarantees 99.9% uptime for trading applications.