How Does Kubernetes Orchestrate Containers? A Deep Dive into Architecture and Workflows

Kubernetes Architecture

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

At a high level, the architecture consists of a Master, Nodes, and etcd.

The Master controls the entire cluster and includes the API Server, Scheduler, and Controller, 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 : Ensures resources reach their desired state.

Nodes provide the compute power where containers actually run, encompassing the container runtime, 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 by monitoring Service/Endpoints changes.

From Creating a Deployment

A Deployment orchestrates Pods; the following steps illustrate how Kubernetes components collaborate to create a Deployment.

kubectl sends a request to create a Deployment.

The API Server writes the resource 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 unscheduled Pods and binds them to suitable Nodes.

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

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

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

Pod

Pods are the smallest deployable units in Kubernetes, serving as the fundamental building block.

Pods embody a container design pattern for tightly coupled containers that need to share network, storage, and configuration, such as sidecar containers for logging.

Containers within a Pod share the same network namespace via an infra container and can share storage by mounting the same volume.

Container Orchestration

Kubernetes offers various orchestration controllers, including Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for daemon processes, and Job/CronJob for batch workloads.

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

Horizontal Scaling

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

Update/Rollback

Updates transition Pods from one version to another by gradually shifting replica counts between old and new ReplicaSets; rollbacks reverse this process.

Rolling Update

During a rolling update, Pods are upgraded one by one while maintaining at least two healthy Pods, ensuring continuous service and easy rollback if bugs appear.

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

Kubernetes Networking

Three basic connectivity requirements (“three‑way”) are:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

Inter‑Pod communication is facilitated by the cni0/docker0 bridge; Node‑to‑Pod traffic uses the same bridge.

Cross‑Node Pod communication can be implemented with solutions like Flannel (VXLAN/host‑gw), which reads network information from etcd and configures routing tables.

Microservice – Service

Service objects provide stable endpoints for Pods, handling dynamic Pod IPs and load balancing.

Services select 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‑way” network foundation, Kubernetes supports intra‑service calls via ClusterIP and DNS.

ClusterIP creates a virtual IP (VIP) using iptables/ipvs; accessing the VIP load‑balances traffic to backend Pods.

DNS resolves a Service’s A record (e.g., service-name.namespace-name.svc.cluster.local) to its 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 leverages cloud provider LB services; Ingress provides a unified entry point, routing external requests to internal Services, often built on top of NodePort and LoadBalancer.

In summary, this article introduces core Kubernetes concepts, its operational workflow, and how microservices run on the platform.

Link: https://fredal.xin/what-is-kubernetes

(© Original author, remove if infringing)