Kubernetes Cluster Architecture

 


1. What is Kubernetes cluster architecture?

A Kubernetes cluster has two main parts:

  • Control plane: The brain of the cluster. It decides and coordinates what should happen.

  • Worker nodes: The machines that run your application Pods.

+----------------------+
|    Control Plane     |
+----------------------+
| kube-apiserver       |
| etcd                 |
| kube-scheduler       |
| kube-controller-mgr  |
| cloud-controller     |
+----------------------+
          |
          v
+----------------------+
|     Worker Nodes     |
+----------------------+
| kubelet              |
| container runtime    |
| kube-proxy           |
| Pods                 |
+----------------------+

Think of it like a company:

  • Control plane = management team.

  • Worker nodes = employees doing the actual work.

  • Pods = individual application workloads.

2. Control plane components

There are four main components to understand first.

A. kube-apiserver — the entry point

The API server is the main communication point for Kubernetes.

When you run a command using kubectl, the command communicates with the API server through the Kubernetes API.


Responsibilities

  • Receives all requests
  • Validates requests
  • Authenticates users
  • Authorizes operations
  • Updates cluster state

For example:

kubectl get pods

This asks Kubernetes to show you the Pods in your current namespace.

Or:

kubectl create deployment nginx --image=nginx

This requests that Kubernetes create a Deployment for NGINX.

The API server also handles authentication, authorization, request validation and admission control.

Remember: kubectl → API server → Kubernetes cluster.


B. etcd — the cluster database

etcd stores Kubernetes' persistent cluster state.

etcd is Kubernetes' distributed key-value database.

It stores information such as:

  • Which nodes belong to the cluster.

  • Which Pods and Deployments should exist.

  • Cluster configuration and other Kubernetes objects.

Stores

  • Cluster configuration
  • Node information
  • Pod information
  • Service information
  • Secrets
  • ConfigMaps


Imagine you request three replicas of your application. Kubernetes stores the desired configuration as part of its cluster state.

You normally interact with this information through the Kubernetes API rather than accessing etcd directly.

Remember: etcd = the cluster's database.


C. kube-scheduler — chooses where Pods run

Scheduler decides:

Which node should run a pod?

Suppose you want to run a new Java application Pod. Your cluster has two worker nodes.

  • Node 1 has insufficient available memory.

  • Node 2 has enough available memory.

The scheduler evaluates the Pod's requirements and chooses a suitable node.

An important detail from your lesson: the scheduler assigns a node to the Pod; it does not launch the container itself.

It records the chosen node in the Pod's assignment. The node's kubelet then handles the work of starting it.

The scheduler can consider constraints such as:

  • CPU and memory requirements.

  • Node selection rules.

  • Affinity: prefer or require certain Pods to run near each other.

  • Anti-affinity: prefer or require certain Pods to run separately.

Remember: scheduler = decides where a Pod should run.

D. kube-controller-manager — maintains the desired state

This component runs controllers that continuously monitor Kubernetes resources and try to bring the actual state closer to the desired state.

Example: Keeping three Pods running

Suppose you create a Deployment that requests three replicas of your Java application.

Your desired state:

- Three running replicas.

But one Pod crashes, leaving only two.

A controller detects the difference and works toward restoring three replicas.

Desired state vs actual state

Desired replicas

3

Actual replicas after failure

2

Controller reconciles the state

Kubernetes works to restore the third replica.

This is one of Kubernetes' most important ideas: you declare what you want, and controllers continuously work to achieve it.

The controller manager also runs system controllers, including the node controller, which monitors node health.


2. Worker Node Components

Each worker node runs several agents.


A. kubelet

Think of kubelet as:

Kubernetes agent running on every node.

Responsibilities

  • Receives pod instructions
  • Starts containers
  • Monitors pods
  • Reports status back
API Server
      |
      v
   kubelet
      |
      v
Container Runtime
      |
      v
    Pod

A. kubelet — the node agent

The kubelet is an agent running on each node.

Its responsibilities include:

  • Watching for Pods assigned to its node.

  • Working with the container runtime to start and manage containers.

  • Monitoring container and Pod health.

  • Reporting node and workload status to the control plane.

For example, if the scheduler assigns your Java Pod to Node 1, the kubelet on Node 1 works to make that Pod run.

B. Container runtime — runs containers

The container runtime is the software responsible for starting containers from container images.

Your lesson mentions containerd, which is the container runtime used by GKE node configurations discussed in the course.

The relationship is:

  • Container image = packaged application.

  • Container runtime = software that runs the container.

  • kubelet = agent that instructs and monitors the runtime as part of Pod management.

C. kube-proxy — helps with networking

In the architecture described in your lesson, kube-proxy helps maintain network connectivity and implements Kubernetes Service networking rules on nodes.

This helps traffic reach the appropriate Pods through Kubernetes Services.

The course mentions iptables as one mechanism used by kube-proxy. Some Kubernetes environments use other networking implementations, so the exact mechanism depends on the cluster configuration.

Remember: kube-proxy = helps direct network traffic to the right Pods in configurations that use it.

4. What happens when you deploy an application?

Let's put the components together with a practical example.

You want to deploy a Java Spring Boot application with three replicas.

1

You run kubectl

You request a Deployment with three replicas.

2

kube-apiserver

Receives and validates your request.

3

etcd

The cluster's persistent state is updated through the API server.

4

Controller manager

The Deployment and ReplicaSet controllers work toward three replicas.

5

kube-scheduler

Assigns unassigned Pods to suitable worker nodes.

6

kubelet + container runtime

The kubelet works with the runtime to start containers on each assigned node.

7

Health and networking

Kubernetes monitors status, while the configured networking components enable traffic to reach the application.

One useful detail: creating a Deployment does not directly command the scheduler to launch containers. Instead, Kubernetes components work together through the API and reconcile the desired state.



The five components to memorize first:

  • kube-apiserver — accepts API requests.

  • etcd — stores cluster state.

  • kube-scheduler — chooses where Pods run.

  • kube-controller-manager — works toward the desired state.

  • kubelet — manages Pods on its node.

Comments

Post a Comment

Popular posts from this blog

Async/await

  Async/await An async function is a function declared with the async keyword, and the await keyword is permitted within them. The async and await keywords enable asynchronous, promise-based behavior to be written in a cleaner style, avoiding the need to explicitly configure promise chains. "async and await make promises easier to write" async  makes a function return a Promise await  makes a function wait for a Promise  Async functions Let’s start with the async keyword. It can be placed before a function, like this: async function f() {   return 1; } The word “async” before a function means one simple thing: a function always returns a promise. Other values are wrapped in a resolved promise automatically. For instance, this function returns a resolved promise with the result of 1; let’s test it: async function f() {   return 1; } f().then(alert); // 1 …We could explicitly return a promise, which would be the same: async function f() {   return Promis...
Read more

Valid Parentheses

Given a string s containing just the characters '(', ')', '{', '}', '[' and ']', determine if the input string is valid. An input string is valid if: Open brackets must be closed by the same type of brackets. Open brackets must be closed in the correct order. Every close bracket has a corresponding open bracket of the same type.   Example 1: Input: s = "()" Output: true Example 2: Input: s = "()[]{}" Output: true Example 3: Input: s = "(]" Output: false Example 4: Input: s = "([])" Output: true   Stack-Based Logic: Traverse each character in the string. If it's an opening bracket ( '(' , '{' , '[' ), push it onto the stack. If it's a closing bracket ( ')' , '}' , ']' ): If the stack is empty , return false (nothing to match). If the top of the stack is the corresponding opening bracket , pop it. Otherwise, return false . ...
Read more

kafka

  ✅ spring.kafka.bootstrap-servers=localhost:9092 🧠 Meaning: The address of the Kafka broker (the server that stores and processes messages). ✅ Why: This tells Spring Boot where to send/receive Kafka messages. 🛠 If you’re running Kafka locally, use localhost:9092 . In production, you may have multiple brokers: kafka1:9092,kafka2:9092,... ✅ spring.kafka.consumer.group-id=my-group 🧠 Meaning: Assigns the consumer group ID to your consumer. ✅ Why: Kafka uses this to track which consumer read which message. If two consumers share the same group ID, Kafka will load-balance messages between them. 🔄 Helps in parallel processing and message tracking ✅ spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer ✅ spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer 🧠 Meaning: Kafka sends binary data . These settings tell Kafka how to convert data back into Java strings (deserialize). ✅ W...
Read more