**Aidez à améliorer cette page** 

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien **Modifier cette page sur** qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exécutez les modules complémentaires critiques sur des instances dédiées.
<a name="critical-workload"></a>

Dans cette rubrique, vous apprendrez comment déployer une charge de travail avec une tolérance `CriticalAddonsOnly` afin que le mode automatique EKS la planifie sur le pool de nœuds `system`.

Le pool de nœuds `system` intégré au mode automatique EKS est conçu pour exécuter des modules complémentaires essentiels sur des instances dédiées. Cette séparation garantit que les composants essentiels disposent de ressources dédiées et sont isolés des charges de travail générales, ce qui améliore la stabilité et les performances globales du cluster.

Ce guide explique comment déployer des modules complémentaires dans le pool de nœuds `system` en utilisant la tolérance `CriticalAddonsOnly` et les sélecteurs de nœuds appropriés. En suivant ces étapes, vous pouvez vous assurer que vos applications critiques sont planifiées sur les nœuds `system` dédiés, en tirant parti des avantages en termes d’isolation et d’allocation des ressources offerts par la structure de pool de nœuds spécialisée du mode automatique EKS.

Le mode automatique EKS dispose de deux pools de nœuds intégrés : `general-purpose` et `system`. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).

Le but du pool de nœuds `system` est de séparer les modules complémentaires critiques sur différents nœuds. Les nœuds provisionnés par le pool de nœuds `system` ont un rejet Kubernetes `CriticalAddonsOnly`. Kubernetes ne planifiera les pods sur ces nœuds que s’ils ont une tolérance correspondante. Pour plus d’informations, consultez [Rejets et tolérances](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dans la documentation de Kubernetes.

## Prérequis
<a name="_prerequisites"></a>
+ Le cluster du mode automatique EKS avec le groupe de nœuds `system` intégré activé. Pour plus d’informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md). 
+  `kubectl` installé et configuré. Pour de plus amples informations, consultez [Configuration pour utiliser Amazon EKS](setting-up.md).

## Procédure
<a name="_procedure"></a>

Consultez l’exemple YAML ci-dessous. Notez les configurations suivantes :
+  `nodeSelector`—  Cela associe la charge de travail au pool de nœuds `system` intégré. Ce pool de nœuds doit être activé avec l’API AWS. Pour de plus amples informations, consultez [Activer ou désactiver la fonction intégrée NodePools](set-builtin-node-pools.md).
+  `tolerations` : cette tolérance permet de surmonter le rejet `CriticalAddonsOnly` des nœuds dans le groupe de nœuds `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"
```

Pour mettre à jour une charge de travail afin qu’elle s’exécute sur le pool de nœuds `system`, vous devez :

1. Mettez à jour la charge de travail existante pour ajouter les configurations suivantes décrites ci-dessus :
   +  `nodeSelector` 
   +  `tolerations` 

1. Déployez la charge de travail mise à jour sur votre cluster avec `kubectl apply` 

Une fois la charge de travail mise à jour, elle s’exécutera sur des nœuds dédiés.