Configurare il monitoraggio e la rete per un cluster Kafka nel servizio Azure Kubernetes

Questo articolo illustra come configurare il monitoraggio e la rete per un cluster Kafka nel servizio Azure Kubernetes.

Monitoraggio con Prometheus gestito da Azure e Grafana

Strimzi implementa il monitoraggio esponendo le metriche JMX tramite Prometheus JMX Exporter, che trasforma i dati di prestazioni interni di Kafka in un formato che Prometheus può raccogliere e analizzare. Questa pipeline di monitoraggio consente la visibilità in tempo reale in:

• Metriche relative all'integrità e alle prestazioni del broker.
• Velocità effettiva per produttore e utente.
• Distribuzione della leadership di partizione.
• Ritardo della replica e potenziali rischi di perdita di dati.
• Modelli di utilizzo delle risorse.

Prometheus gestito di Azure offre un back-end di monitoraggio completamente gestito e scalabile senza il sovraccarico operativo della gestione delle proprie istanze di Prometheus. Se abbinato a Grafana gestito di Azure, si ottiene l'accesso a funzionalità di visualizzazione complete con dashboard predefiniti progettati appositamente per il monitoraggio di Kafka.

Creare PodMonitor

PodMonitors sono risorse personalizzate Kubernetes che indicano a Prometheus quali pod da cui raccogliere le metriche e come raccoglierle. Per il monitoraggio di Kafka, è necessario definire i *PodMonitors* destinati a vari componenti Strimzi.

Prima di procedere, verificare che il cluster Kafka sia stato distribuito con la configurazione JMX Exporter. Senza questa configurazione, le metriche non saranno disponibili per la raccolta.

• Creare le risorse PodMonitor usando il kubectl apply comando .

  Annotazioni

  Quando si usa Prometheus gestito di Azure:

  • PodMonitor apiVersion deve essere azmonitoring.coreos.com/v1 anziché lo standard monitoring.coreos.com/v1.
  • Il selettore dello spazio dei nomi negli esempi seguenti presuppone che i carichi di lavoro Kafka vengano distribuiti nello spazio dei nomi kafka. Se si sta usando uno spezio dei nomi diverso, modificarlo di conseguenza.

  kubectl apply -f - <<EOF
  ---
  apiVersion: azmonitoring.coreos.com/v1
  kind: PodMonitor
  metadata:
    name: azmon-cluster-operator-metrics
    labels:
      app: strimzi
  spec:
    selector:
      matchLabels:
        strimzi.io/kind: cluster-operator
    namespaceSelector:
      matchNames:
        - kafka
    podMetricsEndpoints:
    - path: /metrics
      port: http
  ---
  apiVersion: azmonitoring.coreos.com/v1
  kind: PodMonitor
  metadata:
    name: azmon-entity-operator-metrics
    labels:
      app: strimzi
  spec:
    selector:
      matchLabels:
        app.kubernetes.io/name: entity-operator
    namespaceSelector:
      matchNames:
        - kafka
    podMetricsEndpoints:
    - path: /metrics
      port: healthcheck
  ---
  apiVersion: azmonitoring.coreos.com/v1
  kind: PodMonitor
  metadata:
    name: azmon-bridge-metrics
    labels:
      app: strimzi
  spec:
    selector:
      matchLabels:
        strimzi.io/kind: KafkaBridge
    namespaceSelector:
      matchNames:
        - kafka
    podMetricsEndpoints:
    - path: /metrics
      port: rest-api
  ---
  apiVersion: azmonitoring.coreos.com/v1
  kind: PodMonitor
  metadata:
    name: azmon-kafka-resources-metrics
    labels:
      app: strimzi
  spec:
    selector:
      matchExpressions:
        - key: "strimzi.io/kind"
          operator: In
          values: ["Kafka", "KafkaConnect", "KafkaMirrorMaker", "KafkaMirrorMaker2"]
    namespaceSelector:
      matchNames:
        - kafka
    podMetricsEndpoints:
    - path: /metrics
      port: tcp-prometheus
      relabelings:
      - separator: ;
        regex: __meta_kubernetes_pod_label_(strimzi_io_.+)
        replacement: $1
        action: labelmap
      - sourceLabels: [__meta_kubernetes_namespace]
        separator: ;
        regex: (.*)
        targetLabel: namespace
        replacement: $1
        action: replace
      - sourceLabels: [__meta_kubernetes_pod_name]
        separator: ;
        regex: (.*)
        targetLabel: kubernetes_pod_name
        replacement: $1
        action: replace
      - sourceLabels: [__meta_kubernetes_pod_node_name]
        separator: ;
        regex: (.*)
        targetLabel: node_name
        replacement: $1
        action: replace
      - sourceLabels: [__meta_kubernetes_pod_host_ip]
        separator: ;
        regex: (.*)
        targetLabel: node_ip
        replacement: $1
        action: replace
  EOF
  

Caricare dashboard di Grafana per il monitoraggio di Kafka

Strimzi fornisce dashboard Grafana pronti per l'uso nel repository GitHub strimzi/strimzi-kafka-operator progettato appositamente per il monitoraggio dei cluster Kafka. Questi dashboard visualizzano le metriche esposte dall'utilità di esportazione JMX Prometheus configurata in precedenza.

Implementare il monitoraggio Kafka con Grafana seguendo questa procedura:

1. Selezionare i dashboard dal repository GitHub in base alle esigenze di monitoraggio specifiche.
2. Scaricare i file del dashboard JSON dal repository.
3. Importare i dashboard nell'istanza di Grafana gestita di Azure tramite l'interfaccia utente di Grafana.

Configurare Kafka Exporter per abilitare le metriche Prometheus avanzate

Mentre JMX Prometheus Exporter fornisce metriche Kafka interne, Kafka Exporter lo integra concentrandosi sul monitoraggio del ritardo utente e sulle informazioni dettagliate a livello di argomento. Questo esportatore:

• Tiene traccia degli offset dei gruppi di consumatori e calcola le metriche di ritardo.
• Monitora lo stato dell'argomento, incluse le partizioni replicate.
• Fornisce metriche per i conteggi e le dimensioni dei messaggi di un argomento.

Queste metriche aggiuntive possono essere fondamentali per gli ambienti di produzione in cui il monitoraggio delle prestazioni dei clienti e il rispetto degli SLA per l'elaborazione dei dati sono essenziali.

È disponibile un Helm Chart per distribuire il Kafka Exporter insieme alla pipeline di monitoraggio esistente.

1. Creare uno spazio dei nomi per distribuire l'utilità di esportazione Kafka usando il comando kubectl create namespace. Se si preferisce, è anche possibile usare uno spazio dei nomi esistente.

   kubectl create namespace azmon-kafka-exporter  
   

2. Aggiungi e aggiorna il repository Helm prometheus-community utilizzando i comandi helm repo add e helm repo update.

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts  
   helm repo update  
   

3. Creare un file values.yaml per eseguire l'override di configurazioni specifiche per il grafico Helm. Prima di eseguire lo script, è necessario aggiornare l'endpoint di bootstrap kafka:

   cat <<EOF > values.yaml  
   kafkaServer:  
     - <kafka-bootstrap-fqdn-or-privateip>:9092 #additional kafka clusters can be added to the list  
   prometheus:  
     serviceMonitor:  
       namespace: azmon-kafka-exporter #ensure namespace is the same as in step 1  
       enabled: true  
       apiVersion: azmonitoring.coreos.com/v1  
   EOF  
   

4. Installare l'operatore cluster Strimzi usando il helm install comando .

   helm install azmon-kafka-exporter prometheus-community/prometheus-kafka-exporter \
   --version 2.11.0 \
   --namespace azmon-kafka-exporter \
   --values values.yaml
   

5. Caricare il dashboard di Kafka Exporter in Grafana.

Connettività client al cluster Kafka

Strimzi offre opzioni flessibili per esporre il cluster Kafka ai client tramite listener. Ogni listener definisce il modo in cui i client si connettono ai broker Kafka usando protocolli, metodi di autenticazione e modelli di esposizione di rete specifici.

Una configurazione del listener definisce:

• Su quale porta Kafka accetta le connessioni.
• Protocollo di sicurezza (Plain, TLS, SASL).
• Modalità di esposizione dell'endpoint di connessione (tipo di servizio Kubernetes).

Kafka usa un processo di connessione a due fasi che influisce su come configurare la rete. Quando si configurano listener per la distribuzione di Strimzi Kafka nel servizio Azure Kubernetes, è importante comprendere il processo seguente:

• Fase 1: il client si connette al servizio bootstrap, che quindi si connette a uno dei broker per recuperare i metadati. I metadati contengono informazioni sugli argomenti, sulle relative partizioni e sui broker che li ospitano.
• Fase 2: il client stabilisce quindi una nuova connessione direttamente a un singolo broker usando l'indirizzo annunciato ottenuto dai metadati.

Ciò significa che l'architettura di rete deve tenere conto sia del servizio bootstrap che della connettività del singolo broker.

Per altre informazioni, vedere la documentazione di Strimzi sulla configurazione dell'accesso client.

Opzione 1: Accesso interno al cluster (ClusterIP)

Per le applicazioni in esecuzione nello stesso cluster Kubernetes del cluster Kafka, esporre Kafka tramite ClusterIP:

listeners:
  - name: internal
    port: 9092
    type: internal
    tls: true

Verrà creato un clusterIP per il servizio bootstrap e i broker accessibili solo all'interno della rete Kubernetes.

Opzione 2: Accesso esterno tramite Load Balancer pubblico

Per i client esterni, il loadbalancer tipo di listener crea una configurazione di Azure Load Balancer con indirizzi IP pubblici:

listeners:
  - name: external
    port: 9094
    type: loadbalancer
    tls: false

Quando si usa questa configurazione:

• Viene creato un servizio LoadBalancer Kubernetes per ogni broker e il servizio bootstrap.
• Azure effettua il provisioning degli indirizzi IP pubblici per ogni servizio.

Se si vogliono usare nomi DNS personalizzati, è necessario configurare advertisedHost per ogni broker e alternativeNames per il servizio bootstrap. Questa operazione è necessaria per garantire che Kafka annunci correttamente il nome host personalizzato per ogni broker a un client. Aggiunge anche le informazioni al rispettivo certificato broker o bootstrap in modo che possa essere usato per la verifica del nome host TLS.

listeners:
  - name: external
    port: 9094
    type: loadbalancer
    tls: true
    configuration: 
      bootstrap:
        alternativeNames: 
        - kafka-bootstrap.example.com
      brokers:
        - broker: 0
          advertisedHost: kafka-broker-0.example.com

Opzione 3: Accesso esterno tramite Load Balancer privato

Se si vuole accedere al cluster Kafka all'esterno del cluster del servizio Azure Kubernetes ma all'interno di una rete virtuale di Azure, è possibile esporre il servizio bootstrap e i broker tramite un servizio di bilanciamento del carico interno con indirizzi IP privati:

listeners:
  - name: private-lb
    port: 9094
    type: loadbalancer
    tls: true
    configuration: 
      bootstrap:
        annotations:
          service.beta.kubernetes.io/azure-load-balancer-internal: "true"
      brokers:
        - broker: 0
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
        - broker: 1
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
        - broker: 2
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"

Se si vogliono usare nomi DNS personalizzati, è necessario configurare advertisedHost per ogni broker e alternativeNames per il servizio bootstrap. Questo è necessario per garantire che Kafka pubblichi correttamente il nome host personalizzato associato a ciascun broker verso il client. Aggiunge anche le informazioni al rispettivo certificato broker o bootstrap in modo che possa essere usato per la verifica del nome host TLS.

  listeners:
    - name: private-lb
      port: 9094
      type: loadbalancer
      tls: true
      configuration: 
        bootstrap:
          alternativeNames: 
          - kafka-bootstrap.example.com
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
        brokers:
          - broker: 0
            advertisedHost: kafka-broker-0.example.com
            annotations:
              service.beta.kubernetes.io/azure-load-balancer-internal: "true"

Opzione 4: Accesso esterno tramite il servizio collegamento privato

Per una rete interna più sicura o per l'accesso tra reti virtuali di Azure non con peering, è possibile esporre il cluster Kafka tramite i servizi di collegamento privato di Azure:

listeners:
  - name: private-link
    port: 9094
    type: loadbalancer
    tls: true
    configuration:
      bootstrap:
        alternativeNames: 
        - kafka-bootstrap.<privatedomain-pe>.com
        annotations:
          service.beta.kubernetes.io/azure-load-balancer-internal: "true"
          service.beta.kubernetes.io/azure-pls-create: "true"
          service.beta.kubernetes.io/azure-pls-name: "pls-kafka-bootstrap" 
      brokers:
        - broker: 0
          advertisedHost: kafka-broker-0.<privatedomain-pe>.com
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
            service.beta.kubernetes.io/azure-pls-create: "true"
            service.beta.kubernetes.io/azure-pls-name: "pls-kafka-broker-0"
        - broker: 1
          advertisedHost: kafka-broker-1.<privatedomain-pe>.com   
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
            service.beta.kubernetes.io/azure-pls-create: "true"
            service.beta.kubernetes.io/azure-pls-name: "pls-kafka-broker-1"
        - broker: 2
          advertisedHost: kafka-broker-2.<privatedomain-pe>.com
          annotations:
            service.beta.kubernetes.io/azure-load-balancer-internal: "true"
            service.beta.kubernetes.io/azure-pls-create: "true"
            service.beta.kubernetes.io/azure-pls-name: "pls-kafka-broker-2"

Questa configurazione:

• Crea servizi di bilanciamento del carico interni con indirizzi IP privati per tutti i componenti.
• Stabilisce un servizio di collegamento privato per il servizio bootstrap e i singoli broker, rispettivamente. Ciò consente la connessione tramite endpoint privati da altre reti virtuali.
• Configura alternativeNames. Questa operazione è necessaria per assicurarsi che Strimzi aggiunga i nomi del servizio bootstrap alternativi al certificato TLS in modo che possano essere usati per la verifica del nome host TLS.
• Configura advertisedHost. Questa operazione è necessaria per garantire che Kafka annunci la voce DNS privata dell'endpoint privato configurato per ogni broker. advertisedHost viene aggiunto anche al certificato broker in modo che possa essere usato per la verifica del nome host TLS.

Dopo aver distribuito questa configurazione, seguire la procedura per creare un endpoint privato nel servizio collegamento privato di Azure Load Balancer.

Contributori

Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno originariamente scritto:

• Sergio Navar | Senior Customer Engineer
• Erin Schaffer | Sviluppatore di contenuti 2