Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Abilitazione del supporto di Windows per il cluster Amazon 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 diHostProcess
Pod per Windowsnella documentazione di Kubernetes. -
I cluster Amazon EKS devono contenere uno o più nodi Linux o Fargate per eseguire i Pods del sistema core che funzionano solo su Linux, come CoreDNS.
-
I log degli eventi
kubelet
ekube-proxy
vengono reindirizzati al log degli eventiEKS
Windows e sono impostati su un limite di 200 MB. -
Non puoi utilizzare Gruppi di sicurezza per 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, consultare la sezione relativa agli Indirizzi IP per interfaccia di rete per tipo di istanza nella Guida per l'utente di Amazon EC2 per le istanze Windows.
-
In un cluster Amazon EKS, un singolo servizio con un load balancer può supportare fino a 1024 Pods di back-end. 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 container Windows non sono supportati per i Pods Amazon EKS su 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 indirizzoIPv4
a causa della mancata validità delle regolekube-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 ID AMI 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.
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. Se la versione del cluster o della piattaforma è precedente a una delle seguenti versioni, dovrai abilitare il supporto Windows legacy sul piano dati del cluster. Una volta che il cluster si trova in una delle seguenti versioni Kubernetes e della piattaforma o versioni successive, puoi rimuovere il supporto Windows legacy e abilitare il supporto Windows sul piano di controllo.
Versione Kubernetes Versione della piattaforma 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 Ruolo IAM del cluster Amazon EKS esistente.
Abilitazione del supporto Windows
Se la versione del cluster non corrisponde a una delle versioni o versioni successive della piattaforma e di Kubernetes elencate in Prerequisiti, devi abilitare invece il supporto Windows legacy. Per ulteriori informazioni, consulta Abilitazione del supporto Windows legacy.
Se non hai mai abilitato il supporto Windows sul cluster, vai al passaggio successivo.
Se hai abilitato il supporto Windows su un cluster precedente a una versione Kubernetes o della piattaforma elencata nei Prerequisiti, per prima cosa rimuovi vpc-resource-controller e vpc-admission-webhook dal tuo piano dati. Sono obsoleti e non sono più necessari.
Abilitazione del supporto Windows per il cluster
-
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
con il nome del ruolo del cluster.eksClusterRole
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.
-
Allega la politica gestita da AmazonekSVPC ResourceController al tuo. Ruolo IAM del cluster Amazon EKS Sostituisci
con il nome del ruolo del cluster.eksClusterRole
aws iam attach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Crea un file denominato
con i seguenti contenuti.vpc-resource-controller-configmap.yaml
apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-windows-ipam: "true"
-
Applica la
ConfigMap
al cluster.kubectl apply -f
vpc-resource-controller-configmap.yaml
-
Verifica che
aws-auth
ConfigMap
contenga una mappatura per il ruolo di istanza del nodo Windows per includere il gruppo di autorizzazionieks:kube-proxy-windows
RBAC. 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 laConfigMap
o crearla per includere il gruppo richiesto. Per ulteriori informazioni suaws-auth
ConfigMap
, consulta Applica la aws-authConfigMap al cluster.
Rimozione del supporto Windows legacy dal piano dati
Se hai abilitato il supporto Windows su un cluster precedente a una versione Kubernetes o della piattaforma elencata nei Prerequisiti, per prima cosa rimuovi vpc-resource-controller
e vpc-admission-webhook
dal tuo piano dati. Sono obsoleti e non più necessari in quanto la funzionalità fornita è ora abilitata sul piano di controllo.
-
Disinstallare il
vpc-resource-controller
con il seguente comando. Utilizza questo comando indipendentemente dallo strumento con cui è stato originariamente installato. Sostituisci
(solo l'istanza del testo doporegion-code
/manifests/
) con la Regione AWS in cui si trova il cluster.kubectl delete -f https://s3.us-west-2.amazonaws.com/amazon-eks/manifests/
region-code
/vpc-resource-controller/latest/vpc-resource-controller.yaml -
Disinstalla il
vpc-admission-webhook
seguendo le istruzioni dello strumento con cui è stato installato. -
Abilita il supporto Windows per il tuo cluster sul piano di controllo.
Disabilitazione del supporto Windows
Disabilitazione del supporto Windows sul cluster
-
Se il cluster contiene nodi Amazon Linux e utilizzi gruppi di sicurezza per pod Pods, salta questo passaggio.
Rimuovi la policy IAM gestita
AmazonVPCResourceController
dal ruolo del cluster. Sostituisci
con il nome del ruolo del tuo cluster eeksClusterRole
con il tuo ID account.111122223333
aws iam detach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Disabilita Windows IPAM in.
amazon-vpc-cni
ConfigMapkubectl patch configmap/amazon-vpc-cni \ -n kube-system \ --type merge \ -p '{"data":{"enable-windows-ipam":"false"}}'
Implementazione di pod
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.
Abilitazione del supporto Windows legacy
Se il cluster non corrisponde a una delle versioni Kubernetes e della piattaforma elencate nei Prerequisiti o a una versione successiva, consigliamo di abilitare il supporto Windows sul piano di controllo. Per ulteriori informazioni, consulta Abilitazione del supporto Windows.
I passaggi seguenti consentono di abilitare il supporto Windows legacy per il piano dati del cluster Amazon EKS se la versione del cluster o della piattaforma è precedente alle versioni elencate nei Prerequisiti. Una volta che la versione del cluster e della piattaforma corrispondono a una versione elencata nei Prerequisiti o a una versione successiva, ti consigliamo di rimuovere il supporto Windows legacy e di abilitarlo per il tuo piano di controllo.
Puoi utilizzare eksctl
, un client Windows o un client macOS o Linux per abilitare il supporto Windows legacy per il cluster.
Rinnovo del certificato webhook di ammissione VPC
Il certificato utilizzato dal webhook di ammissione VPC scade un anno dopo il rilascio. Per evitare tempi di inattività, è importante rinnovare il certificato prima della scadenza. È possibile verificare la data di scadenza del certificato corrente con il seguente comando.
kubectl get secret \ -n kube-system \ vpc-admission-webhook-certs -o json | \ jq -r '.data."cert.pem"' | \ base64 -decode | \ openssl x509 \ -noout \ -enddate | \ cut -d= -f2
Di seguito viene riportato un output di esempio:
May 28 14:23:00 2022 GMT
Puoi rinnovare il certificato utilizzando eksctl
o un computer Windows o un Linux/macOS. Seguire le istruzioni per lo strumento utilizzato originariamente per installare il webhook di ammissione VPC. Ad esempio, se in origine è stato installato il webhook di ammissione VPC utilizzando eksctl
, è necessario rinnovare il certificato utilizzando le istruzioni riportate nella scheda eksctl
.
Supporto di maggiore densità di Pod sui nodi di Windows
Su Amazon EKS a ciascun Pod viene assegnato un indirizzo IPv4
dal tuo VPC. 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 Aumentare la quantità di indirizzi IP disponibili per i nodi Amazon EC2.