Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete

Questa pagina spiega come controllare la comunicazione tra i pod e i servizi del cluster utilizzando l'applicazione dei criteri di rete di GKE.

Puoi anche controllare il traffico in uscita dei pod verso qualsiasi endpoint o servizio al di fuori del cluster utilizzando criteri di rete basati sul nome di dominio completo (FQDN). Per ulteriori informazioni, consulta Controllare la comunicazione tra pod e servizi utilizzando i nomi di dominio completi.

Informazioni sull'applicazione dei criteri di rete GKE

L'applicazione dei criteri di rete ti consente di creare criteri di rete di Kubernetes nel tuo cluster. Per impostazione predefinita, tutti i pod all'interno di un cluster possono comunicare tra loro liberamente. I criteri di rete creano regole firewall a livello di pod che determinano quali pod e servizi possono accedere l'uno all'altro all'interno del cluster.

La definizione dei criteri di rete ti aiuta ad abilitare funzionalità come la difesa in profondità quando il cluster gestisce un'applicazione a più livelli. Ad esempio, puoi creare una norma di rete per garantire che un servizio di frontend compromesso nella tua applicazione non possa comunicare direttamente con un servizio di fatturazione o contabilità a diversi livelli di profondità.

Le norme di rete possono anche semplificare l'hosting dei dati di più utenti contemporaneamente per la tua applicazione. Ad esempio, puoi fornire un multi-tenancy sicuro definendo un modello di tenant per spazio dei nomi. In un modello di questo tipo, le regole dei criteri di rete possono garantire che i pod e i servizi in un determinato spazio dei nomi non possano accedere ad altri pod o servizi in uno spazio dei nomi diverso.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Requisiti e limitazioni

Ai cluster Autopilot e Standard si applicano i seguenti requisiti e limitazioni:

• Devi consentire l'uscita al server di metadati.
• Se specifichi un campo endPort in un criterio di rete su un cluster con GKE Dataplane V2 abilitato, potrebbe non essere applicato a partire dalla versione 1.22 di GKE. Per ulteriori informazioni, vedi Gli intervalli di porte di Network Policy non hanno effetto. Per i cluster Autopilot, GKE Dataplane V2 è sempre abilitato.

I seguenti requisiti e limitazioni si applicano solo ai cluster Standard:

• Devi consentire il traffico in uscita verso il server metadati se utilizzi il criterio di rete con Workload Identity Federation for GKE.
• L'attivazione dell'applicazione dei criteri di rete aumenta l'utilizzo di memoria del processo kube-system di circa 128 MB e richiede circa 300 millicore di CPU. Ciò significa che se abiliti i criteri di rete per un cluster esistente, potresti dover aumentare le dimensioni del cluster per continuare a eseguire i carichi di lavoro pianificati.
• L'abilitazione dell'applicazione dei criteri di rete richiede la ricreazione dei nodi. Se il cluster ha un periodo di manutenzione attivo, i nodi non vengono ricreati automaticamente fino al periodo di manutenzione successivo. Se preferisci, puoi eseguire manualmente l'upgrade del cluster in qualsiasi momento.
• La dimensione minima richiesta del cluster per l'applicazione dei criteri di rete è di tre istanze e2-medium o di un'istanza di tipo di macchina con più di 1 vCPU allocabile. Per maggiori dettagli, consulta la sezione Problemi noti di GKE.
• I criteri di rete non sono supportati per i cluster i cui nodi sono istanze f1-micro o g1-small, in quanto i requisiti di risorse sono troppo elevati.
• Cilium o Calico non gestiscono i pod che impostano hostNetwork: true e le norme di rete non possono governare questi pod.

Per saperne di più sui tipi di macchine dei nodi e sulle risorse allocabili, consulta Architettura del cluster standard - Nodi.

Abilita l'applicazione dei criteri di rete

L'applicazione dei criteri di rete è abilitata per impostazione predefinita per i cluster Autopilot, quindi puoi passare a Creare un criterio di rete.

Puoi abilitare l'applicazione dei criteri di rete in Standard utilizzando gcloud CLI, la Google Cloud console o l'API GKE.

L'applicazione della policy di rete è integrata in GKE Dataplane V2. Non è necessario abilitare l'applicazione dei criteri di rete nei cluster che utilizzano GKE Dataplane V2.

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

Disabilitare l'applicazione dei criteri di rete in un cluster Standard

Puoi disattivare l'applicazione dei criteri di rete utilizzando gcloud CLI, la console Google Cloud o l'API GKE. Non puoi disattivare l'applicazione dei criteri di rete nei cluster Autopilot o nei cluster che utilizzano GKE Dataplane V2.

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

Crea un criterio di rete

Puoi creare un criterio di rete utilizzando l'API Network Policy di Kubernetes.

Per ulteriori dettagli sulla creazione di un criterio di rete, consulta i seguenti argomenti nella documentazione di Kubernetes:

• Panoramica delle norme di rete
• Dichiarare il criterio di rete

Criterio di rete e federazione delle identità per i carichi di lavoro per GKE

Se utilizzi le norme di rete con la federazione delle identità per i carichi di lavoro per GKE, devi consentire il traffico in uscita verso i seguenti indirizzi IP in modo che i pod possano comunicare con il server metadati GKE.

• Per i cluster che eseguono GKE versione 1.21.0-gke.1000 e successive, consenti l'uscita a 169.254.169.252/32 sulla porta 988.
• Per i cluster che eseguono versioni di GKE precedenti alla 1.21.0-gke.1000, consenti l'uscita a 127.0.0.1/32 sulla porta 988.
• Per i cluster che eseguono GKE Dataplane V2, consenti l'uscita a 169.254.169.254/32 sulla porta 80.

Se non consenti l'uscita a questi indirizzi IP e porte, potresti riscontrare interruzioni durante gli upgrade automatici.

Migrazione da Calico a GKE Dataplane V2

Se esegui la migrazione dei criteri di rete da Calico a GKE Dataplane V2, considera le seguenti limitazioni:

• Non puoi utilizzare un indirizzo IP di pod o servizio nel campo ipBlock.cidr di un manifest NetworkPolicy. Devi fare riferimento ai workload utilizzando le etichette. Ad esempio, la seguente configurazione non è valida:

  - ipBlock:
      cidr: 10.8.0.6/32
  

• Non puoi specificare un campo ports.port vuoto in un manifest NetworkPolicy. Se specifichi un protocollo, devi specificare anche una porta. Ad esempio, la seguente configurazione non è valida:

  ingress:
  - ports:
    - protocol: TCP
  

Utilizzo dei bilanciatori del carico delle applicazioni

Quando un ingresso viene applicato a un servizio per creare un bilanciatore del carico delle applicazioni, devi configurare il criterio di rete applicato ai pod dietro il servizio per consentire gli intervalli di indirizzi IP del controllo di integrità del bilanciatore del carico delle applicazioni appropriati. Se utilizzi un bilanciatore del carico delle applicazioni interno, devi anche configurare il criterio di rete per consentire la subnet solo proxy.

Se non utilizzi il bilanciamento del carico nativo del container con i gruppi di endpoint di rete, le porte dei nodi per un servizio potrebbero inoltrare le connessioni ai pod su altri nodi, a meno che non venga impedito impostando externalTrafficPolicy su Local nella definizione del servizio. Se externalTrafficPolicy non è impostato su Local, la policy di rete deve anche consentire le connessioni da altri IP dei nodi nel cluster.

Inclusione degli intervalli IP dei pod nelle regole ipBlock

Per controllare il traffico per pod specifici, seleziona sempre i pod in base allo spazio dei nomi o alle etichette dei pod utilizzando i campi namespaceSelector e podSelector nelle regole di ingresso o uscita di NetworkPolicy. Non utilizzare il campo ipBlock.cidr per selezionare intenzionalmente intervalli di indirizzi IP dei pod, che sono temporanei per natura. Il progetto Kubernetes non definisce esplicitamente il comportamento del campo ipBlock.cidr quando include intervalli di indirizzi IP dei pod. La specifica di intervalli CIDR ampi in questo campo, come 0.0.0.0/0 (che includono gli intervalli di indirizzi IP dei pod), potrebbe avere risultati imprevisti in diverse implementazioni di NetworkPolicy.

Le seguenti sezioni descrivono in che modo le diverse implementazioni di NetworkPolicy in GKE valutano gli intervalli di indirizzi IP specificati nel campo ipBlock.cidr e come ciò potrebbe influire sugli intervalli di indirizzi IP dei pod che sono inclusi in modo intrinseco in ampi intervalli CIDR. Comprendere il diverso comportamento tra le implementazioni ti aiuterà a prepararti ai risultati quando esegui la migrazione a un'altra implementazione.

Comportamento di ipBlock in GKE Dataplane V2

Con l'implementazione di NetworkPolicy di GKE Dataplane V2, il traffico dei pod non è mai coperto da una regola ipBlock. Pertanto, anche se definisci una regola generale come cidr: '0.0.0.0/0', non includerà il traffico del pod. Ciò è utile perché ti consente, ad esempio, di consentire ai pod in uno spazio dei nomi di ricevere traffico da internet, senza consentire anche il traffico dai pod. Per includere anche il traffico dei pod, seleziona esplicitamente i pod utilizzando un selettore aggiuntivo di pod o spazi dei nomi nelle definizioni delle regole di ingresso o uscita di NetworkPolicy.

Comportamento di ipBlock in Calico

Per l'implementazione di NetworkPolicy di Calico, le regole ipBlock coprono il traffico dei pod. Con questa implementazione, per configurare un intervallo CIDR ampio senza consentire il traffico dei pod, escludi esplicitamente l'intervallo CIDR dei pod del cluster, come nel seguente esempio:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

In questo esempio, POD_IP_RANGE è l'intervallo di indirizzi IPv4 dei pod del cluster, ad esempio 10.95.0.0/17. Se hai più intervalli IP, questi possono essere inclusi singolarmente nell'array, ad esempio ['10.95.0.0/17', '10.108.128.0/17'].

Controllare il comportamento delle policy di rete con externalTrafficPolicy

L'impostazione externalTrafficPolicy per il servizio influisce sul modo in cui Kubernetes applica i criteri di rete. Questa impostazione determina l'indirizzo IP di origine che i tuoi pod vedono per il traffico in entrata e può influire sul modo in cui Kubernetes valuta le regole NetworkPolicy.

externalTrafficPolicyha due valori possibili:

• Cluster: quando externalTrafficPolicy è impostato su Cluster, il pod di destinazione vede l'indirizzo IP di origine come l'indirizzo IP del nodo in cui viene ricevuto inizialmente il traffico. Se hai un NetworkPolicy che nega il traffico in base agli indirizzi IP client, ma non include gli indirizzi IP dei nodi remoti, potrebbe bloccare involontariamente il traffico esterno dai client esterni specificati nelle regole del criterio. Per evitarlo, crea un criterio che consenta il traffico da tutti i nodi del cluster. Tuttavia, questo criterio consentirà il traffico da qualsiasi client esterno.

• Local: quando externalTrafficPolicy è impostato su Local, il pod vede l'indirizzo IP di origine come l'indirizzo IP client originale. Ciò consente un controllo più granulare con le norme di rete, in quanto puoi definire regole basate sugli indirizzi IP client effettivi.

Risoluzione dei problemi

I pod non possono comunicare con il control plane sui cluster che utilizzano Private Service Connect

I pod sui cluster GKE che utilizzano Private Service Connect potrebbero riscontrare un problema di comunicazione con il control plane se l'uscita del pod verso l'indirizzo IP interno del control plane è limitata nelle norme di rete in uscita.

Per risolvere il problema:

1. Verifica che il cluster utilizzi Private Service Connect. Nei cluster che utilizzano Private Service Connect, se utilizzi il flag master-ipv4-cidr durante la creazione della subnet, GKE assegna a ogni control plane un indirizzo IP interno dai valori definiti in master-ipv4-cidr. In caso contrario, GKE utilizza la subnet dei nodi del cluster per assegnare a ogni control plane un indirizzo IP interno.

2. Configura il criterio di uscita del cluster per consentire il traffico verso l'indirizzo IP interno del control plane.

   Per trovare l'indirizzo IP interno del control plane:

   gcloud

   Per cercare privateEndpoint, esegui questo comando:

   gcloud container clusters describe CLUSTER_NAME
   

   Sostituisci CLUSTER_NAME con il nome del cluster.

   Questo comando recupera il privateEndpoint del cluster specificato.

   Console

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

      Vai a Google Kubernetes Engine

   2. Nel riquadro di navigazione, in Cluster, fai clic sul cluster di cui vuoi trovare l'indirizzo IP interno.

   3. In Impostazioni di base del cluster, vai a Internal endpoint, dove è elencato l'indirizzo IP interno.

   Una volta individuato privateEndpoint o Internal endpoint, configura il criterio di uscita del cluster per consentire il traffico verso l'indirizzo IP interno del control plane. Per saperne di più, consulta Creare un criterio di rete.

Aggiornamento del cluster lento

Quando abiliti o disabiliti l'applicazione dei criteri di rete su un cluster esistente, GKE potrebbe non aggiornare immediatamente i nodi se il cluster ha un periodo di manutenzione o un'esclusione configurati.

Puoi eseguire manualmente l'upgrade di un pool di nodi impostando il flag --cluster-version alla stessa versione GKE in esecuzione nel control plane. Devi utilizzare Google Cloud CLI per eseguire questa operazione. Per saperne di più, consulta avvertenze per i periodi di manutenzione.

Pod di cui è stato eseguito il deployment manualmente non pianificati

Quando abiliti l'applicazione dei criteri di rete sul control plane di un cluster esistente, GKE annulla la pianificazione di tutti i pod ip-masquerade-agent o calico node che hai eseguito il deployment manualmente.

GKE non riprogramma questi pod finché l'applicazione dei criteri di rete non è attivata sui nodi del cluster e i nodi non vengono ricreati.

Se hai configurato un periodo di manutenzione o un'esclusione, potrebbe verificarsi un'interruzione prolungata.

Per ridurre al minimo la durata di questa interruzione, puoi assegnare manualmente le seguenti etichette ai nodi del cluster:

• node.kubernetes.io/masq-agent-ds-ready=true
• projectcalico.org/ds-ready=true

Il criterio di rete non ha effetto

Se una NetworkPolicy non viene applicata, puoi risolvere il problema seguendo questi passaggi:

1. Verifica che l'applicazione dei criteri di rete sia attivata. Il comando che utilizzi dipende dal fatto che il cluster abbia GKE Dataplane V2 abilitato.

   Se nel cluster è abilitato GKE Dataplane V2, esegui questo comando:

   kubectl -n kube-system get pods -l k8s-app=cilium
   

   Se l'output è vuoto, l'applicazione dei criteri di rete non è abilitata.

   Se il tuo cluster non ha GKE Dataplane V2 abilitato, esegui il seguente comando:

   kubectl get nodes -l projectcalico.org/ds-ready=true
   

   Se l'output è vuoto, l'applicazione dei criteri di rete non è abilitata.

2. Controlla le etichette dei pod:

   kubectl describe pod POD_NAME
   

   Sostituisci POD_NAME con il nome del pod.

   L'output è simile al seguente:

   Labels:        app=store
                  pod-template-hash=64d9d4f554
                  version=v1
   

3. Verifica che le etichette sui criteri corrispondano a quelle sul Pod:

   kubectl describe networkpolicy
   

   L'output è simile al seguente:

   PodSelector: app=store
   

   In questo output, le etichette app=store corrispondono alle etichette app=store del passaggio precedente.

4. Controlla se sono presenti criteri di rete che selezionano i tuoi carichi di lavoro:

   kubectl get networkpolicy
   

   Se l'output è vuoto, non è stata creata alcuna NetworkPolicy nello spazio dei nomi e nessun elemento seleziona i tuoi carichi di lavoro. Se l'output non è vuoto, controlla se il criterio seleziona i tuoi carichi di lavoro:

   kubectl describe networkpolicy
   

   L'output è simile al seguente:

   ...
   PodSelector:     app=nginx
   Allowing ingress traffic:
      To Port: <any> (traffic allowed to all ports)
      From:
         PodSelector: app=store
   Not affecting egress traffic
   Policy Types: Ingress
   

Problemi noti

Terminazione dei pod StatefulSet con Calico

I cluster GKE con Calico network policy abilitata potrebbero riscontrare un problema per cui un pod StatefulSet abbandona le connessioni esistenti quando viene eliminato. Dopo che un pod entra nello stato Terminating, la configurazione terminationGracePeriodSeconds nella specifica del pod non viene rispettata e causa interruzioni per altre applicazioni che hanno una connessione esistente con il pod StatefulSet. Per ulteriori informazioni su questo problema, consulta il problema n. 4710 di Calico.

Questo problema interessa le seguenti versioni di GKE:

• 1.18
• da 1.19 a 1.19.16-gke.99
• Da 1.20 a 1.20.11-gke.1299
• Da 1.21 a 1.21.4-gke.1499

Per risolvere il problema, esegui l'upgrade del control plane GKE a una delle seguenti versioni:

• 1.19.16-gke.100 o versioni successive
• 1.20.11-gke.1300 o versioni successive
• 1.21.4-gke.1500 o versioni successive

Pod bloccato nello stato containerCreating

Esistono scenari in cui i cluster GKE con il criterio di rete Calico abilitato potrebbero riscontrare un problema per cui i pod rimangono bloccati nello stato containerCreating.

Nella scheda Eventi del pod, viene visualizzato un messaggio simile al seguente:

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

Per risolvere questo problema, utilizza host-local ipam per Calico anziché calico-ipam nei cluster GKE.

Passaggi successivi

• Segui il tutorial sui criteri di rete.

• Leggi la documentazione di Kubernetes sui criteri di rete.

• Implementa approcci comuni per limitare il traffico utilizzando i criteri di rete.

• Utilizzo del logging dei criteri di rete.

• Utilizza le informazioni sulla sicurezza per esplorare altri modi per rafforzare la tua infrastruttura.