Considérations Conditions préalables Activer la prise en charge de Windows Déployer des pods Windows Prise en charge d’une densité de pods plus élevée sur les nœuds Windows

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.

Déployer des nœuds Windows sur des clusters EKS

Découvrez comment activer et gérer la prise en charge de Windows pour votre cluster Amazon EKS afin d’exécuter des conteneurs Windows parallèlement à des conteneurs Linux.

Considérations

Avant de déployer des nœuds Windows, veuillez tenir compte des considérations suivantes.

Le mode automatique EKS ne prend pas en charge les nœuds Windows
Vous pouvez utiliser le réseau hôte sur les nœuds Windows à l'aide des pods HostProcess. Pour plus d'informations, consultez la section Créer une fenêtre HostProcessPod dans la documentation de Kubernetes.
Les clusters Amazon EKS doivent contenir un ou plusieurs nœuds Linux ou Fargate pour exécuter les pods système de base qui ne fonctionnent que sous Linux, tels que CoreDNS.
Les journaux d’événements kubelet et kube-proxy sont journalisés vers le journal d’événements EKS Windows et sont limités à 200 Mo.
Vous ne pouvez pas utiliser Attribuer des groupes de sécurité à des pods individuels avec des pods s’exécutant sur des nœuds Windows.
Vous ne pouvez pas utiliser la mise en réseau personnalisée avec des nœuds Windows.
Il n’est pas possible d’utiliser IPv6 avec les nœuds Windows.
Les nœuds Windows prennent en charge une interface réseau Elastic par nœud. Par défaut, le nombre de pods pouvant être exécutés par nœud Windows est égal au nombre d’adresses IP disponibles par interface réseau Elastic pour le type d’instance du nœud, moins un. Pour plus d'informations, consultez la section Adresses IP par interface réseau et par type d'instance dans le guide de EC2 l'utilisateur Amazon.
Dans un cluster Amazon EKS, un seul service avec un équilibreur de charge peut prendre en charge jusqu’à 1 024 pods dorsaux. Chaque pod a sa propre adresse IP. La limite précédente de 64 pods n’est plus le cas, après une mise à jour de Windows Server à partir de OS Build 17763.2746.
Les conteneurs Windows ne sont pas pris en charge pour les pods Amazon EKS sur Fargate.
Vous ne pouvez pas utiliser les nœuds hybrides Amazon EKS avec Windows comme système d’exploitation pour l’hôte.
Vous ne pouvez pas journaliser les journaux à partir du pod vpc-resource-controller. Vous le pouviez auparavant lorsque vous déployiez le contrôleur sur le plan de données.
Il y a un temps de stabilisation avant qu'une adresse IPv4 ne soit affectée à un nouveau pod. Cela empêche le trafic de s'écouler vers un pod plus ancien avec la même adresse IPv4 en raison de règles kube-proxy périmées.
La source du contrôleur est gérée sur GitHub. Pour contribuer ou signaler des problèmes contre le contrôleur, consultez le projet sur GitHub.
Lorsque vous spécifiez un ID AMI personnalisé pour les groupes de nœuds gérés par Windows, ajoutez-le eks:kube-proxy-windows à votre carte de configuration AWS IAM Authenticator. Pour de plus amples informations, veuillez consulter Limites et conditions lors de la spécification d'un ID d'AMI.
S'il est essentiel de préserver IPv4 les adresses disponibles pour votre sous-réseau, reportez-vous au Guide des meilleures pratiques d'EKS - Gestion des adresses IP réseau Windows pour obtenir des conseils.
Considérations relatives aux entrées d’accès EKS
- Les entrées d’accès à utiliser avec les nœuds Windows doivent être de type EC2_WINDOWS. Pour de plus amples informations, veuillez consulter Créer des entrées d’accès.
  
  Pour créer une entrée d’accès pour un nœud Windows :
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/<role-name> --type EC2_Windows
```

Conditions préalables

Un cluster existant.
Votre cluster doit comporter au moins un nœud Linux ou un pod Fargate (nous recommandons au moins deux) pour exécuter CoreDNS. Si vous activez la prise en charge Windows héritée, vous devez utiliser un nœud Linux (vous ne pouvez pas utiliser un pod Fargate) pour exécuter CoreDNS.
Un rôle IAM de cluster Amazon EKS existant.

Activer la prise en charge de Windows

Si votre cluster ne comporte pas de nœuds Amazon Linux et que vous utilisez des groupes de sécurité pour les pods, passez à l’étape suivante. Sinon, confirmez que la politique gérée AmazonEKSVPCResourceController est attachée à votre rôle de cluster. Remplacez eksClusterRole par le nom de rôle de votre cluster.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
L'exemple qui suit illustre un résultat.
```
{
    "AttachedPolicies": [
        {
            "PolicyName": "AmazonEKSClusterPolicy",
            "PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy"
        },
        {
            "PolicyName": "AmazonEKSVPCResourceController",
            "PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController"
        }
    ]
}
```
Si la politique est attachée, comme c'est le cas dans la sortie précédente, passez à l'étape suivante.
Associez la politique gérée par Amazon EKSVPCResource Controller au rôle IAM de votre cluster Amazon EKS. Remplacez eksClusterRole par le nom de rôle de votre cluster.
```
aws iam attach-role-policy \
  --role-name eksClusterRole \
  --policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
Mettez à jour le VPC CNI ConfigMap pour activer Windows IPAM. Notez que si le VPC CNI est installé sur votre cluster à l'aide d'un graphique Helm ou en tant que module complémentaire Amazon EKS, vous ne pourrez peut-être pas modifier directement le. ConfigMap Pour plus d’informations sur la configuration des modules complémentaires Amazon EKS, consultez Déterminez les champs que vous pouvez personnaliser pour les modules complémentaires Amazon EKS.
1. Créez un fichier nommé vpc-resource-controller-configmap.yaml avec les contenus suivants.
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-windows-ipam: "true"
```
2. Appliquer le ConfigMap à votre cluster.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
Si le mode d’authentification de votre cluster est défini pour activer la configmap aws-auth :
- Vérifiez que votre aws-auth ConfigMap contient un mappage pour le rôle d’instance du nœud Windows afin d’inclure le groupe d’autorisation RBAC eks:kube-proxy-windows. Vous pouvez vérifier en exécutant la commande suivante.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
  L'exemple qui suit illustre un résultat.
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
      rolearn: arn:aws: iam::111122223333:role/eksNodeRole
      username: system:node:{{EC2PrivateDNSName}}
[...]
```
  Vous devriez voir eks:kube-proxy-windows répertorié sous les groupes. Si le groupe n’est pas spécifié, vous devez mettre à jour votre ConfigMap ou le créer pour inclure le groupe requis. Pour en savoir plus sur ConfigMap aws-auth, consultez Appliquer la ConfigMap aws-auth à votre cluster.
Si le mode d’authentification de votre cluster est défini pour désactiver la configmap aws-auth, vous pouvez utiliser les entrées d’accès EKS. Créez un nouveau rôle de nœud à utiliser avec les instances Windows, et EKS créera automatiquement une entrée d’accès de type EC2_WINDOWS.

Déployer des pods Windows

Lorsque vous déployez des pods sur votre cluster, vous devez spécifier le système d’exploitation qu’ils utilisent si vous exécutez plusieurs types de nœuds.

Pour les pods Linux, utilisez le texte de sélecteur de nœud suivant dans vos manifestes.


nodeSelector:
        kubernetes.io/os: linux
        kubernetes.io/arch: amd64

Pour les pods Windows, utilisez le texte de sélecteur de nœud suivant dans vos manifestes.


nodeSelector:
        kubernetes.io/os: windows
        kubernetes.io/arch: amd64

Vous pouvez déployer un exemple d'application pour voir les sélecteurs de nœuds utilisés.

Prise en charge d’une densité de pods plus élevée sur les nœuds Windows

Dans Amazon EKS, chaque pod se voit attribuer une adresse IPv4 provenant de votre VPC. De ce fait, le nombre de pods que vous pouvez déployer sur un nœud est limité par les adresses IP disponibles, même si les ressources sont suffisantes pour exécuter davantage de pods sur le nœud. Étant donné qu'une seule interface réseau élastique est prise en charge par un nœud Windows, par défaut, le nombre maximal d'adresses IP disponibles sur un nœud Windows est égal à :


Number of private IPv4 addresses for each interface on the node - 1

Une adresse IP est utilisée comme adresse IP principale de l’interface réseau, elle ne peut donc pas être attribuée aux pods.

Vous pouvez activer une densité de pods plus élevée sur les nœuds Windows en activant la délégation de préfixe IP. Cette fonctionnalité vous permet d'attribuer un préfixe /28 IPv4 à l'interface réseau principale, au lieu d'attribuer des adresses secondaires IPv4. L'attribution d'un préfixe IP augmente le nombre maximum d'adresses IPv4 disponibles sur le nœud à :


(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16

Grâce à ce nombre considérablement plus important d’adresses IP disponibles, celles-ci ne devraient plus limiter votre capacité à faire évoluer le nombre de pods sur vos nœuds. Pour de plus amples informations, veuillez consulter Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Configuration de l’accès au point de terminaison

Désactiver la prise en charge Windows