A control plane coordinates changes to platform resources and works to keep them in a desired state. Kubernetes can fill this role for a distributed-service platform: its orchestration engine responds when applications become unhealthy, while its extensible API lets the same approach reach beyond application workloads. A control plane is therefore more than a place to deploy services. section 7.0 section 2.3.5
Start with the operational problem. A platform must give developers resources to build, release, and operate software without requiring them to manage every failure or infrastructure change themselves. Kubernetes can redeploy a failing service, move services away from failing machines, and adjust instance counts. Its API also provides a way to extend orchestration to other platform needs. That combination makes self-service more reliable without treating every request as a manual operations task. section 7.0
Keep the control plane’s deployment boundary explicit. One practical base contains only services the cloud vendor fully manages. This limits the platform team’s operational responsibility and concentrates provisioning in one infrastructure pipeline. The boundary can change as vendor-managed offerings change; it is not a reason to force every platform component into the first deployment. section 7.4
Establishing an EKS control plane base
After provisioning VPCs and preparing a customer OpenID Connect provider, deploy an EKS base through a dedicated pipeline. Configure the cluster’s version, network placement, and access, then test that EKS exists, is active, and runs the requested version. Check that nodes report as ready and required cluster services are running. These checks make the foundation verifiable before additional platform capabilities depend on it. section 7.4
$ cat main.tf
module "eks" {
source = "terraform-aws-modules/eks/aws"
version = "20.36.0"
cluster_name = var.cluster_name
cluster_version = var.eks_version
cluster_endpoint_public_access = true #1
authentication_mode = "API" #2
access_entries = { #3
clusterAdmin = {
principal_arn = "arn:aws:iam::${var.aws_account_id}:role/${var.aws_assume_role}"
policy_associations = {
clusterAdmin = {
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKS
➥ ClusterAdminPolicy"
access_scope = {
type = "cluster"
}
}
}
}
}
vpc_id = data.aws_vpc.vpc.id
subnet_ids = data.aws_subnets.cluster_private_subnets.ids
control_plane_subnet_ids = data.aws_subnets.cluster_intra_subnets.ids
cluster_enabled_log_types = var.enable_log_types #4
create_kms_key = true #5
# For longer cluster names using the prefix goes over 38 char limit
iam_role_use_name_prefix = false
}
The EKS Terraform configuration shows concrete control-plane choices: cluster version, VPC and subnet placement, endpoint access, and an administrator access entry. section 7.4
Kubernetes is not the only possible control plane. Cloud-provider APIs can be a starting point, but may require a service interface that Kubernetes supplies through its extensible API; cloud control-plane services with serverless functions or Terraform Cloud with Sentinel and permission boundaries are other options. Whatever the implementation, keep governance close to the change: provide developers with self-service ways to meet requirements, then have the control plane confirm compliance before a change is made. section 7.4 section 1.3.3
