Configurar monitoramento e rede para um cluster Kafka no Serviço Kubernetes do Azure (AKS)

Este artigo mostra como configurar o monitoramento e a rede para um cluster Kafka no Serviço Kubernetes do Azure (AKS).

Monitoramento com o Azure Managed Prometheus e o Grafana

Strimzi implementa o monitoramento expondo métricas JMX através do Prometheus JMX Exporter, que transforma os dados internos de desempenho do Kafka em um formato que o Prometheus pode coletar e analisar. Esse pipeline de monitoramento permite visibilidade em tempo real sobre:

• Métricas de integridade e desempenho do corretor.
• Rendimento do produtor e do consumidor.
• Distribuição de liderança de partição.
• Atraso na replicação e riscos potenciais de perda de dados.
• Padrões de utilização de recursos.

O Azure Managed Prometheus fornece um back-end de monitoramento totalmente gerenciado e escalável sem a sobrecarga operacional de gerenciar suas próprias instâncias do Prometheus. Quando emparelhado com o Azure Managed Grafana, obtém acesso a capacidades de visualização abrangentes com dashboards pré-criados concebidos especificamente para monitorização Kafka.

Criar PodMonitor

Os PodMonitors são recursos personalizados do Kubernetes que informam ao Prometheus de quais pods coletar métricas e como coletá-las. Para o monitoramento Kafka, você precisa definir PodMonitors que visam vários componentes Strimzi.

Antes de continuar, verifique se o cluster Kafka foi implantado com a configuração do Exportador JMX. Sem essa configuração, as métricas não estarão disponíveis para coleta.

• Crie os recursos do PodMonitor usando o kubectl apply comando.

  Observação

  Ao usar o Azure Managed Prometheus:

  • O apiVersion do PodMonitor deve ser azmonitoring.coreos.com/v1 em vez do padrão monitoring.coreos.com/v1.
  • O seletor de namespace nos exemplos a seguir pressupõe que suas cargas de trabalho Kafka sejam implantadas no kafka namespace. Modifique de acordo se estiver usando um namespace diferente.

  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
  

Carregar painéis Grafana para monitoramento Kafka

O Strimzi fornece painéis Grafana prontos para uso no repositório GitHub do operador strimzi/strimzi-kafka, projetado especificamente para monitorar clusters Kafka. Esses painéis visualizam as métricas expostas pelo JMX Prometheus Exporter que você configurou anteriormente.

Implemente o monitoramento Kafka com o Grafana usando as seguintes etapas:

1. Selecione painéis no repositório GitHub com base em suas necessidades específicas de monitoramento.
2. Baixe os arquivos do painel JSON do repositório.
3. Importe os painéis para sua instância do Azure Managed Grafana por meio da interface do usuário do Grafana.

Configurar o Kafka Exporter para habilitar métricas aprimoradas do Prometheus

Enquanto o Exportador JMX Prometheus fornece métricas internas de Kafka, o Exportador de Kafka complementa-o, concentrando-se no monitoramento do atraso do consumidor e em insights de nível de tópico. Este exportador:

• Rastreia compensações de grupos de consumidores e calcula métricas de atraso.
• Monitora o status do tópico, incluindo partições subreplicadas.
• Fornece métricas para a contagem e os tamanhos de mensagens de tópicos.

Essas métricas adicionais podem ser críticas para ambientes de produção onde o monitoramento do desempenho do consumidor e o cumprimento dos SLAs de processamento de dados são essenciais.

Um chart do Helm está disponível para implementar o Kafka Exporter juntamente com o seu pipeline de monitorização existente.

1. Crie um namespace para implantar o Exportador Kafka usando o kubectl create namespace comando. Você também pode usar um namespace existente, se preferir.

   kubectl create namespace azmon-kafka-exporter  
   

2. Adicione e atualize o repositório prometheus-community Helm usando os comandos helm repo add e helm repo update.

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

3. Crie um values.yaml arquivo para substituir configurações específicas para o gráfico Helm. O ponto de extremidade de bootstrap Kafka deve ser atualizado antes de correr o script.

   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. Instale o Operador de Cluster Strimzi usando o 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. Carregue o Painel do Exportador de Kafka no Grafana.

Conectividade do cliente com o cluster Kafka

Strimzi oferece opções flexíveis para expor o seu cluster Kafka aos clientes através de ouvintes. Cada ouvinte define como os clientes se conectam aos seus corretores Kafka usando protocolos específicos, métodos de autenticação e padrões de exposição de rede.

Uma configuração de ouvinte define:

• Em qual porta Kafka aceita conexões.
• O protocolo de segurança (Plain, TLS, SASL).
• Como o endpoint de conexão é exposto (tipo de serviço Kubernetes).

Kafka usa um processo de conexão de duas fases que influencia como você deve configurar a rede. Ao configurar ouvintes para sua implantação do Strimzi Kafka no AKS, é importante entender o seguinte processo:

• Fase 1: O cliente se conecta ao serviço de bootstrap, que então se conecta a qualquer um dos brokers para recuperar metadados. Os metadados contêm informações sobre os tópicos, suas partições e os corretores que os hospedam.
• Fase 2: O cliente então estabelece uma nova conexão diretamente com um corretor individual usando o endereço anunciado obtido a partir dos metadados.

Isso significa que sua arquitetura de rede deve levar em conta o serviço de bootstrap e a conectividade individual do broker.

Para obter mais informações, consulte a documentação do Strimzi sobre como configurar o acesso para cliente.

Opção 1: Acesso interno ao cluster (ClusterIP)

Para aplicativos executados no mesmo cluster Kubernetes que o cluster Kafka, exponha Kafka via ClusterIP:

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

Isso cria um ClusterIP para o serviço de bootstrap e corretores acessíveis somente na rede do Kubernetes.

Opção 2: Acesso externo via Public Load Balancer

Para clientes externos, o loadbalancer tipo de ouvinte cria uma configuração do Balanceador de Carga do Azure com endereços IP públicos:

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

Ao usar esta configuração:

• Um serviço LoadBalancer do Kubernetes é criado para cada broker e para o serviço de bootstrap.
• O Azure provisiona endereços IP públicos para cada serviço.

Se quiser usar nomes DNS personalizados, você deve configurar o advertisedHost para cada broker e o alternativeNames para o serviço de bootstrap. Isso é necessário para garantir que Kafka divulgue corretamente o nome de host personalizado para cada intermediário para o cliente. Ele também adiciona a informação ao respetivo broker ou ao certificado bootstrap para que possa ser utilizada para verificação de nome de 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

Opção 3: Acesso externo via Private Load Balancer

Se você quiser acessar o cluster Kafka fora do cluster AKS, mas dentro de uma rede virtual do Azure, poderá expor o serviço de bootstrap e os brokers por meio de um balanceador de carga interno com endereços IP privados:

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 quiser usar nomes DNS personalizados, você deve configurar o advertisedHost para cada broker e o alternativeNames para o serviço de bootstrap. Isso é necessário para garantir que Kafka retransmita corretamente o nome de host personalizado de cada corretor para um cliente. Adiciona também a informação ao respetivo broker ou certificado de arranque para que possa ser utilizada na verificação de nome de 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"

Opção 4: Acesso externo através do Serviço de Link Privado

Para uma rede interna mais segura ou acesso em redes virtuais do Azure não emparelhadas, você pode expor seu cluster Kafka por meio dos Serviços de Link Privado do 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"

Esta configuração:

• Cria serviços de balanceador de carga interno com IPs privados para todos os componentes.
• Estabelece um Serviço de Link Privado para o serviço de bootstrap e os corretores individuais, respectivamente. Isso permite a conexão via pontos de extremidade privados de outras redes virtuais.
• Configura o alternativeNames. Isso é necessário para garantir que Strimzi adicione os nomes alternativos de serviço bootstrap ao certificado TLS, para que possam ser usados para a verificação do nome do host TLS.
• Configura o advertisedHost. Isso é necessário para garantir que o Kafka anuncie a entrada DNS privada do endpoint privado configurado para cada broker. O advertisedHost também é adicionado ao certificado do broker para que possa ser usado para verificação de nome de host TLS.

Depois de implantar essa configuração, siga as etapas para criar um ponto de extremidade privado para o Serviço de Link Privado do Balanceador de Carga do Azure.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram-no originalmente:

• Sergio Navar | Engenheiro de Clientes Senior
• Erin Schaffer | Desenvolvedora de Conteúdo 2