Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel stellen Sie den Strimzi Cluster Operator und einen hoch verfügbaren Kafka-Cluster auf Azure Kubernetes Service (AKS) bereit.
Hinweis
Wenn Sie die erforderliche Infrastruktur für diese Bereitstellung nicht erstellt haben, befolgen Sie die Schritte in Vorbereiten der Infrastruktur für die Bereitstellung von Kafka auf Azure Kubernetes Service (AKS), um die Einrichtung vorzunehmen, und dann können Sie zu diesem Artikel zurückkehren.
Strimzi-Bereitstellung
Der Strimzi-Clusteroperator wird in seinem eigenen Namespace bereitgestellt und wird so konfiguriert, strimzi-operatordass der kafka Namespace überwacht wird, in dem die Kafka-Clusterkomponenten bereitgestellt werden. Für hohe Verfügbarkeit verwendet der Operator Folgendes:
- Mehrere Replikate mit Spitzenwahl: Ein Replikat dient als aktiver Leiter, der bereitgestellte Ressourcen verwaltet, während andere im Standbymodus bleiben. Wenn der Leiter ausfällt, übernimmt ein Standby-Replikat die Rolle.
- Zonalverteilung: Drei Replikate (eine pro Verfügbarkeitszone) bieten Resilienz gegen Zonenausfälle. Pod-Antiaffinitätsregeln verhindern, dass mehrere Replikate in derselben Zone geplant werden.
- Pod Disruption Budget: Automatisch von der Operatorbereitstellung erstellt, um sicherzustellen, dass mindestens ein Replikat während freiwilliger Unterbrechungen verfügbar bleibt.
Diese Architektur stellt sicher, dass der Strimzi Cluster Operator während Infrastrukturwartungen oder teilweisen Ausfällen weiterhin hochverfügbar ist.
Installieren von Strimzi Cluster Operator mit Helm
Erstellen Sie die Namespaces für den Strimzi-Clusteroperator und den Kafka-Cluster mithilfe des
kubectl create namespaceBefehls.kubectl create namespace strimzi-operator kubectl create namespace kafkaErstellen Sie mithilfe des folgenden Skripts eine
values.yamlDatei, um bestimmte Konfigurationen für das Helm-Diagramm bereitzustellen: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 EOFInstallieren Sie den Strimzi Cluster Operator mit dem
helm installBefehl.helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \ --namespace strimzi-operator \ --values values.yamlÜberprüfen Sie, ob der Strimzi-Cluster-Operator erfolgreich bereitgestellt wurde und ob sich alle Pods im laufenden Zustand befinden, indem Sie den
kubectl getBefehl verwenden.kubectl get pods -n strimzi-operatorIhre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
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
Installieren sie Strimzi Drain Cleaner mit Helm
Strimzi Drain Cleaner sorgt für einen reibungslosen Kubernetes-Knotenausgleich durch das Abfangen von Ausgleichsanforderungen für Broker-Pods, was verhindert, dass Kafka-Partitionsreplikate unterrepliziert werden und die Integrität und Zuverlässigkeit des Clusters aufrechterhält.
Stellen Sie für hohe Verfügbarkeit Drain Cleaner mit mehreren Replikaten in allen Verfügbarkeitszonen bereit, und konfigurieren Sie dies mit Pod-Unterbrechungsbudgets, um sicherzustellen, dass die Funktionsfähigkeit bei Zonenausfällen oder Clusterupgrades erhalten bleibt.
Für die Installation von Strimzi Drain Cleaner steht ein Helm-Diagramm zur Verfügung:
Erstellen Sie den Namespace für Drain Cleaner mithilfe des
kubectl create namespaceBefehls.kubectl create namespace strimzi-drain-cleanerErstellen Sie eine
values.yamlDatei, um bestimmte Konfigurationen für das Helm-Diagramm mithilfe des folgenden Skripts außer Kraft zu setzen: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 EOFInstallieren Sie den Strimzi Drain Cleaner mit dem
helm installBefehl.helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \ --namespace strimzi-drain-cleaner \ --values values.yamlStellen Sie sicher, dass der Strimzi Drain Cleaner erfolgreich bereitgestellt wurde und dass alle Pods durch den
kubectl getBefehl im Status 'running' sind.kubectl get pods -n strimzi-drain-cleanerIhre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
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
Kafka Clusterarchitektur und Überlegungen
Der Strimzi-Clusteroperator ermöglicht die deklarative Kafka-Bereitstellung auf AKS mithilfe von benutzerdefinierten Ressourcendefinitionen. Ab Strimzi 0.46 verwenden Kafka-Cluster KRaft in Kafka anstelle von ZooKeeper.
Strimzi verwendet die KafkaNodePool benutzerdefinierte Ressource, wobei jedem Pool eine bestimmte Rolle zugewiesen wird (Broker, Controller oder beides):
- Kafka-Broker verarbeiten die Verarbeitung und Speicherung von Nachrichten.
- Kafka-Controller verwalten Kafka-Metadaten mithilfe des Raft-Konsensprotokolls.
Für hohe Verfügbarkeit wird die Zielarchitektur durch Folgendes definiert:
- Trennen Sie
KafkaNodePoolsfür Broker und Controller, jeweils mit drei Replikaten. - Topologieverteilungseinschränkungen, die dazu dienen, Pods über Verfügbarkeitszonen und Knoten zu verteilen.
- Knotenaffinitätsregeln, die die Ressourcenauslastung mit bestimmten Knotenpools optimieren.
- Persistente Datenträger vom Azure Disk CSI-Treiber mit separaten Volumen für Brokernachrichten und Metadaten.
Diese Architektur verbessert die Skalierbarkeit und Fehlertoleranz, während Broker und Controller unabhängig skaliert werden können, um die Workloadanforderungen zu erfüllen.
JVM-Konfiguration für Produktions-Kafka-Cluster
Die Optimierung des virtuellen Java-Computers (JVM) ist wichtig für optimale Kafka-Broker- und Controllerleistung, insbesondere in Produktionsumgebungen. Die ordnungsgemäß konfigurierten JVM-Einstellungen helfen dabei, den Durchsatz zu maximieren, die Latenz zu minimieren und die Stabilität bei hoher Auslastung für jeden Broker sicherzustellen.
LinkedIn, die Ersteller von Kafka, teilten ihre empfohlenen Argumente für die Ausführung von Kafka auf Java für einen ihrer größten Cluster: Apache Kafka Java Configuration. In diesem Leitfaden wird diese Konfiguration als Basislinie für die Kafka-Broker verwendet. Sie können Änderungen vornehmen, um Ihre spezifischen Workloadanforderungen zu erfüllen.
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"
Bereitstellen von Kafka-Knotenpools
In diesem Abschnitt erstellen Sie zwei Kafka-Knotenpools: einen für Broker und einen für Controller.
Wenden Sie das YAML-Manifest an, um die beiden Kafka-Knotenpools mithilfe des
kubectl applyBefehls zu erstellen.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
Nach dem Erstellen der Kafka-Knotenpools besteht der nächste Schritt darin, eine benutzerdefinierte Kafka-Clusterressource zu definieren, die diese Pools an ein funktionierendes Kafka-Ökosystem bindet. Diese Architektur folgt einer Trennung von Bedenkenmustern, bei denen Kafka-Knotenpools die Infrastrukturaspekte verwalten, während die Kafka-Clusterressource Konfigurationen auf Anwendungsebene verarbeitet.
Bereitstellen des Kafka-Clusters
Erstellen Sie vor dem Erstellen des Kafka-Clusters eine ConfigMap, die die JMX Prometheus Exporter-Konfiguration mit dem
kubectl applyBefehl enthält. Diese ConfigMap definiert, wie die internen JMX-Metriken von Kafka transformiert und im Prometheus-Format verfügbar gemacht werden, wodurch eine umfassende Überwachung Ihres Kafka-Ökosystems ermöglicht wird. Die in dieser Konfiguration definierten Muster ordnen JMX-Metrikpfade ordnungsgemäß formatierten Prometheus-Metriken mit entsprechenden Typen und Bezeichnungen zu.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 EOFStellen Sie die Kafka-Clusterressource bereit, die die zuvor erstellten Knotenpools mit einem vollständigen Kafka-Ökosystem verbindet, indem Sie den
kubectl applyBefehl verwenden. Diese benutzerdefinierte Ressource konfiguriert die folgenden kritischen Komponenten:- Kafka-Kernkonfiguration: Definiert Replikationsfaktoren, Listenereinstellungen und andere kafka-spezifische Parameter.
- Cruise Control: Bietet automatisierte Clusterausgleichs- und Überwachungsfunktionen.
- Entitätsoperator: Stellt das Thema und die Benutzeroperatoren bereit, die Kafka-Themen und Benutzer deklarativ über Kubernetes-Ressourcen verwalten.
- JMX-Metriken: Konfiguriert die Belichtung von Metriken mithilfe der zuvor definierten ConfigMaps.
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Überprüfen Sie nach dem Deployment Ihre Kafka-Bereitstellung, indem Sie sicherstellen, dass alle KafkaNodePools, Kafka-Cluster-Ressourcen und deren entsprechende Pods mit dem
kubectl get-Befehl erstellt und in einem laufenden Zustand sind.kubectl get pods,kafkanodepool,kafka -n kafkaIhre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
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
Erstellen eines Kafka-Benutzers und -Themas
Der Strimzi Entity Operator, der mit der benutzerdefinierten Kafka-Clusterressource bereitgestellt wird, übersetzt Kubernetes benutzerdefinierte Ressourcen (KafkaTopic und KafkaUser) in tatsächliche Kafka-Ressourcen. Dies ermöglicht GitOps-Workflows und eine konsistente Konfigurationsverwaltung.
Hinweis
Das Deklarative Erstellen von Kafka Topics und Benutzern mithilfe des Entitätsoperators ist optional. Sie können sie auch mit herkömmlichen Kafka CLI-Tools oder APIs erstellen. Der deklarative Ansatz bietet jedoch Vorteile wie Versionssteuerung, Überwachungspfade und konsistente Verwaltung in allen Umgebungen.
Erstellen Sie ein Kafka-Thema mit dem Themenoperator mithilfe des
kubectl applyBefehls.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Überprüfen Sie, ob das Kafka-Thema mithilfe des
kubectl getBefehls erfolgreich erstellt wurde.kubectl get kafkatopic -n kafkaIhre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY test-topic kafka-aks-cluster 4 3 TrueWeitere Informationen finden Sie unter Verwendung des Themenoperators zum Verwalten von Kafka-Themen.
Erstellen Sie einen Kafka-Benutzer mit dem Benutzeroperator mithilfe des
kubectl applyBefehls.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: "*" EOFWeitere Informationen finden Sie unter Verwendung des Benutzeroperators zum Verwalten von Kafka-Benutzern.
Nächster Schritt
Beitragende
Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:
- Sergio Navar | Senior Customer Engineer
- Erin Schaffer | Inhaltsentwickler 2