Select your cookie preferences

We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.

If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”

Run critical add-ons on dedicated instances

Focus mode
Run critical add-ons on dedicated instances - Amazon EKS

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

In this topic, you will learn how to deploy a workload with a CriticalAddonsOnly toleration so EKS Auto Mode will schedule it onto the system node pool.

EKS Auto Mode’s built-in system node pool is designed for running critical add-ons on dedicated instances. This segregation ensures essential components have dedicated resources and are isolated from general workloads, enhancing overall cluster stability and performance.

This guide demonstrates how to deploy add-ons to the system node pool by utilizing the CriticalAddonsOnly toleration and appropriate node selectors. By following these steps, you can ensure that your critical applications are scheduled onto the dedicated system nodes, leveraging the isolation and resource allocation benefits provided by EKS Auto Mode’s specialized node pool structure.

EKS Auto Mode has two built-in node pools: general-purpose and system. For more information, see Enable or Disable Built-in NodePools.

The purpose of the system node pool is to segregate critical add-ons onto different nodes. Nodes provisioned by the system node pool have a CriticalAddonsOnly Kubernetes taint. Kubernetes will only schedule pods onto these nodes if they have a corresponding toleration. For more information, see Taints and Tolerations in the Kubernetes documentation.

Prerequisites

Procedure

Review the example yaml below. Note the following configurations:

  • nodeSelector — This associates the workload with the built-in system node pool. This node pool must be enabled with the AWS API. For more information, see Enable or Disable Built-in NodePools.

  • tolerations — This toleration overcomes the CriticalAddonsOnly taint on nodes in the system node pool.

apiVersion: apps/v1 kind: Deployment metadata: name: sample-app spec: replicas: 3 selector: matchLabels: app: sample-app template: metadata: labels: app: sample-app spec: nodeSelector: karpenter.sh/nodepool: system tolerations: - key: "CriticalAddonsOnly" operator: "Exists" containers: - name: app image: nginx:latest resources: requests: cpu: "500m" memory: "512Mi"

To update a workload to run on the system node pool, you need to:

  1. Update the existing workload to add the following configurations described above:

    • nodeSelector

    • tolerations

  2. Deploy the updated workload to your cluster with kubectl apply

After updating the workload, it will run on dedicated nodes.

PrivacySite termsCookie preferences
© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved.