Kubernetes-native declarative infrastructure for AWS.

What is the Cluster API Provider AWS

The Cluster API brings declarative, Kubernetes-style APIs to cluster creation, configuration and management.

The API itself is shared across multiple cloud providers allowing for true AWS hybrid deployments of Kubernetes. It is built atop the lessons learned from previous cluster managers such as kops and kubicorn.

Documentation

Please see our book for in-depth documentation.

Launching a Kubernetes cluster on AWS

Check out the Cluster API Quick Start for launching a cluster on AWS.

Features

• Native Kubernetes manifests and API
• Manages the bootstrapping of VPCs, gateways, security groups and instances.
• Choice of Linux distribution using pre-baked AMIs.
• Deploys Kubernetes control planes into private subnets with a separate bastion server.
• Doesn’t use SSH for bootstrapping nodes.
• Installs only the minimal components to bootstrap a control plane and workers.
• Supports control planes on EC2 instances.
• EKS support

Compatibility with Cluster API and Kubernetes Versions

This provider’s versions are compatible with the following versions of Cluster API and support all Kubernetes versions that is supported by its compatible Cluster API version:

(See Kubernetes support matrix of Cluster API versions).

Kubernetes versions with published AMIs

See amis for the list of most recently published AMIs.

clusterawsadm

clusterawsadm CLI tool provides bootstrapping, AMI, EKS, and controller related helpers.

clusterawsadm binaries are released with each release, can be found under assets section.

clusterawsadm could also be installed via Homebrew on macOS and linux OS. Install the latest release using homebrew:

brew install clusterawsadm

Test to ensure the version you installed is up-to-date:

clusterawsadm version

Getting involved and contributing

Are you interested in contributing to cluster-api-provider-aws? We, the maintainers and community, would love your suggestions, contributions, and help! Also, the maintainers can be contacted at any time to learn more about how to get involved.

In the interest of getting more new people involved we tag issues with good first issue. These are typically issues that have smaller scope but are good ways to start to get acquainted with the codebase.

We also encourage ALL active community participants to act as if they are maintainers, even if you don’t have “official” write permissions. This is a community effort, we are here to serve the Kubernetes community. If you have an active interest and you want to get involved, you have real power! Don’t assume that the only people who can get things done around here are the “maintainers”.

We also would love to add more “official” maintainers, so show us what you can do!

This repository uses the Kubernetes bots. See a full list of the commands here.

Build the images locally

If you want to just build the CAPA containers locally, run

  REGISTRY=docker.io/my-reg make docker-build

Tilt-based development environment

See development section for details.

Implementer office hours

Maintainers hold office hours every two weeks, with sessions open to all developers working on this project.

Office hours are hosted on a zoom video chat every other Monday at 09:00 (Pacific) / 12:00 (Eastern) / 17:00 (Europe/London), and are published on the Kubernetes community meetings calendar.

Other ways to communicate with the contributors

Please check in with us in the #cluster-api-aws channel on Slack.

Github issues

Bugs

If you think you have found a bug please follow the instructions below.

• Please spend a small amount of time giving due diligence to the issue tracker. Your issue might be a duplicate.
• Get the logs from the cluster controllers. Please paste this into your issue.
• Open a new issue.
• Remember that users might be searching for your issue in the future, so please give it a meaningful title to help others.
• Feel free to reach out to the cluster-api community on the kubernetes slack.

Tracking new features

We also use the issue tracker to track features. If you have an idea for a feature, or think you can help kops become even more awesome follow the steps below.

• Open a new issue.
• Remember that users might be searching for your issue in the future, so please give it a meaningful title to help others.
• Clearly define the use case, using concrete examples. EG: I type this and cluster-api-provider-aws does that.
• Some of our larger features will require some design. If you would like to include a technical design for your feature please include it in the issue.
• After the new feature is well understood, and the design agreed upon, we can start coding the feature. We would love for you to code it. So please open up a WIP (work in progress) pull request, and happy coding.

“Amazon Web Services, AWS, and the “Powered by AWS” logo materials are trademarks of Amazon.com, Inc. or its affiliates in the United States and/or other countries.”

Our Contributors

Thank you to all contributors and a special thanks to our current maintainers & reviewers:

and the previous/emeritus maintainers & reviewers:

All the CAPA contributors:

Getting Started

Quick Start

In this tutorial we’ll cover the basics of how to use Cluster API to create one or more Kubernetes clusters.

Installation

There are two major quickstart paths: Using clusterctl or the Cluster API Operator.

This article describes a path that uses the clusterctl CLI tool to handle the lifecycle of a Cluster API management cluster.

The clusterctl command line interface is specifically designed for providing a simple “day 1 experience” and a quick start with Cluster API. It automates fetching the YAML files defining provider components and installing them.

Additionally it encodes a set of best practices in managing providers, that helps the user in avoiding mis-configurations or in managing day 2 operations such as upgrades.

The Cluster API Operator is a Kubernetes Operator built on top of clusterctl and designed to empower cluster administrators to handle the lifecycle of Cluster API providers within a management cluster using a declarative approach. It aims to improve user experience in deploying and managing Cluster API, making it easier to handle day-to-day tasks and automate workflows with GitOps. Visit the CAPI Operator quickstart if you want to experiment with this tool.

Common Prerequisites

• Install and setup kubectl in your local environment
• Install kind and Docker
• Install Helm

Install and/or configure a Kubernetes cluster

Cluster API requires an existing Kubernetes cluster accessible via kubectl. During the installation process the Kubernetes cluster will be transformed into a management cluster by installing the Cluster API provider components, so it is recommended to keep it separated from any application workload.

It is a common practice to create a temporary, local bootstrap cluster which is then used to provision a target management cluster on the selected infrastructure provider.

Choose one of the options below:

1. Existing Management Cluster

   For production use-cases a “real” Kubernetes cluster should be used with appropriate backup and disaster recovery policies and procedures in place. The Kubernetes cluster must be at least v1.20.0.

   export KUBECONFIG=<...>
   

OR

2. Kind

   kind can be used for creating a local Kubernetes cluster for development environments or for the creation of a temporary bootstrap cluster used to provision a target management cluster on the selected infrastructure provider.

   The installation procedure depends on the version of kind; if you are planning to use the Docker infrastructure provider, please follow the additional instructions in the dedicated tab:

   DefaultDockerKubeVirt

   Create the kind cluster:

   kind create cluster
   

   Test to ensure the local kind cluster is ready:

   kubectl cluster-info
   

   Run the following command to create a kind config file for allowing the Docker provider to access Docker on the host:

   cat > kind-cluster-with-extramounts.yaml <<EOF
   kind: Cluster
   apiVersion: kind.x-k8s.io/v1alpha4
   networking:
     ipFamily: dual
   nodes:
   - role: control-plane
     extraMounts:
       - hostPath: /var/run/docker.sock
         containerPath: /var/run/docker.sock
   EOF
   

   Then follow the instruction for your kind version using kind create cluster --config kind-cluster-with-extramounts.yaml to create the management cluster using the above file.

   Create the Kind Cluster

   KubeVirt is a cloud native virtualization solution. The virtual machines we’re going to create and use for the workload cluster’s nodes, are actually running within pods in the management cluster. In order to communicate with the workload cluster’s API server, we’ll need to expose it. We are using Kind which is a limited environment. The easiest way to expose the workload cluster’s API server (a pod within a node running in a VM that is itself running within a pod in the management cluster, that is running inside a Docker container), is to use a LoadBalancer service.

   To allow using a LoadBalancer service, we can’t use the kind’s default CNI (kindnet), but we’ll need to install another CNI, like Calico. In order to do that, we’ll need first to initiate the kind cluster with two modifications:

   1. Disable the default CNI
   2. Add the Docker credentials to the cluster, to avoid the Docker Hub pull rate limit of the calico images; read more about it in the docker documentation, and in the kind documentation.

   Create a configuration file for kind. Please notice the Docker config file path, and adjust it to your local setting:

   cat <<EOF > kind-config.yaml
   kind: Cluster
   apiVersion: kind.x-k8s.io/v1alpha4
   networking:
   # the default CNI will not be installed
     disableDefaultCNI: true
   nodes:
   - role: control-plane
     extraMounts:
      - containerPath: /var/lib/kubelet/config.json
        hostPath: <YOUR DOCKER CONFIG FILE PATH>
   EOF
   

   Now, create the kind cluster with the configuration file:

   kind create cluster --config=kind-config.yaml
   

   Test to ensure the local kind cluster is ready:

   kubectl cluster-info
   

   Install the Calico CNI

   Now we’ll need to install a CNI. In this example, we’re using calico, but other CNIs should work as well. Please see calico installation guide for more details (use the “Manifest” tab). Below is an example of how to install calico version v3.24.4.

   Use the Calico manifest to create the required resources; e.g.:

   kubectl create -f  https://raw.githubusercontent.com/projectcalico/calico/v3.24.4/manifests/calico.yaml
   

Install clusterctl

The clusterctl CLI tool handles the lifecycle of a Cluster API management cluster.

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-linux-amd64 -o clusterctl

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-linux-arm64 -o clusterctl

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-linux-ppc64le -o clusterctl

sudo install -o root -g root -m 0755 clusterctl /usr/local/bin/clusterctl

clusterctl version

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-darwin-amd64 -o clusterctl

curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-darwin-arm64 -o clusterctl

chmod +x ./clusterctl

sudo mv ./clusterctl /usr/local/bin/clusterctl

clusterctl version

brew install clusterctl

clusterctl version

curl.exe -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v1.8.4/clusterctl-windows-amd64.exe -o clusterctl.exe

clusterctl.exe version

Initialize the management cluster

Now that we’ve got clusterctl installed and all the prerequisites in place, let’s transform the Kubernetes cluster into a management cluster by using clusterctl init.

The command accepts as input a list of providers to install; when executed for the first time, clusterctl init automatically adds to the list the cluster-api core provider, and if unspecified, it also adds the kubeadm bootstrap and kubeadm control-plane providers.

Enabling Feature Gates

Feature gates can be enabled by exporting environment variables before executing clusterctl init. For example, the ClusterTopology feature, which is required to enable support for managed topologies and ClusterClass, can be enabled via:

export CLUSTER_TOPOLOGY=true

Additional documentation about experimental features can be found in Experimental Features.

Initialization for common providers

Depending on the infrastructure provider you are planning to use, some additional prerequisites should be satisfied before getting started with Cluster API. See below for the expected settings for common providers.

export LINODE_TOKEN=<your-access-token>

# Initialize the management cluster
clusterctl init --infrastructure linode-linode

curl -L https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/download/v0.0.0/clusterawsadm-linux-amd64 -o clusterawsadm

chmod +x clusterawsadm

sudo mv clusterawsadm /usr/local/bin

clusterawsadm version

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

# The clusterawsadm utility takes the credentials that you set as environment
# variables and uses them to create a CloudFormation stack in your AWS account
# with the correct IAM resources.
clusterawsadm bootstrap iam create-cloudformation-stack

# Create the base64 encoded credentials using clusterawsadm.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

# Finally, initialize the management cluster
clusterctl init --infrastructure aws

curl -L https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/download/v0.0.0/clusterawsadm-darwin-amd64 -o clusterawsadm

curl -L https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/download/v0.0.0/clusterawsadm-darwin-arm64 -o clusterawsadm

chmod +x clusterawsadm

sudo mv clusterawsadm /usr/local/bin

clusterawsadm version

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

# The clusterawsadm utility takes the credentials that you set as environment
# variables and uses them to create a CloudFormation stack in your AWS account
# with the correct IAM resources.
clusterawsadm bootstrap iam create-cloudformation-stack

# Create the base64 encoded credentials using clusterawsadm.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

# Finally, initialize the management cluster
clusterctl init --infrastructure aws

brew install clusterawsadm

clusterawsadm version

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

# The clusterawsadm utility takes the credentials that you set as environment
# variables and uses them to create a CloudFormation stack in your AWS account
# with the correct IAM resources.
clusterawsadm bootstrap iam create-cloudformation-stack

# Create the base64 encoded credentials using clusterawsadm.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

# Finally, initialize the management cluster
clusterctl init --infrastructure aws

curl.exe -L https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/download/v0.0.0/clusterawsadm-windows-amd64.exe -o clusterawsadm.exe

clusterawsadm.exe version

$Env:AWS_REGION="us-east-1" # This is used to help encode your environment variables
$Env:AWS_ACCESS_KEY_ID="<your-access-key>"
$Env:AWS_SECRET_ACCESS_KEY="<your-secret-access-key>"
$Env:AWS_SESSION_TOKEN="<session-token>" # If you are using Multi-Factor Auth.

# The clusterawsadm utility takes the credentials that you set as environment
# variables and uses them to create a CloudFormation stack in your AWS account
# with the correct IAM resources.
clusterawsadm bootstrap iam create-cloudformation-stack

# Create the base64 encoded credentials using clusterawsadm.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
$Env:AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)

# Finally, initialize the management cluster
clusterctl init --infrastructure aws

export AZURE_SUBSCRIPTION_ID="<SubscriptionId>"

# Create an Azure Service Principal and paste the output here
export AZURE_TENANT_ID="<Tenant>"
export AZURE_CLIENT_ID="<AppId>"
export AZURE_CLIENT_ID_USER_ASSIGNED_IDENTITY=$AZURE_CLIENT_ID # for compatibility with CAPZ v1.16 templates
export AZURE_CLIENT_SECRET="<Password>"

# Settings needed for AzureClusterIdentity used by the AzureCluster
export AZURE_CLUSTER_IDENTITY_SECRET_NAME="cluster-identity-secret"
export CLUSTER_IDENTITY_NAME="cluster-identity"
export AZURE_CLUSTER_IDENTITY_SECRET_NAMESPACE="default"

# Create a secret to include the password of the Service Principal identity created in Azure
# This secret will be referenced by the AzureClusterIdentity used by the AzureCluster
kubectl create secret generic "${AZURE_CLUSTER_IDENTITY_SECRET_NAME}" --from-literal=clientSecret="${AZURE_CLIENT_SECRET}" --namespace "${AZURE_CLUSTER_IDENTITY_SECRET_NAMESPACE}"

# Finally, initialize the management cluster
clusterctl init --infrastructure azure

[Global]
api-url = <cloudstackApiUrl>
api-key = <cloudstackApiKey>
secret-key = <cloudstackSecretKey>

export CLOUDSTACK_B64ENCODED_SECRET=`cat cloud-config | base64 | tr -d '\n'`

clusterctl init --infrastructure cloudstack

export DIGITALOCEAN_ACCESS_TOKEN=<your-access-token>
export DO_B64ENCODED_CREDENTIALS="$(echo -n "${DIGITALOCEAN_ACCESS_TOKEN}" | base64 | tr -d '\n')"

# Initialize the management cluster
clusterctl init --infrastructure digitalocean

# Enable the experimental Cluster topology feature.
export CLUSTER_TOPOLOGY=true

# Initialize the management cluster
clusterctl init --infrastructure docker

export PACKET_API_KEY="34ts3g4s5g45gd45dhdh"

clusterctl init --infrastructure packet

# Create the base64 encoded credentials by catting your credentials json.
# This command uses your environment variables and encodes
# them in a value to be stored in a Kubernetes Secret.
export GCP_B64ENCODED_CREDENTIALS=$( cat /path/to/gcp-credentials.json | base64 | tr -d '\n' )

# Finally, initialize the management cluster
clusterctl init --infrastructure gcp

export IBMCLOUD_API_KEY=<you_api_key>

# Finally, initialize the management cluster
clusterctl init --infrastructure ibmcloud

clusterctl init --infrastructure ionoscloud-ionoscloud

# Initialize the management cluster
clusterctl init --infrastructure k0sproject-k0smotron

# Initialize the management cluster
clusterctl init --infrastructure kubekey

METALLB_VER=$(curl "https://api.github.com/repos/metallb/metallb/releases/latest" | jq -r ".tag_name")
kubectl apply -f "https://raw.githubusercontent.com/metallb/metallb/${METALLB_VER}/config/manifests/metallb-native.yaml"
kubectl wait pods -n metallb-system -l app=metallb,component=controller --for=condition=Ready --timeout=10m
kubectl wait pods -n metallb-system -l app=metallb,component=speaker --for=condition=Ready --timeout=2m

GW_IP=$(docker network inspect -f '{{range .IPAM.Config}}{{.Gateway}}{{end}}' kind)
NET_IP=$(echo ${GW_IP} | sed -E 's|^([0-9]+\.[0-9]+)\..*$|\1|g')
cat <<EOF | sed -E "s|172.19|${NET_IP}|g" | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: capi-ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 172.19.255.200-172.19.255.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: empty
  namespace: metallb-system
EOF

# get KubeVirt version
KV_VER=$(curl "https://api.github.com/repos/kubevirt/kubevirt/releases/latest" | jq -r ".tag_name")
# deploy required CRDs
kubectl apply -f "https://github.com/kubevirt/kubevirt/releases/download/${KV_VER}/kubevirt-operator.yaml"
# deploy the KubeVirt custom resource
kubectl apply -f "https://github.com/kubevirt/kubevirt/releases/download/${KV_VER}/kubevirt-cr.yaml"
kubectl wait -n kubevirt kv kubevirt --for=condition=Available --timeout=10m

clusterctl init --infrastructure kubevirt

# Initialize the management cluster
clusterctl init --infrastructure openstack

export OSC_SECRET_KEY=<your-secret-key>
export OSC_ACCESS_KEY=<your-access-key>
export OSC_REGION=<you-region>
# Create namespace
kubectl create namespace cluster-api-provider-outscale-system
# Create secret
kubectl create secret generic cluster-api-provider-outscale --from-literal=access_key=${OSC_ACCESS_KEY} --from-literal=secret_key=${OSC_SECRET_KEY} --from-literal=region=${OSC_REGION}  -n cluster-api-provider-outscale-system
# Initialize the management cluster
clusterctl init --infrastructure outscale

# The host for the Proxmox cluster
export PROXMOX_URL="https://pve.example:8006"
# The Proxmox token ID to access the remote Proxmox endpoint
export PROXMOX_TOKEN='root@pam!capi'
# The secret associated with the token ID
# You may want to set this in `$XDG_CONFIG_HOME/cluster-api/clusterctl.yaml` so your password is not in
# bash history
export PROXMOX_SECRET="1234-1234-1234-1234"


# Finally, initialize the management cluster
clusterctl init --infrastructure proxmox --ipam in-cluster

# Initialize the management cluster
clusterctl init --infrastructure vcd

clusterctl init --infrastructure vcluster

# Initialize the management cluster
clusterctl init --infrastructure virtink

# The username used to access the remote vSphere endpoint
export VSPHERE_USERNAME="vi-admin@vsphere.local"
# The password used to access the remote vSphere endpoint
# You may want to set this in `$XDG_CONFIG_HOME/cluster-api/clusterctl.yaml` so your password is not in
# bash history
export VSPHERE_PASSWORD="admin!23"

# Finally, initialize the management cluster
clusterctl init --infrastructure vsphere

export VULTR_API_KEY=<your_api_key>

# initialize the management cluster
clusterctl init --infrastructure vultr

The output of clusterctl init is similar to this:

Fetching providers
Installing cert-manager Version="v1.11.0"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v1.0.0" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v1.0.0" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v1.0.0" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-docker" Version="v1.0.0" TargetNamespace="capd-system"

Your management cluster has been initialized successfully!

You can now create your first workload cluster by running the following:

  clusterctl generate cluster [name] --kubernetes-version [version] | kubectl apply -f -

Create your first workload cluster

Once the management cluster is ready, you can create your first workload cluster.

Preparing the workload cluster configuration

The clusterctl generate cluster command returns a YAML template for creating a workload cluster.

Required configuration for common providers

Depending on the infrastructure provider you are planning to use, some additional prerequisites should be satisfied before configuring a cluster with Cluster API. Instructions are provided for common providers below.

Otherwise, you can look at the clusterctl generate cluster command documentation for details about how to discover the list of variables required by a cluster templates.

export LINODE_REGION=us-ord
export LINODE_TOKEN=<your linode PAT>
export LINODE_CONTROL_PLANE_MACHINE_TYPE=g6-standard-2
export LINODE_MACHINE_TYPE=g6-standard-2

export AWS_REGION=us-east-1
export AWS_SSH_KEY_NAME=default
# Select instance types
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export AWS_NODE_MACHINE_TYPE=t3.large

# Name of the Azure datacenter location. Change this value to your desired location.
export AZURE_LOCATION="centralus"

# Select VM types.
export AZURE_CONTROL_PLANE_MACHINE_TYPE="Standard_D2s_v3"
export AZURE_NODE_MACHINE_TYPE="Standard_D2s_v3"

# [Optional] Select resource group. The default value is ${CLUSTER_NAME}.
export AZURE_RESOURCE_GROUP="<ResourceGroupName>"

clusterctl generate cluster --infrastructure cloudstack --list-variables capi-quickstart

# Set this to the name of the zone in which to deploy the cluster
export CLOUDSTACK_ZONE_NAME=<zone name>
# The name of the network on which the VMs will reside
export CLOUDSTACK_NETWORK_NAME=<network name>
# The endpoint of the workload cluster
export CLUSTER_ENDPOINT_IP=<cluster endpoint address>
export CLUSTER_ENDPOINT_PORT=<cluster endpoint port>
# The service offering of the control plane nodes
export CLOUDSTACK_CONTROL_PLANE_MACHINE_OFFERING=<control plane service offering name>
# The service offering of the worker nodes
export CLOUDSTACK_WORKER_MACHINE_OFFERING=<worker node service offering name>
# The capi compatible template to use
export CLOUDSTACK_TEMPLATE_NAME=<template name>
# The ssh key to use to log into the nodes
export CLOUDSTACK_SSH_KEY_NAME=<ssh key name>

export DO_REGION=nyc1
export DO_SSH_KEY_FINGERPRINT=<your-ssh-key-fingerprint>
export DO_CONTROL_PLANE_MACHINE_TYPE=s-2vcpu-2gb
export DO_CONTROL_PLANE_MACHINE_IMAGE=<your-capi-image-id>
export DO_NODE_MACHINE_TYPE=s-2vcpu-2gb
export DO_NODE_MACHINE_IMAGE==<your-capi-image-id>

# The list of service CIDR, default ["10.128.0.0/12"]
export SERVICE_CIDR=["10.96.0.0/12"]

# The list of pod CIDR, default ["192.168.0.0/16"]
export POD_CIDR=["192.168.0.0/16"]

# The service domain, default "cluster.local"
export SERVICE_DOMAIN="k8s.test"

export POD_SECURITY_STANDARD_ENABLED="false"

# Required (made up examples shown)
# The project where your cluster will be placed to.
# You have to get one from the Equinix Metal Console if you don't have one already.
export PROJECT_ID="2b59569f-10d1-49a6-a000-c2fb95a959a1"
# This can help to take advantage of automated, interconnected bare metal across our global metros.
export METRO="da"
# What plan to use for your control plane nodes
export CONTROLPLANE_NODE_TYPE="m3.small.x86"
# What plan to use for your worker nodes
export WORKER_NODE_TYPE="m3.small.x86"
# The ssh key you would like to have access to the nodes
export SSH_KEY="ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDvMgVEubPLztrvVKgNPnRe9sZSjAqaYj9nmCkgr4PdK username@computer"
export CLUSTER_NAME="my-cluster"

# Optional (defaults shown)
export NODE_OS="ubuntu_18_04"
export POD_CIDR="192.168.0.0/16"
export SERVICE_CIDR="172.26.0.0/16"
# Only relevant if using the kube-vip flavor
export KUBE_VIP_VERSION="v0.5.0"

# Name of the GCP datacenter location. Change this value to your desired location
export GCP_REGION="<GCP_REGION>"
export GCP_PROJECT="<GCP_PROJECT>"
# Make sure to use same Kubernetes version here as building the GCE image
export KUBERNETES_VERSION=1.23.3
# This is the image you built. See https://github.com/kubernetes-sigs/image-builder
export IMAGE_ID=projects/$GCP_PROJECT/global/images/<built image>
export GCP_CONTROL_PLANE_MACHINE_TYPE=n1-standard-2
export GCP_NODE_MACHINE_TYPE=n1-standard-2
export GCP_NETWORK_NAME=<GCP_NETWORK_NAME or default>
export CLUSTER_NAME="<CLUSTER_NAME>"

# Required environment variables for VPC
# VPC region
export IBMVPC_REGION=us-south
# VPC zone within the region
export IBMVPC_ZONE=us-south-1
# ID of the resource group in which the VPC will be created
export IBMVPC_RESOURCEGROUP=<your-resource-group-id>
# Name of the VPC
export IBMVPC_NAME=ibm-vpc-0
export IBMVPC_IMAGE_ID=<you-image-id>
# Profile for the virtual server instances
export IBMVPC_PROFILE=bx2-4x16
export IBMVPC_SSHKEY_ID=<your-sshkey-id>

# Required environment variables for PowerVS
export IBMPOWERVS_SSHKEY_NAME=<your-ssh-key>
# Internal and external IP of the network
export IBMPOWERVS_VIP=<internal-ip>
export IBMPOWERVS_VIP_EXTERNAL=<external-ip>
export IBMPOWERVS_VIP_CIDR=29
export IBMPOWERVS_IMAGE_NAME=<your-capi-image-name>
# ID of the PowerVS service instance
export IBMPOWERVS_SERVICE_INSTANCE_ID=<service-instance-id>
export IBMPOWERVS_NETWORK_NAME=<your-capi-network-name>

# The token which is used to authenticate against the IONOS Cloud API
export IONOS_TOKEN=<your-token>
# The datacenter ID where the cluster will be deployed
export IONOSCLOUD_DATACENTER_ID="<your-datacenter-id>"
# The IP of the control plane endpoint
export CONTROL_PLANE_ENDPOINT_IP=10.10.10.4
# The location of the data center where the cluster will be deployed
export CONTROL_PLANE_ENDPOINT_LOCATION=de/txl 
# The image ID of the custom image that will be used for the VMs
export IONOSCLOUD_MACHINE_IMAGE_ID="<your-image-id>"
# The SSH key that will be used to access the VMs
export IONOSCLOUD_MACHINE_SSH_KEYS="<your-ssh-key>"

# Required environment variables
# The KKZONE is used to specify where to download the binaries. (e.g. "", "cn")
export KKZONE=""
# The ssh name of the all instance Linux user. (e.g. root, ubuntu)
export USER_NAME=<your-linux-user>
# The ssh password of the all instance Linux user.
export PASSWORD=<your-linux-user-password>
# The ssh IP address of the all instance. (e.g. "[{address: 192.168.100.3}, {address: 192.168.100.4}]")
export INSTANCES=<your-linux-ip-address>
# The cluster control plane VIP. (e.g. "192.168.100.100")
export CONTROL_PLANE_ENDPOINT_IP=<your-control-plane-virtual-ip>

export CAPK_GUEST_K8S_VERSION="v1.23.10"
export CRI_PATH="/var/run/containerd/containerd.sock"
export NODE_VM_IMAGE_TEMPLATE="quay.io/capk/ubuntu-2004-container-disk:${CAPK_GUEST_K8S_VERSION}"

# The URL of the kernel to deploy.
export DEPLOY_KERNEL_URL="http://172.22.0.1:6180/images/ironic-python-agent.kernel"
# The URL of the ramdisk to deploy.
export DEPLOY_RAMDISK_URL="http://172.22.0.1:6180/images/ironic-python-agent.initramfs"
# The URL of the Ironic endpoint.
export IRONIC_URL="http://172.22.0.1:6385/v1/"
# The URL of the Ironic inspector endpoint.
export IRONIC_INSPECTOR_URL="http://172.22.0.1:5050/v1/"
# Do not use a dedicated CA certificate for Ironic API. Any value provided in this variable disables additional CA certificate validation.
# To provide a CA certificate, leave this variable unset. If unset, then IRONIC_CA_CERT_B64 must be set.
export IRONIC_NO_CA_CERT=true
# Disables basic authentication for Ironic API. Any value provided in this variable disables authentication.
# To enable authentication, leave this variable unset. If unset, then IRONIC_USERNAME and IRONIC_PASSWORD must be set.
export IRONIC_NO_BASIC_AUTH=true
# Disables basic authentication for Ironic inspector API. Any value provided in this variable disables authentication.
# To enable authentication, leave this variable unset. If unset, then IRONIC_INSPECTOR_USERNAME and IRONIC_INSPECTOR_PASSWORD must be set.
export IRONIC_INSPECTOR_NO_BASIC_AUTH=true

clusterctl generate cluster --infrastructure nutanix --list-variables capi-quickstart

clusterctl generate cluster --infrastructure openstack --list-variables capi-quickstart

wget https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-openstack/master/templates/env.rc -O /tmp/env.rc
source /tmp/env.rc <path/to/clouds.yaml> <cloud>

# The list of nameservers for OpenStack Subnet being created.
# Set this value when you need create a new network/subnet while the access through DNS is required.
export OPENSTACK_DNS_NAMESERVERS=<dns nameserver>
# FailureDomain is the failure domain the machine will be created in.
export OPENSTACK_FAILURE_DOMAIN=<availability zone name>
# The flavor reference for the flavor for your server instance.
export OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR=<flavor>
# The flavor reference for the flavor for your server instance.
export OPENSTACK_NODE_MACHINE_FLAVOR=<flavor>
# The name of the image to use for your server instance. If the RootVolume is specified, this will be ignored and use rootVolume directly.
export OPENSTACK_IMAGE_NAME=<image name>
# The SSH key pair name
export OPENSTACK_SSH_KEY_NAME=<ssh key pair name>
# The external network
export OPENSTACK_EXTERNAL_NETWORK_ID=<external network ID>

# The outscale root disk iops
export OSC_IOPS="<IOPS>"
# The outscale root disk size
export OSC_VOLUME_SIZE="<VOLUME_SIZE>"
# The outscale root disk volumeType
export OSC_VOLUME_TYPE="<VOLUME_TYPE>"
# The outscale key pair
export OSC_KEYPAIR_NAME="<KEYPAIR_NAME>"
# The outscale subregion name
export OSC_SUBREGION_NAME="<SUBREGION_NAME>"
# The outscale vm type
export OSC_VM_TYPE="<VM_TYPE>"
# The outscale image name
export OSC_IMAGE_NAME="<IMAGE_NAME>"

# The node that hosts the VM template to be used to provision VMs
export PROXMOX_SOURCENODE="pve"
# The template VM ID used for cloning VMs
export TEMPLATE_VMID=100
# The ssh authorized keys used to ssh to the machines.
export VM_SSH_KEYS="ssh-ed25519 ..., ssh-ed25519 ..."
# The IP address used for the control plane endpoint
export CONTROL_PLANE_ENDPOINT_IP=10.10.10.4
# The IP ranges for Cluster nodes
export NODE_IP_RANGES="[10.10.10.5-10.10.10.50, 10.10.10.55-10.10.10.70]"
# The gateway for the machines network-config.
export GATEWAY="10.10.10.1"
# Subnet Mask in CIDR notation for your node IP ranges
export IP_PREFIX=24
# The Proxmox network device for VMs
export BRIDGE="vmbr1"
# The dns nameservers for the machines network-config.
export DNS_SERVERS="[8.8.8.8,8.8.4.4]"
# The Proxmox nodes used for VM deployments
export ALLOWED_NODES="[pve1,pve2,pve3]"

export TINKERBELL_IP=<hegel ip>

clusterctl generate cluster --infrastructure vcd --list-variables capi-quickstart

export CLUSTER_NAME=kind
export CLUSTER_NAMESPACE=vcluster
export KUBERNETES_VERSION=1.23.4
export HELM_VALUES="service:\n  type: NodePort"

clusterctl generate cluster --infrastructure virtink --list-variables capi-quickstart

# The vCenter server IP or FQDN
export VSPHERE_SERVER="10.0.0.1"
# The vSphere datacenter to deploy the management cluster on
export VSPHERE_DATACENTER="SDDC-Datacenter"
# The vSphere datastore to deploy the management cluster on
export VSPHERE_DATASTORE="vsanDatastore"
# The VM network to deploy the management cluster on
export VSPHERE_NETWORK="VM Network"
# The vSphere resource pool for your VMs
export VSPHERE_RESOURCE_POOL="*/Resources"
# The VM folder for your VMs. Set to "" to use the root vSphere folder
export VSPHERE_FOLDER="vm"
# The VM template to use for your VMs
export VSPHERE_TEMPLATE="ubuntu-1804-kube-v1.17.3"
# The public ssh authorized key on all machines
export VSPHERE_SSH_AUTHORIZED_KEY="ssh-rsa AAAAB3N..."
# The certificate thumbprint for the vCenter server
export VSPHERE_TLS_THUMBPRINT="97:48:03:8D:78:A9..."
# The storage policy to be used (optional). Set to "" if not required
export VSPHERE_STORAGE_POLICY="policy-one"
# The IP address used for the control plane endpoint
export CONTROL_PLANE_ENDPOINT_IP="1.2.3.4"

export CLUSTER_NAME=<clustername>
export KUBERNETES_VERSION=v1.28.9
export CONTROL_PLANE_MACHINE_COUNT=1
export CONTROL_PLANE_PLANID=<plan_id>
export WORKER_MACHINE_COUNT=1
export WORKER_PLANID=<plan_id>
export MACHINE_IMAGE=<snapshot_id>  
export REGION=<region>
export PLANID=<plan_id>
export VPCID=<vpc_id> 
export SSHKEY_ID=<sshKey_id>

Generating the cluster configuration

For the purpose of this tutorial, we’ll name our cluster capi-quickstart.

clusterctl generate cluster capi-quickstart --flavor development \
  --kubernetes-version v1.31.0 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

export CLUSTER_NAME=kind
export CLUSTER_NAMESPACE=vcluster
export KUBERNETES_VERSION=1.28.0
export HELM_VALUES="service:\n  type: NodePort"

kubectl create namespace ${CLUSTER_NAMESPACE}
clusterctl generate cluster ${CLUSTER_NAME} \
    --infrastructure vcluster \
    --kubernetes-version ${KUBERNETES_VERSION} \
    --target-namespace ${CLUSTER_NAMESPACE} | kubectl apply -f -

clusterctl generate cluster capi-quickstart \
  --infrastructure="kubevirt" \
  --flavor lb \
  --kubernetes-version ${CAPK_GUEST_K8S_VERSION} \
  --control-plane-machine-count=1 \
  --worker-machine-count=1 \
  > capi-quickstart.yaml

clusterctl generate cluster capi-quickstart \
  --infrastructure azure \
  --kubernetes-version v1.31.0 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

# Cluster templates authenticate with Workload Identity by default. Modify the AzureClusterIdentity for ServicePrincipal authentication.
# See https://capz.sigs.k8s.io/topics/identities for more details.
yq -i "with(. | select(.kind == \"AzureClusterIdentity\"); .spec.type |= \"ServicePrincipal\" | .spec.clientSecret.name |= \"${AZURE_CLUSTER_IDENTITY_SECRET_NAME}\" | .spec.clientSecret.namespace |= \"${AZURE_CLUSTER_IDENTITY_SECRET_NAMESPACE}\")" capi-quickstart.yaml

clusterctl generate cluster capi-quickstart \
  --kubernetes-version v1.31.0 \
  --control-plane-machine-count=3 \
  --worker-machine-count=3 \
  > capi-quickstart.yaml

This creates a YAML file named capi-quickstart.yaml with a predefined list of Cluster API objects; Cluster, Machines, Machine Deployments, etc.

The file can be eventually modified using your editor of choice.

See clusterctl generate cluster for more details.

Apply the workload cluster

When ready, run the following command to apply the cluster manifest.

kubectl apply -f capi-quickstart.yaml

The output is similar to this:

cluster.cluster.x-k8s.io/capi-quickstart created
dockercluster.infrastructure.cluster.x-k8s.io/capi-quickstart created
kubeadmcontrolplane.controlplane.cluster.x-k8s.io/capi-quickstart-control-plane created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-control-plane created
machinedeployment.cluster.x-k8s.io/capi-quickstart-md-0 created
dockermachinetemplate.infrastructure.cluster.x-k8s.io/capi-quickstart-md-0 created
kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/capi-quickstart-md-0 created

Accessing the workload cluster

The cluster will now start provisioning. You can check status with:

kubectl get cluster

You can also get an “at glance” view of the cluster and its resources by running:

clusterctl describe cluster capi-quickstart

and see an output similar to this:

NAME              PHASE         AGE   VERSION
capi-quickstart   Provisioned   8s    v1.31.0

To verify the first control plane is up:

kubectl get kubeadmcontrolplane

You should see an output is similar to this:

NAME                    CLUSTER           INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE    VERSION
capi-quickstart-g2trk   capi-quickstart   true                                 3                  3         3             4m7s   v1.31.0

After the first control plane node is up and running, we can retrieve the workload cluster Kubeconfig.

clusterctl get kubeconfig capi-quickstart > capi-quickstart.kubeconfig

kind get kubeconfig --name capi-quickstart > capi-quickstart.kubeconfig

Install a Cloud Provider

The Kubernetes in-tree cloud provider implementations are being removed in favor of external cloud providers (also referred to as “out-of-tree”). This requires deploying a new component called the cloud-controller-manager which is responsible for running all the cloud specific controllers that were previously run in the kube-controller-manager. To learn more, see this blog post.

helm install --kubeconfig=./capi-quickstart.kubeconfig --repo https://raw.githubusercontent.com/kubernetes-sigs/cloud-provider-azure/master/helm/repo cloud-provider-azure --generate-name --set infra.clusterName=capi-quickstart --set cloudControllerManager.clusterCIDR="192.168.0.0/16"

cat > cloud.conf <<EOF
[Global]
auth-url=<your_auth_url>
application-credential-id=<your_credential_id>
application-credential-secret=<your_credential_secret>
region=<your_region>
domain-name=<your_domain_name>
EOF

kubectl --kubeconfig=./capi-quickstart.kubeconfig -n kube-system create secret generic cloud-config --from-file=cloud.conf

kubectl apply --kubeconfig=./capi-quickstart.kubeconfig -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/cloud-controller-manager-roles.yaml
kubectl apply --kubeconfig=./capi-quickstart.kubeconfig -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/cloud-controller-manager-role-bindings.yaml
kubectl apply --kubeconfig=./capi-quickstart.kubeconfig -f https://raw.githubusercontent.com/kubernetes/cloud-provider-openstack/master/manifests/controller-manager/openstack-cloud-controller-manager-ds.yaml

Deploy a CNI solution

Calico is used here as an example.

helm repo add projectcalico https://docs.tigera.io/calico/charts --kubeconfig=./capi-quickstart.kubeconfig && \
helm install calico projectcalico/tigera-operator --kubeconfig=./capi-quickstart.kubeconfig -f https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-azure/main/templates/addons/calico/values.yaml --namespace tigera-operator --create-namespace

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes

kubectl get vm

NAME                                  AGE    STATUS    READY
capi-quickstart-control-plane-7s945   167m   Running   True
capi-quickstart-md-0-zht5j            164m   Running   True

kubectl get vmi

NAME                                  AGE    PHASE     IP             NODENAME             READY
capi-quickstart-control-plane-7s945   167m   Running   10.244.82.16   kind-control-plane   True
capi-quickstart-md-0-zht5j            164m   Running   10.244.82.17   kind-control-plane   True

curl https://raw.githubusercontent.com/projectcalico/calico/v3.24.4/manifests/calico.yaml -o calico-workload.yaml

sed -i -E 's|^( +)# (- name: CALICO_IPV4POOL_CIDR)$|\1\2|g;'\
's|^( +)# (  value: )"192.168.0.0/16"|\1\2"10.243.0.0/16"|g;'\
'/- name: CLUSTER_TYPE/{ n; s/( +value: ").+/\1k8s"/g };'\
'/- name: CALICO_IPV4POOL_IPIP/{ n; s/value: "Always"/value: "Never"/ };'\
'/- name: CALICO_IPV4POOL_VXLAN/{ n; s/value: "Never"/value: "Always"/};'\
'/# Set Felix endpoint to host default action to ACCEPT./a\            - name: FELIX_VXLANPORT\n              value: "6789"' \
calico-workload.yaml

kubectl --kubeconfig=./capi-quickstart.kubeconfig create -f calico-workload.yaml

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes

kubectl --kubeconfig=./capi-quickstart.kubeconfig \
  apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml

kubectl --kubeconfig=./capi-quickstart.kubeconfig get nodes

NAME                                          STATUS   ROLES           AGE    VERSION
capi-quickstart-vs89t-gmbld                   Ready    control-plane   5m33s  v1.31.0
capi-quickstart-vs89t-kf9l5                   Ready    control-plane   6m20s  v1.31.0
capi-quickstart-vs89t-t8cfn                   Ready    control-plane   7m10s  v1.31.0
capi-quickstart-md-0-55x6t-5649968bd7-8tq9v   Ready    <none>          6m5s   v1.31.0
capi-quickstart-md-0-55x6t-5649968bd7-glnjd   Ready    <none>          6m9s   v1.31.0
capi-quickstart-md-0-55x6t-5649968bd7-sfzp6   Ready    <none>          6m9s   v1.31.0

Clean Up

Delete workload cluster.

kubectl delete cluster capi-quickstart

Delete management cluster

kind delete cluster

Next steps

• Create a second workload cluster. Simply follow the steps outlined above, but remember to provide a different name for your second workload cluster.
• Deploy applications to your workload cluster. Use the CNI deployment steps for pointers.
• See the clusterctl documentation for more detail about clusterctl supported actions.

AWS Machine Images for CAPA Clusters

CAPA requires a “machine image” containing pre-installed, matching versions of kubeadm and kubelet.

EKS Clusters

For an EKS cluster the default behaviour is to retieve the AMI to use from SSM. This is so the recommended Amazon Linux AMI is used (see here).

Instead of using the auto resolved AMIs an appropriate custom image ID for the Kubernetes version can be set in AWSMachineTemplate spec.

Non-EKS Clusters

By default the machine image is auto-resolved by CAPA to a public AMI that matches the Kubernetes version in KubeadmControlPlane or MachineDeployment spec. These AMIs are published in a community owned AWS account. See pre-built public AMIs for details of the CAPA project published images.

IMPORTANT: The project doesn’t recommend using the public AMIs for production use. Instead its recommended that you build your own AMIs for the Kubernetes versions you want to use. The AMI can then be specified in the AWSMachineTemplate spec. Custom images can be created using image-builder project.

Pre-built Kubernetes AMIs

New AMIs are built on a best effort basis when a new Kubernetes version is released for each supported OS distribution and then published to supported regions.

AMI Publication Policy

• AMIs should only be used for non-production usage. For production environments we recommend that you build and maintain your own AMIs using the image-builder project.
• AMIs will only be published for the latest release series and 2 previous release series. For example, if the current release series is v1.30 then AMIs will only be published for v1.30, v1.29, v1.28.
• When there is a new k8s release series then any AMIs no longer covered by the previous point will be deleted. For example, when v1.31.0 is published then any AMIs for the v1.28 release series will be deleted.
• Existing AMIs are not updated for security fixes and it is recommended to always use the latest patch version for the Kubernetes version you want to run.

NOTE: As the old community images were located in an AWS account that the project no longer has access to and because those AMIs have been automatically deleted, we have started publishing images again starting from Kubernetes v1.29.9.

Finding AMIs

clusterawsadm ami list command lists pre-built reference AMIs by Kubernetes version, OS, or AWS region. See clusterawsadm ami list for details.

If you are using a version of clusterawsadm prior to v2.6.2 then you will need to explicitly specify the owner-id for the community account: clusterawsadm ami list --owner-id 819546954734.

Supported OS Distributions

• Ubuntu (ubuntu-22.04, ubuntu-24.04)
• Flatcar (flatcar-stable)

Note: Centos (centos-7) and Amazon Linux 2 (amazon-2) where supported but there are some issues with the AMI build that need fixing. See this issue for details.

Supported AWS Regions

• ap-northeast-1
• ap-northeast-2
• ap-south-1
• ap-southeast-1
• ap-southeast-2
• ca-central-1
• eu-central-1
• eu-west-1
• eu-west-2
• eu-west-3
• sa-east-1
• us-east-1
• us-east-2
• us-west-1
• us-west-2

Custom Kubernetes AMIs

Cluster API uses the Kubernetes Image Builder tools. You should use the AWS images from that project as a starting point for your custom image.

The Image Builder Book explains how to build the images defined in that repository, with instructions for AWS CAPI Images in particular.

Operating system requirements

For custom images to work with Cluster API, it must meet the operating system requirements of the bootstrap provider. For example, the default kubeadm bootstrap provider has a set of [preflight checks][kubeadm-preflight-checks] that a VM is expected to pass before it can join the cluster.

Kubernetes version requirements

The pre-built public images are each built to support a specific version of Kubernetes. When using custom images, make sure to match the image to the version: field of the KubeadmControlPlane and MachineDeployment in the YAML template for your workload cluster.

To upgrade to a new Kubernetes release with custom images requires this preparation:

• create a new custom image which supports the Kubernetes release version
• copy the existing AWSMachineTemplate and change its ami: section to reference the new custom image
• create the new AWSMachineTemplate on the management cluster
• modify the existing KubeadmControlPlane and MachineDeployment to reference the new AWSMachineTemplate and update the version: field to match

See Upgrading workload clusters for more details.

Creating a cluster from a custom image

To use a custom image, it needs to be referenced in an ami: section of your AWSMachineTemplate.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
metadata:
  name: capa-image-id-example
  namespace: default
spec:
  template:
    spec:
      ami:
        id: ami-09709369c53539c11
      iamInstanceProfile: control-plane.cluster-api-provider-aws.sigs.k8s.io
      instanceType: m5.xlarge
      sshKeyName: default

Topics

Using clusterawsadm to fulfill prerequisites

Requirements

• Linux or MacOS (Windows isn’t supported at the moment).
• AWS credentials.
• AWS CLI
• jq

IAM resources

With clusterawsadm

Get the latest clusterawsadm and place it in your path.

Cluster API Provider AWS ships with clusterawsadm, a utility to help you manage IAM objects for this project.

In order to use clusterawsadm you must have an administrative user in an AWS account. Once you have that administrator user you need to set your environment variables:

• AWS_REGION
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN (if you are using Multi-factor authentication)

After these are set run this command to get you up and running:

clusterawsadm bootstrap iam create-cloudformation-stack

Additional policies can be added by creating a configuration file

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  controlPlane:
    extraPolicyAttachments:
      - arn:aws:iam::<AWS_ACCOUNT>:policy/my-policy
      - arn:aws:iam::aws:policy/AmazonEC2FullAccess
  nodes:
    extraPolicyAttachments:
      - arn:aws:iam::<AWS_ACCOUNT>:policy/my-other-policy

and passing it to clusterawsadm as follows

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-config.yaml

These will be added to the control plane and node roles respectively when they are created.

Note: If you used the now deprecated clusterawsadm alpha bootstrap 0.5.4 or earlier to create IAM objects for the Cluster API Provider for AWS, using clusterawsadm bootstrap iam 0.5.5 or later will, by default, remove the bootstrap user and group. Anything using those credentials to authenticate will start experiencing authentication failures. If you rely on the bootstrap user and group credentials, specify bootstrapUser.enable = true in the configuration file, like this:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true

With EKS Support

The pre-requisities for EKS are enabled by default. However, if you want to use some of the optional features of EKS (see here for more information on what these are) then you will need to enable these features via the configuration file. For example:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks:
    iamRoleCreation: false # Set to true if you plan to use the EKSEnableIAM feature flag to enable automatic creation of IAM roles
    managedMachinePool:
      disable: false # Set to false to enable creation of the default node role for managed machine pools
    fargate:
      disable: false # Set to false to enable creation of the default role for the fargate profiles

and then use that configuration file:

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-config.yaml

Enabling EventBridge Events

To enable EventBridge instance state events, additional permissions must be granted along with enabling the feature-flag. Additional permissions for events and queue management can be enabled through the configuration file as follows:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  ...
  eventBridge:
    enable: true
  ...

Cross Account Role Assumption

CAPA, by default, does not provide the necessary permissions to allow cross-account role assumption, which can be used to manage clusters in other environments. This is documented here. The ‘sts:AssumeRole’ permissions can be added via the following configuration on the manager account configuration:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  ...
  allowAssumeRole: true
  ...

The above will give the controller to have the necessary permissions needed in order for it to manage clusters in other accounts using the AWSClusterRoleIdentity. Please note, the above should only be applied to the account where CAPA is running. To allow CAPA to assume the roles in the managed/target accounts, the following configuration needs to be used:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  ...
  clusterAPIControllers:
    disabled: false
    trustStatements:
    - Action:
      - "sts:AssumeRole"
      Effect: "Allow"
      Principal:
        AWS:
        - "arn:aws:iam::<manager account>:role/controllers.cluster-api-provider-aws.sigs.k8s.io"
  ...

Without clusterawsadm

This is not a recommended route as the policies are very specific and will change with new features.

If you do not wish to use the clusteradwsadm tool then you will need to understand exactly which IAM policies and groups we are expecting. There are several policies, roles and users that need to be created. Please see our controller policy file to understand the permissions that are necessary.

You can use clusteradwadm to print out the needed IAM policies, e.g.

clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap-config.yaml

SSH Key pair

If you plan to use SSH to access the instances created by Cluster API Provider AWS then you will need to specify the name of an existing SSH key pair within the region you plan on using. If you don’t have one yet, a new one needs to be created.

Create a new key pair

# Save the output to a secure location
aws ec2 create-key-pair --key-name default --output json | jq .KeyMaterial -r
-----BEGIN RSA PRIVATE KEY-----
[... contents omitted ...]
-----END RSA PRIVATE KEY-----

If you want to save the private key directly into AWS Systems Manager Parameter Store with KMS encryption for security, you can use the following command:

aws ssm put-parameter --name "/sigs.k8s.io/cluster-api-provider-aws/ssh-key" \
  --type SecureString \
  --value "$(aws ec2 create-key-pair --key-name default --output json | jq .KeyMaterial -r)"

Adding an existing public key to AWS

# Replace with your own public key
aws ec2 import-key-pair \
  --key-name default \
  --public-key-material "$(cat ~/.ssh/id_rsa.pub)"

NB: Only RSA keys are supported by AWS.

Setting up the environment

The current iteration of the Cluster API Provider AWS relies on credentials being present in your environment. These then get written into the cluster manifests for use by the controllers.

E.g.

export AWS_REGION=us-east-1 # This is used to help encode your environment variables
export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_SESSION_TOKEN=<session-token> # If you are using Multi-Factor Auth.

Note: The credentials used must have the appropriate permissions for use by the controllers. You can get the required policy statement by using the following command:

clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap-config.yaml

To save credentials securely in your environment, aws-vault uses the OS keystore as permanent storage, and offers shell features to securely expose and setup local AWS environments.

Accessing cluster instances

Overview

After running clusterctl generate cluster to generate the configuration for a new workload cluster (and then redirecting that output to a file for use with kubectl apply, or piping it directly to kubectl apply), the new workload cluster will be deployed. This document explains how to access the new workload cluster’s nodes.

Prerequisites

1. clusterctl generate cluster was successfully executed to generate the configuration for a new workload cluster
2. The configuration for the new workload cluster was applied to the management cluster using kubectl apply and the cluster is up and running in an AWS environment.
3. The SSH key referenced by clusterctl in step 1 exists in AWS and is stored in the correct location locally for use by SSH (on macOS/Linux systems, this is typically $HOME/.ssh). This document will refer to this key as cluster-api-provider-aws.sigs.k8s.io.
4. (If using AWS Session Manager) The AWS CLI and the Session Manager plugin have been installed and configured.

Methods for accessing nodes

There are two ways to access cluster nodes once the workload cluster is up and running:

• via SSH
• via AWS Session Manager

Accessing nodes via SSH

By default, workload clusters created in AWS will not support access via SSH apart from AWS Session Manager (see the section titled “Accessing nodes via AWS Session Manager”). However, the manifest for a workload cluster can be modified to include an SSH bastion host, created and managed by the management cluster, to enable SSH access to cluster nodes. The bastion node is created in a public subnet and provides SSH access from the world. It runs the official Ubuntu Linux image.

Enabling the bastion host

To configure the Cluster API Provider for AWS to create an SSH bastion host, add this line to the AWSCluster spec:

spec:
  bastion:
    enabled: true

If this field is set and a specific AMI ID is not provided for the bastion (by setting spec.bastion.ami) then by default the latest AMI(Ubuntu 20.04 LTS OS) is looked up from Ubuntu cloud images by CAPA controller and used in bastion host creation.

Obtain public IP address of the bastion node

Once the workload cluster is up and running after being configured for an SSH bastion host, you can use the kubectl get awscluster command to look up the public IP address of the bastion host (make sure the kubectl context is set to the management cluster). The output will look something like this:

NAME   CLUSTER   READY   VPC                     BASTION IP
test   test      true    vpc-1739285ed052be7ad   1.2.3.4

Setting up the SSH key path

Assumming that the cluster-api-provider-aws.sigs.k8s.io SSH key is stored in $HOME/.ssh/cluster-api-provider-aws, use this command to set up an environment variable for use in a later command:

export CLUSTER_SSH_KEY=$HOME/.ssh/cluster-api-provider-aws

Get private IP addresses of nodes in the cluster

To get the private IP addresses of nodes in the cluster (nodes may be control plane nodes or worker nodes), use this kubectl command with the context set to the management cluster:

kubectl get nodes -o custom-columns=NAME:.metadata.name,\
IP:"{.status.addresses[?(@.type=='InternalIP')].address}"

This will produce output that looks like this:

NAME                                         IP
ip-10-0-0-16.us-west-2.compute.internal   10.0.0.16
ip-10-0-0-68.us-west-2.compute.internal   10.0.0.68

The above command returns IP addresses of the nodes in the cluster. In this case, the values returned are 10.0.0.16 and 10.0.0.68.

Connecting to the nodes via SSH

To access one of the nodes (either a control plane node or a worker node) via the SSH bastion host, use this command if you are using a non-EKS cluster:

ssh -i ${CLUSTER_SSH_KEY} ubuntu@<NODE_IP> \
	-o "ProxyCommand ssh -W %h:%p -i ${CLUSTER_SSH_KEY} ubuntu@${BASTION_HOST}"

And use this command if you are using a EKS based cluster:

ssh -i ${CLUSTER_SSH_KEY} ec2-user@<NODE_IP> \
	-o "ProxyCommand ssh -W %h:%p -i ${CLUSTER_SSH_KEY} ubuntu@${BASTION_HOST}"

If the whole document is followed, the value of <NODE_IP> will be either 10.0.0.16 or 10.0.0.68.

Alternately, users can add a configuration stanza to their SSH configuration file (typically found on macOS/Linux systems as $HOME/.ssh/config):

Host 10.0.*
  User ubuntu
  IdentityFile <CLUSTER_SSH_KEY>
  ProxyCommand ssh -W %h:%p ubuntu@<BASTION_HOST>

Accessing nodes via AWS Session Manager

All CAPA-published AMIs based on Ubuntu have the AWS SSM Agent pre-installed (as a Snap package; this was added in June 2018 to the base Ubuntu Server image for all 16.04 and later AMIs). This allows users to access cluster nodes directly, without the need for an SSH bastion host, using the AWS CLI and the Session Manager plugin.

To access a cluster node (control plane node or worker node), you’ll need the instance ID. You can retrieve the instance ID using this kubectl command with the context set to the management cluster:

kubectl get awsmachines -o custom-columns=NAME:.metadata.name,INSTANCEID:.spec.providerID

This will produce output similar to this:

NAME                      INSTANCEID
test-controlplane-52fhh   aws:////i-112bac41a19da1819
test-controlplane-lc5xz   aws:////i-99aaef2381ada9228

Users can then use the instance ID (everything after the aws://// prefix) to connect to the cluster node with this command:

aws ssm start-session --target <INSTANCE_ID>

This will log you into the cluster node as the ssm-user user ID.

Additional Notes

Using the AWS CLI instead of kubectl

It is also possible to use AWS CLI commands instead of kubectl to gather information about the cluster nodes.

For example, to use the AWS CLI to get the public IP address of the SSH bastion host, use this AWS CLI command:

export BASTION_HOST=$(aws ec2 describe-instances --filter='Name=tag:Name,Values=<CLUSTER_NAME>-bastion' \
	| jq '.Reservations[].Instances[].PublicIpAddress' -r)

You should substitute the correct cluster name for <CLUSTER_NAME> in the above command. (NOTE: If make manifests was used to generate manifests, by default the <CLUSTER_NAME> is set to test1.)

Similarly, to obtain the list of private IP addresses of the cluster nodes, use this AWS CLI command:

for type in control-plane node
do
	aws ec2 describe-instances \
    --filter="Name=tag:sigs.k8s.io/cluster-api-provider-aws/role,\
    Values=${type}" \
		| jq '.Reservations[].Instances[].PrivateIpAddress' -r
done
10.0.0.16
10.0.0.68

Finally, to obtain AWS instance IDs for cluster nodes, you can use this AWS CLI command:

for type in control-plane node
do
	aws ec2 describe-instances \
    --filter="Name=tag:sigs.k8s.io/cluster-api-provider-aws/role,\
    Values=${type}" \
		| jq '.Reservations[].Instances[].InstanceId' -r
done
i-112bac41a19da1819
i-99aaef2381ada9228

Note that your AWS CLI must be configured with credentials that enable you to query the AWS EC2 API.

Spot Instances

AWS Spot Instances allows user to reduce the costs of their compute resources by utilising AWS spare capacity for a lower price.

Because Spot Instances are tightly integrated with AWS services such as Auto Scaling, ECS and CloudFormation, users can choose how to launch and maintain their applications running on Spot Instances.

Although, with this lower cost, comes the risk of preemption. When capacity within a particular Availability Zone is increased, AWS may need to reclaim Spot instances to satisfy the demand on their data centres.

When to use spot instances?

Spot instances are ideal for workloads that can be interrupted. For example, short jobs or stateless services that can be rescheduled quickly, without data loss, and resume operation with limited degradation to a service.

Using Spot Instances with AWSMachine

To enable AWS Machine to be backed by a Spot Instance, users need to add spotMarketOptions to AWSMachineTemplate:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
metadata:
  name: ${CLUSTER_NAME}-md-0
spec:
  template:
    spec:
      iamInstanceProfile: nodes.cluster-api-provider-aws.sigs.k8s.io
      instanceType: ${AWS_NODE_MACHINE_TYPE}
      spotMarketOptions:
        maxPrice: ""
      sshKeyName: ${AWS_SSH_KEY_NAME}

Users may also add a maxPrice to the options to limit the maximum spend for the instance. It is however, recommended not to set a maxPrice as AWS will cap your spending at the on-demand price if this field is left empty, and you will experience fewer interruptions.

spec:
  template:
    spotMarketOptions:
      maxPrice: 0.02 # Price in USD per hour (up to 5 decimal places)

Using Spot Instances with AWSManagedMachinePool

To use spot instance in EKS managed node groups for a EKS cluster, set capacityType to spot in AWSManagedMachinePool.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSManagedMachinePool
metadata:
  name: ${CLUSTER_NAME}-pool-0
spec:
  capacityType: spot
  ...

See AWS doc for more details.

Using Spot Instances with AWSMachinePool

To enable AWSMachinePool to be backed by a Spot Instance, users need to add spotMarketOptions to AWSLaunchTemplate:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachinePool
metadata:
  name: ${CLUSTER_NAME}-mp-0
spec:
  minSize: 1
  maxSize: 4
  awsLaunchTemplate:
    instanceType: "${AWS_CONTROL_PLANE_MACHINE_TYPE}"
    iamInstanceProfile: "nodes.cluster-api-provider-aws.sigs.k8s.io"
    sshKeyName: "${AWS_SSH_KEY_NAME}"
    spotMarketOptions:
       maxPrice: ""

IMPORTANT WARNING: The experimental feature AWSMachinePool supports using spot instances, but the graceful shutdown of machines in AWSMachinePool is not supported and has to be handled externally by users.

MachinePools

• Feature status: Experimental
• Feature gate: MachinePool=true

MachinePool allows users to manage many machines as a single entity. Infrastructure providers implement a separate CRD that handles infrastructure side of the feature.

AWSMachinePool

Cluster API Provider AWS (CAPA) has experimental support for MachinePool though the infrastructure type AWSMachinePool. An AWSMachinePool corresponds to an AWS AutoScaling Groups, which provides the cloud provider specific resource for orchestrating a group of EC2 machines.

The AWSMachinePool controller creates and manages an AWS AutoScaling Group using launch templates so users don’t have to manage individual machines. You can use Autoscaling health checks for replacing instances and it will maintain the number of instances specified.

Using clusterctl to deploy

To deploy a MachinePool / AWSMachinePool via clusterctl generate there’s a flavor for that.

Make sure to set up your AWS environment as described here.

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws
clusterctl generate cluster my-cluster --kubernetes-version v1.25.0 --flavor machinepool > my-cluster.yaml

The template used for this flavor is located here.

AWSManagedMachinePool

Cluster API Provider AWS (CAPA) has experimental support for EKS Managed Node Groups using MachinePool through the infrastructure type AWSManagedMachinePool. An AWSManagedMachinePool corresponds to an AWS AutoScaling Groups that is used for an EKS managed node group. .

The AWSManagedMachinePool controller creates and manages an EKS managed node group which in turn manages an AWS AutoScaling Group of managed EC2 instance types.

To use the managed machine pools certain IAM permissions are needed. The easiest way to ensure the required IAM permissions are in place is to use clusterawsadm to create them. To do this, follow the EKS instructions in using clusterawsadm to fulfill prerequisites.

Using clusterctl to deploy

To deploy an EKS managed node group using AWSManagedMachinePool via clusterctl generate you can use a flavor.

Make sure to set up your AWS environment as described here.

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws
clusterctl generate cluster my-cluster --kubernetes-version v1.22.0 --flavor eks-managedmachinepool > my-cluster.yaml

The template used for this flavor is located here.

Examples

Example: MachinePool, AWSMachinePool and KubeadmConfig Resources

Below is an example of the resources needed to create a pool of EC2 machines orchestrated with an AWS Auto Scaling Group.

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: capa-mp-0
spec:
  clusterName: capa
  replicas: 2
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfig
          name: capa-mp-0
      clusterName: capa
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachinePool
        name: capa-mp-0
      version: v1.25.0
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachinePool
metadata:
  name: capa-mp-0
spec:
  minSize: 1
  maxSize: 10
  availabilityZones:
    - "${AWS_AVAILABILITY_ZONE}"
  awsLaunchTemplate:
    instanceType: "${AWS_CONTROL_PLANE_MACHINE_TYPE}"
    sshKeyName: "${AWS_SSH_KEY_NAME}"
  subnets:
    - id : "${AWS_SUBNET_ID}"
---
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfig
metadata:
  name: capa-mp-0
  namespace: default
spec:
  joinConfiguration:
    nodeRegistration:
      name: '{{ ds.meta_data.local_hostname }}'
      kubeletExtraArgs:
        cloud-provider: aws

Autoscaling

cluster-autoscaler can be used to scale MachinePools up and down. Two providers are possible to use with CAPA MachinePools: clusterapi, or aws.

If the AWS autoscaler provider is used, each MachinePool needs to have an annotation set to prevent scale up/down races between cluster-autoscaler and cluster-api. Example:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: capa-mp-0
  annotations:
    cluster.x-k8s.io/replicas-managed-by: "external-autoscaler"
spec:
  clusterName: capa
  replicas: 2
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfig
          name: capa-mp-0
      clusterName: capa
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachinePool
        name: capa-mp-0
      version: v1.25.0

When using GitOps, make sure to ignore differences in spec.replicas on MachinePools. Example when using ArgoCD:

  ignoreDifferences:
    - group: cluster.x-k8s.io
      kind: MachinePool
      jsonPointers:
        - /spec/replicas

Multi-tenancy

Starting from v0.6.5, single controller multi-tenancy is supported that allows using a different AWS Identity for each workload cluster. For details, see the multi-tenancy proposal.

For multi-tenancy support, a reference field (identityRef) is added to AWSCluster, which informs the controller of which identity to be used when reconciling the cluster. If the identity provided exists in a different AWS account, this is the mechanism which informs the controller to provision a cluster in a different account. Identities should have adequate permissions for CAPA to reconcile clusters.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: <IdentityType>
    name: <IdentityName>

Identity resources are used to describe IAM identities that will be used during reconciliation. There are three identity types: AWSClusterControllerIdentity, AWSClusterStaticIdentity, and AWSClusterRoleIdentity. Once an IAM identity is created in AWS, the corresponding values should be used to create a identity resource.

AWSClusterControllerIdentity

Before multi-tenancy support, all AWSClusters were being reconciled using the credentials that are used by Cluster API Provider AWS Controllers. AWSClusterControllerIdentity is used to restrict the usage of controller credentials only to AWSClusters that are in allowedNamespaces. Since CAPA controllers use a single set of credentials, AWSClusterControllerIdentity is a singleton, and can only be created with name: default.

For backward compatibility, AutoControllerIdentityCreator experimental feature is added, which is responsible to create the AWSClusterControllerIdentity singleton if it does not exist.

• Feature status: Experimental
• Feature gate: AutoControllerIdentityCreator=true AutoControllerIdentityCreator creates AWSClusterControllerIdentity singleton with empty allowedNamespaces (allowedNamespaces: {}) to grant access to the AWSClusterControllerIdentity from all namespaces.

Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterControllerIdentity
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
metadata:
  name: "default"
spec:
  allowedNamespaces: {}  # matches all namespaces

AWSClusterControllerIdentity is immutable to avoid any unwanted overrides to the allowed namespaces, especially during upgrading clusters.

AWSClusterStaticIdentity

AWSClusterStaticIdentity represents static AWS credentials, which are stored in a Secret.

Example: Below, an AWSClusterStaticIdentity is created that allows access to the AWSClusters that are in “test” namespace. The identity credentials that will be used by “test” AWSCluster are stored in “test-account-creds” secret.

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterStaticIdentity
    name: test-account
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterStaticIdentity
metadata:
  name: "test-account"
spec:
  secretRef: test-account-creds
  allowedNamespaces:
    selector:
      matchLabels:
        cluster.x-k8s.io/ns: "testlabel"
---
apiVersion: v1
kind: Namespace
metadata:
  labels:
    cluster.x-k8s.io/ns: "testlabel"
  name: "test"
---
apiVersion: v1
kind: Secret
metadata:
  name: "test-account-creds"
  namespace: capa-system
stringData:
 AccessKeyID: AKIAIOSFODNN7EXAMPLE
 SecretAccessKey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

AWSClusterRoleIdentity

AWSClusterRoleIdentity allows CAPA to assume a role either in the same or another AWS account, using the STS::AssumeRole API. The assumed role could be used by the AWSClusters that is in the allowedNamespaces.

Example: Below, an AWSClusterRoleIdentity instance, which will be used by AWSCluster “test”, is created. This role will be assumed by the source identity at runtime. Source identity can be of any identity type. Role is assumed in the beginning once and after, whenever the assumed role’s credentials are expired.

This snippet illustrates the connection between AWSClusterand the AWSClusterRoleIdentity, however this is not a working example. Please view a full example below.

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test"
  namespace: "test"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterRoleIdentity
    name: test-account-role
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: "test-account-role"
spec:
  allowedNamespaces:
  - "test" # allows only "test" namespace to use this identity
  roleARN: "arn:aws:iam::123456789:role/CAPARole"
  sourceIdentityRef:
    kind: AWSClusterControllerIdentity # use the singleton for root auth
    name: default

Nested role assumption is also supported. Example: Below, “multi-tenancy-nested-role” will be assumed by “multi-tenancy-role”, which will be assumed by the “default” AWSClusterControllerIdentity

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: multi-tenancy-role
spec:
  allowedNamespaces:
    list: []
  durationSeconds: 900 # default and min value is 900 seconds
  roleARN: arn:aws:iam::11122233344:role/multi-tenancy-role
  sessionName: multi-tenancy-role-session
  sourceIdentityRef:
    kind: AWSClusterControllerIdentity
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: multi-tenancy-nested-role
spec:
  allowedNamespaces:
    list: []
  roleARN: arn:aws:iam::11122233355:role/multi-tenancy-nested-role
  sessionName: multi-tenancy-nested-role-session
  sourceIdentityRef:
    kind: AWSClusterRoleIdentity
    name: multi-tenancy-role

Necessary permissions for assuming a role:

There are multiple AWS assume role permissions that need to be configured in order for the assume role to work:

• The source identity (user/role specified in the source identity field) should have IAM policy permissions that enable it to perform sts:AssumeRole operation.

  {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Action": "sts:AssumeRole",
              "Resource": "*"
          }
      ]
  }
  

• The target role (can be in a different AWS account) must be configured to allow the source user/role (or all users in an AWS account) to assume into it by setting a trust policy:

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
          // "AWS": "arn:aws:iam::111111111111:role/role-used-during-cluster-bootstrap"
      },
      "Action": "sts:AssumeRole"
    }
  ]
  }
  

Both of these permissions can be enabled via clusterawsadm as documented here.

Examples

This is a deployable example which uses the AWSClusterRoleIdentity “test-account-role” to assume into the arn:aws:iam::123456789:role/CAPARole role in the target account. This example assumes that the CAPARole has already been configured in the target account.

Finally, we inform the Cluster to use our AWSClustertype to provision a cluster in the target account specified by the identityRef section.

Note

By default the AutoControllerIdentityCreator=true feature gate is set to true here. If this is not enabled for your cluster, you will need to enable the flag, or create your own default AWSClusterControllerIdentity.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
metadata:
  name: "default"
spec:
  allowedNamespaces: {}  # matches all namespaces

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: "test-account-role"
spec:
  allowedNamespaces: {} # matches all namespaces
  roleARN: "arn:aws:iam::123456789:role/CAPARole"
  sourceIdentityRef:
    kind: AWSClusterControllerIdentity # use the singleton for root auth
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
metadata:
  name: "test-multi-tenant-workload"
spec:
  region: "eu-west-1"
  identityRef:
    kind: AWSClusterRoleIdentity
    name: test-account-role
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: "test-multi-tenant-workload"
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: "test-multi-tenant-workload"

More specific examples can be referenced from the existing templates directory.

In order to use the EC2 template with identity type, you can add the identityRef section to kind: AWSCluster spec section in the template. If you do not, CAPA will automatically add the default identity provider (which is usually your local account credentials).

Similarly, to use the EKS template with identity type, you can add the identityRef section to kind: AWSManagedControlPlane spec section in the template. If you do not, CAPA will automatically add the default identity provider (which is usually your local account credentials).

Secure Access to Identities

allowedNamespaces field is used to grant access to the namespaces to use Identities. Only AWSClusters that are created in one of the Identity’s allowed namespaces can use that Identity. allowedNamespaces are defined by providing either a list of namespaces or label selector to select namespaces.

Examples

An empty allowedNamespaces indicates that the Identity can be used by all namespaces.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:{}  # matches all namespaces

Having a nil list and a nil selector is the same with having an empty allowedNamespaces (Identity can be used by all namespaces).

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:
    list: nil
    selector: nil

A nil allowedNamespaces indicates that the Identity cannot be used from any namespace.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:  # this is same with not providing the field at all or allowedNamespaces: null

The union of namespaces that are matched by selector and the namespaces that are in the list is granted access to the identity. The namespaces that are not in the list and not matching the selector will not have access.

Nil or empty list matches no namespaces. Nil or empty selector matches no namespaces. If list is nil and selector is empty OR list is empty and selector is nil, Identity cannot be used from any namespace. Because in this case, allowedNamespaces is not empty or nil, and neither list nor selector allows any namespaces, so the union is empty.

# Matches no namespaces
allowedNamespaces:
  list: []

# Matches no namespaces
allowedNamespaces:
  selector: {}

# Matches no namespaces
allowedNamespaces:
  list: null
  selector: {}

# Matches no namespaces
allowedNamespaces:
  list: []
  selector: {}

Important The default behaviour of an empty label selector is to match all objects, however here we do not follow that behavior to avoid unintended access to the identities. This is consistent with core cluster API selectors, e.g., Machine and ClusterResourceSet selectors. The result of matchLabels and matchExpressions are ANDed.

In Kubernetes selectors, matchLabels and matchExpressions are ANDed. In the example below, list is empty/nil, so does not allow any namespaces and selector matches with only default namespace. Since list and selector results are ORed, default namespace can use this identity.

kind: namespace
metadata:
  name: default
  labels:
    environment: dev
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
spec:
  allowedNamespaces:
    list: null # or []
    selector:
      matchLabels:
        namespace: default
      matchExpressions:
        - {key: environment, operator: In, values: [dev]}

Multitenancy setup with EKS and Service Account

See multitenancy for more details on enabling the functionality and the various options you can use.

In this example, we are going to see how to create the following architecture with cluster API:

                                  AWS Account 1
                                 +--------------------+
                                 |                    |
                 +---------------+->EKS - (Managed)   |
                 |               |                    |
                 |               +--------------------+
 AWS Account 0   |                AWS Account 2
+----------------+---+           +--------------------+
|                |   |           |                    |
|  EKS - (Manager)---+-----------+->EKS - (Managed)   |
|                |   |           |                    |
+----------------+---+           +--------------------+
                 |                AWS Account 3
                 |               +--------------------+
                 |               |                    |
                 +---------------+->EKS - (Managed)   |
                                 |                    |
                                 +--------------------+

And specifically, we will only include:

• AWS Account 0 (aka Manager account used by management cluster where cluster API controllers reside)
• AWS Account 1 (aka Managed account used for EKS-managed workload clusters)

Prerequisites

• A bootstrap cluster (kind)
• AWS CLI installed
• 2 (or more) AWS accounts
• clusterawsadm
• clusterctl

Set variables

Note: the credentials below are the ones of the manager account

Export the following environment variables:

• AWS_REGION
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN (if you are using Multi-factor authentication)
• AWS_MANAGER_ACCOUNT_ID
• AWS_MANAGED_ACCOUNT_ID
• OIDC_PROVIDER_ID=”WeWillReplaceThisLater”

Prepare the manager account

As explained in the EKS prerequisites page, we need a couple of roles in the account to build the cluster, clusterawsadm CLI can take care of it.

We know that the CAPA provider in the Manager account should be able to assume roles in the Managed account (AWS Account 1).

We can create a clusterawsadm configuration that adds an inline policy to the controllers.cluster-api-provider-aws.sigs.k8s.io role.

envsubst > bootstrap-manager-account.yaml << EOL
apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks: # This section should be changed accordingly to your requirements
    iamRoleCreation: false
    managedMachinePool:
      disable: true
    fargate:
      disable: false
  clusterAPIControllers: # This is the section that really matter
    disabled: false
    extraStatements:
    - Action:
      - "sts:AssumeRole"
      Effect: "Allow"
      Resource: ["arn:aws:iam::${AWS_MANAGED_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io"]
    trustStatements:
    - Action:
      - "sts:AssumeRoleWithWebIdentity"
      Effect: "Allow"
      Principal:
        Federated:
        - "arn:aws:iam::${AWS_MANAGER_ACCOUNT_ID}:oidc-provider/oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}"
      Condition:
        "ForAnyValue:StringEquals":
          "oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}:sub":
            - system:serviceaccount:capi-providers:capa-controller-manager
            - system:serviceaccount:capa-eks-control-plane-system:capa-eks-control-plane-controller-manager # Include if also using EKS
EOL

Let’s provision the Manager role with:

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-manager-account.yaml

Manager cluster

The following commands assume you have the AWS credentials for the Manager account exposed, and your kube context is pointing to the bootstrap cluster.

Install cluster API provider in the bootstrap cluster

export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
export EKS=true
export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws --target-namespace capi-providers

Generate the cluster configuration

NOTE: You might want to update the Kubernetes and VPC addon versions to one of the available versions when running this command.

• Kubernetes versions
• VPC CNI add-on versions don’t forget to add the v prefix

export AWS_SSH_KEY_NAME=default
export VPC_ADDON_VERSION="v1.10.2-eksbuild.1"
clusterctl generate cluster manager --flavor eks-managedmachinepool-vpccni --kubernetes-version v1.20.2 --worker-machine-count=3 > manager-cluster.yaml

Apply the cluster configuration

kubectl apply -f manager-cluster.yaml

WAIT: time to have a drink, the cluster is creating and we will have to wait for it to be there before continuing.

IAM OIDC Identity provider

Follow AWS documentation to create an OIDC provider https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

Update the TrustStatement above

export OIDC_PROVIDER_ID=<OIDC_ID_OF_THE_CLUSTER>

run the Prepare the manager account step again

Get manager cluster credentials

kubectl --namespace=default get secret manager-user-kubeconfig \
   -o jsonpath={.data.value} | base64 --decode \
   > manager.kubeconfig

Install the CAPA provider in the manager cluster

Here we install the Cluster API providers into the manager cluster and create a service account to use the controllers.cluster-api-provider-aws.sigs.k8s.io role for the Management Components.

export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
export EKS=true
export EXP_MACHINE_POOL=true
export AWS_CONTROLLER_IAM_ROLE=arn:aws:iam::${AWS_MANAGER_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io
clusterctl init --kubeconfig manager.kubeconfig --infrastructure aws --target-namespace capi-providers

Managed cluster

Time to build the managed cluster for pivoting the bootstrap cluster.

Generate the cluster configuration

NOTE: As for the manager cluster you might want to update the Kubernetes and VPC addon versions.

export AWS_SSH_KEY_NAME=default
export VPC_ADDON_VERSION="v1.10.2-eksbuild.1"
clusterctl generate cluster managed --flavor eks-managedmachinepool-vpccni --kubernetes-version v1.20.2 --worker-machine-count=3 > managed-cluster.yaml

Edit the file and add the following to the AWSManagedControlPlane resource spec to point the controller to the manager account when creating the cluster.

identityRef:
  kind: AWSClusterRoleIdentity
  name: managed-account

Create the identities

envsubst > cluster-role-identity.yaml << EOL
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterRoleIdentity
metadata:
  name: managed-account
spec:
  allowedNamespaces: {} # This is unsafe since every namespace is allowed to use the role identity
  roleARN: arn:aws:iam::${AWS_MANAGED_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io
  sourceIdentityRef:
    kind: AWSClusterControllerIdentity
    name: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSClusterControllerIdentity
metadata:
  name: default
spec:
  allowedNamespaces: {}
EOL

Prepare the managed account

NOTE: Expose the managed account credentials before running the following commands.

This configuration is adding the trustStatement in the cluster api controller role to allow the controllers.cluster-api-provider-aws.sigs.k8s.io in the manager account to assume it.

envsubst > bootstrap-managed-account.yaml << EOL
apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks:
    iamRoleCreation: false # Set to true if you plan to use the EKSEnableIAM feature flag to enable automatic creation of IAM roles
    managedMachinePool:
      disable: true # Set to false to enable creation of the default node role for managed machine pools
    fargate:
      disable: false # Set to false to enable creation of the default role for the fargate profiles
  clusterAPIControllers:
    disabled: false
    trustStatements:
    - Action:
      - "sts:AssumeRole"
      Effect: "Allow"
      Principal:
        AWS:
        - "arn:aws:iam::${AWS_MANAGER_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io"
EOL

Let’s provision the Managed account with:

clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap-managed-account.yaml

Apply the cluster configuration

Note: Back to the manager account credentials

kubectl --kubeconfig manager.kubeconfig apply -f cluster-role-identity.yaml
kubectl --kubeconfig manager.kubeconfig apply -f managed-cluster.yaml

Time for another drink, enjoy your multi-tenancy setup.

EKS Support in the AWS Provider

• Feature status: Stable
• Feature gate (required): EKS=true
• Feature gate (optional): EKSEnableIAM=true,EKSAllowAddRoles=true

Overview

The AWS provider supports creating EKS based cluster. Currently the following features are supported:

• Provisioning/managing an Amazon EKS Cluster
• Upgrading the Kubernetes version of the EKS Cluster
• Attaching a self-managed machines as nodes to the EKS cluster
• Creating a machine pool and attaching it to the EKS cluster. See machine pool docs for details.
• Creating a managed machine pool and attaching it to the EKS cluster. See machine pool docs for details
• Managing “EKS Addons”. See addons for further details
• Creating an EKS fargate profile
• Managing aws-iam-authenticator configuration

Note: machine pools and fargate profiles are still classed as experimental.

The implementation introduces the following CRD kinds:

• AWSManagedControlPlane - specifies the EKS Cluster in AWS and used by the Cluster API AWS Managed Control plane (MACP)
• AWSManagedMachinePool - defines the managed node pool for the cluster
• EKSConfig - used by Cluster API bootstrap provider EKS (CABPE)

And a number of new templates are available in the templates folder for creating a managed workload cluster.

SEE ALSO

• Prerequisites
• Enabling EKS Support
• Disabling EKS Support
• Creating a cluster
• Using EKS Console
• Using EKS Addons
• Enabling Encryption
• Cluster Upgrades

Prerequisites

To use EKS you must give the controller the required permissions. The easiest way to do this is by using clusterawsadm. For instructions on how to do this see the prerequisites.

When using clusterawsadm and enabling EKS support a new IAM role will be created for you called eks-controlplane.cluster-api-provider-aws.sigs.k8s.io. This role is the IAM role that will be used for the EKS control plane if you don’t specify your own role and if EKSEnableIAM isn’t enabled (see the enabling docs for further information).

Additionally using clusterawsadm will add permissions to the controllers.cluster-api-provider-aws.sigs.k8s.io policy for EKS to function properly.

Enabling EKS Support

Support for EKS is enabled by default when you use the AWS infrastructure provider. For example:

clusterctl init --infrastructure aws

Enabling optional EKS features

There are additional EKS experimental features that are disabled by default. The sections below cover how to enable these features.

Machine Pools

To enable support for machine pools the MachinePool feature flag must be set to to true. This can be done using the EXP_MACHINE_POOL environment variable:

export EXP_MACHINE_POOL=true
clusterctl init --infrastructure aws

See the machine pool documentation for further information.

NOTE: you will need to enable the creation of the default IAM role. The easiest way is using clusterawsadm, for instructions see the prerequisites.

IAM Roles Per Cluster

By default EKS clusters will use the same IAM roles (i.e. control plane, node group roles). There is a feature that allows each cluster to have its own IAM roles. This is done by enabling the EKSEnableIAM feature flag. This can be done before running clusterctl init by using the the CAPA_EKS_IAM environment variable:

export CAPA_EKS_IAM=true
clusterctl init --infrastructure aws

NOTE: you will need the correct prerequisities for this. The easiest way is using clusterawsadm and setting iamRoleCreation to true, for instructions see the prerequisites.

Additional Control Plane Roles

You can add additional roles to the control plane role that is created for an EKS cluster. To use this you must enable the EKSAllowAddRoles feature flag. This can be done before running clusterctl init by using the CAPA_EKS_ADD_ROLES environment variable:

export CAPA_EKS_IAM=true
export CAPA_EKS_ADD_ROLES=true
clusterctl init --infrastructure aws

NOTE: to use this feature you must also enable the CAPA_EKS_IAM feature.

EKS Fargate Profiles

You can use Fargate Profiles with EKS. To use this you must enable the EKSFargate feature flag. This can be done before running clusterctl init by using the EXP_EKS_FARGATE environmnet variable:

export EXP_EKS_FARGATE=true
clusterctl init --infrastructure aws

NOTE: you will need to enable the creation of the default Fargate IAM role. The easiest way is using clusterawsadm and using the fargate configuration option, for instructions see the prerequisites.

Pod Networking

When creating a EKS cluster the Amazon VPC CNI will be used by default for Pod Networking.

When using the AWS Console to create an EKS cluster with a Kubernetes version of v1.18 or greater you are required to select a specific version of the VPC CNI to use.

Using the VPC CNI Addon

You can use an explicit version of the Amazon VPC CNI by using the vpc-cni EKS addon. See the addons documentation for further details of how to use addons.

Using Custom VPC CNI Configuration

If your use case demands custom networking VPC CNI configuration you might already be familiar with the helm chart which helps with the process. This gives you access to ENI Configs and you can set Environment Variables on the aws-node DaemonSet where the VPC CNI runs. CAPA is able to tune the same DaemonSet through Kubernetes.

The following example shows how to turn on custom network config and set a label definition.

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  vpcCni:
    env:
    - name: AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
      value: "true" 
    - name: ENABLE_PREFIX_DELEGATION
      value: "true"

Increase node pod limit

You can increase the pod limit per-node as per the upstream AWS documentation. You’ll need to enable the vpc-cni plugin addon on your EKS cluster as well as enable prefix assignment mode through the ENABLE_PREFIX_DELEGATION environment variable.

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  vpcCni:
    env:
    - name: AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
      value: "true" 
    - name: ENABLE_PREFIX_DELEGATION
      value: "true"
  addons:
  - name: vpc-cni
    version: <replace_with_version>
    conflictResolution: overwrite
  associateOIDCProvider: true
  disableVPCCNI: false

Using Secondary CIDRs

EKS allows users to assign a secondary CIDR range for pods to be assigned. Below are how to get CAPA to generate ENIConfigs in both the managed and unmanaged VPC configurations.

Secondary CIDR functionality will not work unless you enable custom network config too.

Managed (dynamic) VPC

Default configuration for CAPA is to manage the VPC and all the subnets for you dynamically. It will create and delete them along with your cluster. In this method all you need to do is set a SecondaryCidrBlock to one of the allowed two IPv4 CIDR blocks: 100.64.0.0/10 and 198.19.0.0/16. CAPA will automatically generate subnets and ENIConfigs for you and the VPC CNI will do the rest.

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  secondaryCidrBlock: 100.64.0.0/10
  vpcCni:
    env:
    - name: AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
      value: "true" 
  

Unmanaged (static) VPC

In an unmanaged VPC configuration CAPA will create no VPC or subnets and will instead assign the cluster pieces to the IDs you pass. In order to get ENIConfigs to generate you will need to add tags to the subnet you created and want to use as the secondary subnets for your pods. This is done through tagging the subnets with the following tag: sigs.k8s.io/cluster-api-provider-aws/association=secondary.

Setting SecondaryCidrBlock in this configuration will be ignored and no subnets are created.

Using an alternative CNI

There may be scenarios where you do not want to use the Amazon VPC CNI. EKS supports a number of alternative CNIs such as Calico, Cilium, and Weave Net (see docs for full list).

There are a number of ways to install an alternative CNI into the cluster. One option is to use a ClusterResourceSet to apply the required artifacts to a newly provisioned cluster.

When using an alternative CNI you will want to delete the Amazon VPC CNI, especially for a cluster using v1.17 or less. This can be done via the disableVPCCNI property of the AWSManagedControlPlane:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  disableVPCCNI: true

If you are replacing Amazon VPC CNI with your own helm managed instance, you will need to set AWSManagedControlPlane.spec.disableVPCCNI to true and add "aws.cluster.x-k8s.io/prevent-deletion": "true" label on the Daemonset. This label is needed so aws-node daemonset is not reaped during CNI reconciliation.

The following example shows how to label your aws-node Daemonset.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  annotations:
    ...
  generation: 1
  labels:
    app.kubernetes.io/instance: aws-vpc-cni
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: aws-node
    app.kubernetes.io/version: v1.15.1
    helm.sh/chart: aws-vpc-cni-1.15.1
    aws.cluster.x-k8s.io/prevent-deletion: true

You cannot set disableVPCCNI to true if you are using the VPC CNI addon.

Some alternative CNIs provide for the replacement of kube-proxy, such as in Calico and Cilium. When enabling the kube-proxy alternative, the kube-proxy installed by EKS must be deleted. This can be done via the disable property of kubeProxy in AWSManagedControlPlane:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  disableVPCCNI: true
  kubeProxy:
    disable: true

You cannot set disable to true in kubeProxy if you are using the kube-proxy addon.

Additional Information

See the AWS documentation for further details of EKS pod networking.

Creating a EKS cluster

New “eks” cluster templates have been created that you can use with clusterctl to create a EKS cluster. To create a EKS cluster with self-managed nodes (a.k.a machines):

clusterctl generate cluster capi-eks-quickstart --flavor eks --kubernetes-version v1.22.9 --worker-machine-count=3 > capi-eks-quickstart.yaml

To create a EKS cluster with a managed node group (a.k.a managed machine pool):

clusterctl generate cluster capi-eks-quickstart --flavor eks-managedmachinepool --kubernetes-version v1.22.9 --worker-machine-count=3 > capi-eks-quickstart.yaml

NOTE: When creating an EKS cluster only the MAJOR.MINOR of the -kubernetes-version is taken into consideration.

Kubeconfig

When creating an EKS cluster 2 kubeconfigs are generated and stored as secrets in the management cluster. This is different to when you create a non-managed cluster using the AWS provider.

User kubeconfig

This should be used by users that want to connect to the newly created EKS cluster. The name of the secret that contains the kubeconfig will be [cluster-name]-user-kubeconfig where you need to replace [cluster-name] with the name of your cluster. The -user-kubeconfig in the name indicates that the kubeconfig is for the user use.

To get the user kubeconfig for a cluster named managed-test you can run a command similar to:

kubectl --namespace=default get secret managed-test-user-kubeconfig \
   -o jsonpath={.data.value} | base64 --decode \
   > managed-test.kubeconfig

Cluster API (CAPI) kubeconfig

This kubeconfig is used internally by CAPI and shouldn’t be used outside of the management server. It is used by CAPI to perform operations, such as draining a node. The name of the secret that contains the kubeconfig will be [cluster-name]-kubeconfig where you need to replace [cluster-name] with the name of your cluster. Note that there is NO -user in the name.

There are three keys in the CAPI kubeconfig for eks clusters:

The secret contents are regenerated every sync-period as the token that is embedded in the kubeconfig and token file is only valid for a short period of time. When EKS support is enabled the maximum sync period is 10 minutes. If you try to set --sync-period to greater than 10 minutes then an error will be raised.

EKS Console

To use the Amazon EKS Console to view workloads running in an EKS cluster created using the AWS provider (CAPA) you can do the following:

1. Create a new policy with the required IAM permissions for the console. This example can be used. For example, a policy called EKSViewNodesAndWorkloads.

2. Assign the policy created in step 1) to a IAM user or role for the users of your EKS cluster

3. Map the IAM user or role from step 2) to a Kubernetes user that has the RBAC permissions to view the Kubernetes resources. This needs to be done via the aws-auth configmap (used by aws-iam-authenticator) which is generated by the AWS provider. This mapping can be specified using in the AWSManagedControlPlane, for example:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  iamAuthenticatorConfig:
    mapRoles:
    - username: "kubernetes-admin"
      rolearn: "arn:aws:iam::1234567890:role/AdministratorAccess"
      groups:
      - "system:masters"

In the sample above the arn:aws:iam::1234567890:role/AdministratorAccess IAM role has the EKSViewNodesAndWorkloads policy attached (created in step 1.)

EKS Addons

EKS Addons can be used with EKS clusters created using Cluster API Provider AWS.

Addons are supported in EKS clusters using Kubernetes v1.18 or greater.

Installing addons

To install an addon you need to declare them by specifying the name, version and optionally how conflicts should be resolved in the AWSManagedControlPlane. For example:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  region: "eu-west-2"
  sshKeyName: "capi-management"
  version: "v1.18.0"
  addons:
    - name: "vpc-cni"
      version: "v1.6.3-eksbuild.1"
      conflictResolution: "overwrite"

Note: For conflictResolution overwrite is the default behaviour. That means, if not otherwise specified, it’s set to overwrite.

Additionally, there is a cluster flavor called eks-managedmachinepool-vpccni that you can use with clusterctl:

clusterctl generate cluster my-cluster --kubernetes-version v1.18.0 --flavor eks-managedmachinepool-vpccni > my-cluster.yaml

Updating Addons

To update the version of an addon you need to edit the AWSManagedControlPlane instance and update the version of the addon you want to update. Using the example from the previous section we would do:

...
  addons:
    - name: "vpc-cni"
      version: "v1.7.5-eksbuild.1"
      conflictResolution: "overwrite"
...

Deleting Addons

To delete an addon from a cluster you need to edit the AWSManagedControlPlane instance and remove the entry for the addon you want to delete.

Viewing installed addons

You can see what addons are installed on your EKS cluster by looking in the Status of the AWSManagedControlPlane instance.

Additionally you can run the following command:

clusterawsadm eks addons list-installed -n <<eksclustername>>

Viewing available addons

You can see what addons are available to your EKS cluster by running the following command:

clusterawsadm eks addons list-available -n <<eksclustername>>

Enabling Encryption

To enable encryption when creating a cluster you need to create a new KMS key that has an alias name starting with cluster-api-provider-aws-.

For example, arn:aws:kms:eu-north-1:12345678901:alias/cluster-api-provider-aws-key1.

You then need to specify the key ARN in the encryptionConfig of the AWSManagedControlPlane:

kind: AWSManagedControlPlane
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
metadata:
  name: "capi-managed-test-control-plane"
spec:
  ...
  encryptionConfig:
    provider: "arn:aws:kms:eu-north-1:12345678901:key/351f5544-6130-42e4-8786-2c85e546fc2d"
    resources:
    - "secrets"

You must use the ARN of the key and not the ARN of the alias.

Custom KMS Alias Prefix

If you would like to use a different alias prefix then you can use the kmsAliasPrefix in the optional configuration file for clusterawsadm:

clusterawsadm bootstrap iam create-stack --config custom-prefix.yaml

And the contents of the configuration file:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  eks:
    enable: true
    kmsAliasPrefix: "my-prefix-*

EKS Cluster Upgrades

Control Plane Upgrade

Upgrading the Kubernetes version of the control plane is supported by the provider. To perform an upgrade you need to update the version in the spec of the AWSManagedControlPlane. Once the version has changed the provider will handle the upgrade for you.

You can only upgrade a EKS cluster by 1 minor version at a time. If you attempt to upgrade the version by more then 1 minor version the provider will ensure the upgrade is done in multiple steps of 1 minor version. For example upgrading from v1.15 to v1.17 would result in your cluster being upgraded v1.15 -> v1.16 first and then v1.16 to v1.17.

ROSA Support in the AWS Provider

• Feature status: Experimental
• Feature gate (required): ROSA=true

Overview

The AWS provider supports creating Red Hat OpenShift Service on AWS (ROSA) based cluster. Currently the following features are supported:

• Provisioning/Deleting a ROSA cluster with hosted control planes (HCP)

The implementation introduces the following CRD kinds:

• ROSAControlPlane - specifies the ROSA Cluster in AWS
• ROSACluster - needed only to satisfy cluster-api contract

A new template is available in the templates folder for creating a managed ROSA workload cluster.

SEE ALSO

• Enabling ROSA Support
• Creating a cluster
• Creating MachinePools
• Upgrades
• External Auth Providers
• Support

Enabling ROSA Support

To enable support for ROSA clusters, the ROSA feature flag must be set to true. This can be done using the EXP_ROSA environment variable.

Make sure to set up your AWS environment first as described here.

export EXP_ROSA="true"
export EXP_MACHINE_POOL="true"
clusterctl init --infrastructure aws

Troubleshooting

To check the feature-gates for the Cluster API controller run the following command:

$ kubectl get deploy capi-controller-manager -n capi-system -o yaml

the feature gate container arg should have MachinePool=true as shown below.

spec:
  containers:
  - args:
    - --feature-gates=MachinePool=true,ClusterTopology=true,...

To check the feature-gates for the Cluster API AWS controller run the following command:

$ kubectl get deploy capa-controller-manager -n capa-system -o yaml

the feature gate arg should have ROSA=true as shown below.

spec:
  containers:
  - args:
    - --feature-gates=ROSA=true,...

Creating a ROSA cluster

Permissions

CAPA controller requires an API token in order to be able to provision ROSA clusters:

1. Visit https://console.redhat.com/openshift/token to retrieve your API authentication token

2. Create a credentials secret within the target namespace with the token to be referenced later by ROSAControlePlane

   kubectl create secret generic rosa-creds-secret \
     --from-literal=ocmToken='eyJhbGciOiJIUzI1NiIsI....' \
     --from-literal=ocmApiUrl='https://api.openshift.com' 
   

   Alternatively, you can edit CAPA controller deployment to provide the credentials:

   kubectl edit deployment -n capa-system capa-controller-manager
   

   and add the following environment variables to the manager container:

     env:
     - name: OCM_TOKEN
       value: "<token>"
     - name: OCM_API_URL
       value: "https://api.openshift.com" # or https://api.stage.openshift.com
   

Prerequisites

Follow the guide here up until Step 3 to install the required tools and setup the prerequisite infrastructure. Once Step 3 is done, you will be ready to proceed with creating a ROSA cluster using cluster-api.

Creating the cluster

1. Prepare the environment:

   export OPENSHIFT_VERSION="4.14.5"
   export AWS_REGION="us-west-2"
   export AWS_AVAILABILITY_ZONE="us-west-2a"
   export AWS_ACCOUNT_ID="<account_id>"
   export AWS_CREATOR_ARN="<user_arn>" # can be retrieved e.g. using `aws sts get-caller-identity`
   
   export OIDC_CONFIG_ID="<oidc_id>" # OIDC config id creating previously with `rosa create oidc-config`
   export ACCOUNT_ROLES_PREFIX="ManagedOpenShift-HCP" # prefix used to create account IAM roles with `rosa create account-roles`
   export OPERATOR_ROLES_PREFIX="capi-rosa-quickstart"  # prefix used to create operator roles with `rosa create operator-roles --prefix <PREFIX_NAME>`
   
   # subnet IDs created earlier
   export PUBLIC_SUBNET_ID="subnet-0b54a1111111111111"   
   export PRIVATE_SUBNET_ID="subnet-05e72222222222222"
   

2. Render the cluster manifest using the ROSA cluster template:

   clusterctl generate cluster <cluster-name> --from templates/cluster-template-rosa.yaml > rosa-capi-cluster.yaml
   

Note: The AWS role name must be no more than 64 characters in length. Otherwise an error will be returned. Truncate values exceeding 64 characters.

1. If a credentials secret was created earlier, edit ROSAControlPlane to reference it:

   apiVersion: controlplane.cluster.x-k8s.io/v1beta2
   kind: ROSAControlPlane
   metadata:
     name: "capi-rosa-quickstart-control-plane"
   spec:
     credentialsSecretRef:
       name: rosa-creds-secret
   ...
   

2. Provide an AWS identity reference

   apiVersion: controlplane.cluster.x-k8s.io/v1beta2
   kind: ROSAControlPlane
   metadata:
     name: "capi-rosa-quickstart-control-plane"
   spec:
     identityRef:
       kind: <IdentityType>
       name: <IdentityName>
   ...
   

   Otherwise, make sure the following AWSClusterControllerIdentity singleton exists in your management cluster:

   apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
   kind: AWSClusterControllerIdentity
   metadata:
     name: "default"
   spec:
     allowedNamespaces: {}  # matches all namespaces
   

   see Multi-tenancy for more details

3. Finally apply the manifest to create your Rosa cluster:

   kubectl apply -f rosa-capi-cluster.yaml
   

see ROSAControlPlane CRD Reference for all possible configurations.

Creating MachinePools

Cluster API Provider AWS (CAPA) has experimental support for managed ROSA MachinePools through the infrastructure type ROSAMachinePool. A ROSAMachinePool is responsible for orchestrating and bootstraping a group of EC2 machines into kubernetes nodes.

Using clusterctl to deploy

To deploy a MachinePool / ROSAMachinePool via clusterctl generate use the template located here.

Make sure to set up your environment as described here.

clusterctl generate cluster my-cluster --from templates/cluster-template-rosa-machinepool > my-cluster.yaml

Example

Below is an example of the resources needed to create a ROSA MachinePool.

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: "${CLUSTER_NAME}-pool-0"
spec:
  clusterName: "${CLUSTER_NAME}"
  replicas: 1
  template:
    spec:
      clusterName: "${CLUSTER_NAME}"
      bootstrap:
        dataSecretName: ""
      infrastructureRef:
        name: "${CLUSTER_NAME}-pool-0"
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
        kind: ROSAMachinePool
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: ROSAMachinePool
metadata:
  name: "${CLUSTER_NAME}-pool-0"
spec:
  nodePoolName: "nodepool-0"
  instanceType: "m5.xlarge"
  subnet: "${PRIVATE_SUBNET_ID}"
  version: "${OPENSHIFT_VERSION}"

see ROSAMachinePool CRD Reference for all possible configurations.

Upgrades

Control Plane Upgrade

Upgrading the OpenShift version of the control plane is supported by the provider. To perform an upgrade you need to update the version in the spec of the ROSAControlPlane. Once the version has changed the provider will handle the upgrade for you.

The Upgrade state can be checked in the conditions under ROSAControlPlane.status.

MachinePool Upgrade

Upgrading the OpenShift version of the MachinePools is supported by the provider and can be performed independetly from the Control Plane upgrades. To perform an upgrade you need to update the version in the spec of the ROSAMachinePool. Once the version has changed the provider will handle the upgrade for you.

The Upgrade state can be checked in the conditions under ROSAMachinePool.status.

The version of the MachinePool can’t be greater than Control Plane version.

External Auth Providers (BYOI)

ROSA allows you to Bring Your Own Identity (BYOI) to manage and authenticate cluster users.

Enabling

To enable this feature, enableExternalAuthProviders field should be set to true on cluster creation. Changing this field afterwards will have no effect:

---
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: ROSAControlPlane
metadata:
  name: "capi-rosa-quickstart-control-plane"
spec:
  enableExternalAuthProviders: true
  ....

Note: This feauture requires OpenShift version 4.15.5 or newer.

Usage

After creating and configuring your OIDC provider of choice, the next step is to configure ROSAControlPlane externalAuthProviders as follows:

---
apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: ROSAControlPlane
metadata:
  name: "capi-rosa-quickstart-control-plane"
spec:
  enableExternalAuthProviders: true
  externalAuthProviders:
  - name: my-oidc-provider
    issuer:
      issuerURL: https://login.microsoftonline.com/<tenant-id>/v2.0 # e.g. if using Microsoft Entra ID
      audiences:  # audiences that will be trusted by the kube-apiserver
      - "audience1" # usually the client ID
    claimMappings:
      username:
        claim: email
        prefixPolicy: ""
      groups:
        claim: groups
  ....

Note: oidcProviders only accepts one entry at the moment.

Accessing the cluster

Setting up RBAC

When enableExternalAuthProviders is set to true, ROSA provider will generate a temporary admin kubeconfig secret in the same namespace named <cluster-name>-bootstrap-kubeconfig. This kubeconfig can be used to access the cluster to setup RBAC for OIDC users/groups.

The following example binds the cluster-admin role to an OIDC group, giving all users in that group admin permissions.

kubectl get secret <cluster-name>-bootstrap-kubeconfig -o jsonpath='{.data.value}' | base64 -d > /tmp/capi-admin-kubeconfig
export KUBECONFIG=/tmp/capi-admin-kubeconfig

kubectl create clusterrolebinding oidc-cluster-admins --clusterrole cluster-admin --group <group-id>

Note: The generated bootstrap kubeconfig is only valid for 24h, and will not be usable afterwards. However, users can opt to manually delete the secret object to trigger the generation of a new one which will be valid for another 24h.

Login using the cli

The kubelogin kubectl plugin can be used to login with OIDC credentials using the cli.

Configuring OpenShift Console

The OpenShift Console needs to be configured before it can be used to authenticate and login to the cluster.

1. Setup a new client in your OIDC provider with the following Redirect URL: <console-url>/auth/callback. You can find the console URL in the status field of the ROSAControlPlane once the cluster is ready:

   kubectl get rosacontrolplane <control-plane-name> -o jsonpath='{.status.consoleURL}'
   

2. Create a new client secret in your OIDC provider and store the value in a kubernetes secret in the same namespace as your cluster:

   kubectl create secret generic console-client-secret --from-literal=clientSecret='<client-secret-value>' 
   

3. Configure ROSAControlPlane external auth provider with the created client:

   ---
   apiVersion: controlplane.cluster.x-k8s.io/v1beta2
   kind: ROSAControlPlane
   metadata:
     name: "capi-rosa-quickstart-control-plane"
   spec:
     enableExternalAuthProviders: true
     externalAuthProviders:
     - name: my-oidc-provider
       issuer:
         issuerURL: https://login.microsoftonline.com/<tenant-id>/v2.0 # e.g. if using Microsoft Entra ID
         audiences:  # audiences that will be trusted by the kube-apiserver
         - "audience1"
         - <console-client-id> # <----New
       claimMappings:
         username:
           claim: email
           prefixPolicy: ""
         groups:
           claim: groups
       oidcClients:  # <----New
         - componentName: console
           componentNamespace: openshift-console
           clientID: <console-client-id>
           clientSecret:
             name: console-client-secret # secret name created in step 2
     ....
   

see ROSAControlPlane CRD Reference for all possible configurations.

Create issue for ROSA

When creating issue for ROSA-HCP cluster, include the logs for the capa-controller-manager and capi-controller-manager deployment pods. The logs can be saved to text file using the commands below. Also include the yaml files for all the resources used to create the ROSA cluster:

• Cluster
• ROSAControlPlane
• MachinePool
• ROSAMachinePool

$ kubectl get pod -n capa-system 
NAME                                      READY   STATUS    RESTARTS   AGE
capa-controller-manager-77f5b946b-sddcg   1/1     Running   1          3d3h

$ kubectl logs -n capa-system capa-controller-manager-77f5b946b-sddcg > capa-controller-manager-logs.txt

$ kubectl get pod -n capi-system 
NAME                                       READY   STATUS    RESTARTS   AGE
capi-controller-manager-78dc897784-f8gpn   1/1     Running   18         26d

$ kubectl logs -n capi-system capi-controller-manager-78dc897784-f8gpn > capi-controller-manager-logs.txt

Bring Your Own AWS Infrastructure

Normally, Cluster API will create infrastructure on AWS when standing up a new workload cluster. However, it is possible to have Cluster API re-use external AWS infrastructure instead of creating its own infrastructure.

There are two possible ways to do this:

• By consuming existing AWS infrastructure
• By using externally managed AWS infrastructure

IMPORTANT NOTE: This externally managed AWS infrastructure should not be confused with EKS-managed clusters.

Follow the instructions below to configure Cluster API to consume existing AWS infrastructure.

Consuming Existing AWS Infrastructure

Overview

CAPA supports using existing AWS resources while creating AWS Clusters which gives flexibility to the users to bring their own existing resources into the cluster instead of creating new resources again.

Follow the instructions below to configure Cluster API to consume existing AWS infrastructure.

Prerequisites

In order to have Cluster API consume existing AWS infrastructure, you will need to have already created the following resources:

• A VPC
• One or more private subnets (subnets that do not have a route to an Internet gateway)
• A NAT gateway for each private subnet, along with associated Elastic IP addresses (only needed if the nodes require access to the Internet, i.e. pulling public images)
  • A public subnet in the same Availability Zone (AZ) for each private subnet (this is required for NAT gateways to function properly)
• An Internet gateway for all public subnets (only required if the workload cluster is set to use an Internet facing load balancer or one or more NAT gateways exist in the VPC)
• Route table associations that provide connectivity to the Internet through a NAT gateway (for private subnets) or the Internet gateway (for public subnets)
• VPC endpoints for ec2, elasticloadbalancing, secretsmanager an autoscaling (if using MachinePools) when the private Subnets do not have a NAT gateway

You will need the ID of the VPC and subnet IDs that Cluster API should use. This information is available via the AWS Management Console or the AWS CLI.

Note that there is no need to create an Elastic Load Balancer (ELB), security groups, or EC2 instances; Cluster API will take care of these items.

If you want to use existing security groups, these can be specified and new ones will not be created.

If you want to use an existing control load load balancer, specify its name.

Tagging AWS Resources

Cluster API itself does tag AWS resources it creates. The sigs.k8s.io/cluster-api-provider-aws/cluster/<cluster-name> (where <cluster-name> matches the metadata.name field of the Cluster object) tag, with a value of owned, tells Cluster API that it has ownership of the resource. In this case, Cluster API will modify and manage the lifecycle of the resource.

When consuming existing AWS infrastructure, the Cluster API AWS provider does not require any tags to be present. The absence of the tags on an AWS resource indicates to Cluster API that it should not modify the resource or attempt to manage the lifecycle of the resource.

However, the built-in Kubernetes AWS cloud provider does require certain tags in order to function properly. Specifically, all subnets where Kubernetes nodes reside should have the kubernetes.io/cluster/<cluster-name> tag present. Private subnets should also have the kubernetes.io/role/internal-elb tag with a value of 1, and public subnets should have the kubernetes.io/role/elb tag with a value of 1. These latter two tags help the cloud provider understand which subnets to use when creating load balancers.

Finally, if the controller manager isn’t started with the --configure-cloud-routes: "false" parameter, the route table(s) will also need the kubernetes.io/cluster/<cluster-name> tag. (This parameter can be added by customizing the KubeadmConfigSpec object of the KubeadmControlPlane object.)

Note: All the tagging of resources should be the responsibility of the users and are not managed by CAPA controllers.

Configuring the AWSCluster Specification

Specifying existing infrastructure for Cluster API to use takes place in the specification for the AWSCluster object. Specifically, you will need to add an entry with the VPC ID and the IDs of all applicable subnets into the network field. Here is an example:

For EC2

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSCluster

For EKS

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSManagedControlPlane

spec:
  network:
    vpc:
      id: vpc-0425c335226437144
    subnets:
    - id: subnet-0261219d564bb0dc5
    - id: subnet-0fdcccba78668e013

When you use kubectl apply to apply the Cluster and AWSCluster specifications to the management cluster, Cluster API will use the specified VPC ID and subnet IDs, and will not create a new VPC, new subnets, or other associated resources. It will, however, create a new ELB and new security groups.

Placing EC2 Instances in Specific AZs

To distribute EC2 instances across multiple AZs, you can add information to the Machine specification. This is optional and only necessary if control over AZ placement is desired.

To tell Cluster API that an EC2 instance should be placed in a particular AZ but allow Cluster API to select which subnet in that AZ can be used, add this to the Machine specification:

spec:
  failureDomain: "us-west-2a"

If using a MachineDeployment, specify AZ placement like so:

spec:
  template:
    spec:
      failureDomain: "us-west-2b"

Note that all replicas within a MachineDeployment will reside in the same AZ.

Placing EC2 Instances in Specific Subnets

To specify that an EC2 instance should be placed in a specific subnet, add this to the AWSMachine specification:

spec:
  subnet:
    id: subnet-0a3507a5ad2c5c8c3

When using MachineDeployments, users can control subnet selection by adding information to the AWSMachineTemplate associated with that MachineDeployment, like this:

spec:
  template:
    spec:
      subnet:
        id: subnet-0a3507a5ad2c5c8c3

Users may either specify failureDomain on the Machine or MachineDeployment objects, or users may explicitly specify subnet IDs on the AWSMachine or AWSMachineTemplate objects. If both are specified, the subnet ID is used and the failureDomain is ignored.

Placing EC2 Instances in Specific External VPCs

CAPA clusters are deployed within a single VPC, but it’s possible to place machines that live in external VPCs. For this kind of configuration, we assume that all the VPCs have the ability to communicate, either through external peering, a transit gateway, or some other mechanism already established outside of CAPA. CAPA will not create a tunnel or manage the network configuration for any secondary VPCs.

The AWSMachineTemplate subnet field allows specifying filters or specific subnet ids for worker machine placement. If the filters or subnet id is specified in a secondary VPC, CAPA will place the machine in that VPC and subnet.

spec:
  template:
    spec:
      subnet:
        filters:
          name: "vpc-id"
          values:
            - "secondary-vpc-id"
      securityGroupOverrides:
        node: sg-04e870a3507a5ad2c5c8c2
        node-eks-additional: sg-04e870a3507a5ad2c5c8c1

Caveats/Notes

CAPA helpfully creates security groups for various roles in the cluster and automatically attaches them to workers. However, security groups are tied to a specific VPC, so workers placed in a VPC outside of the cluster will need to have these security groups created by some external process first and set in the securityGroupOverrides field, otherwise the ec2 creation will fail.

Security Groups

To use existing security groups for instances for a cluster, add this to the AWSCluster specification:

spec:
  network:
    securityGroupOverrides:
      bastion: sg-0350a3507a5ad2c5c8c3
      controlplane: sg-0350a3507a5ad2c5c8c3
      apiserver-lb: sg-0200a3507a5ad2c5c8c3
      node: sg-04e870a3507a5ad2c5c8c3
      lb: sg-00a3507a5ad2c5c8c3

Any additional security groups specified in an AWSMachineTemplate will be applied in addition to these overriden security groups.

To specify additional security groups for the control plane load balancer for a cluster, add this to the AWSCluster specification:

spec:
  controlPlaneLoadBalancer:
    additionalSecurityGroups:
    - sg-0200a3507a5ad2c5c8c3
    - ...

It’s also possible to override the cluster security groups for an individual AWSMachine or AWSMachineTemplate:

spec:
  SecurityGroupOverrides:
    node: sg-04e870a3507a5ad2c5c8c2
    node-eks-additional: sg-04e870a3507a5ad2c5c8c1

Control Plane Load Balancer

The cluster control plane is accessed through a Classic ELB. By default, Cluster API creates the Classic ELB. To use an existing Classic ELB, add its name to the AWSCluster specification:

spec:
  controlPlaneLoadBalancer:
    name: my-classic-elb-name

As control plane instances are added or removed, Cluster API will register and deregister them, respectively, with the Classic ELB.

It’s also possible to specify custom ingress rules for the control plane load balancer. To do so, add this to the AWSCluster specification:

spec:
  controlPlaneLoadBalancer:
    ingressRules:
      - description: "example ingress rule"
        protocol: "-1" # all
        fromPort: 7777
        toPort: 7777

WARNING: Using an existing Classic ELB is an advanced feature. If you use an existing Classic ELB, you must correctly configure it, and attach subnets to it.

An incorrectly configured Classic ELB can easily lead to a non-functional cluster. We strongly recommend you let Cluster API create the Classic ELB.

Control Plane ingress rules

It’s possible to specify custom ingress rules for the control plane itself. To do so, add this to the AWSCluster specification:

spec:
  network:
    additionalControlPlaneIngressRules:
    - description: "example ingress rule"
      protocol: "-1" # all
      fromPort: 7777
      toPort: 7777

Caveats/Notes

• When both public and private subnets are available in an AZ, CAPI will choose the private subnet in the AZ over the public subnet for placing EC2 instances.
• If you configure CAPI to use existing infrastructure as outlined above, CAPI will not create an SSH bastion host. Combined with the previous bullet, this means you must make sure you have established some form of connectivity to the instances that CAPI will create.

Using Externally managed AWS Clusters

Overview

Alternatively, CAPA supports externally managed cluster infrastructure which is useful for scenarios where a different persona is managing the cluster infrastructure out-of-band(external system) while still wanting to use CAPI for automated machine management. Users can make use of existing AWSCluster CRDs in their externally managed clusters.

How to use externally managed clusters?

Users have to use cluster.x-k8s.io/managed-by: "<name-of-system>" annotation to depict that AWS resources are managed externally. If CAPA controllers come across this annotation in any of the AWS resources while reconciliation, then it will ignore the resource and not perform any reconciliation(including creating/modifying any of the AWS resources, or it’s status).

A predicate ResourceIsNotExternallyManaged is exposed by Cluster API which allows CAPA controllers to differentiate between externally managed vs CAPA managed resources. For example:

c, err := ctrl.NewControllerManagedBy(mgr).
        For(&providerv1.InfraCluster{}).
        Watches(...).
        WithOptions(options).
        WithEventFilter(predicates.ResourceIsNotExternallyManaged(logger.FromContext(ctx))).
        Build(r)
if err != nil {
	return errors.Wrap(err, "failed setting up with a controller manager")
}

The external system must provide all required fields within the spec of the AWSCluster and must adhere to the CAPI provider contract and set the AWSCluster status to be ready when it is appropriate to do so.

IMPORTANT NOTE: Users should take care of skipping reconciliation in external controllers within mapping function while enqueuing requests. For example:

err := c.Watch(
  	&source.Kind{Type: &infrav1.AWSCluster{}},
  	handler.EnqueueRequestsFromMapFunc(func(a client.Object) []reconcile.Request {
  	   if annotations.IsExternallyManaged(awsCluster) {
  		    log.Info("AWSCluster is externally managed, skipping mapping.")
  		    return nil
  	   }
           return []reconcile.Request{
             {
  	         NamespacedName: client.ObjectKey{Namespace: c.Namespace, Name: c.Spec.InfrastructureRef.Name},
             },
          }}))
if err != nil {
   // handle it
}

Caveats

Once the user has created externally managed AWSCluster, it is not allowed to convert it to CAPA managed cluster. However, converting from managed to externally managed is allowed.

User should only use this feature if their cluster infrastructure lifecycle management has constraints that the reference implementation does not support. See user stories for more details.

Bring your own (BYO) Public IPv4 addresses

Cluster API also provides a mechanism to allocate Elastic IP from the existing Public IPv4 Pool that you brought to AWS[1].

Bringing your own Public IPv4 Pool (BYOIPv4) can be used as an alternative to buying Public IPs from AWS, also considering the changes in charging for this since February 2024[2].

Supported resources to BYO Public IPv4 Pool (BYO Public IPv4):

• NAT Gateways
• Network Load Balancer for API server
• Machines

Use BYO Public IPv4 when you have brought to AWS custom IPv4 CIDR blocks and want the cluster to automatically use IPs from the custom pool instead of Amazon-provided pools.

Prerequisites and limitations for BYO Public IPv4 Pool

• BYOIPv4 is limited to AWS to selected regions. See more in AWS Documentation for Regional availability
• The IPv4 address must be provisioned and advertised to the AWS account before the cluster is installed
• The public IPv4 addresses is limited to the network border group that the CIDR block have been advertised[3][4], and the NetworkSpec.ElasticIpPool.PublicIpv4Pool must be the same of the cluster will be installed.
• Only NAT Gateways and the Network Load Balancer for API server will consume from the IPv4 pool defined in the network scope.
• The public IPv4 pool must be assigned to each machine to consume public IPv4 from a custom IPv4 pool.

Steps to set BYO Public IPv4 Pool to core infrastructure

Currently, CAPA supports BYO Public IPv4 to core components NAT Gateways and Network Load Balancer for the internet-facing API server.

To specify a Public IPv4 Pool for core components you must set the spec.elasticIpPool as follows:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: aws-cluster-localzone
spec:
  region: us-east-1
  networkSpec:
    vpc:
      elasticIpPool:
        publicIpv4Pool: ipv4pool-ec2-0123456789abcdef0
        publicIpv4PoolFallbackOrder: amazon-pool

Then all the Elastic IPs will be created by consuming from the pool ipv4pool-ec2-0123456789abcdef0.

Steps to BYO Public IPv4 Pool to machines

To create a machine consuming from a custom Public IPv4 Pool you must set the pool ID to the AWSMachine spec, then set the PublicIP to true:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSMachine
metadata:
  name: byoip-s55p4-bootstrap
spec:
  # placeholder for AWSMachine spec
  elasticIpPool:
    publicIpv4Pool: ipv4pool-ec2-0123456789abcdef0
    publicIpv4PoolFallbackOrder: amazon-pool
  publicIP: true

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html [2] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ [3] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-byoip.html#byoip-onboard [4] https://docs.aws.amazon.com/cli/latest/reference/ec2/advertise-byoip-cidr.html

Specifying the IAM Role to use for Management Components

Prerequisites

To be able to specify the IAM role that the management components should run as your cluster must be set up with the ability to assume IAM roles using one of the following solutions:

• IAM Roles for Service Accounts
• Kiam
• Kube2iam

Setting IAM Role

Set the AWS_CONTROLLER_IAM_ROLE environment variable to the ARN of the IAM role to use when performing the clusterctl init command.

For example:

export AWS_CONTROLLER_IAM_ROLE=arn:aws:iam::1234567890:role/capa-management-components
clusterctl init --infrastructure=aws

IAM Role Trust Policy

IAM Roles for Service Accounts

When creating the IAM role, the following trust policy will need to be used with the AWS_ACCOUNT_ID, AWS_REGION and OIDC_PROVIDER_ID environment variables replaced.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}:sub": [
            "system:serviceaccount:capa-system:capa-controller-manager",
            "system:serviceaccount:capi-system:capi-controller-manager",
            "system:serviceaccount:capa-eks-control-plane-system:capa-eks-control-plane-controller-manager",
            "system:serviceaccount:capa-eks-bootstrap-system:capa-eks-bootstrap-controller-manager",
          ]
        }
      }
    }
  ]
}

If you plan to use the controllers.cluster-api-provider-aws.sigs.k8s.io role created by clusterawsadm then you’ll need to add the following to your AWSIAMConfiguration:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  clusterAPIControllers:
    disabled: false
    trustStatements:
    - Action:
      - "sts:AssumeRoleWithWebIdentity"
      Effect: "Allow"
      Principal:
        Federated:
        - "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}"
      Condition:
        "ForAnyValue:StringEquals":
          "oidc.eks.${AWS_REGION}.amazonaws.com/id/${OIDC_PROVIDER_ID}:sub":
            - system:serviceaccount:capa-system:capa-controller-manager
            - system:serviceaccount:capa-eks-control-plane-system:capa-eks-control-plane-controller-manager # Include if also using EKS

With this you can then set AWS_CONTROLLER_IAM_ROLE to arn:aws:iam::${AWS_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io

Kiam / kube2iam

When creating the IAM role, you will need to apply the kubernetes.io/cluster/${CLUSTER_NAME}/role": "enabled" tag to the role and use the following trust policy with the AWS_ACCOUNT_ID and CLUSTER_NAME environment variables correctly replaced.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}.worker-node-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

If you plan to use the controllers.cluster-api-provider-aws.sigs.k8s.io role created by clusterawsadm then you’ll need to add the following to your AWSIAMConfiguration:

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  clusterAPIControllers:
    disabled: false
    trustStatements:
      - Action:
        - "sts:AssumeRole"
        Effect: "Allow"
        Principal:
          Service:
          - "ec2.amazonaws.com"
      - Action:
        - "sts:AssumeRole"
        Effect: "Allow"
        Principal:
          AWS:
          - "arn:aws:iam::${AWS_ACCOUNT_ID}:role/${CLUSTER_NAME}.worker-node-role"

With this you can then set AWS_CONTROLLER_IAM_ROLE to arn:aws:iam::${AWS_ACCOUNT_ID}:role/controllers.cluster-api-provider-aws.sigs.k8s.io

External AWS Cloud Provider and AWS CSI Driver

Overview

The support for in-tree cloud providers and the CSI drivers is coming to an end and CAPA supports various upgrade paths to use external cloud provider (Cloud Controller Manager - CCM) and external CSI drivers. This document explains how to create a CAPA cluster with external CSI/CCM plugins and how to upgrade existing clusters that rely on in-tree providers.

Creating clusters with external CSI/CCM and validating

For clusters that will use external CCM, cloud-provider: external flag needs to be set in KubeadmConfig resources in both KubeadmControlPlane and MachineDeployment resources.

clusterConfiguration:
  apiServer:
    extraArgs:
      cloud-provider: external
  controllerManager:
    extraArgs:
      cloud-provider: external
initConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: external
joinConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: external

External CCM and EBS CSI driver can be installed manually or using ClusterResourceSets (CRS) onto the CAPA workload cluster. To install them with CRS, create a CRS resource on the management cluster with labels, for example csi: external and ccm: external labels. Then, when creating Cluster objects for workload clusters that should have this CSR applied, create them with matching labels csi: external and ccm: external for CSI and CCM, respectively.

Manifests for installing the AWS CCM and the AWS EBS CSI driver are available from their respective GitHub repositories (see here for the AWS CCM and here for the AWS EBS CSI driver).

An example of a workload cluster manifest with labels assigned for matching to a CRS can be found here.

Verifying dynamically provisioned volumes with CSI driver

Once you have the cluster with external CCM and CSI controller running successfully, you can test the CSI driver functioning with following steps after switching to workload cluster:

1. Create a service (say,nginx)

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  namespace: default
spec:
  clusterIP: None
  ports:
    - name: nginx-web
      port: 80
  selector:
    app: nginx

2. Create a storageclass and statefulset for the service created above with the persistent volume assigned to the storageclass:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: aws-ebs-volumes
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "100"
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.ebs.csi.aws.com/zone
        values:
          - us-east-1a
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
spec:
  serviceName: "nginx-svc"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: registry.k8s.io/nginx-slim:0.8
          ports:
            - name: nginx-web
              containerPort: 80
          volumeMounts:
            - name: nginx-volumes
              mountPath: /usr/share/nginx/html
      volumes:
        - name: nginx-volumes
          persistentVolumeClaim:
            claimName: nginx-volumes
  volumeClaimTemplates:
    - metadata:
        name: nginx-volumes
      spec:
        storageClassName: "aws-ebs-volumes"
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 4Gi

3. Once you apply the above manifest, the EBS volumes will be created and attached to the worker nodes.

IMPORTANT WARNING: The CRDs from the AWS EBS CSI driver and AWS external cloud provider gives issue while installing the respective controllers on the AWS Cluster, it doesn’t allow statefulsets to create the volume on existing EC2 instance. We need the CSI controller deployment and CCM pinned to the control plane which has right permissions to create, attach and mount the volumes to EC2 instances. To achieve this, you should add the node affinity rules to the CSI driver controller deployment and CCM DaemonSet manifests.

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule
- effect: NoSchedule
  key: node-role.kubernetes.io/control-plane
affinity:
  nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
      - matchExpressions:
          - key: node-role.kubernetes.io/control-plane
            operator: Exists
      - matchExpressions:
          - key: node-role.kubernetes.io/master
            operator: Exists

Validated upgrade paths for existing clusters

From Kubernetes 1.23 onwards, CSIMigrationAWS flag is enabled by default, which requires the installation of external CSI driver, unless CSIMigrationAWS is disabled by the user. For installing external CSI/CCM in the upgraded cluster, CRS can be used, see the section above for details.

CCM and CSI do not need to be migrated to use external plugins at the same time, external CSI drivers works with in-tree CCM (Warning: using in-tree CSI with external CCM does not work).

Following 3 upgrade paths are validated:

• Scenario 1: During upgrade to v1.23.x, disabling CSIMigrationAWS flag and keep using in-tree CCM and CSI.
• Scenario 2: During upgrade to v1.23.x, enabling CSIMigrationAWS flag and using in-tree CCM with external CSI.
• Scenario 3: During upgrade to v1.23.x, enabling CSIMigrationAWS flag and using external CCM and CSI.

KubeadmConfig in the upgraded cluster for scenario 1:

clusterConfiguration:
  apiServer:
    extraArgs:
      cloud-provider: aws
  controllerManager:
    extraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=false
initConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=false
    name: '{{ ds.meta_data.local_hostname }}'
joinConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=false

KubeadmConfig in the upgraded cluster for scenario 2:

When CSIMigrationAWS=true, installed external CSI driver will be used while relying on in-tree CCM.

clusterConfiguration:
  apiServer:
    extraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=true   // Set only if Kubernetes version < 1.23.x, otherwise this flag is enabled by default.
  controllerManager:
    extraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=true   // Set only if Kubernetes version < 1.23.x, otherwise this flag is enabled by default.
initConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=true   // Set only if Kubernetes version < 1.23.x, otherwise this flag is enabled by default.
joinConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: aws
      feature-gates: CSIMigrationAWS=true   // Set only if Kubernetes version < 1.23.x, otherwise this flag is enabled by default.

KubeadmConfig in the upgraded cluster for scenario 3:

external-cloud-volume-plugin flag needs to be set for old Kubelets to keep talking to in-tree CCM and upgrade fails without this is set.

clusterConfiguration:
  apiServer:
    extraArgs:
      cloud-provider: external
  controllerManager:
    extraArgs:
      cloud-provider: external
      external-cloud-volume-plugin: aws
initConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: external
joinConfiguration:
  nodeRegistration:
    kubeletExtraArgs:
      cloud-provider: external

Restricting Cluster API to certain namespaces

Cluster-api-provider-aws controllers by default, reconcile cluster-api objects across all namespaces in the cluster. However, it is possible to restrict reconciliation to a single namespace and this document tells you how.

Contents

• Use cases
• Configuring cluster-api-provider-aws controllers

Use cases

• Grouping clusters into a namespace based on the AWS account will allow managing clusters across multiple AWS accounts. This will require each cluster-api-provider-aws controller to have credentials to their respective AWS accounts. These credentials can be created as kubernetes secret and be mounted in the pod at /home/.aws or as environment variables.
• Grouping clusters into a namespace based on their environment, (test, qualification, canary, production) will allow a phased rolling out of cluster-api-provider-aws releases.
• Grouping clusters into a namespace based on the infrastructure provider will allow running multiple cluster-api provider implementations side-by-side and manage clusters across infrastructure providers.

Configuring cluster-api-provider-aws controllers

• Create the namespace that cluster-api-provider-aws controller will watch for cluster-api objects

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: my-pet-clusters #edit if necessary
EOF

• Deploy/edit aws-provider-controller-manager controller statefulset

Specifically, edit the container spec for cluster-api-aws-controller, in the aws-provider-controller-manager statefulset, to pass a value to the namespace CLI flag.

        - -namespace=my-pet-clusters # edit this if necessary

Once the aws-provider-controller-manager-0 pod restarts, cluster-api-provider-aws controllers will only reconcile the cluster-api objects in the my-pet-clusters namespace.

Using IAM roles in management cluster instead of AWS credentials

Overview

Sometimes users might want to use IAM roles to deploy management clusters. If the user already has a management cluster which was created using the AWS credentials, CAPA provides a way to use IAM roles instead of using these credentials.

Pre-requisites

User has a bootstrap cluster created with AWS credentials. These credentials can be temporary as well. To create temporary credentials, please follow this doc.

We can verify whether this bootstrap cluster is using AWS credentials by checking the capa-manager-bootstrap-credentials secret created in capa-system namespace:

kubectl get secret -n capa-system capa-manager-bootstrap-credentials -o=jsonpath='{.data.credentials}' | { base64 -d 2>/dev/null || base64 -D; }

which will give output similar to below:

[default]
aws_access_key_id = <your-access-key>
aws_secret_access_key = <your-secret-access-key>
region = us-east-1

aws_session_token = <session-token>

Goal

Create a management cluster which uses instance profiles (IAM roles) attached to EC2 instance.

Steps for CAPA-managed clusters

1. Create a workload cluster on existing bootstrap cluster. Refer quick start guide for more details. Since only control-plane nodes have the required IAM roles attached, CAPA deployment should have the necessary tolerations for master (control-plane) node and node selector for master.

Note: A cluster with a single control plane node won’t be sufficient here due to the NoSchedule taint.

2. Get the kubeconfig for the new target management cluster(created in previous step) once it is up and running.

3. Zero the credentials CAPA controller started with, such that target management cluster uses empty credentials and not the previous credentials used to create bootstrap cluster using:

   clusterawsadm controller zero-credentials --namespace=capa-system
   

   For more details, please refer zero-credentials doc.

4. Rollout and restart on capa-controller-manager deployment using:

   clusterawsadm controller rollout-controller --kubeconfig=kubeconfig --namespace=capa-system
   

   For more details, please refer rollout-controller doc.

5. Use clusterctl init with the new cluster’s kubeconfig to install the provider components. For more details on preparing for init, please refer clusterctl init doc.

6. Use clusterctl move to move the Cluster API resources from the bootstrap cluster to the target management cluster. For more details on preparing for move, please refer clusterctl move doc.

7. Once the resources are moved to target management cluster successfully, capa-manager-bootstrap-credentials will be created as nil, and hence CAPA controllers will fall back to use the attached instance profiles.

8. Delete the bootstrap cluster with the AWS credentials.

Failure Domains

A failure domain in the AWS provider corresponds to an availability zone within an AWS region.

In AWS, Availability Zones are distinct locations within an AWS Region that are engineered to be isolated from failures in other Availability Zones. They provide inexpensive, low-latency network connectivity to other Availability Zones in the same AWS Region, to ensure a cluster (or any application) is resilient to failure.

If a zone goes down, your cluster will continue to run as the other 2 zones are physically separated and can continue to run.

More details of availability zones and regions can be found in the AWS docs.

The usage of failure domains for control-plane and worker nodes can be found below in detail:

• Control Plane
• Worker nodes

Failure domains in control-plane nodes

By default, the control plane of a workload cluster created by CAPA will span multiple availability zones (AZs) (also referred to as “failure domains”) when using multiple control plane nodes. This is because CAPA will, by default, create public and private subnets in all the AZs of a region (up to a maximum of 3 AZs by default). If a region has more than 3 AZs then CAPA will pick 3 AZs to use.

Configuring CAPA to Use Specific AZs

The Cluster API controller will look for the FailureDomain status field and will set the FailureDomain field in a Machine if a value hasn’t already been explicitly set. It will try to ensure that the machines are spread across all the failure domains.

The AWSMachine controller looks for a failure domain (i.e. Availability Zone) first in the Machine before checking in the network specification of AWSMachine. This failure domain is then used when provisioning the AWSMachine.

Using FailureDomain in Machine/MachineDeployment spec

To control the placement of AWSMachine into a failure domain (i.e. Availability Zones), we can explicitly state the failure domain in Machine. The best way is to specify this using the FailureDomain field within the Machine (or MachineDeployment) spec.

For example:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Machine
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: my-cluster
    cluster.x-k8s.io/control-plane: "true"
  name: controlplane-0
  namespace: default
spec:
  version: "v1.22.1"
  clusterName: my-cluster
  failureDomain: "1"
  bootstrap:
    configRef:
        apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
        kind: KubeadmConfigTemplate
        name: my-cluster-md-0
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSMachineTemplate
    name: my-cluster-md-0

IMPORTANT WARNING: All the replicas within a MachineDeployment will reside in the same Availability Zone.

Using FailureDomain in network object of AWSMachine

Another way to explicitly instruct CAPA to create resources in specific AZs (and not by random), users can add a network object to the AWSCluster specification. Here is an example network that creates resources across three AZs in the “us-west-2” region:

spec:
  network:
    vpc:
      cidrBlock: 10.50.0.0/16
    subnets:
    - availabilityZone: us-west-2a
      cidrBlock: 10.50.0.0/20
      isPublic: true
    - availabilityZone: us-west-2a
      cidrBlock: 10.50.16.0/20
    - availabilityZone: us-west-2b
      cidrBlock: 10.50.32.0/20
      isPublic: true
    - availabilityZone: us-west-2b
      cidrBlock: 10.50.48.0/20
    - availabilityZone: us-west-2c
      cidrBlock: 10.50.64.0/20
      isPublic: true
    - availabilityZone: us-west-2c
      cidrBlock: 10.50.80.0/20

Note: This method can also be used with worker nodes as well.

Specifying the CIDR block alone for the VPC is not enough; users must also supply a list of subnets that provides the desired AZ, the CIDR for the subnet, and whether the subnet is public (has a route to an Internet gateway) or is private (does not have a route to an Internet gateway).

Note that CAPA insists that there must be a public subnet (and associated Internet gateway), even if no public load balancer is requested for the control plane. Therefore, for every AZ where a control plane node should be placed, the network object must define both a public and private subnet.

Once CAPA is provided with a network that spans multiple AZs, the KubeadmControlPlane controller will automatically distribute control plane nodes across multiple AZs. No further configuration from the user is required.

Note: This method can also be used if you do not want to split your EC2 instances across multiple AZs.

Changing AZ defaults

When creating default subnets by default a maximum of 3 AZs will be used. If you are creating a cluster in a region that has more than 3 AZs then 3 AZs will be picked based on alphabetical from that region.

If this default behavior for maximum number of AZs and ordered selection method doesn’t suit your requirements you can use the following to change the behaviour:

• availabilityZoneUsageLimit - specifies the maximum number of availability zones (AZ) that should be used in a region when automatically creating subnets.
• availabilityZoneSelection - specifies how AZs should be selected if there are more AZs in a region than specified by availabilityZoneUsageLimit. There are 2 selection schemes:
  • Ordered - selects based on alphabetical order
  • Random - selects AZs randomly in a region

For example if you wanted have a maximum of 2 AZs using a random selection scheme:

spec:
  network:
    vpc:
      availabilityZoneUsageLimit: 2
      availabilityZoneSelection: Random

Caveats

Deploying control plane nodes across multiple AZs is not a panacea to cure all availability concerns. The sizing and overall utilization of the cluster will greatly affect the behavior of the cluster and the workloads hosted there in the event of an AZ failure. Careful planning is needed to maximize the availability of the cluster even in the face of an AZ failure. There are also other considerations, like cross-AZ traffic charges, that should be taken into account.

Failure domains in worker nodes

To ensure that the worker machines are spread across failure domains, we need to create N MachineDeployment for your N failure domains, scaling them independently. Resiliency to failures comes from having multiple MachineDeployment. For example:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: ${CLUSTER_NAME}-md-0
  namespace: default
spec:
  clusterName: ${CLUSTER_NAME}
  replicas: ${WORKER_MACHINE_COUNT}
  selector:
    matchLabels: null
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: ${CLUSTER_NAME}-md-0
      clusterName: ${CLUSTER_NAME}
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: ${CLUSTER_NAME}-md-0
      version: ${KUBERNETES_VERSION}
      failureDomain: "1"
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: ${CLUSTER_NAME}-md-1
  namespace: default
spec:
  clusterName: ${CLUSTER_NAME}
  replicas: ${WORKER_MACHINE_COUNT}
  selector:
    matchLabels: null
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: ${CLUSTER_NAME}-md-1
      clusterName: ${CLUSTER_NAME}
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: ${CLUSTER_NAME}-md-1
      version: ${KUBERNETES_VERSION}
      failureDomain: "2"
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: ${CLUSTER_NAME}-md-2
  namespace: default
spec:
  clusterName: ${CLUSTER_NAME}
  replicas: ${WORKER_MACHINE_COUNT}
  selector:
    matchLabels: null
  template:
    spec:
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: ${CLUSTER_NAME}-md-2
      clusterName: ${CLUSTER_NAME}
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: ${CLUSTER_NAME}-md-2
      version: ${KUBERNETES_VERSION}
      failureDomain: "3"

IMPORTANT WARNING: All the replicas within a MachineDeployment will reside in the same Availability Zone.

Using AWSMachinePool

You can use an AWSMachinePool object which automatically distributes worker machines across the configured availability zones. Set the FailureDomains field to the list of availability zones that you want to use. Be aware that not all regions have the same availability zones.

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: my-cluster
  name: ${CLUSTER_NAME}-mp-0
  namespace: default
spec:
  clusterName: my-cluster
  failureDomains:
    - "1"
    - "3"
  replicas: 3
  template:
    spec:
      clusterName: my-cluster
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: ${CLUSTER_NAME}-mp-0
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachinePool
        name: ${CLUSTER_NAME}-mp-0
      version: ${KUBERNETES_VERSION}
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachinePool
metadata:
  labels:
    cluster.x-k8s.io/cluster-name: my-cluster
  name: ${CLUSTER_NAME}-mp-0
  namespace: default
spec:
  minSize: 1
  maxSize: 4
  awsLaunchTemplate:
    instanceType: ${AWS_NODE_MACHINE_TYPE}
    iamInstanceProfile: "nodes.cluster-api-provider-aws.sigs.k8s.io"
    sshKeyName: ${AWS_SSH_KEY_NAME}

Userdata Privacy

Cluster API Provider AWS bootstraps EC2 instances to create and join Kubernetes clusters using instance user data. Because Kubernetes clusters are secured using TLS using multiple Certificate Authorities, these are generated by Cluster API and injected into the user data. It is important to note that without the configuring of host firewalls, processes can retrieve instance userdata from http://169.254.169.254/latest/api/token

Requirements

• An AMI that includes the AWS CLI
• AMIs using CloudInit
• A working /bin/bash shell
• LFS directory layout (i.e. /etc exists and is readable by CloudInit)

Listed AMIs on 1.16 and up should include the AWS CLI.

How Cluster API secures TLS secrets

Since v0.5.x, Cluster API Provider AWS has used AWS Secrets Manager as a limited-time secret store, storing the userdata using KMS encryption at rest in AWS. The EC2 IMDS userdata will contain a boot script to download the encrypted userdata secret using instance profile permissions, then immediately delete it from AWS Secrets Manager, and then execute it.

To avoid guessing keys in the AWS Secrets Manager key-value store and to prevent collisions, the key is an encoding the Kubernetes namespace, cluster name and instance name, with a random string appended, providing ~256-bits of entropy.

Cluster API Provider AWS also stores the secret ARN in the AWSMachine spec, and will delete the secret if it isn’t already deleted and the machine has registered successfully against the workload cluster API server as a node. Cluster API Provider AWS will also attempt deletion of the secret if the AWSMachine is otherwise deleted or the EC2 instance is terminated or failed.

This method is only compatible with operating systems and distributions using cloud-init. If you are using a different bootstrap process, you will need to co-ordinate this externally and set the following in the specification of the AWSMachine types to disable the use of a cloud-init boothook:

cloudInit:
  insecureSkipSecretsManager: true

Troubleshooting

Script errors

cloud-init does not print boothook script errors to the systemd journal. Logs for the script, if it errored can be found in /var/log/cloud-init-output.log

Warning messages

Because cloud-init will attempt to read the final file at start, cloud-init will always print a /etc/secret-userdata.txt cannot be found message. This can be safely ignored.

Secrets manager console

The AWS secrets manager console should show secrets being created and deleted, with a lifetime of around a minute. No plaintext secret data will appear in the console as Cluster API Provider AWS stores the userdata as fragments of a gzipped data stream.

Troubleshooting

Resources aren’t being created

TODO

Target cluster’s control plane machine is up but target cluster’s apiserver not working as expected

If aws-provider-controller-manager-0 logs did not help, you might want to look into cloud-init logs, /var/log/cloud-init-output.log, on the controller host. Verifying kubelet status and logs may also provide hints:

journalctl -u kubelet.service
systemctl status kubelet

For reaching controller host from your local machine:

 ssh -i <private-key> -o "ProxyCommand ssh -W %h:%p -i <private-key> ubuntu@<bastion-IP>" ubuntu@<controller-host-IP>

private-key is the private key from the key-pair discussed in the ssh key pair section above.

kubelet on the control plane host failing with error: NoCredentialProviders

failed to run Kubelet: could not init cloud provider "aws": error finding instance i-0c276f2a1f1c617b2: "error listing AWS instances: \"NoCredentialProviders: no valid providers in chain. Deprecated.\\n\\tFor verbose messaging see aws.Config.CredentialsChainVerboseErrors\""

This error can occur if CloudFormation stack is not created properly and IAM instance profile is missing appropriate roles. Run following command to inspect IAM instance profile:

$ aws iam get-instance-profile --instance-profile-name control-plane.cluster-api-provider-aws.sigs.k8s.io --output json
{
    "InstanceProfile": {
        "InstanceProfileId": "AIPAJQABLZS4A3QDU576Q",
        "Roles": [
            {
                "AssumeRolePolicyDocument": {
                    "Version": "2012-10-17",
                    "Statement": [
                        {
                            "Action": "sts:AssumeRole",
                            "Effect": "Allow",
                            "Principal": {
                                "Service": "ec2.amazonaws.com"
                            }
                        }
                    ]
                },
                "RoleId": "AROAJQABLZS4A3QDU576Q",
                "CreateDate": "2019-05-13T16:45:12Z",
                "RoleName": "control-plane.cluster-api-provider-aws.sigs.k8s.io",
                "Path": "/",
                "Arn": "arn:aws:iam::123456789012:role/control-plane.cluster-api-provider-aws.sigs.k8s.io"
            }
        ],
        "CreateDate": "2019-05-13T16:45:28Z",
        "InstanceProfileName": "control-plane.cluster-api-provider-aws.sigs.k8s.io",
        "Path": "/",
        "Arn": "arn:aws:iam::123456789012:instance-profile/control-plane.cluster-api-provider-aws.sigs.k8s.io"
    }
}

If instance profile does not look as expected, you may try recreating the CloudFormation stack using clusterawsadm as explained in the above sections.

Recover a management cluster after losing the api server load balancer

These steps outline the process for recovering a management cluster after losing the load balancer for the api server. These steps are needed because AWS load balancers have dynamically generated DNS names. This means that when a load balancer is deleted CAPA will recreate the load balancer but it will have a different DNS name that does not match the original, so we need to update some resources as well as the certs to match the new name to make the cluster healthy again. There are a few different scenarios which this could happen.

• The load balancer gets deleted by some external process or user.
• If a cluster is created with the same name as the management cluster in a different namespace and then deleted it will delete the existing load balancer. This is due to ownership of AWS resources being managed by tags. See this issue for reference.

Access the api server locally

1. ssh to a control plane node and modify the /etc/kubernetes/admin.conf

   • Replace the server with server: https://localhost:6443

   • Add insecure-skip-tls-verify: true

   • Comment out certificate-authority-data:

2. Export the kubeconfig and ensure you can connect

   export KUBECONFIG=/etc/kubernetes/admin.conf
   kubectl get nodes
   

Get rid of the lingering duplicate cluster

This step is only needed in the scenario that duplicate cluster was created and deleted which caused the API server load balancer to be deleted.

1. since there is a duplicate cluster that is trying to be deleted and can’t due to some resources being unable to cleanup since they are in use we need to stop the conflicting reconciliation process. Edit the duplicate aws cluster object and remove the finalizers

   kubectl edit awscluster <clustername>
   

2. next run kubectl describe awscluster <clustername> to validate that the finalizers have been removed

3. kubectl get clusters to verify the cluster is gone

Make at least one node Ready

1. Right now all endpoints are down due to nodes not being ready. this is problematic for coredns adn cni pods in particular. let’s get one control plane node back healthy. on the control plane node we logged into edit the /etc/kubernetes/kubelet.conf

   • Replace the server with server: https://localhost:6443

   • Add insecure-skip-tls-verify: true

   • Comment out certificate-authority-data:

   • Restart the kubelet systemctl restart kubelet

2. kubectl get nodes and validate that the node is in a ready state.

3. After a few minutes most things should start scheduling themselves on the new node. The pods that did not restart on their own that were causing issues were core-dns,kube-proxy, and cni pods.Those should be restart manually.

4. (optional) tail the capa logs to see the load balancer start to reconcile

   kubectl logs -f -n capa-system deployments.apps/capa-controller-manager`
   

Update the control plane nodes with new LB settings

1. To be safe we will do this on all CP nodes rather than having them recreate to avoid potential data loss issues. Follow the following steps for each CP node.

2. Regenrate the certs for the api server using the new name. Make sure to update your service cidr and endpoint in the below command.

   rm /etc/kubernetes/pki/apiserver.crt
   rm /etc/kubernetes/pki/apiserver.key
   
   kubeadm init phase certs apiserver --control-plane-endpoint="mynewendpoint.com" --service-cidr=100.64.0.0/13 -v10
   

3. Update settings in /etc/kubernetes/admin.conf

   • Replace the server with server: https://<your-new-lb.com>:6443

   • Remove insecure-skip-tls-verify: true

   • Uncomment certificate-authority-data:

   • Export the kubeconfig and ensure you can connect

     export KUBECONFIG=/etc/kubernetes/admin.conf
     kubectl get nodes
     

4. Update the settings in /etc/kubernetes/kubelet.conf

   • Replace the server with server: https://your-new-lb.com:6443

   • Remove insecure-skip-tls-verify: true

   • Uncomment certificate-authority-data:

   • restart the kubelet systemctl restart kubelet

5. Just as we did before we need new pods to pick up api server cache changes so you will want to force restart pods like cni pods, kube-proxy, core-dns , etc.

Update capi settings for new LB DNS name

1. Update the control plane endpoint on the awscluster and cluster objects. To do this we need to disable the validatingwebhooks. We will back them up and then delete so we can apply later.

   kubectl get validatingwebhookconfigurations capa-validating-webhook-configuration -o yaml > capa-webhook && kubectl delete validatingwebhookconfigurations capa-validating-webhook-configuration
   
   kubectl get validatingwebhookconfigurations capi-validating-webhook-configuration -o yaml > capi-webhook && kubectl delete validatingwebhookconfigurations capi-validating-webhook-configuration
   

2. Edit the spec.controlPlaneEndpoint.host field on both awscluster and cluster to have the new endpoint

3. Re-apply your webhooks

   kubectl apply -f capi-webhook
   kubectl apply -f capa-webhook
   

4. Update the following config maps and replace the old control plane name with the new one.

   kubectl edit cm -n kube-system kubeadm-config
   kubectl edit cm -n kube-system kube-proxy
   kubectl edit cm -n kube-public cluster-info
   

5. Edit the cluster kubeconfig secret that capi uses to talk to the management cluster. You will need to decode teh secret, replace the endpoint and re-encode and save.

   kubectl edit secret -n <namespace> <cluster-name>-kubeconfig`
   

6. At this point things should start to reconcile on their own, but we can use the commands in the next step to force it.

Roll all of the nodes to make sure everything is fresh

1. kubectl patch kcp <clusternamekcp> -n namespace --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}"
   

2.  kubectl patch machinedeployment CLUSTER_NAME-md-0 -n namespace --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
   

IAM Permissions

Required to use clusterawsadm to provision IAM roles via CloudFormation

If using clusterawsadm to automate deployment of IAM roles via CloudFormation, you must have IAM administrative access as clusterawsadm will provision IAM roles and policies.

Required by Cluster API Provider AWS controllers

The Cluster API Provider AWS controller requires permissions to use EC2, ELB Autoscaling and optionally EKS. If provisioning IAM roles using clusterawsadm, these will be set up as the controllers.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the controllers.cluster-api-provider-aws.sigs.k8s.io and control-plane.cluster-api-provider-aws.sigs.k8s.io IAM roles.

EC2 Provisioned Kubernetes Clusters

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeIpamPools",
        "ec2:AllocateIpamPoolCidr",
        "ec2:AttachNetworkInterface",
        "ec2:DetachNetworkInterface",
        "ec2:AllocateAddress",
        "ec2:AssignIpv6Addresses",
        "ec2:AssignPrivateIpAddresses",
        "ec2:UnassignPrivateIpAddresses",
        "ec2:AssociateRouteTable",
        "ec2:AssociateVpcCidrBlock",
        "ec2:AttachInternetGateway",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateCarrierGateway",
        "ec2:CreateInternetGateway",
        "ec2:CreateEgressOnlyInternetGateway",
        "ec2:CreateNatGateway",
        "ec2:CreateNetworkInterface",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVpc",
        "ec2:CreateVpcEndpoint",
        "ec2:DisassociateVpcCidrBlock",
        "ec2:ModifyVpcAttribute",
        "ec2:ModifyVpcEndpoint",
        "ec2:DeleteCarrierGateway",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteEgressOnlyInternetGateway",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRouteTable",
        "ec2:ReplaceRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteTags",
        "ec2:DeleteVpc",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAddresses",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeCarrierGateways",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeEgressOnlyInternetGateways",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeImages",
        "ec2:DescribeNatGateways",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeNetworkInterfaceAttribute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeDhcpOptions",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeVolumes",
        "ec2:DescribeTags",
        "ec2:DetachInternetGateway",
        "ec2:DisassociateRouteTable",
        "ec2:DisassociateAddress",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:ModifySubnetAttribute",
        "ec2:ReleaseAddress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "tag:GetResources",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:SetSecurityGroups",
        "elasticloadbalancing:DescribeTags",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:RemoveTags",
        "elasticloadbalancing:SetSubnets",
        "elasticloadbalancing:ModifyTargetGroupAttributes",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:DeleteListener",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeInstanceRefreshes",
        "ec2:CreateLaunchTemplate",
        "ec2:CreateLaunchTemplateVersion",
        "ec2:DescribeLaunchTemplates",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DeleteLaunchTemplate",
        "ec2:DeleteLaunchTemplateVersions",
        "ec2:DescribeKeyPairs",
        "ec2:ModifyInstanceMetadataOptions"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CreateAutoScalingGroup",
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:CreateOrUpdateTags",
        "autoscaling:StartInstanceRefresh",
        "autoscaling:DeleteAutoScalingGroup",
        "autoscaling:DeleteTags"
      ],
      "Resource": [
        "arn:*:autoscaling:*:*:autoScalingGroup:*:autoScalingGroupName/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "spot.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/*.cluster-api-provider-aws.sigs.k8s.io"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:TagResource"
      ],
      "Resource": [
        "arn:*:secretsmanager:*:*:secret:aws.cluster.x-k8s.io/*"
      ]
    }
  ]
}

With EKS Support

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeIpamPools",
        "ec2:AllocateIpamPoolCidr",
        "ec2:AttachNetworkInterface",
        "ec2:DetachNetworkInterface",
        "ec2:AllocateAddress",
        "ec2:AssignIpv6Addresses",
        "ec2:AssignPrivateIpAddresses",
        "ec2:UnassignPrivateIpAddresses",
        "ec2:AssociateRouteTable",
        "ec2:AssociateVpcCidrBlock",
        "ec2:AttachInternetGateway",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateCarrierGateway",
        "ec2:CreateInternetGateway",
        "ec2:CreateEgressOnlyInternetGateway",
        "ec2:CreateNatGateway",
        "ec2:CreateNetworkInterface",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVpc",
        "ec2:CreateVpcEndpoint",
        "ec2:DisassociateVpcCidrBlock",
        "ec2:ModifyVpcAttribute",
        "ec2:ModifyVpcEndpoint",
        "ec2:DeleteCarrierGateway",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteEgressOnlyInternetGateway",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRouteTable",
        "ec2:ReplaceRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteTags",
        "ec2:DeleteVpc",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAddresses",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeCarrierGateways",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeEgressOnlyInternetGateways",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeImages",
        "ec2:DescribeNatGateways",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeNetworkInterfaceAttribute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeDhcpOptions",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeVolumes",
        "ec2:DescribeTags",
        "ec2:DetachInternetGateway",
        "ec2:DisassociateRouteTable",
        "ec2:DisassociateAddress",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:ModifySubnetAttribute",
        "ec2:ReleaseAddress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "tag:GetResources",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:SetSecurityGroups",
        "elasticloadbalancing:DescribeTags",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:RemoveTags",
        "elasticloadbalancing:SetSubnets",
        "elasticloadbalancing:ModifyTargetGroupAttributes",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:DeleteListener",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeInstanceRefreshes",
        "ec2:CreateLaunchTemplate",
        "ec2:CreateLaunchTemplateVersion",
        "ec2:DescribeLaunchTemplates",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DeleteLaunchTemplate",
        "ec2:DeleteLaunchTemplateVersions",
        "ec2:DescribeKeyPairs",
        "ec2:ModifyInstanceMetadataOptions"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CreateAutoScalingGroup",
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:CreateOrUpdateTags",
        "autoscaling:StartInstanceRefresh",
        "autoscaling:DeleteAutoScalingGroup",
        "autoscaling:DeleteTags"
      ],
      "Resource": [
        "arn:*:autoscaling:*:*:autoScalingGroup:*:autoScalingGroupName/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "spot.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/*.cluster-api-provider-aws.sigs.k8s.io"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:TagResource"
      ],
      "Resource": [
        "arn:*:secretsmanager:*:*:secret:aws.cluster.x-k8s.io/*"
      ]
    }
  ]
}

With S3 Support

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeIpamPools",
        "ec2:AllocateIpamPoolCidr",
        "ec2:AttachNetworkInterface",
        "ec2:DetachNetworkInterface",
        "ec2:AllocateAddress",
        "ec2:AssignIpv6Addresses",
        "ec2:AssignPrivateIpAddresses",
        "ec2:UnassignPrivateIpAddresses",
        "ec2:AssociateRouteTable",
        "ec2:AssociateVpcCidrBlock",
        "ec2:AttachInternetGateway",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateCarrierGateway",
        "ec2:CreateInternetGateway",
        "ec2:CreateEgressOnlyInternetGateway",
        "ec2:CreateNatGateway",
        "ec2:CreateNetworkInterface",
        "ec2:CreateRoute",
        "ec2:CreateRouteTable",
        "ec2:CreateSecurityGroup",
        "ec2:CreateSubnet",
        "ec2:CreateTags",
        "ec2:CreateVpc",
        "ec2:CreateVpcEndpoint",
        "ec2:DisassociateVpcCidrBlock",
        "ec2:ModifyVpcAttribute",
        "ec2:ModifyVpcEndpoint",
        "ec2:DeleteCarrierGateway",
        "ec2:DeleteInternetGateway",
        "ec2:DeleteEgressOnlyInternetGateway",
        "ec2:DeleteNatGateway",
        "ec2:DeleteRouteTable",
        "ec2:ReplaceRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteSubnet",
        "ec2:DeleteTags",
        "ec2:DeleteVpc",
        "ec2:DeleteVpcEndpoints",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAddresses",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeCarrierGateways",
        "ec2:DescribeInstances",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeInternetGateways",
        "ec2:DescribeEgressOnlyInternetGateways",
        "ec2:DescribeInstanceTypes",
        "ec2:DescribeImages",
        "ec2:DescribeNatGateways",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeNetworkInterfaceAttribute",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeDhcpOptions",
        "ec2:DescribeVpcAttribute",
        "ec2:DescribeVpcEndpoints",
        "ec2:DescribeVolumes",
        "ec2:DescribeTags",
        "ec2:DetachInternetGateway",
        "ec2:DisassociateRouteTable",
        "ec2:DisassociateAddress",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:ModifySubnetAttribute",
        "ec2:ReleaseAddress",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:RunInstances",
        "ec2:TerminateInstances",
        "tag:GetResources",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:SetSecurityGroups",
        "elasticloadbalancing:DescribeTags",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:RemoveTags",
        "elasticloadbalancing:SetSubnets",
        "elasticloadbalancing:ModifyTargetGroupAttributes",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:DeleteListener",
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeInstanceRefreshes",
        "ec2:CreateLaunchTemplate",
        "ec2:CreateLaunchTemplateVersion",
        "ec2:DescribeLaunchTemplates",
        "ec2:DescribeLaunchTemplateVersions",
        "ec2:DeleteLaunchTemplate",
        "ec2:DeleteLaunchTemplateVersions",
        "ec2:DescribeKeyPairs",
        "ec2:ModifyInstanceMetadataOptions"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:CreateAutoScalingGroup",
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:CreateOrUpdateTags",
        "autoscaling:StartInstanceRefresh",
        "autoscaling:DeleteAutoScalingGroup",
        "autoscaling:DeleteTags"
      ],
      "Resource": [
        "arn:*:autoscaling:*:*:autoScalingGroup:*:autoScalingGroupName/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/elasticloadbalancing.amazonaws.com/AWSServiceRoleForElasticLoadBalancing"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "elasticloadbalancing.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateServiceLinkedRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/aws-service-role/spot.amazonaws.com/AWSServiceRoleForEC2Spot"
      ],
      "Condition": {
        "StringLike": {
          "iam:AWSServiceName": "spot.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": [
        "arn:*:iam::*:role/*.cluster-api-provider-aws.sigs.k8s.io"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:CreateSecret",
        "secretsmanager:DeleteSecret",
        "secretsmanager:TagResource"
      ],
      "Resource": [
        "arn:*:secretsmanager:*:*:secret:aws.cluster.x-k8s.io/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:PutBucketPolicy",
        "s3:PutBucketTagging"
      ],
      "Resource": [
        "arn:*:s3:::cluster-api-provider-aws-*"
      ]
    }
  ]
}

Required by the Kubernetes AWS Cloud Provider

These permissions are used by the Kubernetes AWS Cloud Provider. If you are running with the in-tree cloud provider, this will typically be used by the controller-manager pod in the kube-system namespace.

If provisioning IAM roles using clusterawsadm, these will be set up as the control-plane.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the control-plane.cluster-api-provider-aws.sigs.k8s.io IAM role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeLaunchConfigurations",
        "autoscaling:DescribeTags",
        "ec2:AssignIpv6Addresses",
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:DescribeRegions",
        "ec2:DescribeRouteTables",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVolumes",
        "ec2:CreateSecurityGroup",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyVolume",
        "ec2:AttachVolume",
        "ec2:AuthorizeSecurityGroupIngress",
        "ec2:CreateRoute",
        "ec2:DeleteRoute",
        "ec2:DeleteSecurityGroup",
        "ec2:DeleteVolume",
        "ec2:DetachVolume",
        "ec2:RevokeSecurityGroupIngress",
        "ec2:DescribeVpcs",
        "elasticloadbalancing:AddTags",
        "elasticloadbalancing:AttachLoadBalancerToSubnets",
        "elasticloadbalancing:ApplySecurityGroupsToLoadBalancer",
        "elasticloadbalancing:SetSecurityGroups",
        "elasticloadbalancing:CreateLoadBalancer",
        "elasticloadbalancing:CreateLoadBalancerPolicy",
        "elasticloadbalancing:CreateLoadBalancerListeners",
        "elasticloadbalancing:ConfigureHealthCheck",
        "elasticloadbalancing:DeleteLoadBalancer",
        "elasticloadbalancing:DeleteLoadBalancerListeners",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:DescribeLoadBalancerAttributes",
        "elasticloadbalancing:DetachLoadBalancerFromSubnets",
        "elasticloadbalancing:DeregisterInstancesFromLoadBalancer",
        "elasticloadbalancing:ModifyLoadBalancerAttributes",
        "elasticloadbalancing:RegisterInstancesWithLoadBalancer",
        "elasticloadbalancing:SetLoadBalancerPoliciesForBackendServer",
        "elasticloadbalancing:CreateListener",
        "elasticloadbalancing:CreateTargetGroup",
        "elasticloadbalancing:DeleteListener",
        "elasticloadbalancing:DeleteTargetGroup",
        "elasticloadbalancing:DeregisterTargets",
        "elasticloadbalancing:DescribeListeners",
        "elasticloadbalancing:DescribeLoadBalancerPolicies",
        "elasticloadbalancing:DescribeTargetGroups",
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:ModifyListener",
        "elasticloadbalancing:ModifyTargetGroup",
        "elasticloadbalancing:RegisterTargets",
        "elasticloadbalancing:SetLoadBalancerPoliciesOfListener",
        "iam:CreateServiceLinkedRole",
        "kms:DescribeKey"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

Required by all nodes

All nodes require these permissions in order to run, and are used by the AWS cloud provider run by kubelet.

If provisioning IAM roles using clusterawsadm, these will be set up as the nodes.cluster-api-provider-aws.sigs.k8s.io IAM Policy, and attached to the nodes.cluster-api-provider-aws.sigs.k8s.io IAM role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:AssignIpv6Addresses",
        "ec2:DescribeInstances",
        "ec2:DescribeRegions",
        "ec2:CreateTags",
        "ec2:DescribeTags",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DescribeInstanceTypes",
        "ecr:GetAuthorizationToken",
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:BatchGetImage"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}

When using EKS, the AmazonEKSWorkerNodePolicy and AmazonEKS_CNI_Policy AWS managed policies will also be attached to nodes.cluster-api-provider-aws.sigs.k8s.io IAM role.

Ignition support

• Feature status: Experimental
• Feature gate: BootstrapFormatIgnition=true

The default configuration engine for bootstrapping workload cluster machines is cloud-init. Ignition is an alternative engine used by Linux distributions such as Flatcar Container Linux and Fedora CoreOS and therefore should be used when choosing an Ignition-based distribution as the underlying OS for workload clusters.

This document explains how Ignition support works.

For more generic information, see Cluster API documentation on Ignition Bootstrap configuration.

Overview

When using CloudInit for bootstrapping, by default the awsmachine controller stores EC2 instance user data using SSM to store it encrypted, which underneath uses multi part mime types. Unfortunately multi part mime types are not supported by Ignition. Moreover EC2 instance user data storage is also limited to 64 KB, which might not always be enough to provision Kubernetes controlplane because of the size of required certificates and configuration files.

To address these limitations, when using Ignition for bootstrapping, by default the awsmachine controller uses a Cluster Object Store (e.g. S3 Bucket), configured in the AWSCluster, to store user data, which will be then pulled by the instances during provisioning.

Optionally, when using Ignition for bootstrapping, users can optionally choose an alternative storageType for user data. For now the single available alternative is to store user data unencrypted directly in the EC2 instance user data. This storageType option is although discouraged unless strictly necessary, as it is not considered as safe as storing it in the S3 Bucket.

Prerequirements for enabling Ignition bootstrapping

Enabling EXP_BOOTSTRAP_FORMAT_IGNITION feature gate

In order to activate Ignition bootstrap you first need to enable its feature gate.

When deploying CAPA using clusterctl, make sure you set BOOTSTRAP_FORMAT_IGNITION=true and EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION=true environment variables to enable experimental Ignition bootstrap support.

# Enable the feature gates controlling Ignition bootstrap.
export EXP_KUBEADM_BOOTSTRAP_FORMAT_IGNITION=true # Used by the kubeadm bootstrap provider.
export EXP_BOOTSTRAP_FORMAT_IGNITION=true # Used by the AWS provider.

# Initialize the management cluster.
clusterctl init --infrastructure aws

Choosing a storage type for Ignition user data

S3 is the default storage type when Ignition is enabled for managing machine’s bootstrapping. But other methods can be choosen for storing Ignition user data.

Store Ignition config in a Cluster Object Store (e.g. S3 bucket)

To explicitly set ClusterObjectStore as the storage type, provide the following config in the AWSMachineTemplate:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
metadata:
  name: "test"
spec:
  template:
    spec:
      ignition:
        storageType: ClusterObjectStore

Cluster Object Store and object management

When you want to use Ignition user data format for you machines, you need to configure your cluster to specify which Cluster Object Store to use. Controller will then check that the bucket already exists and that required policies are in place.

See the configuration snippet below to learn how to configure AWSCluster to manage S3 bucket.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSCluster
spec:
  s3Bucket:
    controlPlaneIAMInstanceProfile: control-plane.cluster-api-provider-aws.sigs.k8s.io
    name: cluster-api-provider-aws-unique-suffix
    nodesIAMInstanceProfiles:
    - nodes.cluster-api-provider-aws.sigs.k8s.io

Buckets are safe to be reused between clusters.

After successful machine provisioning, the bootstrap data is removed from the object store.

During cluster removal, if the Cluster Object Store is empty, it will be deleted as well.

S3 IAM Permissions

If you choose to use an S3 bucket as the Cluster Object Store, CAPA controllers require additional IAM permissions.

If you use clusterawsadm for managing the IAM roles, you can use the configuration below to create S3-related IAM permissions.

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  s3Buckets:
    enable: true

See Using clusterawsadm to fulfill prerequisites for more details.

Cluster Object Store naming

Cluster Object Store and bucket naming must follow S3 Bucket naming rules.

In addition, by default clusterawsadm creates IAM roles to only allow interacting with buckets with cluster-api-provider-aws- prefix to reduce the permissions of CAPA controller, so all bucket names should use this prefix.

To change it, use spec.s3Buckets.namePrefix field in AWSIAMConfiguration.

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  s3Buckets:
    namePrefix: my-custom-secure-bucket-prefix-

Store Ignition config as UnencryptedUserData

To instruct the controllers to store the user data directly in the EC2 instance user data unencrypted, provide the following config in the AWSMachineTemplate:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
metadata:
  name: "test"
spec:
  template:
    spec:
      ignition:
        storageType: UnencryptedUserData

No further requirements are necessary.

Supported bootstrap providers

At the moment only CABPK is known to support producing bootstrap data in Ignition format.

Trying it out

If you want to test Ignition support, use flatcar cluster flavor.

Other bootstrap providers

If you want to use Ignition support with custom bootstrap provider which supports producing Ignition bootstrap data, ensure that bootstrap provider sets the format field in machine bootstrap secret to ignition. This information is used by the machine controller to determine which user data format to use for the instances.

External Resource Garbage Collection

• Feature status: Experimental
• Feature gate (required): ExternalResourceGC=true

Overview

Workload clusters that CAPA has created may have additional resources in AWS that need to be deleted when the cluster is deleted.

For example, if the workload cluster has Services of type LoadBalancer then AWS ELB/NLB are provisioned. If you try to delete the workload cluster in this example, it will fail as these load balancers are still using the VPC.

This feature enables deletion of these external resources as part of cluster deletion. During the deletion of a workload cluster the external AWS resources that where created by the Cloud Controller Manager (CCM) in the workload cluster will be identified and deleted.

NOTE: This is not related to externally managed infrastructure.

Currently, we support cleaning up the following:

• AWS ELB/NLB - by deleting Services of type LoadBalancer from the workload cluster

We will look to support deleting EBS volumes in the future potentially.

Note: this feature will likely be superseded by an upstream CAPI feature in the future when this issue is resolved.

Enabling

To enable garbage collection, you must set the ExternalResourceGC feature gate to true on the controller manager. The easiest way to do this is via an environment variable:

export EXP_EXTERNAL_RESOURCE_GC=true
clusterctl init --infrastructure aws

Note: if you enable this feature ALL clusters will be marked as requiring garbage collection.

Operations

Manually Disabling Garbage Collection for a Cluster

There are 2 ways to manually disable garbage collection for an individual cluster:

Using clusterawsadm

By running the following command:

clusterawsadm gc disable --cluster-name mycluster

See the command help for more examples.

Editing AWSCluster\AWSManagedControlPlane

Or, by editing your AWSCluster or AWSManagedControlPlane so that the annotation aws.cluster.x-k8s.io/external-resource-gc is set to false.

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSManagedControlPlane
metadata:
  annotations:
    aws.cluster.x-k8s.io/external-resource-gc: "false"

Manually Enabling Garbage Collection for a Cluster

There are 2 ways to manually enable garbage collection for an individual cluster:

Using clusterawsadm

By running the following command:

clusterawsadm gc enable --cluster-name mycluster

See the command help for more examples.

Editing AWSCluster\AWSManagedControlPlane

Or, by editing your AWSCluster or AWSManagedControlPlane o that the annotation aws.cluster.x-k8s.io/external-resource-gc is either removed or set to true.

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: AWSManagedControlPlane
metadata:
  annotations:
    aws.cluster.x-k8s.io/external-resource-gc: "true"

Instance Metadata Service

Instance metadata is data about your instance that you can use to configure or manage the running instance which you can access from a running instance using one of the following methods:

• Instance Metadata Service Version 1 (IMDSv1) – a request/response method
• Instance Metadata Service Version 2 (IMDSv2) – a session-oriented method

CAPA defaults to use IMDSv2 as optional property when creating instances.

CAPA expose options to configure IMDSv2 as required when creating instances, as it provides a better level of security.

It is possible to configure the instance metadata options using the field called instanceMetadataOptions in the AWSMachineTemplate.

Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSMachineTemplate
metadata:
  name: "test"
spec:
  template:
    spec:
      instanceMetadataOptions:
        httpEndpoint: enabled
        httpPutResponseHopLimit: 1
        httpTokens: optional
        instanceMetadataTags: disabled

To use IMDSv2, simply set httpTokens value to required (in other words, set the use of IMDSv2 to required). To use IMDSv2, please also set httpPutResponseHopLimit value to 2, as it is recommended in container environment according to AWS document.

Similarly, this can be done with AWSManagedMachinePool for use with EKS Managed Nodegroups. One slight difference here is that you must use Launch Templates to configure IMDSv2 with Autoscaling Groups. In order to configure the LaunchTemplate, you must use a custom AMI type according to the AWS API. This can be done by setting AWSManagedMachinePool.spec.amiType to CUSTOM. This change means that you must also specify a bootstrapping script to the worker node, which allows it to be joined to the EKS cluster. The default AWS Managed Node Group bootstrap script can be found here on Github.

The following example will use the default Amazon EKS Worker Node AMI which includes the default EKS Bootstrapping script. This must be installed on the management cluster as a Secret, under the key value. The secret’s name must then be included in your MachinePool manifest at MachinePool.spec.template.spec.bootstrap.dataSecretName. Some assumptions are made for this example:

• Your cluster name is capi-imds, which CAPA renames to default_capi-imds-control-plane automatically
• Your cluster is Kubernetes Version v1.25.9
• Your AWSManagedCluster is deployed in the default namespace along with the bootstrap secret eks-bootstrap

kind: Secret
apiVersion: v1
type: Opaque
data:
  value: IyEvYmluL2Jhc2ggLXhlCi9ldGMvZWtzL2Jvb3RzdHJhcC5zaCBkZWZhdWx0X2NhcGktaW1kcy1jb250cm9sLXBsYW5l
metadata:
  name: eks-bootstrap
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSManagedMachinePool
metadata:
  name: "capi-imds-pool-launchtemplate"
spec:
  amiType: CUSTOM
  awsLaunchTemplate:
    name: my-aws-launch-template
    instanceType: t3.nano
    metadataOptions:
      httpTokens: required
      httpPutResponseHopLimit: 2
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachinePool
metadata:
  name: "capi-imds-pool-1"
spec:
  clusterName: "capi-imds"
  replicas: 1
  template:
    spec:
      version: v1.25.9
      clusterName: "capi-imds"
      bootstrap:
        dataSecretName: "eks-bootstrap"
      infrastructureRef:
        name: "capi-imds-pool-launchtemplate"
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
        kind: AWSManagedMachinePool

IyEvYmluL2Jhc2ggLXhlCi9ldGMvZWtzL2Jvb3RzdHJhcC5zaCBkZWZhdWx0X2NhcGktaW1kcy1jb250cm9sLXBsYW5l in the above secret is a Base64 encoded version of the following script:

#!/bin/bash -xe
/etc/eks/bootstrap.sh default_capi-imds-control-plane

If your cluster is not named default_capi-imds-control-plane in the AWS EKS console, you must update the name and store it as a Secret again.

See the CLI command reference for more information.

Before you decide to use IMDSv2 for the cluster instances, please make sure all your applications are compatible with IMDSv2.

See the transition guide for more information.

Setting up a Network Load Balancer

Overview

It’s possible to set up and use a Network Load Balancer with AWSCluster instead of the Classic Load Balancer that is created by default.

AWSCluster setting

To make CAPA create a network load balancer simply set the load balancer type to network like this:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: "test-aws-cluster"
spec:
  region: "eu-central-1"
  controlPlaneLoadBalancer:
    loadBalancerType: nlb

This will create the following objects:

• A network load balancer
• Listeners
• A target group

It will also take into consideration IPv6 enabled clusters and create an IPv6 aware load balancer.

Preserve Client IPs

By default, client ip preservation is disabled. This is to avoid hairpinning issues between kubelet and the node registration process. To enable client IP preservation, you can set it to enable with the following flag:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: "test-aws-cluster"
spec:
  region: "eu-central-1"
  sshKeyName: "capa-key"
  controlPlaneLoadBalancer:
    loadBalancerType: nlb
    preserveClientIP: true

Security

NLBs can use security groups, but only if one is associated at the time of creation. CAPA will associate the default control plane security groups with a new NLB by default.

For more information, see AWS’s Network Load Balancer and Security Groups documentation.

Extension of the code

Right now, only NLBs and a Classic Load Balancer is supported. However, the code has been written in a way that it should be easy to extend with an ALB or a GLB.

Enabling a Secondary Control Plane Load Balancer

Overview

It is possible to use a second control plane load balancer within a CAPA cluster. This secondary control plane load balancer is primarily meant to be used for internal cluster traffic, for use cases where traffic between nodes and pods should be kept internal to the VPC network. This adds a layer of privacy to traffic, as well as potentially saving on egress costs for traffic to the Kubernetes API server.

A dual load balancer topology is not used as a default in order to maintain backward compatibility with existing CAPA clusters.

Requirements and defaults

• A secondary control plane load balancer is not created by default.
• The secondary control plane load balancer must be a Network Load Balancer, and will default to this type.
• The secondary control plane load balancer must also be provided a name.
• The secondary control plane’s Scheme defaults to internal, and must be different from the spec.controlPlaneLoadBalancer‘s Scheme.

The secondary load balancer will use the same Security Group information as the primary control plane load balancer.

Creating a secondary load balancer

To create a secondary load balancer, add the secondaryControlPlaneLoadBalancer stanza to your AWSCluster.

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: test-aws-cluster
spec:
  region: us-east-2
  sshKeyName: nrb-default
  secondaryControlPlaneLoadBalancer:
    name: internal-apiserver
    scheme: internal     # optional

Manage Local Zone subnets

Overview

CAPA provides the option to manage network resources required to provision compute nodes to Local Zone and Wavelength Zone locations.

AWS Local Zones extends the cloud infrastructure to metropolitan regions, allowing to deliver applications closer to the end-users, decreasing the network latency.

AWS Wavelength Zones extends the AWS infrastructure deployments infrastructure to carrier infrastructure, allowing to deploy within communications service providers’ (CSP) 5G networks.

When “edge zones” is mentioned in this document, it is referencing to AWS Local Zones and AWS Wavelength Zones.

Requirements and defaults

For both Local Zones and Wavelength Zones (’edge zones’):

• Subnets in edge zones are not created by default.
• When you choose to CAPA manage edge zone’s subnets, you also must specify the regular zones (Availability Zones) you will create the cluster.
• IPv6 is not globally supported by AWS across Local Zones, and is not supported in Wavelength zones, CAPA support is limited to IPv4 subnets in edge zones.
• The subnets in edge zones will not be used by CAPA to create NAT Gateways, Network Load Balancers, or provision Control Plane or Compute nodes by default.
• NAT Gateways are not globally available to edge zone’s locations, the CAPA uses the Parent Zone for the edge zone to create the NAT Gateway to allow the instances on private subnets to egress traffic to the internet.
• The CAPA subnet controllers discovers the zone attributes ZoneType and ParentZoneName for each subnet on creation, those fields are used to ensure subnets for it’s role. For example: only subnets with ZoneType with value availability-zone can be used to create a load balancer for API.
• It is required to manually opt-in to each zone group for edge zones you are planning to create subnets.

The following steps are example to describe the zones and opt-into an zone group for an Local Zone:

- To check the zone group name for a Local Zone, you can use the [EC2 API `DescribeAvailabilityZones`][describe-availability-zones]. For example:

aws --region "<value_of_AWS_Region>" ec2 describe-availability-zones \
    --query 'AvailabilityZones[].[{ZoneName: ZoneName, GroupName: GroupName, Status: OptInStatus}]' \
    --filters Name=zone-type,Values=local-zone \
    --all-availability-zones

- To opt-int the zone group, you can use the [EC2 API `ModifyZoneAttributes`](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyAvailabilityZoneGroup.html):

aws ec2 modify-availability-zone-group \
    --group-name "<value_of_GroupName>" \
    --opt-in-status opted-in

Installing managed clusters extending subnets to Local Zones

To create a cluster with support of subnets on AWS Local Zones, add the Subnets stanza to your AWSCluster.NetworkSpec. Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: aws-cluster-localzone
spec:
  region: us-east-1
  networkSpec:
    vpc:
      cidrBlock: "10.0.0.0/20"
    subnets:
    # regular zones (availability zones)
    - availabilityZone: us-east-1a
      cidrBlock: "10.0.0.0/24"
      id: "cluster-subnet-private-us-east-1a"
      isPublic: false
    - availabilityZone: us-east-1a
      cidrBlock: "10.0.1.0/24"
      id: "cluster-subnet-public-us-east-1a"
      isPublic: true
    - availabilityZone: us-east-1b
      cidrBlock: "10.0.3.0/24"
      id: "cluster-subnet-private-us-east-1b"
      isPublic: false
    - availabilityZone: us-east-1b
      cidrBlock: "10.0.4.0/24"
      id: "cluster-subnet-public-us-east-1b"
      isPublic: true
    - availabilityZone: us-east-1c
      cidrBlock: "10.0.5.0/24"
      id: "cluster-subnet-private-us-east-1c"
      isPublic: false
    - availabilityZone: us-east-1c
      cidrBlock: "10.0.6.0/24"
      id: "cluster-subnet-public-us-east-1c"
      isPublic: true
    # Subnets in Local Zones of New York location (public and private)
    - availabilityZone: us-east-1-nyc-1a
      cidrBlock: "10.0.128.0/25"
      id: "cluster-subnet-private-us-east-1-nyc-1a"
      isPublic: false
    - availabilityZone: us-east-1-nyc-1a
      cidrBlock: "10.0.128.128/25"
      id: "cluster-subnet-public-us-east-1-nyc-1a"
      isPublic: true

Installing managed clusters extending subnets to Wavelength Zones

To create a cluster with support of subnets on AWS Wavelength Zones, add the Subnets stanza to your AWSCluster.NetworkSpec. Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: aws-cluster-wavelengthzone
spec:
  region: us-east-1
  networkSpec:
    vpc:
      cidrBlock: "10.0.0.0/20"
    subnets:
    # <placeholder for regular zones (availability zones)>
    - availabilityZone: us-east-1-wl1-was-wlz-1
      cidrBlock: "10.0.128.0/25"
      id: "cluster-subnet-private-us-east-1-wl1-was-wlz-1"
      isPublic: false
    - availabilityZone: us-east-1-wl1-was-wlz-1
      cidrBlock: "10.0.128.128/25"
      id: "cluster-subnet-public-us-east-1-wl1-was-wlz-1"
      isPublic: true

Installing managed clusters extending subnets to Local and Wavelength Zones

It is also possible to mix the creation across both Local and Wavelength zones.

To create a cluster with support of edge zones, add the Subnets stanza to your AWSCluster.NetworkSpec. Example:

---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: aws-cluster-edge
spec:
  region: us-east-1
  networkSpec:
    vpc:
      cidrBlock: "10.0.0.0/20"
    subnets:
    # <placeholder for regular zones (availability zones)>
    - availabilityZone: us-east-1-nyc-1a
      cidrBlock: "10.0.128.0/25"
      id: "cluster-subnet-private-us-east-1-nyc-1a"
      isPublic: false
    - availabilityZone: us-east-1-nyc-1a
      cidrBlock: "10.0.128.128/25"
      id: "cluster-subnet-public-us-east-1-nyc-1a"
      isPublic: true
    - availabilityZone: us-east-1-wl1-was-wlz-1
      cidrBlock: "10.0.129.0/25"
      id: "cluster-subnet-private-us-east-1-wl1-was-wlz-1"
      isPublic: false
    - availabilityZone: us-east-1-wl1-was-wlz-1
      cidrBlock: "10.0.129.128/25"
      id: "cluster-subnet-public-us-east-1-wl1-was-wlz-1"
      isPublic: true

clusterawsadm

Kubernetes Cluster API Provider AWS Management Utility

Synopsis

clusterawsadm provides helpers for bootstrapping Kubernetes Cluster API Provider AWS. Use clusterawsadm to view required AWS Identity and Access Management (IAM) policies as JSON docs, or create IAM roles and instance profiles automatically using AWS CloudFormation.

clusterawsadm additionally helps provide credentials for use with clusterctl.

clusterawsadm [flags]

Examples

  # Create AWS Identity and Access Management (IAM) roles for use with
  # Kubernetes Cluster API Provider AWS.
  clusterawsadm bootstrap iam create-cloudformation-stack
  
  # Encode credentials for use with clusterctl init
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help    help for clusterawsadm
  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands
• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm controller - controller commands
• clusterawsadm eks - Commands related to EKS
• clusterawsadm gc - Commands related to garbage collecting external resources of clusters
• clusterawsadm resource - Commands related to AWS resources
• clusterawsadm version - Print version of clusterawsadm

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm controller

controller commands

Synopsis

All controller related actions such as:

Zero controller credentials and rollout controllers

clusterawsadm controller [command] [flags]

Options

  -h, --help   help for controller

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm controller print-credentials - print credentials the controller is using
• clusterawsadm controller rollout-controller - initiates rollout and restart on capa-controller-manager deployment
• clusterawsadm controller update-credentials - update credentials the controller is using (i.e., update controller bootstrap secret)
• clusterawsadm controller zero-credentials - zero credentials the controller is started with

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm controller print-credentials

print credentials the controller is using

Synopsis

print credentials the controller is using

clusterawsadm controller print-credentials [flags]

Examples

  # print credentials
  clusterawsadm controller print-credentials --kubeconfig=kubeconfig --namespace=capa-system

Options

  -h, --help                        help for print-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm controller rollout-controller

initiates rollout and restart on capa-controller-manager deployment

Synopsis

initiates rollout and restart on capa-controller-manager deployment

clusterawsadm controller rollout-controller [flags]

Examples

  # rollout controller deployment
  clusterawsadm controller rollout-controller --kubeconfig=kubeconfig --namespace=capa-system

Options

  -h, --help                        help for rollout-controller
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm controller update-credentials

update credentials the controller is using (i.e., update controller bootstrap secret)

Synopsis

Update credentials the controller is started with

clusterawsadm controller update-credentials [flags]

Examples

  # update credentials: AWS_B64ENCODED_CREDENTIALS environment variable must be set and be used to update the bootstrap secret
  # Kubeconfig file will be searched in default locations
  clusterawsadm controller update-credentials --namespace=capa-system
  # Provided kubeconfig file will be used
  clusterawsadm controller update-credentials --kubeconfig=kubeconfig  --namespace=capa-system
  # Kubeconfig in the default location will be retrieved and the provided context will be used
  clusterawsadm controller update-credentials --kubeconfig-context=mgmt-cluster  --namespace=capa-system

Options

  -h, --help                        help for update-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm controller zero-credentials

zero credentials the controller is started with

Synopsis

Zero credentials the controller is started with

clusterawsadm controller zero-credentials [flags]

Examples

  # zero credentials
  # Kubeconfig file will be searched in default locations
  clusterawsadm controller zero-credentials --namespace=capa-system
  # Provided kubeconfig file will be used
  clusterawsadm controller zero-credentials --kubeconfig=kubeconfig  --namespace=capa-system
  # Kubeconfig in the default location will be retrieved and the provided context will be used
  clusterawsadm controller zero-credentials --kubeconfig-context=mgmt-cluster  --namespace=capa-system

Options

  -h, --help                        help for zero-credentials
      --kubeconfig string           Path to the kubeconfig file to use for the management cluster. If empty, default discovery rules apply.
      --kubeconfig-context string   Context to be used within the kubeconfig file. If empty, current context will be used.
      --namespace string            Namespace the controllers are in. If empty, default value (capa-system) is used (default "capa-system")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm controller - controller commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm eks

Commands related to EKS

clusterawsadm eks [flags]

Options

  -h, --help   help for eks

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm eks addons

Commands related to EKS addons

clusterawsadm eks addons [flags]

Options

  -h, --help   help for addons

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks - Commands related to EKS
• clusterawsadm eks addons list-available - List available EKS addons
• clusterawsadm eks addons list-installed - List installed EKS addons

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm eks addons list-available

List available EKS addons

Synopsis

Lists the addons that are available for use with an EKS cluster

clusterawsadm eks addons list-available [flags]

Options

  -n, --cluster-name string   The name of the cluster to get the list of available addons for
  -h, --help                  help for list-available
  -o, --output string         The output format of the results. Possible values: table,json,yaml (default "table")
  -r, --region string         The AWS region containing the EKS cluster

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm eks addons list-installed

List installed EKS addons

Synopsis

Lists the addons that are installed for an EKS cluster

clusterawsadm eks addons list-installed [flags]

Options

  -n, --cluster-name string   The name of the cluster to get the list of installed addons for
  -h, --help                  help for list-installed
  -o, --output string         The output format of the results. Possible values: table,json,yaml (default "table")
  -r, --region string         The AWS region containing the EKS cluster

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm eks addons - Commands related to EKS addons

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm gc

Commands related to garbage collecting external resources of clusters

clusterawsadm gc [command] [flags]

Options

  -h, --help   help for gc

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm gc configure - Specify what cleanup tasks will be executed on a given cluster
• clusterawsadm gc disable - Mark a cluster as NOT requiring external resource garbage collection
• clusterawsadm gc enable - Mark a cluster as requiring external resource garbage collection

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm gc configure

Specify what cleanup tasks will be executed on a given cluster

Synopsis

This command will set what cleanup tasks to execute on the given cluster during garbage collection (i.e. deleting) when the cluster is requested to be deleted. Supported values: load-balancer, security-group, target-group.

clusterawsadm gc configure [flags]

Examples

  # Configure GC for a cluster to delete only load balancers and security groups using existing k8s context
  clusterawsadm gc configure --cluster-name=test-cluster --gc-task load-balancer --gc-task security-group
  
  # Reset GC configuration for a cluster using kubeconfig
  clusterawsadm gc configure --cluster-name=test-cluster --kubeconfig=test.kubeconfig

Options

      --cluster-name string   The name of the CAPA cluster
      --gc-task strings       Garbage collection tasks to execute during cluster deletion
  -h, --help                  help for configure
      --kubeconfig string     Path to the kubeconfig file to use (default "/opt/buildhome/.kube/config")
  -n, --namespace string      The namespace for the cluster definition (default "default")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm gc - Commands related to garbage collecting external resources of clusters

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm gc disable

Mark a cluster as NOT requiring external resource garbage collection

Synopsis

This command will mark the given cluster as not requiring external resource garbage collection (i.e. deleting) when the cluster is requested to be deleted.

clusterawsadm gc disable [flags]

Examples

  # Disable GC for a cluster using existing k8s context
  clusterawsadm gc disable --cluster-name=test-cluster
  
  # Disable GC for a cluster using kubeconfig
  clusterawsadm gc disable --cluster-name=test-cluster --kubeconfig=test.kubeconfig

Options

      --cluster-name string   The name of the CAPA cluster
  -h, --help                  help for disable
      --kubeconfig string     Path to the kubeconfig file to use (default "/opt/buildhome/.kube/config")
  -n, --namespace string      The namespace for the cluster definition (default "default")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm gc - Commands related to garbage collecting external resources of clusters

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm gc enable

Mark a cluster as requiring external resource garbage collection

Synopsis

This command will mark the given cluster as requiring external resource garbage collection (i.e. deleting) when the cluster is requested to be deleted. This works by adding an annotation to the infra cluster.

clusterawsadm gc enable [flags]

Examples

  # Enable GC for a cluster using existing k8s context
  clusterawsadm gc enable --cluster-name=test-cluster
  
  # Enable GC for a cluster using kubeconfig
  clusterawsadm gc enable --cluster-name=test-cluster --kubeconfig=test.kubeconfig

Options

      --cluster-name string   The name of the CAPA cluster
  -h, --help                  help for enable
      --kubeconfig string     Path to the kubeconfig file to use (default "/opt/buildhome/.kube/config")
  -n, --namespace string      The namespace for the cluster definition (default "default")

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm gc - Commands related to garbage collecting external resources of clusters

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm resource

Commands related to AWS resources

Synopsis

All AWS resources related actions such as:

List of AWS resources created by CAPA

clusterawsadm resource [command] [flags]

Options

  -h, --help   help for resource

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm resource list - List all AWS resources created by CAPA

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm resource list

List all AWS resources created by CAPA

Synopsis

List AWS resources directly created by CAPA based on region and cluster-name. There are some indirect resources like Cloudwatch alarms, rules, etc which are not directly created by CAPA, so those resources are not listed here. If region and cluster-name are not set, then it will throw an error.

clusterawsadm resource list [flags]

Examples

  # List AWS resources directly created by CAPA in given region and clustername
  clusterawsadm resource list --region=us-east-1 --cluster-name=test-cluster

Options

  -n, --cluster-name string   The name of the cluster where AWS resources created by CAPA
  -h, --help                  help for list
  -o, --output string         The output format of the results. Possible values: table, json, yaml (default "table")
  -r, --region string         The AWS region where resources are created by CAPA

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm resource - Commands related to AWS resources

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm version

Print version of clusterawsadm

clusterawsadm version [flags]

Options

  -h, --help            help for version
  -o, --output string   Output format; available options are 'yaml', 'json' and 'short'

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm ami

AMI commands

Synopsis

All AMI related actions such as:

Copy AMIs based on Kubernetes version, OS etc from an AWS account where AMIs are stored

     to the current AWS account (use case: air-gapped deployments)

(to be implemented) List available AMIs

clusterawsadm ami [command] [flags]

Options

  -h, --help   help for ami

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm ami copy - Copy AMIs from an AWS account to the AWS account which credentials are provided
• clusterawsadm ami encrypted-copy - Encrypt and copy AMI snapshot, then create an AMI with that snapshot
• clusterawsadm ami list - List AMIs from the default AWS account where AMIs are stored

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm ami copy

Copy AMIs from an AWS account to the AWS account which credentials are provided

Synopsis

Copy AMIs based on Kubernetes version, OS, region from an AWS account where AMIs are stored to the current AWS account (use case: air-gapped deployments)

clusterawsadm ami copy [flags]

Examples

  # Copy AMI from the default AWS account where AMIs are stored.
  # Available os options: centos-7, ubuntu-24.04, ubuntu-22.04, amazon-2, flatcar-stable
  clusterawsadm ami copy --kubernetes-version=v1.30.1 --os=ubuntu-22.04  --region=us-west-2
  
  # owner-id and dry-run flags are optional. region can be set via flag or env
  clusterawsadm ami copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --dry-run
  
  # copy from us-east-1 to us-east-2
  clusterawsadm ami copy --os centos-7 --kubernetes-version=v1.19.4 --region us-east-2 --source-region us-east-1

Options

      --dry-run                     Check if AMI exists and can be copied
  -h, --help                        help for copy
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be copied
      --owner-id string             The source AWS owner ID, where the AMI will be copied from (default "819546954734")
      --region string               The AWS region in which to provision
      --source-region string        Set if wanting to copy an AMI from a different region

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm ami encrypted-copy

Encrypt and copy AMI snapshot, then create an AMI with that snapshot

Synopsis

Find the AMI based on Kubernetes version, OS, region in the AWS account where AMIs are stored. Encrypt and copy the snapshot of the AMI to the current AWS account. Create an AMI with that snapshot.

clusterawsadm ami encrypted-copy [flags]

Examples

  # Create an encrypted AMI:
  # Available os options: centos-7, ubuntu-24.04, ubuntu-22.04, amazon-2, flatcar-stable
  clusterawsadm ami encrypted-copy --kubernetes-version=v1.18.12 --os=ubuntu-20.04  --region=us-west-2
  
  # owner-id and dry-run flags are optional. region can be set via flag or env
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --dry-run
  
  # copy from us-east-1 to us-east-2
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --owner-id=111111111111 --region us-east-2 --source-region us-east-1
  
  # Encrypt using a non-default KmsKeyId specified using Key ID:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=key/1234abcd-12ab-34cd-56ef-1234567890ab
  
  # Encrypt using a non-default KmsKeyId specified using Key alias:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=alias/ExampleAlias
  
  # Encrypt using a non-default KmsKeyId specified using Key ARN:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=arn:aws:kms:us-east-1:012345678910:key/abcd1234-a123-456a-a12b-a123b4cd56ef
  
  # Encrypt using a non-default KmsKeyId specified using Alias ARN:
  clusterawsadm ami encrypted-copy --os centos-7 --kubernetes-version=v1.19.4 --kms-key-id=arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias

Options

      --dry-run                     Check if AMI exists and can be copied
  -h, --help                        help for encrypted-copy
      --kms-key-id string           The ID of the KMS key for Amazon EBS encryption
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be copied
      --owner-id string             The source AWS owner ID, where the AMI will be copied from (default "819546954734")
      --region string               The AWS region in which to provision
      --source-region string        Set if wanting to copy an AMI from a different region

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm ami list

List AMIs from the default AWS account where AMIs are stored

Synopsis

List AMIs based on Kubernetes version, OS, region. If no arguments are provided, it will print all AMIs in all regions, OS types for the supported Kubernetes versions. Supported Kubernetes versions start from the latest stable version and goes 2 release back: if the latest stable release is v1.20.4- v1.19.x and v1.18.x are supported. Note: First release of each version will be skipped, e.g., v1.21.0 To list AMIs of unsupported Kubernetes versions, --kubernetes-version flag needs to be provided.

clusterawsadm ami list [flags]

Examples

  # List AMIs from the default AWS account where AMIs are stored.
  # Available os options: centos-7, ubuntu-24.04, ubuntu-22.04, amazon-2, flatcar-stable
  clusterawsadm ami list --kubernetes-version=v1.18.12 --os=ubuntu-20.04  --region=us-west-2
  # To list all supported AMIs in all supported Kubernetes versions, regions, and linux distributions:
  clusterawsadm ami list

Options

  -h, --help                        help for list
      --kubernetes-version string   Kubernetes version of the AMI to be copied
      --os string                   Operating system of the AMI to be listed
  -o, --output string               The output format of the results. Possible values: table,json,yaml (default "table")
      --owner-id string             The owner ID of the AWS account to be used for listing AMIs
      --region string               The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm ami - AMI commands

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap

bootstrap commands

Synopsis

In order to use Kubernetes Cluster API Provider AWS, an AWS account needs to be prepared with AWS Identity and Access Management (IAM) roles to be used by clusters as well as provide Kubernetes Cluster API Provider AWS with credentials to use to provision infrastructure.

clusterawsadm bootstrap [command] [flags]

Options

  -h, --help   help for bootstrap

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm - Kubernetes Cluster API Provider AWS Management Utility
• clusterawsadm bootstrap credentials - Encode credentials to use with Kubernetes Cluster API Provider AWS
• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap credentials

Encode credentials to use with Kubernetes Cluster API Provider AWS

Synopsis

Encode credentials to use with Kubernetes Cluster API Provider AWS.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

The utility will then generate an ini-file with a default profile corresponding to the resolved credentials.

If a region cannot be found, for the purposes of using AWS Security Token Service, this utility will fall back to us-east-1. This does not affect the region in which clusters will be created.

In the case of an instance profile or role assumption, note that encoded credentials are time-limited.

clusterawsadm bootstrap credentials [flags]

Examples

  # Encode credentials from the environment for use with clusterctl
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help   help for credentials

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm bootstrap credentials encode-as-profile - Generate an AWS profile from the current environment

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap credentials encode-as-profile

Generate an AWS profile from the current environment

Synopsis

Generate an AWS profile from the current environment for the ephemeral bootstrap cluster.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

The utility will then generate an ini-file with a default profile corresponding to the resolved credentials.

If a region cannot be found, for the purposes of using AWS Security Token Service, this utility will fall back to us-east-1. This does not affect the region in which clusters will be created.

In the case of an instance profile or role assumption, note that encoded credentials are time-limited.

clusterawsadm bootstrap credentials encode-as-profile [flags]

Examples

  # Encode credentials from the environment for use with clusterctl
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  clusterctl init --infrastructure aws

Options

  -h, --help            help for encode-as-profile
      --output string   Output for credential configuration (rawSharedConfig, base64SharedConfig) (default "base64SharedConfig")
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap credentials - Encode credentials to use with Kubernetes Cluster API Provider AWS

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam

View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Synopsis

View/output AWS Identity and Access Management (IAM) policy documents required for configuring Kubernetes Cluster API Provider AWS as well as create/update AWS IAM resources using AWS CloudFormation.

clusterawsadm bootstrap iam [command] [flags]

Options

  -h, --help   help for iam

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap - bootstrap commands
• clusterawsadm bootstrap iam create-cloudformation-stack - Create or update an AWS CloudFormation stack
• clusterawsadm bootstrap iam delete-cloudformation-stack - Delete an AWS CloudFormation stack
• clusterawsadm bootstrap iam print-cloudformation-template - Print cloudformation template
• clusterawsadm bootstrap iam print-config - Print configuration
• clusterawsadm bootstrap iam print-policy - Generate and show an IAM policy

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam create-cloudformation-stack

Create or update an AWS CloudFormation stack

Synopsis

Create or update an AWS CloudFormation stack for bootstrapping Kubernetes Cluster API and Kubernetes AWS Identity and Access Management (IAM) permissions. To use this command, there must be AWS credentials loaded in this environment.

The utility will attempt to find credentials in the following order:

1. Check for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
2. Read the default credentials from the shared configuration files ~/.aws/credentials or the default profile in ~/.aws/config.
3. Check for the presence of an EC2 IAM instance profile if it’s running on AWS.
4. Check for ECS credentials.

IAM role assumption can be performed by using any valid configuration for the AWS CLI at: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html. For role assumption to be used, a region is required for the utility to use the AWS Security Token Service (STS). The utility resolves the region in the following order:

1. Check for the --region flag.
2. Check for the AWS_REGION environment variable.
3. Check for the DEFAULT_AWS_REGION environment variable.
4. Check that a region is specified in the shared configuration file.

clusterawsadm bootstrap iam create-cloudformation-stack [flags]

Examples

  # Create or update IAM roles and policies for Kubernetes using a AWS CloudFormation stack.
  clusterawsadm bootstrap iam create-cloudformation-stack
  
  # Create or update IAM roles and policies for Kubernetes using a AWS CloudFormation stack with a custom configuration.
  clusterawsadm bootstrap iam create-cloudformation-stack --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/v2/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for create-cloudformation-stack
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam delete-cloudformation-stack

Delete an AWS CloudFormation stack

Synopsis

Delete the AWS CloudFormation stack that created AWS Identity and Access Management (IAM) resources for use with Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam delete-cloudformation-stack [flags]

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/v2/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for delete-cloudformation-stack
      --region string   The AWS region in which to provision

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam print-cloudformation-template

Print cloudformation template

Synopsis

Generate and print out a CloudFormation template that can be used to provision AWS Identity and Access Management (IAM) policies and roles for use with Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam print-cloudformation-template [flags]

Examples

  # Print out the default CloudFormation template.
  clusterawsadm bootstrap iam print-cloudformation-template
  
  # Print out a CloudFormation template using a custom configuration.
  clusterawsadm bootstrap iam print-cloudformation-template --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/v2/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for print-cloudformation-template

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam print-config

Print configuration

Synopsis

Print configuration

clusterawsadm bootstrap iam print-config [flags]

Examples

  # Print the default configuration.
  clusterawsadm bootstrap iam print-config
  
  # Apply defaults to a configuration file and print the result
  clusterawsadm bootstrap iam print-config --config bootstrap_config.yaml

Options

      --config string   clusterawsadm will load a bootstrap configuration from this file. The path may be
                        absolute or relative; relative paths start at the current working directory.
                        
                        The configuration file is a Kubernetes YAML using the
                        bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                        kind.
                        
                        Documentation for this kind can be found at:
                        https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/v2/cmd/clusterawsadm/api/bootstrap/v1beta1
                        
                        To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
  -h, --help            help for print-config

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

clusterawsadm bootstrap iam print-policy

Generate and show an IAM policy

Synopsis

Generate and show an AWS Identity and Access Management (IAM) policy for Kubernetes Cluster API Provider AWS.

clusterawsadm bootstrap iam print-policy [flags]

Examples

  # Print out all the IAM policies for the Kubernetes CLuster API Provider AWS.
  clusterawsadm bootstrap iam print-policy
  
  # Print out the IAM policy for the Kubernetes Cluster API Provider AWS Controller.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers
  
  # Print out the IAM policy for the Kubernetes Cluster API Provider AWS Controller using a given configuration file.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyControllers --config bootstrap_config.yaml
  
  # Print out the IAM policy for the Kubernetes AWS Cloud Provider for the control plane.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyCloudProviderControlPlane
  
  # Print out the IAM policy for the Kubernetes AWS Cloud Provider for all nodes.
  clusterawsadm bootstrap iam print-policy --document AWSIAMManagedPolicyCloudProviderNodes
  
  # Print out the IAM policy for the Kubernetes AWS EBS CSI Driver Controller.
  clusterawsadm bootstrap iam print-policy --document AWSEBSCSIPolicyController

Options

      --config string     clusterawsadm will load a bootstrap configuration from this file. The path may be
                          absolute or relative; relative paths start at the current working directory.
                          
                          The configuration file is a Kubernetes YAML using the
                          bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1/AWSIAMConfiguration
                          kind.
                          
                          Documentation for this kind can be found at:
                          https://pkg.go.dev/sigs.k8s.io/cluster-api-provider-aws/v2/cmd/clusterawsadm/api/bootstrap/v1beta1
                          
                          To see the default configuration, run 'clusterawsadm bootstrap iam print-config'.
      --document string   which document to show: [AWSIAMManagedPolicyControllers AWSIAMManagedPolicyControllersEKS AWSIAMManagedPolicyCloudProviderControlPlane AWSIAMManagedPolicyCloudProviderNodes AWSEBSCSIPolicyController]
  -h, --help              help for print-policy

Options inherited from parent commands

  -v, --v int   Set the log level verbosity. (default 2)

SEE ALSO

• clusterawsadm bootstrap iam - View required AWS IAM policies and create/update IAM roles using AWS CloudFormation

Auto generated by spf13/cobra on 4-Nov-2024

Developer Guide

Initial setup for development environment

Install prerequisites

1. Install go
   • Get the latest patch version for go v1.22.
2. Install jq
   • brew install jq on macOS.
   • chocolatey install jq on Windows.
   • sudo apt install jq on Ubuntu Linux.
3. Install KIND
   • GO111MODULE="on" go get sigs.k8s.io/kind@v0.12.0.
4. Install Kustomize
   • install instructions
5. Install envsubst
6. Install make.
7. Install direnv
   • brew install direnv on macOS.
8. Set AWS Environment variable for an IAM Admin user

   • export AWS_ACCESS_KEY_ID=ADMID
     export AWS_SECRET_ACCESS_KEY=ADMKEY
     export AWS_REGION=eu-west-1
     

Get the source

Fork the cluster-api-provider-aws repo:

cd "$(go env GOPATH)"/src
mkdir sigs.k8s.io
cd sigs.k8s.io/
git clone git@github.com:<GITHUB USERNAME>/cluster-api-provider-aws.git
cd cluster-api-provider-aws
git remote add upstream git@github.com:kubernetes-sigs/cluster-api-provider-aws.git
git fetch upstream

Build clusterawsadm

Build clusterawsadm in cluster-api-provider-aws:

cd "$(go env GOPATH)"/src/sigs.k8s.io/cluster-api-provider-aws/
make clusterawsadm
sudo mv ./bin/clusterawsadm /usr/local/bin/clusterawsadm

Setup AWS Environment

Create bootstrap file and bootstrap IAM roles and policies using clusterawsadm

$ cat config-bootstrap.yaml

apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true

$ clusterawsadm bootstrap iam create-cloudformation-stack
Attempting to create AWS CloudFormation stack cluster-api-provider-aws-sigs-k8s-io

Customizing the bootstrap permission

The IAM permissions can be customized by using a configuration file with clusterawsadm. For example, to create the default IAM role for use with managed machine pools:

$ cat config-bootstrap.yaml
apiVersion: bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
kind: AWSIAMConfiguration
spec:
  bootstrapUser:
    enable: true
  eks:
    iamRoleCreation: false # Set to true if you plan to use the EKSEnableIAM feature flag to enable automatic creation of IAM roles
    managedMachinePool:
      disable: false # Set to false to enable creation of the default node role for managed machine pools

Use the configuration file to create the additional IAM role:

$ clusterawsadm bootstrap iam create-cloudformation-stack --config=config-bootstrap.yaml
Attempting to create AWS CloudFormation stack cluster-api-provider-aws-sigs-k8s-io

If you don’t plan on using EKS then see the documentation on disabling EKS support.

Sample Output

When creating the CloudFormation stack using clusterawsadm you will see output similar to this:

Following resources are in the stack:

Resource                  |Type                                                                                |Status
AWS::IAM::Group           |cluster-api-provider-aws-s-AWSIAMGroupBootstrapper-ME9XZVCO2491                     |CREATE_COMPLETE
AWS::IAM::InstanceProfile |control-plane.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::InstanceProfile |controllers.cluster-api-provider-aws.sigs.k8s.io                                    |CREATE_COMPLETE
AWS::IAM::InstanceProfile |nodes.cluster-api-provider-aws.sigs.k8s.io                                          |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/control-plane.cluster-api-provider-aws.sigs.k8s.io |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/nodes.cluster-api-provider-aws.sigs.k8s.io         |CREATE_COMPLETE
AWS::IAM::ManagedPolicy   |arn:aws:iam::xxx:policy/controllers.cluster-api-provider-aws.sigs.k8s.io   |CREATE_COMPLETE
AWS::IAM::Role            |control-plane.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::Role            |controllers.cluster-api-provider-aws.sigs.k8s.io                                    |CREATE_COMPLETE
AWS::IAM::Role            |eks-controlplane.cluster-api-provider-aws.sigs.k8s.io                               |CREATE_COMPLETE
AWS::IAM::Role            |eks-nodegroup.cluster-api-provider-aws.sigs.k8s.io                                  |CREATE_COMPLETE
AWS::IAM::Role            |nodes.cluster-api-provider-aws.sigs.k8s.io                                          |CREATE_COMPLETE
AWS::IAM::User            |bootstrapper.cluster-api-provider-aws.sigs.k8s.io                                   |CREATE_COMPLETE

Set Environment Variables

• Create a security credentials in the bootstrapper.cluster-api-provider-aws.sigs.k8s.io IAM user that is created by cloud-formation stack and copy the AWS_ACCESS_KEY_ID and AWS_SECRETS_ACCESS_KEY. (Or use admin user credentials instead)

• Set AWS_B64ENCODED_CREDENTIALS environment variable

  export AWS_ACCESS_KEY_ID=AKIATEST
  export AWS_SECRET_ACCESS_KEY=TESTTEST
  export AWS_REGION=eu-west-1
  export AWS_B64ENCODED_CREDENTIALS=$(clusterawsadm bootstrap credentials encode-as-profile)
  

Running local management cluster for development

Before the next steps, make sure initial setup for development environment steps are complete.

There are two ways to build aws manager from local cluster-api-provider-aws source and run it in local kind cluster:

Option 1: Setting up Development Environment with Tilt

Tilt is a tool for quickly building, pushing, and reloading Docker containers as part of a Kubernetes deployment. Many of the Cluster API engineers use it for quick iteration. Please see our Tilt instructions to get started.

Option 2: The Old-fashioned way

Running cluster-api and cluster-api-provider-aws controllers in a kind cluster:

1. Create a local kind cluster
   • kind create cluster
2. Install core cluster-api controllers (the version must match the cluster-api version in go.mod)
   • clusterctl init --core cluster-api:v0.3.16 --bootstrap kubeadm:v0.3.16 --control-plane kubeadm:v0.3.16
3. Build cluster-api-provider-aws docker images
   • make e2e-image
4. Release manifests under ./out directory
   • RELEASE_TAG="e2e" make release-manifests
5. Apply the manifests
   • kubectl apply -f ./out/infrastructure.yaml

Developing Cluster API Provider AWS with Tilt

This document describes how to use kind and Tilt for a simplified workflow that offers easy deployments and rapid iterative builds. Before the next steps, make sure initial setup for development environment steps are complete.

Also, visit the Cluster API documentation on Tilt for more information on how to set up your development environment.

Create a kind cluster

First, make sure you have a kind cluster and that your KUBECONFIG is set up correctly:

kind create cluster --name=capi-test

This local cluster will be running all the cluster api controllers and become the management cluster which then can be used to spin up workload clusters on AWS.

Get the source

Get the source for core cluster-api for development with Tilt along with cluster-api-provider-aws.

cd "$(go env GOPATH)"/src
mkdir sigs.k8s.io
cd sigs.k8s.io/
git clone git@github.com:kubernetes-sigs/cluster-api.git
cd cluster-api
git fetch upstream

Create a tilt-settings.json file

Next, create a tilt-settings.json file and place it in your local copy of cluster-api. Here is an example:

Example tilt-settings.json for CAPA clusters:

{
  "enable_providers": [
    "kubeadm-bootstrap",
    "kubeadm-control-plane",
    "aws"
  ],
  "default_registry": "gcr.io/your-project-name-here",
  "provider_repos": [
    "/Users/username/go/src/sigs.k8s.io/cluster-api-provider-aws/v2"
  ],
  "kustomize_substitutions": {
    "EXP_CLUSTER_RESOURCE_SET": "true",
    "EXP_MACHINE_POOL": "true",
    "EVENT_BRIDGE_INSTANCE_STATE": "true",
    "AWS_B64ENCODED_CREDENTIALS": "W2RlZmFZSZnRg==",
    "EXP_EKS_FARGATE": "false",
    "CAPA_EKS_IAM": "false",
    "CAPA_EKS_ADD_ROLES": "false",
    "EXP_BOOTSTRAP_FORMAT_IGNITION": "true"
  },
  "extra_args": {
    "aws": ["--v=2"]
  }
}

Example tilt-settings.json for EKS managed clusters prior to CAPA v0.7.0:

{
    "default_registry": "gcr.io/your-project-name-here",
    "provider_repos": ["../cluster-api-provider-aws"],
    "enable_providers": ["eks-bootstrap", "eks-controlplane", "kubeadm-bootstrap", "kubeadm-control-plane", "aws"],
    "kustomize_substitutions": {
        "AWS_B64ENCODED_CREDENTIALS": "W2RlZmFZSZnRg==",
        "EXP_EKS": "true",
        "EXP_EKS_IAM": "true",
        "EXP_MACHINE_POOL": "true"
    },
    "extra_args": {
        "aws": ["--v=2"],
        "eks-bootstrap": ["--v=2"],
        "eks-controlplane": ["--v=2"]
    }
  }

Debugging

If you would like to debug CAPA (or core CAPI / another provider) you can run the provider with delve. This will then allow you to attach to delve and debug.

To do this you need to use the debug configuration in tilt-settings.json. Full details of the options can be seen here.

An example tilt-settings.json:

{
  "enable_providers": [
    "kubeadm-bootstrap",
    "kubeadm-control-plane",
    "aws"
  ],
  "default_registry": "gcr.io/your-project-name-here",
  "provider_repos": [
    "/Users/username/go/src/sigs.k8s.io/cluster-api-provider-aws/v2"
  ],
  "kustomize_substitutions": {
    "EXP_CLUSTER_RESOURCE_SET": "true",
    "EXP_MACHINE_POOL": "true",
    "EVENT_BRIDGE_INSTANCE_STATE": "true",
    "AWS_B64ENCODED_CREDENTIALS": "W2RlZmFZSZnRg==",
    "EXP_EKS_FARGATE": "false",
    "CAPA_EKS_IAM": "false",
    "CAPA_EKS_ADD_ROLES": "false"
  },
  "extra_args": {
    "aws": ["--v=2"]
  }
  "debug": {
    "aws": {
      "continue": true,
      "port": 30000
    }
  }
}

Once you have run tilt (see section below) you will be able to connect to the running instance of delve.

For vscode, you can use the a launch configuration like this:

    {
        "name": "Connect to CAPA",
        "type": "go",
        "request": "attach",
        "mode": "remote",
        "remotePath": "",
        "port": 30000,
        "host": "127.0.0.1",
        "showLog": true,
        "trace": "log",
        "logOutput": "rpc"
    }

For GoLand/IntelliJ add a new run configuration following these instructions.

Or you could use delve directly from the CLI using a command similar to this:

dlv-dap connect 127.0.0.1:3000

Run Tilt!

To launch your development environment, run:

tilt up

kind cluster becomes a management cluster after this point, check the pods running on the kind cluster kubectl get pods -A.

Create workload clusters

Set the following variables for both CAPA and EKS managed clusters:

export AWS_SSH_KEY_NAME=<sshkeypair>
export KUBERNETES_VERSION=v1.20.2
export CLUSTER_NAME=capi-<test-clustename>
export CONTROL_PLANE_MACHINE_COUNT=1
export AWS_CONTROL_PLANE_MACHINE_TYPE=t3.large
export WORKER_MACHINE_COUNT=1
export AWS_NODE_MACHINE_TYPE=t3.large

Set the following variables for only EKS managed clusters:

export AWS_EKS_ROLE_ARN=arn:aws:iam::<accountid>:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS
export EKS_KUBERNETES_VERSION=v1.15

Create CAPA managed workload cluster:

cat templates/cluster-template.yaml
cat templates/cluster-template.yaml | $HOME/go/bin/envsubst > test-cluster.yaml
kubectl apply -f test-cluster.yaml

Create EKS workload cluster:

cat templates/cluster-template-eks.yaml
cat templates/cluster-template-eks.yaml | $HOME/go/bin/envsubst > test-cluster.yaml
kubectl apply -f test-cluster.yaml

Check the tilt logs and wait for the clusters to be created.

Clean up

Before deleting the kind cluster, make sure you delete all the workload clusters.

kubectl delete cluster <clustername>
tilt up (ctrl-c)
kind delete cluster

Troubleshooting

• Make sure you have at least three available spaces EIP and NAT Gateways to be created
• If your git starts throwing this error

flag provided but not defined: -variables
Usage: envsubst [options...] <input>

you might need to reinstall the system envsubst

brew install gettetxt
# or
brew reinstall gettext

Make sure you specify which envsubst you are using

Developing E2E tests

Visit the Cluster API documentation on E2E for information on how to develop and run e2e tests.

Set up

It’s recommended to create a separate AWS account to run E2E tests. This ensures it does not conflict with your other cluster API environment.

Running from CLI

e2e tests can be run using Makefile targets:

$ make test-e2e
$ make test-e2e-eks

The following useful env variables can help to speed up the runs:

• E2E_ARGS="--skip-cloudformation-creation --skip-cloudformation-deletion" - in case the cloudformation stack is already properly set up, this ensures a quicker start and tear down.
• GINKGO_FOCUS='\[PR-Blocking\]' - only run a subset of tests
• USE_EXISTING_CLUSTER - use an existing management cluster (useful if you have a Tilt setup)

Running in IDEs

The following example assumes you run a management cluster locally (e.g. using Tilt).

IntelliJ/GoLand

The following run configuration can be used:

<component name="ProjectRunConfigurationManager">
  <configuration default="false" name="capa e2e: unmanaged PR-Blocking" type="GoTestRunConfiguration" factoryName="Go Test">
    <module name="cluster-api-provider-aws" />
    <working_directory value="$PROJECT_DIR$/test/e2e/suites/unmanaged" />
    <parameters value="-ginkgo.focus=&quot;\[PR-Blocking\]&quot; -ginkgo.v=true -artifacts-folder=$PROJECT_DIR$/_artifacts --data-folder=$PROJECT_DIR$/test/e2e/data -use-existing-cluster=true -config-path=$PROJECT_DIR$/test/e2e/data/e2e_conf.yaml" />
    <envs>
      <env name="AWS_REGION" value="SET_AWS_REGION" />
      <env name="AWS_PROFILE" value="IF_YOU_HAVE_MULTIPLE_PROFILES" />
      <env name="AWS_ACCESS_KEY_ID" value="REPLACE_ACCESS_KEY" />
      <env name="AWS_SECRET_ACCESS_KEY" value="2W2RlZmFZSZnRg==" />
    </envs>
    <kind value="PACKAGE" />
    <package value="sigs.k8s.io/cluster-api-provider-aws/v2/test/e2e/suites/unmanaged" />
    <directory value="$PROJECT_DIR$" />
    <filePath value="$PROJECT_DIR$" />
    <framework value="gotest" />
    <pattern value="^\QTestE2E\E$" />
    <method v="2" />
  </configuration>
</component>

Visual Studio Code

With the example above, you can configure a launch configuration for VSCode.

Coding Conventions

Below is a collection of conventions, guidlines and general tips for writing code for this project.

API Definitions

Don’t Expose 3rd Party Package Types

When adding new or modifying API types don’t expose 3rd party package types/enums via the CAPA API definitions. Instead create our own versions and where provide mapping functions.

For example:

• AWS SDK InstanceState
• CAPA InstanceState

Don’t use struct pointer slices

When adding new fields to an API type don’t use a slice of struct pointers. This can cause issues with the code generator for the conversion functions. Instead use struct slices.

For example:

Instead of this

	// Configuration options for the non root storage volumes.
	// +optional
	NonRootVolumes []*Volume `json:"nonRootVolumes,omitempty"`

use

	// Configuration options for the non root storage volumes.
	// +optional
	NonRootVolumes []Volume `json:"nonRootVolumes,omitempty"`

And then within the code you can check the length or range over the slice.

Tests

There are three types of tests written for CAPA controllers in this repo:

• Unit tests
• Integration tests
• E2E tests

In these tests, we use fakeclient, envtest and gomock libraries based on the requirements of individual test types.

If any new unit, integration or E2E tests has to be added in this repo,we should follow the below conventions.

Unit tests

These tests are meant to verify the functions inside the same controller file where we perform sanity checks, functionality checks etc. These tests go into the file with suffix *_unit_test.go.

Integration tests

These tests are meant to verify the overall flow of the reconcile calls in the controllers to test the flows for all the services/subcomponents of controllers as a whole. These tests go into the file with suffix *_test.go.

E2E tests

These tests are meant to verify the proper functioning of a CAPA cluster in an environment that resembles a real production environment. For details, refer here.

Nightly Builds

Nightly builds are regular automated builds of the CAPA source code that occur every night.

These builds are generated directly from the latest commit of source code on the main branch.

Nightly builds serve several purposes:

• Early Testing: They provide an opportunity for developers and testers to access the most recent changes in the codebase and identify any issues or bugs that may have been introduced.
• Feedback Loop: They facilitate a rapid feedback loop, enabling developers to receive feedback on their changes quickly, allowing them to iterate and improve the code more efficiently.
• Preview of New Features: Users and can get a preview of upcoming features or changes by testing nightly builds, although these builds may not always be stable enough for production use.

Overall, nightly builds play a crucial role in software development by promoting user testing, early bug detection, and rapid iteration.

CAPA Nightly build jobs run in Prow. For details on how this is configured you can check the Periodics Jobs section.

Usage

To try a nightly build, you can download the latest built nightly CAPA manifests, you can find the available ones by executing the following command:

curl -sL -H 'Accept: application/json' "https://storage.googleapis.com/storage/v1/b/k8s-staging-cluster-api-aws/o" | jq -r '.items | map(select(.name | startswith("components/nightly_main"))) | .[] | [.timeCreated,.mediaLink] | @tsv'

The output should look something like this:

2024-05-03T08:03:09.087Z        https://storage.googleapis.com/download/storage/v1/b/k8s-staging-cluster-api-aws/o/components%2Fnightly_main_2024050x?generation=1714723389033961&alt=media
2024-05-04T08:02:52.517Z        https://storage.googleapis.com/download/storage/v1/b/k8s-staging-cluster-api-aws/o/components%2Fnightly_main_2024050y?generation=1714809772486582&alt=media
2024-05-05T08:02:45.840Z        https://storage.googleapis.com/download/storage/v1/b/k8s-staging-cluster-api-aws/o/components%2Fnightly_main_2024050z?generation=1714896165803510&alt=media

Now visit the link for the manifest you want to download. This will automatically download the manifest for you.

Once downloaded you can apply the manifest directly to your testing CAPI management cluster/namespace (e.g. with kubectl), as the downloaded CAPA manifest will already contain the correct, corresponding CAPA nightly image reference.

Publish AMIs

Publishing new AMIs is done via manually invoking a GitHub Actions workflow.

NOTE: the plan is to ultimately fully automate the process in the future (see this issue for progress).

NOTE: there are some issues with the RHEL based images at present.

Get build inputs

For a new Kubernetes version that you want to build an AMI for you will need to determine the following values:

You can determine these values directly or by looking at the publish debian apt repositories for the k8s release.

Build

Using GitHub Actions Workflow

To build the AMI using GitHub actions you must have write access to the CAPA repository (i.e. be a maintainer or part of release team).

To build the new version:

1. Got to the GitHub Action
2. Click the Start Workflow button
3. Fill in the details of the build
4. Click Run

Manually

**WARNING: the manual process should only be followed in exceptional circumstances.

To build manually you must have admin access to the CNCF AWS account used for the AMIs.

The steps to build manually are:

1. Clone image-builder
2. Open a terminal
3. Set the AWS environment variables for the CAPA AMI account
4. Change directory into images/capi
5. Create a new file called vars.json with the following content (substituing the values with the build inputs):

{
    "kubernetes_rpm_version": "<INSERT_INPUT_VALUE>",
    "kubernetes_semver": "<INSERT_INPUT_VALUE>",
    "kubernetes_series": "<INSERT_INPUT_VALUE>",
    "kubernetes_deb_version": "<INSERT_INPUT_VALUE>",
    "kubernetes_cni_semver": "<INSERT_INPUT_VALUE>",
    "kubernetes_cni_deb_version": "<INSERT_INPUT_VALUE>",
    "crictl_version": "<INSERT_INPUT_VALUE>"
}

6. Install dependencies by running:

make deps-ami

7. Build the AMIs using:

PACKER_VAR_FILES=vars.json make build-ami-ubuntu-2204
PACKER_VAR_FILES=vars.json make build-ami-ubuntu-2404
PACKER_VAR_FILES=vars.json make build-ami-flatcar
PACKER_VAR_FILES=vars.json make build-ami-rhel-8

Additional Information

• The AMIs are hosted in a CNCF owned AWS account (819546954734).
• The AWS resources that are needed to support the GitHub Actions workflow are created via terraform. Source is here.
• OIDC and IAM Roles are used to grant access via short lived credentials to the GitHub Action workflow instance when it runs.

Packages:

• ami.aws.infrastructure.cluster.x-k8s.io/v1beta1
• bootstrap.aws.infrastructure.cluster.x-k8s.io/v1alpha1
• bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1
• bootstrap.cluster.x-k8s.io/v1beta1
• bootstrap.cluster.x-k8s.io/v1beta2
• controlplane.cluster.x-k8s.io/v1beta1
• controlplane.cluster.x-k8s.io/v1beta2
• infrastructure.cluster.x-k8s.io/v1beta1
• infrastructure.cluster.x-k8s.io/v1beta2

ami.aws.infrastructure.cluster.x-k8s.io/v1beta1

Package v1beta1 contains API Schema definitions for the AMI v1beta1 API group

AWSAMI

AWSAMI defines an AMI.

AWSAMISpec

(Appears on:AWSAMI)

AWSAMISpec defines an AMI.

bootstrap.aws.infrastructure.cluster.x-k8s.io/v1alpha1

Package v1alpha1 contains API Schema definitions for the bootstrap v1alpha1 API group

AWSIAMConfiguration

AWSIAMConfiguration controls the creation of AWS Identity and Access Management (IAM) resources for use by Kubernetes clusters and Kubernetes Cluster API Provider AWS.

AWSIAMConfigurationSpec

(Appears on:AWSIAMConfiguration)

AWSIAMConfigurationSpec defines the specification of the AWSIAMConfiguration.

AWSIAMRoleSpec

(Appears on:ClusterAPIControllers, ControlPlane, EKSConfig, Nodes)

AWSIAMRoleSpec defines common configuration for AWS IAM roles created by Kubernetes Cluster API Provider AWS.

BootstrapUser

(Appears on:AWSIAMConfigurationSpec)

BootstrapUser contains a list of elements that is specific to the configuration and enablement of an IAM user.

ClusterAPIControllers

(Appears on:AWSIAMConfigurationSpec)

ClusterAPIControllers controls the configuration of the AWS IAM role for the Kubernetes Cluster API Provider AWS controller.

ControlPlane

(Appears on:AWSIAMConfigurationSpec)

ControlPlane controls the configuration of the AWS IAM role for the control plane of provisioned Kubernetes clusters.

EKSConfig

(Appears on:AWSIAMConfigurationSpec)

EKSConfig represents the EKS related configuration config.

EventBridgeConfig

(Appears on:AWSIAMConfigurationSpec)

EventBridgeConfig represents configuration for enabling experimental feature to consume EventBridge EC2 events.

Nodes

(Appears on:AWSIAMConfigurationSpec)

Nodes controls the configuration of the AWS IAM role for worker nodes in a cluster created by Kubernetes Cluster API Provider AWS.

bootstrap.aws.infrastructure.cluster.x-k8s.io/v1beta1

Package v1beta1 contains API Schema definitions for the bootstrap v1beta1 API group

AWSIAMConfiguration

AWSIAMConfiguration controls the creation of AWS Identity and Access Management (IAM) resources for use by Kubernetes clusters and Kubernetes Cluster API Provider AWS.

AWSIAMConfigurationSpec

(Appears on:AWSIAMConfiguration)

AWSIAMConfigurationSpec defines the specification of the AWSIAMConfiguration.

AWSIAMRoleSpec

(Appears on:ClusterAPIControllers, ControlPlane, EKSConfig, Nodes)

AWSIAMRoleSpec defines common configuration for AWS IAM roles created by Kubernetes Cluster API Provider AWS.

BootstrapUser

(Appears on:AWSIAMConfigurationSpec)

BootstrapUser contains a list of elements that is specific to the configuration and enablement of an IAM user.

ClusterAPIControllers

(Appears on:AWSIAMConfigurationSpec)

ClusterAPIControllers controls the configuration of the AWS IAM role for the Kubernetes Cluster API Provider AWS controller.

ControlPlane

(Appears on:AWSIAMConfigurationSpec)

ControlPlane controls the configuration of the AWS IAM role for the control plane of provisioned Kubernetes clusters.

EKSConfig

(Appears on:AWSIAMConfigurationSpec)

EKSConfig represents the EKS related configuration config.

EventBridgeConfig

(Appears on:AWSIAMConfigurationSpec)

EventBridgeConfig represents configuration for enabling experimental feature to consume EventBridge EC2 events.

Nodes

(Appears on:AWSIAMConfigurationSpec)

Nodes controls the configuration of the AWS IAM role for worker nodes in a cluster created by Kubernetes Cluster API Provider AWS.

S3Buckets

(Appears on:AWSIAMConfigurationSpec)

S3Buckets controls the configuration of the AWS IAM role for S3 buckets which can be created for storing bootstrap data for nodes requiring it.

bootstrap.cluster.x-k8s.io/v1beta1

EKSConfig

EKSConfig is the schema for the Amazon EKS Machine Bootstrap Configuration API.

EKSConfigSpec

(Appears on:EKSConfig, EKSConfigTemplateResource)

EKSConfigSpec defines the desired state of Amazon EKS Bootstrap Configuration.

EKSConfigStatus

(Appears on:EKSConfig)

EKSConfigStatus defines the observed state of the Amazon EKS Bootstrap Configuration.

EKSConfigTemplate

EKSConfigTemplate is the Amazon EKS Bootstrap Configuration Template API.

EKSConfigTemplateResource

(Appears on:EKSConfigTemplateSpec)

EKSConfigTemplateResource defines the Template structure.

EKSConfigTemplateSpec

(Appears on:EKSConfigTemplate)

EKSConfigTemplateSpec defines the desired state of templated EKSConfig Amazon EKS Bootstrap Configuration resources.

PauseContainer

(Appears on:EKSConfigSpec)

PauseContainer contains details of pause container.

bootstrap.cluster.x-k8s.io/v1beta2

Package v1beta2 contains API Schema definitions for the Amazon EKS Bootstrap v1beta2 API group.

DiskSetup

(Appears on:EKSConfigSpec)

DiskSetup defines input for generated disk_setup and fs_setup in cloud-init.

EKSConfig

EKSConfig is the schema for the Amazon EKS Machine Bootstrap Configuration API.

EKSConfigSpec

(Appears on:EKSConfig, EKSConfigTemplateResource)

EKSConfigSpec defines the desired state of Amazon EKS Bootstrap Configuration.

EKSConfigStatus

(Appears on:EKSConfig)

EKSConfigStatus defines the observed state of the Amazon EKS Bootstrap Configuration.

EKSConfigTemplate

EKSConfigTemplate is the Amazon EKS Bootstrap Configuration Template API.

EKSConfigTemplateResource

(Appears on:EKSConfigTemplateSpec)

EKSConfigTemplateResource defines the Template structure.

EKSConfigTemplateSpec

(Appears on:EKSConfigTemplate)

EKSConfigTemplateSpec defines the desired state of templated EKSConfig Amazon EKS Bootstrap Configuration resources.

Encoding (string alias)

(Appears on:File)

Encoding specifies the cloud-init file encoding.

File

(Appears on:EKSConfigSpec)

File defines the input for generating write_files in cloud-init.

FileSource

(Appears on:File)

FileSource is a union of all possible external source types for file data. Only one field may be populated in any given instance. Developers adding new sources of data for target systems should add them here.

Filesystem

(Appears on:DiskSetup)

Filesystem defines the file systems to be created.

MountPoints ([]string alias)

(Appears on:EKSConfigSpec)

MountPoints defines input for generated mounts in cloud-init.

NTP

(Appears on:EKSConfigSpec)

NTP defines input for generated ntp in cloud-init.

Partition

(Appears on:DiskSetup)

Partition defines how to create and layout a partition.

PasswdSource

(Appears on:User)

PasswdSource is a union of all possible external source types for passwd data. Only one field may be populated in any given instance. Developers adding new sources of data for target systems should add them here.

PauseContainer

(Appears on:EKSConfigSpec)

PauseContainer contains details of pause container.

SecretFileSource

(Appears on:FileSource)

SecretFileSource adapts a Secret into a FileSource.

The contents of the target Secret’s Data field will be presented as files using the keys in the Data field as the file names.

SecretPasswdSource

(Appears on:PasswdSource)

SecretPasswdSource adapts a Secret into a PasswdSource.

The contents of the target Secret’s Data field will be presented as passwd using the keys in the Data field as the file names.

User

(Appears on:EKSConfigSpec)

User defines the input for a generated user in cloud-init.

controlplane.cluster.x-k8s.io/v1beta1

Package v1beta1 contains API Schema definitions for the controlplane v1beta1 API group

AWSManagedControlPlane

AWSManagedControlPlane is the schema for the Amazon EKS Managed Control Plane API.

AWSManagedControlPlaneSpec

(Appears on:AWSManagedControlPlane)

AWSManagedControlPlaneSpec defines the desired state of an Amazon EKS Cluster.