Managed Kubernetes: Cloud Shared Responsibility

Enterprise problem: A managed Kubernetes purchase can remove control-plane toil, but Ziba still fails if the team assumes the provider owns application memory, workload security, capacity policy, data recovery, or customer-facing availability. Whole-course context: The incoming on-premises model assigns every rack-to-pod layer to the organization; today moves selected layers behind a provider service boundary without erasing accountability. Today’s slice: We compare self-managed, managed-control-plane, managed-node, and highly managed modes, then create a responsibility matrix tied to an OOM recovery. End-of-day evidence: A provider-neutral architecture, RACI-style ownership record, mode decision, deployment mapping, and recovery drill identify who acts at every boundary. Still unsolved: AWS- and GCP-specific network, identity, billing, and provisioning details are handled in dedicated days.

The thesis is that “managed Kubernetes” moves responsibilities; it does not remove them. Begin with three boxes—provider platform, shared cluster, customer outcome—then name every interface whose failure can still reach readers.

Vendor feature lists hide ownership gaps unless each operational action has an accountable party and terminal evidence. These use cases turn a service-mode selection and a live incident escalation into testable customer outcomes.

Shared responsibility becomes useful only when it changes a decision during design or incident response. These stories require a named owner, action, and proof instead of the vague statement that “the cloud handles it.”

A cloud console click can create a cluster while leaving critical defaults implicit, so the product flow must begin with the customer's required outcome and expose every retained responsibility. The recovery flow likewise separates workload action from provider escalation before either party changes state.

A single “cloud” box conceals which API, machine, and process an operator can actually change. The architecture expands the service boundary while keeping Kubernetes control-plane state, worker execution, and Ziba's code/data distinct.

Responsibility drifts when it lives only in onboarding slides, leaving later operators to infer ownership from permissions. Durable records connect each responsibility to a service mode, evidence path, review date, and escalation route.

Generated-application database: Not created in this slice — Ziba's domain data is unchanged; cloud resource state, Kubernetes state, responsibility decisions, provider cases, and incident evidence provide the durable records required here.

“Managed” is not binary, and comparing only product names creates a false dichotomy. Each step moves a different set of operational loops while leaving application outcome and policy choices with the customer.

Infrastructure declarations compose provider APIs and Kubernetes APIs, but they act at different ownership layers. Reviewers should be able to trace each block to the resources, software, and residual customer duty it creates.

module "managed_kubernetes" {
  source = "./modules/managed-kubernetes"

  region             = var.region
  private_endpoint   = true
  node_mode          = "managed"
  minimum_node_count = 3
}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ziba-blog
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: blog
          image: registry.example/ziba@sha256:REPLACE_ME
          resources:
            requests:
              memory: 384Mi
            limits:
              memory: 768Mi

An application OOM usually remains a customer-owned workload incident even when every machine is provider-managed. Escalation becomes appropriate when evidence points to the managed service rather than the application's declared or observed state.

Cloud Kubernetes changes the location and operator of infrastructure, but Ziba's manifest, memory behavior, data, replicas, and reader SLO remain customer concerns. The exact responsibility boundary depends on service mode and must be tested rather than inferred from the word “managed.”

• Compare operational loops and evidence, not provider feature counts alone.
• Decompose “shared” work until one party owns each concrete action.
• Route OOM, capacity, network, and control-plane failures to different owners.

A managed-service decision is incomplete if a future on-call engineer cannot tell what they can change and what evidence a provider requires. Validate the matrix through both a workload failure and a provider-boundary simulation.

• [ ] Recorded requirements and rejected modes with concrete falsifiers.
• [ ] Assigned owner, action, evidence, and escalation route per layer.
• [ ] Mapped Terraform and Kubernetes code to provider, software, and compute effects.
• [ ] Exercised Ziba's OOM path without assuming provider ownership.
• [ ] Retained customer proof and provider case identifiers in one incident timeline.