Module 7: Eks Specifics For Production

2. The managed control plane: what AWS runs, what you still own

Description

In Module 1, lesson 6, you opened up andes-cargo-cluster's box and found five processes — kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kube-proxy — running as Pods inside a Docker container acting as the control-plane node. You confirmed it yourself with kubectl get pods -A -o wide and with docker exec ... crictl images: the same container images that run on a real node (registry.k8s.io/kube-apiserver, registry.k8s.io/etcd), simply packaged by kind to run on your laptop. What that lesson didn't say, because it didn't matter until now, is that you were responsible for all of it. If that andes-cargo-cluster-control-plane container had run out of memory, if etcd had gotten corrupted, if you needed to apply a security patch to kube-apiserver itself — all of that would have been your problem, with no one else to call.

In EKS, that responsibility changes hands. This lesson draws the exact line: what passes to AWS, with a service level agreement in place, and what stays yours even though the cluster is no longer kind.

Connection to the module

This lesson directly picks back up the architecture you built in Module 1, lesson 6 — not as a review, but as the exact comparison point everything EKS changes gets measured against. Every component you identified there (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, kube-proxy, kubelet) reappears here, with one new question for each: who administers it in EKS?

The shared responsibility model, applied to Kubernetes

AWS splits an EKS cluster's responsibility into two planes, with a clear boundary:

              THE RESPONSIBILITY BOUNDARY IN EKS

  ┌──────────────────────────────────────────────────────────┐
  │  CONTROL PLANE — AWS account, administered by AWS            │
  │                                                                │
  │   kube-apiserver   (multiple replicas, load-balanced,        │
  │                      across at least two availability zones) │
  │   etcd              (backed up, replicated, encrypted at rest)│
  │   kube-scheduler                                              │
  │   kube-controller-manager                                     │
  │                                                                │
  │   AWS applies security patches, administers availability,    │
  │   and offers a formal SLA on this layer                       │
  └──────────────────────────────┬───────────────────────────────┘
                                  │  kube-apiserver exposes an
                                  │  HTTPS endpoint — the same
                                  │  ~/.kube/config you already use
                                  ▼
  ┌──────────────────────────────────────────────────────────┐
  │  DATA PLANE — your AWS account, your responsibility           │
  │                                                                │
  │   Nodes (EC2 via node groups, or Fargate)                     │
  │   kubelet + kube-proxy + containerd on every node              │
  │   Cluster add-ons (CNI, CoreDNS, storage CSI)                 │
  │   RBAC — who can do what inside the cluster                   │
  │   Your Pods, Deployments, Services — everything from M2-6      │
  └──────────────────────────────────────────────────────────┘

The AWS Shared Responsibility Model, applied here with no ambiguity: AWS owns the infrastructure that runs kube-apiserver and etcd — security patching of the underlying operating system, high availability of those processes, etcd encryption at rest, automatic backups. You still own everything running inside the cluster that control plane administers: your nodes, your add-ons, your RBAC, and — this is what almost no one anticipates — the Kubernetes version running on your nodes, which you have to keep synchronized with the control plane's version (AWS doesn't automatically update your nodes for you, unless you use EKS Auto Mode, named by contrast in Module 7.3).

Component by component: the same map from Module 1.6, with the correct owner

Component	In `kind` (Module 1)	In real EKS
`kube-apiserver`	Just another Pod, running in the Docker container acting as the `control-plane` node — you created it with `kind create cluster`	Administered by AWS, with multiple replicas load-balanced across availability zones, outside your directly visible AWS account
`etcd`	Just another Pod, in the same container — no automatic backup, no encryption configured by default	Administered by AWS: backed up, replicated, encrypted at rest by default
`kube-scheduler`	Just another Pod, in the same container	Administered by AWS
`kube-controller-manager`	Just another Pod, in the same container	Administered by AWS
`kube-proxy`	Runs on every node (control plane and workers), you installed it when creating the cluster	Runs on every node of yours — AWS distributes it as an optionally managed add-on, but it lives in the data plane, not the managed one
`kubelet`	Runs on every node, part of the `kindest/node` image you downloaded	Runs on every node of yours (EC2 or Fargate) — never AWS's responsibility in the "managed control plane" sense
CNI (Pod networking)	`kindnet`, installed automatically by `kind`	Your choice — Amazon VPC CNI by default, or a third-party CNI; your responsibility to install and maintain it (except with EKS Auto Mode)
CoreDNS	Installed automatically by `kind`	Optionally AWS-managed add-on, but the decision to install it and its configuration are still yours
Nodes (the hardware/VM behind it)	A single Docker host on your laptop, simulating three nodes	Real EC2 (node groups) or Fargate — your account, your bill, your patching responsibility unless you choose managed node groups or Fargate
RBAC	Configured by you, or inherited from `kind`'s default `kubeconfig`	Configured by you — AWS adds an extra mapping layer between IAM and RBAC (`aws-auth` ConfigMap or `EKS access entries`, depending on the version), but the RBAC rules themselves are still yours

The row worth rereading twice: in kind, the control plane's four central components (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) ran in the same Docker container you fully controlled — no one had an SLA with you over those four processes, because they were, literally, yours. In EKS, those same four processes move to an AWS account you don't directly see, with a formal contract behind it. The rest of the table — nodes, add-ons, RBAC, and everything you built in Modules 2-6 — stays yours, regardless of whether the cluster is kind or EKS.

Worked example: what `aws eks describe-cluster` tells you that `kubectl cluster-info` never did

What to expect (representative) — verified against the AWS CLI reference for describe-cluster, never executed against a real account:

aws eks describe-cluster --name andes-cargo-cluster --region us-east-1

{
  "cluster": {
    "name": "andes-cargo-cluster",
    "arn": "arn:aws:eks:us-east-1:000000000000:cluster/andes-cargo-cluster",
    "status": "ACTIVE",
    "endpoint": "https://A1B2C3D4E5F6G7H8I9J0.gr7.us-east-1.eks.amazonaws.com",
    "version": "1.34",
    "platformVersion": "eks.5",
    "resourcesVpcConfig": {
      "subnetIds": ["subnet-0abc123", "subnet-0def456"],
      "endpointPublicAccess": true,
      "endpointPrivateAccess": true
    },
    "identity": {
      "oidc": {
        "issuer": "https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
      }
    }
  }
}

Compare this result with the only thing kubectl cluster-info --context kind-andes-cargo-cluster showed you in Module 1: a localhost URL pointing at the port Docker exposed on your laptop. Here there are three fields with no equivalent in kind, and each is a piece you're going to use in this module's following lessons:

endpoint — a real AWS URL (*.eks.amazonaws.com), load-balanced by AWS across the kube-apiserver replicas it administers. There's no Docker port involved at all.
platformVersion — a number kind has no equivalent to report, because in kind there's no "platform version" separate from the Kubernetes version: it's AWS that separately versions both Kubernetes itself (version) and the details of the managed infrastructure holding it up (platformVersion).
identity.oidc.issuer — this cluster's unique OIDC provider, the exact piece this module's lesson 5 uses for IRSA. kind exposes no equivalent, because there's no IAM integration of any kind on a local cluster.

Common mistakes

Thinking "administered by AWS" means "there's nothing to learn about the control plane" (oversimplification). What happens: someone concludes that, since AWS administers kube-apiserver/etcd, it's not worth understanding what those components do. How to spot it: if your explanation of "what EKS is" boils down to "Kubernetes but on AWS," with no ability to name what specific part AWS delegates. How to fix it: understanding what each component does — what Module 1.6 already gave you with executed evidence on kind — is exactly what lets you reason about failures, limits, and costs of a real EKS cluster; "managed" doesn't mean "invisible," it means "someone else operates it, with an SLA."

Assuming AWS also automatically updates nodes and add-ons (responsibility boundary). What happens: someone takes for granted that, if AWS administers the control plane, it also takes care of keeping EC2 nodes and their kubelet versions up to date. How to spot it: if your EKS cluster operation plan includes no node-update step at all. How to fix it: unless you use EKS Auto Mode (Module 7.3, named by contrast), updating nodes — operating system patches, kubelet version kept in sync with the control plane's — is your responsibility, even with managed node groups: "managed" there means AWS gives you one-click update tools, not that it does it without you asking.

Confusing the control plane's Kubernetes version with the nodes' and assuming they always match (technical). What happens: someone assumes that if the control plane reports version: "1.34", all nodes automatically run the same kubelet version. How to spot it: if you never checked kubectl get nodes -o wide to compare the KUBELET-VERSION column against the control plane's version. How to fix it: Kubernetes tolerates up to a few minor-version differences between the control plane and each node's kubelet (the so-called version skew policy), but that tolerance isn't infinite or automatic — a node left outdated for too long can fall outside the supported range, and no one is going to fix it for you without you updating the node group.

Exercises

Exercise 1 — Complete the table from memory. Without looking at this lesson's table, for each of these five components, say whether AWS administers it in EKS or it stays yours: kube-apiserver, kubelet, etcd, the CNI, kube-scheduler.

See solution

kube-apiserver → AWS. kubelet → yours (runs on your nodes, whether EC2 or Fargate). etcd → AWS. The CNI → yours (your choice of which to install and how to configure it, unless you use EKS Auto Mode). kube-scheduler → AWS. If you correctly separated the control plane's four central processes (always AWS) from everything running on or for your nodes (always yours, with EKS Auto Mode as the partial exception), you have this lesson's boundary clear.

Exercise 2 — Explain the responsibility difference using Module 1's real evidence. A colleague who never saw kubectl get pods -A -o wide run against kind asks you: "what's the real difference between kind's control plane and EKS's, if in both cases it's 'just' Kubernetes?" Answer them using that lesson's concrete evidence.

See solution

A complete answer sounds, roughly, like this: "Technically they're the same software — when I ran kubectl get pods -A -o wide against my kind cluster, I saw etcd-andes-cargo-cluster-control-plane, kube-apiserver-andes-cargo-cluster-control-plane, and the rest, running as normal Pods inside a single Docker container on my laptop. The difference isn't the software, it's who's responsible for those Pods staying healthy: in kind, it was me, with no contract in place, running on my own machine. In EKS, those same processes run inside infrastructure AWS administers, with a formal SLA, outside my directly visible account."

Exercise 3 — Predict which describe-cluster field has no equivalent in kind, and why. Of the three fields highlighted in this lesson's "Worked example" (endpoint, platformVersion, identity.oidc.issuer), pick the one you consider most important for the rest of this module, and justify in one sentence why kind could never report that same data.

See solution

identity.oidc.issuer is, with evidence, the most important for the rest of this module: all of lesson 5 (IRSA/EKS Pod Identity) depends on a unique OIDC provider existing, issued by the cluster itself, that IAM can use to trust Kubernetes tokens. kind could never report an equivalent field because it has no IAM integration of any kind — it's a cluster completely isolated from any AWS account, with no built-in federated identity concept at all.

Summary and next step

This lesson took the same five-component map Module 1.6 confirmed with executed evidence on kind, and drew the exact responsibility boundary EKS introduces: kube-apiserver, etcd, kube-scheduler, and kube-controller-manager pass into AWS's hands, with a formal SLA; kubelet, kube-proxy, the CNI, the add-ons, and everything you built in Modules 2-6 stay yours, regardless of which cluster they run on. You confirmed, with a representative aws eks describe-cluster example, three fields kind could never report — a real AWS endpoint, platformVersion, and the OIDC provider (identity.oidc.issuer) — and why the third matters especially for what follows.

Before moving on you should be able to: name the four components EKS administers for you; explain why "managed" doesn't mean "invisible" for nodes and add-ons; and describe which new describe-cluster field enables the identity pattern this module's lesson 5 builds.

Next lesson: node groups, managed, self-managed, and Fargate profiles. There you're going to see the three distinct ways of having compute behind an EKS cluster, and when a real team picks each one.

Resources

Amazon EKS — Amazon EKS architecture — the official reference for the managed control plane and its boundary with the data plane.
AWS — Shared Responsibility Model — the general shared responsibility model, applied here specifically to Kubernetes.
AWS CLI — aws eks describe-cluster — the exact reference for the command and fields used in this lesson's representative example.
kubernetes-and-eks-in-production-guide (NIEVA), Module 1, lesson 6 — kind's architecture with executed evidence, this lesson's central comparison point.
kind — Quick Start — kind reference for anyone who wants to review the local architecture again before continuing.

← Previous1. Module introduction: why this one is different from the previous six Next →3. Node groups: managed, self-managed, and Fargate profiles

2. The managed control plane: what AWS runs, what you still own

Description

Connection to the module

The shared responsibility model, applied to Kubernetes

Component by component: the same map from Module 1.6, with the correct owner

Worked example: what aws eks describe-cluster tells you that kubectl cluster-info never did

Common mistakes

Exercises

Summary and next step

Resources

Worked example: what `aws eks describe-cluster` tells you that `kubectl cluster-info` never did