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

Autopilota 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 l'infrastruttura il traffico in uscita verso qualsiasi endpoint o servizio al di fuori di il cluster utilizzando i criteri di rete del nome di dominio completo (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 l'uno all'altro all'interno del cluster.

La definizione dei criteri di rete è utile per attivare funzionalità quali difesa in profondità quando il cluster gestisce un'applicazione multilivello. 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.

Il criterio di rete può inoltre semplificare l'hosting dei dati da parte dell'applicazione a più utenti contemporaneamente. Ad esempio, puoi fornire una configurazione multi-tenancy sicura definendo un modello tenant per spazio dei nomi. In questo modello, le regole dei criteri di rete può garantire che i pod e i servizi in un determinato spazio dei nomi non possano accedere ad altri pod o Service in uno spazio dei nomi diverso.

Nota: affinché l'applicazione dei criteri di rete funzioni correttamente, GKE esegue il deployment dei pod nei nodi con valori Autorizzazioni RBAC, 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.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con gcloud CLI. Se hai già installato gcloud CLI, scarica 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 ad Autopilot Standard e Standard:

• Devi consentire il traffico in uscita verso il server di 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, vedi 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 alle norme clusters:

• 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'abilitazione dell'applicazione dei criteri di rete aumenta l'utilizzo della memoria kube-system elabora 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.
• Se abiliti l'applicazione dei criteri di rete, è necessario creare nuovamente i nodi. Se per il cluster è attivo un periodo di manutenzione, i nodi non vengono ricreati automaticamente fino al successivo periodo di manutenzione. Se preferisci, eseguire manualmente l'upgrade 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 Autopilot quindi puoi passare direttamente Crea un criterio di rete.

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

L'applicazione dei criteri di rete è integrata in GKE Dataplane V2. Non devi devi abilitare l'applicazione dei criteri di rete nei cluster che usano GKE Dataplane V2.

Nota :se attivi o disattivi l'applicazione dei criteri di rete per un modello esistente in un cluster, GKE ricrea automaticamente configurazioni del pool di nodi prima che il cluster possa eseguire il criterio di rete e il processo di sviluppo. Per ulteriori informazioni, vedi caveat e limitazioni.

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, quindi 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, 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'enumerazione che specifica quale rete provider di criteri da utilizzare e un valore booleano che specifica se abilitare criterio 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 l'interfaccia a riga di comando gcloud, la console Google Cloud o l'API GKE. Non puoi disabilitare dell'applicazione dei criteri di rete in cluster Autopilot o che usano GKE Dataplane V2.

Avviso: la disattivazione dell'applicazione dei criteri di rete è un'operazione che comporta interruzioni. Tutti i nodi del cluster ricreati in base alla procedura di upgrade dei nodi GKE.

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 disabilitare l'applicazione dei criteri di rete, esegui queste 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 il tuo cluster pool di nodi con 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 è 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 disabiliti l'applicazione dei criteri di rete, GKE potrebbe non aggiornare immediatamente i nodi se per il cluster è configurata periodo di manutenzione o esclusione. Per ulteriori informazioni, vedi 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 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 per utilizzare networkPolicy.enabled: false mediante 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 finestra 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 in la documentazione relativa a Kubernetes:

• Panoramica dei criteri di rete
• Dichiarazione del criterio di rete

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

Se utilizzi il criterio 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 Server di metadati GKE.

• Per i cluster che esegue GKE versione 1.21.0-gke.1000 e successive, consente il traffico 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 il traffico in uscita verso 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. Per 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 specificare 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, deve configurare il criterio di rete applicato ai pod dietro quel servizio per consentire l'appropriata Intervalli IP del 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 una 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 IP dei nodi del cluster.

Inclusione di intervalli IP di 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 ipBlock.cidr quando include intervalli di indirizzi IP del 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 seguenti sezioni descrivono le diverse implementazioni NetworkPolicy in GKE valuta gli intervalli di indirizzi IP che nel campo ipBlock.cidr e come questo potrebbe influire sull'indirizzo IP del pod che sono intrinsecamente inclusi in ampi intervalli CIDR. Comprendere il il comportamento diverso tra le implementazioni vi aiuterà a prepararvi alle 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 Calico di NetworkPolicy, le regole ipBlock si comportano per la copertura del 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 è il pod del cluster Intervallo di indirizzi IPv4, 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'].

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 avere un problema di comunicazione con il piano di controllo se l'uscita del pod per l'indirizzo IP interno del piano di controllo è limitata nei criteri di rete di uscita.

Per ridurre il problema:

1. Scopri se il tuo cluster utilizza Private Service Connect. Per maggiori informazioni informazioni, vedi Cluster pubblici con Private Service Connect. Nei cluster che utilizzano Private Service Connect, a ogni piano di controllo viene assegnato un indirizzo IP interno della subnet del nodo del cluster.

2. Configura il criterio in uscita del cluster per consentire il traffico verso la rete all'indirizzo IP interno.

   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 è indicato 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, consulta la sezione Creare una rete. .

Aggiornamento del cluster lento

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

Puoi eseguire manualmente l'upgrade di un pool di nodi impostando il flag --cluster-version alla stessa versione GKE in esecuzione del piano di controllo. Tu devi utilizzare Google Cloud CLI per eseguire questa operazione. Per ulteriori informazioni, consulta i limiti relativi ai periodi 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 ripianifica questi pod fino al criterio di rete l'applicazione forzata è abilitata sui nodi del cluster e questi 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

Il criterio di rete non viene applicato

Se un criterio NetworkPolicy non viene applicato, puoi risolvere i problemi utilizzando il seguenti passaggi:

1. Verifica che l'applicazione dei criteri di rete sia attivata. Il comando dipende dall'abilitazione di GKE Dataplane V2 nel cluster.

   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 è 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 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 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 nessuno seleziona i tuoi carichi di lavoro. Se l'output non è vuoto, controlla che 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 del pod StatefulSet con Calico

di cluster GKE Rete Calico se il criterio viene attivato, potrebbe verificarsi un problema per cui un pod StatefulSet elimina 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 ulteriori informazioni su questo problema, consulta Calico issue #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

Pod bloccato in stato containerCreating

Ci può essere uno scenario in cui i cluster GKE con la rete Calico se il criterio viene attivato, potrebbe verificarsi 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 ridurre il problema, usa un indirizzo IPam locale dell'host 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 insight sulla sicurezza per scoprire altri modi per rafforzare la protezione dell'infrastruttura.