Konfigurieren von Überwachung und Netzwerk für einen Kafka-Cluster auf Azure Kubernetes Service (AKS)

In diesem Artikel erfahren Sie, wie Sie überwachung und Netzwerk für einen Kafka-Cluster auf Azure Kubernetes Service (AKS) konfigurieren.

Überwachung mit Azure Managed Prometheus und Grafana

Strimzi implementiert die Überwachung, indem JMX-Metriken über den Prometheus JMX-Exporter verfügbar werden, der die internen Leistungsdaten von Kafka in ein Format transformiert, das Prometheus sammeln und analysieren kann. Diese Überwachungspipeline ermöglicht die Echtzeitsicht in:

• Gesundheits- und Leistungsmetriken des Brokers.
• Hersteller- und Verbraucherdurchsatz.
• Partitionsführungsverteilung.
• Replikationsverzögerung und potenzielle Risiken von Datenverlust.
• Ressourcenauslastungsmuster.

Azure Managed Prometheus bietet ein vollständig verwaltetes, skalierbares Überwachungs-Back-End ohne den betriebstechnischen Aufwand für die Verwaltung Ihrer eigenen Prometheus-Instanzen. Wenn Sie mit Azure Managed Grafana gekoppelt sind, erhalten Sie Zugriff auf umfassende Visualisierungsfunktionen mit vordefinierten Dashboards, die speziell für die Kafka-Überwachung entwickelt wurden.

PodMonitor erstellen

PodMonitors sind benutzerdefinierte Kubernetes-Ressourcen, die Prometheus mitteilen, von welchen Pods Metriken zu sammeln sind und wie sie zu sammeln sind. Für die Kafka-Überwachung müssen Sie PodMonitors definieren, die auf verschiedene Strimzi-Komponenten abzielen.

Stellen Sie vor dem Fortfahren sicher, dass Ihr Kafka-Cluster mit der JMX Exporter-Konfiguration bereitgestellt wurde. Ohne diese Konfiguration stehen Metriken für die Sammlung nicht zur Verfügung.

• Erstellen Sie die PodMonitor-Ressourcen mithilfe des kubectl apply Befehls.

  Hinweis

  Bei Verwendung von Azure Managed Prometheus:

  • Die PodMonitor apiVersion muss azmonitoring.coreos.com/v1 an Stelle des Standards monitoring.coreos.com/v1 sein.
  • Die Namespaceauswahl in den folgenden Beispielen geht davon aus, dass Ihre Kafka-Workloads im kafka Namespace bereitgestellt werden. Ändern Sie entsprechend, wenn Sie einen anderen Namespace verwenden.

  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
  

Hochladen von Grafana-Dashboards für die Kafka-Überwachung

Strimzi bietet einsatzbereite Grafana-Dashboards im GitHub-Repository strimzi/strimzi-kafka-operator , das speziell für die Überwachung von Kafka-Clustern entwickelt wurde. Diese Dashboards visualisieren die Metriken, die vom zuvor konfigurierten JMX Prometheus Exporter verfügbar gemacht werden.

Implementieren Sie die Kafka-Überwachung mit Grafana mithilfe der folgenden Schritte:

1. Wählen Sie Dashboards aus dem GitHub-Repository basierend auf Ihren spezifischen Überwachungsanforderungen aus.
2. Laden Sie die JSON-Dashboarddateien aus dem Repository herunter.
3. Importieren Sie die Dashboards über die Grafana-Benutzeroberfläche in Ihre Azure Managed Grafana-Instanz.

Konfigurieren von Kafka-Exporter zum Aktivieren erweiterter Prometheus-Metriken

Während der JMX Prometheus Exporter interne Kafka-Metriken bereitstellt, ergänzt der Kafka-Exporter dies, indem er sich auf die Überwachung der Verbraucherlatenz und Einblicke auf Themenebene konzentriert. Dieser Exporter:

• Verfolgt die Offsets der Konsumentengruppe und berechnet Verzögerungsmetriken.
• Überwacht den Themenstatus einschließlich unterreplizierter Partitionen.
• Stellt Metriken für die Anzahl und Größe von Themennachrichten bereit.

Diese zusätzlichen Metriken können für Produktionsumgebungen wichtig sein, in denen die Überwachung der Verbraucherleistung und die Verarbeitung von Datenverarbeitungs-SLAs unerlässlich sind.

Ein Helm-Chart steht zur Verfügung, um den Kafka-Exporter zusammen mit Ihrer vorhandenen Monitoring-Pipeline bereitzustellen.

1. Erstellen Sie einen Namespace zum Bereitstellen des Kafka-Exporters mithilfe des kubectl create namespace Befehls. Sie können auch bei Bedarf einen vorhandenen Namespace verwenden.

   kubectl create namespace azmon-kafka-exporter  
   

2. Fügen Sie das Prometheus-Community-Helm-Repository hinzu und aktualisieren Sie es mithilfe der helm repo add und helm repo update Befehle.

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

3. Erstellen Sie eine values.yaml Datei, um bestimmte Konfigurationen für das Helm-Diagramm außer Kraft zu setzen. Der kafka bootstrap-Endpunkt muss aktualisiert werden, bevor das Skript ausgeführt wird:

   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. Installieren Sie den Strimzi Cluster Operator mit dem helm install Befehl.

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

5. Laden Sie das Kafka Exporter Dashboard nach Grafana hoch.

Clientkonnektivität mit Kafka-Cluster

Strimzi bietet flexible Optionen zum Verfügbarmachen Ihres Kafka-Clusters für Kunden über Listener. Jeder Listener definiert, wie Clients mithilfe bestimmter Protokolle, Authentifizierungsmethoden und Netzwerkexpositionsmuster eine Verbindung mit Ihren Kafka-Brokern herstellen.

Eine Listenerkonfiguration definiert Folgendes:

• Auf welchem Port Kafka Verbindungen akzeptiert.
• Das Sicherheitsprotokoll (Plain, TLS, SASL).
• Wie der Verbindungsendpunkt verfügbar gemacht wird (Kubernetes-Diensttyp).

Kafka verwendet einen zweistufigen Verbindungsprozess, der beeinflusst, wie Sie Netzwerke konfigurieren sollten. Beim Konfigurieren von Listenern für Ihre Strimzi Kafka-Bereitstellung auf AKS ist es wichtig, den folgenden Prozess zu verstehen:

• Phase 1: Der Client stellt eine Verbindung mit dem Bootstrap-Dienst dar, der dann eine Verbindung mit einem der Broker herstellt, um Metadaten abzurufen. Die Metadaten enthalten Informationen zu den Themen, deren Partitionen und den Brokern, die sie hosten.
• Phase 2: Der Client stellt dann mithilfe der angekündigten Adresse, die aus den Metadaten abgerufen wurde, eine neue Verbindung direkt mit einem einzelnen Broker her.

Dies bedeutet, dass Ihre Netzwerkarchitektur sowohl den Bootstrap-Dienst als auch die individuelle Brokerkonnektivität berücksichtigen muss.

Weitere Informationen finden Sie in der Strimzi-Dokumentation zum Konfigurieren des Clientzugriffs.

Option 1: Interner Clusterzugriff (ClusterIP)

Für Anwendungen, die innerhalb desselben Kubernetes-Clusters wie der Kafka-Cluster ausgeführt werden, machen Sie Kafka über ClusterIP verfügbar:

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

Dadurch werden ein ClusterIP für den Bootstrap-Dienst und Broker erstellt, auf die nur innerhalb des Kubernetes-Netzwerks zugegriffen werden kann.

Option 2: Externer Zugriff über public Load Balancer

Für externe Clients erstellt der loadbalancer Listenertyp eine Azure Load Balancer-Konfiguration mit öffentlichen IP-Adressen:

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

Bei Verwendung dieser Konfiguration:

• Für jeden Broker und den Bootstrap-Dienst wird ein Kubernetes LoadBalancer-Dienst erstellt.
• Azure stellt öffentliche IP-Adressen für jeden Dienst fest.

Wenn Sie benutzerdefinierte DNS-Namen verwenden möchten, müssen Sie den advertisedHost für jeden Broker und den alternativeNames Bootstrap-Dienst konfigurieren. Dies ist erforderlich, um sicherzustellen, dass Kafka den benutzerdefinierten Hostnamen für jeden Broker ordnungsgemäß an einen Client weitergibt. Außerdem werden dem jeweiligen Broker- oder Bootstrap-Zertifikat die Informationen hinzugefügt, damit es für die ÜBERPRÜFUNG des TLS-Hostnamens verwendet werden kann.

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

Option 3: Externer Zugriff über privates Lastenausgleichsmodul

Wenn Sie auf den Kafka-Cluster außerhalb des AKS-Clusters, aber in einem virtuellen Azure-Netzwerk zugreifen möchten, können Sie den Bootstrap-Dienst und die Broker über einen internen Lastenausgleich mit privaten IP-Adressen verfügbar machen:

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"

Wenn Sie benutzerdefinierte DNS-Namen verwenden möchten, müssen Sie den advertisedHost für jeden Broker und den alternativeNames Bootstrap-Dienst konfigurieren. Dies ist erforderlich, um sicherzustellen, dass Kafka den benutzerdefinierten Hostnamen für jeden Broker ordnungsgemäß an einen Client weitergibt. Außerdem werden dem jeweiligen Broker- oder Bootstrap-Zertifikat die Informationen hinzugefügt, damit es zur ÜBERPRÜFUNG des TLS-Hostnamens verwendet werden kann.

  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"

Option 4: Externer Zugriff über den privaten Linkdienst

Um interne Netzwerke sicherer zu machen oder über virtuelle Azure-Netzwerke ohne Peers zuzugreifen, können Sie Ihren Kafka-Cluster über Azure Private Link Services verfügbar machen:

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"

Diese Konfiguration:

• Erstellt interne Lastenausgleichsdienste mit privaten IPs für alle Komponenten.
• Richtet einen privaten Linkdienst für den Bootstrap-Dienst bzw. die einzelnen Broker ein. Dies ermöglicht die Verbindung über private Endpunkte aus anderen virtuellen Netzwerken.
• Konfiguriert die alternativeNames. Dies ist erforderlich, um sicherzustellen, dass Strimzi dem TLS-Zertifikat die alternativen Bootstrap-Dienstnamen hinzufügt, damit sie für die ÜBERPRÜFUNG des TLS-Hostnamens verwendet werden können.
• Konfiguriert die advertisedHost. Dies ist erforderlich, um sicherzustellen, dass Kafka den privaten DNS-Eintrag des privaten Endpunkts ankündigen, der für jeden Broker konfiguriert ist. Das advertisedHost Zertifikat wird auch dem Brokerzertifikat hinzugefügt, sodass es für die ÜBERPRÜFUNG des TLS-Hostnamens verwendet werden kann.

Führen Sie nach der Bereitstellung dieser Konfiguration die Schritte zum Erstellen eines privaten Endpunkts für den privaten Azure Load Balancer Private Link Service aus.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:

• Sergio Navar | Senior Customer Engineer
• Erin Schaffer | Inhaltsentwickler 2