Contribuisci a migliorare questa pagina
Per contribuire a questa guida per l’utente, seleziona il link Edit this page on GitHub che si trova nel riquadro destro di ogni pagina.
Configurazione dei prerequisiti per i nodi ibridi
Per utilizzare Amazon EKS Hybrid Nodes devi disporre di connettività privata dal tuo ambiente on-premises da/verso AWS, server bare metal o macchine virtuali con un sistema operativo supportato e devi aver configurato attivazioni ibride di IAM Roles Anywhere di AWS o Systems Manager (SSM) di AWS. Sei responsabile della gestione di questi prerequisiti durante l’intero ciclo di vita dei nodi ibridi.
-
Connettività di rete ibrida dall’ambiente on-premises da/verso AWS
-
Infrastruttura sotto forma di macchine fisiche o virtuali
-
Sistema operativo compatibile con i nodi ibridi
-
Provider di credenziali IAM on-premises configurato
Connettività di rete ibrida
La comunicazione tra il piano di controllo di Amazon EKS e i nodi ibridi viene instradata attraverso il VPC e le sottoreti trasferite durante la creazione del cluster, il che si basa sul meccanismo esistente
Per un’esperienza ottimale, ti consigliamo di disporre di una connettività di rete affidabile di almeno 100 Mbps e una latenza massima di 200 ms di andata e ritorno per la connessione dei nodi ibridi alla Regione AWS. Questa è una guida generale adatta alla maggior parte dei casi d’uso, ma non è un requisito fondamentale. I requisiti di larghezza di banda e latenza possono variare in base al numero di nodi ibridi e alle caratteristiche del carico di lavoro, come la dimensione dell’immagine dell’applicazione, l’elasticità dell’applicazione, le configurazioni di monitoraggio e registrazione e le dipendenze delle applicazioni dall’accesso ai dati archiviati in altri servizi AWS. Ti consigliamo di eseguire test con applicazioni e ambienti prima di passare all’implementazione per verificare che la configurazione di rete soddisfi i requisiti per i carichi di lavoro.
Configurazione di reti on-premises
Devi abilitare l’accesso alla rete in entrata dal piano di controllo di Amazon EKS all’ambiente on-premises per consentire al piano di controllo di Amazon EKS di comunicare con il kubelet in esecuzione sui nodi ibridi e, facoltativamente, con i webhook in esecuzione sui nodi ibridi. Inoltre, devi abilitare l’accesso alla rete in uscita per i nodi ibridi e i componenti in esecuzione su di essi per comunicare con il piano di controllo di Amazon EKS. Puoi configurare questa comunicazione in modo che rimanga completamente privata con Direct Connect di AWS, VPN sito-sito di AWS o con la tua connessione VPN.
Gli intervalli di Routing interdominio senza classi (CIDR) utilizzati per le reti di nodi e pod on-premises devono utilizzare intervalli di indirizzi IPv4 RFC-1918. Il router on-premises deve essere configurato con percorsi verso i nodi locali e, facoltativamente, verso i pod. Consulta Configurazione di rete on-premises per ulteriori informazioni sui requisiti di rete on-premises, incluso l’elenco completo delle porte e dei protocolli richiesti che devono essere abilitati nel firewall e nell’ambiente on-premises.
Configurazione del cluster EKS
Per ridurre al minimo la latenza, ti consigliamo di creare il cluster Amazon EKS nella Regione AWS più vicina all’ambiente on-premises o edge. I CIDR dei nodi e dei pod on-premises vengono trasmessi durante la creazione di cluster Amazon EKS tramite due campi API: RemoteNodeNetwork e RemotePodNetwork. Potrebbe essere necessario consultare il team di rete on-premises per individuare i CIDR dei nodi e dei pod on-premises. Il CIDR dei nodi viene allocato dalla rete on-premises e il CIDR dei pod viene allocato dalla Container Network Interface (CNI) che utilizzi se utilizzi una rete overlay per la tua CNI. Cilium e Calico utilizzano reti overlay per impostazione predefinita.
I CIDR dei nodi e dei pod on-premises che configuri tramite i campi RemoteNodeNetwork e RemotePodNetwork vengono utilizzati per configurare il piano di controllo di Amazon EKS per indirizzare il traffico attraverso il tuo VPC verso il kubelet e i pod in esecuzione sui tuoi nodi ibridi. I CIDR dei nodi e dei pod on-premises non possono sovrapporsi tra loro, con il CIDR del VPC che trasferisci durante la creazione del cluster o con la configurazione IPv4 del servizio per il tuo cluster Amazon EKS. Inoltre, i CIDR dei pod devono essere unici per ogni cluster EKS in modo che il router on-premises possa instradare il traffico.
Ti consigliamo di utilizzare l’accesso agli endpoint pubblico o privato per l’endpoint del server API Amazon EKS Kubernetes. Se scegli “Pubblico e privato”, l’endpoint del server API Amazon EKS Kubernetes si risolverà sempre negli IP pubblici per i nodi ibridi in esecuzione all’esterno del tuo VPC, il che può impedire ai nodi ibridi di unirsi al cluster. Quando utilizzi l’accesso pubblico agli endpoint, l’endpoint del server dell’API Kubernetes viene risolto in IP pubblici e la comunicazione dai nodi ibridi al piano di controllo di Amazon EKS verrà instradata su Internet. Quando scegli l’accesso privato agli endpoint, l’endpoint del server dell’API Kubernetes viene risolto in IP privati e la comunicazione dai nodi ibridi al piano di controllo di Amazon EKS verrà instradata tramite il tuo collegamento di connettività privato, nella maggior parte dei casi Direct Connect di AWS o VPN sito-sito di AWS.
Configurazione VPC
Devi configurare il VPC che trasferisci durante la creazione del cluster Amazon EKS con i percorsi nella tabella di routing per il nodo on-premises e, facoltativamente, le reti pod con il gateway privato virtuale (VGW) o il gateway di transito (TGW) come destinazione. Di seguito è riportato un esempio. Sostituisci REMOTE_NODE_CIDR e REMOTE_POD_CIDR con i valori per la tua rete on-premises.
| Destinazione | Target | Descrizione |
|---|---|---|
|
10.226.0.0/16 |
local |
Percorsi del traffico locale verso il VPC all’interno del VPC |
|
REMOTE_NODE_CIDR |
tgw-abcdef123456 |
CIDR nodo on-premises, indirizza il traffico verso il TGW |
|
REMODE_POD_CIDR |
tgw-abcdef123456 |
CIDR pod on-premises, indirizza il traffico verso il TGW |
Configurazione del gruppo di sicurezza
Quando crei un cluster, Amazon EKS crea un gruppo di sicurezza denominato eks-cluster-sg-<cluster-name>-<uniqueID>. Non puoi modificare le regole in entrata di questo gruppo di sicurezza del cluster, ma puoi limitare le regole in uscita. Devi aggiungere un gruppo di sicurezza aggiuntivo al cluster per abilitare il kubelet e, facoltativamente, i webhook in esecuzione sui nodi ibridi per contattare il piano di controllo di Amazon EKS. Le regole in entrata richieste per questo gruppo di sicurezza aggiuntivo sono riportate di seguito. Sostituisci REMOTE_NODE_CIDR e REMOTE_POD_CIDR con i valori per la tua rete on-premises.
| Nome | ID regola del gruppo di sicurezza | Versione IP | Tipo | Protocollo | Intervallo porte | Origine |
|---|---|---|---|---|---|---|
|
Nodo on-premises in entrata |
sgr-abcdef123456 |
IPv4 |
HTTPS |
TCP |
443 |
REMOTE_NODE_CIDR |
|
Pod on-premises in entrata |
sgr-abcdef654321 |
IPv4 |
HTTPS |
TCP |
443 |
REMOTE_POD_CIDR |
Infrastruttura
Devi disporre di server bare metal o macchine virtuali da utilizzare come nodi ibridi. I nodi ibridi sono indipendenti dall’infrastruttura sottostante e supportano le architetture x86 e ARM. Amazon EKS Hybrid Nodes segue un approccio “a infrastruttura personalizzata”, in cui sei responsabile del provisioning e della gestione dei server bare metal o delle macchine virtuali che usi per i nodi ibridi. Sebbene non sia previsto un requisito minimo rigoroso di risorse, ti consigliamo di utilizzare host con almeno 1 vCPU e 1 GB di RAM per i nodi ibridi.
Sistema operativo
Bottlerocket, Amazon Linux 2023 (AL2023), Ubuntu e RHEL vengono convalidati su base continuativa per l’uso come sistema operativo di nodi per nodi ibridi. Bottlerocket è supportato da AWS solo in ambienti VMware vSphere. AL2023 non è coperto dai piani di supporto di AWS se eseguito al di fuori di Amazon EC2. AL2023 può essere utilizzato solo in ambienti virtualizzati on-premises, consulta Amazon Linux 2023 User Guide per ulteriori informazioni. AWS supporta l’integrazione dei nodi ibridi con i sistemi operativi Ubuntu e RHEL ma non fornisce supporto per il sistema operativo stesso.
Il provisioning e la gestione del sistema operativo sono una tua responsabilità. Quando testi i nodi ibridi per la prima volta, è più semplice eseguire la CLI Amazon EKS Hybrid Nodes (nodeadm) su un host già fornito. Per le implementazioni di produzione, ti consigliamo di includere nodeadm nelle immagini “gold” del tuo sistema operativo configurato per l’esecuzione come servizio systemd per unire automaticamente gli host ai cluster Amazon EKS all’avvio dell’host.
Provider di credenziali IAM on-premises
Amazon EKS Hybrid Nodes utilizza credenziali IAM temporanee fornite da attivazioni ibride SSM di AWS o IAM Roles Anywhere di AWS per l’autenticazione con il cluster Amazon EKS. Devi utilizzare attivazioni ibride SSM AWS o IAM Roles Anywhere di AWS con la CLI Amazon EKS Hybrid Nodes (nodeadm). Ti consigliamo di utilizzare le attivazioni ibride SSM AWS se non disponi di un’infrastruttura a chiave pubblica (PKI) esistente con un’autorità di certificazione (CA) e certificati per i tuoi ambienti on-premises. Se disponi di PKI e certificati esistenti on-premises, utilizza IAM Roles Anywhere di AWS.
Analogamente a Ruolo IAM del nodo Amazon EKS per i nodi in esecuzione su Amazon EC2, creerai un ruolo IAM Hybrid Nodes con le autorizzazioni necessarie per unire nodi ibridi ai cluster Amazon EKS. Se utilizzi IAM Roles Anywhere di AWS, configura una policy di fiducia che consenta a IAM Roles Anywhere di AWS di assumere il ruolo IAM di Hybrid Nodes e configura il tuo profilo IAM Roles Anywhere di AWS con il ruolo IAM di Hybrid Nodes come ruolo assumibile. Se utilizzi SSM di AWS, configura una policy di fiducia che consenta a SSM di AWS di assumere il ruolo IAM di Hybrid Nodes e creare l’attivazione ibrida con il ruolo IAM di Hybrid Nodes. Consulta Preparazione delle credenziali per i nodi ibridi su come creare il ruolo IAM di Hybrid Nodes con le autorizzazioni richieste.