Most of the content of this section will cover how EKS Anywhere deploys, upgrades and otherwise manages Kubernetes clusters. It will point to Kubernetes documentation for specifics on how Kubernetes itself works.
This is the multi-page printable view of this section. Click here to print.
- 1: Compare EKS Anywhere and EKS
- 2: Cluster creation workflow
- 3: Cluster topologies
- 4: EKS Anywhere curated packages
1 - Compare EKS Anywhere and EKS
Amazon EKS Anywhere is a new deployment option for Amazon EKS that enables you to easily create and operate Kubernetes clusters on-premises. EKS Anywhere provides an installable software package for creating and operating Kubernetes clusters on-premises and automation tooling for cluster lifecycle support. To learn more, see EKS Anywhere .
Amazon Elastic Kubernetes Service (Amazon EKS) is a managed Kubernetes service that makes it easy for you to run Kubernetes on the AWS cloud. Amazon EKS is certified Kubernetes conformant, so existing applications that run on upstream Kubernetes are compatible with Amazon EKS. To learn more about Amazon EKS, see Amazon Elastic Kubernetes Service .
Comparing Amazon EKS Anywhere to Amazon EKS
|Feature||Amazon EKS Anywhere||Amazon EKS|
|K8s control plane management||Managed by customer||Managed by AWS|
|K8s control plane location||Customer’s datacenter||AWS cloud|
|Cluster updates||Manual CLI updates for control plane. Flux supported rolling updates for data plane||Managed in-place updates for control plane and managed rolling updates for data plane.|
|Compute options||CloudStack, VMware vSphere, Bare Metal servers||Amazon EC2, AWS Fargate|
|Supported node operating systems||Bottlerocket, Ubuntu, and RHEL||Amazon Linux 2, Windows Server, Bottlerocket, Ubuntu|
|Physical hardware (servers, network equipment, storage, etc.)||Managed by customer||Managed by AWS|
|Serverless||Not supported||Amazon EKS on AWS Fargate|
|Command line interface (CLI)||
|Console view for Kubernetes objects||Optional EKS console connection using EKS Connector (public preview)||Native EKS console connection|
|Infrastructure-as-code||Cluster manifest, Kubernetes controllers, 3rd-party solutions||AWS CloudFormation, 3rd-party solutions|
|Logging and monitoring||3rd-party solutions||CloudWatch, CloudTrail, 3rd-party solutions|
|GitOps||Flux controller||Flux controller|
|Functions and tooling|
|Networking and Security||Cilium CNI and network policy supported||Amazon VPC CNI supported. Calico supported for network policy. Other compatible 3rd-party CNI plugins available.|
|Load balancer||Metallb||Elastic Load Balancing including Application Load Balancer (ALB), and Network Load Balancer (NLB)|
|Service mesh||Community or 3rd-party solutions||AWS App Mesh, community, or 3rd-party solutions|
|Community tools and Helm||Works with compatible community tooling and helm charts.||Works with compatible community tooling and helm charts.|
|Pricing and support|
|Control plane pricing||Free to download, paid support subscription option||Hourly pricing per cluster|
|AWS Support||Additional annual subscription (per cluster) for AWS support||Basic support included. Included in paid AWS support plans (developer, business, and enterprise)|
2 - Cluster creation workflow
Each EKS Anywhere cluster is built from a cluster specification file, with the structure of the configuration file based on the target provider for the cluster. Currently, Bare Metal, CloudStack, and VMware vSphere are the recommended providers for supported EKS Anywhere clusters. We step through the cluster creation workflow for those providers here.
Management and workload clusters
EKS Anywhere offers two cluster deployment topology options:
Standalone cluster: If want only a single EKS Anywhere cluster, you can deploy a self-managed, standalone cluster. This type of cluster contains all Cluster API (CAPI) management components needed to manage itself, including managing its own upgrades. It can also run workloads.
Management cluster with workload clusters: If you plan to deploy multiple clusters, the project recommends you first deploy a management cluster. The management cluster can then be used to deploy, upgrade, delete, and otherwise manage a fleet of workload clusters.
For further details about the different cluster topologies, see Cluster topologies
Before cluster creation
Some assets need to be in place before you can create an EKS Anywhere cluster. You need to have an Administrative machine that includes the tools required to create the cluster. Next, you need get the software tools and artifacts used to build the cluster. Then you also need to prepare the provider, such as a vCenter environment or a set of Bare Metal machines, on which to create the resulting cluster.
The Administrative machine is needed to provide:
- A place to run the commands to create and manage the target cluster.
- A Docker container runtime to run a temporary, local bootstrap cluster that creates the resulting target cluster on the vSphere provider.
- A place to hold the
kubeconfigfile needed to perform administrative actions using
kubeconfigfile is stored in the root of the folder created during cluster creation.)
See the Install EKS Anywhere guide for Administrative machine requirements.
EKS Anywhere software
To obtain EKS Anywhere software, you need Internet access to the repositories holding that software. EKS Anywhere software is divided into two types of components: The CLI interface for managing clusters and the cluster components and controllers used to run workloads and configure clusters. The software you need to obtain includes:
- Command line tools: Binaries to install on the administrative machine
- Cluster components and controllers: These components are listed on the artifacts page for each provider.
If you are operating behind a firewall that limits access to the Internet, you can configure EKS Anywhere to identify the location of the proxy service you choose to connect to the Internet.
For more information on the software used in EKS Distro, which includes the Kubernetes release and related software in EKS Anywhere, see the EKS Distro Releases GitHub page.
EKS Anywhere uses an infrastructure provider model for creating, upgrading, and managing Kubernetes clusters that leverages the Kubernetes Cluster API project.
Like Cluster API, EKS Anywhere runs a kind
cluster on the local Administrative machine to act as a bootstrap cluster.
However, instead of using CAPI directly with the
clusterctl command to manage the workload cluster, you use the
eksctl anywhere command which abstracts that process for you, including calling
clusterctl under the covers.
With your Administrative machine in place, you need to prepare your Bare Metal , vSphere , or CloudStack , provider for EKS Anywhere. The following sections describe how to create a Bare Metal or vSphere cluster.
Creating a Bare Metal cluster
The following diagram illustrates what happens when you start the cluster creation process for a Bare Metal provider, as described in the Bare Metal Getting started guide.
Start creating a Bare Metal cluster
1. Generate a config file for Bare Metal
Identify the provider (
--provider tinkerbell) and the cluster name to the
eksctl anywhere create clusterconfig command and direct the output into a cluster config
2. Modify the config file and hardware CSV file
Modify the generated cluster config file to suit your situation.
Details about this config file are contained on the Bare Metal Config
Create a hardware configuration file (
hardware.csv) as described in Prepare hardware inventory
3. Launch the cluster creation
eksctl anywhere cluster create command, providing the cluster config and hardware CSV files.
To see details on the cluster creation process, increase verbosity (
-v=9 provides maximum verbosity).
4. Create bootstrap cluster and provision hardware
The cluster creation process starts by creating a temporary Kubernetes bootstrap cluster on the Administrative machine. Containerized components of the Tinkerbell provisioner run either as pods on the bootstrap cluster (hegel, rufio, and tink) or directly as containers on Docker (boots). Those Tinkerbell components drive the provisioning of the operating systems and Kubernetes components on each of the physical computers.
With the information gathered from the cluster specification and the hardware CSV file, three custom resource definitions (CRDs) are created. These include:
- Hardware custom resources: Which store hardware information for each machine
- Template custom resources: Which store the tasks and actions
- Workflow custom resources: Which put together the complete hardware and template information for each machine. There are different workflows for control plane and worker nodes.
As the bootstrap cluster comes up and Tinkerbell components are started, you should see messages like the following:
$ eksctl anywhere create cluster --hardware-csv hardware.csv -f eksa-mgmt-cluster.yaml Performing setup and validations Tinkerbell Provider setup is valid Validate certificate for registry mirror Create preflight validations pass Creating new bootstrap cluster Provider specific pre-capi-install-setup on bootstrap cluster Installing cluster-api providers on bootstrap cluster Provider specific post-setup Creating new workload cluster
At this point, Tinkerbell will try to boot up the machines in the target cluster.
Continuing cluster creation
Tinkerbell takes over the activities for creating provisioning the Bare Metal machines to become the new target cluster. See Overview of Tinkerbell in EKS Anywhere for examples of commands you can run to watch over this process.
1. Tinkerbell PXE boots and configures nodes
- Rufio uses BMC information to set the power state for the first control plane node it wants to provision.
- When the node boots from its NIC, it talks to the Boots DHCP server, which fetches the kernel and initramfs (HookOS) needed to PXE boot the machine via HTTP.
- With HookOS running on the node, the operating system identified by
IMG_URLin the cluster specification is copied to the identified
DEST_DISKon the machine.
- The hegel components provides data stores that contain information used by services such as cloud-init to configure each system.
- Next, the workflow is run on the first control plane node, followed by PXE booting and running the workflow for each subsequent control plane node.
- Once the control plane is up, worker nodes are PXE booted and workflows are run to deploy each node.
2. Tinkerbell components move to the target cluster
Once all the defined nodes are added to the cluster, the Tinkerbell components and associated data are moved to run as pods on worker nodes in the new workload cluster.
Deleting Tinkerbell from Admin machine
All Tinkerbell-related pods and containers are then deleted from the Admin machine.
Further management of tinkerbell and related information can be done using from the new cluster, using tools such as
Creating a vSphere cluster
The following diagram illustrates what happens when you start the cluster creation process, as described in the vSphere Getting started guide.
Start creating a vSphere cluster
1. Generate a config file for vSphere
To this command, you identify the name of the provider (
-p vsphere) and a cluster name and redirect the output to a file.
The result is a config file template that you need to modify for the specific instance of your provider.
2. Modify the config file
Using the generated cluster config file, make modifications to suit your situation. Details about this config file are contained on the vSphere Config page.
3. Launch the cluster creation
Once you have modified the cluster configuration file, use
eksctl anywhere cluster create -f $CLUSTER_NAME.yaml starts the cluster creation process.
To see details on the cluster creation process, increase verbosity (
-v=9 provides maximum verbosity).
4. Authenticate and create bootstrap cluster
After authenticating to vSphere and validating the assets there, the cluster creation process starts off creating a temporary Kubernetes bootstrap cluster on the Administrative machine. To begin, the cluster creation process runs a series of govc commands to check on the vSphere environment:
Checks that the vSphere environment is available.
Using the URL and credentials provided in the cluster spec files, authenticates to the vSphere provider.
Validates the datacenter and the datacenter network exists:
Validates that the identified datastore (to store your EKS Anywhere cluster) exists, that the folder holding your EKS Anywhere cluster VMs exists, and that the resource pools containing compute resources exist. If you have multiple
VSphereMachineConfigobjects in your config file, will see these validations repeated:
Validates the virtual machine templates to be used for the control plane and worker nodes (such as
If all validations pass, you will see this message:
✅ Vsphere Provider setup is valid
Next, the process runs the kind command to build a single-node Kubernetes bootstrap cluster on the Administrative machine. This includes pulling the kind node image, preparing the node, writing the configuration, starting the control-plane, installing CNI, and installing the StorageClass. You will see:
After this point the bootstrap cluster is installed, but not yet fully configured.
Continuing cluster creation
The following diagram illustrates the activities that occur next:
1. Add CAPI management
Cluster API (CAPI) management is added to the bootstrap cluster to direct the creation of the target cluster.
2. Set up cluster
Configure the control plane and worker nodes.
3. Add Cilium networking
Add Cilium as the CNI plugin to use for networking between the cluster services and pods.
4. Add storage
Add the default storage class to the cluster
5. Add CAPI to target cluster
Add the CAPI service to the target cluster in preparation for it to take over management of the cluster after the cluster creation is completed and the bootstrap cluster is deleted. The bootstrap cluster can then begin moving the CAPI objects over to the target cluster, so it can take over the management of itself.
With the bootstrap cluster running and configured on the Administrative machine, the creation of the target cluster begins.
kubectl to apply a target cluster configuration as follows:
Once etcd, the control plane, and the worker nodes are ready, it applies the networking configuration to the target cluster.
The default storage class is installed on the target cluster.
CAPI providers are configured on the target cluster, in preparation for the target cluster to take over responsibilities for running the components needed to manage the itself.
With CAPI running on the target cluster, CAPI objects for the target cluster are moved from the bootstrap cluster to the target cluster’s CAPI service (done internally with the
Add Kubernetes CRDs and other addons that are specific to EKS Anywhere.
The cluster configuration is saved:
Once etcd, the control plane, and the worker nodes are ready, it applies the networking configuration to the workload cluster:
Installing networking on workload cluster
Next, the default storage class is installed on the workload cluster:
Installing storage class on workload cluster
After that, the CAPI providers are configured on the workload cluster, in preparation for the workload cluster to take over responsibilities for running the components needed to manage the itself.
Installing cluster-api providers on workload cluster
With CAPI running on the workload cluster, CAPI objects for the workload cluster are moved from the bootstrap cluster to the workload cluster’s CAPI service (done internally with the
Moving cluster management from bootstrap to workload cluster
At this point, the cluster creation process will add Kubernetes CRDs and other addons that are specific to EKS Anywhere. That configuration is applied directly to the cluster:
Installing EKS-A custom components (CRD and controller) on workload cluster Creating EKS-A CRDs instances on workload cluster Installing GitOps Toolkit on workload cluster
If you did not specify GitOps support, starting the flux service is skipped:
GitOps field not specified, bootstrap flux skipped
The cluster configuration is saved:
Writing cluster config file
With the cluster up, and the CAPI service running on the new cluster, the bootstrap cluster is no longer needed and is deleted:
At this point, cluster creation is complete. You can now use your target cluster as either:
- A standalone cluster (to run workloads) or
- A management cluster (to optionally create one or more workload clusters)
Creating workload clusters (optional)
As described in Create separate workload clusters , you can use the cluster you just created as a management cluster to create and manage one or more workload clusters on the same vSphere provider as follows:
eksctlto generate a cluster config file for the new workload cluster.
- Modify the cluster config with a new cluster name and different vSphere resources.
eksctlto create the new workload cluster from the new cluster config file and credentials from the initial management cluster.
3 - Cluster topologies
For trying out EKS Anywhere or for times when a single cluster is needed, it is fine to create a standalone cluster and run your workloads on it. However, if you plan to create multiple clusters for running Kubernetes workloads, we recommend you create a management cluster. Then use that management cluster to manage a set of workload clusters.
This document describes those two different EKS Anywhere cluster topologies.
What is an EKS Anywhere management cluster?
An EKS Anywhere management cluster is a long-lived, on-premises Kubernetes cluster that can create and manage a fleet of EKS Anywhere workload clusters.
The workload clusters are where you run your applications.
The management cluster can only be created and managed by the Amazon CLI
The management cluster runs on you hardware on-premises and it does not require any connectivity back to AWS to function. Customers are responsible for operating the management cluster including (but not limited to) patching, upgrading, scaling, and monitoring the cluster control plane and data plane.
What’s the difference between a management cluster and a standalone cluster?
From a technical point of view, they are the same. Regardless of which deployment topology you choose, you always start by creating a singleton, standalone cluster that’s capable of managing itself. This shows examples of separate, standalone clusters:
Once a standalone cluster is created, you have an option to use it to use it as a management cluster to create separate workload cluster(s) under it, hence making this cluster a long-lived management cluster.
You can only use
eksctl to create or delete the management cluster or a standalone cluster.
This shows examples of a management cluster that deploys and manages multiple workload clusters:
What’s the difference between a management cluster and a bootstrap cluster for EKS Anywhere?
A management cluster is a long-lived entity you have to actively operate.
The bootstrap cluster is a temporary, short-lived kind cluster that is created on a separate Administrative machine
to facilitate the creation of an initial standalone or management cluster.
You do not need to interact or operate the
kind cluster will be automatically deleted by the end of the initial cluster creation.
When should I deploy a management cluster?
If you want to run three or more EKS Anywhere clusters, we recommend that you choose a management/workload cluster deployment topology because of the advantages listed in the table below. The EKS Anywhere Curated Packages feature recommends deploying certain packages such as the container registry package or monitoring packages on the management cluster to avoid circular dependency.
|Standalone cluster topology||Management/workload cluster topology|
|Pros||Save hardware resources||Isolation of secrets|
|Reduced operational overhead of maintaining a separate management cluster||Resource isolation between different teams. Reduced noisy-neighbor effect.|
|Isolation between development and production workloads.|
|Isolation between applications and fleet management services, such as monitoring server or container registry.|
|Provides a central control plane and API to automate cluster lifecycles|
|Cons||Shared secrets such, as SSH credentials or VMware credentials, across all teams who share the cluster.||Consumes extra resources.|
|Without a central control plane (such as a parent management cluster), it is not possible to automate cluster creation/deletion with advanced methods like GitOps or IaC.||The creation/deletion of the management cluster itself can’t be automated through GitOps or IaC.|
|Circular dependencies arise if the cluster has to host a monitoring server or a local container registry.|
Which EKS Anywhere features support the management/workload cluster deployment topology today?
|Create/update/delete a workload cluster on…|
|Update a workload cluster on…|
|Create/delete a workload cluster on…|
|Install a curated package on the management cluster||Y|
|Install a curated package on the workload cluster from the management cluster||Y|
|Install a curated package on the management cluster during a workload cluster creation||N|
4 - EKS Anywhere curated packages
NoteThe Amazon EKS Anywhere Curated Packages are only available to customers with the Amazon EKS Anywhere Enterprise Subscription. To request a free trial, talk to your Amazon representative or connect with one here.
Amazon EKS Anywhere Curated Packages are Amazon-curated software packages that extend the core functionalities of Kubernetes on your EKS Anywhere clusters. If you operate EKS Anywhere clusters on-premises, you probably install additional software to ensure the security and reliability of your clusters. However, you may be spending a lot of effort researching for the right software, tracking updates, and testing them for compatibility. Now with the EKS Anywhere Curated Packages, you can rely on Amazon to provide trusted, up-to-date, and compatible software that are supported by Amazon, reducing the need for multiple vendor support agreements.
- Amazon-built: All container images of the packages are built from source code by Amazon, including the open source (OSS) packages. OSS package images are built from the open source upstream.
- Amazon-scanned: Amazon scans the container images including the OSS package images daily for security vulnerabilities and provides remediation.
- Amazon-signed: Amazon signs the package bundle manifest (a Kubernetes manifest) for the list of curated packages. The manifest is signed with AWS Key Management Service (AWS KMS) managed private keys. The curated packages are installed and managed by a package controller on the clusters. Amazon provides validation of signatures through an admission control webhook in the package controller and the public keys distributed in the bundle manifest file.
- Amazon-tested: Amazon tests the compatibility of all curated packages including the OSS packages with each new version of EKS Anywhere.
- Amazon-supported: All curated packages including the curated OSS packages are supported under the EKS Anywhere Support Subscription.
The main components of EKS Anywhere Curated Packages are the package controller , the package build artifacts and the command line interface . The package controller will run in a pod in an EKS Anywhere cluster. The package controller will manage the lifecycle of all curated packages.
Please check out curated package list for the complete list of EKS Anywhere curated packages.
Please check out workshop for curated packages.
Can I install software not from the curated package list?
Yes. You can install any optional software of your choice. Be aware you cannot use EKS Anywhere tooling to install or update your self-managed software. Amazon does not provide testing, security patching, software updates, or customer support for your self-managed software.
Can I install software that’s on the curated package list but not sourced from EKS Anywhere repository?
If, for example, you deploy a Harbor image that is not built and signed by Amazon, Amazon will not provide testing or customer support to your self-built images.
4.1 - EKS Anywhere curated package controller
The package controller will install, upgrade, configure and remove packages from the cluster. The package controller will watch the packages and packagebundle custom resources for the packages to run and their configuration values. The package controller only runs on the management cluster and manages packages on the management cluster and on the workload clusters.
Package release information is stored in a package bundle manifest. The package controller will continually monitor and download new package bundles. When a new package bundle is downloaded, it will show up as update available and users can use the CLI to activate the bundle to upgrade the installed packages.
Any changes to a package custom resource will trigger and install, upgrade, configuration or removal of that package. The package controller will use ECR or private registry to get all resources including bundle, helm charts, and container images.
Please check out package management for how to install package controller after cluster creation and manage curated packages.
4.2 - EKS Anywhere curated package build artifacts
There are three types of build artifacts for packages: the container images, the helm charts and the package bundle manifests. The container images, helm charts and bundle manifests for all of the packages will be built and stored in EKS Anywhere ECR repository. Each package may have multiple versions specified in the packages bundle. The bundle will reference the helm chart tag in the ECR repository. The helm chart will reference the container images for the package.
4.3 - EKS Anywhere curated package CLI
The Curated Packages CLI provides the user experience required to manage curated packages. Through the CLI, a user is able to discover, create, delete, and upgrade curated packages to a cluster. These functionalities can be achieved during and after an EKS Anywhere cluster is created.
The CLI provides both imperative and declarative mechanisms to manage curated packages. These
packages will be included as part of a
packagebundle that will be provided by the EKS Anywhere team.
Whenever a user requests a package creation through the CLI (
eksctl anywhere create package), a custom resource is created on the cluster
indicating the existence of a new package that needs to be installed. When a user executes a delete operation (
eksctl anywhere delete package),
the custom resource will be removed from the cluster indicating the need for uninstalling a package.
An upgrade through the CLI (
eksctl anywhere upgrade packages) upgrades all packages to the latest release.
Please check out Install EKS Anywhere
to install the
eksctl anywhere CLI on your machine.
Check out EKS Anywhere curated package management for how to use the CLI after a cluster is created and manage curated packages.