EKS Control Plane

In a standard Kubernetes cluster, the master node is the “brain” that manages the cluster, schedules containers, and stores cluster state. In EKS, AWS fully abstracts and manages this for you.

Key Takeaway: You do not provision EC2 instances for your EKS control plane. You do not manage its operating system, and you do not manually scale it. AWS provides it as a highly available, managed service.

The Shared Responsibility Model

• AWS is responsible for: The availability, scaling, patching, and backing up of the control plane (API server and etcd database).
• You are responsible for: Configuring worker nodes (Data Plane), setting up IAM/RBAC permissions, managing your VPC networking, and deploying your applications.

Architecture & High Availability

AWS builds the EKS control plane to be highly available and resilient by default. When you create an EKS cluster, AWS creates a dedicated, single-tenant Kubernetes control plane in an AWS-managed VPC (not your customer VPC).

• Multi-AZ Deployment: The control plane is automatically distributed across three Availability Zones (AZs) within an AWS Region.
• Component Redundancy:
  • AWS runs at least two instances of the Kubernetes API server.
  • AWS runs three instances of the etcd database to ensure quorum and prevent data loss.
• Auto-scaling: If your cluster experiences high API load (e.g., massive deployments or intense metric scraping), AWS automatically vertically and horizontally scales the control plane instances behind the scenes.

Core Components of the EKS Control Plane

Under the hood, the EKS Control Plane runs standard upstream Kubernetes components:

1. kube-apiserver: The front end of the control plane. All communication (from kubectl, worker nodes, and internal components) goes through here. EKS automatically places a Network Load Balancer (NLB) in front of the API servers.
2. etcd: The highly available key-value store containing all cluster data and state. In EKS, this is backed up automatically by AWS.
3. kube-scheduler: Watches for newly created Pods with no assigned node and selects a node for them to run on.
4. kube-controller-manager: Runs controller processes (like Node Controller, Job Controller, and Endpoint Controller) that regulate the state of the cluster.
5. cloud-controller-manager: The bridge between Kubernetes and AWS APIs. It handles AWS-specific tasks like provisioning Application Load Balancers (ALBs) or mapping AWS EBS volumes to pods.

Networking: How the Control Plane Talks to Worker Nodes

Because the Control Plane lives in an AWS-managed VPC and your Worker Nodes live in your Customer VPC, they need a secure way to communicate.

AWS solves this using Cross-Account Elastic Network Interfaces (ENIs).

• When you spin up an EKS cluster, AWS injects ENIs into your VPC’s subnets.
• These ENIs act as a secure bridge, allowing the managed API server to talk to the kubelet on your worker nodes, and vice versa.

Endpoint Access Configurations

You have granular control over how you access the kube-apiserver:

• Public Only (Default): The API server is accessible from the internet. Worker nodes also route traffic over the internet to reach the control plane.
• Public & Private: The API server is accessible from the internet, but worker nodes in your VPC communicate with the API server via a private VPC endpoint.
• Private Only (Highest Security): The API server is only accessible from within your VPC (or via VPN/Direct Connect). All internet access to the control plane is disabled.

Security & Identity

Mastering EKS means mastering how it handles authentication. EKS does not use standard Kubernetes user accounts; it natively integrates with AWS IAM (Identity and Access Management).

• Authentication: When you run a kubectl command, the AWS CLI generates a short-lived token using your IAM credentials. The EKS API server intercepts this token and validates it via the AWS IAM service.
• Authorization (RBAC): Once authenticated via IAM, Kubernetes RBAC (Role-Based Access Control) takes over to determine what you can do. The mapping between IAM users/roles and Kubernetes roles is historically managed via the aws-auth ConfigMap (though AWS is transitioning to native EKS Access Entries).
• Secret Encryption: By default, Kubernetes stores secrets in etcd encoded in base64. In EKS, you can enable Envelope Encryption using AWS KMS (Key Management Service) to encrypt secrets at rest within the etcd database.

Observability and Logging

Since you cannot SSH into the master node to check logs (e.g., /var/log/messages), EKS provides Control Plane Logging via Amazon CloudWatch.

You can enable logging for specific control plane components:

• api (API server requests)
• audit (Who did what and when)
• authenticator (Authentication requests)
• controllerManager (Controller logs)
• scheduler (Pod scheduling decisions)

Note: Enabling these logs incurs standard CloudWatch data ingestion charges.

Upgrades and Maintenance

Kubernetes releases new versions frequently. Managing master node upgrades manually is notoriously difficult, but EKS simplifies it:

• On-Demand Upgrades: You control when your control plane is upgraded. EKS does not force-upgrade your cluster until the version reaches absolute End of Life (EOL).
• Zero Downtime: When you trigger an upgrade, EKS performs an out-of-place upgrade. It spins up new control plane instances with the new version, synchronizes the etcd state, shifts the traffic, and then terminates the old instances.