Flussi di traffico di rete per nodi ibridi - Amazon EKS
Dal kubelet del nodo ibrido al piano di controllo (control-plane) EKSDal kube-proxy del nodo ibrido al piano di controllo (control-plane) EKSDal piano di controllo (control-plane) EKS al nodo ibrido (server kubelet)I pod vengono eseguiti su nodi ibridi verso il piano di controllo (control-plane) EKSDal piano di controllo (control-plane) EKS ai pod in esecuzione su un nodo ibrido (webhook)Da pod a pod in esecuzione su nodi ibridiDa pod su nodi cloud a pod su nodi ibridi (traffico est-ovest)

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

Flussi di traffico di rete per nodi ibridi

Questa pagina descrive in dettaglio i flussi di traffico di rete per EKS Hybrid Nodes con diagrammi che mostrano i percorsi di rete end-to-end per i diversi tipi di traffico.

Sono coperti i seguenti flussi di traffico:

Dal kubelet del nodo ibrido al piano di controllo (control-plane) EKS

Dal kubelet del nodo ibrido al piano di controllo (control-plane) EKS

Richiesta

1kubelet. Avvia la richiesta

Quando il kubelet su un nodo ibrido deve comunicare con il piano di controllo (control-plane) EKS (ad esempio, per segnalare lo stato del nodo oppure ottenere le specifiche del pod), utilizza il file kubeconfig fornito durante la registrazione del nodo. Questo kubeconfig contiene l’URL dell’endpoint del server API (il nome DNS di Route53) anziché gli indirizzi IP diretti.

Il kubelet esegue una ricerca DNS per l’endpoint (ad esempio, https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.gr7.us-west-2.eks.amazonaws.com ). In un cluster ad accesso pubblico, questo si risolve in un indirizzo IP pubblico (ad esempio, 54.239.118.52) che appartiene al servizio EKS in esecuzione su AWS. Quindi, il kubelet crea una richiesta HTTPS sicura per questo endpoint. Il pacchetto iniziale appare come riportato di seguito:

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 10.80.0.2     | Src: 52390 (random) |                 |
| Dst: 54.239.118.52 | Dst: 443            |                 |
+--------------------+---------------------+-----------------+

2. Routing del router locale

Poiché l’IP di destinazione è un indirizzo IP pubblico e non fa parte della rete locale, il kubelet invia questo pacchetto al gateway predefinito (il router locale on-premises). Il router esamina l’IP di destinazione e determina che si tratta di un indirizzo IP pubblico.

Per il traffico pubblico, il router in genere inoltra il pacchetto a un gateway Internet o a un router di confine che gestisce il traffico in uscita verso internet. Questo valore è omesso nel diagramma e dipenderà da come è configurata la rete on-premises. Il pacchetto attraversa l’infrastruttura di rete on-premises e alla fine raggiunge la rete del provider di servizi internet.

3. Distribuzione al piano di controllo (control-plane) EKS

Il pacchetto viaggia attraverso la rete internet pubblica e le reti di transito fino a raggiungere la rete AWS. La rete AWS instrada il pacchetto all’endpoint del servizio EKS nella regione appropriata. Quando il pacchetto raggiunge il servizio EKS, viene inoltrato all’effettivo piano di controllo (control-plane) EKS del cluster.

Questo routing attraverso la rete internet pubblica è diverso dal percorso instradato dal VPC privato che vedremo in altri flussi di traffico. La differenza fondamentale è che quando si utilizza la modalità di accesso pubblico, il traffico dal kubelet on-premises (ma non dai pod) al piano di controllo (control-plane) EKS non passa attraverso il VPC, ma utilizza invece l’infrastruttura internet globale.

Risposta

Dopo che il piano di controllo (control-plane) EKS ha elaborato la richiesta del kubelet, invia una risposta:

3. Il piano di controllo (control-plane) EKS invia una risposta

Il piano di controllo (control-plane) EKS crea un pacchetto di risposta. Questo pacchetto ha l’IP pubblico come origine e l’IP del nodo ibrido come destinazione:

+--------------------+---------------------+-----------------+
| IP Header          | TCP Header          | Payload         |
| Src: 54.239.118.52 | Src: 443            |                 |
| Dst: 10.80.0.2     | Dst: 52390          |                 |
+--------------------+---------------------+-----------------+

2. Routing internet

Il pacchetto di risposta attraversa internet, seguendo il percorso di routing determinato dai provider di servizi internet, fino a raggiungere il router edge della rete on-premises.

1. Distribuzione locale

Il router on-premises riceve il pacchetto e riconosce l’IP di destinazione (10.80.0.2) come appartenente alla rete locale. Inoltra il pacchetto attraverso l’infrastruttura di rete locale fino a raggiungere il nodo ibrido di destinazione, dove il kubelet riceve ed elabora la risposta.

Dal kube-proxy del nodo ibrido al piano di controllo (control-plane) EKS

Se abiliti l’accesso pubblico agli endpoint per il cluster, il traffico di ritorno utilizza la rete internet pubblica. Questo traffico proviene dal kube-proxy sul nodo ibrido verso il piano di controllo (control-plane) EKS e segue lo stesso percorso del traffico dal kubelet al piano di controllo (control-plane) EKS.

Dal piano di controllo (control-plane) EKS al nodo ibrido (server kubelet)

Dal piano di controllo (control-plane) EKS al nodo ibrido

Richiesta

1. Il server API EKS Kubernetes avvia la richiesta

Il server API EKS Kubernetes recupera l’indirizzo IP del nodo (10.80.0.2) dallo stato dell’oggetto del nodo. Quindi indirizza questa richiesta tramite la sua interfaccia di rete elastica (ENI) nel VPC, poiché l’IP di destinazione appartiene al CIDR del nodo remoto configurato (10.80.0.0/16). Il pacchetto iniziale appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 67493 (random) |                 |
| Dst: 10.80.0.2  | Dst: 10250          |                 |
+-----------------+---------------------+-----------------+

2. Elaborazione di rete del VPC

Il pacchetto lascia l’ENI ed entra nel livello di rete del VPC, dove viene diretto al gateway della sottorete per un ulteriore instradamento.

3. Ricerca della tabella di routing del VPC

La tabella di routing del VPC per la sottorete contenente l’ENI del piano di controllo (control-plane) EKS ha un instradamento specifico (il secondo nel diagramma) per il CIDR del nodo remoto. In base a questa regola di routing, il pacchetto viene indirizzato al gateway dal VPC a on-premises.

4. Transito oltre il limite

Il gateway trasferisce il pacchetto oltre i limiti del cloud tramite la connessione stabilita (come Direct Connect o VPN) alla rete on-premises.

5. Ricezione nella rete on-premises

Il pacchetto arriva al router on-premises locale che gestisce il traffico per la sottorete in cui si trovano i nodi ibridi.

6. Distribuzione finale

Il router locale identifica che l’indirizzo IP (10.80.0.2) di destinazione appartiene alla sua rete connessa direttamente e inoltra il pacchetto al nodo ibrido di destinazione, dove il kubelet riceve ed elabora la richiesta.

Risposta

Dopo che il kubelet del nodo ibrido ha elaborato la richiesta, restituisce una risposta seguendo lo stesso percorso in senso inverso:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 10250          |                 |
| Dst: 10.0.0.132 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

6. kubelet Invia la risposta

Il kubelet sul nodo ibrido (10.80.0.2) crea un pacchetto di risposta con l’IP di origine originale come destinazione. La destinazione non appartiene alla rete locale, quindi viene inviata al gateway predefinito dell’host, che è il router locale.

5. Routing del router locale

Il router determina l’appartenenza a 10.0.0.0/16 dell’IP di destinazione (10.0.0.132), che dispone di un instradamento che punta al gateway a cui si connette AWS.

4. Ritorno oltre il limite

Il pacchetto torna indietro attraverso la stessa connessione on-premises al VPC (come Direct Connect o VPN), superando il limite del cloud nella direzione opposta.

3. Routing del VPC

Quando il pacchetto arriva nel VPC, le tabelle di routing identificano che l’IP di destinazione appartiene a un CIDR del VPC. L’instradamento dei pacchetti all’interno del VPC.

2. Distribuzione di rete del VPC

Il livello di rete del VPC inoltra il pacchetto alla sottorete con l’ENI del piano di controllo (control-plane) EKS (10.0.0.132).

1. Ricezione dell’ENI

Il pacchetto raggiunge l’ENI del piano di controllo (control-plane) EKS collegata al server API Kubernetes, completando il viaggio di andata e ritorno.

I pod vengono eseguiti su nodi ibridi verso il piano di controllo (control-plane) EKS

I pod vengono eseguiti su nodi ibridi verso il piano di controllo (control-plane) EKS

Senza NAT della CNI

Richiesta

In genere, i pod comunicano al server API Kubernetes tramite il servizio kubernetes. L’IP del servizio è il primo IP del servizio CIDR del cluster. Questa convenzione consente ai pod che devono essere eseguiti prima che CoreDNS sia disponibile per raggiungere il server API, ad esempio la Container Network Interface (CNI). Le richieste lasciano il pod con l’IP del servizio come destinazione. Ad esempio, se il servizio CIDR è 172.16.0.0/16, l’IP del servizio è 172.16.0.1.

1. Il pod avvia la richiesta

Il pod invia una richiesta all’IP del servizio kubernetes (172.16.0.1) sulla porta del server API (443) da una porta di origine casuale. Il pacchetto appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Elaborazione della CNI

La CNI rileva che l’IP di destinazione non appartiene a nessun CIDR del pod che gestisce. Poiché il NAT in uscita è disabilitato, la CNI passa il pacchetto allo stack di rete host senza modificarlo.

3. Elaborazione della rete del nodo

Il pacchetto entra nello stack di rete del nodo dove gli hook netfilter attivano le regole iptables impostate da kube-proxy. Diverse regole si applicano nell’ordine seguente:

  1. Il pacchetto colpisce per primo la catena KUBE-SERVICES, che contiene regole che corrispondono al ClusterIP e alla porta di ogni servizio.

  2. La regola di corrispondenza passa alla catena KUBE-SVC-XXX del servizio kubernetes (pacchetti destinati a 172.16.0.1:443), che contiene le regole di bilanciamento del carico.

  3. La regola di bilanciamento del carico seleziona casualmente una delle catene KUBE-SEP-XXX per gli IP del piano di controllo (control-plane) dell’ENI (10.0.0.132 o 10.0.1.23).

  4. La catena KUBE-SEP-XXX selezionata ha la regola effettiva che modifica l’IP di destinazione dall’IP del servizio a quello selezionato. Si chiama Destination Network Address Translation (DNAT).

Dopo aver applicato queste regole, supponendo che l’IP dell’ENI del piano di controllo (control-plane) EKS selezionato sia 10.0.0.132, il pacchetto appare come indicato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Il nodo inoltra il pacchetto al gateway predefinito perché l’IP di destinazione non si trova nella rete locale.

4. Routing del router locale

Il router locale determina che l’IP di destinazione (10.0.0.132) appartiene al CIDR del VPC (10.0.0.0/16) e lo inoltra al gateway che si connette ad AWS.

5. Transito oltre il limite

Il pacchetto viaggia attraverso la connessione stabilita (come Direct Connect o VPN) oltre il limite del cloud fino al VPC.

6. Distribuzione di rete del VPC

Il livello di rete del VPC indirizza il pacchetto alla sottorete corretta in cui si trova l’ENI del piano di controllo (control-plane) EKS (10.0.0.132).

7. Ricezione dell’ENI

Il pacchetto raggiunge l’ENI del piano di controllo (control-plane) EKS collegato al server API Kubernetes.

Risposta

Dopo che il piano di controllo (control-plane) EKS ha elaborato la richiesta, invia una risposta al pod:

7. Il server API invia una risposta

Il server API EKS Kubernetes crea un pacchetto di risposta con l’IP di origine originale come destinazione. Il pacchetto appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Poiché l’IP di destinazione appartiene al CIDR del pod remoto configurato (10.85.0.0/16), lo invia tramite la sua ENI nel VPC con il router della sottorete come hop successivo.

6. Routing del VPC

La tabella di routing del VPC contiene una voce per il CIDR del pod remoto (10.85.0.0/16), che indirizza questo traffico verso il gateway dal VPC a on-premises.

5. Transito oltre il limite

Il gateway trasferisce il pacchetto oltre i limiti del cloud tramite la connessione stabilita (come Direct Connect o VPN) alla rete on-premises.

4. Ricezione nella rete on-premises

Il pacchetto arriva al router on-premises locale.

3. Distribuzione al nodo

La tabella del router contiene una voce per 10.85.1.0/24 con 10.80.0.2 come hop successivo, che consegna il pacchetto al nostro nodo.

2. Elaborazione della rete del nodo

Poiché il pacchetto viene elaborato dallo stack di rete del nodo, conntrack (una parte di netfilter) abbina il pacchetto alla connessione inizialmente stabilita dal pod. Poiché il DNAT è stato originariamente applicato, conntrack inverte il DNAT riscrivendo l’IP di origine dall’IP dell’ENI del piano di controllo (control-plane) EKS all’IP del servizio kubernetes:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Elaborazione della CNI

La CNI identifica che l’IP di destinazione appartiene a un pod nella sua rete e consegna il pacchetto al namespace della rete del pod corretto.

Questo flusso mostra perché i CIDR dei pod remoti devono essere instradati correttamente dal VPC fino al nodo specifico che ospita ciascun pod: l’intero percorso di ritorno dipende dal corretto instradamento degli IP del pod su reti cloud e on-premises.

Con NAT della CNI

Questo flusso è molto simile a quello senza NAT della CNI, ma con una differenza fondamentale: la CNI applica il NAT di origine (SNAT) al pacchetto prima di inviarlo allo stack di rete del nodo. Ciò modifica l’IP di origine del pacchetto nell’IP del nodo, permettendo al pacchetto di essere reindirizzato al nodo senza richiedere una configurazione di routing aggiuntiva.

Richiesta

1. Il pod avvia la richiesta

Il pod invia una richiesta all’IP del servizio kubernetes (172.16.0.1) sulla porta del server API EKS Kubernetes (443) da una porta di origine casuale. Il pacchetto appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

2. Elaborazione della CNI

La CNI rileva che l’IP di destinazione non appartiene a nessun CIDR del pod che gestisce. Poiché il NAT in uscita è abilitato, la CNI applica lo SNAT al pacchetto, cambiando l’IP di origine con l’IP del nodo prima di passarlo allo stack di rete del nodo:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 172.16.0.1 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Nota: nell’esempio la CNI e iptables sono mostrati come blocchi separati per motivi di chiarezza, ma in pratica è possibile che alcune CNI utilizzino iptables per applicare il NAT.

3. Elaborazione della rete del nodo

Qui le regole iptables stabilite da kube-proxy si comportano come nell’esempio precedente, ovvero il bilanciamento del carico del pacchetto su una delle ENI del piano di controllo (control-plane) EKS. Il pacchetto ora appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.80.0.2  | Src: 67493 (random) |                 |
| Dst: 10.0.0.132 | Dst: 443            |                 |
+-----------------+---------------------+-----------------+

Il nodo inoltra il pacchetto al gateway predefinito perché l’IP di destinazione non si trova nella rete locale.

4. Routing del router locale

Il router locale determina che l’IP di destinazione (10.0.0.132) appartiene al CIDR del VPC (10.0.0.0/16) e lo inoltra al gateway che si connette ad AWS.

5. Transito oltre il limite

Il pacchetto viaggia attraverso la connessione stabilita (come Direct Connect o VPN) oltre il limite del cloud fino al VPC.

6. Distribuzione di rete del VPC

Il livello di rete del VPC indirizza il pacchetto alla sottorete corretta in cui si trova l’ENI del piano di controllo (control-plane) EKS (10.0.0.132).

7. Ricezione dell’ENI

Il pacchetto raggiunge l’ENI del piano di controllo (control-plane) EKS collegato al server API Kubernetes.

Risposta

Dopo che il piano di controllo (control-plane) EKS ha elaborato la richiesta, invia una risposta al pod:

7. Il server API invia una risposta

Il server API EKS Kubernetes crea un pacchetto di risposta con l’IP di origine originale come destinazione. Il pacchetto appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

Poiché l’IP di destinazione appartiene al CIDR del nodo remoto configurato (10.80.0.0/16), lo invia tramite la sua ENI nel VPC con il router della sottorete come hop successivo.

6. Routing del VPC

La tabella di routing del VPC contiene una voce per il CIDR del nodo remoto (10.80.0.0/16), che indirizza questo traffico verso il gateway dal VPC a on-premises.

5. Transito oltre il limite

Il gateway trasferisce il pacchetto oltre i limiti del cloud tramite la connessione stabilita (come Direct Connect o VPN) alla rete on-premises.

4. Ricezione nella rete on-premises

Il pacchetto arriva al router on-premises locale.

3. Distribuzione al nodo

Il router locale identifica che l’indirizzo IP (10.80.0.2) di destinazione appartiene alla sua rete connessa direttamente e inoltra il pacchetto al nodo ibrido di destinazione.

2. Elaborazione della rete del nodo

Poiché il pacchetto viene elaborato dallo stack di rete del nodo, conntrack (una parte di netfilter) abbina il pacchetto alla connessione stabilita inizialmente dal pod e, poiché il DNAT è stato originariamente applicato, inverte la situazione riscrivendo l’IP di origine dall’IP dell’ENI del piano di controllo (control-plane) EKS a quello del servizio kubernetes:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.80.0.2  | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

1. Elaborazione della CNI

Il CNI identifica che questo pacchetto appartiene a una connessione a cui ha precedentemente applicato lo SNAT. Inverte lo SNAT, riportando l’IP di destinazione all’IP del pod:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 172.16.0.1 | Src: 443            |                 |
| Dst: 10.85.1.56 | Dst: 67493          |                 |
+-----------------+---------------------+-----------------+

La CNI identifica che l’IP di destinazione appartiene a un pod nella sua rete e consegna il pacchetto al namespace della rete del pod corretto.

Questo flusso mostra come il NAT della CNI può semplificare la configurazione consentendo il reindirizzamento dei pacchetti al nodo senza richiedere un routing aggiuntivo per i CIDR dei pod.

Dal piano di controllo (control-plane) EKS ai pod in esecuzione su un nodo ibrido (webhook)

Dal piano di controllo (control-plane) EKS ai pod in esecuzione su un nodo ibrido

Questo schema di traffico si riscontra più comunemente con i webhook, in cui il piano di controllo (control-plane) EKS deve avviare direttamente le connessioni ai server webhook in esecuzione nei pod su nodi ibridi. Gli esempi includono la convalida e la modifica dei webhook di ammissione, che vengono chiamati dal server API durante i processi di convalida o mutazione delle risorse.

Richiesta

1. Il server API EKS Kubernetes avvia la richiesta

Quando un webhook è configurato nel cluster e un’operazione API pertinente lo attiva, il server API EKS Kubernetes deve stabilire una connessione diretta al pod del server webhook. Il server API cerca innanzitutto l’indirizzo IP del pod dalla risorsa Service o Endpoint associata al webhook.

Supponendo che il pod del webhook sia in esecuzione su un nodo ibrido con IP 10.85.1.23, il server API EKS Kubernetes crea una richiesta HTTPS all’endpoint del webhook. Il pacchetto iniziale viene inviato tramite l’ENI del piano di controllo (control-plane) EKS nel VPC perché l’IP di destinazione 10.85.1.23 appartiene al CIDR del pod remoto configurato (10.85.0.0/16). Il pacchetto appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.132 | Src: 41892 (random) |                 |
| Dst: 10.85.1.23 | Dst: 8443           |                 |
+-----------------+---------------------+-----------------+

2. Elaborazione di rete del VPC

Il pacchetto lascia l’ENI del piano di controllo (control-plane) EKS ed entra nel livello di rete del VPC con il router della sottorete come hop successivo.

3. Ricerca della tabella di routing del VPC

La tabella di routing del VPC per la sottorete contenente l’ENI del piano di controllo (control-plane) EKS contiene un instradamento specifico per il CIDR del pod remoto (10.85.0.0/16). Questa regola di routing indirizza il pacchetto verso il gateway dal VPC a on-premises (ad esempio, un gateway privato virtuale per Direct Connect o connessioni VPN):

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

4. Transito oltre il limite

Il gateway trasferisce il pacchetto oltre i limiti del cloud tramite la connessione stabilita (come Direct Connect o VPN) alla rete on-premises. Il pacchetto mantiene gli indirizzi IP di origine e destinazione originali mentre attraversa questa connessione.

5. Ricezione nella rete on-premises

Il pacchetto arriva al router on-premises locale. Il router consulta la propria tabella di routing per determinare come raggiungere l’indirizzo 10.85.1.23. Perché ciò funzioni, la rete on-premises deve disporre di percorsi per i CIDR dei pod che indirizzano il traffico verso il nodo ibrido appropriato.

In questo caso, la tabella di routing del router contiene una voce che indica che la sottorete 10.85.1.0/24 è raggiungibile tramite il nodo ibrido con IP 10.80.0.2:

Destination     Next Hop
10.85.1.0/24    10.80.0.2

6. Distribuzione al nodo

In base alla voce della tabella di routing, il router inoltra il pacchetto al nodo ibrido (10.80.0.2). Quando il pacchetto arriva al nodo, ha lo stesso aspetto di quando il server API EKS Kubernetes lo ha inviato, con l’IP di destinazione che è ancora l’IP del pod.

7. Elaborazione della CNI

Lo stack di rete del nodo riceve il pacchetto e, dato che l’IP di destinazione non è quello del nodo, lo passa alla CNI per l’elaborazione. La CNI identifica che l’IP di destinazione appartiene a un pod in esecuzione localmente su questo nodo e inoltra il pacchetto al pod corretto tramite le interfacce virtuali appropriate:

Original packet -> node routing -> CNI -> Pod's network namespace

Il server webhook nel pod riceve la richiesta e la elabora.

Risposta

Dopo che il pod del webhook ha elaborato la richiesta, restituisce una risposta seguendo lo stesso percorso in senso inverso:

7. Il pod invia la risposta

Il pod del webhook crea un pacchetto di risposta con il proprio IP come origine e il richiedente originale (l’ENI del piano di controllo (control-plane) EKS) come destinazione:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.23 | Src: 8443           |                 |
| Dst: 10.0.0.132 | Dst: 41892          |                 |
+-----------------+---------------------+-----------------+

La CNI identifica che questo pacchetto va a una rete esterna (non a un pod locale) e lo passa allo stack di rete del nodo mantenendo l’IP di origine originale.

6. Elaborazione della rete del nodo

Il nodo determina che l’IP di destinazione (10.0.0.132) non si trova nella rete locale e inoltra il pacchetto al gateway predefinito (il router locale).

5. Routing del router locale

Il router locale consulta la sua tabella di routing e determina che l’IP di destinazione (10.0.0.132) appartiene al CIDR del VPC (10.0.0.0/16). Inoltra il pacchetto al gateway che si connette a AWS.

4. Transito oltre il limite

Il pacchetto torna indietro attraverso la stessa connessione on-premises al VPC, superando il limite del cloud nella direzione opposta.

3. Routing del VPC

Quando il pacchetto arriva nel VPC, le tabelle di routing identificano che l’IP di destinazione appartiene a una sottorete all’interno del VPC. Il pacchetto viene instradato di conseguenza all’interno del VPC.

2. e 1. Ricezione dell’ENI del piano di controllo (control-plane) EKS

Il pacchetto raggiunge l’ENI collegata al server API Kubernetes, completando il viaggio di andata e ritorno. Il server API riceve la risposta del webhook e continua a elaborare la richiesta API originale in base a tale risposta.

Questo flusso di traffico dimostra perché i CIDR dei pod remoti devono essere configurati e instradati correttamente:

  • Il VPC deve disporre di percorsi per i CIDR dei pod remoti che puntano al gateway on-premises

  • La rete on-premises deve disporre di percorsi per i CIDR dei pod che indirizzano il traffico verso i nodi specifici che ospitano tali pod

  • Senza questa configurazione di routing, i webhook e altri servizi simili eseguiti in pod su nodi ibridi non sarebbero raggiungibili dal piano di controllo (control-plane) EKS.

Da pod a pod in esecuzione su nodi ibridi

Da pod a pod in esecuzione su nodi ibridi

Questa sezione spiega come i pod in esecuzione su diversi nodi ibridi comunicano tra loro. Questo esempio presuppone che la CNI utilizzi VXLAN per l’incapsulamento, una caratteristica comune per le CNI come Cilium o Calico. Il processo complessivo è simile per altri protocolli di incapsulamento come Geneve o IP-in-IP.

Richiesta

1. Il pod A avvia la comunicazione

Il pod A (10.85.1.56) sul nodo 1 desidera inviare traffico al pod B (10.85.2.67) sul nodo 2. Il pacchetto iniziale appare come riportato di seguito:

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

2. La CNI intercetta ed elabora il pacchetto

Quando il pacchetto del pod A lascia il suo namespace di rete, la CNI lo intercetta. La CNI consulta la sua tabella di routing e determina i seguenti elementi: - L’IP di destinazione (10.85.2.67) appartiene al CIDR del pod - Questo IP non si trova sul nodo locale ma appartiene al nodo 2 (10.80.0.3) - Il pacchetto deve essere incapsulato con VXLAN.

La decisione di incapsulare è fondamentale perché la rete fisica sottostante non sa come instradare direttamente i CIDR dei pod, ma solo come instradare il traffico tra gli IP dei nodi.

La CNI incapsula l’intero pacchetto originale all’interno di un frame VXLAN. Questo crea effettivamente un “pacchetto all’interno di un pacchetto” con nuovi header:

+-----------------+----------------+--------------+------------+---------------------------+
| Outer Ethernet  | Outer IP       | Outer UDP    | VXLAN      | Original Pod-to-Pod       |
| Src: Node1 MAC  | Src: 10.80.0.2 | Src: Random  | VNI: 42    | Packet (unchanged         |
| Dst: Router MAC | Dst: 10.80.0.3 | Dst: 8472    |            | from above)               |
+-----------------+----------------+--------------+------------+---------------------------+

Punti chiave di questo incapsulamento: - Il pacchetto esterno viene indirizzato dal nodo 1 (10.80.0.2) al nodo 2 (10.80.0.3) - La porta UDP 8472 è la porta VXLAN utilizzata da Cilium per impostazione predefinita - Il VXLAN Network Identifier (VNI) identifica a quale rete sovrapposta appartiene tale pacchetto - L’intero pacchetto originale (con l’IP del pod A come origine e l’IP del pod B come destinazione) è conservato intatto all’interno

Il pacchetto incapsulato entra ora nel normale stack di rete del nodo 1 e viene elaborato allo stesso modo di qualsiasi altro pacchetto:

  1. Elaborazione della rete del nodo: lo stack di rete del nodo 1 indirizza il pacchetto in base alla sua destinazione (10.80.0.3)

  2. Distribuzione della rete locale:

    • Se entrambi i nodi si trovano sulla stessa rete di livello 2, il pacchetto viene inviato direttamente al nodo 2

    • Se si trovano su sottoreti diverse, il pacchetto viene prima inoltrato al router locale

  3. Gestione del router: il router inoltra il pacchetto in base alla sua tabella di routing, distribuendolo al nodo 2

3. Elaborazione dei nodi di ricezione

Quando il pacchetto incapsulato arriva al nodo 2 (10.80.0.3):

  1. Lo stack di rete del nodo lo riceve e lo identifica come pacchetto VXLAN (porta UDP 4789)

  2. Il pacchetto viene passato all’interfaccia VXLAN della CNI per l’elaborazione

4. Decapsulazione VXLAN

La CNI sul nodo 2 elabora il pacchetto VXLAN:

  1. Elimina gli header esterni (Ethernet, IP, UDP e VXLAN).

  2. Estrae il pacchetto interno originale.

  3. Il pacchetto è ora tornato alla sua forma originale:

+------------------+-----------------+-------------+-----------------+
| Ethernet Header  | IP Header       | TCP/UDP     | Payload         |
| Src: Pod A MAC   | Src: 10.85.1.56 | Src: 43721  |                 |
| Dst: Gateway MAC | Dst: 10.85.2.67 | Dst: 8080   |                 |
+------------------+-----------------+-------------+-----------------+

La CNI sul nodo 2 esamina l’IP di destinazione (10.85.2.67) e:

  1. Identifica che questo IP appartiene a un pod locale.

  2. Instrada il pacchetto attraverso le interfacce virtuali appropriate.

  3. Fornisce il pacchetto al namespace di rete del pod B.

Risposta

Quando il pod B risponde al pod A, l’intero processo avviene al contrario:

  1. Il pod B invia un pacchetto al pod A (10.85.1.56).

  2. La CNI del nodo 2 lo incapsula con VXLAN, impostando la destinazione sul nodo 1 (10.80.0.2).

  3. Il pacchetto incapsulato viene consegnato al nodo 1.

  4. La CNI del nodo 1 lo decapsula e fornisce la risposta originale al pod A.

Da pod su nodi cloud a pod su nodi ibridi (traffico est-ovest)

Da pod su nodi cloud a pod su nodi ibridi

Richiesta

1. Il pod A avvia la comunicazione

Il pod A (10.0.0.56) sul nodo EC2 desidera inviare traffico al pod B (10.85.1.56) sul nodo ibrido. Il pacchetto iniziale appare come riportato di seguito:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.0.0.56  | Src: 52390 (random) |                 |
| Dst: 10.85.1.56 | Dst: 8080           |                 |
+-----------------+---------------------+-----------------+

Con la CNI del VPC, il pod A ha un IP dal CIDR del VPC ed è collegato direttamente a una ENI sull’istanza EC2. Il namespace di rete del pod è connesso alla rete del VPC, quindi il pacchetto entra direttamente nell’infrastruttura di routing VPC.

2. Routing del VPC

La tabella di routing del VPC contiene un instradamento specifico per il CIDR del pod remoto (10.85.0.0/16), che indirizza questo traffico verso il gateway da VPC a on-premises:

Destination     Target
10.0.0.0/16     local
10.85.0.0/16    vgw-id (VPC-to-onprem gateway)

In base a questa regola di routing, il pacchetto viene indirizzato verso il gateway che si connette alla rete on-premises.

3. Transito oltre il limite

Il gateway trasferisce il pacchetto oltre i limiti del cloud tramite la connessione stabilita (come Direct Connect o VPN) alla rete on-premises. Il pacchetto mantiene gli indirizzi IP di origine e di destinazione originali durante questo transito.

4. Ricezione nella rete on-premises

Il pacchetto arriva al router on-premises locale. Il router consulta la propria tabella di routing per determinare l’hop successivo per raggiungere l’indirizzo 10.85.1.56. Il router on-premises deve disporre di percorsi per i CIDR dei pod che indirizzano il traffico verso il nodo ibrido appropriato.

La tabella del router contiene una voce che indica che la sottorete 10.85.1.0/24 è raggiungibile tramite il nodo ibrido con IP 10.80.0.2:

Destination     Next Hop
10.85.1.0/24    10.80.0.2

5. Elaborazione della rete del nodo

Il router inoltra il pacchetto al nodo ibrido (10.80.0.2). Quando il pacchetto arriva al nodo, ha ancora l’IP del pod A come origine e l’IP del pod B come destinazione.

6. Elaborazione della CNI

Lo stack di rete del nodo riceve il pacchetto e, visto che l’IP di destinazione non è il proprio, lo passa alla CNI per l’elaborazione. La CNI identifica che l’IP di destinazione appartiene a un pod in esecuzione localmente su questo nodo e inoltra il pacchetto al pod corretto tramite le interfacce virtuali appropriate:

Original packet -> node routing -> CNI -> Pod B's network namespace

Il pod B riceve il pacchetto e lo elabora in base alle esigenze.

Risposta

6. Il pod B invia la risposta

Il pod B crea un pacchetto di risposta con il proprio IP come origine e l’IP del pod A come destinazione:

+-----------------+---------------------+-----------------+
| IP Header       | TCP Header          | Payload         |
| Src: 10.85.1.56 | Src: 8080           |                 |
| Dst: 10.0.0.56  | Dst: 52390          |                 |
+-----------------+---------------------+-----------------+

La CNI identifica che questo pacchetto è destinato a una rete esterna e lo passa allo stack di rete del nodo.

5. Elaborazione della rete del nodo

Il nodo determina che l’IP di destinazione (10.0.0.56) non appartiene alla rete locale e inoltra il pacchetto al gateway predefinito (il router locale).

4. Routing del router locale

Il router locale consulta la sua tabella di routing e determina che l’IP di destinazione (10.0.0.56) appartiene al CIDR del VPC (10.0.0.0/16). Inoltra il pacchetto al gateway che si connette a AWS.

3. Transito oltre il limite

Il pacchetto torna indietro attraverso la stessa connessione on-premises al VPC, superando il limite del cloud nella direzione opposta.

2. Routing del VPC

Quando il pacchetto arriva nel VPC, il sistema di routing identifica che l’IP di destinazione appartiene a una sottorete all’interno del VPC. Il pacchetto viene instradato attraverso la rete del VPC verso l’istanza EC2 che ospita il pod A.

1. Il pod A riceve la risposta

Il pacchetto arriva all’istanza EC2 e viene consegnato direttamente al pod A tramite l’ENI collegata. Poiché la CNI del VPC non utilizza reti sovrapposte per i pod nel VPC, non è necessario alcun decapsulazione aggiuntivo: il pacchetto arriva con le intestazioni originali intatte.

Questo flusso di traffico est-ovest dimostra perché i CIDR dei pod remoti devono essere configurati correttamente e instradabili da entrambe le direzioni:

  • Il VPC deve disporre di percorsi per i CIDR dei pod remoti che puntano al gateway on-premises

  • La rete on-premises deve disporre di percorsi per i CIDR dei pod che indirizzano il traffico verso i nodi specifici che ospitano tali pod.