Why Kubernetes Is the Core of Cloud‑Native Architecture: A Deep Dive

Introduction

Kubernetes is an open‑source container orchestration platform that represents a revolutionary breakthrough in cloud computing. It combines Google’s Borg controller with the flexible Omega scheduler, packaging applications into infrastructure‑agnostic container images and automatically managing resource allocation.

1. Overall Architecture

Kubernetes follows a classic master‑worker (master‑node / worker‑node) distributed architecture.

Master (Control Plane) Components

API Server : Acts as the cluster gateway, handling authentication, authorization, and serving as the proxy for all resource operations.

Scheduler : Assigns pods to suitable nodes; supports the default scheduler and custom schedulers.

etcd : Distributed key‑value store that holds the entire cluster state, similar to Zookeeper.

Controller Manager : Runs built‑in controllers (replication, node, namespace, service, endpoint, persistent volume, daemonset, etc.) to achieve self‑healing, scaling, lifecycle management, and service discovery.

Worker (Node) Components

Kubelet : Communicates with the API server, starts/stops pods, and manages networking, storage, and container runtimes.

Kube‑Proxy : Implements Service networking via iptables/ipvs, providing load‑balancing and service discovery.

Container Runtime : Executes containers; supports Docker, cri‑o, cri‑containerd, rkt, frakti, kata‑containers, etc., and follows the CRI, CNI, and CSI standards for extensibility.

Auxiliary Tools

kubectl : Command‑line client that interacts with the API server for cluster management.

Dashboard : Web UI for monitoring and managing cluster resources.

CoreDNS : Provides DNS‑based service discovery within the cluster.

2. Core Concepts

Pods – The Smallest Scheduling Unit

A pod is the minimal unit of deployment and resource allocation. Pods are isolated via Linux namespaces and cgroups. They consist of three container types:

Pause (Infra) Container : Starts first, holds the shared network namespace, and provides a stable IP for the pod.

Init Container : Runs sequentially before the app container to perform setup tasks such as scripts, file copying, or logging configuration.

App Container : Runs the actual workload; multiple app containers can coexist in a pod when tightly coupled.

Resource Isolation

Namespaces (ipc, uts, net, mnt, pid) provide process isolation, while cgroups enforce CPU, memory, and I/O limits.

CRI, CNI, CSI

The Container Runtime Interface (CRI) decouples the kubelet from the runtime, exposing RuntimeService and ImageService. The Container Network Interface (CNI) standardizes network plugins, and the Container Storage Interface (CSI) abstracts storage provisioning, enabling plug‑in storage solutions.

3. Storage Model

Kubernetes supports a rich set of volume plugins to satisfy three primary use cases: configuration data, secret management, and persistent data sharing.

ConfigMap : Stores non‑sensitive configuration files (≤1 MiB).

Secret : Stores sensitive data such as passwords, tokens, or certificates (≤1 MiB).

HostPath : Maps a node’s local filesystem into a pod; data persists beyond pod deletion if configured.

EmptyDir : Lifecycle tied to the pod; data is cleared when the pod is removed.

Advanced storage uses PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass, with in‑tree plugins, FlexVolume, and CSI drivers (e.g., Alibaba Cloud Disk, NAS, CPFS, OSS, LVM).

4. Networking Model

Kubernetes networking is abstracted into four layers:

Layer 0 – Node Network : Basic IP connectivity between cluster nodes.

Layer 1 – Pod Network : All pods share a flat network space; CNI plugins provide IP allocation and connectivity.

Layer 2 – Service Network : Exposes stable virtual IPs and load‑balances traffic to backend pods via kube‑proxy and iptables.

Layer 3 – Ingress/External Access : Exposes services outside the cluster using NodePort, LoadBalancer, or Ingress resources.

CNI plugins (Flannel, Calico, Cilium, OVN, etc.) implement the networking layer.

5. Workloads

Kubernetes manages application deployment through various workload resources:

Deployment & ReplicaSet : Declaratively manage stateless applications; Deployment controls ReplicaSet which in turn manages pods.

StatefulSet : Provides stable network IDs and persistent storage for stateful applications.

DaemonSet : Ensures a copy of a pod runs on every node (e.g., monitoring agents).

Job & CronJob : Run batch or scheduled tasks; Job executes to completion, CronJob triggers Jobs on a schedule.

Additional workload types include DevicePlugin for hardware resources and custom CRDs.

6. Controllers

The Controller Manager runs a suite of controllers that continuously reconcile the desired state with the actual state of the cluster:

Replication Controller : Keeps a specified number of pod replicas.

ResourceQuota Controller : Enforces namespace‑level resource limits.

Namespace Controller : Handles graceful deletion of namespaces and associated resources.

Endpoint Controller : Maintains Service endpoint objects based on pod membership.

Deployment Controller : Orchestrates rolling updates and rollbacks for Deployments.

Since v1.6, the Cloud Controller Manager (CCM) integrates cloud‑provider specific services (e.g., Alibaba Cloud).

7. Summary

Kubernetes is more than a container scheduler; it is a cloud‑native operating system that abstracts infrastructure differences, standardizes application deployment via container images, and offers extensible APIs (CNI, CSI, CRI) for networking, storage, and runtime integration. Its modular design—master‑worker architecture, rich set of controllers, and diverse workload resources—makes it the foundation for modern cloud‑native ecosystems.