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

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

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

Informazioni sull'applicazione delle policy di rete GKE

L'applicazione delle policy di rete ti consente di creare policy di rete Kubernetes nel tuo cluster. Per impostazione predefinita, tutti i pod all'interno di un cluster possono comunicare liberamente tra loro. 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 di una policy di rete ti aiuta ad abilitare elementi come la difesa in profondità quando il tuo cluster gestisce un'applicazione multilivello. Ad esempio, puoi creare una policy di rete per assicurarti che un servizio di frontend compromesso nella tua applicazione non possa comunicare direttamente con un servizio di fatturazione o contabilità a diversi livelli di profondità.

I criteri di rete possono anche semplificare l'hosting dei dati di più utenti contemporaneamente per la tua applicazione. Ad esempio, puoi fornire il multi-tenancy sicuro definendo un modello tenant per spazio dei nomi. In un modello di questo tipo, le regole delle policy di rete possono contribuire a 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.

Plug-in NetworkPolicy in GKE

Il criterio di rete richiede un plug-in di rete per implementare l'applicazione. GKE dispone dei seguenti plug-in di rete reciprocamente esclusivi:

  • GKE Dataplane V2, che si basa su Cilium. GKE Dataplane V2 è il plug-in di rete consigliato per tutti i cluster ed è l'impostazione predefinita per i cluster Autopilot.
  • Il plug-in della policy di rete Calico, disponibile solo nei cluster Standard.

Se un cluster non è configurato con un plug-in di rete gestito, è necessario un plug-in autogestito per applicare il criterio di rete. Se non è configurato alcun plug-in di rete, le norme di rete non vengono applicate.

Se non utilizzi un plug-in di rete per applicare i criteri di rete, ti consigliamo di rimuovere tutti i criteri di rete dal cluster. Questi criteri di rete potrebbero causare restrizioni del traffico impreviste se in seguito installi un plug-in di rete che applica i criteri di rete.

Se un plug-in di rete gestito da GKE non è configurato e nel cluster è presente un oggetto criteri di rete, GKE fornisce un consiglio che ti informa che i criteri potrebbero non essere applicati.

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
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
* Assicurati di avere un cluster Autopilot o Standard esistente. Se non ne hai uno, crea un cluster Autopilot.

Requisiti e limitazioni

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

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

  • Devi consentire l'uscita al server metadati se utilizzi il criterio di rete con Workload Identity Federation for GKE.
  • L'attivazione dell'applicazione delle policy di rete aumenta il footprint della memoria del processo kube-system di circa 128 MB e richiede circa 300 millicore di CPU. Ciò significa che se abiliti le policy 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 delle policy di rete richiede la ricreazione dei nodi. Se il cluster ha un periodo di manutenzione attivo, 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 richiesta del cluster per l'applicazione dei criteri di rete è tre istanze e2-medium o un'istanza di tipo di macchina con più di 1 vCPU allocabile. Per maggiori dettagli, vedi Problemi noti di GKE.
  • La policy di rete non è supportata per i cluster i cui nodi sono istanze f1-micro o g1-small, poiché i requisiti delle risorse sono troppo elevati.

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

Le seguenti limitazioni sono pertinenti ai pod che utilizzano l'impostazione hostNetwork: true:

  • Un campo podSelector vuoto in una NetworkPolicy seleziona tutti i pod in quello spazio dei nomi, ad eccezione dei pod con l'impostazione hostNetwork: true.

  • Nei cluster che utilizzano GKE Dataplane V2, non puoi utilizzare nessuno dei seguenti campi per identificare il traffico da o verso i pod che utilizzano l'impostazione hostNetwork: true:

    • ingress[].from[].podSelector
    • ingress[].from[].namespaceSelector
    • egress[].to[].namespaceSelector
    • egress[].to[].podSelector
    • ingress[].from[].ipBlock
    • egress[].to[].ipBlock

  • Nei cluster che utilizzano il dataplane legacy, puoi utilizzare solo i campi ingress[].from[].ipBlock e egress[].to[].ipBlock per identificare il traffico da o verso i pod che utilizzano l'impostazione hostNetwork: true. Non puoi utilizzare nessuno dei seguenti campi per identificare il traffico:

    • ingress[].from[].podSelector
    • ingress[].from[].namespaceSelector
    • egress[].to[].namespaceSelector
    • egress[].to[].podSelector

Abilita l'applicazione delle policy di rete

Se utilizzi GKE Dataplane V2 nel tuo cluster, vai a Crea una policy di rete.

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

Prima di procedere: le policy di rete verranno applicate quando i nodi verranno ricreati.

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 e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per abilitare l'applicazione dei criteri di rete sul cluster, 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 cluster.

    2. Esegui questo comando per abilitare l'applicazione delle policy di rete nel tuo cluster, che a sua volta ricrea i pool di nodi del cluster con l'applicazione delle policy di rete abilitata:

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

Console

Per abilitare l'applicazione dei criteri di rete sul cluster:

  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 del cluster, nel campo Policy di rete di Calico Kubernetes, fai clic su Modifica policy di rete.

  4. Nella finestra di dialogo Modifica policy di rete, seleziona la casella di controllo Abilita policy di rete di Calico Kubernetes per il control plane e fai clic su Salva modifiche.

  5. Attendi che le modifiche vengano applicate. Per monitorare l'avanzamento, fai clic su Notifiche nell'angolo in alto a destra della console.

  6. Nel campo Policy di rete di Calico Kubernetes, fai di nuovo clic su Modifica policy di rete.

  7. Nella finestra di dialogo Modifica criterio di rete, seleziona la casella di controllo Abilita criterio di rete di Calico Kubernetes per i nodi.

  8. Fai clic su Salva modifiche.

API

Per abilitare l'applicazione dei criteri di rete:

  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 enum che specifica quale provider di policy di rete utilizzare e un valore booleano che specifica se attivare la policy di rete. Se abiliti la policy di rete ma non imposti il provider, i comandi create e update restituiscono un errore.

Disabilita l'applicazione delle policy di rete in un cluster Standard

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

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

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 e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installata e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

  2. Per disabilitare l'applicazione delle policy di rete, esegui queste attività:

    1. Disabilita 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 node pool del cluster con l'applicazione delle policy 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 termini 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 delle policy di rete, GKE potrebbe non aggiornare immediatamente i nodi se nel cluster è configurato un periodo di manutenzione o un'esclusione. Per saperne di più, vedi 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 policy di rete, fai clic su Modifica policy di rete.

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

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

  6. Deseleziona la casella di controllo Abilita policy 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 questi passaggi:

  1. Aggiorna il cluster per utilizzare 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 ha esito positivo, l'output è simile al seguente:

    No resources found

    Se l'output è simile al seguente, devi attendere che GKE termini 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 un periodo di manutenzione o un'esclusione configurati. Per saperne di più, vedi Aggiornamento lento del cluster.

  3. Aggiorna il cluster per utilizzare update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true utilizzando l'API updateCluster.

Crea una policy di rete

Puoi creare una policy di rete utilizzando l'API Kubernetes Network Policy.

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

Policy di rete e Workload Identity Federation for GKE

Se utilizzi la policy di rete con Workload Identity Federation for 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 l'uscita a 169.254.169.252/32 sulle porte 988 e 987.
  • 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 sulle porte 988 e 987.
  • Per i cluster che eseguono GKE Dataplane V2, consenti l'uscita verso 169.254.169.254/32 sulle porte 80 e 8080.

Se non consenti il traffico in uscita verso questi indirizzi IP e porte, potresti riscontrare interruzioni durante gli upgrade automatici.

Migrazione da Calico a GKE Dataplane V2

Se esegui la migrazione delle policy di rete da Calico a GKE Dataplane V2, tieni presente le seguenti limitazioni:

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

    - ipBlock:
    cidr: 10.8.0.6/32

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

    ingress:
- ports:
  - protocol: TCP

Utilizzo dei bilanciatori del carico delle applicazioni

Quando un ingresso viene applicato a un servizio per creare un bilanciatore del carico HTTP(S), devi assicurarti che la tua policy di rete consenta il traffico dagli intervalli di indirizzi IP del controllo di integrità del bilanciatore del carico delle applicazioni HTTP(S).

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

Il bilanciamento del carico nativo del container, abilitato per impostazione predefinita in tutti i cluster GKE, instrada il traffico direttamente agli endpoint dei pod. Per raggiungere questo obiettivo, i servizi GKE vengono annotati automaticamente con cloud.google.com/neg: '{"ingress": true}'. Tuttavia, l'attivazione della policy di rete GKE è una delle condizioni specifiche che impedisce l'attivazione del bilanciamento del carico nativo del container per impostazione predefinita. Per mantenere i vantaggi del bilanciamento del carico nativo del container durante l'utilizzo delle policy di rete, devi applicare manualmente la seguente annotazione ai manifest del servizio:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

Per l'elenco completo delle condizioni di attivazione predefinite, consulta Bilanciamento del carico nativo dei container.

Inclusione degli intervalli IP di pod nelle regole ipBlock

Per controllare il traffico per pod specifici, seleziona sempre i pod in base allo spazio dei nomi o alle etichette dei pod utilizzando i campi namespaceSelector e podSelector nelle regole di ingresso o uscita di NetworkPolicy. Non utilizzare il campo ipBlock.cidr per selezionare intenzionalmente intervalli di indirizzi IP dei pod, che sono temporanei per natura. Il progetto Kubernetes non definisce in modo esplicito il comportamento del campo ipBlock.cidr quando include intervalli di indirizzi IP dei pod. Se in questo campo specifichi intervalli CIDR ampi, come 0.0.0.0/0 (che includono gli intervalli di indirizzi IP dei pod), potresti ottenere risultati imprevisti in diverse implementazioni 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ò potrebbe influire sugli intervalli di indirizzi IP dei pod intrinsecamente inclusi in ampi intervalli CIDR. Comprendere il diverso comportamento tra le implementazioni ti aiuterà a prepararti per i risultati quando migrate a un'altra implementazione.

Comportamento di ipBlock in GKE Dataplane V2

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

Comportamento di ipBlock in Calico

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

Controlla il comportamento della policy di rete con externalTrafficPolicy

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

externalTrafficPolicy ha due valori possibili:

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

  • Local: quando externalTrafficPolicy è impostato su Local, il pod vede l'indirizzo IP di origine come l'indirizzo IP client originale. In questo modo, è possibile un controllo più granulare con le policy di rete, poiché puoi definire regole basate sugli indirizzi IP client effettivi.

Risoluzione dei problemi

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

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

Per risolvere il problema:

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

  2. Configura la policy in uscita del cluster per consentire il traffico verso l'indirizzo IP interno del control plane.

    Per trovare l'indirizzo IP interno del control plane:

    gcloud

    Per cercare privateEndpoint, esegui questo comando:

    gcloud container clusters describe CLUSTER_NAME

    Sostituisci CLUSTER_NAME con il nome del cluster.

    Questo comando recupera privateEndpoint del cluster specificato.

    Console

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

      Vai a Google Kubernetes Engine

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

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

    Una volta individuato privateEndpoint o Internal endpoint, configura la policy di uscita del cluster in modo da consentire il traffico verso l'indirizzo IP interno del control plane. Per saperne di più, consulta Crea una policy di rete.

Aggiornamento del cluster lento

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

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

Pod di cui è stato eseguito il deployment manualmente non pianificati

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

GKE non ripianifica questi pod finché l'applicazione delle policy 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, potrebbe verificarsi un'interruzione prolungata.

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

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

La policy di rete non viene applicata

Se un NetworkPolicy non ha effetto, puoi risolvere il problema seguendo questi passaggi:

  1. Verifica che l'applicazione delle policy di rete sia abilitata. Il comando che utilizzi dipende dal fatto che nel cluster sia abilitato GKE Dataplane V2.

    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 delle policy di rete non è abilitata.

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

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

    Se l'output è vuoto, l'applicazione delle policy di rete non è abilitata.

  2. Controlla le etichette dei pod:

    kubectl describe pod POD_NAME

    Sostituisci POD_NAME con il nome del pod.

    L'output è simile al seguente:

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

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

    kubectl describe networkpolicy

    L'output è simile al seguente:

    PodSelector: app=store

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

  4. Controlla se sono presenti policy di rete che selezionano i tuoi workload:

    kubectl get networkpolicy

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

    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

Pod bloccato nello stato containerCreating

Può verificarsi uno scenario in cui i cluster GKE con la policy di rete Calico abilitata potrebbero riscontrare un problema per cui i pod rimangono bloccati nello stato containerCreating.

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

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

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

Errori 503 del probe di idoneità Calico in cluster di grandi dimensioni

Nei cluster di grandi dimensioni che eseguono molte operazioni di scalabilità automatica, Calico potrebbe riavviarsi con una frequenza tale da causare interruzioni. In alcune situazioni, potresti voler desensibilizzare il suo autoscaler verticale con valori più elevati per il campo step.

Per modificare i valori, modifica il ConfigMap calico-node-vertical-autoscaler in modo da utilizzare gli stessi valori dei parametri per i campi base e max. Questo approccio disattiva le richieste di risorse CPU dinamiche, interrompendo le richieste di CPU fluttuanti con l'abbandono dei nodi:

kind: ConfigMap
apiVersion: v1
metadata:
  name: calico-node-vertical-autoscaler
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: EnsureExists
data:
  node-autoscaler: |-
    {
      "calico-node": {
        "requests": {
          "cpu": {
            "base": "200m",
            "step": "100m",
            "nodesPerStep": 50,
            "max": "200m"
          }
        }
      }
    }

L'impostazione del valore del campo base (200m) su un valore superiore a quello del campo step (100m) contribuisce a garantire che i pod calico-node dispongano di risorse CPU sufficienti per cluster fino a 60 nodi, in base alla formula del gestore della scalabilità automatica, perché la CPU richiesta non verrà più scalata in base al numero di nodi.

Passaggi successivi