Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo illustra come distribuire l'operatore cluster Strimzi e un cluster Kafka a disponibilità elevata nel servizio Azure Kubernetes.
Nota
Se non è stata creata l'infrastruttura necessaria per questa distribuzione, seguire la procedura descritta in Preparare l'infrastruttura per la distribuzione di Kafka nel servizio Azure Kubernetes per configurare e quindi tornare a questo articolo.
Distribuzione di Strimzi
L'operatore cluster Strimzi viene distribuito nel proprio spazio dei nomi, strimzi-operatore viene configurato per controllare lo kafka spazio dei nomi in cui vengono distribuiti i componenti del cluster Kafka. Per la disponibilità elevata, l'operatore usa:
- Più repliche con elezione del leader: una replica funge da leader attivo che gestisce le risorse implementate, mentre altre rimangono in standby. Se il leader ha esito negativo, una replica di standby assume il controllo.
- Distribuzione di zona: tre repliche (una per zona di disponibilità) offrono resilienza in caso di interruzioni della zona. Le regole anti-affinità dei pod impediscono la pianificazione di più repliche nella stessa zona.
- Budget interruzione pod: creato automaticamente dalla distribuzione dell'operatore per garantire che almeno una replica rimanga disponibile durante le interruzioni volontarie.
Questa architettura garantisce che l'operatore cluster Strimzi rimanga a disponibilità elevata anche durante la manutenzione dell'infrastruttura o interruzioni parziali.
Installare l'operatore cluster Strimzi con Helm
Creare gli spazi dei nomi per l'operatore cluster Strimzi e il cluster Kafka usando il comando
kubectl create namespace.kubectl create namespace strimzi-operator kubectl create namespace kafkaUsando lo script seguente, creare un
values.yamlfile per fornire configurazioni specifiche per il grafico 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 EOFInstallare l'operatore cluster Strimzi usando il
helm installcomando .helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \ --namespace strimzi-operator \ --values values.yamlVerificare che l'operatore cluster Strimzi sia stato distribuito correttamente e che tutti i pod siano in esecuzione usando il
kubectl getcomando .kubectl get pods -n strimzi-operatorL'output dovrebbe essere simile all'esempio di output seguente:
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
Installare Strimzi Drain Cleaner con Helm
Strimzi Drain Cleaner garantisce lo svuotamento lineare del nodo Kubernetes intercettando le richieste di svuotamento per i pod broker, in modo da impedire alle repliche di partizione Kafka di diventare sotto replicate, mantenendo l'integrità e l'affidabilità del cluster.
Per la disponibilità elevata, distribuire Drain Cleaner con più repliche tra le zone di disponibilità e configurarlo con budget di interruzione dei pod per assicurare il suo funzionamento continuo durante le interruzioni della zona o gli aggiornamenti del cluster.
Per l'installazione di Strimzi Drain Cleaner è disponibile un grafico Helm:
Creare lo spazio dei nomi per Drain Cleaner usando il comando
kubectl create namespace.kubectl create namespace strimzi-drain-cleanerCreare un
values.yamlfile per eseguire l'override di configurazioni specifiche per il grafico Helm usando lo script seguente: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 EOFInstallare Strimzi Drain Cleaner usando il
helm installcomando .helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \ --namespace strimzi-drain-cleaner \ --values values.yamlVerificare che Strimzi Drain Cleaner sia stato distribuito correttamente e che tutti i pod siano in esecuzione usando il
kubectl getcomando .kubectl get pods -n strimzi-drain-cleanerL'output dovrebbe essere simile all'esempio di output seguente:
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
Architettura e considerazioni sul cluster Kafka
L'operatore cluster Strimzi abilita la distribuzione dichiarativa di Kafka nel servizio Azure Kubernetes usando definizioni di risorse personalizzate. A partire da Strimzi 0.46, i cluster Kafka usano KRaft all'interno di Kafka anziché ZooKeeper.
Strimzi usa la KafkaNodePool risorsa personalizzata, in cui a ogni pool viene assegnato un ruolo specifico (broker, controller o entrambi):
- I broker Kafka gestiscono l'elaborazione e l'archiviazione dei messaggi.
- I controller Kafka gestiscono i metadati Kafka usando il protocollo di consenso Raft.
Per la disponibilità elevata, l'architettura di destinazione è definita da:
- Separare
KafkaNodePoolsper broker e controller, ognuno con tre repliche. - Vincoli di distribuzione della topologia che distribuiscono i pod tra zone di disponibilità e nodi.
- Regole di affinità dei nodi che ottimizzano l'utilizzo delle risorse con pool di nodi specifici.
- Volumi persistenti dal driver CSI del disco di Azure con volumi separati per i messaggi e i metadati del broker.
Questa architettura migliora la scalabilità e la tolleranza di errore, consentendo al contempo la scalabilità indipendente di broker e controller per soddisfare i requisiti del carico di lavoro.
Configurazione di JVM per i cluster Kafka di produzione
L'ottimizzazione della macchina virtuale Java (JVM) è fondamentale per ottenere prestazioni ottimali del broker e del controller Kafka, in particolare negli ambienti di produzione. Le impostazioni JVM configurate correttamente consentono di ottimizzare la velocità effettiva, ridurre al minimo la latenza e garantire la stabilità in condizioni di carico elevato per ogni broker.
LinkedIn, creatori di Kafka, ha condiviso gli argomenti consigliati per l'esecuzione di Kafka in Java per uno dei cluster più trafficati: Apache Kafka Java Configuration. Questa guida usa questa configurazione come baseline per i broker Kafka. È possibile apportare modifiche per soddisfare i requisiti specifici del carico di lavoro.
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"
Distribuire pool di nodi Kafka
In questa sezione vengono creati due pool di nodi Kafka: uno per i broker e uno per i controller.
Applicare il manifesto YAML per creare i due pool di nodi Kafka usando il
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
Dopo aver creato i pool di nodi Kafka, il passaggio successivo consiste nel definire una risorsa personalizzata del cluster Kafka che associa questi pool a un ecosistema Kafka funzionante. Questa architettura segue un modello di separazione dei problemi, in cui i pool di nodi Kafka gestiscono gli aspetti dell'infrastruttura mentre la risorsa cluster Kafka gestisce le configurazioni a livello di applicazione.
Distribuire il cluster Kafka
Prima di creare il cluster Kafka, creare un oggetto ConfigMap contenente la configurazione JMX Prometheus Exporter usando il
kubectl applycomando . Questo ConfigMap definisce il modo in cui le metriche JMX interne di Kafka vengono trasformate ed esposte in formato Prometheus, consentendo il monitoraggio completo dell'ecosistema Kafka. I modelli definiti in questa configurazione mappano i percorsi delle metriche JMX a metriche Prometheus correttamente formattate, con tipi ed etichette appropriate.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 EOFDistribuire la risorsa cluster Kafka, che connette i pool di nodi creati in precedenza in un ecosistema Kafka completo, usando il
kubectl applycomando . Questa risorsa personalizzata configura i componenti critici seguenti:- Configurazione di base Kafka: definisce i fattori di replica, le impostazioni del listener e altri parametri specifici di Kafka.
- Cruise Control: offre funzionalità automatizzate di bilanciamento e monitoraggio dei cluster.
- Operatore entità: distribuisce gli argomenti e gli operatori utente che gestiscono gli argomenti Kafka e gli utenti in modo dichiarativo tramite risorse Kubernetes.
- Metriche JMX: configura l'esposizione delle metriche usando gli oggetti ConfigMap definiti in precedenza.
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: {} EOFDopo la distribuzione, verificare la distribuzione Kafka controllando che tutti i KafkaNodePools, le risorse del cluster Kafka e i pod corrispondenti vengano creati e che siano in esecuzione usando il comando
kubectl get.kubectl get pods,kafkanodepool,kafka -n kafkaL'output dovrebbe essere simile all'esempio di output seguente:
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
Creare un utente e un argomento Kafka
L'operatore di entità Strimzi, distribuito con la risorsa personalizzata del cluster Kafka, converte le risorse personalizzate kubernetes (KafkaTopic e KafkaUser) in risorse Kafka effettive. Questo consente i flussi di lavoro GitOps e una gestione uniforme della configurazione.
Nota
La creazione di argomenti e utenti Kafka in modo dichiarativo tramite l'operatore di entità è facoltativa. È anche possibile crearli usando gli strumenti o le API tradizionali dell'interfaccia della riga di comando di Kafka. Tuttavia, l'approccio dichiarativo offre vantaggi come il controllo della versione, i audit trail e la gestione coerente tra gli ambienti.
Creare un argomento Kafka con l'operatore topic usando il
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 EOFVerificare che l'argomento Kafka sia stato creato correttamente usando il
kubectl getcomando .kubectl get kafkatopic -n kafkaL'output dovrebbe essere simile all'esempio di output seguente:
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY test-topic kafka-aks-cluster 4 3 TruePer ulteriori informazioni, vedere l'uso dell'operatore Topic per gestire i topic Kafka.
Creare un utente Kafka con l'operatore utente usando il
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: "*" EOFPer altre informazioni, vedere Uso dell'operatore utente per gestire gli utenti Kafka.
Passaggio successivo
Contributori
Microsoft gestisce questo articolo. I collaboratori seguenti l'hanno originariamente scritto:
- Sergio Navar | Senior Customer Engineer
- Erin Schaffer | Sviluppatore di contenuti 2