在 Azure Kubernetes 服务（AKS）上为 Kafka 群集配置监视和网络

2025-10-15

本文介绍如何为 Azure Kubernetes 服务（AKS）上的 Kafka 群集配置监视和网络。

在 Azure 托管环境中使用 Prometheus 和 Grafana 进行监视

Strimzi 通过 Prometheus JMX 导出程序公开 JMX 指标来实现监视，后者将 Kafka 的内部性能数据转换为 Prometheus 可以收集和分析的格式。此监视管道可实现对以下情况的实时可见性：

中介运行状况和性能指标。
生产者和消费者吞吐率。
分区领导分配。
复制滞后和潜在的数据丢失风险。
资源利用率模式。

Azure 托管版 Prometheus 提供完全托管的、可扩展的监控后端，免去管理您自己 Prometheus 实例的管理开销。与 Azure 托管 Grafana 配对时，可以使用专为 Kafka 监视设计的预构建仪表板访问全面的可视化功能。

创建 PodMonitor

PodMonitors 是 Kubernetes 的自定义资源，用于告知 Prometheus 从哪些 Pod 收集度量指标，以及如何收集这些指标。要进行 Kafka 监控，需定义针对各种 Strimzi 组件的 PodMonitors。

在继续作之前，请确保已使用 JMX 导出程序配置部署 Kafka 群集。如果没有此配置，指标将不可用于收集。

使用 kubectl apply 命令创建 PodMonitor 资源。

注释

使用 Azure 托管 Prometheus 时：

PodMonitor apiVersion 必须为 azmonitoring.coreos.com/v1，而不是标准的 monitoring.coreos.com/v1。
以下示例中的命名空间选择器假定 Kafka 工作负载部署在命名空间中 kafka 。如果使用其他命名空间，请相应地修改。

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

上传用于 Kafka 监控的 Grafana 仪表板

Strimzi 在 strimzi/strimzi-kafka-operator GitHub 存储库中提供现成的 Grafana 仪表板，专为监视 Kafka 群集而设计。这些仪表板可视化前面配置的 JMX Prometheus 导出程序公开的指标。

使用以下步骤通过 Grafana 实施 Kafka 监控：

根据特定的监视需求从 GitHub 存储库中选择仪表板。
从存储库下载 JSON 仪表板文件。
通过 Grafana UI 将仪表板导入到 Azure 托管的 Grafana 实例中。

配置 Kafka 导出程序以启用增强的 Prometheus 指标

虽然 JMX Prometheus 导出程序提供内部 Kafka 指标，但 Kafka 导出程序通过专注于消费者滞后监视和主题级见解来补充它。此导出程序：

跟踪使用者组偏移量并计算滞后指标。
监视主题状态，包括复制不足的分区。
提供主题消息数量和大小的统计数据。

这些附加指标对于生产环境至关重要，在这些环境中，监视使用者性能和满足数据处理 SLA 至关重要。

Helm 图表可用于将 Kafka 导出程序与现有监视管道一起部署。

使用 kubectl create namespace 命令创建命名空间以部署 Kafka 导出程序。如果愿意，也可以使用现有的命名空间。
```
kubectl create namespace azmon-kafka-exporter  
```

使用和helm repo add命令添加和更新 helm repo update Helm 存储库。

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

创建 values.yaml 文件替代 Helm 图表的特定配置。在运行脚本之前，必须更新 Kafka bootstrap 终结点。

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

使用 helm install 命令安装 Strimzi 集群操作员。

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

将 Kafka 导出程序仪表板上传到 Grafana。

注释

此 Grafana 仪表板使用将在将来版本的 Grafana 中弃用的 AngularJS 插件。有关详细信息，请参阅 Angular 支持弃用。 Kafka 导出程序指标仍将可用，但弃用后，你可能需要创建自己的仪表板。

与 Kafka 群集的客户端连接

Strimzi 提供了灵活的选项，用于通过 侦听器向客户端公开 Kafka 群集。每个侦听器定义客户端如何使用特定的协议、身份验证方法和网络公开模式连接到 Kafka 中转站。

侦听器配置会定义：

Kafka 接受连接的端口。
安全协议（普通、TLS、SASL）。
连接终结点的公开方式（Kubernetes 服务类型）。

Kafka 使用一种两阶段连接过程，这会影响网络配置的方式。在 AKS 上为 Strimzi Kafka 部署配置侦听器时，请务必了解以下过程：

阶段 1：客户端连接到引导服务，然后连接到任意一个代理以获取元数据。元数据包含有关主题、其分区以及托管主题的中转站的信息。
阶段 2：客户端随后使用从元数据获取的发布地址直接建立与单个代理的新连接。

这意味着网络架构必须同时考虑启动服务和单个代理连接。

有关详细信息，请参阅有关配置客户端访问的 Strimzi 文档。

选项 1：内部群集访问（ClusterIP）

对于在与 Kafka 群集相同的 Kubernetes 群集中运行的应用程序，请通过 ClusterIP 公开 Kafka：

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

这将为启动服务和代理创建一个仅可在 Kubernetes 网络中访问的 ClusterIP。

选项 2：通过公共负载均衡器进行外部访问

对于外部客户端， loadbalancer 侦听器类型使用公共 IP 地址创建 Azure 负载均衡器配置：

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

使用此配置时：

为每个代理和引导服务创建 Kubernetes LoadBalancer 服务。
Azure 为每个服务预配公共 IP 地址。

如果要使用自定义 DNS 名称，则必须为每个代理服务器配置advertisedHost，为引导服务配置alternativeNames。这需要确保 Kafka 能够正确地将每个代理节点的自定义主机名传递回客户端。它还会将信息添加到相应的代理或启动证书，以便可用于 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

选项 3：通过专用负载均衡器进行外部访问

如果要访问的 Kafka 群集在 AKS 群集外部但在 Azure 虚拟网络中，可以通过具有专用 IP 地址的内部负载均衡器公开启动服务和代理：

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"

重要

向集群添加新代理时，必须为每个新代理使用相应的注释更新监听器配置。否则，这些代理将通过公共 IP 地址公开。

如果要使用自定义 DNS 名称，则必须为每个代理服务器配置advertisedHost，为引导服务配置alternativeNames。为了确保 Kafka 正确地将支持每个代理的自定义主机名播发回到客户端，需要执行此操作。它还会将信息添加到相应的代理或启动证书，以便可用于 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"

选项 4：通过专用链接服务进行外部访问

若要更安全的内部网络或跨非对等互连的 Azure 虚拟网络进行访问，可以通过 Azure 专用链接服务公开 Kafka 群集：

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"

此配置：

为所有组件创建具有专用 IP 的内部负载均衡器服务。
分别为启动服务和各个代理建立专用链接服务。这样就可以通过来自其他虚拟网络的专用终结点进行连接。
配置 alternativeNames。这需要确保 Strimzi 将备用启动服务名称添加到 TLS 证书，以便它们可用于 TLS 主机名验证。
配置 advertisedHost。为了确保 Kafka 播发为每个代理配置的专用终结点的专用 DNS 条目，需要执行此操作。 advertisedHost 也被添加到代理证书中，以便可以用于 TLS 主机名验证。

重要