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

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

This article quickly introduces Kubernetes and explains the concepts commonly discussed.

Kubernetes Architecture

From a high level, Kubernetes consists of a Master, Nodes, and etcd.

The Master controls the entire cluster and includes the API Server, Scheduler, and Controller components, all of which interact with etcd for data storage.

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

Scheduler: Assigns Pods to Nodes based on scheduling rules.

Controller: Acts as the resource control center to ensure resources reach the desired state.

Nodes provide the compute power for the cluster, running containers, kubelet, and kube-proxy.

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, watching Service/Endpoint changes.

From Creating a Deployment

A Deployment orchestrates Pods; the following steps illustrate how Kubernetes components cooperate when a Deployment is created:

kubectl sends a request to create a Deployment.

The API Server writes the resource to etcd; subsequent component interactions follow the same pattern.

The Deployment controller watches for changes and creates a ReplicaSet.

The ReplicaSet controller watches for changes and creates Pods.

The Scheduler binds unassigned Pods to suitable Nodes.

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

kube-proxy sets up Service‑related resources, including service discovery and load‑balancing rules.

Through coordinated actions of these components, the Deployment request results in running Pods.

Pod

Pods are the smallest deployable units in Kubernetes, designed for tightly coupled containers that need to share network, storage, and configuration.

Containers within a Pod share the same network namespace via an infra container and can mount a common volume, which maps to a directory on the host.

Container Orchestration

Kubernetes offers various orchestration resources such as Deployment (stateless apps), StatefulSet (stateful apps), DaemonSet (daemon processes), and Job/CronJob (batch workloads).

Using Deployment as an example, the relationship is: Deployment controls ReplicaSet versions, and ReplicaSet controls the number of Pods, enabling horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

Adjusting the replica count in a ReplicaSet scales the number of Pods up or down.

Update/Rollback

When updating from version v1 to v2, the v1 ReplicaSet’s Pod count decreases while the v2 ReplicaSet’s count increases, achieving a seamless update; 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 new version has bugs. The RollingUpdateStrategy can be tuned with maxSurge and maxUnavailable.

Kubernetes Networking

Three basic connectivity requirements are:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

Pods on the same Node communicate via the cni0/docker0 bridge; inter‑Node Pod traffic is typically handled by solutions like Flannel, which uses etcd to discover node network info and creates routing tables for cross‑host communication.

Microservice – Service

Service abstracts a set of Pods (a microservice) and solves two problems: Pods have dynamic IPs, and load balancing across Pods is needed.

Service selects Pods via label selectors to build an Endpoints list, enabling load‑balanced access.

Service Discovery and Network Calls in Kubernetes

With the three‑way connectivity in place, service communication works as follows.

Service‑to‑Service Calls

ClusterIP services expose a virtual IP (VIP) via kube‑proxy using iptables or IPVS, providing load‑balanced access to backend Pods. DNS creates an A record like service-name.namespace.svc.cluster.local pointing to the ClusterIP, allowing callers to use the service name directly.

External Access

North‑south traffic (external to the cluster) can be exposed via NodePort, LoadBalancer, or Ingress. NodePort maps a host port to a Service, LoadBalancer provisions a cloud load balancer, and Ingress provides a unified entry point that routes traffic to multiple Services, often built on top of NodePort or LoadBalancer.

In summary, we have covered the essential concepts of Kubernetes architecture, the lifecycle of Deployments and Pods, and how services enable discovery and networking for microservices within a cloud‑native environment.