WeDoOps
Обсудить задачу
← Ко всем статьям
8 мин чтения

Брокеры очередей в Kubernetes: от выбора до продакшена

Поделиться в Telegram
Содержание

Брокеры очередей в Kubernetes: от выбора до продакшена

Практическое руководство для DevOps-инженеров: выбор, развёртывание и эксплуатация очередей в Kubernetes в 2026 году.

Содержание

Часть 1. Выбор брокера: Kafka, RabbitMQ или NATS?

Кратко: три модели брокеров — лог (Kafka), маршрутизация (RabbitMQ) и лёгкий cloud-native стек (NATS JetStream) — и сценарии, где каждый выигрывает.

В 2026 году ландшафт брокеров сообщений в Kubernetes стабилизировался вокруг трёх игроков: Apache Kafka, RabbitMQ и NATS JetStream. Каждый вырос от «просто контейнера» до экосистемы с операторами, автоскейлингом и GitOps.

Разница между ними — в архитектуре, а не в списке фич.

Apache Kafka — «умный консьюмер»

Распределённый лог: высокая пропускная способность, длинный retention и replay сообщений.

Идеален для:

  • стриминга данных и аналитики;
  • сценариев, где важен порядок сообщений;
  • повторного чтения истории.

Минусы:

  • высокая операционная сложность;
  • нужны ресурсы и опытная команда;
  • даже с KRaft (без ZooKeeper) остаётся тяжёлым.

RabbitMQ — «умный брокер»

Сильная сторона — маршрутизация: exchanges, priority queues, dead letter exchanges, publisher confirms.

Идеален для:

  • task queue;
  • RPC;
  • гарантированной доставки каждого сообщения.

Минусы:

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

NATS JetStream — «современный challenger»

Лёгкий и быстрый, хорошо ложится на Kubernetes.

Идеален для:

  • низкой задержки;
  • малого потребления ресурсов;
  • классических очередей и лог-ориентированного стриминга в одном стеке.

Особенность: reconnect durable consumer не вызывает rebalance и не блокирует остальных воркеров.

Минусы:

  • экосистема и enterprise-фичи скромнее, чем у Kafka и RabbitMQ.

Сравнительная таблица брокеров

Критерий

Kafka

RabbitMQ

NATS JetStream

Модель

Распределённый лог

Умный брокер + очереди

Лог + pub/sub + очереди

Пропускная способность

Очень высокая (миллионы msg/s)

Высокая (десятки тысяч msg/s)

Очень высокая (миллионы msg/s)

Задержка

Миллисекунды

Микросекунды–миллисекунды

Микросекунды

Retention

Дни / недели / бессрочно (log)

До подтверждения (queue)

Настраиваемый (stream)

Сложность эксплуатации

Высокая

Средняя

Низкая

Экосистема в Kubernetes

Strimzi (CNCF)

Cluster Operator + Topology Operator

Helm + NACK

Основной use case

Стриминг, аналитика, event sourcing

Task queue, RPC, сложная маршрутизация

Микросервисы, IoT, edge, low-latency

Краткое руководство по выбору

Сценарий

Рекомендация

Стриминг, аналитика, retention на дни/недели

Kafka

Сложная маршрутизация, гарантированная доставка, task queue

RabbitMQ

Лёгкость, низкая задержка, простая эксплуатация в Kubernetes

NATS JetStream

Часть 2. Операторы: как разворачивать брокеры в Kubernetes

Кратко: production-ready операторы — Strimzi, RabbitMQ Cluster Operator, NACK — и декларативные примеры CRD.

Разворачивать Kafka, RabbitMQ или NATS «руками» через StatefulSet — путь к боли. В 2026 году стандарт — операторы.

Kafka: Strimzi

Strimzi — де-факто стандарт для Kafka в Kubernetes. CNCF-проект: Kubernetes-native оператор для развёртывания, управления и масштабирования кластеров.

Оператор следит за CRD Kafka, KafkaNodePool, KafkaConnect, KafkaMirrorMaker2 и ведёт жизненный цикл брокеров: rolling updates и Cruise Control.

Важно: с версии 0.51 Strimzi официально поддерживает только Kubernetes 1.30+. Актуальная линейка — 1.x (на сентябрь 2026 — 1.2.0): API kafka.strimzi.io/v1, ZooKeeper снят с поддержки. Для production используйте KRaft и KafkaNodePool. Старый v1beta2 снят в 1.0.0.

yaml
apiVersion: kafka.strimzi.io/v1
kind: KafkaNodePool
metadata:
  name: dual-role
  labels:
    strimzi.io/cluster: production-cluster
spec:
  replicas: 3
  roles:
    - controller
    - broker
  storage:
    type: jbod
    volumes:
      - id: 0
        type: persistent-claim
        size: 100Gi
        kraftMetadata: shared
        deleteClaim: false
---
apiVersion: kafka.strimzi.io/v1
kind: Kafka
metadata:
  name: production-cluster
spec:
  kafka:
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
    config:
      default.replication.factor: 3
      min.insync.replicas: 2
      offsets.topic.replication.factor: 3
      transaction.state.log.replication.factor: 3
      transaction.state.log.min.isr: 2
  entityOperator:
    topicOperator: {}
    userOperator: {}

Версию Kafka (spec.kafka.version / metadataVersion) задавайте по таблице совместимости вашего релиза Strimzi. Оператор также ставится Helm-чартом — удобно для GitOps.

RabbitMQ: Cluster Operator + Messaging Topology Operator

У RabbitMQ два официальных оператора:

  1. Cluster Operator — жизненный цикл кластера: создание, обновление, graceful shutdown, масштабирование, мониторинг. Разработка команды RabbitMQ (Broadcom), production-ready с 1.x. CRD кластера: rabbitmq.com/v1beta1, kind: RabbitmqCluster.
  2. Messaging Topology Operator — очереди, exchanges, bindings, users, vhosts, policies и permissions через CRD (rabbitmq.com/v1beta1).

Важно: в production берите официальный Cluster Operator, а не Bitnami Helm-чарт — у оператора лучше жизненный цикл и HA.

yaml
apiVersion: rabbitmq.com/v1beta1
kind: Queue
metadata:
  name: orders-queue
spec:
  name: orders
  vhost: /
  durable: true
  rabbitmqClusterReference:
    name: production-rabbitmq
  arguments:
    x-dead-letter-exchange: dlx
    x-max-priority: 10

NATS: Helm + NACK

Экосистема NATS в Kubernetes собирается из частей:

  • NATS Helm Chart — кластер NATS с JetStream;
  • NACK (NATS Controllers for Kubernetes) — Streams, Consumers, Key/Value через CRD (jetstream.nats.io/v1beta2).

Для простых сценариев достаточно Helm-чарта; для multi-tenant — Helm + NACK (JWT-аккаунты обычно ведут через nsc и секреты, а не отдельный «Auth Operator»).

Часть 3. Автоскейлинг на основе очередей: KEDA

Кратко: масштабирование подов по длине очереди, consumer lag и message rate, включая scale-to-zero.

Стандартный HPA не масштабирует поды по длине очереди. Для этого нужен KEDA (Kubernetes Event-Driven Autoscaling). CRD: keda.sh/v1alpha1.

KEDA смотрит на внешние источники — очереди, стримы, базы — и меняет число реплик по метрикам (queue depth, consumer lag, message rate).

Scale-to-zero: пустая очередь — поды сворачиваются до нуля; появились сообщения — поднимаются снова.

Поддерживаемые режимы

RabbitMQ:

  • QueueLength
  • MessageRate
  • DeliverGetRate
  • PublishedToDeliveredRatio
  • ExpectedQueueConsumptionTime

Kafka: consumer lag (лаг консьюмер-группы по партициям).

NATS: backlog JetStream.

Пример ScaledObject для RabbitMQ

yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
spec:
  scaleTargetRef:
    name: order-processor
  minReplicaCount: 0
  maxReplicaCount: 30
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        mode: QueueLength
        value: "5"
      authenticationRef:
        name: rabbitmq-auth

Если в очереди 50 сообщений, а порог value равен 5, KEDA запросит 10 реплик. Нагрузка ведёт число подов без ручных правок HPA.

Часть 4. Лучшие практики эксплуатации в Kubernetes

Кратко: хранение состояния, изоляция ресурсов, мониторинг, GitOps и ошибки, которые ломают продакшен.

Хранение состояния

Брокеры — stateful. Kafka, RabbitMQ и NATS JetStream нужны персистентные тома. Берите StorageClass с expansion, чтобы не мигрировать диски при росте. Для RabbitMQ в production — quorum queues (Raft).

Изоляция ресурсов

Kafka и RabbitMQ чувствительны к «шумным соседям». Namespaces, resource quotas, pod anti-affinity. В Kafka на production разделяйте controller и broker node pools, если нагрузка это оправдывает.

Spot-инстансы

Не ставьте брокеры на spot-ноды. Эвикция может сделать очередь недоступной. Node affinity / taints, чтобы исключить spot для RabbitMQ и Kafka.

Мониторинг и readiness

Очередь задаёт пульс системы. Смотрите:

  • размер очереди;
  • скорость потребления;
  • consumer lag.

Readiness probes, чтобы Kubernetes не слал трафик на неготовый брокер. У RabbitMQ и Kafka есть Prometheus-экспортеры; операторы их подключают.

GitOps и декларативность

Strimzi, RabbitMQ Cluster Operator и NACK работают декларативно. Топология очередей, топиков и permissions живёт в Git рядом с кодом. Argo CD или Flux применяют манифесты, оператор приводит кластер к желаемому состоянию.

Антипаттерны

  1. StatefulSet «руками» вместо оператора. Потеря лидера, кривой rolling update, нет graceful shutdown — недоступность очереди и потеря сообщений.
  2. Брокеры на spot-нодах. Эвикция ноды выбивает брокера; при малом replication factor — потеря данных и downtime.
  3. replication.factor: 1 в production. Сбой ноды = потеря топика/очереди. Минимум — 3 с min.insync.replicas: 2.
  4. Масштабирование по CPU вместо очереди. HPA по CPU не видит рост backlog. KEDA с триггером по queue depth / consumer lag.
  5. Один namespace для брокеров и приложений. Соседи съедают CPU и память. Отдельный namespace и resource quotas.
  6. Данные на emptyDir. Рестарт пода = потеря непрочитанных сообщений. Только PVC с retain.

Чек-лист перед продакшеном

Полезные ссылки

Kafka:

  • Strimzi Operator — https://strimzi.io/
  • Apache Kafka Documentation — https://kafka.apache.org/documentation/
  • Cruise Control — https://github.com/linkedin/cruise-control

RabbitMQ:

  • RabbitMQ Cluster Operator — https://www.rabbitmq.com/kubernetes/operator/operator-overview
  • Messaging Topology Operator — https://www.rabbitmq.com/kubernetes/operator/using-topology-operator
  • Quorum Queues — https://www.rabbitmq.com/quorum-queues.html

NATS:

  • NATS JetStream — https://docs.nats.io/nats-concepts/jetstream
  • NACK (NATS Controllers for Kubernetes) — https://github.com/nats-io/nack
  • NATS Auth Operator — https://github.com/nats-io/nats-auth-operator <!-- DEAD LINK -->

Автоскейлинг:

  • KEDA — https://keda.sh/
  • KEDA RabbitMQ Scaler — https://keda.sh/docs/latest/scalers/rabbitmq-queue/
  • KEDA Kafka Scaler — https://keda.sh/docs/latest/scalers/apache-kafka/

GitOps:

  • Argo CD — https://argo-cd.readthedocs.io/
  • Flux — https://fluxcd.io/

Заключение

В 2026 году выбор брокера в Kubernetes — не «что лучше», а «что лучше для сценария»:

  • Kafka — стриминг;
  • RabbitMQ — маршрутизация;
  • NATS — лёгкость и скорость.

Операторы обязательны: Day 2, безопасность, инфраструктура как код.

KEDA даёт эластичность: поды следуют за очередью, а не за средним CPU. Вместе с GitOps получается предсказуемая messaging-платформа.

Если вы только начинаете

  • RabbitMQ + Cluster Operator — проще в освоении; Messaging Topology Operator даёт декларативность.
  • Strimzi + Kafka — если строите стриминговую платформу.
  • NATS + Helm + NACK — если нужны лёгкость и малые накладные расходы.