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

Autopilot Standard

---

Questa pagina spiega come controllare la comunicazione tra i pod del cluster I servizi che utilizzano 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, vedi Controlla la comunicazione tra pod e servizi utilizzando i nomi di dominio completi.

Informazioni sull'applicazione dei criteri di rete di GKE

L'applicazione dei criteri di rete consente di creare Norme nel tuo cluster. Per impostazione predefinita, tutti i pod all'interno di un cluster possono comunicare altri 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 consente di attivare funzionalità quali 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 nel tuo un'applicazione non può comunicare direttamente con un servizio di fatturazione di diversi livelli verso il basso.

Il criterio di rete può inoltre semplificare l'hosting dei dati da parte dell'applicazione a più utenti contemporaneamente. Ad esempio, puoi offrire un ambiente multi-tenancy sicuro 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 necessaria per consentire a GKE di applicare i criteri di rete in base configurazione.

Prima di iniziare

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

• 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 gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: 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 con GKE Dataplane V2 è abilitato, potrebbe non avere effetto a partire dal GKE versione 1.22. 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 cluster:

• Devi consentire il traffico in uscita verso il server dei metadati se utilizzi il criterio di rete con Federazione delle identità dei 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 abiliti i criteri di rete per un potrebbe essere necessario aumenta 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 il cluster ha un'istanza 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 è tre istanze e2-medium.
• Il criterio di rete non è supportato per i cluster i cui nodi sono f1-micro o g1-small istanze, perché i requisiti delle risorse sono troppo elevati.

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

Attenzione :per impostazione predefinita, anche l'abilitazione dei criteri di rete per il cluster abilita l'applicazione forzata per i nodi del cluster e potrebbe causare un'interruzione di cui è stato eseguito il deployment manuale. Per ulteriori informazioni, vedi 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 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 forzata dei criteri di rete è integrata 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 seguente comando:

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

   Sostituisci CLUSTER_NAME con il nome del nuovo in un cluster Kubernetes.

   Per abilitare l'applicazione dei criteri di rete per un cluster esistente, esegui le seguenti 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 in un cluster Kubernetes.

   2. Esegui questo comando per abilitare l'applicazione dei criteri di rete sul tuo 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 in base alle tue preferenze.

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, segui questi passaggi:

1. Specifica l'oggetto networkPolicy all'interno dell'oggetto cluster che 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 i criteri 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 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 invasiva. Tutti nodi cluster ricreati secondo i modelli GKE processo di upgrade dei 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 disabilitare 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 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 ha esito positivo, l'output è simile al seguente:

   No resources found
   

   Se l'output è simile al seguente, devi attendere GKE per completare 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, quindi 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, esegui seguenti:

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 ha esito positivo, l'output è simile al seguente:

   No resources found
   

   Se l'output è simile al seguente, devi attendere GKE per completare 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.

3. Aggiorna il cluster per utilizzare update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true utilizzando 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 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 porte, potresti riscontrare e interruzioni durante gli upgrade automatici.

Migrazione da Calico a GKE Dataplane V2

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

• Non puoi utilizzare un indirizzo IP di pod o servizio nel campo ipBlock.cidr di una NetworkPolicy. 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 l'endpoint di rete gruppi, le porte dei nodi per un servizio potrebbero inoltrare le connessioni ai pod ad altri nodi, a meno che non ne venga impedito Da externalTrafficPolicy a Local nella definizione del servizio. Se externalTrafficPolicy non è impostato su Local, anche il criterio di rete deve e consentire connessioni da altri IP dei nodi nel cluster.

Inclusione di intervalli IP di pod nelle regole ipBlock

Per controllare il traffico per pod specifici, seleziona sempre i pod in base al relativo spazio dei nomi o le etichette dei pod utilizzando i campi namespaceSelector e podSelector nel le regole di traffico in entrata o in uscita di NetworkPolicy. Non utilizzare il campo ipBlock.cidr per selezionare intenzionalmente gli 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. Specificare Intervalli CIDR in questo campo, ad esempio 0.0.0.0/0 (che includono l'indirizzo IP del pod) potrebbe avere risultati imprevisti in implementazioni diverse 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 GKE Dataplane V2 di NetworkPolicy, il traffico dei pod non viene mai coperta da una regola ipBlock. Perciò, anche se definisci una regola generica come come cidr: '0.0.0.0/0', non includerà il traffico dei pod. È utile in quanto ti consente, ad esempio, di consentire ai pod in uno spazio dei nomi di ricevere traffico a internet, senza consentire anche il traffico dai pod. Per inoltre includi il traffico dei pod, seleziona i pod in modo esplicito utilizzando un pod o uno spazio dei nomi aggiuntivo nelle definizioni delle regole di traffico in entrata o in 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 ampio intervallo CIDR senza consentire il traffico dei pod, escludere esplicitamente 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 è 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

su cluster GKE che utilizzano Private Service Connect potrebbe si verifichi un problema di comunicazione con il piano di controllo se il traffico in uscita del pod l'indirizzo IP interno del piano di controllo è limitato nei criteri di rete in uscita.

Per limitare il problema:

1. Verifica se il cluster utilizza Private Service Connect. Per maggiori informazioni informazioni, vedi Cluster pubblici con Private Service Connect. Nei 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 all'indirizzo IP interno.

   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'elemento 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 la cui all'indirizzo IP interno che vuoi trovare.

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

   Una volta individuato l'privateEndpoint o il Internal endpoint, configurare il criterio in uscita del cluster per consentire il traffico verso all'indirizzo IP interno. 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, vedi caveat 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 di applicazioni cluster, GKE annulla la pianificazione di qualsiasi agente di mascheramento IP o nodo calico di cui hai eseguito il deployment 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 esclusione, questo potrebbe causare un'interruzione estesa.

Per ridurre al minimo la durata dell'interruzione, puoi assegnare manualmente il valore le etichette seguenti 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 abilitata. Il comando dipende dall'abilitazione 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. Verifica 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 di al 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 criterio NetworkPolicy nello spazio dei nomi. non devi selezionare 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 dei pod StatefulSet con Calico

di cluster GKE Rete Calico l'attivazione di un criterio potrebbe verificarsi un problema per cui un pod StatefulSet elimina quando il pod viene eliminato. Quando un pod è entrato nello stato Terminating, la configurazione di terminationGracePeriodSeconds nella specifica del pod non viene rispettata e causa interruzioni per altre applicazioni che dispongono di 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 mitigare questo problema, esegui l'upgrade del piano di controllo GKE a uno dei le 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 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 rafforzare la protezione dell'infrastruttura.