Déployer des nœuds Windows sur des clusters EKS - Amazon EKS
ConsidérationsPrérequisActiver la prise en charge de WindowsDéployer des pods WindowsPrise en charge d’une densité de pods plus élevée sur les nœuds Windows

Aidez à améliorer cette page

Pour contribuer à ce guide de l’utilisateur, cliquez sur le lien Modifier cette page sur GitHub 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 Créer un HostProcessPod Windows dans la documentation 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 le même rôle IAM pour les nœuds Linux et Windows.

  • 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 Adresses IP par interface réseau par type d’instance dans le Guide de l’utilisateur Amazon EC2.

  • 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 soumettre des problèmes concernant le contrôleur, visitez le projet sur GitHub.

  • Lorsque vous spécifiez un ID d’AMI personnalisé pour les groupes de nœuds gérés par Windows, ajoutez eks:kube-proxy-windows à votre carte de configuration AWS IAM Authenticator. Pour de plus amples informations, consultez Limites et conditions lors de la spécification d'un ID d'AMI.

  • Si la conservation de vos adresses IPv4 disponibles est cruciale pour votre sous-réseau, veuillez vous reporter au Guide des bonnes pratiques 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, consultez 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

Prérequis

  • 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

  1. 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 votre rôle de 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.

  2. Associez la politique gérée AmazonEKSVPCResourceController à votre rôle IAM de cluster Amazon EKS. Remplacez eksClusterRole par le nom de votre rôle de cluster.

    aws iam attach-role-policy \
  --role-name eksClusterRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController

  3. Mettez à jour la ConfigMap CNI VPC pour activer Windows IPAM. Veuillez noter que si CNI VPC est installé sur votre cluster à l’aide des Charts de Helm ou en tant que module complémentaire Amazon EKS, vous ne pourrez peut-être pas modifier directement la 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 le contenu suivant.

      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

  4. 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.

  5. 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, consultez Attribution de davantage d’adresses IP aux nœuds Amazon EKS avec des préfixes.