**Ajudar a melhorar esta página** 

Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.

# Executar complementos críticos em instâncias dedicadas
<a name="critical-workload"></a>

Neste tópico, você aprenderá como implantar uma workload com uma tolerância `CriticalAddonsOnly` para que o Modo Automático do EKS a programe no grupo de nós `system`.

O grupo de nós `system` integrado do Modo Automático do EKS foi projetado para executar complementos críticos em instâncias dedicadas. Essa segmentação garante que os componentes essenciais tenham recursos dedicados e fiquem isolados das workloads gerais, aprimorando a estabilidade e a performance gerais do cluster.

Este guia demonstra como implantar complementos no grupo de nós `system` usando a tolerância `CriticalAddonsOnly` e os seletores de nós apropriados. Seguindo estas etapas, você pode garantir que as aplicações críticas sejam programadas nos nós `system` dedicados, aproveitando os benefícios de isolamento e alocação de recursos fornecidos pela estrutura especializada de grupo de nós do Modo Automático do EKS.

O Modo Automático do EKS tem dois grupos de nós integrados: `general-purpose` e `system`. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).

O objetivo do grupo de nós `system` é segregar complementos críticos em nós diferentes. Os nós provisionados pelo grupo de nós `system` têm um taint `CriticalAddonsOnly` do Kubernetes. O Kubernetes apenas programará pods nesses nós se eles tiverem uma tolerância correspondente. Para obter mais informações, consulte [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) na documentação do Kubernetes.

## Pré-requisitos
<a name="_prerequisites"></a>
+ Cluster do Modo Automático do EKS com o grupo de nós `system` integrado habilitado. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md). 
+  `kubectl` instalado e configurado. Para ter mais informações, consulte [Configurar para usar o Amazon EKS](setting-up.md).

## Procedimento
<a name="_procedure"></a>

Analise o exemplo de YAML abaixo. Observe as seguintes configurações:
+  `nodeSelector`: associa a workload ao grupo de nós `system` integrado. Esse grupo de nós deve ser habilitado com a API da AWS. Para ter mais informações, consulte [Habilitar ou desabilitar NodePools integrados](set-builtin-node-pools.md).
+  `tolerations`: esta tolerância supera o taint `CriticalAddonsOnly` nos nós do grupos de nós `system`.

```
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"
```

Para atualizar uma workload para executar no grupo de nós `system`, você precisa:

1. Atualizar a workload existente para adicionar as seguintes configurações descritas acima:
   +  `nodeSelector` 
   +  `tolerations` 

1. Implantar a workload atualizada no cluster com `kubectl apply` 

Depois de atualizar a workload, ela será executada em nós dedicados.