Ziba Kubernetes Platform Decision Capstone

Enterprise problem: Ziba’s OOM-killed blog can be moved to a larger server, an on-premises cluster, Amazon EKS, or Google Kubernetes Engine (GKE), but a provider choice made before ownership, recovery, latency, compliance, and scaling evidence merely relocates the outage. Whole-course context: The incoming artifacts now include memory diagnosis, workload manifests, observability, GitOps, KEDA replica policy, and Karpenter node evidence; today assembles them into one reviewable operating model. Today’s slice: We compare on-premises and managed cloud, AWS and Google Cloud, Infrastructure as Code (IaC) with Terraform, Argo CD delivery, pod and node autoscalers, and the physical effects of each declaration. End-of-day evidence: A decision record, cost/failure model, Git revision, Terraform plan, deployment proof, OOM recovery drill, denied path, and provider-specific resource IDs support a go/no-go. Still unsolved: Contract negotiation, exact regional prices, data-classification approval, and migration scheduling require Ziba’s owners.

The thesis is that Kubernetes portability ends at the API boundary: the same workload YAML can describe pods, but hardware supply, identity, networks, storage, upgrades, cost, and failure recovery remain platform-specific. Begin with need, operating model, and evidence—then expand each box.

A platform decision is useful only if it improves Ziba’s customer outcome and remains operable during failure. These cases cover routine publishing and an evidence-driven recovery that can falsify the chosen model.

“Managed Kubernetes” does not mean managed application reliability, so each actor must know which layers the provider owns and which Ziba still operates. Acceptance joins product evidence to infrastructure and recovery evidence.

The release path crosses source, infrastructure, cluster reconciliation, runtime, and customer traffic, so success at one controller is not production proof. The two flows make a normal change and a failed change terminate in customer-visible evidence.

Portability claims fail when declarative tools are drawn as one controller, because Terraform, Argo CD, Kubernetes, autoscalers, and providers own different state. The architecture separates desired infrastructure, desired workloads, runtime reconciliation, and the hardware underneath.

Recovery becomes dangerous when Git, Terraform state, Kubernetes state, and provider inventory are treated as interchangeable sources of truth. Each record owns a different binding, and cross-plane identifiers remain references rather than inherited authority.

Generated-application database: Not created in this slice — Ziba’s blog content store is pre-existing; this capstone adds durable platform intent, resource bindings, deployment history, audit, backup, and evidence without inventing a new application database.

Provider comparison is meaningless until Ziba decides which undifferentiated work it wants to own. “On-premises” and “cloud” describe location and commercial boundary, while “managed” describes which control-plane or node operations a provider assumes.

Tool overlap causes destructive drift when two controllers believe they own the same object. IaC is the practice of versioning and reconciling infrastructure declarations; Terraform is one implementation, GitOps is an operating model centred on version-controlled desired state and reconciliation, and Argo CD reconciles Kubernetes application resources.

Terraform syntax can look uniform while provider resources produce different networks, control planes, VMs, disks, and identities. The following skeleton deliberately stops at the cluster boundary; production modules must add private access, least-privilege identity, logging, encryption, node strategy, backups, and organisation policy.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 7.0"
    }
  }
}

resource "aws_eks_cluster" "ziba" {
  name     = "ziba-production"
  role_arn = aws_iam_role.eks_control_plane.arn
  vpc_config {
    subnet_ids              = aws_subnet.private[*].id
    endpoint_private_access = true
    endpoint_public_access  = false
  }
}

resource "google_container_cluster" "ziba" {
  name             = "ziba-production"
  location         = "europe-west2"
  enable_autopilot = true
  network          = google_compute_network.ziba.id
  subnetwork       = google_compute_subnetwork.private.id
}

Kubernetes manifests preserve a useful workload contract across providers, but scheduling translates that contract into different supply mechanisms. Keep the image digest, requests, limits, probes, topology and disruption policy portable; isolate provider-specific storage, identity, ingress and node declarations.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ziba-blog
  namespace: ziba
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ziba-blog
  template:
    metadata:
      labels:
        app: ziba-blog
    spec:
      containers:
        - name: blog
          image: registry.example/ziba/blog@sha256:replace-with-approved-digest
          resources:
            requests:
              cpu: "500m"
              memory: 768Mi
            limits:
              memory: 1Gi
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
            periodSeconds: 5

Autoscalers form a dependency chain, not a menu of interchangeable brands, so enable each only for the variable it owns. Wrong-layer automation can multiply OOM failures or create machines that still cannot run the pod.

An automated sync can rapidly reproduce a bad declaration, so Git review, immutable images, health checks, and rollback evidence matter more as automation increases. This Application delegates Kubernetes resources to Argo CD while leaving provider infrastructure to Terraform.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ziba-production
  namespace: argocd
spec:
  project: ziba
  source:
    repoURL: https://github.com/example/ziba-platform.git
    targetRevision: main
    path: environments/production
  destination:
    server: https://kubernetes.default.svc
    namespace: ziba
  syncPolicy:
    automated:
      enabled: true
      prune: false
      selfHeal: true
    syncOptions:
      - CreateNamespace=false

A weighted matrix can launder assumptions into a precise-looking score, so every score needs evidence, an owner, and a condition that would reverse it. Use hard gates first, then score only surviving options.

A platform is not production-ready until it survives the original failure and a platform failure without hiding behind autoscaling. Run the same falsifiable tests on each finalist so the decision compares evidence rather than demos.

1. Replay representative publish and read traffic with the approved image digest.
2. Force the worker above its test cgroup limit in a non-production environment; verify OOMKilled, alerting, diagnosis, and bounded recovery.
3. Create legitimate backlog; verify KEDA/HPA pod scaling and queue-age recovery.
4. Exhaust current placement capacity; verify Pending evidence and the chosen node supplier’s machine lifecycle.
5. Terminate one worker node; verify disruption policy, replacement, availability and provider resource cleanup.
6. Revert a bad Git revision; verify Argo returns to the exact approved image and manifests.
7. Restore content/configuration from backup into an isolated target; measure recovery point and recovery time.
8. Deny the Terraform, Argo, scaler, and node-controller identities one at a time; verify least privilege, alerting, and unaffected positive controls.
9. Export manifests, Terraform state/configuration, evidence and data according to the retirement plan; prove the platform is not a one-way door.

The capstone decision is an ownership choice backed by drills, not a Kubernetes brand comparison. Portable manifests are valuable, but the operational system extends from Git and controllers down to provider APIs, virtual machines, disks, networks, and physical hardware.

• On-premises gives Ziba control and responsibility from facilities through etcd, nodes, and applications.
• EKS and GKE manage Kubernetes control-plane work; node responsibility varies by service mode.
• IaC is a practice, Terraform is an infrastructure reconciler, GitOps is an operating model, and Argo CD reconciles Kubernetes desired state.
• KEDA/HPA change pod count, VPA changes or recommends pod resources, and node automation changes machine supply.
• Karpenter is AWS-specific in this design; Cluster Autoscaler and managed provider modes cover different supply models.
• An OOM remains a container/kernel event even when the provider manages the control plane or nodes.
• The winning platform is the least complex option that passes hard constraints, customer SLOs, recovery drills, cost bounds, and exit tests.

The decision is not approved until an independent reviewer can connect every declaration to real state and physical consequence. Record gaps as failed criteria rather than optimistic future work.

• [ ] The decision record names objective, thesis, boundary, assumptions, alternatives, owners, trade-offs and falsifiers.
• [ ] On-premises, EKS and GKE modes were compared at the hardware, control-plane, node, workload, data and support layers.
• [ ] Terraform and Argo CD have non-overlapping ownership, protected state, least-privilege identities and reviewed recovery.
• [ ] Workload YAML uses immutable image digests, truthful requests/limits, probes, topology and disruption controls.
• [ ] KEDA/HPA/VPA and Cluster Autoscaler/Karpenter/managed node supply each own one explicit scaling question.
• [ ] The original OOM, Pending capacity, node loss, bad release, denied authority and restore paths were tested.
• [ ] Evidence links Git SHA, image digest, Terraform state/apply, Argo sync, pod, node and provider resource IDs.
• [ ] Cost includes people, idle buffer, support, storage, network, egress, migration and retirement—not only VM price.
• [ ] RTO, RPO, data residency, security, support and exit criteria pass hard gates.
• [ ] Production approval is based on measured customer and recovery evidence, not a successful apply or green controller alone.