Kubernetes Architecture Analysis: Design Patterns, Principles and Implementation

This article provides an in-depth analysis of Kubernetes (K8s) architecture from a software architecture perspective, explaining why K8s succeeded over Swarm and Mesos through its declarative API and highly extensible ecosystem.

K8s Core Concepts: K8s addresses four key operations areas: environment initialization (OS installation, runtime setup, storage mounting, network partitioning), configuration management (replica count, reliability, metrics), service operation (runtime selection and service startup), and monitoring with scaling/upgrade capabilities. It solves these through immutable infrastructure (using container images for standardization) and declarative API (for operations standardization).

Control Plane Components: The control plane includes API Server, Controller Manager, Scheduler, Kubelet, and Proxy. Key processes include: 1) Resource Process - centered on API Server with List-Watch mechanism for triggering, transforming, scheduling and starting resources; 2) Node Process - Kubelet's SyncLoop handles pod events through PLEG, podManager, and PodWorker; 3) Resource Scheduling - Scheduler Framework with Filter, Score, and Bind stages.

Architecture Styles Identified:

Microkernel Architecture - Uses Watch mechanism for extensions with minimal interface definitions

Event-Driven (Brokers) - List-Watch and Informer mechanisms implement edge-triggered, level-driven event handling

Control Loop - Controller Manager controls Pod state through continuous reconciliation

Blackboard - API Server and Etcd serve as central knowledge sources

Pipeline Filter - Scheduler Framework represents this pattern

Microservices - Event-driven decomposition rather than DDD

CQRS - Informer and Queue mechanism separate read/write operations

Interpreter Design Pattern - Parses operations into atomic actions

Architecture Decisions: 1) Event Processing: Edge-triggered, level-driven with re-sync; 2) Transaction Model: Optimistic concurrency using resource version in ObjectMeta; 3) Data Operations: Only API Server can directly manipulate data.

Pros and Cons: Advantages include excellent fault isolation through indirect service relationships (preventing thundering herd/cascade failures). Limitations include incomplete object description for architecture-as-code, imperfect call chain management, and added complexity from YAML Schema.