Questa pagina spiega come utilizzare il logging dei criteri di rete per Google Kubernetes Engine (GKE). I criteri di rete di Kubernetes specificano il traffico di rete che i pod possono inviare e ricevere. La registrazione dei criteri di rete consente di registrare quando una connessione è consentita o negata da un criterio di rete. La registrazione dei criteri di rete può aiutarti a risolvere i problemi relativi ai criteri di rete.
Panoramica
Con il logging dei criteri di rete, puoi:
- Verifica che i criteri di rete funzionino come previsto.
- Scopri quali pod del tuo cluster comunicano con internet.
- Scopri quali spazi dei nomi comunicano tra loro.
- Riconoscere un attacco Denial of Service.
I log dei criteri di rete vengono caricati in Cloud Logging per archiviazione, ricerca, analisi e generazione di avvisi, se Cloud Logging è attivo. Cloud Logging è abilitato per impostazione predefinita nei nuovi cluster. Per saperne di più, consulta Configurare il logging e il monitoraggio per GKE.
Requisiti
- Il logging dei criteri di rete è disponibile solo per i cluster che utilizzano GKE Dataplane V2.
- La registrazione dei criteri di rete richiede Google Cloud CLI 303.0.0 o versioni successive.
- La registrazione dei criteri di rete non è supportata con i pool di nodi Windows Server.
Prezzi
- Non sono previsti costi per la generazione di log per la registrazione dei criteri di rete.
- Se archivi i log in Cloud Logging, si applicano i costi di Cloud Logging standard.
- I log possono essere inoltrati a Pub/Sub, Cloud Storage o BigQuery. Potrebbero essere applicati costi per Pub/Sub, Cloud Storage o BigQuery. Per ulteriori informazioni, consulta la panoramica su routing e archiviazione.
Configurazione del logging dei criteri di rete
Per configurare le impostazioni di registrazione dei criteri di rete, modifica l'oggetto NetworkLogging
nel cluster. GKE crea automaticamente un oggetto NetworkLogging denominato default nei nuovi cluster Dataplane V2. Può esserci un solo
oggetto NetworkLogging per cluster e non può essere rinominato.
Puoi configurare separatamente il logging delle connessioni consentite e il logging delle connessioni vietate. Puoi anche attivare in modo selettivo la registrazione per alcuni criteri di rete. Di seguito è riportato un esempio della specifica NetworkLogging, con le impostazioni specificate per registrare tutte le connessioni consentite e negate:
kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
name: default
spec:
cluster:
allow:
log: true
delegate: false
deny:
log: true
delegate: false
Utilizza kubectl per modificare la configurazione:
kubectl edit networklogging default
Specifiche di NetworkLogging
La specifica dell'oggetto NetworkLogging è in formato YAML. Questo formato è descritto nella tabella seguente:
| Campo | Tipo | Descrizione | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
cluster.allow | struct |
Impostazioni per il logging delle connessioni consentite.
|
|||||||||
cluster.deny |
struct |
Impostazioni per la registrazione delle connessioni negate.
|
Accesso ai log dei criteri di rete
I log dei criteri di rete vengono caricati automaticamente in Cloud Logging. Puoi accedere ai log tramite Esplora log o con Google Cloud CLI. Puoi anche indirizzare i log a un sink.
Cloud Logging
Vai alla pagina Esplora log nella console Google Cloud.
Fai clic su Query Builder.
Utilizza la seguente query per trovare tutti i record dei log dei criteri di rete:
resource.type="k8s_node" resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/policy-action"Sostituisci quanto segue:
CLUSTER_LOCATION: la posizione di Compute Engine del cluster.CLUSTER_NAME: il nome del cluster.PROJECT_NAME: il nome del tuo progetto Google Cloud.
Consulta Utilizzo di Esplora log per scoprire come utilizzare Esplora log.
Puoi anche creare una query utilizzando Query Builder. Per creare una query per i log dei criteri di rete, seleziona policy-action nell'elenco a discesa Nome log. Se non sono disponibili log, policy-action non viene visualizzato nell'elenco a discesa.
gcloud
Trova tutti i record dei log dei criteri di rete:
gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_NAME/logs/policy-action"'
Sostituisci quanto segue:
PROJECT_NAME: il nome del tuo progetto Google Cloud.CLUSTER_LOCATION: la posizione di Compute Engine del cluster.CLUSTER_NAME: il nome del cluster.
Puoi aggiungere altre condizioni per filtrare i risultati. Ad esempio:
Mostrare i log in un determinato periodo di tempo:
timestamp>="2020-06-22T06:30:51.128Z" timestamp<="2020-06-23T06:30:51.128Z"Mostra i log per le connessioni negate:
jsonPayload.disposition="deny"Mostra i log di un deployment denominato "redis":
jsonPayload.dest.pod_name=~"redis" jsonPayload.dest.pod_namespace="default"Mostra i log per le connessioni esterne al cluster:
jsonPayload.dest.instance != ""Mostra i log corrispondenti a un determinato criterio di rete, in questo caso "allow-frontend-to-db":
jsonPayload.policies.name="allow-frontend-to-db" jsonPayload.policies.namespace="default"
Se utilizzi un cluster standard, puoi anche trovare i log dei criteri di rete generati su ogni nodo del cluster localmente in /var/log/network/policy_action.log*. Viene creato un nuovo file di log numerato quando il file di log corrente raggiunge i 10 MB. Vengono archiviati fino a cinque file di log precedenti.
Formato del log dei criteri di rete
I record dei log dei criteri di rete sono in formato JSON. Questo formato è descritto nella tabella seguente:
| Campo | Tipo | Descrizione | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
connection | struct |
Informazioni sulla connessione:
|
|||||||||||||||||||||
src | struct |
Informazioni sull'endpoint dell'origine:
|
|||||||||||||||||||||
dest | struct |
Informazioni sull'endpoint della destinazione:
|
|||||||||||||||||||||
disposition | string | Disposizione della connessione, che può essere allow o deny. | |||||||||||||||||||||
policies | list of structs |
Criteri corrispondenti per le connessioni consentite dalla visualizzazione del pod applicato. Per la connessione in entrata, il pod applicato è il pod di destinazione. Per la connessione in uscita, il pod imposto è il pod di origine. Vengono registrati più criteri se una connessione corrisponde a tutti. Questo campo è incluso solo nei log delle connessioni consentite.
|
|||||||||||||||||||||
count | int | Utilizzato per l'aggregazione dei log delle query rifiutate. Il valore è sempre 1 per la connessione consentita. | |||||||||||||||||||||
node_name | string | Il nodo che esegue il pod che ha generato questo messaggio di log. | |||||||||||||||||||||
timestamp | string | Quando si è verificato il tentativo di connessione. |
Definizione di connessione
Per i protocolli orientati alla connessione come TCP, viene creato un log per ogni connessione consentita o rifiutata. Per protocolli come UDP e ICMP che non sono basati su connessioni, i pacchetti vengono raggruppati in connessioni basate su finestre temporali.
Log dei criteri per le connessioni negate
I record dei log per le connessioni negate non includono il campo policies
perché l'API Network Policy di Kubernetes non ha criteri di rifiuto espliciti.
Una connessione viene rifiutata se un pod è coperto da uno o più criteri di rete, ma
nessuno dei criteri consente la connessione. Ciò significa che nessun criterio è individualmente responsabile di una connessione bloccata.
Aggregazione dei log per le connessioni negate
È normale che un client riprovi a effettuare una connessione rifiutata. Per evitare un logging eccessivo, le connessioni ripetutamente rifiutate in un intervallo di cinque secondi vengono aggregate in un unico messaggio di log utilizzando il campo count.
Le connessioni rifiutate successive vengono aggregate con un messaggio di log precedente se src_ip, dest_ip, dest_port, protocol,e direction della connessione corrispondono alla prima connessione rifiutata. Tieni presente che il src_port delle connessioni successive non deve corrispondere perché le connessioni riprovate potrebbero provenire da una porta diversa.
Il messaggio di log aggregato include il src_prt della prima connessione rifiutata
all'inizio della finestra di aggregazione.
Record di log di esempio
Il seguente esempio di criterio di rete denominato allow-green applicato a
test-service consente le connessioni a test-service da un pod denominato
client-green. Implicitamente, questo criterio nega tutto il resto del traffico in entrata a
test-service, incluso quello proveniente dal pod client-red.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-green
namespace: default
annotations:
policy.network.gke.io/enable-logging: "true"
spec:
podSelector:
matchLabels:
app: test-service
ingress:
- from:
- podSelector:
matchLabels:
app: client-green
policyTypes:
- Ingress
Questo diagramma mostra l'effetto del criterio allow-green su due connessioni a
test-service. Il criterio allow-green consente la connessione da
client-green. Poiché nessun criterio consente la connessione da client-red, la connessione viene negata.
Il log per la connessione consentita da client-green ha il seguente aspetto:
{
"connection":{
"src_ip":"10.84.0.252",
"dest_ip":"10.84.0.165",
"src_port":52648,
"dest_port":8080,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"allow",
"policies":[
{
"name":"allow-green",
"namespace":"default"
}
],
"src":{
"pod_name":"client-green-7b78d7c957-68mv4",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"client-green-7b78d7c957",
"workload_kind":"ReplicaSet"
},
"dest":{
"pod_name":"test-service-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"test-service-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":1,
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2020-06-16T03:10:37.993712906Z"
}
Il log relativo alla connessione rifiutata da client-red ha il seguente aspetto:
{
"connection":{
"src_ip":"10.84.0.180",
"dest_ip":"10.84.0.165",
"src_port":39610,
"dest_port":8080,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"deny",
"src":{
"pod_name":"client-red-5689846f5b-b5ccx",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"client-red-5689846f5b",
"workload_kind":"ReplicaSet"
},
"dest":{
"pod_name":"test-service-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"test-service-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":3,
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2020-06-15T22:38:32.189649531Z"
}
Tieni presente che il log delle connessioni rifiutate non include il campo policies. Questo
è descritto nella sezione precedente,
Log dei criteri per le connessioni negate.
Il log delle connessioni negate include un campo count per
aggregare le connessioni negate.
Risolvere i problemi relativi ai log delle norme di rete
Controlla la presenza di eventi di errore nell'oggetto
NetworkLogging:kubectl describe networklogging defaultSe la configurazione del logging non è valida, la configurazione non verrà applicata e verrà segnalato un errore nella sezione degli eventi:
Name: default Namespace: Labels: addonmanager.kubernetes.io/mode=EnsureExists Annotations: API Version: networking.gke.io/v1alpha1 Kind: NetworkLogging Metadata: Creation Timestamp: 2020-06-20T05:54:08Z Generation: 8 Resource Version: 187864 Self Link: /apis/networking.gke.io/v1alpha1/networkloggings/default UID: 0f1ddd6e-4193-4295-9172-baa6a52aa6e6 Spec: Cluster: Allow: Delegate: true Log: false Deny: Delegate: false Log: false Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning InvalidNetworkLogging 16s (x3 over 11h) network-logging-controller, gke-anthos-default-pool-cee49209-0t09 cluster allow log action is invalid: delegate cannot be true when log is false Warning InvalidNetworkLogging 16s (x3 over 11h) network-logging-controller, gke-anthos-default-pool-cee49209-80fx cluster allow log action is invalid: delegate cannot be true when log is falsePer limitare l'utilizzo della CPU per il logging, un nodo può registrare fino a 500 collegamenti al secondo prima di iniziare a eliminare i log. I criteri di rete sul nodo continuano a essere applicati. Puoi vedere se sono stati eliminati log delle norme controllando se i contatori degli errori sono in aumento:
kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_loggingSostituisci
ANETD_POD_NAMEcon il nome di un pod anetd. Controlla ogni nodo. anetd è il controller di rete per Dataplane V2.
I log senza nome vengono visualizzati per i pod con criteri di rifiuto predefiniti
I probe di attività, di idoneità e di avvio richiedono che il pod accetti le connessioni Ingress effettuate dai probe di kubelet. Per garantire il corretto funzionamento di questi controlli, GKE consente automaticamente il traffico di controllo al pod selezionato come configurato per il pod, indipendentemente dai criteri di rete applicati al pod. Non puoi modificare questo comportamento.
I log per le connessioni dei probe sono simili al seguente:
{
"connection":{
"src_ip":"10.88.1.1",
"dest_ip":"10.88.1.4",
"src_port":35848,
"dest_port":15021,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"allow",
"src":{
"instance":"10.88.1.1"
},
"dest":{
"pod_name":"testpod-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"testpod-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":1,
"policies": [
{
"name":""
}
],
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2021-04-01T12:42:32.1898720941Z"
}
Il log presenta le seguenti caratteristiche:
- Il valore di
policies.nameè vuoto perché non è associato alcun criterio di rete per consentire la connessione. - Il valore di
connection.src_ipnon corrisponde a nessun pod o nodo.
Passaggi successivi
- Scopri come visualizzare e analizzare i log con Cloud Logging.
- Implementa approcci comuni per limitare il traffico utilizzando i criteri di rete.