Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo, implementará el operador de clúster Strimzi y un clúster de Kafka de alta disponibilidad en Azure Kubernetes Service (AKS).
Nota:
Si no ha creado la infraestructura necesaria para esta implementación, siga los pasos descritos en Preparación de la infraestructura para implementar Kafka en Azure Kubernetes Service (AKS) para configurarla y, a continuación, puede volver a este artículo.
Despliegue de Strimzi
El operador de clúster strimzi se implementa en su propio espacio de nombres, strimzi-operatory está configurado para ver el kafka espacio de nombres donde se implementan los componentes del clúster de Kafka. Para lograr una alta disponibilidad, el operador usa:
- Varias réplicas con elección de líder: una réplica actúa como líder activo que administra los recursos implementados, mientras que otras permanecen en espera. Si se produce un error en el líder, se hace cargo de una réplica en espera.
- Distribución zonal: tres réplicas (una por zona de disponibilidad) proporcionan resistencia frente a interrupciones de zona. Las reglas antiafinidad de pod impiden que varias réplicas se programen en la misma zona.
- Pod Disruption Budget: creado automáticamente por el despliegue del operador para garantizar que al menos una réplica permanezca disponible durante las interrupciones voluntarias.
Esta arquitectura garantiza que el operador de clúster strimzi sigue siendo de alta disponibilidad incluso durante el mantenimiento de la infraestructura o interrupciones parciales.
Instalación del operador de clúster de Strimzi mediante Helm
Cree los espacios de nombres para el Operador de Clúster Strimzi y el clúster de Kafka mediante el comando
kubectl create namespace.kubectl create namespace strimzi-operator kubectl create namespace kafkaCon el siguiente script, cree un
values.yamlarchivo para proporcionar configuraciones específicas para el gráfico de 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 el operador de clúster strimzi mediante el
helm installcomando .helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \ --namespace strimzi-operator \ --values values.yamlCompruebe que el Operador de Clúster Strimzi se implementó correctamente y que todos los pods están en un estado de ejecución utilizando el comando
kubectl get.kubectl get pods -n strimzi-operatorEl resultado debería ser similar al ejemplo siguiente:
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
Instalación de Strimzi Drain Cleaner mediante Helm
Strimzi Drain Cleaner garantiza un drenaje suave del nodo de Kubernetes mediante la interceptación de solicitudes de purga para pods de agente, lo que impide que las réplicas de partición de Kafka se vuelvan infra replicadas y mantengan el estado y la confiabilidad del clúster.
Para obtener una alta disponibilidad, implemente Drain Cleaner con varias réplicas en distintas zonas de disponibilidad y configúrelo con presupuestos de interrupciones de pods para garantizar que siga funcionando durante las interrupciones de la zona o las actualizaciones del clúster.
Hay disponible un gráfico de Helm para la instalación de Strimzi Drain Cleaner:
Cree el espacio de nombres para Drain Cleaner usando el comando
kubectl create namespace.kubectl create namespace strimzi-drain-cleanerCree un
values.yamlarchivo para invalidar configuraciones específicas para el gráfico de Helm mediante el siguiente 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 Strimzi Drain Cleaner mediante el
helm installcomando .helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \ --namespace strimzi-drain-cleaner \ --values values.yamlCompruebe que Strimzi Drain Cleaner se implementó correctamente y que todos los pods son un estado en ejecución mediante el
kubectl getcomando.kubectl get pods -n strimzi-drain-cleanerEl resultado debería ser similar al ejemplo siguiente:
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
Consideraciones y arquitectura del clúster de Kafka
El operador de clúster strimzi habilita la implementación declarativa de Kafka en AKS mediante definiciones de recursos personalizados. A partir de Strimzi 0.46, los clústeres de Kafka usan KRaft en Kafka en lugar de ZooKeeper.
Strimzi usa el KafkaNodePool recurso personalizado, donde a cada grupo se le asigna un rol específico (agente, controlador o ambos):
- Los agentes de Kafka controlan el procesamiento y el almacenamiento de mensajes.
- Los controladores de Kafka administran los metadatos de Kafka mediante el protocolo de consenso raft.
Para lograr una alta disponibilidad, la arquitectura de destino se define mediante:
- Independiente
KafkaNodePoolspara agentes y controladores, cada uno con tres réplicas. - Restricciones de propagación de topología que distribuyen pods entre zonas de disponibilidad y nodos.
- Reglas de afinidad de nodo que optimizan el uso de recursos con grupos de nodos específicos.
- Volúmenes persistentes del controlador CSI de disco de Azure con volúmenes independientes para los mensajes y metadatos del broker.
Esta arquitectura mejora la escalabilidad y la tolerancia a errores, al tiempo que permite que los agentes y controladores se escalen de forma independiente para satisfacer los requisitos de carga de trabajo.
Configuración de JVM para clústeres de Kafka de producción
La optimización de la máquina virtual Java (JVM) es fundamental para un rendimiento óptimo del agente y el controlador de Kafka, especialmente en entornos de producción. Las opciones de JVM configuradas correctamente ayudan a maximizar el rendimiento, minimizar la latencia y garantizar la estabilidad bajo una carga pesada para cada agente.
LinkedIn, los creadores de Kafka, han compartido sus argumentos recomendados para ejecutar Kafka en Java para uno de sus clústeres más ocupados: Apache Kafka Java Configuration. En esta guía se usa esta configuración como línea base para los agentes de Kafka. Puede realizar cambios para cumplir los requisitos específicos de la carga de trabajo.
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"
Implementación de grupos de nodos de Kafka
En esta sección, creará dos grupos de nodos de Kafka: uno para agentes y otro para controladores.
Aplique el manifiesto DE YAML para crear los dos grupos de nodos de Kafka mediante el
kubectl applycomando .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
Después de crear los grupos de nodos de Kafka, el siguiente paso es definir un recurso personalizado de clúster de Kafka que enlaza estos grupos a un ecosistema de Kafka en funcionamiento. Esta arquitectura sigue una separación del patrón de preocupaciones, donde los grupos de nodos de Kafka administran los aspectos de la infraestructura mientras que el recurso de clúster de Kafka controla las configuraciones de nivel de aplicación.
Implementación del clúster de Kafka
Antes de crear el clúster de Kafka, cree un configMap que contenga la configuración del exportador de JMX Prometheus mediante el
kubectl applycomando . Este configMap define cómo se transforman y exponen las métricas internas de JMX de Kafka en formato Prometheus, lo que permite una supervisión completa del ecosistema de Kafka. Los patrones definidos en este mapa de configuración asignan rutas de métricas JMX a métricas de Prometheus correctamente formateadas, con los tipos y etiquetas apropiados.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 EOFImplemente el recurso de clúster de Kafka, que conecta los grupos de nodos creados anteriormente en un ecosistema completo de Kafka mediante el
kubectl applycomando . Este recurso personalizado configura los siguientes componentes críticos:- Configuración principal de Kafka: define los factores de replicación, la configuración del agente de escucha y otros parámetros específicos de Kafka.
- Control de crucero: proporciona funcionalidades automatizadas de equilibrio y supervisión de clústeres.
- Operador de entidad: implementa los operadores de tema y usuario que administran temas y usuarios de Kafka mediante declaración a través de recursos de Kubernetes.
- Métricas de JMX: Configura la exposición de las métricas mediante 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: {} EOFUna vez implementado, verifique la implementación de Kafka comprobando que todos los KafkaNodePools, los recursos del clúster de Kafka y sus pods correspondientes se crean y están en ejecución utilizando el comando
kubectl get.kubectl get pods,kafkanodepool,kafka -n kafkaEl resultado debería ser similar al ejemplo siguiente:
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
Creación de un usuario y un tema de Kafka
El operador de entidad Strimzi, implementado con el recurso personalizado del clúster de Kafka, convierte los recursos personalizados de Kubernetes (KafkaTopic y KafkaUser) en recursos reales de Kafka. Esto permite flujos de trabajo de GitOps y una administración de configuración coherente.
Nota:
La creación de temas y usuarios de Kafka mediante declaración mediante el operador de entidad es opcional. También puede crearlos mediante las api o herramientas tradicionales de la CLI de Kafka. Sin embargo, el enfoque declarativo ofrece ventajas como el control de versiones, los seguimientos de auditoría y la administración coherente entre entornos.
Cree un tema de Kafka con el operador topic mediante el
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 EOFCompruebe que el tema de Kafka se creó correctamente mediante el
kubectl getcomando .kubectl get kafkatopic -n kafkaEl resultado debería ser similar al ejemplo siguiente:
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY test-topic kafka-aks-cluster 4 3 TruePara obtener más información, consulte uso del operador de temas para administrar temas de Kafka.
Cree un usuario de Kafka con el operador de usuario mediante el
kubectl applycomando .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 obtener más información, consulte uso del operador de usuario para administrar usuarios de Kafka.
Paso siguiente
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores:
- Sergio Navar | Ingeniero superior de clientes
- Erin Schaffer | Desarrollador de contenido 2