Configurazione di rete locale AWS Configurazione di VPC e sottorete Configurazione del gruppo di sicurezza del cluster

Aiutaci a migliorare questa pagina

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

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

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

Preparare la rete per i nodi ibridi

Questo argomento fornisce una panoramica della configurazione di rete che devi aver configurato prima di creare il cluster Amazon EKS e collegare nodi ibridi. Questa guida presuppone che tu abbia soddisfatto i requisiti preliminari per la connettività di rete ibrida utilizzando AWS Site-to-Site VPN, AWS Direct Connect o la tua soluzione VPN.

Configurazione di rete locale

Requisiti minimi di rete

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 che si adatta alla maggior parte dei casi d'uso, ma non è un requisito rigoroso. 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 Si consiglia di eseguire test con le proprie applicazioni e ambienti prima di passare alla produzione per verificare che la configurazione di rete soddisfi i requisiti per i carichi di lavoro.

Nodo e pod locali CIDRs

Identifica il nodo e il pod CIDRs che utilizzerai per i tuoi nodi ibridi e i carichi di lavoro in esecuzione su di essi. Il nodo CIDR viene allocato dalla rete locale e il pod CIDR viene allocato dalla Container Network Interface (CNI) se si utilizza una rete overlay per il CNI. Il nodo CIDRs e il pod locali vengono passati CIDRs come input quando si crea il cluster EKS con i campi and. RemoteNodeNetwork RemotePodNetwork Il nodo locale CIDRs deve essere instradabile sulla rete locale. Vedi la sezione seguente per informazioni sulla routabilità CIDR del pod locale.

I blocchi CIDR del nodo e del pod locali devono soddisfare i seguenti requisiti:

Rientrare in uno dei seguenti intervalli IPv4 RFC-1918:,, o. 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
Non si sovrappongono tra loro, il CIDR VPC per il tuo cluster EKS o il tuo servizio Kubernetes CIDR. IPv4

Routing di rete pod in locale

Quando si utilizzano i nodi ibridi EKS, in genere si consiglia di rendere il pod locale CIDRs instradabile sulla rete locale per consentire la comunicazione e la funzionalità complete del cluster tra ambienti cloud e locali.

Reti di pod routabili

Se riesci a rendere la tua rete di pod instradabile sulla tua rete locale, segui le istruzioni riportate di seguito.

Configura il RemotePodNetwork campo per il cluster EKS con il pod CIDR locale, le tabelle di routing VPC con il pod CIDR locale e il gruppo di sicurezza del cluster EKS con il pod CIDR locale.
Esistono diverse tecniche che puoi utilizzare per rendere il tuo pod CIDR locale instradabile sulla tua rete locale, tra cui Border Gateway Protocol (BGP), route statiche o altre soluzioni di routing personalizzate. BGP è la soluzione consigliata in quanto è più scalabile e facile da gestire rispetto alle soluzioni alternative che richiedono una configurazione del percorso personalizzata o manuale. AWS supporta le funzionalità BGP di Cilium e Calico per il pod CIDRs pubblicitario, vedi e per ulteriori informazioni. Configurare un CNI per nodi ibridi Pod remoto indirizzabile CIDRs
I webhook possono essere eseguiti su nodi ibridi poiché il piano di controllo EKS è in grado di comunicare con gli indirizzi IP dei Pod assegnati ai webhook.
I carichi di lavoro in esecuzione su nodi cloud sono in grado di comunicare direttamente con i carichi di lavoro in esecuzione su nodi ibridi nello stesso cluster EKS.
Altri AWS servizi, come AWS Application Load Balancers e Amazon Managed Service for Prometheus, sono in grado di comunicare con i carichi di lavoro in esecuzione su nodi ibridi per bilanciare il traffico di rete e le metriche dei pod.

Reti pod non routabili

Se non riesci a rendere instradabili le tue reti di pod sulla tua rete locale, segui le istruzioni riportate di seguito.

I webhook non possono essere eseguiti su nodi ibridi perché richiedono la connettività dal piano di controllo EKS agli indirizzi IP dei Pod assegnati ai webhook. In questo caso, ti consigliamo di eseguire webhook su nodi cloud nello stesso cluster EKS dei nodi ibridi, vedi per ulteriori informazioni. Configurare webhook per nodi ibridi
I carichi di lavoro in esecuzione sui nodi cloud non sono in grado di comunicare direttamente con i carichi di lavoro in esecuzione su nodi ibridi quando si utilizza VPC CNI per i nodi cloud e Cilium o Calico per i nodi ibridi.
Utilizza Service Traffic Distribution per mantenere il traffico locale rispetto alla zona da cui proviene. Per ulteriori informazioni su Service Traffic Distribution, vedereConfigura la distribuzione del traffico di servizio.
Configura il CNI per utilizzare la mascheratura in uscita o la traduzione degli indirizzi di rete (NAT) per il traffico dei pod in uscita dagli host locali. Questa opzione è abilitata di default in Cilium. Calico deve essere natOutgoing impostato su. true
Altri AWS servizi, come AWS Application Load Balancers e Amazon Managed Service for Prometheus, non sono in grado di comunicare con i carichi di lavoro in esecuzione su nodi ibridi.

Accesso richiesto durante l'installazione e l'aggiornamento del nodo ibrido

È necessario avere accesso ai seguenti domini durante il processo di installazione in cui si installano le dipendenze dei nodi ibridi sui propri host. Questo processo può essere eseguito una sola volta durante la creazione delle immagini del sistema operativo oppure può essere eseguito su ciascun host in fase di esecuzione. Ciò include l'installazione iniziale e l'aggiornamento della versione Kubernetes dei nodi ibridi.

Componente	URL	Protocollo	Porta
Artefatti del nodo EKS (S3)	https://hybrid-assets.eks.amazonaws.com	HTTPS	443
Endpoint del servizio EKS	https://eks. `region`.amazonaws.com	HTTPS	443
Endpoint del servizio ECR	https://api.ecr. `region`.amazonaws.com	HTTPS	443
Endpoint EKS ECR	Vedi Visualizza i registri delle immagini dei container Amazon per i componenti aggiuntivi Amazon EKS per gli endpoint regionali.	HTTPS	443
^{Endpoint binario SSM 1}	https://amazon-ssm - `region` .s3. `region`.amazonaws.com	HTTPS	443
^{Endpoint 1 del servizio SSM}	https://ssm. `region`.amazonaws.com	HTTPS	443
^{Endpoint binario IAM Anywhere 2}	https://rolesanywhere.amazonaws.com	HTTPS	443
^{Endpoint 2 del servizio IAM Anywhere}	https://rolesanywhere. `region`.amazonaws.com	HTTPS	443

Nota

¹ L'accesso agli endpoint AWS SSM è richiesto solo se utilizzi attivazioni ibride AWS SSM per il tuo provider di credenziali IAM locale.

² L'accesso agli endpoint AWS IAM è richiesto solo se utilizzi IAM Roles Anywhere per il tuo provider di credenziali AWS IAM locale.

Accesso richiesto per le operazioni in corso del cluster

Il seguente accesso alla rete per il firewall locale è necessario per le operazioni in corso del cluster.

Importante

A seconda della scelta del CNI, è necessario configurare regole di accesso alla rete aggiuntive per le porte CNI. Consulta la documentazione di Cilium e la documentazione di Calico per i dettagli.

Tipo	Protocollo	Direzione	Porta	Origine	Destinazione	Utilizzo
HTTPS	TCP	In uscita	443	CIDR (i) del nodo remoto	^{Cluster EKS 1 IPs}	da kubelet al server API Kubernetes
HTTPS	TCP	In uscita	443	CIDR (i) Pod remoto	^{Cluster EKS 1 IPs}	Da Pod al server API Kubernetes
HTTPS	TCP	In uscita	443	CIDR (i) del nodo remoto	Endpoint del servizio SSM	Attivazioni ibride SSM, aggiornamento delle credenziali e battiti cardiaci SSM ogni 5 minuti
HTTPS	TCP	In uscita	443	CIDR del nodo remoto	Endpoint del servizio IAM Anywhere	Aggiornamento delle credenziali IAM Roles Anywhere
HTTPS	TCP	In uscita	443	CIDR (i) Pod remoto	Endpoint regionale STS	Da Pod a endpoint STS, richiesto solo per IRSA
HTTPS	TCP	In uscita	443	CIDR del nodo remoto	Endpoint del servizio di autenticazione Amazon EKS	Da nodo a endpoint di autenticazione Amazon EKS, richiesto solo per Amazon EKS Pod Identity
HTTPS	TCP	In entrata	10250	^{Cluster EKS 1 IPs}	CIDR (i) del nodo remoto	Da server API Kubernetes a kubelet
HTTPS	TCP	In entrata	Porte Webhook	^{Cluster EKS 1 IPs}	CIDR del pod remoto	Server API Kubernetes per webhook
HTTPS	TCP, UDP	In entrata, in uscita	53	CIDR del pod remoto	CIDR del pod remoto	Da Pod a CoredNS. Se esegui almeno 1 replica di CoreDNS nel cloud, devi consentire il traffico DNS al VPC su cui è in esecuzione CoredNS.
Definito dall'utente	Definito dall'utente	In entrata, in uscita	Porte per app	CIDR (i) Pod remoto	CIDR del pod remoto	Da pod a pod

Nota

¹ Il IPs cluster EKS. Consulta la sezione seguente sulle interfacce di rete elastiche di Amazon EKS.

Interfacce di rete Amazon EKS

Amazon EKS collega le interfacce di rete alle sottoreti del VPC che passi durante la creazione del cluster per abilitare la comunicazione tra il piano di controllo EKS e il tuo VPC. Le interfacce di rete create da Amazon EKS possono essere trovate dopo la creazione del cluster nella EC2 console Amazon o con l' AWS interfaccia a riga di comando. Le interfacce di rete originali vengono eliminate e vengono create nuove interfacce di rete quando vengono applicate modifiche al cluster EKS, come gli aggiornamenti delle versioni di Kubernetes. Puoi limitare l'intervallo IP per le interfacce di rete Amazon EKS utilizzando dimensioni di sottorete vincolate per le sottoreti che passate durante la creazione del cluster, il che semplifica la configurazione del firewall locale per consentire la inbound/outbound connettività a questo insieme noto e vincolato di. IPs Per controllare in quali sottoreti vengono create le interfacce di rete, è possibile limitare il numero di sottoreti specificato quando si crea un cluster oppure è possibile aggiornare le sottoreti dopo la creazione del cluster.

Le interfacce di rete fornite da Amazon EKS hanno una descrizione del formato. Amazon EKS your-cluster-name Guarda l'esempio seguente per un comando AWS CLI che puoi usare per trovare gli indirizzi IP delle interfacce di rete fornite da Amazon EKS. Sostituisci VPC_ID con l'ID del VPC passato durante la creazione del cluster.


aws ec2 describe-network-interfaces \
--query 'NetworkInterfaces[?(VpcId == VPC_ID && contains(Description,Amazon EKS))].PrivateIpAddress'

AWS Configurazione di VPC e sottorete

I requisiti esistenti di VPC e sottorete per Amazon EKS si applicano ai cluster con nodi ibridi. Inoltre, il tuo VPC CIDR non può sovrapporsi al nodo e al pod locali. CIDRs È necessario configurare i percorsi nella tabella di routing VPC per il nodo locale e, facoltativamente, il pod. CIDRs Questi percorsi devono essere configurati per indirizzare il traffico verso il gateway utilizzato per la connettività di rete ibrida, che di solito è un gateway privato virtuale (VGW) o un gateway di transito (TGW). Se utilizzi TGW o VGW per connettere il tuo VPC all'ambiente locale, devi creare un allegato TGW o VGW per il tuo VPC. Il VPC deve supportare il nome host DNS e la risoluzione DNS.

I passaggi seguenti utilizzano la AWS CLI. Puoi anche creare queste risorse in AWS Management Console o con altre interfacce come AWS CDK o AWS CloudFormation Terraform.

Fase 1: Creare un VPC

Esegui il seguente comando per creare un VPC. Sostituisci VPC_CIDR con un intervallo IPv4 CIDR RFC-1918 (privato) o non RFC-1918 (pubblico) (ad esempio). 10.0.0.0/16 Nota: la risoluzione DNS, che è un requisito EKS, è abilitata per impostazione predefinita per il VPC.
```
aws ec2 create-vpc --cidr-block VPC_CIDR
               
```
Abilita i nomi host DNS per il tuo VPC. Nota, la risoluzione DNS è abilitata per impostazione predefinita per il VPC. Sostituisci VPC_ID con l'ID del VPC creato nel passaggio precedente.
```
aws ec2 modify-vpc-attribute --vpc-id VPC_ID --enable-dns-hostnames
```

Fase 2: Creare sottoreti

Creare almeno 2 sottoreti. Amazon EKS utilizza queste sottoreti per le interfacce di rete del cluster. Per ulteriori informazioni, consulta i requisiti e le considerazioni sulle sottoreti.

È possibile trovare le zone di disponibilità per una AWS regione con il seguente comando. Sostituisci us-west-2 con la tua regione.
```
aws ec2 describe-availability-zones \
     --query 'AvailabilityZones[?(RegionName == us-west-2)].ZoneName'
```
Crea una sottorete. Sostituisci VPC_ID con l'ID del VPC. Sostituisci SUBNET_CIDR con il blocco CIDR per la tua sottorete (ad esempio 10.0.1.0/24). Sostituisci AZ con la zona di disponibilità in cui verrà creata la sottorete (ad esempio us-west-2a). Le sottoreti create devono trovarsi in almeno 2 zone di disponibilità diverse.
```
aws ec2 create-subnet \
    --vpc-id VPC_ID \
    --cidr-block SUBNET_CIDR \
    --availability-zone AZ
               
```

(Facoltativo) Fase 3: collegare il VPC con Amazon VPC Transit Gateway (TGW) o il gateway privato virtuale AWS Direct Connect (VGW)

Se utilizzi un TGW o VGW, collega il tuo VPC al TGW o VGW. Per ulteriori informazioni, consulta gli allegati Amazon VPC nelle associazioni di gateway di transito Amazon VPC o gateway privati virtuali AWS Direct Connect.

Gateway di transito

Esegui il comando seguente per collegare un Transit Gateway. Sostituisci VPC_ID con l'ID del VPC. Sostituisci SUBNET_ID1 e SUBNET_ID2 con IDs le sottoreti che hai creato nel passaggio precedente. TGW_IDSostituiscilo con l'ID del tuo TGW.


aws ec2 create-transit-gateway-vpc-attachment \
    --vpc-id VPC_ID \
    --subnet-ids SUBNET_ID1 SUBNET_ID2 \
    --transit-gateway-id TGW_ID

Gateway privato virtuale

Esegui il comando seguente per collegare un Transit Gateway. VPN_IDSostituiscilo con l'ID del tuo VGW. Sostituisci VPC_ID con l'ID del VPC.


aws ec2 attach-vpn-gateway \
    --vpn-gateway-id VPN_ID \
    --vpc-id VPC_ID

(Facoltativo) Fase 4: Creazione della tabella dei percorsi

È possibile modificare la tabella di routing principale per il VPC o creare una tabella di routing personalizzata. I passaggi seguenti creano una tabella di routing personalizzata con i percorsi verso il nodo e il pod locali. CIDRs Per ulteriori informazioni, consulta Tabelle di routing di sottorete. Sostituisci VPC_ID con l'ID del VPC.


aws ec2 create-route-table --vpc-id VPC_ID

Fase 5: Creare percorsi per nodi e pod locali

Crea percorsi nella tabella delle rotte per ciascuno dei tuoi nodi remoti locali. È possibile modificare la tabella di routing principale per il VPC o utilizzare la tabella di routing personalizzata creata nel passaggio precedente.

Gli esempi seguenti mostrano come creare percorsi per il nodo e il pod locali. CIDRs Negli esempi, viene utilizzato un gateway di transito (TGW) per connettere il VPC all'ambiente locale. Se disponi di più nodi e pod locali CIDRs, ripeti i passaggi per ogni CIDR.

Se utilizzi un gateway Internet o un gateway privato virtuale (VGW) sostituiscilo con. --transit-gateway-id --gateway-id
Sostituisci RT_ID con l'ID della tabella di routing creata nel passaggio precedente.
Sostituiscilo REMOTE_NODE_CIDR con l'intervallo CIDR che utilizzerai per i tuoi nodi ibridi.
Sostituiscilo REMOTE_POD_CIDR con l'intervallo CIDR che utilizzerai per i pod in esecuzione su nodi ibridi. L'intervallo CIDR del pod corrisponde alla configurazione Container Networking Interface (CNI), che più comunemente utilizza una rete overlay locale. Per ulteriori informazioni, consulta Configurare un CNI per nodi ibridi.
Sostituiscilo TGW_ID con l'ID del tuo TGW.

Rete a nodi remoti


aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_NODE_CIDR \
    --transit-gateway-id TGW_ID

Rete Pod remota


aws ec2 create-route \
    --route-table-id RT_ID \
    --destination-cidr-block REMOTE_POD_CIDR \
    --transit-gateway-id TGW_ID

(Facoltativo) Fase 6: Associare le sottoreti alla tabella delle rotte

Se hai creato una tabella di routing personalizzata nel passaggio precedente, associa ciascuna delle sottoreti che hai creato nel passaggio precedente alla tua tabella di routing personalizzata. Se stai modificando la tabella di routing principale del VPC, le sottoreti vengono automaticamente associate alla tabella di routing principale del VPC e puoi saltare questo passaggio.

Esegui il comando seguente per ciascuna delle sottoreti che hai creato nei passaggi precedenti. Sostituiscilo RT_ID con la tabella di routing creata nel passaggio precedente. Sostituisci SUBNET_ID con l'ID di una sottorete.


aws ec2 associate-route-table --route-table-id RT_ID --subnet-id SUBNET_ID

Configurazione del gruppo di sicurezza del cluster

Il seguente accesso per il gruppo di sicurezza del cluster EKS è necessario per le operazioni in corso del cluster.

Tipo	Protocollo	Direzione	Porta	Origine	Destinazione	Utilizzo
HTTPS	TCP	In entrata	443	CIDR (i) del nodo remoto	N/D	Server API da Kubelet a Kubernetes
HTTPS	TCP	In entrata	443	CIDR (i) Pod remoto	N/D	Pod che richiedono l'accesso al server API K8s quando il CNI non utilizza NAT per il traffico dei pod.
HTTPS	TCP	In uscita	10250	N/D	CIDR (i) del nodo remoto	Da server API Kubernetes a Kubelet
HTTPS	TCP	In uscita	Porte Webhook	N/D	CIDR del pod remoto	Da server API Kubernetes a webhook (se esegui webhook su nodi ibridi)

Per creare un gruppo di sicurezza con le regole di accesso in entrata, esegui i seguenti comandi. Questo gruppo di sicurezza deve essere passato quando crei il tuo cluster Amazon EKS. Per impostazione predefinita, il comando seguente crea un gruppo di sicurezza che consente tutti gli accessi in uscita. È possibile limitare l'accesso in uscita in modo da includere solo le regole di cui sopra. Se state pensando di limitare le regole in uscita, vi consigliamo di testare a fondo tutte le applicazioni e la connettività dei pod prima di applicare le regole modificate a un cluster di produzione.

Nel primo comando, sostituiscilo SG_NAME con un nome per il tuo gruppo di sicurezza
Nel primo comando, sostituisci VPC_ID con l'ID del VPC creato nel passaggio precedente
Nel secondo comando, SG_ID sostituiscilo con l'ID del gruppo di sicurezza creato nel primo comando
Nel secondo comando, sostituisci REMOTE_NODE_CIDR e REMOTE_POD_CIDR con i valori per i nodi ibridi e la rete locale.


aws ec2 create-security-group \
    --group-name SG_NAME \
    --description "security group for hybrid nodes" \
    --vpc-id VPC_ID


aws ec2 authorize-security-group-ingress \
    --group-id SG_ID \
    --ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "REMOTE_NODE_CIDR"}, {"CidrIp": "REMOTE_POD_CIDR"}]}]'

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Prerequisiti

Preparare il sistema operativo