Skip to main content
In this lesson we’ll place Kubernetes within modern application architecture and walk through its core components, how they interact, and common operational patterns. This overview is useful for architects, platform engineers, and developers who deploy cloud-native workloads. Evolution: Monolith → Microservices → Containers → Orchestration
  • Monoliths: historically, applications were packaged and deployed as a single unit. For example, an Uber-like app might combine passenger management, payments, and driver logic in one codebase and one deployable artifact.
    • Benefits: simple development workflow, one artifact to test and deploy, straightforward integration testing.
    • Challenges: poor scalability (you must scale the entire app even when only one part needs more capacity), large codebase complexity, and frequent full redeploys for small changes.
  • Microservices: break the monolith into independently developed and deployed services.
    • Benefits: independent scaling and release cadence, smaller service codebases.
    • Challenges: service discovery, distributed configuration and logging, networked failure modes, and load balancing across many replicas.
  • Containers (OCI images): container runtimes (Docker, Buildah, etc.) make packaging reproducible and lightweight. Containers include the application and dependencies (no guest OS) and start quickly, improving developer velocity and deployment consistency.
  • Container orchestration: systems like Kubernetes operate containers at scale and add features such as autoscaling, self-healing, rolling updates, and pluggable networking and storage. Building images remains the job of CI/CD pipelines or build tools; Kubernetes does runtime orchestration.
Platform variants (PaaS, managed platforms)
  • Managed or opinionated platforms (OpenShift, cloud-provider managed Kubernetes) combine orchestration with extra features: web consoles, integrated registries, CI tooling, and policy integrations.
  • OpenShift moved from Docker to CRI-O as the default runtime and promotes Podman for local image workflows.
  • Additional layers (API gateways, service meshes, policy engines) are often added on top of a platform for governance and security.
Service mesh
  • Service meshes (Istio, Linkerd, etc.) provide advanced traffic control, mTLS, tracing, circuit breaking, and telemetry.
  • Meshes add visibility and policy capabilities but also increase configuration and runtime complexity.
  • Observability tooling complements meshes: Prometheus (metrics) and Grafana (visualization) are common pairings.
Kubernetes architecture overview
  • Pod: the smallest deployable unit; one or more containers that share networking and volumes.
  • Nodes: worker machines (VMs or physical servers) that run Pods. Use multiple worker nodes for high availability.
  • Control plane (master nodes): manage cluster state and scheduling; you can run multiple control plane nodes for HA.
Key components and how they interact
The kube-apiserver is the canonical gateway to cluster state. All controllers and clients interact with the cluster through the API server; etcd is never accessed directly by cluster users.
Do not access etcd directly for routine operations. Direct etcd manipulation risks data corruption. Use the API server and controller patterns for normal management. Note that the historical dockershim removal (Kubernetes v1.24) means you must use a CRI-compatible runtime such as containerd or CRI-O.
Container runtimes and sandboxing
  • The kubelet communicates with the container runtime via the Container Runtime Interface (CRI).
  • Runtimes like containerd support multiple low-level runtimes (runc, runsc). gVisor (runsc) provides user-space syscall handling to increase isolation.
  • Use RuntimeClass to select a specific runtime for Pods (e.g., to sandbox with gVisor). Alternatively, apply seccomp or AppArmor profiles for syscall restrictions.
Simplified image lifecycle
  1. Build an OCI-compliant image (Docker, Buildah, Kaniko) and push to a registry (Docker Hub, GCR, ECR, private registry).
  2. Create Pod/Deployment manifests referencing the image.
  3. The kubelet on the target node instructs the container runtime to pull and run the image.
  4. The runtime pulls, unpacks, and launches containers using the configured low-level runtime.
Pod networking and exposing workloads
  • Each Pod gets an IP assigned by the CNI plugin. Cross-node Pod communication relies on routing and node-level rules configured by the CNI.
  • Services and Ingress provide stable access patterns.
Service types Ingress provides HTTP(S) routing with host/path rules and TLS termination. Ingress controllers implement the ingress rules and map traffic to Services. API server request lifecycle (authentication → authorization → admission) When a request arrives at the API server it undergoes:
  1. Authentication — verify caller identity (certs, tokens, external identity providers).
  2. Authorization — check permissions (RBAC, ABAC, webhook-based policies).
  3. Admission control — mutating and validating webhooks and built-in admission controllers:
    • MutatingAdmissionWebhook: can modify objects (e.g., sidecar injection).
    • ValidatingAdmissionWebhook: enforces policies before persistence.
    • Third-party policy engines (OPA/Gatekeeper, Kyverno) provide advanced policy enforcement. Only after passing these stages is the object persisted to etcd and controllers notified to reconcile.
Protocols and performance
  • The API server communicates with etcd using etcd’s protocol (etcd v3 over gRPC).
  • Controllers, kubelet, and clients usually use REST/HTTP; client libraries can use protobuf over HTTP/2 for more efficient payloads where supported.
DevSecOps pipeline for Kubernetes A common CI/CD / DevSecOps flow:
  1. Build and test code (unit tests, static analysis, security scans).
  2. Build container image and push to a registry.
  3. Scan images for vulnerabilities (Trivy, Clair) and validate manifests (kubesec, kube-score).
  4. Enforce policies via admission webhooks or policy engines (allowed registries, required labels, forbidden privileges).
  5. Deploy to Kubernetes (Deployments, StatefulSets). Consider canary/blue-green strategies and service-mesh traffic shaping.
  6. Monitor runtime behavior with metrics (Prometheus), visualizations (Grafana), tracing, logs, and runtime security tools (Falco).
A detailed Kubernetes architecture diagram showing a master node (API server, etcd, scheduler, controller) connected to multiple worker nodes hosting pods, kubelet, CNI/CSI/CRI components, and external persistent storage. It also includes the service/ingress layer, container runtimes (Docker/containerd/runc), CI/CD/DevSecOps pipeline, and various network/storage legends.
Summary Kubernetes is a pluggable, extensible orchestrator that runs containers at scale. It relies on standards (OCI images, CRI, CNI, CSI), a declarative API model, and a small set of core primitives (Pods, Services, Deployments, etc.). Operating Kubernetes securely and reliably requires layered tooling: runtime sandboxes (gVisor), policy enforcement (RBAC, admission webhooks, OPA/Kyverno), CI/CD pipelines with image scanning, and robust observability (Prometheus, Grafana). Links and references

Watch Video