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 Hyper-V virtuale (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 IPv4 disponibili. È possibile calcolare l'indirizzo IPv4 disponibile sul nodo nel modo seguente:

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: hcn CreateLoadBalancer 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 nelle AMI ottimizzate per Windows Server SAC EKS. Per le AMI ottimizzate per Windows Server 2019 LTSC EKS, sarà necessario abilitarle durante il provisioning dell'istanza utilizzando lo script seguente e utilizzando Windows Server 2019 Full o Core come famiglia AMI in 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 gli indirizzi IPv4 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 comunque utilizzare la delega dei prefissi, è possibile adottare misure per ottimizzare l'utilizzo degli indirizzi IPv4 nella sottorete. 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 indirizzi IPv4 e i vantaggi della delega dei prefissi in termini di densità dei pod.

Quando si utilizza l'impostazione predefinita di assegnazione di indirizzi IPv4 secondari, attualmente non esistono configurazioni supportate per manipolare il modo in cui il VPC Resource Controller richiede e alloca gli indirizzi IPv4. Più specificamente, sono supportate solo per la modalità di delega dei prefissiminimum-ip-target. warm-ip-target Tieni inoltre presente che in modalità IP secondaria, a seconda degli indirizzi IP disponibili sull'interfaccia, il VPC Resource Controller in genere alloca 3 indirizzi IPv4 inutilizzati sul nodo per tuo conto per mantenere IP caldi e tempi di avvio dei pod più rapidi. Se desideri ridurre al minimo lo spreco IP di indirizzi IP caldi non utilizzati, potresti mirare a pianificare più pod su un determinato nodo Windows in modo da utilizzare la massima capacità di indirizzi IP dell'ENI. Più esplicitamente, potresti evitare di avere IP caldi e inutilizzati se tutti gli indirizzi IP sull'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 IPv6 non è supportato sui nodi Windows.

Opzioni CNI (Container Network Interface)

L'AWSVPC CNI è il plug-in CNI de facto per i nodi di lavoro Windows e Linux. Sebbene AWSVPC CNI soddisfi le esigenze di molti clienti, potrebbero esserci momenti in cui è 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.