Cluster #

A cluster is the fundamental unit and the smallest physical boundary of the entire Kubernetes ecosystem. When we say we’re “deploying an application to Kubernetes,” that concretely means we’re interacting with a Kubernetes cluster. The cluster abstracts a group of physical machines or Virtual Machines into one unified, giant compute pool.

Understanding how a cluster is structured, how roles are divided within it, and how communication between components is managed is a mandatory first step before diving into Kubernetes’ more specific API objects.

Cluster Role Division: Brain vs Muscle #

A Kubernetes cluster is made up of a number of server machines (known as Nodes) working together. These nodes are divided into two main roles with very clear responsibility boundaries: the Control Plane (Brain) and the Worker Nodes (Muscle).

1. Control Plane (The Cluster’s Brain) #

The Control Plane is fully responsible for global decision-making inside the cluster (such as workload scheduling), detecting any failure, and responding to changes to keep the cluster in its desired state.

The Control Plane consists of several core components working modularly:

  • kube-apiserver: The cluster’s main gateway. All communication (from admins via kubectl, internal applications, and worker nodes) must pass through the API Server. This component validates and processes every request.
  • etcd: A distributed key-value database that is the single source of truth for cluster data. All configuration, status, and object history are stored here consistently.
  • kube-scheduler: The node-finding component. When a new Pod is created, the Scheduler detects the Pod’s resource requirements and finds the most suitable worker node to run it.
  • kube-controller-manager: A set of control loops tasked with keeping the cluster consistent. For example, the Node Controller watches node health, while the Deployment Controller ensures the application replica count always matches.

2. Worker Nodes (The Cluster’s Muscle) #

Worker nodes execute the actual application workloads wrapped in Pods. The components running on worker nodes receive commands from the control plane and periodically report back compute health status.

The main components on a Worker Node include:

  • kubelet: The primary Kubernetes agent running on every node. The kubelet watches the Pod specs (PodSpec) sent by the API Server and ensures the containers inside those Pods run healthily.
  • kube-proxy: The network rule manager at the node level. Kube-proxy forwards traffic from the internal load balancer to the correct application containers.
  • Container Runtime: The software that downloads container images and physically runs them (e.g. containerd or CRI-O).

Cluster Topologies: From Local to High Availability (HA) #

Kubernetes cluster topologies are designed to be very flexible and configurable based on your target workload and agreed-upon downtime tolerance.

1. Single-Node Cluster (Local Development) #

In this topology, all Control Plane and Worker Node components run on the same physical machine or VM. This topology is ideal for experiments, learning, testing CI/CD pipelines, or developing applications on a local laptop using tools like Kind or Minikube.

2. Standard Multi-Node Cluster (Staging) #

The Control Plane runs on one separate dedicated machine, while application workloads are spread across several different Worker Node machines. This pattern separates system workloads from application workloads, so if an application runs out of memory, the cluster’s Control Plane stays safe and doesn’t crash along with it.

3. High Availability Cluster (Production HA) #

For critical production environments, a single-Control-Plane topology is very dangerous because it’s a single point of failure. If the control plane server dies, you lose the ability to monitor, scale, or fix applications.

HA clusters solve this problem by distributing the Control Plane across several servers (usually at least 3 or 5 machines to reach quorum for etcd’s Raft consensus algorithm) behind an external load balancer.

flowchart TD
    subgraph CP_HA["Control Plane High Availability (Multi-Node)"]
        direction TB
        LB["External Load Balancer (Port 6443)"]
        
        CP1["Control Plane Node 1
        (API Server, Controller, Scheduler)"]
        CP2["Control Plane Node 2
        (API Server, Controller, Scheduler)"]
        CP3["Control Plane Node 3
        (API Server, Controller, Scheduler)"]
        
        subgraph ETCD_Cluster["Replicated etcd Cluster"]
            E1["etcd 1"] <--> E2["etcd 2"]
            E2 <--> E3["etcd 3"]
            E3 <--> E1["etcd 1"]
        end
        
        LB --> CP1
        LB --> CP2
        LB --> CP3
        
        CP1 <--> ETCD_Cluster
        CP2 <--> ETCD_Cluster
        CP3 <--> ETCD_Cluster
    end

    subgraph Workers["Worker Nodes Pool"]
        W1["Worker Node 1
        (kubelet, proxy, containerd)"]
        W2["Worker Node 2
        (kubelet, proxy, containerd)"]
        W3["Worker Node 3
        (kubelet, proxy, containerd)"]
    end

    W1 --> LB
    W2 --> LB
    W3 --> LB

    style CP_HA stroke:#8e44ad,stroke-width:2px
    style ETCD_Cluster stroke:#d35400,stroke-width:2px
    style Workers stroke:#27ae60,stroke-width:2px

In the HA architecture above, if Control Plane Node 1 dies suddenly, the load balancer instantly reroutes API request traffic from kubelet to Control Plane Node 2 or Node 3. The cluster keeps functioning normally with no interruption to application lifecycles.

Multi-Cluster Management: Kubeconfig and Context #

As an engineer managing infrastructure, you’ll almost certainly work with more than one Kubernetes cluster at the same time — for example, a local cluster for development, a staging cluster for integration testing, and a production cluster for end users.

Kubernetes manages the credentials and access endpoints of these clusters through a configuration file called kubeconfig, which by default lives in the user’s home folder: ~/.kube/config.

Inside the kubeconfig file, the data is divided into three main sections:

  1. clusters: Contains the API Server endpoint address (e.g. https://prod-k8s.company.com:6443) along with its certificate authority (CA Certificate).
  2. users: Contains authentication tokens or client certificates for cluster users.
  3. contexts: The bridge between clusters and users. It defines the pairing: “I want to connect to cluster X using user Y in namespace Z”.

You can easily inspect and switch the active context using built-in kubectl commands:

# List all contexts registered in the kubeconfig file
kubectl config get-contexts

# Activate the target context (e.g. staging-cluster)
kubectl config use-context staging-cluster

# Check which context is currently active
kubectl config current-context

Anti-Pattern: Running Destructive Commands on the Wrong Context #

Working with multiple clusters in the same terminal carries a very high risk of human error. The most common mistake is executing resource deletion commands on the production cluster because you assumed the terminal was connected to the staging cluster.

ANTI-PATTERN: Running Commands Without Context Validation
// WHAT WE DO:
- Hurriedly run a resource deletion command:
  kubectl delete namespace payment-service
- Assume the terminal is connected to the local/staging cluster.
// THE CONSEQUENCES IN PRODUCTION:
- All Pods, Services, ConfigMaps, and transient database data of the payment service
  in the production cluster are deleted instantly. Total downtime of the transaction system occurs.

✓ THE RIGHT SOLUTION:
- Use active-context visualization on your terminal prompt with tools like
  [kube-ps1](https://github.com/jonmosco/kube-ps1) or a Starship-themed Zsh prompt. The terminal prompt
  always shows the active cluster name visually (e.g. `(k8s:prod-cluster)` in red).
- Use tools like [kubectx](https://github.com/ahmetb/kubectx) and [kubens] to switch clusters and namespaces safely.
- Create dedicated aliases with confirmation protection before running destructive commands on the production cluster.

Logical Division of the Cluster: Namespace #

A physical Kubernetes cluster can be divided into several separate logical sub-clusters using the Namespace object. A Namespace acts as a resource-name isolation space, useful for dividing cluster capacity among multiple teams or separating application environments.

# List all namespaces in the cluster
kubectl get namespaces

# Create a new namespace
kubectl create namespace staging

# View Pods in a specific namespace
kubectl get pods -n staging

Every object in Kubernetes (such as Pod, Service, Deployment) must by default be registered in a namespace. If you don’t specify one, the object goes into the built-in namespace called default.

DNS Name Resolution Format Across Namespaces #

Every time you deploy a Service in a namespace, the cluster’s CoreDNS registers the Service’s domain name using the format:

<service-name>.<namespace-name>.svc.cluster.local

So if a Frontend Pod in the development namespace wants to reach the API Service in the same namespace, it can simply call the short name http://api-service. However, if it wants to call an API in the production namespace, it must use the fully qualified domain name: http://api-service.production.svc.cluster.local.

Namespace Isolation Limits #

Keep in mind that by default, a Namespace only provides resource name isolation, not physical or security isolation.

  • Networking: Pods in the development namespace can, by default, send data packets to Pods in the production namespace. To restrict this communication, you must configure NetworkPolicy objects.
  • Resource Allocation: A single namespace can consume the entire cluster’s CPU/Memory capacity if left unbounded. To prevent dev teams from exhausting production cluster capacity, you must configure ResourceQuota objects at the namespace level.

Summary #

  • A cluster is a unified server abstraction — it merges a group of machine nodes into one large compute resource pool managed by a central API.
  • Control Plane vs Worker Nodes — The Control Plane (API Server, Scheduler, Controller, etcd) makes decisions, while Worker Nodes (kubelet, proxy, runtime) run application Pods.
  • Production Topologies Must Be HA — Running a single Control Plane in production is very risky. HA clusters distribute the control plane across at least 3 nodes behind a load balancer.
  • Kubeconfig and Context — Switching clusters is managed through the ~/.kube/config file. Always use a visual terminal prompt (like kube-ps1) to minimize the risk of running commands on the wrong cluster in production.
  • Namespaces divide the cluster logically — they avoid object name conflicts and divide resource quotas per team. Remember that namespaces don’t block network traffic by default without a NetworkPolicy.

← Previous: When Do You Need It?   Next: Node →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact