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

Kubernetes Architecture

From a macro perspective, Kubernetes consists of a Master control plane, worker Nodes, and etcd as the distributed key‑value store.

The Master includes the API Server, Scheduler, and Controller Manager, all of which interact with etcd to store and retrieve cluster state.

API Server : Unified entry point for resource operations, abstracting direct etcd access and providing security, registration, and discovery functions.

Scheduler : Assigns Pods to Nodes based on scheduling rules.

Controller Manager : Ensures resources reach their desired state.

Nodes provide the compute resources where containers actually run and contain two key components:

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

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

Creating a Deployment

The article walks through the complete flow when a user creates a Deployment with kubectl:

kubectl sends a create‑Deployment request.

API Server writes the Deployment object to etcd.

Deployment controller watches the resource and creates a ReplicaSet.

ReplicaSet controller watches the ReplicaSet and creates Pods.

Scheduler detects unscheduled Pods and binds them to suitable Nodes.

kubelet on the selected Node creates the Pods and manages their lifecycle.

kube‑proxy sets up Service‑related networking rules.

Through this coordinated effort, the requested Deployment is realized as running Pods.

Pod

A Pod is the smallest deployable unit in Kubernetes, designed for tightly coupled containers that share network namespace, storage volumes, and configuration, effectively acting as a single logical host.

Container Orchestration

Kubernetes offers various controllers for different workloads: Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for daemon processes, and Job/CronJob for batch jobs. Deployment manages ReplicaSets, which in turn manage Pods, enabling horizontal scaling and rolling updates.

Horizontal Scaling

Adjusting the replica count in a ReplicaSet directly changes the number of Pods, providing simple scale‑out or scale‑in capabilities.

Update / Rollback

During an update, a new ReplicaSet is created and gradually takes over the Pods from the old ReplicaSet; a rollback reverses this process.

Rolling Update

Kubernetes performs rolling updates by ensuring a minimum number of Pods remain available while new Pods are created, controlled by maxSurge and maxUnavailable settings.

Kubernetes Networking

Three basic connectivity requirements are satisfied: Node ↔ Pod, Pod ↔ Pod on the same Node, and Pod ↔ Pod across Nodes. This is achieved via CNI bridges (cni0/docker0). Cross‑Node communication can be implemented with solutions like Flannel, which uses etcd to distribute routing information.

Microservice – Service

Service provides a stable virtual IP and load‑balancing for a set of Pods selected by label selectors (e.g., app=xxx), solving the problems of dynamic Pod IPs and the need for load distribution.

Service Discovery and Network Calls

Inside the cluster, Service can be accessed via ClusterIP (a VIP implemented with iptables or IPVS) or via DNS name service-name.namespace-name.svc.cluster.local. External access is achieved through NodePort, LoadBalancer, or Ingress, with Ingress acting as a unified entry point that routes traffic to backend Services.

Overall, the article gives a concise yet thorough introduction to Kubernetes concepts, component interactions, and how microservices run on a Kubernetes cluster.