Learn About Amazon VGT2 Learning Manager Chanci Turner
Since its debut in 2018, Amazon Elastic Kubernetes Service (EKS) has steadily enhanced its mission to streamline the process of building, securing, operating, and maintaining Kubernetes clusters. Initially, this was achieved through a managed Kubernetes control plane that replaced the cumbersome tasks of provisioning, curating, and assembling the various software components of a cluster control plane with a single API call. In 2019, EKS further expanded its lifecycle management capabilities by introducing managed node groups for provisioning and managing cluster compute resources.
With Amazon EKS managed node groups, the automation of node provisioning and lifecycle management for your Kubernetes clusters is simplified. This feature abstracts Amazon EC2 instances and Auto Scaling groups, enabling easy one-step operations in EKS to oversee groups of cluster nodes. When utilizing managed node groups in EKS, your Kubernetes nodes are supported by EC2 instances managed by an Auto Scaling group within your account. This means you no longer need to provision EC2 instances separately, curate your own Kubernetes node AMIs, or handle the integration of nodes into the cluster. You can easily create, upgrade, and remove groups of nodes using straightforward operations in EKS.
We are consistently working on enhancing the service’s capabilities for our users. Our motivation since the launch of managed node groups has been to lower entry barriers while providing all necessary customizations, configurations, and automation. The aim is for managed node groups to become the preferred and optimal method for deploying EC2 compute resources for your EKS clusters, easing the infrastructure burden even further for our customers.
Initially, managed node groups were designed to provide the best out-of-the-box experience, supporting only the curated Amazon EKS-optimized Amazon Linux 2 AMIs with a standard configuration. Last year, we rolled out support for custom AMIs and customization via EC2 launch template specifications, catering to a broader range of customer use cases. Additionally, we’ve increased the capacity of groups and their default service quotas, now allowing for 30 groups of 450 nodes each.
As the adoption of EKS managed node groups accelerates, we are determined to make this feature the best option for provisioning discrete Kubernetes compute resources on EC2. Over the last few months, our team has implemented several improvements, unlocking new use cases and simplifying operations for users. In the following sections, we will explore these recent features and look ahead.
Managed Node Groups Feature Overview
Parallel Node Upgrades
Starting with the latest EKS feature, we introduced parallel node upgrades for managed node groups earlier this month. When upgrading a managed node group in EKS, the process is automated to minimize disruption to your scheduled workloads. During this operation, Kubernetes nodes are cordoned and drained before being replaced with the upgraded node version. Previously, this upgrade was conducted one node at a time to ensure minimal disruption.
This new feature allows you to configure either the number of nodes or the percentage of total nodes within a group that can be unavailable during an upgrade. This flexibility enables you to determine how many nodes EKS will update at once based on your application’s tolerance for cycling larger numbers of nodes. You can specify this setting when creating a new node group or modify an existing one.
Kubernetes Node Taints
Next, we are pleased to announce native support for adding Kubernetes node taints through the managed node groups API. This feature was highly requested on the AWS Container Services Roadmap, and we were thrilled to launch it recently. EKS has allowed for automatic addition of Kubernetes labels to nodes during managed node group configuration. However, prior to this update, customers had to apply node taints using the Kubernetes API once the nodes were part of the cluster.
With this feature, you can now specify taints directly in the node group specification during creation or by modifying an existing group. Once your node group is created or updated, the nodes will be tainted as specified.
In Kubernetes, taints are used, along with tolerations, to manage workload scheduling, ensuring applications and services run only on designated compute resources within your cluster. This process involves adding taints to nodes, which prevents the scheduler from deploying pods unless they possess specific tolerations, creating an explicit configuration pattern to bind pods to particular nodes.
Scale-to-Zero in the Managed Node Groups API
This feature introduces a preliminary phase for scaling EKS managed node groups to and from zero. With this enhancement, you can now configure both the minimum and desired size of a node group to zero. This functionality allows you to scale down to zero nodes and subsequently scale back up from a group that has no active nodes.
You can achieve this by setting the minimum size of the group configuration to zero. This is particularly beneficial for development clusters, enabling you to deactivate compute resources when not in use, and integrating this capability into pipelines for scaling temporary workload resources.
Amazon EKS-Optimized AMI Changes and Version Support
To conclude our overview of recent features, I want to highlight some changes regarding the EKS-optimized Amazon Linux 2 AMIs. Notably, managed node groups now support all versions of its curated selection of EKS-optimized AMIs.
For more insights and to enrich your onboarding experience, consider checking out this webinar, which offers valuable perspectives. Additionally, if you’re interested in understanding the implications of inflation on workers, refer to this SHRM article, as they are an authority on the subject. For excellent onboarding resources, visit this page.