Unlock Kubernetes: Architecture, Deployments, Pods, and Service Networking

Kubernetes has become the dominant container orchestration engine, offering cluster scaling, rolling upgrades, auto‑healing, service discovery and more.

This article quickly introduces what Kubernetes is and the concepts commonly discussed.

Kubernetes Architecture

From a macro perspective, Kubernetes consists of a Master, Nodes, and etcd.

The Master (control plane) manages the whole cluster and includes the API Server, Scheduler, and Controller Manager, all of which interact with etcd for state storage.

API Server : Provides a unified entry point for resource operations, shielding 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, kubelet, and kube‑proxy.

kubelet : Manages container lifecycles, monitors health via cAdvisor, and reports node status.

kube‑proxy : Implements service discovery and load balancing, watching Service/Endpoint changes.

From Creating a Deployment

A Deployment orchestrates Pods. The creation flow is:

kubectl sends a Deployment creation request.

API Server stores the object in etcd.

Deployment controller watches the resource and creates a ReplicaSet.

ReplicaSet controller creates Pods.

Scheduler binds each new Pod to a suitable Node.

kubelet on the selected Node creates and manages the Pod.

kube‑proxy sets up Service networking for the Pods.

Pod

Pods are the smallest deployable units in Kubernetes, representing a group of tightly coupled containers that share network, storage, and configuration.

Container Orchestration

Kubernetes provides various controllers for different workloads: Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for node‑level agents, and Job/CronJob for batch processing.

Horizontal Scaling

Scaling is achieved by adjusting the replica count in a ReplicaSet, e.g., changing from 2 to 3 replicas expands the workload horizontally.

Update / Rollback

Updates create a new ReplicaSet with the desired version while gradually shifting replicas from the old to the new set; rollback reverses this process.

Rolling Update

During a rolling update, Pods are upgraded one by one, ensuring at least two Pods remain available while up to four may serve traffic, allowing quick rollback if a bug appears.

Kubernetes Networking

Three basic connectivity guarantees are required:

Node ↔ Pod communication.

Pod ↔ Pod on the same Node.

Pod ↔ Pod across different Nodes.

Microservice – Service

Service abstracts a set of Pods, providing a stable endpoint and load‑balancing. It selects Pods via label selectors, creating an Endpoints list for traffic routing.

Service Discovery and Network Calls

With the three‑way connectivity in place, Kubernetes implements service discovery using ClusterIP (virtual IP) and DNS. ClusterIP creates a VIP via kube‑proxy (iptables/ipvs) that load‑balances to backend Pods. DNS resolves service-name.namespace.svc.cluster.local to the ClusterIP.

External Access

North‑south traffic (outside to inside) can be exposed via NodePort, LoadBalancer, or Ingress. NodePort maps a host port to a Service, LoadBalancer provisions a cloud provider’s LB, and Ingress offers a unified entry point with routing rules, often built on top of NodePort or LoadBalancer.

By now you should have a basic understanding of Kubernetes concepts, how the control plane components cooperate, and how micro‑services run on a Kubernetes cluster.