← Back

Kubernetes Architecture — Internal Components & Secure Cloud Infrastructure

Rather than reading through dense abstract definitions, let's understand Kubernetes (K8s) through clear architectural diagrams:

  1. How the orchestrator works internally (anatomy of the Control Plane and Worker Node components).
  2. How to run a production Kubernetes cluster within a secure private cloud network, exposed safely to the web through WAF/DDoS filtering, and connected to an isolated, encrypted managed database.

⚙️ 1. Internal Anatomy: Kubernetes Components

A Kubernetes cluster is divided into two fundamental planes:

📐 Component Flow Diagram

Kubernetes Internal Components: Control Plane & Worker Nodes 🧠 Control Plane (Cluster Brain) kube-apiserver • Sole REST entry point • AuthN, AuthZ (RBAC), Admission • Orchestrates all components ▶ Core hub of all communication etcd (Key-Value Store) • Complete cluster state • Distributed Raft consensus • Encrypted at-rest (Secrets) ONLY accessible by API Server mTLS / gRPC kube-controller-manager • Continuous reconciliation loop • Node, Deployment, ReplicaSet, Endpoints kube-scheduler • Evaluates CPU / RAM / Affinity • Assigns Pods to optimal Workers 👤 kubectl / Helm (HTTPS) 💻 Worker Node 1 kubelet (Node Agent) • Receives API Pod specs • Drives Container Runtime • Liveness & Readiness checks kube-proxy / CNI • iptables / IPVS / eBPF • Service traffic routing • Pod load balancing Container Runtime • containerd / CRI-O • Pulls verified images • cgroups & namespaces Pod: Order (Rep 1) order-api:v1.4 IP: 10.244.1.14 CPU 500m / 512Mi Secret injected Port: 8080 Readiness OK ✅ Pod: Catalog (Rep 1) catalog-api:v2.1 IP: 10.244.1.18 CPU 250m / 256Mi Local Redis cache Port: 8081 Readiness OK ✅ Pod: Cart (Rep 1) cart-service:v2.0 IP: 10.244.1.15 CPU 250m / 256Mi Session Cart Port: 8082 Readiness OK ✅ 💻 Worker Node 2 kubelet (Node Agent) • Receives API Pod specs • Drives Container Runtime • Liveness & Readiness checks kube-proxy / CNI • iptables / IPVS / eBPF • Service traffic routing • Pod load balancing Container Runtime • containerd / CRI-O • Pulls verified images • cgroups & namespaces Pod: Order (Rep 2) order-api:v1.4 IP: 10.244.2.19 Node Anti-Affinity Survives Node 1 fail Port: 8080 High Avail ✅ Pod: Catalog (Rep 2) catalog-api:v2.1 IP: 10.244.2.22 Node Anti-Affinity Survives Node 1 fail Port: 8081 High Avail ✅ Pod: Ingress nginx / cilium IP: 10.244.2.08 TLS Termination HTTP Routing Strict NetPol Gateway ✅ Encrypted mTLS Node Channel

🛡️ 2. Secure Production Kubernetes Architecture in a Private Cloud VPC

In mission-critical enterprise environments, Worker Nodes must never have public IP addresses. They reside strictly inside private subnets within an isolated Virtual Private Cloud (VPC).

🔍 Core Security Principles:

  1. Perimeter Defense: Public requests hit a high-capacity WAF (Cloudflare or AWS WAF) for OWASP filtering and DDoS absorption before reaching an Application Load Balancer in the public subnet.
  2. Private Cluster Subnets: Worker Nodes operate on private IP CIDRs (10.0.10.0/20). Outbound traffic to pull container registries or call external third-party payment APIs routes through a NAT Gateway with fixed egress IPs.
  3. Restricted Control Plane: The Kubernetes API endpoint (kube-apiserver) is private or IP-whitelisted, reachable only via VPN (WireGuard / Tailscale) or bastion jump hosts.
  4. Database Governance (Managed DB):
    • Never in an ephemeral container: We leverage a managed cloud engine (AWS RDS PostgreSQL) in Multi-AZ synchronous replication with automatic failover (<60s).
    • Isolated Database Subnet: The DB sits in an air-gapped subnet with zero route to the internet gateway.
    • Zero Hardcoded Credentials: Containers authenticate to the database via short-lived IAM credentials (AWS IRSA / Workload Identity) or automated Vault rotation, combined with KMS disk encryption and TLS 1.3 in transit.
    • Workload Segregation (Orders & Catalog): Critical transactional writes (Orders) hit the Primary instance, while read-intensive catalog lookups target the Standby Read-Replica or local Redis caches.
  5. East-West Micro-segmentation (NetworkPolicies): Using eBPF-powered CNI (Cilium), default-deny ingress/egress rules ensure that even if a public web container is compromised, it cannot lateral move to the database or administrative namespaces.

🌐 End-to-End Infrastructure Architecture Diagram

Enterprise Cloud Architecture: Hardened Kubernetes Cluster in Private VPC 🌍 Public Internet & Edge Security 👤 Web End Users HTTPS / 443 🛡️ WAF & Anti-DDoS Cloudflare / AWS WAF (OWASP rules) 🔐 DevOps & Bastion VPN WireGuard / OIDC SSO / mTLS 🏢 Private Virtual Private Cloud (VPC) — 10.0.0.0/16 🌐 Public Subnet (Ingress DMZ) — 10.0.1.0/24 Public Application Load Balancer (ALB) ACM TLS 1.3 Certificate • Public SSL Termination 🔄 NAT Gateway (Outbound Only) Fixed Egress IP (Pulls registries & 3rd-party APIs) Sanitized traffic 🔒 Private Subnet: Kubernetes Worker Nodes (No Public IPs) — 10.0.10.0/20 Ingress Controller (Nginx / Envoy / Cilium) • URL routing: /orders, /catalog, /cart • Rate Limiting & Inter-service mTLS • NetworkPolicy: Ingress strictly from ALB Private TargetGroup Namespace: prod • Pod: Order-Service App Container (Non-Root, ReadOnlyFS) SecurityContext: drop ALL, seccomp Secrets & Cloud IAM Roles (IRSA) Zero hardcoded secrets • Ephemeral OIDC token NetworkPolicy (Cilium eBPF) Egress allowed ONLY to Primary DB 5432 Namespace: prod • Pod: Catalog-Service Catalog Container (Read-Heavy) Product search, categories & inventory Distributed Redis Cache & DB Reads Read-Replica DB connection (port 5432) Strict NetworkPolicy Egress allowed ONLY to DB / Cache Namespace: prod • Pod: Payment & Cart Cart Container & Outbox Relayer Asynchronous domain event publishing Controlled outbound egress via NAT Secure TLS calls to Stripe gateway Strict NetworkPolicy No access to order transaction tables Egress via NAT 🗄️ Isolated Database Subnet — 10.0.50.0/24 (ZERO INTERNET ROUTE) PostgreSQL RDS Primary (AZ-a) • KMS Encryption at-rest (AES-256) • Mandatory TLS 1.3 connections • Security Group: ONLY accepts Pods on port 5432 • Automated backups & Point-in-time recovery • IAM DB Authentication (Short-lived 15m tokens) Tables: orders, catalog_items, outbox_events PostgreSQL RDS Standby / Read-Replica (AZ-b) • Continuous synchronous Multi-AZ replication • Automatic failover < 60s upon outage • Situated in distinct Availability Zone (AZ-b) • Serves as Read-Replica for Catalog • Zero inbound/outbound internet routing High Availability SLA (99.99%) Sync AZ TCP 5432 Write TCP 5432 Read Replica ✕ Blocked: no gateway or route

🔐 3. The 5 Security Pillars

🧱 1. Layered VPC Subnetting

Strict 3-tier segregation: Public Subnet for Load Balancers, Private Subnet for Worker Nodes without public IPs, and an Isolated Subnet for the database without any internet route.

🛡️ 2. Perimeter & Ingress Armor

Cloud WAF stops SQL injections, XSS, and volumetric DDoS attacks. Sanitized traffic reaches the Application Load Balancer, which securely terminates TLS and hands off to the cluster Ingress Controller.

🗄️ 3. Managed Database Resilience

Managed Cloud PostgreSQL (RDS) with Multi-AZ synchronous replication. KMS at-rest disk encryption, TLS 1.3 in-transit, and credential-less authentication using ephemeral IAM tokens (IRSA).

🔒 4. Micro-segmentation (NetworkPolicies)

Default-deny network policies enforced via eBPF (Cilium). Only whitelisted Pod labels can open port 5432 to the database. Even if a public container is breached, attackers cannot reach adjacent workloads or data stores.

Related reading: