Configurazione della visibilità tra nodi

Autopilot Standard

Questa guida mostra come configurare la visibilità tra nodi in un cluster Google Kubernetes Engine (GKE).

La visibilità tra nodi configura la rete su ogni nodo del cluster in modo che il traffico inviato da un pod a un altro pod venga elaborato dalla rete VPC (Virtual Private Cloud) del cluster, anche se i pod si trovano sullo stesso nodo.

La visibilità tra nodi è disabilitata per impostazione predefinita nei cluster Standard e abilitata per impostazione predefinita nei cluster Autopilot.

Architettura

La visibilità tra nodi garantisce che i pacchetti inviati tra i pod vengano sempre elaborati dalla rete VPC, il che garantisce che le regole firewall, le route, i log di flusso e le configurazioni di Mirroring pacchetto si applichino ai pacchetti.

Quando un pod invia un pacchetto a un altro pod sullo stesso nodo, il pacchetto lascia il nodo e viene elaborato dalla Google Cloud rete. Il pacchetto viene quindi immediatamente inviato di nuovo allo stesso nodo e inoltrato al pod di destinazione.

La visibilità tra nodi esegue il deployment di netd DaemonSet.

Vantaggi

La visibilità tra nodi offre i seguenti vantaggi:

• Visualizza i log di flusso per tutto il traffico tra i pod, incluso il traffico tra i pod sullo stesso nodo.
• Crea regole firewall che si applicano a tutto il traffico tra i pod, incluso il traffico tra i pod sullo stesso nodo.
• Utilizza Mirroring pacchetto per clonare il traffico, incluso il traffico tra i pod sullo stesso nodo, e inoltralo per l'esame.

Requisiti e limitazioni

La visibilità tra nodi presenta i seguenti requisiti e limitazioni:

• Il cluster deve utilizzare GKE 1.15 o versioni successive.
• La visibilità tra nodi non è supportata con i node pool Windows Server.
• Per evitare problemi di connettività, quando utilizzi il flag ip-masq-agent con la visibilità tra nodi, l'elenco nonMasqueradeCIDRs personalizzato deve includere gli intervalli di indirizzi IP dei nodi e dei pod del cluster.

Regole firewall

Quando abiliti la visibilità tra nodi, la rete VPC elabora tutti i pacchetti inviati tra i pod, inclusi i pacchetti inviati tra i pod sullo stesso nodo. Ciò significa che le regole firewall VPC e le policy firewall gerarchiche si applicano in modo coerente alla comunicazione tra i pod, indipendentemente dalla posizione dei pod.

Se configuri regole firewall personalizzate per la comunicazione all'interno del cluster, valuta attentamente le esigenze di rete del cluster per determinare l'insieme di regole di autorizzazione in uscita e in entrata. Puoi utilizzare i test di connettività per assicurarti che il traffico legittimo non venga bloccato. Ad esempio, la comunicazione tra i pod è necessaria per il funzionamento dei criteri di rete.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Abilitare la visibilità tra nodi in un nuovo cluster

Puoi creare un cluster con la visibilità tra nodi abilitata utilizzando la gcloud CLI o la Google Cloud console.

gcloud

Per creare un cluster a nodo singolo con la visibilità tra nodi abilitata, utilizza il flag --enable-intra-node-visibility:

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-intra-node-visibility

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del nuovo cluster.
• CONTROL_PLANE_LOCATION: la località Compute Engine del piano di controllo del cluster. Fornisci una regione per i cluster regionali o una zona per i cluster zonali.

Console

Per creare un cluster a nodo singolo con la visibilità tra nodi abilitata, segui questi passaggi:

1. Vai alla pagina Google Kubernetes Engine nella Google Cloud console.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Inserisci il nome del cluster.

4. Nella finestra di dialogo Configura cluster, fai clic su Configura accanto a GKE Standard.

5. Configura il cluster in base alle esigenze.

6. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

7. Seleziona la casella di controllo Abilita visibilità tra nodi.

8. Fai clic su Crea.

Abilitare la visibilità tra nodi in un cluster esistente

Puoi abilitare la visibilità tra nodi in un cluster esistente utilizzando il gcloud CLI o la Google Cloud console.

Quando abiliti la visibilità tra nodi per un cluster esistente, GKE riavvia i componenti sia nel control plane sia nei nodi worker.

gcloud

Per abilitare la visibilità tra nodi in un cluster esistente, utilizza il flag --enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

Sostituisci CLUSTER_NAME con il nome del cluster.

Console

Per abilitare la visibilità tra nodi in un cluster esistente, segui questi passaggi:

1. Vai alla pagina Google Kubernetes Engine nella Google Cloud console.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. In Networking, fai clic su Modifica visibilità tra nodi.

4. Seleziona la casella di controllo Abilita visibilità tra nodi.

5. Fai clic su Salva modifiche.

Questa modifica richiede la ricreazione dei nodi, che può causare interruzioni dei carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, trova la riga corrispondente nella tabella delle modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi e rispettando le policy di manutenzione. Per saperne di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni degli aggiornamenti dei nodi.

Importante: GKE rispetta le policy di manutenzione quando ricrea i nodi per questa modifica utilizzando la strategia di upgrade dei nodi e dipende dalla disponibilità delle risorse. La disattivazione degli upgrade automatici dei nodi non impedisce questa modifica. Per applicare manualmente le modifiche ai nodi, utilizza gcloud CLI per chiamare il gcloud container clusters upgrade comando, passando il --cluster-version flag con la stessa versione di GKE già in esecuzione nel node pool.

Disabilitare la visibilità tra nodi

Puoi disabilitare la visibilità tra nodi in un cluster utilizzando il gcloud CLI o la Google Cloud console.

Quando disabiliti la visibilità tra nodi per un cluster esistente, GKE riavvia i componenti sia nel control plane sia nei nodi worker.

gcloud

Per disabilitare la visibilità tra nodi, utilizza il flag --no-enable-intra-node-visibility:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

Sostituisci CLUSTER_NAME con il nome del cluster.

Console

Per disabilitare la visibilità tra nodi, segui questi passaggi:

1. Vai alla pagina Google Kubernetes Engine nella Google Cloud console.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. In Networking, fai clic su Modifica visibilità tra nodi.

4. Deseleziona la casella di controllo Abilita visibilità tra nodi.

5. Fai clic su Salva modifiche.

Questa modifica richiede la ricreazione dei nodi, che può causare interruzioni dei carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, trova la riga corrispondente nella tabella delle modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi e rispettando le policy di manutenzione. Per saperne di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni degli aggiornamenti dei nodi.

Importante: GKE rispetta le policy di manutenzione quando ricrea i nodi per questa modifica utilizzando la strategia di upgrade dei nodi e dipende dalla disponibilità delle risorse. La disattivazione degli upgrade automatici dei nodi non impedisce questa modifica. Per applicare manualmente le modifiche ai nodi, utilizza gcloud CLI per chiamare il gcloud container clusters upgrade comando, passando il --cluster-version flag con la stessa versione di GKE già in esecuzione nel node pool.

Esercitazione: verificare la visibilità tra nodi

Questa esercitazione mostra i passaggi necessari per abilitare la visibilità tra nodi e confermare che funzioni per il tuo cluster.

In questa esercitazione, esegui i seguenti passaggi:

1. Abilita i log di flusso per la subnet predefinita nella regione us-central1.
2. Crea un cluster a nodo singolo con la visibilità tra nodi abilitata nella zona us-central1-a.
3. Crea due pod nel cluster.
4. Invia una richiesta HTTP da un pod a un altro pod.
5. Visualizza la voce di log di flusso per la richiesta tra i pod.

Abilitare i log di flusso

1. Abilita i log di flusso per la subnet predefinita:

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. Verifica che i log di flusso siano abilitati per la subnet predefinita:

   gcloud compute networks subnets describe default \
       --region=us-central1
   

   L'output mostra che i log di flusso sono abilitati, come nel seguente esempio:

   ...
   enableFlowLogs: true
   ...
   

Creare un cluster

1. Crea un cluster a nodo singolo con la visibilità tra nodi abilitata:

   gcloud container clusters create flow-log-test \
       --location=us-central1-a \
       --num-nodes=1 \
       --enable-intra-node-visibility
   

2. Recupera le credenziali per il tuo cluster:

   gcloud container clusters get-credentials flow-log-test \
       --location=us-central1-a
   

Creare due pod

1. Crea un pod.

   Salva il seguente manifest in un file denominato pod-1.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

2. Applica il manifest al cluster:

   kubectl apply -f pod-1.yaml
   

3. Crea un secondo pod.

   Salva il seguente manifest in un file denominato pod-2.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
   

4. Applica il manifest al cluster:

   kubectl apply -f pod-2.yaml
   

5. Visualizza i pod:

   kubectl get pod pod-1 pod-2 --output wide
   

   L'output mostra gli indirizzi IP dei pod, come nel seguente esempio:

   NAME      READY     STATUS    RESTARTS   AGE       IP           ...
   pod-1     1/1       Running   0          1d        10.52.0.13   ...
   pod-2     1/1       Running   0          1d        10.52.0.14   ...
   

   Prendi nota degli indirizzi IP di pod-1 e pod-2.

Inviare una richiesta

1. Apri una shell nel container in pod-1:

   kubectl exec -it pod-1 -- sh
   

2. Nella shell, invia una richiesta a pod-2:

   curl -s POD_2_IP_ADDRESS:8080
   

   Sostituisci POD_2_IP_ADDRESS con l'indirizzo IP di pod-2.

   L'output mostra la risposta del container in esecuzione in pod-2.

   Hello, world!
   Version: 2.0.0
   Hostname: pod-2
   

3. Digita exit per uscire dalla shell e tornare all'ambiente della riga di comando principale.

Visualizzare le voci dei log di flusso

Per visualizzare una voce di log del flusso, utilizza il seguente comando:

gcloud logging read \
    'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'

Sostituisci quanto segue:

• PROJECT_ID: il tuo ID progetto.
• POD_1_IP_ADDRESS: l'indirizzo IP di pod-1.
• POD_2_IP_ADDRESS: l'indirizzo IP di pod-2.

L'output mostra una voce di log di flusso per una richiesta da pod-1 a pod-2. In questo esempio, pod-1 ha l'indirizzo IP 10.56.0.13 e pod-2 ha l'indirizzo IP 10.56.0.14.

...
jsonPayload:
  bytes_sent: '0'
  connection:
    dest_ip: 10.56.0.14
    dest_port: 8080
    protocol: 6
    src_ip: 10.56.0.13
    src_port: 35414
...

Libera spazio

Per evitare addebiti indesiderati sul tuo account, segui questi passaggi per rimuovere le risorse che hai creato:

1. Elimina il cluster:

   gcloud container clusters delete -q flow-log-test
   

2. Disabilita i log di flusso per la subnet predefinita:

   gcloud compute networks subnets update default --no-enable-flow-logs
   

Passaggi successivi

• Scopri come controllare la comunicazione tra i pod e i servizi del cluster creando un criterio di rete del cluster.
• Scopri i vantaggi dei cluster nativi di VPC.