Requirements
Supported add-ons
- Dashboard: Provides a Kubernetes dashboard UI for the cluster.
- AWS Workload Identity: Allows your pods to assume AWS IAM Roles.
- AWS ECR: Allows pulling images from private ECR registries.
- AWS EFS: Provides support for persistent volumes using AWS Elastic File System.
- Local Path Storage: Create PVCs backed by local volumes.
- Logs: Enable logging for pods and cluster auditing.
Step 1 - Preparing the AWS environment
Ensure your AWS environment includes:- A VPC with:
- At least one public subnet, or
- At least one private subnet with a NAT gateway for egress traffic
- Guide on creating a VPC with AWS Console (External)
Tailored instructions for IAM Role creation are available in the Control Plane Console when creating an AWS Kubernetes cluster using the UI. Alternatively, you can follow the instructions below:
- IAM Role:
- Create an IAM Role with the naming pattern
cpln-mk8s-${ORG}. For example,cpln-mk8s-testingif the organization name istesting. - Create an IAM Policy with the naming pattern
cpln-mk8s-${ORG}. For example,cpln-mk8s-testingif the organization name istesting.
- Create an IAM Role with the naming pattern
Control Plane Connector Policy
-
Attach the connector policy to the
cpln-mk8s-${ORG}IAM Role. -
Edit the trust policy of the
cpln-mk8s-${ORG}IAM Role. Important: Replace${ACCOUNT_ID}with your own account id.
Trust Policy
- Save the updates and copy the ARN of the IAM Role for use in the next step.
Step 2 - Create a Managed Kubernetes Cluster Using a Manifest File
- Update the manifest below: Modify the following
aws-mk8s-template.yamlYAML manifest below with actual values. Customize the file as needed. Replace placeholders for${ROLE_ARN},${SSH_KEY_NAME},${SUBNET_1}and${SUBNET_2}and${VPC_ID}. Use the Role ARN of the IAM Role created in the previous step in place of${ROLE_ARN}.
YAML
- Add-ons: Includes Dashboard, Local Path Storage, AWS Workload Identity and awsECR.
- Location: The cluster’s Kubernetes control plane is managed in the
eu-central-1region. Placing worker nodes close to the control plane is recommended for optimal performance. Full list of supported regions:[af-south-1, ap-east-1, ap-northeast-1, ap-northeast-2, ap-northeast-3, ap-south-1, ap-south-2, ap-southeast-1, ap-southeast-2, ap-southeast-3, ap-southeast-4, ca-central-1, eu-central-1, eu-central-2, eu-north-1, eu-south-1, eu-south-2, eu-west-1, eu-west-2, eu-west-3, me-central-1, me-south-1, sa-east-1, us-east-1, us-east-2, us-west-1, us-west-2]. - Kubernetes API Firewall: Utilizes the
Defaultrule, allowing public access to the Kubernetes API. It is advisable to restrict API access to a known IP range for security purposes. - Kubernetes Version: 1.30.3.
- Node Pool: A single
generalnode pool, scaling on-demand between 1 and 4 nodes. - Server Image: ubuntu/jammy-22.04.
-
Create the Cluster: Deploy the
aws-mk8s-examplecluster by applying the manifest.- Console: Apply the
aws-mk8s-template.yamlfile using thecpln apply >_option in the upper right corner. - CLI: Execute
cpln apply -f aws-mk8s-template.yaml --org YOUR_ORG_HERE.
- Console: Apply the
Step 3 - Accessing the Cluster
1. Using the Terminal
- Obtain the Cluster’s Kubeconfig File: Execute the command
cpln mk8s kubeconfig aws-mk8s-example -f /tmp/aws-mk8s-example-conf. - Access the Cluster with
kubectl: Use the obtained kubeconfig file by runningexport KUBECONFIG=/tmp/aws-mk8s-example-conffor the current shell session.
2. Using Kubernetes Dashboard
- Navigate to Control Plane Console: Visit the Control Plane Console.
- Access the Dashboard: In the Control Plane Console, navigate to
Kubernetesin the left sidebar panel and click onOpenunderDashboardfor the clusteraws-mk8s-example.
Advanced Configuration Options
Deploy Role Chain
AWS accounts with high security requirements may not allow a direct trust policy to allow direct access from Control Plane for setup and management. In this situation, you can configure the initial login from Control Plane into a different intermediary account and add a chain of roles that will be assumed to reach the target account..spec.provider.aws.deployRoleChain
Each record in the deployRoleChain array is assumed after the initial login into the deployRole.
The chain of roles is processed in the order listed in the array, from top to bottom.
Each step in the chain must have a trust policy in place to allow sts:assumeRole from the previous step.
| Property | Type | Description |
|---|---|---|
roleArn | string | The role that will be assumed using sts:assumeRole. |
externalId | string (optional) | The externalId to use during the assume role. |
sessionNamePrefix | string (optional) | A prefix to use for the session name. The rest of the session will be generated to make it unique. |
example trust policy