Distribuisci Windows nodi su cluster EKS

Prima di implementare i nodi di Windows, tieni conto delle seguenti considerazioni.

Considerazioni

• Puoi utilizzare la rete host sui nodi Windows utilizzando i Pod HostProcess . Per ulteriori informazioni, consulta Creazione di HostProcessPod per Windows nella documentazione di Kubernetes.

• EKSI cluster Amazon devono contenere uno Linux o più nodi Fargate per eseguire il Pods sistema principale che funziona solo Linux su, ad esempio. CoreDNS

• I log degli eventi kubelet e kube-proxy vengono reindirizzati al log degli eventi EKS Windows e sono impostati su un limite di 200 MB.

• Non puoi utilizzare Assegnazione dei gruppi di sicurezza ai singoli pods con Pods in esecuzione sui nodi Windows.

• Non puoi utilizzare una rete personalizzata con i nodi Windows.

• Non puoi utilizzare IPv6 con nodi di Windows.

• I nodi di Windows supportano un'interfaccia di rete elastica per nodo. Per impostazione predefinita, il numero di Pods che puoi eseguire per ogni nodo di Windows è uguale al numero di indirizzi IP meno uno disponibili per ogni interfaccia di rete elastica relativa al tipo di istanza del nodo. Per ulteriori informazioni, consulta Indirizzi IP per interfaccia di rete per tipo di istanza nella Amazon EC2 User Guide.

• In un EKS cluster Amazon, un singolo servizio con bilanciamento del carico può supportare fino a 1024 back-end. Pods Ogni Pod ha il proprio indirizzo IP univoco. Il limite precedente di 64 Pods non è più valido, dopo un aggiornamento di Windows Server a partire dalla Build del sistema operativo 17763.2746.

• I contenitori Windows non sono supportati per Amazon EKS Pods on Fargate.

• Non è possibile recuperare i log dal pod vpc-resource-controller. In precedenza era possibile quando si implementava il controller sul piano dati.

• Esiste un periodo di raffreddamento prima che un indirizzo IPv4 venga assegnato a un nuovo pod. In questo modo, si impedisce che il traffico vada verso un pod precedente con lo stesso indirizzo IPv4 a causa della mancata validità delle regole kube-proxy.

• L'origine per il controller è gestita su GitHub. Per contribuire o segnalare problemi relativi al controller, consulta il progetto su GitHub.

• Quando specifichi un AMI ID personalizzato per i gruppi di nodi Windows gestiti, aggiungilo eks:kube-proxy-windows alla mappa di configurazione di AWS IAM Authenticator. Per ulteriori informazioni, consulta Limiti e condizioni quando si specifica un ID AMI.

• Se la conservazione IPv4 degli indirizzi disponibili è fondamentale per la sottorete, consultate la Guida alle EKS migliori pratiche - Gestione degli indirizzi IP di rete di Windows per ottenere indicazioni.

Prerequisiti

• Un cluster esistente. Il cluster deve eseguire una delle versioni Kubernetes e della piattaforma elencate nella tabella seguente. Sono supportate anche tutte le versioni Kubernetes e della piattaforma successive a quelle elencate.

  Versione Kubernetes	Versione della piattaforma
  1.30	eks.2
  1,29	eks.1
  1,28	eks.1
  1,27	eks.1
  1,26	eks.1
  1,25	eks.1
  1,24	eks.2

• Il tuo cluster deve avere almeno un nodo Linux (ne consigliamo almeno due) o un Pod Fargate per eseguire CoreDNS. Se abiliti il supporto Windows legacy, devi utilizzare un nodo Linux (non è possibile utilizzare un Pod Fargate) per eseguire CoreDNS.

• Un EKSIAMRuolo del cluster Amazon esistente.

Abilita Windows il supporto

Abilitazione del supporto Windows per il cluster

1. Se non disponi di nodi Amazon Linux nel cluster e utilizzi gruppi di sicurezza per i Pods, vai al passaggio successivo. Altrimenti, conferma che la policy gestita di AmazonEKSVPCResourceController è collegata al tuo ruolo del cluster. Sostituisci eksClusterRole con il nome del ruolo del cluster.

   aws iam list-attached-role-policies --role-name eksClusterRole
   

   Di seguito viene riportato un output di esempio:

   {
       "AttachedPolicies": [
           {
               "PolicyName": "AmazonEKSClusterPolicy",
               "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
           },
           {
               "PolicyName": "AmazonEKSVPCResourceController",
               "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
           }
       ]
   }

   Se la policy è collegata, come nell'output precedente, salta il passaggio successivo.

2. Allega la politica gestita da A mazonEKSVPCResource Controller al tuoEKSIAMRuolo del cluster Amazon. Sostituisci eksClusterRole con il nome del ruolo del cluster.

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

3. Crea un file denominato vpc-resource-controller-configmap.yaml con i seguenti contenuti.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: amazon-vpc-cni
     namespace: kube-system
   data:
     enable-windows-ipam: "true"

4. Applica la ConfigMap al cluster.

   kubectl apply -f vpc-resource-controller-configmap.yaml
   

5. Verifica che aws-auth ConfigMap contenga una mappatura per il ruolo di istanza del Windows nodo per includere il gruppo di eks:kube-proxy-windows RBAC autorizzazioni. Puoi eseguire la verifica eseguendo il comando seguente.

   kubectl get configmap aws-auth -n kube-system -o yaml
   

   Di seguito viene riportato un output di esempio:

   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}}
   [...]
   

   Dovresti vedere eks:kube-proxy-windows elencato nei gruppi. Se il gruppo non è specificato, devi aggiornare la ConfigMap o crearla per includere il gruppo richiesto. Per ulteriori informazioni su aws-auth ConfigMap, consulta Applica la aws-authConfigMap al cluster.

Distribuisci Windows Pods

Quando si implementano i pod nel cluster, è necessario specificare il sistema operativo utilizzato se si esegue una combinazione di tipi di nodi.

Per i Pods Linux, utilizza il seguente testo del selettore dei nodi nei manifesti.

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

Per i Pods Windows, utilizza il seguente testo del selettore dei nodi nei manifesti.

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

È possibile implementare un'applicazione di esempio per vedere i selettori dei nodi in uso.

Supporta una maggiore Pod densità sui nodi Windows

In AmazonEKS, a ognuno Pod viene assegnato un IPv4 indirizzo dal tuoVPC. Per questo motivo, il numero di Pods che è possibile distribuire su un nodo è vincolato agli indirizzi IP disponibili, anche se ci sono risorse sufficienti per eseguire più Pods sul nodo. Poiché un nodo di Windows supporta una sola interfaccia di rete elastica, per impostazione predefinita, il numero massimo di indirizzi IP disponibili su un nodo di Windows è pari a:

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

Un indirizzo IP viene utilizzato come indirizzo IP principale dell'interfaccia di rete, quindi non può essere assegnato a Pods.

Puoi abilitare una maggiore densità di Pod sui nodi di Windows abilitando la delega del prefisso IP. Questa funzionalità consente di assegnare un prefisso/28 IPv4 all'interfaccia di rete principale, anziché assegnare indirizzi IPv4 secondari. L'assegnazione di un prefisso IP aumenta il numero massimo di indirizzi IPv4 disponibili sul nodo:

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

Con questo numero di indirizzi IP disponibili di gran lunga maggiore, gli indirizzi IP disponibili non dovrebbero limitare la capacità di dimensionare il numero di Pods sui tuoi nodi. Per ulteriori informazioni, consulta Assegna più indirizzi IP ai EKS nodi Amazon con prefissi.