Why Kubernetes Is the Backbone of Modern Cloud‑Native Architecture

1. Origin of Microservice Architecture

Monolithic architecture runs all business logic in a single process, typically a Tomcat container. Advantages include low technical threshold, simple development, easy debugging, quick deployment, and low cost, while disadvantages are code bloat, high coupling, and difficulty scaling to meet growing user demand.

Monolithic systems become bloated and tightly coupled, making sustainable development and operations hard.

Monoliths struggle to handle rapidly increasing request volumes.

Distributed architecture splits a single‑process system into multiple cooperating processes that can be deployed independently on different servers, enabling horizontal or vertical scaling.

Horizontal scaling: add more servers.

Vertical scaling: assign better machines to specific workloads.

Remote Procedure Call (RPC) is the first solution for inter‑process communication in distributed systems.

Common microservice frameworks include Dubbo and Spring Cloud; container orchestration platforms such as Kubernetes and Docker Swarm are now the dominant deployment solutions.

Microservices bring complexity; developers must handle RPC latency, failures, and related issues.

2. Early Kubernetes (K8s)

Kubernetes, named after the Greek word for “helmsman”, originated from Google’s Borg and provides a container‑centric cluster management system.

It offers robust cluster management features: multi‑layer security, multi‑tenant support, service discovery, built‑in load balancing, self‑healing, rolling updates, auto‑scaling, resource quotas, and more.

2.1 Kubernetes Architecture and Components

Core components include etcd, apiserver, controller‑manager, scheduler, kubelet, container runtime, and kube‑proxy.

2.2 Design Principles

API Design Principles

Kubernetes objects consist of metadata, spec, and status. Declarative YAML defines the desired state; the control loop drives the actual state toward it.

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Key fields: apiVersion, kind, metadata (name, namespace, labels), spec (desired configuration), status (current state).

Control Mechanism Principles

Modules should be able to degrade gracefully.

Control logic must depend only on the current state.

Avoid complex state machines; do not rely on unobservable internal state.

Assume any operation may be rejected or mis‑interpreted.

Modules should self‑recover after errors.

3. Resource Management

3.1 Compute Resources

Nodes provide CPU, memory, disk, and network. Namespaces partition the cluster logically for multi‑tenant resource isolation.

Pods are the smallest deployable units, each running one or more containers with a unique IP.

Containers share the same network namespace; the “one‑container‑per‑Pod” pattern is the most common.

Three Levels of Compute Resource Management

Container level: ResourceRequests and ResourceLimits.

apiVersion: v1
kind: Pod
metadata:
  name: memory-demo-3
spec:
  containers:
  - name: memory-demo-3-ctr
    image: vish/stress
    resources:
      limits:
        memory: "1000Gi"
      requests:
        memory: "1000Gi"
    args:
    - --mem-total
    - 150Mi
    - --mem-alloc-size
    - 10Mi
    - --mem-alloc-sleep
    - 1s

Pod level: LimitRange objects set default/min/max resources for all containers in a pod.

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - type: Pod
    max:
      cpu: "4"
      memory: 2Gi
    min:
      cpu: 200m
      memory: 6Mi
    default:
      cpu: 300m
      memory: 200Mi
    defaultRequest:
      cpu: 200m
      memory: 100Mi

Namespace level: ResourceQuota objects limit total resource consumption across a namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    request.cpu: "4"
    request.memory: 8GB
    limit.memory: 16GB
    pods: "2"

3.2 Network Resources

Kubernetes defines node IP (physical), pod IP (virtual), and cluster/service IP (virtual). Overlay networks via CNI plugins (Flannel, Calico, macvlan, Open vSwitch, direct routing) provide cross‑host container networking.

Ingress

Ingress exposes services outside the cluster and performs L7 routing.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: mywebsite-ingress
spec:
  rules:
  - host: mywebsite.com
    http:
      paths:
      - path: /demo
        backend:
          serviceName: webapp
          servicePort: 8080

Common Ingress controllers: Nginx, HAProxy, Traefik, apisix.

3.3 Storage Resources

Kubernetes supports various Volume types: emptyDir, ConfigMap, Secret, DownwardAPI, gitRepo, hostPath, local, PersistentVolume (PV), PersistentVolumeClaim (PVC).

PV provides a shared storage resource; PVC is a request for a PV. StorageClass automates dynamic provisioning.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
mountOptions:
- debug

CSI (Container Storage Interface)

CSI decouples storage vendors from Kubernetes, defining Identity, Node, and Controller services for volume lifecycle operations such as CreateVolume, DeleteVolume, NodePublishVolume, etc.

3.4 Multi‑Cluster Management (Federation)

Federation adds a control plane that unifies multiple Kubernetes clusters, providing a single API, shared DNS, ConfigMaps, and a central etcd database for coordinated management.

Overall, the article serves as a concise reference for beginners to understand Kubernetes core concepts, resource objects, and the ecosystem surrounding cloud‑native deployments.