Миграция Kafka с EC2 на Kubernetes: как переносить petabyte-scale без простоя

Kafka редко бывает маленькой надолго. Если через неё проходят события продукта, аналитика, логи, ML-пайплайны и интеграции, кластер быстро становится критичной частью инфраструктуры. Перенос такой системы с виртуальных машин на Kubernetes — не обычный redeploy. Ошибка может затронуть producers, consumers, data pipelines и downstream-сервисы.

Миграция petabyte-scale Kafka требует инженерной дисциплины: планирования, staged rollout, измерений, canary-подхода и готового rollback. Kubernetes может упростить управление брокерами, но не отменяет сложность Kafka как stateful-системы.

Почему Kafka сложно мигрировать

Kafka хранит состояние: partitions, replicas, offsets, logs. В отличие от stateless API, брокер нельзя просто убить и поднять где угодно без учёта данных и ISR.

Критичные элементы:

размер log segments;
replication factor;
partition leadership;
consumer offsets;
network throughput;
disk IO;
broker identity;
rack awareness;
controller behavior;
compatibility clients.

Если не учитывать эти детали, Kubernetes станет не платформой, а источником нестабильности.

Зачем переносить в Kubernetes

У миграции могут быть веские причины:

единый deployment workflow;
стандартизованный monitoring;
проще управлять конфигурацией;
self-healing для инфраструктурных сбоев;
GitOps;
унификация команды эксплуатации;
снижение зависимости от ручных EC2-процедур.

Но перенос ради моды опасен. Kafka на VM может быть проще и надёжнее, если команда хорошо умеет её сопровождать. Kubernetes оправдан, когда он снижает общую сложность платформы, а не просто меняет место запуска.

StatefulSet и storage

В Kubernetes Kafka обычно запускают через StatefulSet или оператор. Важна стабильная identity каждого broker и persistent volume. Но storage в Kubernetes — отдельный источник рисков.

Проверить нужно:

latency и throughput дисков;
поведение volume при reschedule;
topology и zone placement;
скорость восстановления;
лимиты IOPS;
monitoring PVC;
backup/restore metadata;
правила anti-affinity.

Для Kafka storage — не второстепенная деталь. Он определяет стабильность кластера.

Миграция без большого взрыва

Самый опасный подход — перенести всё сразу. Более безопасная стратегия:

Поднять Kubernetes-контур рядом со старым.
Проверить конфигурацию и observability.
Перенести тестовые topics.
Запустить canary producers/consumers.
Постепенно переносить нагрузку.
Следить за lag, throughput и errors.
Держать rollback-путь.

Для больших кластеров важна не скорость миграции, а контролируемость. Лучше переносить дольше, но с понятными точками проверки.

Partition reassignment

Перемещение данных в Kafka часто упирается в reassignment partitions. Это дорогая операция: она грузит сеть, диски и brokers. Если выполнить её слишком агрессивно, можно получить latency spikes и consumer lag.

Нужны лимиты:

throttling replication traffic;
ограничение числа одновременных reassignments;
мониторинг under-replicated partitions;
контроль offline partitions;
проверка leader distribution;
возможность остановить процесс.

Без throttling миграция сама станет инцидентом.

Observability

Перед миграцией нужно убедиться, что видны ключевые метрики:

broker CPU, memory, disk;
disk usage per broker;
network in/out;
request latency;
producer errors;
consumer lag;
under-replicated partitions;
ISR shrink/expand;
controller events;
Kubernetes pod restarts;
PVC saturation.

Если команда не видит эти параметры, она не управляет миграцией, а надеется на удачу.

Rollback

Rollback для Kafka сложнее, чем для stateless-сервиса. Нужно заранее понимать, можно ли вернуть traffic на старый кластер, что будет с offsets, какие topics уже перенесены и как избежать split-brain в данных.

Практический rollback-план должен описывать:

точку остановки миграции;
переключение producers;
поведение consumers;
сохранность offsets;
синхронизацию topics;
критерии отката;
ответственных и команды.

Итог

Перенос Kafka с EC2 на Kubernetes может быть полезным шагом к единой платформе, но это не обычная миграция контейнеров. Kafka требует уважения к состоянию, storage, partitions и клиентскому трафику.

Успех зависит от staged migration, observability, throttling, canary-проверок и честного rollback-плана. Kubernetes помогает только тогда, когда вокруг него выстроены правильные эксплуатационные практики.