Manage compute resources by using nodes - Amazon EKS

Manage compute resources by using nodes

A Kubernetes node is a machine that runs containerized applications. Each node has the following components:

  • Container runtime – Software that’s responsible for running the containers.

  • kubelet – Makes sure that containers are healthy and running within their associated Pod.

  • kube-proxy – Maintains network rules that allow communication to your Pods.

For more information, see Nodes in the Kubernetes documentation.

Your Amazon EKS cluster can schedule Pods on any combination of self-managed nodes, Amazon EKS managed node groups, and AWS Fargate. To learn more about nodes deployed in your cluster, see View Kubernetes resources in the AWS Management Console.

Important

AWS Fargate with Amazon EKS isn’t available in AWS GovCloud (US-East) and AWS GovCloud (US-West).

Note

Nodes must be in the same VPC as the subnets you selected when you created the cluster. However, the nodes don’t have to be in the same subnets.

The following table provides several criteria to evaluate when deciding which options best meet your requirements. This table doesn’t include connected nodes that were created outside of Amazon EKS, which can only be viewed.

Note

Bottlerocket has some specific differences from the general information in this table. For more information, see the Bottlerocket documentation on GitHub.

Criteria EKS managed node groups Self managed nodes AWS Fargate

Can be deployed to AWS Outposts

No

Yes

No

Can be deployed to an AWS Local Zone

No

Yes – For more information, see Launch low-latency EKS clusters with AWS Local Zones.

No

Can run containers that require Windows

Yes

Yes – Your cluster still requires at least one (two recommended for availability) Linux node though.

No

Can run containers that require Linux

Yes

Yes

Yes

Can run workloads that require the Inferentia chip

Yes – Amazon Linux nodes only

Yes – Amazon Linux only

No

Can run workloads that require a GPU

Yes – Amazon Linux nodes only

Yes – Amazon Linux only

No

Can run workloads that require Arm processors

Yes

Yes

No

Can run AWS Bottlerocket

Yes

Yes

No

Pods share a kernel runtime environment with other Pods

Yes – All of your Pods on each of your nodes

Yes – All of your Pods on each of your nodes

No – Each Pod has a dedicated kernel

Pods share CPU, memory, storage, and network resources with other Pods.

Yes – Can result in unused resources on each node

Yes – Can result in unused resources on each node

No – Each Pod has dedicated resources and can be sized independently to maximize resource utilization.

Pods can use more hardware and memory than requested in Pod specs

Yes – If the Pod requires more resources than requested, and resources are available on the node, the Pod can use additional resources.

Yes – If the Pod requires more resources than requested, and resources are available on the node, the Pod can use additional resources.

No – The Pod can be re-deployed using a larger vCPU and memory configuration though.

Must deploy and manage Amazon EC2 instances

Yes – automated through Amazon EKS if you deployed an Amazon EKS optimized AMI. If you deployed a custom AMI, then you must update the instance manually.

Yes – Manual configuration or using Amazon EKS provided AWS CloudFormation templates to deploy Linux (x86), Linux (Arm), or Windows nodes.

No

Must secure, maintain, and patch the operating system of Amazon EC2 instances

Yes

Yes

No

Can provide bootstrap arguments at deployment of a node, such as extra kubelet arguments.

Yes – Using eksctl or a launch template with a custom AMI

Yes – For more information, see the bootstrap script usage information on GitHub.

No

Can assign IP addresses to Pods from a different CIDR block than the IP address assigned to the node.

Yes – Using a launch template with a custom AMI. For more information, see Customize managed nodes with launch templates.

Yes – For more information, see Deploy pods in alternate subnets with custom networking.

No

Can SSH into node

Yes

Yes

No – There’s no node host operating system to SSH to.

Can deploy your own custom AMI to nodes

Yes – Using a launch template

Yes

No

Can deploy your own custom CNI to nodes

Yes – Using a launch template with a custom AMI

Yes

No

Must update node AMI on your own

Yes – If you deployed an Amazon EKS optimized AMI, you’re notified in the Amazon EKS console when updates are available. You can perform the update with one-click in the console. If you deployed a custom AMI, you’re not notified in the Amazon EKS console when updates are available. You must perform the update on your own.

Yes – Using tools other than the Amazon EKS console. This is because self-managed nodes can’t be managed with the Amazon EKS console.

No

Must update node Kubernetes version on your own

Yes – If you deployed an Amazon EKS optimized AMI, you’re notified in the Amazon EKS console when updates are available. You can perform the update with one-click in the console. If you deployed a custom AMI, you’re not notified in the Amazon EKS console when updates are available. You must perform the update on your own.

Yes – Using tools other than the Amazon EKS console. This is because self-managed nodes can’t be managed with the Amazon EKS console.

No – You don’t manage nodes.

Can use Amazon EBS storage with Pods

Yes

Yes

No

Can use Amazon EFS storage with Pods

Yes

Yes

Yes

Can use Amazon FSx for Lustre storage with Pods

Yes

Yes

No

Can use Network Load Balancer for services

Yes

Yes

Yes, when using the Create a network load balancer

Pods can run in a public subnet

Yes

Yes

No

Can assign different VPC security groups to individual Pods

Yes – Linux nodes only

Yes – Linux nodes only

Yes

Can run Kubernetes DaemonSets

Yes

Yes

No

Support HostPort and HostNetwork in the Pod manifest

Yes

Yes

No

AWS Region availability

All Amazon EKS supported regions

All Amazon EKS supported regions

Some Amazon EKS supported regions

Can run containers on Amazon EC2 dedicated hosts

Yes

Yes

No

Pricing

Cost of Amazon EC2 instance that runs multiple Pods. For more information, see Amazon EC2 pricing.

Cost of Amazon EC2 instance that runs multiple Pods. For more information, see Amazon EC2 pricing.

Cost of an individual Fargate memory and CPU configuration. Each Pod has its own cost. For more information, see AWS Fargate pricing.