Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Neste artigo, você implantará o Operador de Cluster Strimzi e um cluster Kafka altamente disponível no AKS (Serviço de Kubernetes do Azure).
Observação
Se você ainda não criou a infraestrutura necessária para essa implantação, siga as etapas em Preparar a infraestrutura para implantar o Kafka no AKS (Serviço de Kubernetes do Azure) para ser configurado e, em seguida, você poderá retornar a este artigo.
Implantação do Strimzi
O Operador de Cluster Strimzi é implantado em seu próprio namespace strimzi-operatore está configurado para observar o kafka namespace em que os componentes do cluster Kafka são implantados. Para alta disponibilidade, o operador usa:
- Várias réplicas com eleição de líder: uma réplica serve como o líder ativo gerenciando recursos implantados, enquanto outras permanecem em espera. Se o líder falhar, uma réplica em espera assumirá o comando.
- Distribuição zonal: três réplicas (uma por zona de disponibilidade) fornecem resiliência contra interrupções de zona. As regras antiafinidade do pod impedem que várias réplicas sejam agendadas na mesma zona.
- Orçamento de Interrupção do Pod: 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 namespacecomando.kubectl create namespace strimzi-operator kubectl create namespace kafkaUsando o script a seguir, crie um
values.yamlarquivo para fornecer configurações específicas para o gráfico do 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 EOFInstale o Operador de Cluster Strimzi usando o
helm installcomando.helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \ --namespace strimzi-operator \ --values values.yamlVerifique se o Operador de Cluster Strimzi foi implantado com êxito e se todos os pods estão em execução usando o comando
kubectl get.kubectl get pods -n strimzi-operatorSeu resultado deve ser semelhante ao seguinte exemplo de saída:
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
Instalar o Limpador de Drenagem Strimzi usando o Helm
O Strimzi Drain Cleaner garante a drenagem suave de nós do Kubernetes interceptando solicitações de drenagem para pods de corretor, impedindo que as réplicas de partição Kafka se tornem sub-replicadas e mantendo a integridade e a confiabilidade do cluster.
Para alta disponibilidade, implante o Drain Cleaner com várias réplicas entre zonas de disponibilidade e configure-o com orçamentos de interrupção de pods para garantir que permaneça funcional durante interrupções de zona ou atualizações de cluster.
Um gráfico do Helm está disponível para a instalação do limpador de drenagem Strimzi:
Crie o namespace para o Limpador de Drenagem usando o
kubectl create namespacecomando.kubectl create namespace strimzi-drain-cleanerCrie um arquivo
values.yamlpara substituir configurações específicas para o gráfico do 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 EOFInstale o Strimzi Drain Cleaner usando o
helm installcomando.helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \ --namespace strimzi-drain-cleaner \ --values values.yamlVerifique que o Strimzi Drain Cleaner foi implantado com êxito e que todos os pods estão em execução usando o comando
kubectl get.kubectl get pods -n strimzi-drain-cleanerSeu resultado deve ser semelhante ao seguinte exemplo de saída:
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
Considerações e arquitetura de cluster do Kafka
O Operador de Cluster Strimzi habilita a implantação declarativa do Kafka no AKS usando definições de recurso personalizadas. Começando com Strimzi 0.46, os clusters Kafka usam KRaft no Kafka em vez do ZooKeeper.
Strimzi usa o KafkaNodePool recurso personalizado, em que cada pool recebe uma função específica (agente, controlador ou ambos):
- Os agentes do Kafka lidam com o processamento e o 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
KafkaNodePoolspara agentes 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 a utilização de recursos com pools de nós específicos.
- Volumes persistentes do driver CSI do Disco do Azure, com volumes separados para as mensagens do corretor e os metadados.
Essa arquitetura melhora a escalabilidade e a tolerância a falhas, permitindo que agentes e controladores sejam dimensionados independentemente para atender aos requisitos de carga de trabalho.
Configuração de JVM para clusters Kafka de produção
O ajuste da JVM (Máquina Virtual Java) é essencial para o desempenho ideal do agente kafka e do controlador, especialmente em ambientes de produção. As configurações de JVM definidas corretamente ajudam a maximizar a taxa de transferência, minimizar a latência e garantir a estabilidade sob carga pesada para cada agente.
O LinkedIn, os criadores do Kafka, compartilharam seus argumentos recomendados para executar o Kafka em Java para um de seus clusters mais movimentados: A Configuração Java do Apache Kafka. Este guia usa essa configuração como uma linha de base para os brokers do Kafka. Você pode fazer alterações para atender aos requisitos de carga de trabalho específicos.
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 pools de nós do Kafka
Nesta seção, você criará dois pools de nós Kafka: um para brokers e outro para controladores.
Aplique o manifesto YAML para criar os dois pools de nós Kafka usando o comando
kubectl apply.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 do Kafka, a próxima etapa é definir um recurso personalizado do cluster Kafka que associa esses pools a um ecossistema kafka em funcionamento. Essa arquitetura segue um padrão de separação de preocupações, em que os pools de nós do Kafka gerenciam os aspectos de infraestrutura enquanto o recurso de cluster do Kafka lida com as 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 Exportador do Prometheus JMX usando o
kubectl applycomando. Esse ConfigMap define como as métricas internas do JMX do Kafka são transformadas e expostas no formato Prometheus, permitindo o monitoramento completo do ecossistema Kafka. Os padrões definidos nesta configuração mapeiam caminhos de métrica JMX para métricas Prometheus formatadas corretamente 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 EOFImplante o recurso de cluster Kafka, que conecta os pools de nós criados anteriormente em um ecossistema Kafka completo, usando o comando
kubectl apply. Esse recurso personalizado configura os seguintes componentes críticos:- Configuração principal do Kafka: define fatores de replicação, configurações do ouvinte e outros parâmetros específicos do Kafka.
- Cruise Control: oferece recursos automatizados de balanceamento e monitoramento de cluster.
- Operador de entidade: implanta os operadores de tópico e de usuário que gerenciam os 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 o ConfigMaps definido 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: {} EOFDepois de implantado, verifique sua implantação do Kafka assegurando-se de que todos os KafkaNodePools, recursos de cluster Kafka e seus pods correspondentes foram criados e estão em execução usando o comando
kubectl get.kubectl get pods,kafkanodepool,kafka -n kafkaSeu resultado deve ser semelhante ao seguinte exemplo de saída:
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 um tópico do Kafka
O Operador de Entidade Strimzi, implantado com o recurso personalizado do cluster Kafka, converte recursos personalizados do Kubernetes (KafkaTopic e KafkaUser) em recursos reais do Kafka. Isso permite fluxos de trabalho do GitOps e gerenciamento de configuração consistente.
Observação
Criar tópicos e usuários do Kafka declarativamente usando o Operador de Entidade é opcional. Você também pode criá-los usando apIs ou ferramentas 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 applycomando.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 EOFVerifique se o Tópico do Kafka foi criado com êxito usando o
kubectl getcomando.kubectl get kafkatopic -n kafkaSeu resultado deve ser semelhante ao seguinte exemplo de saída:
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY test-topic kafka-aks-cluster 4 3 TruePara obter mais informações, consulte como usar o Operador de Tópico para gerenciar tópicos do Kafka.
Crie um usuário do 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: "*" EOFPara obter mais informações, consulte como usar o Operador de Usuário para gerenciar usuários do Kafka.
Próxima etapa
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