Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule wdrożysz operator klastra Strimzi i klaster platformy Kafka o wysokiej dostępności w usłudze Azure Kubernetes Service (AKS).
Uwaga / Notatka
Jeśli nie utworzono wymaganej infrastruktury dla tego wdrożenia, wykonaj kroki opisane w artykule Przygotowywanie infrastruktury do wdrażania platformy Kafka w usłudze Azure Kubernetes Service (AKS), a następnie możesz wrócić do tego artykułu.
Wdrożenie Strimzi
Operator klastra Strimzi jest wdrażany we własnej przestrzeni nazw, strimzi-operatori jest skonfigurowany do obserwowania kafka przestrzeni nazw, w której są wdrażane składniki klastra Kafka. W celu zapewnienia wysokiej dostępności operator używa następujących funkcji:
- Wiele replik z wyborem lidera: jedna replika służy jako aktywny lider zarządzający wdrożonymi zasobami, podczas gdy inne pozostają w gotowości. Jeśli lider ulegnie awarii, replika rezerwowa przejmuje kontrolę.
- Rozkład strefowy: trzy repliki (jedna na strefę dostępności) zapewniają odporność na awarie stref. Reguły anty-afinityjne podów zapobiegają rozmieszczeniu wielu replik w tej samej strefie.
- Budżet zakłóceń zasobników: utworzony automatycznie przez wdrożenie operatora w celu zapewnienia dostępności co najmniej jednej repliki podczas dobrowolnych zakłóceń.
Ta architektura zapewnia, że operator klastra Strimzi pozostaje wysoce dostępny nawet podczas konserwacji infrastruktury lub częściowych awarii.
Instalowanie operatora klastra Strimzi przy użyciu programu Helm
Utwórz przestrzenie nazw dla operatora klastra Strimzi i klastra Kafka przy użyciu polecenia
kubectl create namespace.kubectl create namespace strimzi-operator kubectl create namespace kafkaKorzystając z następującego skryptu, utwórz plik
values.yamlw celu udostępnienia określonych konfiguracji dla Helm Chart.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 EOFZainstaluj operator klastra Strimzi przy użyciu
helm installpolecenia .helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \ --namespace strimzi-operator \ --values values.yamlSprawdź, czy operator klastra Strimzi został pomyślnie wdrożony, a wszystkie zasobniki są w stanie uruchomienia, używając polecenia
kubectl get.kubectl get pods -n strimzi-operatorDane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:
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
Instalowanie narzędzia Strimzi Drain Cleaner przy użyciu narzędzia Helm
Narzędzie Strimzi Drain Cleaner zapewnia bezproblemowe opróżnianie węzłów Kubernetes przez przechwytywanie żądań opróżniania podów brokera, co zapobiega niedoreplikowaniu replik partycji platformy Kafka i utrzymuje kondycję oraz niezawodność klastra.
Aby zapewnić wysoką dostępność, wdróż narzędzie Cleaner z wieloma replikami w różnych strefach dostępności i skonfiguruj je z budżetami przerw w działaniu podów, aby działało podczas awarii strefy lub aktualizacji klastra.
Chart Helm jest dostępny do instalacji narzędzia Strimzi Drain Cleaner.
Utwórz przestrzeń nazw narzędzia Drain Cleaner przy użyciu
kubectl create namespacepolecenia .kubectl create namespace strimzi-drain-cleanerUtwórz plik
values.yaml, aby zastąpić określone konfiguracje diagramu Helm przy użyciu następującego skryptu: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 EOFZainstaluj narzędzie Strimzi Drain Cleaner przy użyciu
helm installpolecenia .helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \ --namespace strimzi-drain-cleaner \ --values values.yamlSprawdź, czy narzędzie Strimzi Drain Cleaner zostało pomyślnie wdrożone i czy wszystkie pody działają za pomocą polecenia
kubectl get.kubectl get pods -n strimzi-drain-cleanerDane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:
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
Architektura i zagadnienia dotyczące klastra platformy Kafka
Operator klastra Strimzi umożliwia deklaratywne wdrożenie platformy Kafka w usłudze AKS przy użyciu niestandardowych definicji zasobów. Począwszy od wersji Strimzi 0.46, klastry platformy Kafka używają narzędzia KRaft na platformie Kafka zamiast usługi ZooKeeper.
Strimzi używa zasobu niestandardowego KafkaNodePool , w którym każda pula ma przypisaną określoną rolę (broker, kontroler lub oba):
- Brokerzy platformy Kafka obsługują przetwarzanie i przechowywanie komunikatów.
- Kontrolery platformy Kafka zarządzają metadanymi platformy Kafka przy użyciu protokołu raft consensus.
W przypadku wysokiej dostępności architektura docelowa jest definiowana przez:
- Oddzielne
KafkaNodePoolsdla brokerów i kontrolerów, z których każda ma trzy repliki. - Ograniczenia rozmieszczenia topologii, które rozmieszczają zasobniki między strefami dostępności i węzłami.
- Reguły koligacji węzłów, które optymalizują wykorzystanie zasobów przy użyciu określonych pul węzłów.
- Trwałe woluminy ze sterownika CSI dla dysków Azure z oddzielnymi woluminami dla komunikatów brokera i metadanych.
Ta architektura zwiększa skalowalność i odporność na uszkodzenia, umożliwiając brokerom i kontrolerom niezależne skalowanie w celu spełnienia wymagań dotyczących obciążenia.
Konfiguracja maszyny wirtualnej JVM dla produkcyjnych klastrów platformy Kafka
Dostrajanie maszyny wirtualnej Java (JVM) ma kluczowe znaczenie dla optymalnej wydajności brokera i kontrolera platformy Kafka, szczególnie w środowiskach produkcyjnych. Prawidłowo skonfigurowane ustawienia maszyny JVM pomagają zmaksymalizować przepływność, zminimalizować opóźnienia i zapewnić stabilność pod dużym obciążeniem dla każdego brokera.
LinkedIn, twórcy platformy Kafka, udostępnili swoje zalecane argumenty dotyczące uruchamiania platformy Kafka w języku Java dla jednego z najbardziej ruchliwych klastrów: Apache Kafka Java Configuration. W tym przewodniku użyto tej konfiguracji jako punktu odniesienia dla brokerów platformy Kafka. Możesz wprowadzić zmiany, aby spełnić określone wymagania dotyczące obciążenia.
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"
Wdrażanie pul węzłów platformy Kafka
W tej sekcji utworzysz dwie pule węzłów platformy Kafka: jedną dla brokerów i jedną dla kontrolerów.
Zastosuj manifest YAML, aby utworzyć dwie pule węzłów Kafka, używając polecenia
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
Po utworzeniu pul węzłów platformy Kafka następnym krokiem jest zdefiniowanie niestandardowego zasobu klastra platformy Kafka, który wiąże te pule z działającym ekosystemem platformy Kafka. Ta architektura jest zgodna ze wzorcem separacji aspektów, w którym pule węzłów Kafka zarządzają aspektami infrastrukturalnymi, podczas gdy zasób klastra Kafka obsługuje konfiguracje na poziomie aplikacji.
Wdrażanie klastra platformy Kafka
Przed utworzeniem klastra Kafka utwórz ConfigMap zawierającą konfigurację JMX Prometheus Exporter przy użyciu polecenia
kubectl apply. Ten obiekt ConfigMap definiuje, jak wewnętrzne metryki JMX platformy Kafka są przekształcane i uwidaczniane w formacie Prometheus, umożliwiając kompleksowe monitorowanie ekosystemu platformy Kafka. Wzorce zdefiniowane w tej konfiguracji odpowiednio przyporządkowują ścieżki metryk JMX do prawidłowo sformatowanych metryk Prometheus z właściwymi typami i etykietami.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 EOFWdróż zasób klastra Kafka, który łączy wcześniej utworzone pule węzłów w kompletny ekosystem Kafka, przy użyciu polecenia
kubectl apply. Ten zasób niestandardowy konfiguruje następujące składniki krytyczne:- Podstawowa konfiguracja platformy Kafka: definiuje czynniki replikacji, ustawienia odbiornika i inne parametry specyficzne dla platformy Kafka.
- Cruise Control: zapewnia zautomatyzowane równoważenie klastra i możliwości monitorowania.
- Operator jednostki: wdraża operatory tematów i użytkowników, które zarządzają tematami i użytkownikami platformy Kafka deklaratywnie za pośrednictwem zasobów platformy Kubernetes.
- Metryki JMX: konfiguruje ekspozycję metryk przy użyciu wcześniej zdefiniowanych map konfiguracji.
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: {} EOFPo wdrożeniu zweryfikuj wdrożenie Kafka, sprawdzając, czy wszystkie KafkaNodePools, zasoby klastra Kafka oraz odpowiadające im pody są tworzone i znajdują się w stanie uruchomienia przy użyciu polecenia
kubectl get.kubectl get pods,kafkanodepool,kafka -n kafkaDane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:
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
Tworzenie użytkownika i tematu platformy Kafka
Operator jednostki Strimzi wdrożony przy użyciu zasobu niestandardowego klastra Kafka tłumaczy zasoby niestandardowe platformy Kubernetes (KafkaTopic i KafkaUser) na rzeczywiste zasoby platformy Kafka. Umożliwia to przepływy pracy usługi GitOps i spójne zarządzanie konfiguracją.
Uwaga / Notatka
Deklaratywne tworzenie tematów i użytkowników platformy Kafka przy użyciu operatora jednostki jest opcjonalne. Można je również utworzyć przy użyciu tradycyjnych narzędzi interfejsu wiersza polecenia platformy Kafka lub interfejsów API. Jednak podejście deklaratywne oferuje korzyści, takie jak kontrola wersji, ślady inspekcji i spójne zarządzanie w środowiskach.
Utwórz temat Kafka przy użyciu Topic Operator za pomocą polecenia
kubectl apply.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 EOFSprawdź, czy temat Kafka został pomyślnie utworzony przy użyciu polecenia
kubectl get.kubectl get kafkatopic -n kafkaDane wyjściowe powinny wyglądać podobnie do następujących przykładowych danych wyjściowych:
NAME CLUSTER PARTITIONS REPLICATION FACTOR READY test-topic kafka-aks-cluster 4 3 TrueAby uzyskać więcej informacji, zobacz używanie operatora tematu do zarządzania tematami platformy Kafka.
Utwórz użytkownika platformy Kafka za pomocą operatora użytkownika przy użyciu
kubectl applypolecenia .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: "*" EOFAby uzyskać więcej informacji, zobacz używanie operatora użytkownika do zarządzania użytkownikami platformy Kafka.
Następny krok
Współautorzy
Firma Microsoft utrzymuje ten artykuł. Następujący autorzy pierwotnie napisali ten tekst:
- Sergio Navar | Starszy inżynier klienta
- Erin Schaffer | Content Developer 2