Skip to content

AWS template parameters#

AWS AMI#

For AWS, by default k0rdent looks up the AMI ID automatically, using the latest Amazon Linux 2 image.

You can override lookup parameters to search your desired image automatically or you can use a specific AMI ID directly. If both the AMI ID and lookup parameters are defined, the AMI ID will have higher precedence.

Image lookup#

To configure automatic AMI lookup, k0rdent uses three parameters:

  • .imageLookup.format - Used directly as a value for the name filter (see the describe-images filters). This field supports substitutions for {{.BaseOS}} and {{.K8sVersion}} with the base OS and kubernetes version, respectively.

  • .imageLookup.org - The AWS org ID that will be used as value for the owner-id filter.

  • .imageLookup.baseOS - The string to be used as a value for the {{.BaseOS}} substitution in the .imageLookup.format string.

AMI ID#

The AMI ID can be directly used in the .amiID parameter.

CAPA prebuilt AMIs#

Use clusterawsadm to get available AMIs to create a ClusterDeployment:

clusterawsadm ami list

For details, see Pre-built Kubernetes AMIs.

SSH access to cluster nodes#

To access nodes using SSH you'll need to do two things:

  • Add an SSH key added in the region where you want to deploy the cluster
  • Enable Bastion host is enabled

SSH keys#

Only one SSH key is supported and it should be added in AWS prior to creating the ClusterDeployment object. The name of the key should then be placed under the .spec.config.sshKeyName.

The same SSH key will be used for all machines and a bastion host, or jump box. The bastion host is used as a single entry point that provides access to the rest of the cluster, enabling you to more tightly control access.

To enable the bastion, set the .spec.config.bastion.enabled option in the ClusterDeployment object to true.

You can get a full list of the bastion configuration options in the CAPA docs.

The resulting ClusterDeployment might look something like this:

apiVersion: k0rdent.mirantis.com/v1beta1
kind: ClusterDeployment
metadata:
  name: cluster-1
spec:
  template: aws-standalone-cp-1-0-0
  credential: aws-cred
  config:
    clusterLabels: {}
    sshKeyName: foobar
    bastion:
      enabled: true
...

EKS templates#

Warning

When deploying an EKS cluster please note that additional steps may be needed for proper VPC removal.

Warning

You may encounter an issue where EKS machines are not created due to the ControlPlaneIsStable preflight check failure during EKS cluster deployment. Please follow this instruction to apply the workaround.

EKS templates use parameters similar to AWS and the resulting EKS ClusterDeployment looks something like this:

apiVersion: k0rdent.mirantis.com/v1beta1
kind: ClusterDeployment
metadata:
  name: cluster-1
spec:
  template: aws-eks-1-0-0
  credential: aws-cred
  config:
    clusterLabels: {}
    sshKeyName: foobar
    region: ${AWS_REGION}
    workersNumber: 1
...

Non-root volumes#

To configure options for non-root storage volumes, set the corresponding fields in the ClusterDeployment responsible for these settings, which depend on the template in use:

Template Section(s)
aws-standalone-cp-1-0-0 .spec.controlPlane.nonRootVolumes,.spec.worker.nonRootVolumes
aws-hosted-cp-1-0-0 .spec.nonRootVolumes
aws-eks-1-0-0 .spec.worker.nonRootVolumes

The nonRootVolumes field is a list of Volumes.