← Kubernetes from Zero: Containers, Clusters, and Operations

Managed Kubernetes: Cloud Shared Responsibility

Decide what a cloud Kubernetes service operates, what your team still owns, and where the enterprise AI workflow platform's OOM recovery actually lands.

Published 11 Aug 2026

Run it in the public monorepo

This course is built around the public HelixWorks Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.

Source: infra/stacks/prod/main.tf

vpc_cidr            = "10.30.0.0/16"
  kubernetes_version  = var.kubernetes_version
  node_instance_types = ["m7i.large"]
  node_min_size       = 3
  node_max_size       = 20
  deletion_protection = true

Code to reality

Declared intent: Declare the production cloud substrate with explicit network, Kubernetes, capacity, and protection policy.
Interpreter: Terraform passes environment policy into the shared module and the AWS provider reconciles managed resources.
Software effect: One EKS control plane manages a bounded node group while deletion protection applies to the managed data tier.
Hardware effect: AWS allocates network ranges, managed control-plane capacity, at least three billable EC2 workers, and protected database storage.
Observable evidence: Terraform outputs, AWS inventory, Kubernetes node readiness, and an application probe connect declaration to reality.

The enterprise problem and today’s slice

Enterprise problem: A managed Kubernetes purchase can remove control-plane toil, but the enterprise AI workflow platform 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.

The service-mode ladder

“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.

Mode	Provider typically operates	Customer still operates	Use when	Avoid when
Self-managed on cloud VMs	Physical facilities, hypervisor, base cloud APIs	Control plane, etcd, nodes, upgrades, network integrations, workloads, data	Exact control or portability outweighs toil	Team wants a managed control plane or lacks cluster lifecycle expertise
Managed control plane	Control-plane hosts, etcd availability/maintenance, service API	VPC design, nodes or node groups, add-ons, workloads, data, authorization, SLO	Standard Kubernetes API plus node flexibility	Required responsibility remains ambiguous or provider constraints conflict
Managed control plane and node groups	Above plus automation around node creation/update/repair	Node-pool policy and rollout timing, workload compatibility, resources, data, SLO	Reduce repetitive fleet operations while retaining shapes/configuration	Workload cannot tolerate provider node lifecycle or needs unsupported host control
Highly managed or autopilot mode	Above plus much node sizing, scaling, security configuration, and maintenance	Workload manifests, supported constraints, application/data security, availability design, observability and response	Most workloads fit constraints and reduced toil is the priority	Privileged agents, unusual host access, or exact hardware/network control is mandatory

GKE currently describes Autopilot as its recommended managed mode for most production workloads and says Google manages nodes, scaling, security configuration, and other preconfigured settings; Standard preserves direct node-infrastructure control (GKE modes). This is a current product claim, not a reason to skip workload validation.

Code versus cloud, cluster, and hardware effects

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: enterprise-workflow-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: workflow-platform
          image: registry.example/enterprise-workflow@sha256:REPLACE_ME
          resources:
            requests:
              memory: 384Mi
            limits:
              memory: 768Mi

Code or action	Cloud/provider effect	Kubernetes/software effect	Actual compute/customer effect
Terraform managed-cluster module	Calls provider APIs to create regional service resources, endpoint, and mode-specific compute policy	Provider initializes a Kubernetes control plane and integration controllers	Provider allocates hidden control-plane compute; customer pays/operates according to service terms
`private_endpoint = true`	Configures provider network reachability for the cluster API	Changes where Kubernetes clients can connect from	Does not make workloads private automatically; routes, DNS, firewall, and egress remain designed
`minimum_node_count = 3`	Requests mode-specific worker capacity or lower bound	Nodes register and expose allocatable resources when provisioning succeeds	Creates three separate machine budgets, not one pooled RAM heap
the enterprise AI workflow platform Deployment	No control-plane hardware is created	Controllers schedule three desired pod replicas	Processes consume real node CPU/RAM; replicas improve availability only across failures they are spread over
Memory request/limit	No cloud VM is resized directly	Scheduler reserves request; runtime applies limit	Kernel accounts physical/VM-backed pages and may kill a process at its boundary

OOM response across the shared boundary

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.

Evidence	First owner	Action	Escalate when
Container exceeds declared limit	Application/platform team	Profile growth; justify resource or code change; replay	Provider enforcement contradicts documented behavior with reproducible evidence
Pod Pending for insufficient resources	Platform team or mode-specific autoscaler owner	Check requests, constraints, quotas, and capacity policy	Provider cannot provision eligible advertised capacity or service reports degradation
Managed control-plane endpoint unavailable	Provider service plus customer network owner	Separate provider status from customer DNS/routes/firewalls	Provider-owned endpoint fails from approved paths with network controls proven
Node maintenance disrupts all replicas	Shared: provider schedules lifecycle; customer designs workload tolerance	Fix spreading, budgets, readiness, rollout policy	Provider violates documented maintenance behavior after workload controls are proven

Decision rule: buy the most managed mode that satisfies required privileges, topology, evidence, and lifecycle control; keep an explicit owner for everything above the service boundary. Reduced access should be accepted only when the provider supplies enough behavior and evidence to operate the customer outcome.

Key takeaways

Cloud Kubernetes changes the location and operator of infrastructure, but the enterprise AI workflow platform'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.

Checklist

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 the enterprise AI workflow platform's OOM path without assuming provider ownership.
[ ] Retained customer proof and provider case identifiers in one incident timeline.

Primary references

Managed control planes do not transfer workload, identity, or availability ownership; validate each boundary against the provider guidance for EKS security, EKS control-plane operations, and EKS reliability.