Controlla 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 del nome di dominio completo (FQDN). Per maggiori informazioni, consulta Controllare la comunicazione tra pod e servizi utilizzando nomi di dominio completi.

Informazioni sull'applicazione dei criteri di rete GKE

L'applicazione dei criteri di rete consente di creare criteri di rete Kubernetes nel cluster. 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 del criterio di rete consente di abilitare elementi come la difesa in profondità quando il cluster gestisce un'applicazione multilivello. Ad esempio, puoi creare un criterio di rete per garantire che un servizio front-end compromesso nella tua applicazione non possa comunicare direttamente con un servizio di fatturazione o contabilità in diversi livelli.

Il criterio di rete può anche semplificare l'hosting simultaneo dei dati di più utenti da parte dell'applicazione. Ad esempio, per garantire la sicurezza multi-tenancy, puoi definire un modello tenant per spazio dei nomi. In un modello di questo tipo, le regole dei criteri di rete possono garantire che pod e 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 forzata dei criteri di rete funzioni correttamente, GKE esegue il deployment dei pod nei nodi che hanno autorizzazioni RBAC elevate, come la capacità di applicare le patch a tutti i deployment e aggiornare lo stato dei nodi. Queste autorizzazioni sono necessarie affinché GKE possa applicare i criteri di rete in base alla configurazione.

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à, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Requisiti e limitazioni

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

• Devi consentire il traffico in uscita al server dei metadati.
• Se specifichi un campo endPort in un criterio di rete su un cluster in cui è abilitato GKE Dataplane V2, questo potrebbe non avere effetto a partire dalla versione 1.22 di GKE. Per maggiori 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 il traffico in uscita verso il server dei metadati se utilizzi il criterio di rete con Workload Identity Federation per GKE.
• L'abilitazione dell'applicazione dei criteri di rete aumenta l'ingombro 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, potrebbe essere necessario aumentare le dimensioni del cluster per continuare a eseguire i carichi di lavoro pianificati.
• L'abilitazione dell'applicazione dei criteri di rete richiede la nuova creazione 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 l'upgrade manuale del cluster in qualsiasi momento.
• La dimensione minima del cluster consigliata per l'esecuzione dell'applicazione dei criteri di rete è di tre istanze e2-medium.
• Il criterio di rete non è supportato per i cluster i cui nodi sono istanze f1-micro o g1-small, perché i requisiti delle risorse sono troppo elevati.

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

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

Abilita l'applicazione dei criteri di rete

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

Puoi abilitare l'applicazione dei criteri di rete in Standard utilizzando 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.

Nota: se abiliti o disabiliti l'applicazione dei criteri di rete per un cluster esistente, GKE ricrea automaticamente tutte le configurazioni dei pool di nodi del cluster prima che il cluster possa eseguire il processo dei criteri di rete. Per maggiori informazioni, consulta Avvertenze e limitazioni.

gcloud

1. Nella console Google Cloud, attiva Cloud Shell.

   Attiva Cloud Shell

   Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

2. Per abilitare l'applicazione dei criteri di rete durante la creazione di un nuovo cluster, esegui questo 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 queste attività:

   1. Esegui questo comando per abilitare il componente aggiuntivo:

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

      Sostituisci CLUSTER_NAME con il nome del cluster.

   2. Esegui questo 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 preferisci.

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, poi fai di nuovo 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, segui questi passaggi:

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

2. L'oggetto networkPolicy richiede un'enumerazione che specifichi il provider di criteri di rete da utilizzare e un valore booleano che specifica se abilitare il criterio di rete. Se abiliti il criterio di rete ma non imposti il provider, i comandi create e update restituiscono un errore.

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

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

Avviso: la disattivazione dell'applicazione dei criteri di rete è un'operazione problematica. Tutti i nodi cluster vengono ricreati in base al processo di upgrade dei nodi di GKE.

gcloud

1. Nella console Google Cloud, attiva Cloud Shell.

   Attiva Cloud Shell

   Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

2. Per disattivare l'applicazione dei criteri di rete, esegui queste attività:

   1. Disabilita l'applicazione dei criteri di rete sul tuo 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 disabilitata.

3. Verifica che tutti i nodi siano stati ricreati:

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

   Se l'operazione ha esito positivo, 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 disabiliti 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 maggiori informazioni, consulta L'aggiornamento del cluster è lento.

4. Dopo aver ricreato tutti i nodi, disabilita 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, poi fai di nuovo 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:

1. Aggiorna il cluster per utilizzare networkPolicy.enabled: false mediante 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 ha esito positivo, 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 disabiliti 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 maggiori informazioni, consulta L'aggiornamento del cluster è lento.

3. Aggiorna il cluster per utilizzare update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true con 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, vedi i seguenti argomenti nella documentazione di Kubernetes:

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

Criterio di rete e federazione di Workload Identity per GKE

Se utilizzi il criterio di rete con la federazione di Workload Identity per GKE, devi consentire il traffico in uscita verso i seguenti indirizzi IP in modo che i pod possano comunicare con il server di metadati GKE.

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

Se non consenti il traffico in 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, 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 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 file manifest NetworkPolicy. Se specifichi un protocollo, devi indicare anche una porta. Ad esempio, la seguente configurazione non è valida:

  ingress:
  - ports:
    - protocol: TCP
  

Utilizzo dei bilanciatori del carico delle applicazioni

Quando viene applicata una risorsa Ingress a un servizio per creare un bilanciatore del carico delle applicazioni, devi configurare il criterio di rete applicato ai pod su cui si basa il servizio per consentire gli intervalli IP appropriati per il controllo di integrità del bilanciatore del carico delle applicazioni. 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 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 il criterio externalTrafficPolicy non è impostato su Local, il criterio di rete deve consentire anche le connessioni da altri IP dei nodi nel cluster.

Inclusione di intervalli IP di pod nelle regole ipBlock

Per controllare il traffico di 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 in entrata o in uscita di NetworkPolicy. Non utilizzare il campo ipBlock.cidr per selezionare intenzionalmente intervalli di indirizzi IP del pod, che sono di natura temporanea. Il progetto Kubernetes non definisce esplicitamente il comportamento del campo ipBlock.cidr quando include intervalli di indirizzi IP dei pod. La specifica di ampi intervalli CIDR in questo campo, come 0.0.0.0/0 (che includono gli intervalli di indirizzi IP del 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 come ciò potrebbero influire sugli intervalli di indirizzi IP dei pod inclusi intrinsecamente in ampi intervalli CIDR. Comprendere il diverso comportamento delle implementazioni ti aiuterà a prepararti ai risultati quando migrate a un'altra implementazione.

Comportamento ipBlock in GKE Dataplane V2

Con l'implementazione di NetworkPolicy in GKE Dataplane V2, il traffico tra i pod non è mai coperto da una regola ipBlock. Di conseguenza, anche se definisci una regola generica come cidr: '0.0.0.0/0', non includerà il traffico dei pod. Questo è utile perché consente, ad esempio, di consentire ai pod in uno spazio dei nomi di ricevere il traffico da internet, senza consentire anche il traffico dai pod. Per includere anche il traffico dei pod, seleziona i pod in modo esplicito utilizzando un pod o un selettore dello spazio dei nomi aggiuntivo nelle definizioni delle regole in entrata o in uscita di NetworkPolicy.

Comportamento di ipBlock in Calico

Per l'implementazione di Calico di NetworkPolicy, le regole ipBlock coprono il traffico dei pod. Con questa implementazione, per configurare un ampio intervallo CIDR senza consentire il traffico dei pod, escludi in modo esplicito l'intervallo CIDR dei 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 dei pod del tuo cluster, ad esempio 10.95.0.0/17. Se disponi di più intervalli IP, possono essere inclusi singolarmente nell'array, ad esempio ['10.95.0.0/17', '10.108.128.0/17'].

Risoluzione dei problemi

I pod non possono comunicare con il piano di controllo 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 piano di controllo se il traffico in uscita del pod verso l'indirizzo IP interno del piano di controllo è limitato nei criteri di rete in uscita.

Per limitare il problema:

1. Scopri se il cluster utilizza Private Service Connect. Per ulteriori informazioni, consulta Cluster pubblici con Private Service Connect. Sui cluster che utilizzano Private Service Connect, ogni piano di controllo viene assegnato a un indirizzo IP interno dalla subnet del nodo cluster.

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

   Per trovare l'indirizzo IP interno del piano di controllo:

   gcloud

   Per cercare privateEndpoint, esegui questo comando:

   gcloud container clusters describe CLUSTER_NAME
   

   Sostituisci CLUSTER_NAME con il nome del cluster.

   Questo comando recupera l'oggetto 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.

   Quando riesci a individuare privateEndpoint o Internal endpoint, configura il criterio in uscita del cluster per consentire il traffico all'indirizzo IP interno del piano di controllo. Per ulteriori informazioni, 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 per il cluster è stata configurata una finestra di manutenzione o un'esclusione.

Puoi eseguire manualmente l'upgrade di un pool di nodi impostando il flag --cluster-version sulla stessa versione GKE in esecuzione dal piano di controllo. Per eseguire questa operazione devi utilizzare Google Cloud CLI. Per ulteriori informazioni, consulta la sezione Avvertenze per i periodi di manutenzione.

Pod di cui è stato eseguito il deployment manuale non pianificati

Quando abiliti l'applicazione dei criteri di rete sul piano di controllo del cluster esistente, GKE annulla la pianificazione di tutti i pod di agente ip-masquerade o nodo calico di cui hai eseguito il deployment manuale.

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

Se hai configurato un periodo di manutenzione o un'esclusione, questa operazione 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

Il criterio di rete non viene applicato

Se un criterio di rete non viene applicato, puoi risolvere i problemi seguendo questi passaggi:

1. Verifica che l'applicazione dei criteri di rete sia abilitata. Il comando da utilizzare dipende dall'abilitazione o meno di GKE Dataplane V2 nel cluster.

   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 nel cluster non è abilitato GKE Dataplane V2, esegui questo 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. Conferma che le etichette nel criterio corrispondano alle etichette nel 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 esistono criteri di rete che selezionano i carichi di lavoro:

   kubectl get networkpolicy
   

   Se l'output è vuoto, non è stato creato alcun NetworkPolicy nello spazio dei nomi e non è necessario selezionare i carichi di lavoro. Se l'output non è vuoto, controlla se il criterio seleziona i 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 in cui è abilitato il criterio di rete Calico potrebbero riscontrare un problema per cui un pod StatefulSet elimina le connessioni esistenti quando il pod 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 maggiori informazioni su questo problema, consulta il problema di Calico n. 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 limitare questo 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

Pod bloccato nello stato containerCreating

Può verificarsi uno scenario in cui i cluster GKE in cui è abilitato il criterio di rete Calico 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 mitigare questo problema, utilizza ipam locale dell'host 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.

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

• Utilizzo del logging dei criteri di rete.

• Utilizza gli insight sulla sicurezza per esplorare altri modi per proteggere la tua infrastruttura.