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

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

Monitoramento com o Azure Managed Prometheus e o Grafana

Strimzi implementa o monitoramento expondo métricas JMX por meio do Exportador Prometheus JMX, que transforma os dados de desempenho interno do Kafka em um formato que o Prometheus pode coletar e analisar. Este fluxo de monitoramento proporciona visibilidade em tempo real sobre:

• Métricas de desempenho e integridade do corretor.
• Taxa de transferência do produtor e do consumidor.
• Distribuição de liderança de partição.
• Retardo de replicação e possíveis riscos de perda de dados.
• Padrões de utilização de recursos.

O Azure Managed Prometheus fornece um back-end de monitoramento totalmente gerenciado e escalonável sem a sobrecarga operacional de gerenciar suas próprias instâncias do Prometheus. Quando emparelhado com o Grafana Gerenciado do Azure, você obtém acesso a recursos de visualização abrangentes com painéis predefinidos projetados especificamente para monitoramento do Kafka.

Criar PodMonitor

PodMonitors são recursos personalizados do Kubernetes que informam ao Prometheus de quais pods coletar métricas e como coletá-las. Para o monitoramento do Kafka, você precisa definir PodMonitors direcionados a 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 coleção.

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

  Observação

  Ao usar o Prometheus Gerenciado do Azure:

  • A apiVersion do PodMonitor deve estar azmonitoring.coreos.com/v1 em vez do padrão monitoring.coreos.com/v1.
  • O seletor de namespace nos exemplos a seguir pressupõe que as cargas de trabalho do Kafka sejam implantadas no kafka namespace. Modifique adequadamente 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 do Grafana para monitoramento do Kafka

Strimzi fornece painéis do Grafana prontos para uso no repositório GitHub strimzi/strimzi-kafka-operator projetado especificamente para monitorar clusters Kafka. Esses painéis apresentam as métricas expostas pelo JMX Prometheus Exporter configurado anteriormente.

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

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

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

Embora o Exportador do Prometheus JMX forneça métricas internas do Kafka, o Exportador do Kafka o complementa ao focar no monitoramento do atraso do consumidor e nos insights ao nível do tópico. Este exportador:

• Controla os deslocamentos do grupo de consumidores e calcula as métricas de retardo.
• Monitora o status do tópico, incluindo partições sub-replicadas.
• Fornece métricas para contagens e tamanhos de mensagens de tópico.

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

Um gráfico do Helm está disponível para implantar o Exportador do Kafka junto com o pipeline de monitoramento 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 Helm prometheus-community 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 arquivo values.yaml para substituir configurações específicas para o gráfico do Helm. O endpoint de bootstrap do Kafka deve ser atualizado antes de executar 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 do Kafka no Grafana.

Conectividade do cliente com o cluster Kafka

Strimzi oferece opções flexíveis para expor seu cluster Kafka aos clientes por meio de ouvintes. Cada ouvinte define como os clientes se conectam aos seus brokers 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 o Kafka aceita conexões.
• O protocolo de segurança (Plano, TLS, SASL).
• Como o ponto de extremidade de conexão é exposto (tipo de serviço do Kubernetes).

O 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 inicialização, 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 agentes que os hospedam.
• Fase 2: em seguida, o cliente estabelece uma nova conexão diretamente com um agente individual usando o endereço anunciado obtido dos metadados.

Isso significa que sua arquitetura de rede deve considerar o serviço de inicialização e a conectividade de agente individual.

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

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

Para aplicativos em execução no mesmo cluster do Kubernetes que o cluster Kafka, exponha o Kafka por meio do ClusterIP:

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

Isso cria um ClusterIP para o serviço de inicialização e os agentes acessíveis somente na rede do Kubernetes.

Opção 2: Acesso externo por meio do Load Balancer Público

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

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

Ao usar essa configuração:

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

Se você quiser usar nomes DNS personalizados, deverá configurar o advertisedHost para cada broker e o alternativeNames para o serviço de inicialização. Isso é necessário para garantir que o Kafka anuncie corretamente o nome de host personalizado de cada corretor de volta para um cliente. Ele também adiciona as informações ao respectivo corretor ou certificado de inicialização, para que possa ser usado para verificação do nome do host no 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 por meio do Balanceador de Carga Privado

Se você quiser acessar o cluster Kafka fora do cluster do AKS, mas dentro de uma rede virtual do Azure, poderá expor o serviço de inicialização e os agentes 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 você quiser usar nomes DNS personalizados, deverá configurar o advertisedHost para cada broker e o alternativeNames para o serviço de inicialização. Isso é necessário para garantir que o Kafka anuncie corretamente o nome do host personalizado que faz backup de cada agente para um cliente. Ele também adiciona as informações ao respectivo agente ou certificado de inicialização para que ele possa ser usado para verificação de nome de host do 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 por meio 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 internos de balanceador de carga com IPs privados para todos os componentes.
• Estabelece um Serviço de Link Privado para o serviço de inicialização e os agentes individuais, respectivamente. Isso habilita a conexão por meio de pontos de extremidade privados de outras redes virtuais.
• Configura o alternativeNames. Isso é necessário para garantir que Strimzi adicione os nomes de serviço de inicialização alternativos ao certificado TLS para que eles possam ser usados para verificação de nome de host do TLS.
• Configura o advertisedHost. Isso é necessário para garantir que o Kafka anuncie a entrada DNS privada do ponto de extremidade privado configurado para cada agente. O advertisedHost também é adicionado ao certificado do intermediário para que possa ser usado na verificação do nome de host para TLS.

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

Contribuidores

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

• Sergio Navar | Engenheiro sênior de clientes
• Erin Schaffer | Desenvolvedora de Conteúdo 2