Containerization
Layer 2 runs Kubernetes on top of the infrastructure — managed by the cloud provider (Amazon EKS on AWS, Azure AKS on Azure), so we don’t operate the control plane by hand.
This layer is the cloud-agnostic boundary. Below it, the platform is built from cloud-specific primitives. From Kubernetes up, the implementation is the same regardless of which cloud sits underneath — the same manifests, the same delivery pipeline, the same dashboards. That portability is the whole point of containerizing here: it’s what keeps you from being locked to one provider.
What runs in the cluster
Section titled “What runs in the cluster”Workload packaging
Section titled “Workload packaging”Application and platform workloads are packaged declaratively with Helm and/or Kustomize, so every deployment is versioned, reviewable, and reproducible. These manifests are the desired state that CD reconciles onto the cluster.
Ingress, DNS & TLS
Section titled “Ingress, DNS & TLS”- An ingress controller (NGINX or Traefik) routes external traffic to services.
- cert-manager issues and renews TLS certificates automatically.
- external-dns keeps DNS records in sync with cluster ingress, so there’s no manual DNS step.
Secrets
Section titled “Secrets”Secrets are never committed to Git. We use an operator pattern — External Secrets Operator (pulling from the cloud’s secret store, e.g. AWS Secrets Manager or Azure Key Vault) and/or Sealed Secrets — so the cluster gets what it needs while the source of truth stays in a managed vault.
Scaling & resource governance
Section titled “Scaling & resource governance”- Horizontal Pod Autoscaler (HPA) scales workloads to demand.
- Cluster autoscaler adds and removes nodes to match.
- Requests and limits plus resource quotas keep workloads well-behaved and costs predictable.
Isolation & safety
Section titled “Isolation & safety”- Namespaces separate environments and tenants within the cluster.
- Network policies restrict pod-to-pod traffic to what’s actually needed.
- RBAC scopes who and what can act inside the cluster.
Why this layer matters
Section titled “Why this layer matters”| Without it | With managed Kubernetes here |
|---|---|
| Deploys differ per environment and per cloud | One declarative model, applied everywhere |
| Scaling is manual and reactive | Autoscaling on pods and nodes |
| Moving clouds means a rebuild | Everything above is portable |
This is the foundation the CI/CD layer ships onto, and the source of most of the signals the observability stack collects.