Utilizzo del logging dei criteri di rete

Autopilota Standard

---

Questa pagina spiega come utilizzare il logging dei criteri di rete per Google Kubernetes Engine (GKE). Kubernetes norme della rete e specificare il traffico di rete che i pod possono inviare e ricevere. Rete il logging dei criteri consente di registrare quando una connessione viene consentita o rifiutata 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.
• Comprendi quali spazi dei nomi comunicano tra loro.
• Riconoscere un attacco Denial of Service.

I log dei criteri di rete vengono caricati su Cloud Logging per l'archiviazione ricerca, analisi e avvisi se Cloud Logging è abilitato. Cloud Logging è abilitata per impostazione predefinita nei nuovi cluster. Per saperne di più, consulta la pagina sulla configurazione di logging e 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.

• I log possono essere ulteriormente instradati a Pub/Sub, Cloud Storage o in 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 Oggetto NetworkLogging denominato default nel nuovo Dataplane V2 cluster. 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 selettivamente il logging per alcune reti criteri. 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

Nota: se utilizzi i criteri di rete per limitare il traffico all'interno di Cloud Service Mesh, implementa i criteri di rete prima di attivare Cloud Service Mesh in un spazio dei nomi. In caso contrario, è possibile che siano già state stabilite connessioni di lunga durata tra i pod nella mesh e l'attivazione di nuovi criteri di rete non chiude le connessioni esistenti.

Specifica 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. Campo Tipo Descrizione log bool Se impostato su true, le connessioni consentite nel cluster vengono registrate; in caso contrario, le connessioni consentite non vengono registrate. I criteri di rete che selezionano il pod e hanno una regola corrispondente alla connessione sono elencati nel messaggio di log. delegate bool Se false, vengono registrate tutte le connessioni consentite. Se più criteri di rete consentono una connessione, tutti i criteri corrispondenti sono elencati nel messaggio di log. Se true, le connessioni consentite vengono registrate solo se sono consentite da un criterio di rete con l'annotazione di logging policy.network.gke.io/enable-logging: "true". Se più criteri di rete consentono una connessione, tutti i criteri corrispondenti con l'annotazione enable-logging sono elencati nel messaggio di log. Se imposti spec.cluster.allow.delegate su true e spec.cluster.allow.log su false, si verifica un errore di configurazione.
cluster.deny	struct	Impostazioni per il logging delle connessioni negate. Campo Tipo Descrizione log bool Se impostato su true, le connessioni negate nel cluster vengono registrate; in caso contrario, le connessioni negate non vengono registrate. delegate bool Se false, tutte le connessioni rifiutate vengono registrate. Se true, le connessioni negate vengono registrate solo se il pod in cui è stata negata la connessione si trova in uno spazio dei nomi con l'annotazione policy.network.gke.io/enable-deny-logging: "true". Se imposti spec.cluster.deny.delegate su true e spec.cluster.deny.log su false, si verifica un errore di configurazione.

Accesso ai log dei criteri di rete

I log dei criteri di rete vengono caricati automaticamente Cloud Logging. Puoi accedere ai log tramite Esplora log o con Google Cloud CLI. Puoi anche indirizzare i log a un sink.

Cloud Logging

1. Vai alla pagina Esplora log nella console Google Cloud.

   Vai a Esplora log

2. Fai clic su Query Builder.

3. 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: il Località di Compute Engine nel cluster.
   • CLUSTER_NAME: il nome del cluster.
   • PROJECT_NAME: il nome del tuo progetto Google Cloud.

Consulta Utilizzo di Esplora log per imparerai a 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 in Nome log dall'elenco a discesa. 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:

• Mostra 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 cluster-esterne:

  jsonPayload.dest.instance != ""
  

• Mostra i log che corrispondono 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 il criterio di rete generati su ciascun nodo del cluster localmente /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: Campo Tipo Descrizione src_ip string Indirizzo IP di origine della connessione. src_port int Porta di origine della connessione. dest_ip string Indirizzo IP di destinazione della connessione. dest_port int Porta di destinazione della connessione. protocol string Protocollo di connessione, che può essere tcp, udp o icmp. direction string Direzione della connessione, che può essere ingress o egress.
src	struct	Informazioni sull'endpoint dell'origine: Campo Tipo Descrizione pod_name string Nome del pod, se l'origine è un pod. pod_namespace (deprecated) string Spazio dei nomi del pod, se l'origine è un pod. pod_namespace è deprecato. Utilizza namespace. namespace string Spazio dei nomi del pod, se l'origine è un pod. workload_name string Nome del carico di lavoro, se quello di origine è disponibile. workload_kind string Tipo di carico di lavoro, se quello di origine è disponibile. instance string Indirizzo IP dell'origine, se l'origine non è un pod.
dest	struct	Informazioni sull'endpoint della destinazione: Campo Tipo Descrizione pod_name string Nome del pod, se la destinazione è un pod. pod_namespace (deprecated) string Spazio dei nomi del pod, se la destinazione è un pod. pod_namespace è deprecato. Utilizza namespace. namespace string Spazio dei nomi del pod, se la destinazione è un pod. workload_name string Nome del carico di lavoro, se disponibile. workload_kind string Tipo di carico di lavoro, se il carico di lavoro di destinazione è disponibile. instance string Indirizzo IP dell'origine, se la destinazione non è un pod.
disposition	string	Disposizione della connessione, che può essere allow o deny.
policies	list of structs	Criteri corrispondenti per le connessioni consentite dalla vista del pod applicato. Per la connessione in entrata, il pod applicato è il pod di destinazione. Per la connessione in uscita, il pod applicato è il pod di origine. Vengono registrati più criteri se tutti i criteri corrispondono a una connessione. Questo campo è incluso solo nei log delle connessioni consentite. Campo Tipo Descrizione name string Nome del criterio di rete corrispondente. namespace string Spazio dei nomi del criterio di rete corrispondente.
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.

Nota: namespace, workload_name e workload_kind sono disponibili nelle seguenti versioni:

• da 1.20.10-gke.2200 a 1,21
• da 1.21.4-gke.2300 a 1,22
• 1.22.1-gke.1700 e versioni successive

Definizione di connessione

Per i protocolli orientati alla connessione come TCP, viene creato un log per ogni o connessione negata. 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 di log per le connessioni negate non includono il campo policies perché l'API dei criteri di rete di Kubernetes non ha criteri di negazione 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 connessioni negate

È normale che un client riprovi a effettuare una connessione rifiutata. Per evitare un numero eccessivo di registrazioni, connessioni negate ripetute in una finestra di cinque secondi vengono e aggregati in un singolo messaggio di log mediante il campo count.

Le connessioni negate successive vengono aggregate a un messaggio di log precedente se src_ip, dest_ip, dest_port, protocol, e direction della connessione corrispondono prima connessione negata. Tieni presente che il valore di src_port delle connessioni successive non devono corrispondere perché le connessioni tentate 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. Questo criterio nega implicitamente tutto il traffico in entrata verso test-service anche 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 il connessione 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 per la connessione negata 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 per le connessioni negate include un campo count per aggregazione delle connessioni negate.

Risoluzione dei problemi relativi ai log dei criteri di rete

1. Verifica la presenza di eventi di errore nell'oggetto NetworkLogging:

   kubectl describe networklogging default
   

   Se 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 false
   

2. Per 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 dei criteri controllando se i contatori di errori stanno incrementando:

   kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_logging
   

   Sostituisci ANETD_POD_NAME con il nome di un pod anetd. Controlla ciascun nodo. anetd è il controller di rete per Dataplane V2.

I log senza nome vengono visualizzati per i pod con criteri di rifiuto predefiniti

Probe di attività, idoneità e avvio richiedono che il pod accetti connessioni Ingress effettuate dai probe da kubelet. Per assicurarti che questi probe funzionino correttamente, GKE consente automaticamente il traffico di probe al pod selezionato configurato per il pod, a prescindere dai criteri di rete applicati al pod. Non puoi modificare questo comportamento.

I log per le connessioni dei probe sono simili ai seguenti:

{
   "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_ip non corrisponde ad alcun 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.

• Scopri come visualizzare la connettività dei carichi di lavoro con GKE Dataplane V2.