Configurar e implantar componentes Strimzi e Kafka no Serviço Kubernetes do Azure (AKS)

Neste artigo, você implanta o Operador de Cluster Strimzi e um cluster Kafka altamente disponível no Serviço Kubernetes do Azure (AKS).

Observação

Se você não criou a infraestrutura necessária para essa implantação, siga as etapas em Preparar a infraestrutura para implantar o Kafka no Serviço Kubernetes do Azure (AKS) para ser configurado e, em seguida, você pode retornar a este artigo.

Implantação do Strimzi

O Operador de Cluster Strimzi é implantado em seu próprio namespace strimzi-operatore configurado para observar o kafka namespace onde os componentes do cluster Kafka são implantados. Para alta disponibilidade, o operador utiliza:

Várias réplicas com eleição de líder: uma réplica serve como líder ativo gerenciando recursos implantados, enquanto outras permanecem em espera. Se o líder falhar, uma réplica em standby assume o controle.
Distribuição zonal: Três réplicas (uma por zona de disponibilidade) proporcionam resiliência contra falhas de zona. Regras de antiafinidade do pod impedem que múltiplas réplicas sejam agendadas na mesma zona.
Pod Disruption Budget: criado automaticamente pela implantação do operador para garantir que pelo menos uma réplica permaneça disponível durante interrupções voluntárias.

Essa arquitetura garante que o Operador de Cluster Strimzi permaneça altamente disponível mesmo durante a manutenção da infraestrutura ou interrupções parciais.

Instalar o Operador de Cluster Strimzi usando o Helm

Crie os namespaces para o Operador de Cluster Strimzi e o cluster Kafka usando o kubectl create namespace comando.
```
kubectl create namespace strimzi-operator  
kubectl create namespace kafka  
```

Usando o script a seguir, crie um values.yaml arquivo para fornecer configurações específicas para o gráfico Helm:

cat <<EOF > values.yaml  
replicas: 3  
watchNamespaces: 
  - kafka  
leaderElection:  
  enabled: true  
podDisruptionBudget:  
  enabled: true  
affinity:  
  podAntiAffinity:  
    requiredDuringSchedulingIgnoredDuringExecution:  
      - labelSelector:  
          matchExpressions:  
            - key: name  
              operator: In  
              values:  
                - strimzi-cluster-operator  
        topologyKey: topology.kubernetes.io/zone  
EOF

Instale o Operador de Cluster Strimzi usando o helm install comando.

helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \
--namespace strimzi-operator \
--values values.yaml

Verifique se o Operador de Cluster Strimzi foi implantado com êxito e se todos os pods estão em um estado de execução usando o kubectl get comando.

kubectl get pods -n strimzi-operator

Sua saída deve ser semelhante à saída de exemplo a seguir:

NAME                                        READY   STATUS    RESTARTS      AGE  
strimzi-cluster-operator-6f7588bb79-bvfdp   1/1     Running   0             1d22h  
strimzi-cluster-operator-6f7588bb79-lfcp6   1/1     Running   0             1d22h  
strimzi-cluster-operator-6f7588bb79-qdlm8   1/1     Running   0             1d22h

Instale o Strimzi Drain Cleaner usando o Helm

O Strimzi Drain Cleaner garante a drenagem suave do nó Kubernetes intercetando solicitações de drenagem para pods de broker, o que evita que réplicas de partição Kafka se tornem sub-replicadas e mantém a integridade e a confiabilidade do cluster.

Para alta disponibilidade, implemente o Drain Cleaner com múltiplas réplicas distribuídas por várias zonas de disponibilidade e configure-o com orçamentos de interrupção de pod para garantir que se mantém funcional durante falhas de zona ou atualizações do cluster.

Está disponível um Helm chart para a instalação do Strimzi Drain Cleaner.

Crie o namespace para Drain Cleaner usando o kubectl create namespace comando.
```
kubectl create namespace strimzi-drain-cleaner  
```

Crie um values.yaml arquivo para substituir configurações específicas para o gráfico Helm usando o seguinte script:

cat <<EOF > values.yaml  
replicaCount: 3  
namespace:  
  create: false  
podDisruptionBudget:  
  create: true  
affinity:  
  podAntiAffinity:  
    requiredDuringSchedulingIgnoredDuringExecution:  
      - labelSelector:  
          matchExpressions:  
            - key: app  
              operator: In  
              values:  
                - strimzi-drain-cleaner  
        topologyKey: topology.kubernetes.io/zone  
EOF

Instale o Strimzi Drain Cleaner usando o helm install comando.

helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \
--namespace strimzi-drain-cleaner \
--values values.yaml

Verifique se o Strimzi Drain Cleaner foi implantado com êxito e se todos os pods estão em um estado de execução usando o kubectl get comando.

kubectl get pods -n strimzi-drain-cleaner

Sua saída deve ser semelhante à saída de exemplo a seguir:

NAME                                     READY   STATUS    RESTARTS   AGE  
strimzi-drain-cleaner-6d694bd55b-dshkp   1/1     Running   0          1d22h  
strimzi-drain-cleaner-6d694bd55b-l8cbf   1/1     Running   0          1d22h  
strimzi-drain-cleaner-6d694bd55b-wj6xx   1/1     Running   0          1d22h

Arquitetura e considerações do cluster Kafka

O Operador de Cluster Strimzi permite a implantação declarativa do Kafka no AKS usando definições de recursos personalizadas. Começando com Strimzi 0.46, os clusters Kafka usam KRaft dentro de Kafka em vez de ZooKeeper.

Strimzi usa o KafkaNodePool recurso personalizado, onde cada pool recebe uma função específica (broker, controller ou ambos):

Os corretores Kafka lidam com o processamento e armazenamento de mensagens.
Os controladores Kafka gerenciam metadados Kafka usando o protocolo de consenso Raft.

Para alta disponibilidade, a arquitetura de destino é definida por:

Separe KafkaNodePools para intermediários e controladores, cada um com três réplicas.
Restrições de propagação de topologia que distribuem pods entre zonas de disponibilidade e nós.
Regras de afinidade de nó que otimizam o uso de recursos em pools de nós específicos.
Volumes persistentes do driver CSI de disco do Azure, com volumes separados para mensagens e metadados do intermediário.

Essa arquitetura melhora a escalabilidade e a tolerância a falhas, permitindo que corretores e controladores sejam dimensionados de forma independente para atender aos requisitos de carga de trabalho.

Configuração da JVM para clusters Kafka de produção

O ajuste da Java Virtual Machine (JVM) é fundamental para o desempenho ideal do broker e controlador Kafka, especialmente em ambientes de produção. As configurações da JVM configuradas corretamente ajudam a maximizar a taxa de transferência, minimizar a latência e garantir a estabilidade sob carga pesada para cada broker.

O LinkedIn, os criadores do Kafka, compartilharam seus argumentos recomendados para executar o Kafka em Java para um de seus clusters mais movimentados: Apache Kafka Java Configuration. Este guia usa essa configuração como uma linha de base para os corretores Kafka. Você pode fazer alterações para atender aos seus requisitos específicos de carga de trabalho.

jvmOptions:
  # Sets initial and maximum heap size to 6GB - critical for memory-intensive Kafka operations
  # Equal sizing prevents resizing pauses
  "-Xms": "6g"
  "-Xmx": "6g"
  "-XX":
    # Initial metaspace size (class metadata storage area) at 96MB
    "MetaspaceSize": "96m"
    
    # Enables the Garbage-First (G1) garbage collector, optimized for better predictability and lower pause times
    "UseG1GC": "true"
    
    # Targets maximum GC pause time of 20ms - keeps latency predictable
    "MaxGCPauseMillis": "20"
    
    # Starts concurrent GC cycle when heap is 35% full - balances CPU overhead and frequency
    "InitiatingHeapOccupancyPercent": "35"
    
    # Sets G1 heap region size to 16MB - affects collection efficiency and pause times
    "G1HeapRegionSize": "16M"
    
    # Keeps at least 50% free space after metaspace GC - prevents frequent resizing
    "MinMetaspaceFreeRatio": "50"
    
    # Limits expansion to allow up to 80% free space in metaspace after GC
    "MaxMetaspaceFreeRatio": "80"
    
    # Makes explicit System.gc() calls run concurrently instead of stopping all threads
    "ExplicitGCInvokesConcurrent": "true"

Implantar grupos de nós Kafka

Nesta seção, você cria dois pools de nós Kafka: um para corretores e outro para controladores.

Aplique o manifesto YAML para criar os dois pools de nós Kafka usando o kubectl apply comando.

kubectl apply -n kafka -f - <<EOF
---
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: controller
  labels:
    strimzi.io/cluster: kafka-aks-cluster
spec:
  replicas: 3
  roles:
    - controller
  resources:
    requests:
      memory: 4Gi
    limits:
      memory: 6Gi
  template:
    pod:
      metadata:
        labels:
          kafkaRole: controller
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - kafka
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    kafkaRole: broker
                topologyKey: kubernetes.io/hostname
      topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              kafkaRole: controller
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
        - labelSelector:
            matchLabels:
              kafkaRole: controller
          maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 25Gi
        kraftMetadata: shared
        deleteClaim: false
        class: kafka-premium-ssd-v2
  jvmOptions:
    "-Xms": "3g"
    "-Xmx": "3g"
    "-XX":
      "MetaspaceSize": "96m"
      "UseG1GC": "true"
      "MaxGCPauseMillis": "20"
      "InitiatingHeapOccupancyPercent": "35"
      "G1HeapRegionSize": "16M"
      "MinMetaspaceFreeRatio": "50"
      "MaxMetaspaceFreeRatio": "80"
      "ExplicitGCInvokesConcurrent": "true" 
---
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: broker
  labels:
    strimzi.io/cluster: kafka-aks-cluster
spec:
  replicas: 3
  roles:
    - broker
  resources:
    requests:
      memory: 8Gi
    limits:
      memory: 10Gi
  template:
    pod:
      metadata:
        labels:
          kafkaRole: broker
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - kafka
        podAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    kafkaRole: controller
                topologyKey: kubernetes.io/hostname
      topologySpreadConstraints:
        - labelSelector:
            matchLabels:
              kafkaRole: broker
          maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
        - labelSelector:
            matchLabels:
              kafkaRole: broker
          maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway 
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 50Gi
        deleteClaim: false
        class: kafka-premium-ssd-v2
      - id: 1
        type: persistent-claim
        size: 25Gi
        kraftMetadata: shared
        deleteClaim: false
        class: kafka-premium-ssd-v2
  jvmOptions:
    "-Xms": "6g"
    "-Xmx": "6g"
    "-XX":
      "MetaspaceSize": "96m"
      "UseG1GC": "true"
      "MaxGCPauseMillis": "20"
      "InitiatingHeapOccupancyPercent": "35"
      "G1HeapRegionSize": "16M"
      "MinMetaspaceFreeRatio": "50"
      "MaxMetaspaceFreeRatio": "80"
      "ExplicitGCInvokesConcurrent": "true"
EOF

Depois de criar os pools de nós Kafka, a próxima etapa é definir um recurso personalizado de cluster Kafka que vincule esses pools em um ecossistema Kafka funcional. Essa arquitetura segue um padrão de separação de preocupações, onde os pools de nós Kafka gerenciam os aspetos da infraestrutura, enquanto o recurso de cluster Kafka lida com configurações no nível do aplicativo.

Implantar o cluster Kafka

Antes de criar o cluster Kafka, crie um ConfigMap que contenha a configuração do JMX Prometheus Exporter usando o kubectl apply comando. Este ConfigMap define como as métricas JMX internas do Kafka são transformadas e expostas no formato Prometheus, permitindo o monitoramento abrangente do seu ecossistema Kafka. Os padrões definidos nesta configuração mapeiam caminhos de métricas JMX para métricas Prometheus devidamente formatadas com tipos e rótulos apropriados.

kubectl apply -n kafka -f - <<'EOF'
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: kafka-metrics
  labels:
    app: strimzi
data:
  kafka-metrics-config.yaml: |
    # See https://github.com/prometheus/jmx_exporter for more info about JMX Prometheus Exporter metrics
    lowercaseOutputName: true
    rules:
    # Special cases and very specific rules
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
        clientId: "$3"
        topic: "$4"
        partition: "$5"
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), brokerHost=(.+), brokerPort=(.+)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
        clientId: "$3"
        broker: "$4:$5"
    - pattern: kafka.server<type=(.+), cipher=(.+), protocol=(.+), listener=(.+), networkProcessor=(.+)><>connections
      name: kafka_server_$1_connections_tls_info
      type: GAUGE
      labels:
        cipher: "$2"
        protocol: "$3"
        listener: "$4"
        networkProcessor: "$5"
    - pattern: kafka.server<type=(.+), clientSoftwareName=(.+), clientSoftwareVersion=(.+), listener=(.+), networkProcessor=(.+)><>connections
      name: kafka_server_$1_connections_software
      type: GAUGE
      labels:
        clientSoftwareName: "$2"
        clientSoftwareVersion: "$3"
        listener: "$4"
        networkProcessor: "$5"
    - pattern: "kafka.server<type=(.+), listener=(.+), networkProcessor=(.+)><>(.+-total):"
      name: kafka_server_$1_$4
      type: COUNTER
      labels:
        listener: "$2"
        networkProcessor: "$3"
    - pattern: "kafka.server<type=(.+), listener=(.+), networkProcessor=(.+)><>(.+):"
      name: kafka_server_$1_$4
      type: GAUGE
      labels:
        listener: "$2"
        networkProcessor: "$3"
    - pattern: kafka.server<type=(.+), listener=(.+), networkProcessor=(.+)><>(.+-total)
      name: kafka_server_$1_$4
      type: COUNTER
      labels:
        listener: "$2"
        networkProcessor: "$3"
    - pattern: kafka.server<type=(.+), listener=(.+), networkProcessor=(.+)><>(.+)
      name: kafka_server_$1_$4
      type: GAUGE
      labels:
        listener: "$2"
        networkProcessor: "$3"
    # Some percent metrics use MeanRate attribute
    # Ex) kafka.server<type=(KafkaRequestHandlerPool), name=(RequestHandlerAvgIdlePercent)><>MeanRate
    - pattern: kafka.(\w+)<type=(.+), name=(.+)Percent\w*><>MeanRate
      name: kafka_$1_$2_$3_percent
      type: GAUGE
    # Generic gauges for percents
    - pattern: kafka.(\w+)<type=(.+), name=(.+)Percent\w*><>Value
      name: kafka_$1_$2_$3_percent
      type: GAUGE
    - pattern: kafka.(\w+)<type=(.+), name=(.+)Percent\w*, (.+)=(.+)><>Value
      name: kafka_$1_$2_$3_percent
      type: GAUGE
      labels:
        "$4": "$5"
    # Generic per-second counters with 0-2 key/value pairs
    - pattern: kafka.(\w+)<type=(.+), name=(.+)PerSec\w*, (.+)=(.+), (.+)=(.+)><>Count
      name: kafka_$1_$2_$3_total
      type: COUNTER
      labels:
        "$4": "$5"
        "$6": "$7"
    - pattern: kafka.(\w+)<type=(.+), name=(.+)PerSec\w*, (.+)=(.+)><>Count
      name: kafka_$1_$2_$3_total
      type: COUNTER
      labels:
        "$4": "$5"
    - pattern: kafka.(\w+)<type=(.+), name=(.+)PerSec\w*><>Count
      name: kafka_$1_$2_$3_total
      type: COUNTER
    # Generic gauges with 0-2 key/value pairs
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.+), (.+)=(.+)><>Value
      name: kafka_$1_$2_$3
      type: GAUGE
      labels:
        "$4": "$5"
        "$6": "$7"
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.+)><>Value
      name: kafka_$1_$2_$3
      type: GAUGE
      labels:
        "$4": "$5"
    - pattern: kafka.(\w+)<type=(.+), name=(.+)><>Value
      name: kafka_$1_$2_$3
      type: GAUGE
    # Emulate Prometheus 'Summary' metrics for the exported 'Histogram's.
    # Note that these are missing the '_sum' metric!
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.+), (.+)=(.+)><>Count
      name: kafka_$1_$2_$3_count
      type: COUNTER
      labels:
        "$4": "$5"
        "$6": "$7"
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.*), (.+)=(.+)><>(\d+)thPercentile
      name: kafka_$1_$2_$3
      type: GAUGE
      labels:
        "$4": "$5"
        "$6": "$7"
        quantile: "0.$8"
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.+)><>Count
      name: kafka_$1_$2_$3_count
      type: COUNTER
      labels:
        "$4": "$5"
    - pattern: kafka.(\w+)<type=(.+), name=(.+), (.+)=(.*)><>(\d+)thPercentile
      name: kafka_$1_$2_$3
      type: GAUGE
      labels:
        "$4": "$5"
        quantile: "0.$6"
    - pattern: kafka.(\w+)<type=(.+), name=(.+)><>Count
      name: kafka_$1_$2_$3_count
      type: COUNTER
    - pattern: kafka.(\w+)<type=(.+), name=(.+)><>(\d+)thPercentile
      name: kafka_$1_$2_$3
      type: GAUGE
      labels:
        quantile: "0.$4"
    # KRaft overall related metrics
    # distinguish between always increasing COUNTER (total and max) and variable GAUGE (all others) metrics
    - pattern: "kafka.server<type=raft-metrics><>(.+-total|.+-max):"
      name: kafka_server_raftmetrics_$1
      type: COUNTER
    - pattern: "kafka.server<type=raft-metrics><>(current-state): (.+)"
      name: kafka_server_raftmetrics_$1
      value: 1
      type: UNTYPED
      labels:
        $1: "$2"
    - pattern: "kafka.server<type=raft-metrics><>(.+):"
      name: kafka_server_raftmetrics_$1
      type: GAUGE
    # KRaft "low level" channels related metrics
    # distinguish between always increasing COUNTER (total and max) and variable GAUGE (all others) metrics
    - pattern: "kafka.server<type=raft-channel-metrics><>(.+-total|.+-max):"
      name: kafka_server_raftchannelmetrics_$1
      type: COUNTER
    - pattern: "kafka.server<type=raft-channel-metrics><>(.+):"
      name: kafka_server_raftchannelmetrics_$1
      type: GAUGE
    # Broker metrics related to fetching metadata topic records in KRaft mode
    - pattern: "kafka.server<type=broker-metadata-metrics><>(.+):"
      name: kafka_server_brokermetadatametrics_$1
      type: GAUGE
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cruise-control-metrics
  labels:
    app: strimzi
data:
  metrics-config.yaml: |
    # See https://github.com/prometheus/jmx_exporter for more info about JMX Prometheus Exporter metrics
    lowercaseOutputName: true
    rules:
    - pattern: kafka.cruisecontrol<name=(.+)><>(\w+)
      name: kafka_cruisecontrol_$1_$2
      type: GAUGE
EOF

Implante o recurso de cluster Kafka, que conecta os pools de nós criados anteriormente em um ecossistema Kafka completo, usando o kubectl apply comando. Este recurso personalizado configura os seguintes componentes críticos:

Configuração do núcleo do Kafka: define fatores de replicação, configurações do ouvinte e outros parâmetros específicos do Kafka.
Cruise Control: Fornece recursos automatizados de balanceamento e monitoramento de clusters.
Operador de Entidade: Implanta os Operadores de Tópico e Usuário que gerenciam tópicos e usuários do Kafka declarativamente por meio de recursos do Kubernetes.
Métricas JMX: Configura a exposição de métricas usando os ConfigMaps definidos anteriormente.

kubectl apply -n kafka -f - <<EOF
---
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: kafka-aks-cluster
  annotations:
    strimzi.io/node-pools: enabled
    strimzi.io/kraft: enabled
spec:
  kafka:
    version: 3.9.0
    metadataVersion: 3.9-IV0
    rack:
      topologyKey: topology.kubernetes.io/zone
    template:
      podDisruptionBudget:
        maxUnavailable: 2
    listeners:
      - name: internal
        port: 9092
        type: internal
        tls: true
    config:
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
      default.replication.factor: 3
      min.insync.replicas: 2
      log.segment.bytes: 1073741824  
      log.retention.hours: 168  
      log.retention.check.interval.ms: 300000 
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: kafka-metrics
          key: kafka-metrics-config.yaml
  cruiseControl:
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: cruise-control-metrics
          key: metrics-config.yaml
  entityOperator:
    topicOperator: {}
    userOperator: {}
EOF

Uma vez implantado, verifique sua implantação do Kafka verificando se todos os KafkaNodePools, recursos de cluster Kafka e seus pods correspondentes estão criados e em um estado de execução usando o kubectl get comando.

kubectl get pods,kafkanodepool,kafka -n kafka

Sua saída deve ser semelhante à saída de exemplo a seguir:

NAME                                                     READY   STATUS    RESTARTS   AGE
pod/kafka-aks-cluster-broker-0                           1/1     Running   0          1d22h
pod/kafka-aks-cluster-broker-1                           1/1     Running   0          1d22h
pod/kafka-aks-cluster-broker-2                           1/1     Running   0          1d22h
pod/kafka-aks-cluster-controller-3                       1/1     Running   0          1d22h
pod/kafka-aks-cluster-controller-4                       1/1     Running   0          1d22h
pod/kafka-aks-cluster-controller-5                       1/1     Running   0          1d22h
pod/kafka-aks-cluster-cruise-control-844b69848-87rf6     1/1     Running   0          1d22h
pod/kafka-aks-cluster-entity-operator-6f949f6774-t8wql   2/2     Running   0          1d22h

NAME                                        DESIRED REPLICAS   ROLES            NODEIDS
kafkanodepool.kafka.strimzi.io/broker       3                  ["broker"]       [0,1,2]
kafkanodepool.kafka.strimzi.io/controller   3                  ["controller"]   [3,4,5]

NAME                                       DESIRED KAFKA REPLICAS   DESIRED ZK REPLICAS   READY   METADATA STATE   WARNINGS
kafka.kafka.strimzi.io/kafka-aks-cluster

Criar um usuário e tópico Kafka

O Operador de Entidade Strimzi, implantado com o recurso personalizado de cluster Kafka, traduz recursos personalizados do Kubernetes (KafkaTopic e KafkaUser) em recursos Kafka reais. Isso permite fluxos de trabalho GitOps e gerenciamento de configuração consistente.

Observação

A criação declarativa de Tópicos e Usuários do Kafka usando o Operador de Entidade é opcional. Você também pode criá-los usando ferramentas ou APIs tradicionais da CLI do Kafka. No entanto, a abordagem declarativa oferece benefícios como controle de versão, trilhas de auditoria e gerenciamento consistente entre ambientes.

Crie um Tópico Kafka com o Operador de Tópico usando o kubectl apply comando.

kubectl apply -n kafka -f - << EOF  
apiVersion: kafka.strimzi.io/v1beta2  
kind: KafkaTopic  
metadata:  
  name: test-topic  
  labels:  
    strimzi.io/cluster: kafka-aks-cluster 
spec:  
  replicas: 3  
  partitions: 4  
  config:  
    retention.ms: 7200000  
    segment.bytes: 1073741824  
EOF

Verifique se o tópico Kafka foi criado com êxito usando o kubectl get comando.
```
kubectl get kafkatopic -n kafka  
```
Sua saída deve ser semelhante à saída de exemplo a seguir:
```
NAME         CLUSTER             PARTITIONS   REPLICATION FACTOR   READY  
test-topic   kafka-aks-cluster   4            3                    True  
```
Para obter mais informações, consulte Usando o Operador de tópico para gerenciar tópicos do Kafka.

Crie um usuário Kafka com o operador de usuário usando o comando kubectl apply.

kubectl apply -f - <<EOF  
apiVersion: kafka.strimzi.io/v1beta2  
kind: KafkaUser  
metadata:  
  name: test-user  
  labels:  
    strimzi.io/cluster: kafka-aks-cluster  
spec:  
  authentication:  
    type: tls  
  authorization:  
    type: simple  
    acls:  
      - resource:  
          type: topic  
          name: test-topic  
          patternType: literal  
        operations:  
          - Describe  
          - Read  
        host: "*"  
      - resource:  
          type: group  
          name: test-group  
          patternType: literal  
        operations:  
          - Read  
        host: "*"  
      - resource:  
          type: topic  
          name: test-topic  
          patternType: literal  
        operations:  
          - Create  
          - Describe  
          - Write  
        host: "*"  
EOF

Para obter mais informações, consulte Usando o Operador de Usuário para gerenciar usuários do Kafka.

Próximo passo

Configurar monitoramento e rede para um cluster Kafka no AKS usando o Operador Strimzi

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

Comentários

Esta página foi útil?

Last updated on 2025-09-19

Configurar e implantar componentes Strimzi e Kafka no Serviço Kubernetes do Azure (AKS)

Implantação do Strimzi

Instalar o Operador de Cluster Strimzi usando o Helm

Instale o Strimzi Drain Cleaner usando o Helm

Arquitetura e considerações do cluster Kafka

Configuração da JVM para clusters Kafka de produção

Implantar grupos de nós Kafka

Implantar o cluster Kafka

Criar um usuário e tópico Kafka

Próximo passo

Contribuidores

Comentários

Recursos adicionais