Version focus: Kubernetes v1.36 current line
Last verified: 2026-07-04
Primary use: CKA / CKAD / CKS foundation, platform engineering, EKS/AKS/GKE architecture prep

Important current-version correction

Is Ingress replaced by API Gateway now?

No. Not exactly. The accurate current statement is:

Ingress is still part of Kubernetes. It is stable as networking.k8s.io/v1 and Kubernetes has no plan to remove it.
Ingress is frozen. The Kubernetes project recommends Gateway API instead of Ingress for newer, more advanced traffic routing needs.
Gateway API is not the same thing as a cloud API Gateway product. Gateway API is a Kubernetes-native set of extension APIs, implemented as CRDs, such as GatewayClass, Gateway, HTTPRoute, and GRPCRoute.
API Gateway products such as AWS API Gateway, Kong Gateway, Apigee, Azure API Management, Envoy Gateway, or NGINX/Kong/Traefik-based gateways may sit in front of Kubernetes or implement Kubernetes Gateway API, but they are separate products or controllers.

The clean mental model:

Ingress        = old/stable/frozen Kubernetes HTTP routing API
Gateway API    = recommended Kubernetes-native successor for richer routing
API Gateway    = product/category, not a built-in Kubernetes object

For learning:

CKA: know Ingress very well.
Platform engineering: learn Gateway API too.
Production new design: prefer Gateway API when your environment supports it.
Legacy clusters: you will still see Ingress everywhere.

Current Kubernetes version notes

As of this update, the current Kubernetes release line is v1.36, with Kubernetes v1.36.2 available as the latest patch release on the official release page at the time of verification.

Kubernetes currently maintains the most recent three minor release branches:

v1.36
v1.35
v1.34

Current architecture notes that matter:

The core cluster model is still control plane + worker nodes.
The main control plane components are still kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and usually cloud-controller-manager in cloud environments.
The main node components are still kubelet, a CRI-compatible container runtime, kube-proxy or an eBPF replacement, CNI networking, CSI storage integration, and Pods.
Gateway API is now the recommended direction for advanced service networking beyond Ingress.
Ingress remains stable but frozen. Do not say it has been removed.
Service .spec.externalIPs is deprecated in v1.36, with removal planned for a later release.
The old gitRepo volume driver is removed/disabled in v1.36. Use init containers, sidecars, or external sync tools instead.
User namespaces are GA in v1.36 for Linux workloads using hostUsers: false.
Dynamic Resource Allocation continues to mature and matters for GPUs, accelerators, and specialized hardware.

What Kubernetes Is
Big Picture Architecture
The Core Mental Model
Control Plane vs Data Plane
Control Plane Components
Worker Node / Data Plane Components
Core Kubernetes Objects
Ingress, Gateway API, and API Gateway
Deployment Creation Lifecycle
Desired State and Reconciliation
Kubernetes Networking Architecture
Storage Architecture
Security Architecture
Scheduling Architecture
Autoscaling Architecture
Rolling Updates and Rollbacks
Health Checks and Probes
Add-ons and Ecosystem Components
High Availability Architecture
Managed Kubernetes Architecture
Failure Scenarios
Complete Traffic Flow Example
Kubernetes Architecture as Layers
CKA-Focused Summary
Final Complete Architecture Diagram
Current-Version Checklist
References

1. What Kubernetes Is

Kubernetes is best understood as a distributed operating system for containers.

It is not just a container runner. It is a system that manages application deployment, scaling, networking, storage, configuration, availability, scheduling, rollout, rollback, and recovery across multiple machines.

You tell Kubernetes:

I want 3 copies of this application running, exposed on this port, with these CPU and memory requirements, this configuration, this secret, this storage, and this update strategy.

Kubernetes continuously watches the cluster and tries to make the actual state match the desired state.

The most important Kubernetes idea:

Desired state -> Kubernetes control loops -> Actual state

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

You are not directly starting three containers. You are declaring desired state. Kubernetes then creates the required lower-level objects and keeps them running.

2. Big Picture Architecture

A Kubernetes cluster has two major sides:

2.1 Control plane

The control plane is the brain of the cluster.

It decides:

what should exist
where Pods should run
how many replicas should exist
which workloads are healthy
which workloads need replacement
which users, workloads, and controllers are allowed to do what
which cloud resources may need to be created

2.2 Worker nodes / data plane

The worker nodes are where your applications actually run.

The term data plane is commonly used to describe the runtime path where application workloads, Pod networking, Services, traffic routing, storage mounts, and container execution happen.

Kubernetes officially describes the cluster as:

Control Plane + Worker Nodes

In practical platform engineering language:

Control Plane = decision making and cluster state management
Data Plane    = workload execution and traffic/data movement

2.3 Complete high-level cluster diagram

Diagram preview

3. The Core Mental Model

Kubernetes works through API objects and reconciliation loops.

You submit desired state
        |
        v
kube-apiserver receives and validates it
        |
        v
etcd stores it
        |
        v
controllers notice what is missing or incorrect
        |
        v
scheduler chooses a node for unscheduled Pods
        |
        v
kubelet on that node starts the Pod
        |
        v
container runtime runs the containers
        |
        v
networking and storage components connect everything

When you run:

kubectl apply -f deployment.yaml

You are not directly SSHing into a server and starting containers. You are talking to the Kubernetes API server.

The API server records your desired state. Then the rest of the system reacts.

4. Control Plane vs Data Plane

4.1 Control plane

The control plane makes decisions and stores cluster state.

It answers questions like:

What objects exist in the cluster?
How many Pods should be running?
Which node should run a new Pod?
Is a node healthy?
Should a failed Pod be replaced?
Should a cloud load balancer or disk be created?
Who is allowed to do this operation?

Main components:

kube-apiserver
etcd
kube-scheduler
kube-controller-manager
cloud-controller-manager

4.2 Data plane

The data plane does the actual runtime work.

It answers questions like:

Which containers are running?
How does traffic reach a Pod?
How does one Pod talk to another Pod?
How are volumes mounted?
How are logs and health checks handled?
How are Services implemented on the node?

Main components:

kubelet
container runtime
kube-proxy or eBPF service datapath
CNI plugin
CSI plugin
Pods
Services
Volumes
node OS/kernel

Diagram preview

Important point:

Your application traffic normally does not flow through the control plane.

For example, when a user accesses your web app, the traffic path is usually:

User -> Load Balancer -> Gateway/Ingress -> Service -> Pod

It does not normally go through kube-apiserver.

5. Control Plane Components

5.1 kube-apiserver

kube-apiserver is the front door of Kubernetes.

Everything talks to it:

kubectl
controllers
scheduler
kubelets
operators
CI/CD systems
dashboards
admission controllers
custom controllers

kubectl / clients
      |
      v
kube-apiserver
      |
      v
etcd

The API server handles:

authentication
authorization
admission control
API validation
object persistence
API watches
communication with etcd
communication with kubelets
exposing the Kubernetes API

Request flow through the API server

Diagram preview

Authentication vs authorization

Authentication asks:

Who are you?

Authorization asks:

What are you allowed to do?

Example:

Nauman is authenticated.
Nauman can list Pods in namespace dev.
Nauman cannot delete nodes.

This is usually controlled with RBAC.

5.2 etcd

etcd is the strongly consistent key-value database used by Kubernetes to store cluster state.

It stores objects such as:

Pods
Deployments
ReplicaSets
Services
EndpointSlices
ConfigMaps
Secrets
Nodes
Namespaces
RBAC objects
PersistentVolumeClaims
Custom resources
Events

kube-apiserver <----> etcd

Important rules:

Normally, only the API server talks directly to etcd.
Other Kubernetes components talk to the API server.
If etcd is lost without backup, the cluster state is lost.
Existing containers may keep running for some time, but Kubernetes no longer has its source of truth.

Production etcd should be:

backed up regularly
encrypted at rest where required
protected with strict access controls
monitored carefully
run in an odd-numbered HA cluster, commonly 3 or 5 members

5.3 kube-scheduler

The scheduler decides which node should run a newly created Pod.

It does not start containers. It only assigns an unscheduled Pod to a node.

Pod created without nodeName
        |
        v
scheduler notices it
        |
        v
scheduler filters possible nodes
        |
        v
scheduler scores remaining nodes
        |
        v
scheduler binds Pod to selected node
        |
        v
kubelet on that node starts it

Diagram preview

The scheduler considers:

CPU requests
memory requests
node capacity
node labels
taints and tolerations
node selectors
node affinity
Pod affinity and anti-affinity
topology spread constraints
volume constraints
resource availability
device and accelerator requests
scheduling policies and plugins

Example:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"

This tells the scheduler:

Only place this Pod on a node that has at least this much available allocatable capacity.

5.4 kube-controller-manager

kube-controller-manager runs many built-in controllers.

A controller is a loop that constantly compares:

desired state vs current state

Example:

Desired state: 3 Pods
Current state: 2 Pods
Controller action: create 1 more Pod

Diagram preview

Important controllers include:

Controller	What it does
Node controller	Watches node health and node lifecycle
ReplicaSet controller	Maintains desired number of Pods
Deployment controller	Manages rollout and rollback through ReplicaSets
Job controller	Ensures Jobs run to completion
CronJob controller	Creates Jobs on a schedule
EndpointSlice controller	Tracks backend endpoints for Services
ServiceAccount controller	Creates default ServiceAccounts
Namespace controller	Handles namespace lifecycle and cleanup
PersistentVolume controller	Handles PV/PVC binding
Garbage collector	Cleans up dependent resources using owner references
TTL controller	Cleans up eligible finished resources

Example:

kubectl create deployment nginx --image=nginx --replicas=3

What happens conceptually:

Deployment controller creates ReplicaSet
ReplicaSet controller creates Pods
Scheduler assigns Pods to nodes
Kubelets run the containers

5.5 cloud-controller-manager

cloud-controller-manager connects Kubernetes to the underlying cloud provider.

It handles cloud-specific logic such as:

cloud node metadata
cloud node lifecycle checks
cloud load balancer provisioning
cloud route management
some cloud volume interactions, depending on provider and driver design

Example:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

In a cloud environment, this may cause a cloud load balancer to be created.

Diagram preview

In managed Kubernetes:

EKS integrates with AWS load balancers, node groups, IAM, and cloud networking.
AKS integrates with Azure load balancers, managed identities, Azure CNI, disks, and VNets.
GKE integrates with Google Cloud load balancers, disks, IAM, and VPC networking.

6. Worker Node / Data Plane Components

A worker node is where your application workloads run.

Each worker node typically has:

kubelet
container runtime
kube-proxy or replacement datapath
CNI networking
CSI node plugin
Pods
node OS / kernel

Diagram preview

6.1 kubelet

kubelet is the node agent.

It runs on every node and makes sure containers described by PodSpecs are running and healthy.

The kubelet:

registers the node with the cluster
watches for Pods assigned to its node
asks the container runtime to start containers
mounts volumes
runs liveness, readiness, and startup probes
reports Pod status back to the API server
reports node status back to the API server
restarts containers when required
manages static Pods on some control-plane nodes

kube-apiserver
     |
     v
kubelet on node
     |
     v
container runtime
     |
     v
containers

Important:

The scheduler chooses the node.
The kubelet runs the Pod on that node.

6.2 Container runtime

The container runtime actually runs containers.

Common runtimes:

containerd
CRI-O

The kubelet talks to the runtime through the Container Runtime Interface, or CRI.

Diagram preview

The runtime handles:

pulling images
creating containers
starting containers
stopping containers
reporting container status
integrating with low-level runtimes such as runc
preparing Pod sandboxes

Current note:

Docker Engine itself is not the direct Kubernetes runtime path anymore.
Kubernetes uses CRI-compatible runtimes such as containerd or CRI-O.

Docker images still work because the image format is OCI-compatible. What changed is the runtime integration path.

6.3 kube-proxy

kube-proxy helps implement Kubernetes Service networking on nodes.

Services provide stable virtual access to changing Pods.

Client -> Service IP / DNS -> one of the matching Pods

Diagram preview

kube-proxy watches Services and EndpointSlices and programs node-level forwarding rules.

Depending on cluster implementation, Service routing may use:

iptables
IPVS
nftables in some environments
eBPF-based datapaths through CNI projects such as Cilium

Current nuance:

kube-proxy is still a standard Kubernetes node component,
but some modern clusters replace or bypass parts of it with an eBPF datapath.

For CKA, understand kube-proxy. For modern platform engineering, also understand Cilium/eBPF service routing.

6.4 CNI plugin

CNI means Container Network Interface.

The CNI plugin gives Pods networking.

It handles:

assigning Pod IPs
connecting Pods to the node network
enabling Pod-to-Pod communication
routing traffic across nodes
enforcing NetworkPolicies, if supported
sometimes replacing kube-proxy functionality

Common CNI plugins:

Calico
Cilium
Flannel
Antrea
Weave Net
AWS VPC CNI
Azure CNI
GKE Dataplane

Kubernetes requires a CNI plugin to implement the Kubernetes network model.

Important current note:

CNI management is not the kubelet's job anymore.
The container runtime and node setup are responsible for loading and using CNI plugins.

6.5 CSI plugin

CSI means Container Storage Interface.

It lets Kubernetes use different storage systems through standard interfaces.

Examples:

AWS EBS
Azure Disk
Google Persistent Disk
NFS
Ceph
Longhorn
Portworx
vSphere storage

CSI handles:

provisioning volumes
attaching volumes to nodes
mounting volumes into Pods
detaching volumes
deleting volumes
resizing volumes, if supported
snapshots and advanced storage features, if supported

Diagram preview

7. Core Kubernetes Objects

Kubernetes architecture is easier once you understand the objects Kubernetes manages.

7.1 Pod

A Pod is the smallest deployable unit in Kubernetes.

A Pod contains one or more containers.

Containers inside the same Pod share:

network namespace
IP address
port space
volumes, if mounted
localhost communication

Diagram preview

Examples of sidecars:

log shipper
service mesh proxy
metrics exporter
config reloader
security agent

Important:

In production, you usually do not create bare Pods directly.
You create higher-level objects that manage Pods.

Common Pod-managing objects:

Deployment
StatefulSet
DaemonSet
Job
CronJob

7.2 Deployment

A Deployment manages stateless applications.

It gives you:

replicas
rolling updates
rollbacks
self-healing
versioned rollout history
declarative Pod template management

Diagram preview

When you update the image:

kubectl set image deployment/web web=nginx:1.27

Kubernetes creates a new ReplicaSet and gradually moves from old Pods to new Pods.

Diagram preview

7.3 ReplicaSet

A ReplicaSet ensures that a specified number of Pod replicas exist.

You usually do not manage ReplicaSets directly.

Deployments manage ReplicaSets for you.

Deployment -> ReplicaSet -> Pods

7.4 StatefulSet

A StatefulSet manages stateful applications.

Use it when Pods need:

stable identity
stable network names
ordered startup and shutdown
stable persistent storage
predictable Pod names

Examples:

databases
Kafka
ZooKeeper
Elasticsearch / OpenSearch
Redis clusters, depending on design

Diagram preview

Difference from Deployment:

Deployment Pods:
web-7f9d8c-xk2la
web-7f9d8c-p0s9f
web-7f9d8c-aa82m

StatefulSet Pods:
postgres-0
postgres-1
postgres-2

7.5 DaemonSet

A DaemonSet runs one Pod on every node, or every matching node.

Used for node-level agents:

log collectors
monitoring agents
CNI agents
storage agents
security agents
node exporters

Diagram preview

Examples:

One Fluent Bit Pod per node.
One Cilium agent per node.
One node-exporter Pod per node.

7.6 Job and CronJob

A Job runs Pods until a task completes successfully.

Examples:

database migration
batch processing
report generation
data import
one-time script

A CronJob creates Jobs on a schedule.

Diagram preview

7.7 Service

A Service exposes a stable network endpoint for a group of Pods.

Why Services matter:

Pods are temporary.
Pod IPs change.
Services provide stable access.

Diagram preview

Common Service types:

Service Type	Purpose
ClusterIP	Internal-only stable IP. Default type.
NodePort	Exposes service on every node's port.
LoadBalancer	Requests an external load balancer from the platform/cloud.
ExternalName	Maps a Service to an external DNS name.
Headless Service	No virtual IP; DNS returns backend Pod IPs directly.

Current warning:

Do not rely on Service .spec.externalIPs for new designs.
It is deprecated in Kubernetes v1.36.

Prefer cloud load balancers, Gateway API, Ingress/Gateway controllers, or proper edge routing depending on the use case.

7.8 EndpointSlice

A Service uses selectors to find matching Pods.

Kubernetes stores the actual backend endpoints in EndpointSlices.

Service selector:
app=web

Matching Pod IPs:
10.244.1.10
10.244.2.15
10.244.3.20

EndpointSlice tracks these backends.

Diagram preview

EndpointSlices replaced the older Endpoints object as the scalable backend tracking mechanism.

7.9 ConfigMap

A ConfigMap stores non-sensitive configuration.

Examples:

environment names
feature flags
app settings
config files

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_MODE: production
  LOG_LEVEL: info

A Pod can consume a ConfigMap as:

environment variables
mounted files
command arguments

7.10 Secret

A Secret stores sensitive values.

Examples:

passwords
API keys
tokens
TLS certificates

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: base64-value

Important:

Base64 is not encryption.

In production, care about:

etcd encryption at rest
strict RBAC
avoiding secrets in logs
external secret managers
secret rotation
short-lived credentials where possible

Common secret tooling:

External Secrets Operator
Secrets Store CSI Driver
Sealed Secrets
cloud secret managers

7.11 Namespace

A Namespace is a logical partition inside a cluster.

Used for:

separating teams
separating environments
organizing resources
RBAC boundaries
quotas
network policies

cluster
 ├── default
 ├── kube-system
 ├── dev
 ├── staging
 └── production

Namespaces are not strong security boundaries by themselves.

For real isolation, combine them with:

RBAC
NetworkPolicy
ResourceQuota
LimitRange
admission policies
Pod Security Standards
separate node pools
sometimes separate clusters

7.12 ServiceAccount

A ServiceAccount is an identity for Pods.

Human users use identities like:

nauman@example.com

Pods use ServiceAccounts like:

system:serviceaccount:production:backend-api

This matters for RBAC.

Example:

backend-api Pod can read ConfigMaps.
backend-api Pod cannot delete Secrets.

7.13 RBAC

RBAC means Role-Based Access Control.

Main objects:

Object	Scope	Purpose
Role	Namespace	Permissions inside one namespace
ClusterRole	Cluster-wide	Permissions across cluster or non-namespaced resources
RoleBinding	Namespace	Assigns Role/ClusterRole to user/group/service account
ClusterRoleBinding	Cluster-wide	Assigns ClusterRole cluster-wide

Example permission idea:

Allow this ServiceAccount to get, list, and watch Pods in namespace dev.

7.14 PersistentVolume, PersistentVolumeClaim, StorageClass

Kubernetes separates storage into three main ideas.

PersistentVolume

The actual storage resource.

10Gi disk
NFS share
EBS volume
Azure Disk
Google Persistent Disk
Ceph volume

PersistentVolumeClaim

A request for storage.

I need 10Gi of storage.

StorageClass

Defines how storage should be dynamically provisioned.

Use gp3 EBS volumes.
Use Azure managed disks.
Use fast SSD.
Use replicated storage.

Diagram preview

Current warning:

gitRepo volume is no longer a valid modern design.
Use init containers, sidecars, or external sync tools instead.

8. Ingress, Gateway API, and API Gateway

This deserves its own section because the naming is confusing.

8.1 Ingress

Ingress exposes HTTP and HTTPS routes from outside the cluster to Services inside the cluster.

Diagram preview

Ingress supports:

host-based routing
path-based routing
TLS termination
routing to Services

Example:

api.example.com/users  -> users-service
api.example.com/orders -> orders-service

Important:

Ingress is only the API object.
You need an Ingress Controller to make it work.

Common Ingress controllers:

NGINX Ingress Controller
Traefik
HAProxy
Contour
Istio Ingress
Kong Ingress Controller
cloud provider controllers

Current status:

Ingress is stable.
Ingress is frozen.
Kubernetes has no plan to remove it.
Gateway API is recommended for newer, richer traffic-routing use cases.

8.2 Gateway API

Gateway API is the Kubernetes-native successor direction for service networking.

It is more expressive than Ingress and separates responsibilities more cleanly.

Gateway API is implemented through extension APIs / CRDs.

Important Gateway API objects:

Object	Purpose
GatewayClass	Defines a class of gateways managed by a specific controller
Gateway	Defines an instance of traffic handling infrastructure
HTTPRoute	Defines HTTP routing rules
GRPCRoute	Defines gRPC routing rules
TLSRoute	Defines TLS routing rules where supported
ReferenceGrant	Allows safe cross-namespace references

Diagram preview

Why Gateway API is better for modern platform work:

role-oriented design
better separation between platform teams and app teams
richer routing without controller-specific annotation sprawl
traffic weighting
header matching
route delegation
cross-namespace reference controls
better extensibility
clearer conformance model

8.3 API Gateway products

An API Gateway product is different from Kubernetes Gateway API.

Examples:

AWS API Gateway
Azure API Management
Google API Gateway / Apigee
Kong Gateway
Tyk
Ambassador / Emissary
Envoy Gateway

These can provide features such as:

authentication
API keys
rate limiting
request transformation
WAF integration
developer portals
monetization
analytics
API lifecycle management

They may sit:

Outside Kubernetes -> in front of cluster
Inside Kubernetes  -> as a gateway/controller
Integrated with Gateway API -> controller implements Gateway API

8.4 Which one should you use?

Use case	Best fit
CKA exam basics	Ingress
Existing Kubernetes apps	Ingress may still be fine
New platform routing design	Gateway API
Multi-team routing ownership	Gateway API
Header matching, traffic splitting, richer routing	Gateway API
API product management, API keys, monetization	API Gateway product
Cloud-native external HTTP routing	Gateway API or cloud LB controller
Legacy NGINX annotation-heavy setup	Consider migration to Gateway API

The clean answer:

Ingress was not replaced by “API Gateway”.
Ingress is being superseded by Kubernetes Gateway API for future routing patterns.
API Gateway products are separate tools that may integrate with Kubernetes.

9. Deployment Creation Lifecycle

What happens when you create a Deployment?

kubectl apply -f deployment.yaml

Diagram preview

In plain English:

You submit YAML.
API server validates it.
API server stores it in etcd.
Deployment controller creates a ReplicaSet.
ReplicaSet controller creates Pods.
Scheduler assigns Pods to nodes.
Kubelet starts the assigned Pods.
Container runtime pulls images and runs containers.
Kubelet reports status back.
Kubernetes keeps watching and reconciling.

10. Desired State and Reconciliation

This is the heart of Kubernetes.

You declare desired state:

replicas: 3

Kubernetes compares:

Desired state: 3 Pods
Current state: 2 Pods
Action: create 1 Pod

Or:

Desired state: 3 Pods
Current state: 4 Pods
Action: delete 1 Pod

This is called reconciliation.

Diagram preview

This is why Kubernetes is self-healing.

If a Pod dies:

ReplicaSet wanted 3
Only 2 are running
Create another Pod

If a node dies:

Node controller marks node unhealthy
Pods eventually get evicted/rescheduled
ReplicaSet/Deployment restores desired count

11. Kubernetes Networking Architecture

Kubernetes networking has several layers.

Container-to-container
Pod-to-Pod
Pod-to-Service
External-to-Service
Gateway/Ingress-to-Service
Node-to-control-plane

Kubernetes gives each Pod its own IP address inside the cluster network.

11.1 Container-to-container networking

Containers in the same Pod share the same network namespace.

They can talk over localhost.

Diagram preview

11.2 Pod-to-Pod networking

Every Pod gets its own IP.

Pods should be able to communicate across nodes.

Diagram preview

The CNI plugin makes this possible.

Depending on the CNI, this may use:

overlay networking
native cloud VPC networking
routing tables
eBPF
VXLAN
BGP
direct routing

11.3 Pod-to-Service networking

Pods usually do not call other Pods directly.

They call Services.

frontend Pod -> backend Service -> backend Pods

Diagram preview

The Service gives:

stable DNS name
stable virtual IP
load balancing across matching Pods

Example DNS:

backend-service.default.svc.cluster.local

11.4 Service discovery with CoreDNS

CoreDNS provides DNS inside the cluster.

A Pod can call:

http://backend-service:8080

CoreDNS resolves that Service name.

Diagram preview

Common DNS forms:

backend-service
backend-service.default
backend-service.default.svc
backend-service.default.svc.cluster.local

11.5 External traffic

External traffic commonly flows like this:

User
  |
  v
DNS
  |
  v
Cloud Load Balancer
  |
  v
Gateway API Controller or Ingress Controller
  |
  v
Kubernetes Service
  |
  v
Pod

Diagram preview

For cloud clusters, Service type: LoadBalancer often asks the cloud provider to provision an external load balancer.

11.6 NetworkPolicy

By default, many Kubernetes network setups allow broad Pod-to-Pod communication unless restricted.

NetworkPolicy lets you control traffic.

Example:

Only frontend Pods can call backend Pods on port 8080.
Only backend Pods can call database Pods on port 5432.

Diagram preview

Important:

NetworkPolicy only works if your CNI supports and enforces it.

Calico and Cilium support NetworkPolicy. Basic Flannel by itself has traditionally not enforced NetworkPolicy.

12. Storage Architecture

Containers are ephemeral.

If a container dies, its local writable filesystem may disappear.

Kubernetes uses volumes for storage.

12.1 Common volume types

Volume Type	Purpose
emptyDir	Temporary storage for a Pod lifetime
configMap	Mount config as files
secret	Mount secrets as files
persistentVolumeClaim	Mount persistent storage
projected	Combine multiple volume sources
downwardAPI	Expose Pod metadata as files/env
hostPath	Mount a path from node; use carefully

Current warning:

gitRepo volume is removed/disabled in modern Kubernetes v1.36.
Do not use it for new workloads.

12.2 Persistent storage flow

Diagram preview

For a database on Kubernetes:

StatefulSet
  |
  v
Pod postgres-0
  |
  v
PVC postgres-data-postgres-0
  |
  v
PV
  |
  v
Cloud disk / storage backend

13. Security Architecture

Kubernetes security has many layers.

Authentication
Authorization
Admission control
RBAC
ServiceAccounts
Secrets
NetworkPolicy
Pod Security Standards
Image security
Node security
Runtime security
etcd security
Audit logging
Supply chain security

13.1 API request security path

Diagram preview

13.2 Main security pieces

Component	Purpose
Authentication	Verifies identity
Authorization	Checks permission
RBAC	Defines access rules
Admission Controllers	Validate or mutate requests before persistence
ServiceAccounts	Pod identities
Secrets	Sensitive values
NetworkPolicy	Controls Pod traffic
Pod Security Standards	Restrict risky Pod settings
Image scanning	Detect vulnerable images
Runtime security	Detect suspicious behavior
etcd encryption	Protect stored secrets/state
Audit logs	Record API activity

Example RBAC idea:

CI/CD ServiceAccount can update Deployments in staging.
It cannot delete Secrets.
It cannot modify cluster-wide RBAC.

13.3 User namespaces in v1.36

User namespaces are GA in Kubernetes v1.36 for Linux.

The key idea:

Root inside the container does not have to mean root on the host.

Example Pod field:

spec:
  hostUsers: false

This can improve isolation for some workloads by mapping container users away from host users.

14. Scheduling Architecture

When a Pod needs a node, the scheduler goes through two major phases.

14.1 Filtering

Remove nodes that cannot run the Pod.

Reasons:

not enough CPU
not enough memory
wrong node label
taint not tolerated
volume cannot attach
node unschedulable
required affinity not satisfied
required topology constraints not satisfied
requested devices unavailable

14.2 Scoring

Rank the remaining nodes.

Reasons:

better resource balance
preferred affinity
topology spread
image locality
lower conflict
scheduling plugin scores

Diagram preview

Example node selector:

nodeSelector:
  disk: ssd

The scheduler only considers nodes with:

disk=ssd

Example taint/toleration:

Node has taint: dedicated=gpu:NoSchedule
Pod needs a matching toleration to run there.

15. Autoscaling Architecture

Kubernetes has several autoscaling layers.

15.1 Horizontal Pod Autoscaler

HPA changes the number of Pod replicas.

CPU high -> increase replicas
CPU low  -> decrease replicas

Diagram preview

Example:

Deployment has 3 Pods.
CPU goes above target.
HPA increases replicas to 6.

15.2 Vertical Pod Autoscaler

VPA changes CPU/memory requests.

Pod needs more memory -> increase memory request
Pod over-requesting CPU -> reduce CPU request

VPA helps right-size workloads.

15.3 Cluster Autoscaler

Cluster Autoscaler changes the number of nodes.

Pending Pods cannot fit -> add node
Nodes underused -> remove node

Diagram preview

15.4 Karpenter

In AWS EKS environments, Karpenter is commonly used for flexible node provisioning.

It can launch right-sized nodes based on pending Pods.

Pending Pod needs 4 CPU / 16Gi memory
Karpenter finds suitable EC2 instance type
Launches node
Pod gets scheduled

For EKS/platform engineering, Karpenter is worth learning after basic Cluster Autoscaler.

15.5 KEDA

KEDA provides event-driven autoscaling.

It can scale workloads based on event sources such as:

queues
Kafka topics
Prometheus metrics
cloud event sources
custom scalers

Example:

SQS queue depth increases -> KEDA scales worker Deployment

16. Rolling Updates and Rollbacks

When you update a Deployment, Kubernetes usually does not kill everything at once.

It gradually replaces old Pods with new Pods.

Diagram preview

Controlled by:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

Meaning:

maxUnavailable: at most 1 Pod can be unavailable during rollout
maxSurge: at most 1 extra Pod can be created during rollout

Rollout flow:

Create 1 new Pod
Wait until ready
Remove 1 old Pod
Create another new Pod
Wait until ready
Remove another old Pod
...

Useful commands:

kubectl rollout status deployment/web
kubectl rollout history deployment/web
kubectl rollout undo deployment/web

17. Health Checks and Probes

Kubernetes uses probes to understand container health.

17.1 Liveness probe

Checks if the container is alive.

If it fails, kubelet restarts the container.

Is the app stuck/dead?
If yes, restart it.

17.2 Readiness probe

Checks if the container is ready to receive traffic.

If it fails, Kubernetes removes the Pod from Service endpoints.

Is the app ready for requests?
If no, stop sending traffic to it.

17.3 Startup probe

Gives slow-starting apps time to boot.

Useful for apps that take a long time to start.

Diagram preview

18. Add-ons and Ecosystem Components

Kubernetes core is intentionally minimal.

Real clusters usually include add-ons.

Add-on	Purpose
CoreDNS	Internal DNS
CNI plugin	Pod networking
Metrics Server	Resource metrics for HPA and `kubectl top`
Ingress Controller	Legacy/stable HTTP routing for Ingress
Gateway API Controller	Modern Gateway API routing
CSI driver	Storage integration
cert-manager	TLS certificates
ExternalDNS	DNS automation
Argo CD / Flux	GitOps deployment
Prometheus	Metrics collection
Grafana	Dashboards
Fluent Bit / Loki / Elasticsearch	Logging
OpenTelemetry Collector	Logs/metrics/traces pipeline
Kyverno / OPA Gatekeeper	Policy enforcement
External Secrets / Sealed Secrets	Secret management
Cilium / Calico	Networking and NetworkPolicy
Istio / Linkerd	Service mesh
KEDA	Event-driven autoscaling
Karpenter	Node provisioning, especially common on EKS

Diagram preview

19. High Availability Architecture

In production, you usually do not want a single control-plane node.

A highly available cluster has multiple control-plane nodes.

Diagram preview

Important HA ideas:

Multiple API servers can be active.
etcd should run in a quorum-based cluster.
Scheduler and controller-manager use leader election.
Only one scheduler/controller-manager leader acts at a time.
Worker nodes talk to the API server through a stable endpoint.
Managed Kubernetes usually hides most control-plane HA details.

Control-plane components can be deployed as:

systemd services
static Pods
self-hosted workloads
managed provider components

Tools like kubeadm commonly run control-plane components as static Pods managed by kubelet.

20. Managed Kubernetes Architecture

In managed Kubernetes:

AWS EKS
Azure AKS
Google GKE

The provider usually manages the control plane.

You still manage or configure:

worker nodes or node pools
workloads
namespaces
RBAC
Deployments
Services
Gateway/Ingress
storage classes
network policies
autoscaling
observability
security posture
IAM integration
add-ons

Diagram preview

EKS example:

AWS manages the Kubernetes control plane.
You manage node groups, Fargate profiles, IAM roles, security groups, VPC CNI, add-ons, workloads, and cluster operations.

21. Failure Scenarios

21.1 What happens when a container crashes?

Diagram preview

If just the container crashes:

kubelet restarts it on the same node, depending on restartPolicy.

21.2 What happens when a Pod is deleted?

ReplicaSet wanted 3 Pods.
One Pod deleted.
ReplicaSet controller creates replacement Pod.
Scheduler assigns replacement Pod.
Kubelet starts it.

21.3 What happens when a node fails?

Diagram preview

Node health uses heartbeats, including Node status updates and Lease objects.

21.4 What happens when the API server is unavailable?

Existing Pods usually continue running.

But you cannot reliably:

create new workloads
update objects
schedule new Pods
reconcile changes
run most kubectl operations

The data plane can continue for a while, but the cluster loses central coordination until the API server is restored.

21.5 What happens when etcd fails?

If etcd becomes unavailable:

API server cannot persist or read cluster state properly
new writes fail
control loops are disrupted
cluster management is severely impacted

If etcd data is permanently lost without backup:

The cluster has lost its source of truth.

This is why etcd backups are critical.

22. Complete Traffic Flow Example

Imagine this app:

User -> api.example.com -> backend API Pods -> PostgreSQL

Current Kubernetes path with Gateway API:

Diagram preview

Legacy/common Kubernetes path with Ingress:

Diagram preview

What each piece does:

Piece	Job
DNS	Resolves public domain
Load Balancer	Brings traffic to the cluster edge
Gateway Controller	Implements Gateway API resources
Ingress Controller	Implements Ingress resources
HTTPRoute / Ingress	Defines routing rules
Service	Stable internal endpoint
EndpointSlice	Tracks healthy backend Pods
Pod	Runs app container
StatefulSet	Runs database with stable identity
PVC/PV	Provides persistent storage
CNI	Handles network connectivity
kube-proxy/eBPF	Handles Service routing
CoreDNS	Handles internal DNS

23. Kubernetes Architecture as Layers

Another way to view Kubernetes:

Layer 7: Application
  Deployments, Pods, Services, Gateway/Ingress

Layer 6: Platform behavior
  Controllers, scheduler, autoscaling, rollouts

Layer 5: Kubernetes API
  kube-apiserver, admission, RBAC, API objects

Layer 4: State
  etcd

Layer 3: Node runtime
  kubelet, runtime, probes, logs

Layer 2: Networking
  CNI, kube-proxy/eBPF, Services, DNS, NetworkPolicy

Layer 1: Infrastructure
  VMs, bare metal, cloud instances, disks, load balancers

Diagram preview

24. CKA-Focused Summary

For CKA, be very comfortable with this chain:

kubectl
  -> kube-apiserver
  -> etcd stores desired state
  -> controller creates missing objects
  -> scheduler assigns Pods to nodes
  -> kubelet starts Pods
  -> container runtime runs containers
  -> CNI gives Pod networking
  -> kube-proxy/CNI handles Services
  -> CoreDNS resolves Service names
  -> CSI handles storage

The most exam-relevant components are:

kube-apiserver
etcd
kube-scheduler
kube-controller-manager
kubelet
kube-proxy
container runtime
CoreDNS
CNI
Pods
Deployments
ReplicaSets
Services
Ingress
Gateway API basics
ConfigMaps
Secrets
PV/PVC/StorageClass
RBAC
Namespaces
NetworkPolicy

Important exam/practical distinction:

Ingress is still relevant and exam-worthy.
Gateway API is the modern direction and important for real platform work.

25. Final Complete Architecture Diagram

Diagram preview

The cleanest way to remember Kubernetes:

Control plane decides.
Worker nodes run.
etcd remembers.
Controllers reconcile.
Scheduler places.
Kubelet executes.
Runtime starts containers.
CNI connects.
CSI mounts.
Services stabilize networking.
Gateway API is the modern routing direction.
Ingress still exists but is frozen.
RBAC protects the API.

26. Current-Version Checklist

Use this checklist to avoid outdated Kubernetes statements.

Correct statements

Kubernetes architecture is control plane + worker nodes.
Ingress is stable but frozen.
Gateway API is recommended for advanced/new service networking.
Gateway API is an add-on CRD-based API family, not a built-in cloud API Gateway product.
Ingress requires an Ingress Controller.
Gateway API requires a Gateway API controller.
kube-proxy is still common, but eBPF CNIs may replace or bypass parts of it.
CNI is required for Pod networking.
CSI is the standard storage integration model.
Docker images still work, but Kubernetes uses CRI runtimes such as containerd or CRI-O.
EndpointSlices are the scalable backend tracking mechanism for Services.
User namespaces are GA in v1.36 for Linux workloads.
Service .spec.externalIPs is deprecated in v1.36.
gitRepo volume is not a modern supported design.

Outdated or misleading statements

“Ingress has been removed.” Wrong.
“Ingress was replaced by API Gateway.” Too vague/wrong.
“Docker is the Kubernetes runtime.” Outdated.
“Services directly track Pods without EndpointSlices.” Incomplete.
“Base64 Secrets are encrypted.” Wrong.
“Namespaces are hard security boundaries.” Wrong.
“NetworkPolicy works automatically in every cluster.” Wrong; CNI must enforce it.
“Application traffic goes through kube-apiserver.” Usually wrong.

27. References

Verified against official Kubernetes sources and Kubernetes project pages available on 2026-07-04:

Important current-version correction

Is Ingress replaced by API Gateway now?

Current Kubernetes version notes

Table of Contents

1. What Kubernetes Is

2. Big Picture Architecture

2.1 Control plane

2.2 Worker nodes / data plane

2.3 Complete high-level cluster diagram

3. The Core Mental Model

4. Control Plane vs Data Plane

4.1 Control plane

4.2 Data plane

5. Control Plane Components

5.1 kube-apiserver

Request flow through the API server

Authentication vs authorization

5.2 etcd

5.3 kube-scheduler

5.4 kube-controller-manager

5.5 cloud-controller-manager

6. Worker Node / Data Plane Components

6.1 kubelet

6.2 Container runtime

6.3 kube-proxy

6.4 CNI plugin

6.5 CSI plugin

7. Core Kubernetes Objects

7.1 Pod

7.2 Deployment

7.3 ReplicaSet

7.4 StatefulSet

7.5 DaemonSet

7.6 Job and CronJob

7.7 Service

7.8 EndpointSlice

7.9 ConfigMap

7.10 Secret

7.11 Namespace

7.12 ServiceAccount

7.13 RBAC

7.14 PersistentVolume, PersistentVolumeClaim, StorageClass

PersistentVolume

PersistentVolumeClaim

StorageClass

8. Ingress, Gateway API, and API Gateway

8.1 Ingress

8.2 Gateway API

8.3 API Gateway products

8.4 Which one should you use?

9. Deployment Creation Lifecycle

10. Desired State and Reconciliation

11. Kubernetes Networking Architecture

11.1 Container-to-container networking

11.2 Pod-to-Pod networking

11.3 Pod-to-Service networking

11.4 Service discovery with CoreDNS

11.5 External traffic

11.6 NetworkPolicy

12. Storage Architecture

12.1 Common volume types

12.2 Persistent storage flow

13. Security Architecture

13.1 API request security path

13.2 Main security pieces

13.3 User namespaces in v1.36

14. Scheduling Architecture

14.1 Filtering

14.2 Scoring

15. Autoscaling Architecture

15.1 Horizontal Pod Autoscaler

15.2 Vertical Pod Autoscaler

15.3 Cluster Autoscaler

15.4 Karpenter

15.5 KEDA

16. Rolling Updates and Rollbacks

17. Health Checks and Probes

17.1 Liveness probe

17.2 Readiness probe

17.3 Startup probe