Criteri di rete di Azure Kubernetes

  • Articolo

I criteri di rete forniscono micro-segmentazione per i pod esattamente come i gruppi di sicurezza di rete (NSG) forniscono micro-segmentazione per le macchine virtuali. L'implementazione di Azure Network Policy Manager supporta la specifica dei criteri di rete Kubernetes standard. È possibile usare le etichette per selezionare un gruppo di pod e definire un elenco di regole di ingresso e uscita per filtrare il traffico da e verso questi pod. Altre informazioni sui criteri di rete di Kubernetes sono disponibili nella documentazione di Kubernetes.

Diagram of Kubernetes network policies overview.

L'implementazione di Gestione criteri di rete di Azure funziona con l'interfaccia CNI di Azure che fornisce l'integrazione della rete virtuale per i contenitori. Gestione criteri di rete è supportato in Linux e Windows Server. L'implementazione applica il filtro del traffico configurando regole IP consentite e negate in base ai criteri definiti nelle tabelle IPTable Linux o negli ACLPolicies del servizio di rete host (HNS) per Windows Server.

Pianificazione della sicurezza per il cluster Kubernetes

Quando si implementa la sicurezza per il cluster, usare i gruppi di sicurezza di rete (NSG) per filtrare il traffico che entra e lascia la subnet del cluster (traffico nord-sud). Usare Gestione criteri di rete di Azure per il traffico tra pod nel cluster (traffico east-west).

Uso di Gestione criteri di rete di Azure

Gestione criteri di rete di Azure può essere usato nei modi seguenti per fornire micro-segmentazione per i pod.

Servizio Azure Kubernetes (AKS)

Gestione criteri di rete è disponibile in modo nativo nel servizio Azure Kubernetes e può essere abilitato al momento della creazione del cluster.

Per altre informazioni, vedere Proteggere il traffico tra i pod usando criteri di rete nel servizio Azure Kubernetes.

Eseguire manualmente i cluster Kubernetes (DIY) in Azure

Per i cluster DIY, installare prima di tutto il plug-in CNI e abilitarlo in ogni macchina virtuale in un cluster. Per istruzioni dettagliate, vedere Distribuire il plug-in per un cluster Kubernetes.

Dopo aver distribuito il cluster, eseguire il comando seguente kubectl per scaricare e applicare il daemon di Gestione criteri di rete di Azure impostato sul cluster.

Per Linux:

kubectl apply -f https://raw.githubusercontent.com/Azure/azure-container-networking/master/npm/azure-npm.yaml

Per Windows:

 kubectl apply -f https://raw.githubusercontent.com/Azure/azure-container-networking/master/npm/examples/windows/azure-npm.yaml

La soluzione è anche open source e il codice è disponibile nel repository Azure Container Networking.

Monitorare e visualizzare le configurazioni di rete con Monitoraggio prestazioni rete di Azure

Gestione criteri di rete di Azure include metriche prometheus informative che consentono di monitorare e comprendere meglio le configurazioni. Fornisce visualizzazioni predefinite in portale di Azure o Grafana Labs. È possibile iniziare a raccogliere queste metriche usando Monitoraggio di Azure o un server Prometheus.

Vantaggi delle metriche di Gestione criteri di rete di Azure

Gli utenti in precedenza erano in grado di apprendere solo la configurazione di rete con iptables i comandi e ipset eseguiti all'interno di un nodo del cluster, che produce un output dettagliato e difficile da comprendere.

Nel complesso, le metriche forniscono:

  • Conteggio di criteri, regole ACL, ipset, voci ipset e voci in qualsiasi ipset specificato

  • Tempi di esecuzione per le singole chiamate del sistema operativo e per la gestione degli eventi delle risorse kubernetes (mediana, 90° percentile e 99° percentile)

  • Informazioni sugli errori per la gestione degli eventi delle risorse kubernetes (questi eventi di risorsa hanno esito negativo quando una chiamata del sistema operativo non riesce)

Casi d'uso delle metriche di esempio

Avvisi tramite Prometheus AlertManager

Vedere una configurazione per questi avvisi come indicato di seguito.

  1. Avviso quando Gestione criteri di rete presenta un errore con una chiamata del sistema operativo o quando si converte un criterio di rete.

  2. Genera un avviso quando il tempo mediano per applicare le modifiche per un evento di creazione è superiore a 100 millisecondi.

Visualizzazioni e debug tramite il dashboard di Grafana o la cartella di lavoro di Monitoraggio di Azure

  1. Verificare il numero di regole IPTable create dai criteri. La presenza di un numero elevato di regole IPTables può aumentare leggermente la latenza.

  2. Correlare i conteggi dei cluster (ad esempio, ACL) ai tempi di esecuzione.

  3. Ottenere il nome descrittivo di un ipset in una determinata regola IPTables , ad esempio azure-npm-487392 rappresenta podlabel-role:database.

Tutte le metriche supportate

L'elenco seguente è costituito dalle metriche supportate. Qualsiasi quantile etichetta ha valori 0.5possibili, 0.9, e 0.99. Qualsiasi had_error etichetta ha valori false possibili e true, che indica se l'operazione ha avuto esito positivo o negativo.

Nome misurazione Descrizione Tipo di metrica Prometheus Etichette
npm_num_policies numero di criteri di rete Misuratore -
npm_num_iptables_rules numero di regole IPTables Misuratore -
npm_num_ipsets numero di ipSet Misuratore -
npm_num_ipset_entries numero di voci di indirizzi IP in tutti gli IPSet Misuratore -
npm_add_iptables_rule_exec_time runtime per l'aggiunta di una regola IPTables Riepilogo quantile
npm_add_ipset_exec_time runtime per l'aggiunta di un IPSet Riepilogo quantile
npm_ipset_counts (avanzato) numero di voci all'interno di ogni singolo IPSet MisuratoreVec set_name & set_hash
npm_add_policy_exec_time runtime per l'aggiunta di criteri di rete Riepilogo quantile & had_error
npm_controller_policy_exec_time runtime per l'aggiornamento o l'eliminazione di criteri di rete Riepilogo quantile & & had_erroroperation (con valori update o delete)
npm_controller_namespace_exec_time runtime per la creazione, l'aggiornamento o l'eliminazione di uno spazio dei nomi Riepilogo quantile & & had_erroroperation (con valori create, updateo delete)
npm_controller_pod_exec_time runtime per la creazione,l'aggiornamento/l'eliminazione di un pod Riepilogo quantile & & had_erroroperation (con valori create, updateo delete)

Sono disponibili anche metriche "exec_time_count" e "exec_time_sum" per ogni metrica di riepilogo "exec_time".

Le metriche possono essere raschiate tramite Monitoraggio di Azure per i contenitori o tramite Prometheus.

Configurare Monitoraggio di Azure

Il primo passaggio consiste nell'abilitare Monitoraggio di Azure per i contenitori per il cluster Kubernetes. I passaggi sono disponibili in Monitoraggio di Azure per i contenitori Panoramica. Dopo aver abilitato Monitoraggio di Azure per i contenitori, configurare Monitoraggio di Azure per contenitori ConfigMap per abilitare l'integrazione e la raccolta di Metriche di Prometheus Network Policy Manager.

Monitoraggio di Azure per contenitori ConfigMap include una integrations sezione con le impostazioni per raccogliere le metriche di Network Policy Manager.

Queste impostazioni sono disabilitate per impostazione predefinita in ConfigMap. Abilitare l'impostazione collect_basic_metrics = truedi base , raccoglie le metriche di base di Gestione criteri di rete. L'abilitazione dell'impostazione collect_advanced_metrics = true avanzata raccoglie metriche avanzate oltre alle metriche di base.

Dopo aver modificato ConfigMap, salvarlo in locale e applicare ConfigMap al cluster come indicato di seguito.

kubectl apply -f container-azm-ms-agentconfig.yaml

Il frammento di codice seguente proviene da Monitoraggio di Azure per contenitori ConfigMap, che mostra l'integrazione di Network Policy Manager abilitata con la raccolta di metriche avanzate.

integrations: |-
    [integrations.azure_network_policy_manager]
        collect_basic_metrics = false
        collect_advanced_metrics = true

Le metriche avanzate sono facoltative e attivarle automaticamente attivano la raccolta di metriche di base. Le metriche avanzate attualmente includono solo Network Policy Manager_ipset_counts.

Altre informazioni sulle impostazioni di raccolta di Monitoraggio di Azure per contenitori nella mappa di configurazione.

Opzioni di visualizzazione per Monitoraggio di Azure

Dopo aver abilitato la raccolta delle metriche di Network Policy Manager, è possibile visualizzare le metriche nel portale di Azure usando informazioni dettagliate sui contenitori o in Grafana.

Visualizzazione in portale di Azure in informazioni dettagliate per il cluster

Aprire il portale di Azure. Una volta incluse le informazioni dettagliate del cluster, passare a Cartelle di lavoro e aprire Gestione criteri di rete (Gestione criteri di rete).

Oltre a visualizzare la cartella di lavoro, è anche possibile eseguire direttamente una query sulle metriche di Prometheus in "Log" nella sezione informazioni dettagliate. Ad esempio, questa query restituisce tutte le metriche raccolte.

| where TimeGenerated > ago(5h)
| where Name contains "npm_"

È anche possibile eseguire query su Log Analytics direttamente per le metriche. Per altre informazioni, vedere Introduzione alle query di Log Analytics.

Visualizzazione nel dashboard di Grafana

Configurare il server Grafana e configurare un'origine dati di Log Analytics come descritto qui. Importare quindi Grafana Dashboard con un back-end di Log Analytics in Grafana Labs.

Il dashboard include oggetti visivi simili alla cartella di lavoro di Azure. È possibile aggiungere pannelli al grafico e visualizzare le metriche di Network Policy Manager dalla tabella InsightsMetrics.

Configurare per il server Prometheus

Alcuni utenti possono scegliere di raccogliere metriche con un server Prometheus invece di Monitoraggio di Azure per i contenitori. È sufficiente aggiungere due processi alla configurazione di scrape per raccogliere le metriche di Network Policy Manager.

Per installare un server Prometheus, aggiungere questo repository helm nel cluster:

helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm repo update

quindi aggiungere un server

helm install prometheus stable/prometheus -n monitoring \
--set pushgateway.enabled=false,alertmanager.enabled=false, \
--set-file extraScrapeConfigs=prometheus-server-scrape-config.yaml

dove prometheus-server-scrape-config.yaml è costituito da:

- job_name: "azure-npm-node-metrics"
  metrics_path: /node-metrics
  kubernetes_sd_configs:
  - role: node
  relabel_configs:
  - source_labels: [__address__]
    action: replace
    regex: ([^:]+)(?::\d+)?
    replacement: "$1:10091"
    target_label: __address__
- job_name: "azure-npm-cluster-metrics"
  metrics_path: /cluster-metrics
  kubernetes_sd_configs:
  - role: service
  relabel_configs:
  - source_labels: [__meta_kubernetes_namespace]
    regex: kube-system
    action: keep
  - source_labels: [__meta_kubernetes_service_name]
    regex: npm-metrics-cluster-service
    action: keep
# Comment from here to the end to collect advanced metrics: number of entries for each IPSet
  metric_relabel_configs:
  - source_labels: [__name__]
    regex: npm_ipset_counts
    action: drop

È anche possibile sostituire il azure-npm-node-metrics processo con il contenuto seguente o incorporarlo in un processo preesistente per i pod Kubernetes:

- job_name: "azure-npm-node-metrics-from-pod-config"
  metrics_path: /node-metrics
  kubernetes_sd_configs:
  - role: pod
  relabel_configs:
  - source_labels: [__meta_kubernetes_namespace]
    regex: kube-system
    action: keep
  - source_labels: [__meta_kubernetes_pod_annotationpresent_azure_Network Policy Manager_scrapeable]
    action: keep
  - source_labels: [__address__]
    action: replace
    regex: ([^:]+)(?::\d+)?
    replacement: "$1:10091"
    target_label: __address__

Configurare gli avvisi per AlertManager

Se si usa un server Prometheus, è possibile configurare un AlertManager come questo. Ecco una configurazione di esempio per le due regole di avviso descritte in precedenza:

groups:
- name: npm.rules
  rules:
  # fire when Network Policy Manager has a new failure with an OS call or when translating a Network Policy (suppose there's a scraping interval of 5m)
  - alert: AzureNetwork Policy ManagerFailureCreatePolicy
    # this expression says to grab the current count minus the count 5 minutes ago, or grab the current count if there was no data 5 minutes ago
    expr: (npm_add_policy_exec_time_count{had_error='true'} - (npm_add_policy_exec_time_count{had_error='true'} offset 5m)) or npm_add_policy_exec_time_count{had_error='true'}
    labels:
      severity: warning
      addon: azure-npm
    annotations:
      summary: "Azure Network Policy Manager failed to handle a policy create event"
      description: "Current failure count since Network Policy Manager started: {{ $value }}"
  # fire when the median time to apply changes for a pod create event is more than 100 milliseconds.
  - alert: AzurenpmHighControllerPodCreateTimeMedian
    expr: topk(1, npm_controller_pod_exec_time{operation="create",quantile="0.5",had_error="false"}) > 100.0
    labels:
      severity: warning
      addon: azure-Network Policy Manager
    annotations:
      summary: "Azure Network Policy Manager controller pod create time median > 100.0 ms"
      # could have a simpler description like the one for the alert above,
      # but this description includes the number of pod creates that were handled in the past 10 minutes, 
      # which is the retention period for observations when calculating quantiles for a Prometheus Summary metric
      description: "value: [{{ $value }}] and observation count: [{{ printf `(npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='false'} - (npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='false'} offset 10m)) or npm_controller_pod_exec_time_count{operation='create',pod='%s',had_error='false'}` $labels.pod $labels.pod $labels.pod | query | first | value }}] for pod: [{{ $labels.pod }}]"

Opzioni di visualizzazione per Prometheus

Quando si usa un server Prometheus, è supportato solo il dashboard Grafana.

Se non è già stato fatto, configurare il server Grafana e configurare un'origine dati Prometheus. Importare quindi il dashboard di Grafana con un back-end Prometheus in Grafana Labs.

Gli oggetti visivi per questo dashboard sono identici al dashboard con un back-end di analisi dei contenitori/informazioni dettagliate sui contenitori.

Dashboard di esempio

Di seguito sono riportati alcuni dashboard di esempio per le metriche di Network Policy Manager in Informazioni dettagliate sui contenitori (CI) e Grafana.

Conteggi di riepilogo ci

Screenshot of Azure Workbook summary counts.

Conteggi ci nel tempo

Screenshot of Azure Workbook counts over time.

Voci DI IPSet CI

Screenshot of Azure Workbook IPSet entries.

Quantili di runtime CI

Screenshot of Azure Workbook runtime quantiles.

Conteggi riepilogo dashboard di Grafana

Screenshot Grafana Dashboard summary counts.

Conteggi del dashboard di Grafana nel tempo

Screenshot of Grafana Dashboard counts over time.

Voci IPSet dashboard di Grafana

Screenshot of Grafana Dashboard IPSet entries.

Quantili di runtime del dashboard di Grafana

Screenshot of Grafana Dashboard runtime quantiles.

Passaggi successivi