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

Autopilot Standard

---

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 esterno al cluster utilizzando i criteri di rete basati su nomi di dominio completi (FQDN). Per ulteriori informazioni, consulta Controllare la comunicazione tra pod e servizi utilizzando i FQDN.

Informazioni sull'applicazione dei criteri di rete di GKE

L'applicazione dei criteri di rete ti consente di creare Network Access Control (NAC) 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 uno all'altro all'interno del cluster.

La definizione dei criteri di rete ti consente di attivare, ad esempio, la difesa in profondità quando il cluster serve un'applicazione a più livelli. Ad esempio, puoi creare un criterio di rete per assicurarti che un servizio frontend compromesso nella tua applicazione non possa comunicare direttamente con un servizio di fatturazione o contabilità a diversi livelli di gerarchia.

Le norme di rete possono anche semplificare l'hosting dei dati di più utenti contemporaneamente da parte della tua applicazione. Ad esempio, puoi fornire un'organizzazione multi-tenancy sicura definendo un modello tenant per spazio dei nomi. In questo modello, 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.

Nota: affinché l'applicazione dei criteri di rete funzioni correttamente, GKE esegue il deployment di pod sui nodi con autorizzazioni RBAC elevate, come la possibilità di applicare patch a tutti i deployment e aggiornare lo stato dei nodi. Queste autorizzazioni sono necessarie per consentire a GKE di applicare i criteri di rete in base alla tua configurazione.

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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

Requisiti e limitazioni

I seguenti requisiti e limitazioni si applicano sia ai cluster Autopilot sia ai cluster standard:

• Devi consentire l'uscita al server dei metadati.
• Se specifichi un campo endPort in un criterio di rete su un cluster in cui è attivato GKE Dataplane V2, l'impostazione potrebbe non essere applicata a partire dalla versione 1.22 di GKE. Per ulteriori informazioni, consulta Gli intervalli di porte dei criteri di rete non vengono applicati. Per i cluster Autopilot, GKE Dataplane V2 è sempre abilitato.

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

• Devi consentire l'uscita al server metadati se utilizzi i criteri di rete con la federazione delle identità per i carichi di lavoro per GKE.
• L'attivazione dell'applicazione dei criteri di rete aumenta l'impronta in memoria del processo kube-system di circa 128 MB e richiede circa 300 millicore di CPU. Ciò significa che se attivi 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 per il cluster è attivo un periodo di manutenzione, i nodi non vengono ricreati automaticamente fino al successivo periodo di manutenzione. Se preferisci, puoi eseguire l'upgrade manuale del cluster in qualsiasi momento.
• La dimensione minima del cluster consigliata per eseguire l'applicazione dei criteri di rete è di tre istanze e2-medium.
• I criteri di rete non sono supportati per i cluster i cui nodi sono istanze f1-micro o g1-small, poiché i requisiti delle risorse sono troppo elevati.

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

Attenzione: per impostazione predefinita, l'abilitazione dell'applicazione dei criteri di rete per il cluster abilita anche quella per i nodi del cluster e potrebbe causare un'interruzione per i pod di cui è stato eseguito il deployment manuale. Per ulteriori informazioni, consulta Pod di cui è stato eseguito il deployment manuale non pianificato.

Attivare l'applicazione dei criteri di rete

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

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

L'applicazione dei criteri 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 dei carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, individua 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 scoprire di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni per gli aggiornamenti dei nodi.

Importante: GKE rispetta i criteri 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 variazione. Per applicare manualmente le modifiche ai nodi, utilizza la gcloud CLI per chiamare il comando gcloud container clusters upgrade, passando il flag --cluster-version con la stessa versione GKE in cui è già in esecuzione il pool di nodi.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Per abilitare l'applicazione dei criteri di rete quando crei un nuovo cluster, esegui il seguente comando:

   gcloud container clusters create CLUSTER_NAME --enable-network-policy
   

   Sostituisci CLUSTER_NAME con il nome del nuovo cluster.

   Per abilitare l'applicazione dei criteri di rete per un cluster esistente, esegui le seguenti attività:

   1. Esegui il comando seguente per attivare il componente aggiuntivo:

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED
      

      Sostituisci CLUSTER_NAME con il nome del cluster.

   2. Esegui il seguente comando per abilitare l'applicazione dei criteri di rete sul tuo cluster, che a sua volta ricrea i pool di nodi del cluster con l'applicazione dei criteri di rete abilitata:

      gcloud container clusters update CLUSTER_NAME --enable-network-policy
      

Console

Per abilitare l'applicazione dei criteri di rete quando crei un nuovo cluster:

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

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Nella finestra di dialogo Crea cluster, per GKE Standard, fai clic su Configura.

4. Configura il cluster come scelto.

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

6. Seleziona la casella di controllo Attiva criterio di rete.

7. Fai clic su Crea.

Per abilitare l'applicazione dei criteri di rete per un cluster esistente:

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

   Vai a Google Kubernetes Engine

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

3. In Networking, nel campo Criterio di rete, fai clic su Modifica criterio di rete.

4. Seleziona la casella di controllo Abilita criterio di rete per il master e fai clic su Salva modifiche.

5. Attendi l'applicazione delle modifiche e fai nuovamente clic su Modifica criterio di rete.

6. Seleziona la casella di controllo Abilita criterio di rete per i nodi.

7. Fai clic su Salva modifiche.

API

Per abilitare l'applicazione dei criteri di rete, svolgi i seguenti passaggi:

1. Specifica l'oggetto networkPolicy all'interno dell'oggetto cluster da fornire a projects.zones.clusters.create o projects.zones.clusters.update.

2. L'oggetto networkPolicy richiede un enum che specifica quale fornitore di criteri di rete utilizzare e un valore booleano che specifica se attivare o meno i criteri di rete. Se attivi il criterio di rete, ma non imposti il provider, i comandi create e update restituiscono un errore.

Disattivare l'applicazione dei criteri di rete in un cluster standard

Puoi disattivare l'applicazione dei criteri di rete utilizzando la 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 dei carichi di lavoro in esecuzione. Per informazioni dettagliate su questa modifica specifica, individua 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 scoprire di più sugli aggiornamenti dei nodi, consulta Pianificare le interruzioni per gli aggiornamenti dei nodi.

Importante: GKE rispetta i criteri 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 variazione. Per applicare manualmente le modifiche ai nodi, utilizza la gcloud CLI per chiamare il comando gcloud container clusters upgrade, passando il flag --cluster-version con la stessa versione GKE in cui è già in esecuzione il pool di nodi.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Per disattivare l'applicazione dei criteri di rete, svolgi le seguenti attività:

   1. Disattiva l'applicazione dei criteri di rete sul cluster:

   gcloud container clusters update CLUSTER_NAME --no-enable-network-policy
   

   Sostituisci CLUSTER_NAME con il nome del cluster.

   Dopo aver eseguito questo comando, GKE ricrea i pool di nodi del cluster con l'applicazione dei criteri di rete disattivata.

3. Verifica che tutti i nodi siano stati ricreati:

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

   Se l'operazione è riuscita, l'output è simile al seguente:

   No resources found
   

   Se l'output è simile al seguente, devi attendere che GKE completi l'aggiornamento dei pool di nodi:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Quando disattivi l'applicazione dei criteri di rete, GKE potrebbe non aggiornare immediatamente i nodi se il cluster ha una periodo di manutenzione o un'esclusione configurata. Per ulteriori informazioni, consulta Aggiornamento lento del cluster.

4. Dopo aver ricreato tutti i nodi, disattiva il componente aggiuntivo:

   gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED
   

Console

Per disabilitare l'applicazione dei criteri di rete per un cluster esistente, esegui questi passaggi:

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

   Vai a Google Kubernetes Engine

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

3. In Networking, nel campo Criterio di rete, fai clic su Modifica criterio di rete.

4. Deseleziona la casella di controllo Abilita criterio di rete per i nodi e fai clic su Salva modifiche.

5. Attendi l'applicazione delle modifiche e fai nuovamente clic su Modifica criterio di rete.

6. Deseleziona la casella di controllo Abilita criterio di rete per il master.

7. Fai clic su Salva modifiche.

API

Per disabilitare l'applicazione dei criteri di rete per un cluster esistente, segui questi passaggi:

1. Aggiorna il cluster in modo che utilizzi networkPolicy.enabled: false utilizzando l'API setNetworkPolicy.

2. Verifica che tutti i nodi siano stati ricreati utilizzando gcloud CLI:

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

   Se l'operazione è riuscita, l'output è simile al seguente:

   No resources found
   

   Se l'output è simile al seguente, devi attendere che GKE completi l'aggiornamento dei pool di nodi:

   NAME                                             STATUS                     ROLES    AGE     VERSION
   gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
   gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600
   

   Quando disattivi l'applicazione dei criteri di rete, GKE potrebbe non aggiornare immediatamente i nodi se il cluster ha una periodo di manutenzione o un'esclusione configurata. Per ulteriori informazioni, consulta Aggiornamento lento del cluster.

3. Aggiorna il cluster in modo da utilizzare update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true tramite l'API updateCluster.

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 della documentazione di Kubernetes:

• Panoramica dei criteri di rete
• Dichiara il criterio di rete

Criteri di rete e Workload Identity Federation per GKE

Se utilizzi i criteri di rete con la federazione delle identità per i carichi di lavoro per GKE, devi consentire l'uscita ai 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 su 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 su 127.0.0.1/32 sulla porta 988.
• Per i cluster che eseguono GKE Dataplane V2, consenti l'uscita su 169.254.169.254/32 sulla porta 80.

Se non consenti l'uscita verso questi indirizzi IP e queste 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, tieni presente le seguenti limitazioni:

• Non puoi utilizzare un indirizzo IP di un pod o di un servizio nel campo ipBlock.cidr di un NetworkPolicy manifest. Devi fare riferimento ai carichi di lavoro 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 Ingress viene applicato a un servizio per creare un bilanciatore del carico delle applicazioni, devi configurare il criterio di rete applicato ai pod dietro quel servizio per consentire gli intervalli IP 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, il criterio di rete deve consentire anche le connessioni da altri indirizzi IP del nodo nel cluster.

Inclusione di intervalli IP del pod nelle regole ipBlock

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

Le sezioni seguenti descrivono in che modo le diverse implementazioni di NetworkPolicy in GKE valutano gli intervalli di indirizzi IP specificati nel campo ipBlock.cidr e in che modo ciò potrebbe influire sugli intervalli di indirizzi IP dei pod che sono intrinsecamente inclusi in intervalli CIDR ampi. 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 in GKE Dataplane V2, il traffico dei pod non è mai coperto da una regola ipBlock. Pertanto, anche se definisci una regola generica come cidr: '0.0.0.0/0', il traffico dei pod non verrà incluso. Questo è utile perché 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 i pod esplicitamente utilizzando un selettore di pod o spazio dei nomi aggiuntivo nelle definizioni delle regole di ingresso o di 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 del pod del cluster, come nell'esempio seguente:

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 del pod del cluster, ad esempio 10.95.0.0/17. Se hai più intervalli IP, puoi includerli singolarmente nell'array, ad esempio ['10.95.0.0/17', '10.108.128.0/17'].

Risoluzione dei problemi

I pod non riescono a comunicare con il piano di controllo nei cluster che utilizzano Private Service Connect

I pod sui cluster GKE che utilizzano Private Service Connect potrebbero avere un problema di comunicazione con il control plane se l'uscita del pod per l'indirizzo IP interno del control plane è limitata nei criteri di rete di uscita.

Per ridurre il problema:

1. Verifica che il tuo 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 piano di controllo un indirizzo IP interno dai valori definiti in master-ipv4-cidr. In caso contrario, GKE utilizza la subnet del nodo del cluster per assegnare a ogni piano di controllo un indirizzo IP interno.

2. Configura il criterio di uscita del cluster per consentire il traffico all'indirizzo IP interno del piano di controllo.

   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, fai clic sul cluster di cui vuoi trovare l'indirizzo IP interno in Cluster.

   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 all'indirizzo IP interno del piano di controllo. Per ulteriori informazioni, vedi Creare un criterio di rete.

Aggiornamento lento del cluster

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

Puoi eseguire manualmente l'upgrade di un pool di nodi impostando il flag --cluster-version sulla stessa versione GKE in cui è in esecuzione il piano di controllo. Per eseguire questa operazione, devi utilizzare Google Cloud CLI. Per ulteriori informazioni, consulta le limitazioni relative alle finestre di manutenzione.

Pod di cui è stato eseguito il deployment manuale non pianificati

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

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

Se hai configurato un periodo di manutenzione o un'esclusione, questo potrebbe causare 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

Criterio di rete non applicato

Se un criterio NetworkPolicy non viene applicato, puoi risolvere il problema svolgendo i seguenti passaggi:

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

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

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

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

   Se nel cluster non è abilitato GKE Dataplane V2, esegui il seguente comando:

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

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

2. Controlla le etichette del 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 del criterio corrispondano a quelle del 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 è stato creato alcun NetworkPolicy nello spazio dei nomi e nessuno 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 il criterio di rete Calico abilitato potrebbero riscontrare un problema per cui un pod StatefulSet perde 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 Calico 4710.

Questo problema riguarda 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 attenuare il problema, esegui l'upgrade del piano di controllo 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

Il pod è bloccato nello stato containerCreating

In alcuni casi, i cluster GKE con il criterio di rete Calico attivato potrebbero riscontrare un problema in 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 attenuare il problema, utilizza ipam host-local per Calico anziché calico-ipam nei cluster GKE.

Passaggi successivi

• Segui il tutorial relativo ai criteri della rete.

• Leggi la documentazione di Kubernetes sui criteri di rete.

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

• Utilizzare il logging dei criteri di rete.

• Utilizza gli approfondimenti sulla sicurezza per esplorare altri modi per rafforzare la tua infrastruttura.