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.
Abilitare l’accesso a Internet in uscita per i pod
Si applica a: nodi Fargate Linux IPv4, nodi Linux con istanze Amazon EC2
Le informazioni contenute in questa sezione non sono applicabili al cluster se l’implementazione è avvenuta tramite la famiglia IPv6, in quanto gli indirizzi IPv6 non sono convertiti in rete. Per ulteriori informazioni sull'uso di IPv6 con il cluster, consulta Informazioni sugli indirizzi IPv6 per cluster, pod e servizi.
Per impostazione predefinita, a ciascun pod nel cluster viene assegnato un indirizzo IPv4 privato da un routing interdominio senza classi (CIDR) associato al VPC in cui è implementato il pod. I pod nello stesso VPC comunicano tra loro utilizzando questi indirizzi IP privati come endpoint. Quando un pod comunica a un qualsiasi indirizzo IPv4 che non è incluso in un intervallo CIDR associato al VPC, il plugin CNI di Amazon VPC (per LinuxIPv4 del pod nell’indirizzo IPv4 privato principale dell’interfaccia di rete elastica principale del nodo su cui è in esecuzione il pod, ovvero * per impostazione predefinita.
Nota
Per i nodi Windows, ci sono ulteriori dettagli da considerare. Per impostazione predefinita, il plugin CNI VPC per Windows
A causa di questo comportamento:
-
I pod possono comunicare con le risorse Internet solo se il nodo su cui sono in esecuzione dispone di un indirizzo IP pubblico o elastico a esso assegnato e si trova in una sottorete pubblica. La tabella di routing associata a una sottorete pubblica dispone di un instradamento verso un gateway Internet. Per questo motivo, ti consigliamo di implementare i nodi nelle sottoreti private, quando possibile.
-
Per le versioni del plugin precedenti alla
1.8.0, le risorse che si trovano nelle reti o nei VPC collegati al VPC del cluster tramite peering VPC, VPC di transito o AWS Direct Connect non possono avviare una comunicazione con i pod oltre le interfacce di rete elastiche secondarie. I pod possono tuttavia avviare comunicazioni con tali risorse e ricevere risposte.
Se una delle seguenti affermazioni è vera nel tuo ambiente, modifica la configurazione predefinita con il comando che segue.
-
Si dispone di risorse nelle reti o nei VPC collegati al VPC del cluster tramite peering VPC, VPC di transito o AWS Direct Connect che devono avviare la comunicazione con i pod tramite un indirizzo
IPv4, con la versione del plugin precedente alla1.8.0. -
I pod si trovano in una sottorete privata e devono comunicare in uscita a Internet. La sottorete dispone di una route a un gateway NAT.
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
Nota
Le variabili di configurazione AWS_VPC_K8S_CNI_EXTERNALSNAT e AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS di CNI non sono applicabili ai nodi Windows. La disabilitazione di SNAT non è supportata per Windows. Per quanto riguarda l’esclusione di un elenco di CIDR IPv4 da SNAT, è possibile definirla specificando il parametro ExcludedSnatCIDRs nello script di bootstrap di Windows. Per ulteriori informazioni su questo parametro, consulta la sezione Parametri di configurazione dello script di bootstrap.
Rete host
*Se la specifica di un pod contiene hostNetwork=true (il valore predefinito è false), il suo indirizzo IP non viene convertito in un indirizzo diverso. Per impostazione predefinita, questo comportamento è presente per i pod di kube-proxy e del plugin CNI di Amazon VPC per Kubernetes in esecuzione sul cluster. Per questi pod, l’indirizzo IP corrisponde a quello principale del nodo, poiché l’indirizzo IP del pod non viene convertito. Per ulteriori informazioni sull’impostazione hostNetwork dei pod, consultare PodSpec v1 core