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 sulle reti Windows Container
I contenitori Windows sono fondamentalmente diversi dai contenitori Linux. I contenitori Linux utilizzano costrutti Linux come namespace, Union File System e cgroups. In Windows, questi costrutti vengono estratti dai contenitori dall'Host Compute Service (HCS). https://github.com/microsoft/hcsshim
Dal punto di vista delle reti, HCS e HNS fanno funzionare i contenitori Windows come macchine virtuali. Ad esempio, ogni container 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 nodo di lavoro ENI per Windows. La gestione degli indirizzi IP per i nodi Windows viene eseguita da VPC Resource Controller
Il numero di pod che un nodo di lavoro Windows può supportare è determinato dalla dimensione del nodo e dal numero di indirizzi IPv4 disponibili. È possibile calcolare l'indirizzo IPv4 disponibile sul nodo nel modo seguente:
-
Per impostazione predefinita, all'ENI vengono assegnati solo indirizzi IPv4 secondari. In tal caso:
Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1
Ne sottraiamo uno dal conteggio totale poiché un indirizzo IPv4 verrà utilizzato come indirizzo principale dell'ENI e quindi non può essere assegnato ai Pod.
-
Se il cluster è stato configurato per un'alta densità di pod abilitando la funzione di delega dei prefissi, allora-
Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16
Qui, invece di allocare indirizzi IPv4 secondari, VPC Resource Controller li allocerà
/28 prefixese quindi il numero complessivo di indirizzi IPv4 disponibili verrà aumentato di 16 volte.
Utilizzando la formula precedente, possiamo calcolare il numero massimo di pod per un Windows worker annodato in base a un'istanza m5.large come segue:
-
Per impostazione predefinita, quando si esegue in modalità IP secondaria-
10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses
-
Quando si utilizza
prefix delegation-(10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses
Per ulteriori informazioni sul numero di indirizzi IP che può supportare un tipo di istanza, vedi 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 su nodi con più di 100 servizi. Quando si verifica questa condizione, i nodi inizieranno a generare errori con il seguente messaggio:
«Creazione della politica 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à velocizza la comunicazione tra i pod e riduce il rischio di esaurimento delle porte. Consigliamo pertanto di abilitare il DSR sui nodi Windows.
Il DSR è abilitato per impostazione predefinita nelle AMI ottimizzate SAC EKS di Windows Server. Per le AMI ottimizzate per Windows Server 2019 LTSC EKS, è necessario abilitarla durante il provisioning delle istanze utilizzando lo script riportato di seguito e utilizzando Windows Server 2019 Full o Core come AMIFamily in NodeGroup. eksctl Per
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
<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 Microsoft Networking
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 Modalità prefisso per Windows - Quando evitare. Se si desidera comunque utilizzare la delega dei prefissi, è possibile adottare misure per ottimizzare l'utilizzo degli indirizzi IPv4 nella sottorete. Per istruzioni dettagliate su come ottimizzare il processo di richiesta e allocazione degli indirizzi IPv4, consulta Configurazione dei parametri per la delega dei prefissi. La modifica 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à di pod.
Quando si utilizza l'impostazione predefinita per l'assegnazione di indirizzi IPv4 secondari, al momento non sono supportate configurazioni per manipolare il modo in cui il VPC Resource Controller richiede e alloca gli indirizzi IPv4. Più specificamente, e sono supportati 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 gli IP caldi e velocizzare i tempi di avvio del pod. Se desideri ridurre al minimo lo spreco di indirizzi IP caldi inutilizzati, potresti mirare a pianificare più pod su un determinato nodo Windows in modo da utilizzare quanta più capacità di indirizzi IP dell'ENI possibile. Più esplicitamente, è possibile 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 risolvere i vincoli relativi alla disponibilità degli indirizzi IP nelle sottoreti potrebbe essere quella di aumentare le dimensioni della sottorete o separare i nodi Windows in sottoreti dedicate.
Inoltre, è importante notare che al momento IPv6 non è supportato sui nodi Windows.
Opzioni Container Network Interface (CNI)
L'AWSVPC CNI è il plugin CNI de facto per i nodi di lavoro Windows e Linux. Sebbene l'AWSVPC CNI soddisfi le esigenze di molti clienti, a volte è necessario prendere in considerazione alternative come una rete overlay per evitare l'esaurimento degli IP. In questi casi, il CNI Calico può essere utilizzato al posto del CNI AWSVPC. Project Calico
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 politiche di rete. L'open source Project Calico
Per istruzioni sull'installazione di Calico su Amazon EKS, consulta Installazione di Calico su Amazon EKS
Inoltre, i consigli forniti nella Amazon EKS Best Practices Guide for Security - Sezione Network si applicano anche ai cluster EKS con nodi di lavoro Windows, tuttavia, alcune funzionalità come «Security Groups for Pods» non sono attualmente supportate da Windows.
