How Cloud Native Is Redefining Cloud Computing: Inside Kubernetes Architecture

1. Kubernetes Evolution

Kubernetes has progressed through five major phases: incubation, rapid growth, wild growth, popularization, and business reconstruction. This evolution reflects its role as the foundational layer for cloud‑native workloads such as AI, big data, edge computing, and 5G.

2. Core Architecture

etcd – stores the entire cluster state.

kube‑apiserver – the single entry point for all resource operations; provides authentication, authorization, admission control, API registration and discovery.

controller‑manager – maintains desired state (fault detection, auto‑scaling, rolling updates, etc.).

scheduler – assigns Pods to Nodes based on scheduling policies.

kubelet – runs on each Node, manages container lifecycles, mounts volumes (CSI), configures networking (CNI) and device plugins (GPU, FPGA, NIC).

container runtime – implements the Container Runtime Interface (CRI) to pull images and start containers.

kube‑proxy – provides internal Service discovery and load‑balancing.

2.1 Container Runtime Fragmentation

Kubernetes supports multiple runtimes, each with a distinct execution chain:

docker:    dockershim → dockerd → containerd → runc

containerd: containerd → shim v2 → runc

cri‑o:     cri‑o → runc

frakti:    frakti → runv

pouch:     pouchContainer → containerd → runc

Guidelines:

For performance‑critical workloads, cri‑o + runc is recommended.

For high‑security isolation, frakti + runv is preferable.

2.2 Container Network Models

Kubernetes networking can be classified into three architectural models:

Overlay – builds an independent virtual network (e.g., VXLAN) on top of the underlying L2/L3 fabric. Flexible but incurs ~20‑30% performance overhead.

Routing – uses L3 routing (BGP, IPIP, etc.) to connect Pods. Easier to integrate with existing data‑center fabrics and offers fine‑grained control.

Underlay – exposes the host NIC directly to containers (MAC‑VLAN, IP‑VLAN). Highest performance when a robust IaaS layer exists.

Widely adopted CNI plugins:

Flannel – simple overlay with UDP, VXLAN, or HOST‑GW modes.

Calico – BGP‑based full‑mesh, router‑reflection, and IPIP modes; provides network policy.

Cilium – eBPF‑based, supports L3/L4/L7 security policies and high‑performance load balancing.

OVN – combines underlay and overlay capabilities for flexible deployments.

2.3 Storage Options and CSI

Four broad categories of storage for containers:

Distributed block storage (Ceph, Sheepdog, EMC ScaleIO, VMware vSAN) – generally unsuitable because they lack RWX support.

Distributed file storage (CephFS, GlusterFS, Lustre, MooseFS, LizardFS, EMC Isilon, IBM GPFS) – compatible but may suffer performance penalties.

Local‑disk – simple but risky for stateful workloads due to long recovery after node failure.

Traditional NAS – introduces gateway bottlenecks; increasingly deprecated.

Kubernetes introduced the Container Storage Interface (CSI) in v1.9 (GA in v1.13) to standardize integration with external storage systems. The PVC‑PV lifecycle proceeds as:

User creates a PersistentVolumeClaim (PVC).

Kubernetes provisions a matching PersistentVolume (PV) and binds it to the PVC.

A Pod referencing the PVC is scheduled to a Node.

The Node’s kubelet attaches the volume to the Node.

The kubelet mounts the volume, making it available inside the container.

Selection criteria should balance business requirements, platform consistency, and team expertise. Open‑source solutions demand higher operational skill; commercial offerings provide vetted stability.

2.4 Application Management Fragmentation

Kubernetes resources exceed a hundred types and can be grouped into four logical layers:

Resource layer – core objects such as Pods, Services, ConfigMaps.

Scheduling layer – controllers, schedulers, and custom schedulers (often extended via CRDs).

Isolation & Service Access layer – NetworkPolicies, RBAC, ServiceAccounts.

Application layer – Deployments, StatefulSets, DaemonSets, and higher‑level abstractions.

Key extensibility mechanisms:

Custom Resource Definitions (CRDs) – introduced in v1.7; allow users to define new API objects scoped to a namespace or cluster.

Operators – implement the Reconciler pattern to manage the full lifecycle of stateful applications (e.g., databases, message queues).

Helm – package manager that bundles Kubernetes manifests into versioned charts, simplifying deployment and upgrades.

Open Application Model (OAM) – a vendor‑agnostic specification that separates application components, configurations, and traits.

KubeVela – an open‑source engine built on OAM, providing a declarative, platform‑agnostic way to compose PaaS, AI‑PaaS, or CI/CD platforms on top of Kubernetes.

When choosing an application‑management approach, consider:

Complexity of the workload (stateless vs. stateful).

Team’s familiarity with Helm charts versus Operator development.

Need for cross‑cluster or multi‑cloud portability (favor OAM/KubeVela).

3. Summary

Kubernetes remains the core of the cloud‑native stack, offering extensibility at both infrastructure and application layers. Practitioners should select container runtimes, networking plugins, storage back‑ends, and management tools based on performance, security, and operational expertise, balancing open‑source flexibility with commercial reliability to achieve sustainable business value.