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 dai pod verso qualsiasi endpoint o servizio esterno al 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 nomi di dominio completi.
Informazioni sull'applicazione dei criteri di rete di GKE
L'applicazione dei criteri di rete consente di creare criteri di rete Kubernetes nel 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 dei criteri di rete è utile per abilitare funzionalità come la difesa in profondità quando il cluster gestisce un'applicazione multilivello. Ad esempio, è possibile creare un criterio di rete per garantire che un servizio front-end compromesso nell'applicazione non possa comunicare direttamente con un servizio di fatturazione o di contabilità di diversi livelli.
I criteri di rete possono inoltre semplificare l'hosting simultaneo dei dati di più utenti da parte dell'applicazione. Per offrire un'architettura multi-tenancy sicura, definisci un modello tenant per spazio dei nomi. In questo modello, le regole dei criteri di rete possono garantire che i pod e i servizi in un determinato spazio dei nomi non possano accedere ad altri pod o servizi in uno spazio dei nomi diverso.
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 quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Requisiti e limitazioni
I seguenti requisiti e limitazioni si applicano ai cluster Autopilot e Standard:- Devi consentire il traffico in uscita verso il server di metadati.
- Se specifichi un campo
endPort
in un criterio di rete in un cluster in cui è abilitato GKE Dataplane V2, potrebbe non avere effetto a partire dalla versione 1.22 di GKE. Per maggiori informazioni, vedi Gli intervalli di porte dei criteri di rete non vengono applicati. Per i cluster Autopilot, GKE Dataplane V2 è sempre abilitato.
- Devi consentire il traffico in uscita verso il server dei metadati se utilizzi il criterio di rete con la Federazione delle identità per i carichi di lavoro per GKE.
- L'abilitazione dell'applicazione dei criteri di rete aumenta di circa 128 MB la quantità di memoria del processo
kube-system
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. - Se abiliti l'applicazione dei criteri di rete, è necessario creare nuovamente i nodi. Se per il tuo cluster è attivo un periodo di manutenzione, i nodi non vengono ricreati automaticamente fino al successivo periodo di manutenzione. Se preferisci, puoi eseguire l'upgrade manuale del cluster in qualsiasi momento.
- La dimensione minima consigliata del cluster per eseguire l'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
og1-small
, perché i requisiti delle risorse sono troppo elevati.
Per ulteriori informazioni sui tipi di macchine dei nodi e sulle risorse allocabili, consulta Architettura cluster standard - Nodi.
Abilita l'applicazione dei criteri di rete
L'applicazione dei criteri di rete è abilitata per impostazione predefinita per i cluster Autopilot, quindi puoi passare 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.
gcloud
-
Nella console Google Cloud, 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.
Per abilitare l'applicazione dei criteri di rete quando crei 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à:
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.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:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Fai clic su add_box Crea.
Nella finestra di dialogo Crea cluster, per GKE Standard, fai clic su Configura.
Configura il cluster in base alle tue preferenze.
Nel riquadro di navigazione, in Cluster, fai clic su Networking.
Seleziona la casella di controllo Attiva criterio di rete.
Fai clic su Crea.
Per abilitare l'applicazione dei criteri di rete per un cluster esistente:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
In Networking, nel campo Criterio di rete, fai clic su edit Modifica criterio di rete.
Seleziona la casella di controllo Abilita criterio di rete per il master e fai clic su Salva modifiche.
Attendi l'applicazione delle modifiche, quindi fai di nuovo clic su edit Modifica criterio di rete.
Seleziona la casella di controllo Abilita criterio di rete per i nodi.
Fai clic su Salva modifiche.
API
Per abilitare l'applicazione dei criteri di rete, segui questi passaggi:
Specifica l'oggetto
networkPolicy
all'interno dell'oggettocluster
fornito a projects.zones.clusters.create o projects.zones.clusters.update.L'oggetto
networkPolicy
richiede un'enumerazione che specifica 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 comandicreate
eupdate
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 in quelli che utilizzano GKE Dataplane V2.
gcloud
-
Nella console Google Cloud, 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.
Per disabilitare l'applicazione dei criteri di rete, esegui queste attività:
- 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.
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 dei criteri di rete, GKE potrebbe non aggiornare immediatamente i nodi se per il cluster è configurata una periodo di manutenzione o un'esclusione. Per maggiori informazioni, consulta Aggiornamento del cluster lento.
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:
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
In Networking, nel campo Criterio di rete, fai clic su edit Modifica criterio di rete.
Deseleziona la casella di controllo Abilita criterio di rete per i nodi e fai clic su Salva modifiche.
Attendi l'applicazione delle modifiche, quindi fai di nuovo clic su edit Modifica criterio di rete.
Deseleziona la casella di controllo Abilita criterio di rete per il master.
Fai clic su Salva modifiche.
API
Per disabilitare l'applicazione dei criteri di rete per un cluster esistente, segui questi passaggi:
Aggiorna il cluster per utilizzare
networkPolicy.enabled: false
utilizzando l'APIsetNetworkPolicy
.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 per il cluster è configurata una periodo di manutenzione o un'esclusione. Per maggiori informazioni, consulta Aggiornamento del cluster lento.
Aggiorna il cluster per utilizzare
update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true
mediante l'APIupdateCluster
.
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 nella documentazione di Kubernetes:
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 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 porta988
. - 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 porta988
. - Per i cluster che eseguono GKE Dataplane V2, consenti il traffico in uscita verso
169.254.169.254/32
sulla porta80
.
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 dei criteri di rete da Calico a GKE Dataplane V2, considera le seguenti limitazioni:
Non puoi utilizzare un indirizzo IP di un pod o di un servizio nel campo
ipBlock.cidr
di un file manifestNetworkPolicy
. 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 manifestNetworkPolicy
. 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, devi configurare il criterio di rete applicato ai pod su cui si trova il servizio per consentire gli intervalli IP del controllo di integrità del bilanciatore del carico delle applicazioni appropriati. Se utilizzi un bilanciatore del carico delle applicazioni interno, devi anche configurare il criterio di rete per consentire la subnet solo proxy.
Se non utilizzi il bilanciamento del carico nativo del container con 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 loro di farlo impostando externalTrafficPolicy
su Local
nella definizione del servizio. Se il criterio externalTrafficPolicy
non viene 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 per pod specifici, seleziona sempre i pod in base al relativo 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 gli intervalli di indirizzi IP dei 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. Specificare ampi intervalli CIDR in questo campo, ad esempio 0.0.0.0/0
(che includono gli intervalli di indirizzi IP dei pod), potrebbe avere risultati imprevisti in diverse implementazioni di NetworkPolicy.
Comportamento di ipBlock in GKE Dataplane V2
Con l'implementazione di GKE Dataplane V2 di NetworkPolicy, 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'
, questa non includerà il traffico dei pod. Ciò è 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 di pod o 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
copriranno 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 cluster, ad esempio 10.95.0.0/17
. Se disponi di più intervalli IP, puoi includerli singolarmente nell'array, ad esempio ['10.95.0.0/17', '10.108.128.0/17']
.
Risoluzione dei problemi
I pod non 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 è limitato nei criteri di rete in uscita.
Per limitare il problema:
Verifica se il cluster utilizza Private Service Connect. Per ulteriori 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.
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'elemento
privateEndpoint
del cluster specificato.Console
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Nel riquadro di navigazione, in Cluster, fai clic sul cluster di cui vuoi trovare l'indirizzo IP interno.
In Impostazioni di base del cluster, vai a
Internal endpoint
, dove è elencato l'indirizzo IP interno.
Dopo aver individuato
privateEndpoint
oInternal endpoint
, configura il criterio in uscita del cluster per consentire il traffico all'indirizzo IP interno del piano di controllo. Per maggiori informazioni, vedi Creare un criterio di 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 una finestra di manutenzione o un'esclusione configurata.
Puoi eseguire manualmente l'upgrade di un pool di nodi impostando il flag--cluster-version
sulla stessa versione GKE in esecuzione del piano di controllo. Devi
utilizzare Google Cloud CLI per eseguire questa operazione. Per maggiori informazioni,
consulta le
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 del cluster esistente, GKE annulla la pianificazione dei pod del nodo ip-masquerade-agent o calico di cui hai eseguito il deployment manuale.
GKE non ripianifica 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 una finestra di manutenzione o un'esclusione, questo potrebbe causare un'interruzione estesa.
Per ridurre al minimo la durata dell'interruzione, puoi assegnare manualmente 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 seguendo questa procedura:
Verifica che l'applicazione dei criteri di rete sia abilitata. Il comando che utilizzi 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.
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
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 etichetteapp=store
del passaggio precedente.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 e non è presente alcun elemento che seleziona 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 con il criterio di rete Calico abilitato potrebbero riscontrare un problema per cui un pod StatefulSet interrompe le connessioni esistenti quando il pod viene eliminato. Quando un pod è passato nello stato Terminating
,
la configurazione di 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 mitigare 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 in stato containerCreating
In uno scenario in cui i cluster GKE con il criterio di rete Calico abilitato potrebbero riscontrare un problema in cui i pod rimangono bloccati nello stato containerCreating
.
Nella scheda Eventi del pod, viene visualizzato un messaggio simile al seguente:
plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local
Per ridurre il problema, usa un indirizzo IPam locale dell'host per Calico anziché calico-ipam nei cluster GKE.