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

Kubernetes has become the king of container orchestration, offering cluster scaling, rolling upgrades, rollback, elastic scaling, self‑healing, and service discovery.

Kubernetes Architecture

The overall architecture consists of a Master, Nodes, and Etcd.

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

API Server: unified entry point for resource operations, hides direct Etcd interaction, provides security, registration, and discovery.

Scheduler: assigns Pods to Nodes based on scheduling rules.

Controller: resource control center that ensures resources reach the desired state.

Nodes provide the compute power where containers run, and they host the kubelet and kube‑proxy components.

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

kube‑proxy : implements service discovery and load balancing inside the cluster by watching Service/Endpoints changes and updating network rules.

Starting from Creating a Deployment

A Deployment is a controller resource used to orchestrate 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 receives the request and writes the resources to Etcd; subsequent 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 detects unbound Pods and selects an appropriate Node.

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

kube‑proxy initializes Service‑related resources, including service discovery and load‑balancing rules.

Through this coordinated workflow, a Deployment request results in fully running Pods.

Pod

A Pod is the smallest deployable unit in Kubernetes and the fundamental API resource.

Pods group containers that need to share network, storage, and configuration, acting as a design pattern for tightly coupled containers.

Containers in a Pod share the same network namespace via an infra container and can share volumes mounted from the host.

Container Orchestration

Kubernetes provides various controllers for orchestration: Deployment for stateless applications, StatefulSet for stateful workloads, DaemonSet for daemon processes, and Job/CronJob for batch jobs.

Deployment, ReplicaSet, and Pod form a layered control relationship: the ReplicaSet controls the number of Pods, while the Deployment controls the version of the ReplicaSet, enabling horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

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

Update / Rollback

When updating from version v1 to v2, the v1 ReplicaSet’s Pods are gradually reduced to zero while the v2 ReplicaSet’s Pods increase to the desired count; the reverse process performs a rollback.

Rolling Update

During a rolling update, Pods are upgraded one by one, maintaining at least two Pods available while up to four Pods may serve, ensuring service continuity and easy rollback if a bug appears.

The RollingUpdateStrategy can be configured with maxSurge (extra new Pods) and maxUnavailable (old Pods that may be removed).

Kubernetes Networking

Three basic connectivity requirements (“three passes”) are: Node ↔ Pod, Pod ↔ Pod on the same Node, and Pod ↔ Pod across different Nodes.

Inter‑Pod communication uses the cni0/docker0 bridge; Node‑to‑Pod also uses this bridge.

Cross‑Node Pod communication can be implemented with solutions like Flannel (VXLAN or host‑gateway mode), where Flannel learns node network information from Etcd and creates routing tables.

Microservice – Service

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

Service selects Pods via label selectors (e.g., app=xxx) to build an Endpoints list for load balancing.

Service Discovery and Network Calls in Kubernetes

With the “three passes” in place, service discovery and network calls work as follows.

Service‑to‑Service Calls (East‑West)

ClusterIP services expose a virtual IP (VIP) via kube‑proxy using iptables or IPVS; accessing the VIP load‑balances to backend Pods.

DNS mode provides an A record like service-name.namespace-name.svc.cluster.local that resolves to the ClusterIP, allowing callers to use the service name directly.

External Access (North‑South)

External traffic can reach the cluster via NodePort, LoadBalancer, or Ingress. NodePort maps a host port to the Service, LoadBalancer uses a cloud provider’s load balancer, and Ingress provides a unified entry point that routes to backend Services, often built on top of NodePort and LoadBalancer.

Author: fredalxin