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

Rete Windows

Panoramica di Windows Container Networking

I contenitori Windows sono fondamentalmente diversi dai contenitori Linux. I contenitori Linux utilizzano costrutti Linux come namespace, file system union e cgroups. In Windows, questi costrutti vengono astratti dai containerd dall'Host Compute Service (HCS). HCS funge da livello API che si colloca al di sopra dell'implementazione del contenitore su Windows. I contenitori Windows sfruttano anche l'Host Network Service (HNS) che definisce la topologia di rete su un nodo.

Dal punto di vista della rete, HCS e HNS fanno funzionare i contenitori Windows come macchine virtuali. Ad esempio, ogni contenitore dispone di un adattatore di rete virtuale (vNIC) collegato a uno switch virtuale Hyper-V (vSwitch) come mostrato nel diagramma precedente.

Gestione degli indirizzi IP

Un nodo in Amazon EKS utilizza la sua Elastic Network Interface (ENI) per connettersi a una rete AWS VPC. Attualmente, è supportato un solo ENI per nodo di lavoro Windows. La gestione degli indirizzi IP per i nodi Windows viene eseguita da VPC Resource Controller che viene eseguito nel piano di controllo. Ulteriori dettagli sul flusso di lavoro per la gestione degli indirizzi IP dei nodi Windows sono disponibili qui.

Il numero di pod che un nodo di lavoro di Windows può supportare dipende dalla dimensione del nodo e dal numero di indirizzi disponibili IPv4 . È possibile calcolare l' IPv4 indirizzo disponibile sul nodo come segue:

Utilizzando la formula precedente, possiamo calcolare il numero massimo di pod per un nodo di lavoro Windows basato su un'istanza m5.large come segue:

Per ulteriori informazioni sul numero di indirizzi IP che un tipo di istanza può supportare, consulta Indirizzi IP per interfaccia di rete per tipo di istanza.

Un'altra considerazione fondamentale è il flusso del traffico di rete. Con Windows esiste il rischio di esaurimento delle porte sui nodi con più di 100 servizi. Quando si verifica questa condizione, i nodi inizieranno a generare errori con il seguente messaggio:

«Creazione della policy non riuscita: hcnCreateLoad Balancer non riuscito in Win32: la porta specificata esiste già».

Per risolvere questo problema, utilizziamo Direct Server Return (DSR). DSR è un'implementazione della distribuzione asimmetrica del carico di rete. In altre parole, il traffico di richiesta e risposta utilizza percorsi di rete diversi. Questa funzionalità accelera la comunicazione tra i pod e riduce il rischio di esaurimento delle porte. Si consiglia pertanto di abilitare il DSR sui nodi Windows.

Il DSR è abilitato per impostazione predefinita in Windows Server SAC EKS Optimized. AMIs Per Windows Server 2019 LTSC EKS Optimized AMIs, sarà necessario abilitarlo durante il provisioning dell'istanza utilizzando lo script riportato di seguito e utilizzando Windows Server 2019 Full o Core come AMIFamily nel NodeGroup. eksctl Vedi eksctl custom AMI per ulteriori informazioni.

nodeGroups:
- name: windows-ng
  instanceType: c5.xlarge
  minSize: 1
  volumeSize: 50
  amiFamily: WindowsServer2019CoreContainer
  ssh:
    allow: false

Per utilizzare DSR in Windows Server 2019 e versioni successive, è necessario specificare i seguenti flag kube-proxy durante l'avvio dell'istanza. È possibile farlo modificando lo script userdata associato ai gruppi di nodi autogestiti Launch Template.

<powershell>
[string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS"
[string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1'
[string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName"
(Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile
& $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1
</powershell>

L'abilitazione del DSR può essere verificata seguendo le istruzioni nel blog di Microsoft Networking e in Windows Containers on AWS Lab.

Se preservare IPv4 gli indirizzi disponibili e ridurre al minimo gli sprechi è fondamentale per la sottorete, in genere si consiglia di evitare di utilizzare la modalità di delega dei prefissi, come indicato in Prefix Mode for Windows - When to avoid. Se si desidera continuare a utilizzare la delega dei prefissi, è possibile adottare misure per ottimizzare l'utilizzo degli indirizzi nella sottorete. IPv4 Vedi Configurazione dei parametri per la delega dei prefissi per istruzioni dettagliate su come ottimizzare la richiesta e il processo di allocazione degli indirizzi. IPv4 La regolazione di queste configurazioni può aiutarti a trovare un equilibrio tra la conservazione degli IPv4 indirizzi e i vantaggi della delega dei prefissi in termini di densità dei pod.

Quando si utilizza l'impostazione predefinita di assegnazione di IPv4 indirizzi secondari, attualmente non esistono configurazioni supportate per manipolare il modo in cui il VPC Resource Controller richiede e alloca gli indirizzi. IPv4 Più specificamente, warm-ip-target sono supportate solo per minimum-ip-target la modalità di delega dei prefissi. Tieni inoltre presente che in modalità IP secondaria, a seconda degli indirizzi IP disponibili sull'interfaccia, il VPC Resource Controller in genere alloca 3 IPv4 indirizzi inutilizzati sul nodo per tuo conto per mantenerlo caldo IPs per tempi di avvio più rapidi dei pod. Se desideri ridurre al minimo lo spreco di indirizzi IP non utilizzati, potresti pianificare più pod su un determinato nodo Windows in modo da utilizzare quanta più capacità possibile di indirizzi IP dell'ENI. Più esplicitamente, è possibile evitare che non vengano utilizzati a caldo IPs se tutti gli indirizzi IP dell'ENI sono già utilizzati dal nodo e dai pod in esecuzione. Un'altra soluzione alternativa per aiutarti a risolvere i vincoli relativi alla disponibilità degli indirizzi IP nelle tue sottoreti potrebbe essere quella di aumentare le dimensioni della sottorete o separare i nodi Windows nelle rispettive sottoreti dedicate.

Inoltre, è importante notare che al momento non IPv6 è supportato sui nodi Windows.

Opzioni CNI (Container Network Interface)

Il AWSVPC CNI è il plugin CNI de facto per i nodi di lavoro Windows e Linux. Sebbene il AWSVPC CNI soddisfi le esigenze di molti clienti, a volte è necessario prendere in considerazione alternative come una rete overlay per evitare l'esaurimento dell'IP. In questi casi, il CNI Calico può essere utilizzato al posto del CNI. AWSVPC Project Calico è un software open source sviluppato da Tigera. Tale software include un CNI che funziona con EKS. Le istruzioni per l'installazione di Calico CNI in EKS sono disponibili nella pagina di installazione di Project Calico EKS.

Politiche di rete

È considerata una buona pratica passare dalla modalità predefinita di comunicazione aperta tra i pod del cluster Kubernetes alla limitazione dell'accesso in base alle policy di rete. L'open source Project Calico offre un forte supporto per le policy di rete che funzionano con i nodi Linux e Windows. Questa funzionalità è separata e non dipende dall'uso del CNI di Calico. Consigliamo quindi di installare Calico e di utilizzarlo per la gestione delle politiche di rete.

Le istruzioni per l'installazione di Calico in EKS sono disponibili nella pagina Installazione di Calico su Amazon EKS.

Inoltre, i consigli forniti nella sezione Amazon EKS Best Practices Guide for Security - Network si applicano anche ai cluster EKS con nodi di lavoro Windows, tuttavia alcune funzionalità come «Security Groups for Pods» non sono supportate da Windows al momento.