Настройка и развертывание компонентов Strimzi и Kafka в службе Azure Kubernetes (AKS)

В этой статье описано, как развернуть оператор кластера Strimzi и высокодоступный кластер Kafka в службе Azure Kubernetes (AKS).

Примечание.

Если вы не создали необходимую инфраструктуру для этого развертывания, выполните действия, описанные в статье "Подготовка инфраструктуры для развертывания Kafka в службе Azure Kubernetes (AKS), чтобы настроиться, а затем вернуться к этой статье.

Развертывание Strimzi

Оператор кластера Strimzi развертывается в своем собственном пространстве имен strimzi-operator и настраивается для наблюдения за пространством имен kafka, где развёрнуты компоненты кластера Kafka. Для обеспечения высокой доступности оператор использует:

Несколько реплик с выборами лидера: одна реплика служит активным лидером, который управляет развернутыми ресурсами, а другие остаются в режиме ожидания. Если лидер терпит неудачу, резервная реплика берет на себя управление.
Зональное распределение: три реплики (по одной для зоны доступности) обеспечивают устойчивость к сбоям зон. Правила анти-аффинности для pod препятствуют размещению нескольких реплик в одной и той же зоне.
Бюджет прерывания pod: создается автоматически развертыванием оператора, чтобы гарантировать, что по крайней мере одна реплика остается доступной во время добровольных сбоев.

Эта архитектура гарантирует, что оператор кластера Strimzi остается высокодоступным даже во время обслуживания инфраструктуры или частичных сбоев.

Установка Strimzi Cluster Operator с помощью Helm

Создайте пространства имен для оператора кластера Strimzi и кластера Kafka с помощью kubectl create namespace команды.
```
kubectl create namespace strimzi-operator  
kubectl create namespace kafka  
```

С помощью следующего сценария создайте values.yaml файл для предоставления определенных конфигураций для диаграммы 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  
EOF

Установите оператор кластера Strimzi с помощью helm install команды.

helm install strimzi-cluster-operator oci://quay.io/strimzi-helm/strimzi-kafka-operator \
--namespace strimzi-operator \
--values values.yaml

Убедитесь, что оператор кластера Strimzi успешно развернут, и все pod находятся в работающем состоянии, используя команду kubectl get.

kubectl get pods -n strimzi-operator

Выходные данные должны выглядеть примерно так:

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

Установите Strimzi Drain Cleaner с помощью Helm

Strimzi Drain Cleaner обеспечивает плавное дренирование узлов Kubernetes, перехватывая запросы на очистку для модулей pod брокера, что предотвращает недостаточную репликацию сегментов секций Kafka и поддерживает работоспособность и надежность кластера.

Чтобы обеспечить высокий уровень доступности, разверните Дренажный Очиститель с несколькими репликами в зонах доступности и настройте его с помощью Pod Disruption Budget, чтобы обеспечить работоспособность во время сбоев зон или обновлений кластера.

Диаграмма Helm доступна для установки Strimzi Drain Cleaner:

Создайте пространство имен для средства для прочистки труб, используя команду kubectl create namespace.
```
kubectl create namespace strimzi-drain-cleaner  
```

Создайте файл values.yaml для переопределения определенных конфигураций диаграммы Helm, используя следующий скрипт:

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  
EOF

Установите Strimzi Drain Cleaner с помощью helm install команды.

helm install strimzi-drain-cleaner oci://quay.io/strimzi-helm/strimzi-drain-cleaner \
--namespace strimzi-drain-cleaner \
--values values.yaml

Убедитесь, что Strimzi Drain Cleaner успешно развернут и что все поды находятся в состоянии выполнения с помощью команды kubectl get.

kubectl get pods -n strimzi-drain-cleaner

Выходные данные должны выглядеть примерно так:

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

Оператор кластера Strimzi включает декларативное развертывание Kafka в AKS с помощью пользовательских определений ресурсов. Начиная с Strimzi 0.46, кластеры Kafka используют KRaft в Kafka вместо ZooKeeper.

Strimzi использует KafkaNodePool пользовательский ресурс, где каждому пулу назначена определенная роль (брокер, контроллер или оба):

Брокеры Kafka обрабатывают и хранят сообщения.
Контроллеры Kafka управляют метаданными Kafka с помощью протокола консенсуса Raft.

Для обеспечения высокой доступности целевая архитектура определяется следующим образом:

Отдельные KafkaNodePools для брокеров и контроллеров, каждый из которых имеет три реплики.
Ограничения распространения топологии, которые распределяют pods между зонами доступности и узлами.
Правила совместимости узлов, которые оптимизируют использование ресурсов, работая с конкретными пулами узлов.
Постоянные тома из драйвера CSI диска Azure с отдельными томами для сообщений брокера и метаданных.

Эта архитектура повышает масштабируемость и отказоустойчивость, позволяя брокерам и контроллерам независимо масштабироваться в соответствии с требованиями рабочей нагрузки.

Конфигурация JVM для рабочих кластеров Kafka

Настройка виртуальной машины Java (JVM) важна для оптимальной производительности брокера Kafka и контроллера, особенно в рабочих средах. Правильно настроенные параметры JVM помогают максимизировать пропускную способность, минимизировать задержку и обеспечить стабильность при тяжелой нагрузке для каждого брокера.

LinkedIn, создатели Kafka, поделились своими рекомендуемыми аргументами для запуска Kafka на Java для одного из самых загруженных кластеров: Apache Kafka Java Configuration. В этом руководстве эта конфигурация используется в качестве базового плана для брокеров Kafka. Вы можете внести изменения в соответствии с конкретными требованиями к рабочей нагрузке.

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"

Развертывание пулов узлов Kafka

В этом разделе вы создадите два пула узлов Kafka: один для брокеров и один для контроллеров.

Примените манифест YAML для создания двух пулов узлов Kafka с помощью 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

После создания пулов узлов Kafka необходимо определить настраиваемый ресурс кластера Kafka, который привязывает эти пулы к работающей экосистеме Kafka. Эта архитектура следует разделению проблем, где пулы узлов Kafka управляют аспектами инфраструктуры, а ресурс кластера Kafka обрабатывает конфигурации на уровне приложения.

Развертывание кластера Kafka

Перед созданием кластера Kafka создайте конфигурацию ConfigMap, содержащую конфигурацию экспортера JMX Prometheus с помощью kubectl apply команды. Этот ConfigMap определяет, как внутренние метрики JMX Kafka преобразуются и предоставляются в формате Prometheus, обеспечивая комплексный мониторинг экосистемы Kafka. Шаблоны, определенные в этой схеме конфигурации, сопоставляют пути метрик JMX с правильно отформатированными метриками Prometheus с соответствующими типами и метками.

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
EOF

Разверните ресурс кластера Kafka, который подключает ранее созданные пулы узлов к полной экосистеме Kafka с помощью kubectl apply команды. Этот пользовательский ресурс настраивает следующие критически важные компоненты:

Базовая конфигурация Kafka: определяет факторы репликации, параметры прослушивателя и другие параметры Kafka.
Cruise Control: предоставляет возможности по автоматизированному управлению балансировкой и мониторингом кластеров.
Оператор сущности: развертывает операторов тем и пользователей, которые управляют темами и пользователями Kafka декларативно с помощью ресурсов Kubernetes.
Метрики JMX: настраивает экспозицию метрик с помощью ранее определенных 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

После развертывания с помощью команды kubectl get проверьте развертывание Kafka, убедившись, что все KafkaNodePools, ресурсы кластера Kafka и соответствующие поды созданы и находятся в работающем состоянии.

kubectl get pods,kafkanodepool,kafka -n kafka

Выходные данные должны выглядеть примерно так:

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

Создание пользователя и раздела Kafka

Оператор сущностей Strimzi, развернутый с помощью пользовательского ресурса кластера Kafka, преобразует ресурсы Kubernetes (KafkaTopic и KafkaUser) в фактические ресурсы Kafka. Это позволяет внедрять рабочие процессы GitOps и обеспечивать согласованное управление конфигурацией.

Примечание.

Создание разделов Kafka и пользователей декларативно с помощью оператора entity является необязательным. Вы также можете создать их с помощью традиционных средств командной строки Kafka или API. Однако декларативный подход предлагает такие преимущества, как управление версиями, следы аудита и согласованное управление в разных средах.

Создайте топик Kafka оператором топика, используя команду 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  
EOF

Убедитесь, что раздел Kafka успешно создан с помощью kubectl get команды.
```
kubectl get kafkatopic -n kafka  
```
Выходные данные должны выглядеть примерно так:
```
NAME         CLUSTER             PARTITIONS   REPLICATION FACTOR   READY  
test-topic   kafka-aks-cluster   4            3                    True  
```
Дополнительные сведения см. в разделе "Оператор тем" для управления разделами Kafka.

Создайте пользователя Kafka с Оператором пользователя с помощью команды 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: "*"  
EOF

Дополнительные сведения см. в разделе "Оператор пользователя" для управления пользователями Kafka.

Следующий шаг

Настройка мониторинга и сети для кластера Kafka в AKS с помощью оператора Strimzi

Соавторы

Корпорация Майкрософт поддерживает эту статью. Первоначальная версия была написана следующими участниками:

Серхио Навар | Старший инженер клиента
Эрин Шаффер | Разработчик содержимого 2

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-09-15

Настройка и развертывание компонентов Strimzi и Kafka в службе Azure Kubernetes (AKS)

Развертывание Strimzi

Установка Strimzi Cluster Operator с помощью Helm

Установите Strimzi Drain Cleaner с помощью Helm

Архитектура и рекомендации по архитектуре кластера Kafka

Конфигурация JVM для рабочих кластеров Kafka

Развертывание пулов узлов Kafka

Развертывание кластера Kafka

Создание пользователя и раздела Kafka

Следующий шаг

Соавторы

Обратная связь

Дополнительные ресурсы