Understanding Kubernetes Architecture: Components, Deployment Workflow, Pods, Services, and Networking

Kubernetes has become the dominant container‑orchestration platform, offering features such as cluster scaling, rolling upgrades, self‑healing, and service discovery.

Kubernetes Architecture

At a high level, Kubernetes consists of a Master, Nodes, and Etcd.

The Master (control plane) includes the API Server, Scheduler, and Controller Manager, all of which interact with Etcd for persistent state.

API Server : Provides a unified entry point for resource operations, abstracting direct Etcd access and handling security, registration, and discovery.

Scheduler : Assigns Pods to Nodes based on scheduling rules.

Controller Manager : Ensures resources reach their desired state.

Nodes are the worker machines that run containers and host the kubelet and kube-proxy components.

kubelet : Manages the lifecycle of containers on the node, performs health checks, and reports node status.

kube-proxy : Implements service discovery and load‑balancing by monitoring Service/Endpoint changes.

From Creating a Deployment

A Deployment is a controller that orchestrates Pods. The creation flow involves several components:

kubectl sends a request to create a Deployment.

API Server stores the request in Etcd.

Deployment controller watches the resource and creates a ReplicaSet.

ReplicaSet controller watches the ReplicaSet and creates Pods.

Scheduler binds each unassigned Pod to a suitable Node.

kubelet on the selected Node creates the Pod and manages its lifecycle.

kube-proxy sets up Service‑related networking rules.

Through this coordinated effort, the Deployment request results in running Pods.

Pod

A Pod is the smallest deployable unit in Kubernetes, representing one or more tightly coupled containers that share network, storage, and configuration.

Containers within a Pod share an infra container for network identity and can mount the same volume to share data.

Container Orchestration

Kubernetes provides various controllers for different workloads: Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for daemon processes, and Job/CronJob for batch tasks.

Deployments manage ReplicaSets, which in turn control the number of Pods. This design enables horizontal scaling, versioned updates, and rollbacks.

Horizontal Scaling

Adjust the replica count in a ReplicaSet to scale out or in (e.g., from 2 to 3 replicas).

Update / Rollback

When updating from version v1 to v2, the old ReplicaSet’s Pods are gradually reduced while the new ReplicaSet’s Pods are increased, allowing seamless updates and easy rollbacks.

Rolling Update

Kubernetes updates Pods one by one, keeping a minimum number of Pods available (e.g., at least 2 out of 4) to ensure service continuity and quick rollback if needed.

The RollingUpdateStrategy can be tuned with maxSurge (extra Pods created) and maxUnavailable (Pods that may be taken down).

Kubernetes Networking

Three basic connectivity requirements are:

Node ↔ Pod communication.

Pod ↔ Pod on the same Node.

Pod ↔ Pod across different Nodes.

Intra‑node communication uses the CNI bridge (cni0/docker0). Cross‑node communication is often implemented with solutions like Flannel (VXLAN or host‑gateway mode) that exchange routing information via Etcd.

Microservice – Service

A Service provides a stable endpoint for a set of Pods, handling dynamic Pod IPs and load‑balancing.

Pods are selected using label selectors, e.g., all Pods with app=xxx are grouped under a Service that also uses the same selector:

app=xxx

Service Discovery and Network Calls

With the three‑way connectivity in place, Kubernetes supports two main internal call methods:

ClusterIP : Service type that creates a virtual IP (VIP) via iptables/ipvs; traffic to the VIP is load‑balanced across the backing Pods.

DNS : Each Service gets an A record like service-name.namespace-name.svc.cluster.local, allowing Pods to reach the Service by name.

External Access (North‑South Traffic)

External clients can reach the cluster through:

NodePort : Exposes a Service on a static port on each Node.

LoadBalancer : Uses a cloud provider’s load balancer.

Ingress : A unified entry point that routes traffic to different Services based on host/path rules, typically built on top of NodePort or LoadBalancer.

In summary, the article walks through the core concepts of Kubernetes, how its components collaborate to run Deployments, the role of Pods and Services, and the networking mechanisms that enable both internal microservice communication and external access.