Apache Kafka на Ubuntu 24.04: пошаговая установка

MAATRIX

Если очередь сообщений на RabbitMQ или NATS начинает захлёбываться под миллионами событий в час, а бизнесу нужно ещё и хранить историю сообщений для повторного чтения — рано или поздно упираетесь в Kafka. Это не «ещё одна очередь», а платформа для потоковой обработки событий, которую строили под нагрузки, где обычный брокер сообщений уже не тянет. Ниже — рабочая установка Kafka на чистый Ubuntu 24.04 без ZooKeeper, в современном режиме KRaft, с systemd-юнитом и проверкой, что всё действительно работает.

Что такое Kafka и почему KRaft, а не ZooKeeper

Kafka устроена иначе, чем классические брокеры вроде RabbitMQ. Вместо очередей у неё топики (topics), разбитые на партиции — это позволяет параллелить запись и чтение между несколькими потребителями. Продюсеры пишут события в топик, консьюмеры читают их независимо друг от друга и в своём темпе, а сами сообщения не удаляются сразу после прочтения — они хранятся заданное время (retention), и к ним можно вернуться повторно. Это принципиально отличает Kafka от очереди «прочитал — удалил»: она больше похожа на журнал событий (event log), который можно перечитывать.

Долгое время Kafka не могла работать без ZooKeeper — отдельного кластера для хранения метаданных и координации брокеров. Начиная с версии 3.x появился режим KRaft (Kafka Raft), где брокер сам хранит метаданные через встроенный протокол консенсуса Raft, без внешней зависимости. В актуальных релизах KRaft — единственный поддерживаемый режим, ZooKeeper из дистрибутива убран полностью. Для одиночного сервера или тестового стенда это упрощает жизнь: один процесс, один конфиг, никакого отдельного ZooKeeper-кластера рядом.

Важная оговорка: то, что описано в статье — это установка одного узла (single-node) для разработки, тестов или небольших нагрузок. Промышленный Kafka-кластер — это как минимум 3 брокера для отказоустойчивости, отдельный диск под логи и продуманная стратегия репликации партиций. Если вам нужен именно кластер — считайте эту статью первым шагом и точкой, откуда масштабироваться.

Требования к серверу и подготовка Ubuntu 24.04

Kafka прожорлива не столько по CPU, сколько по памяти (JVM-куча) и диску (она пишет каждое сообщение на диск, полагаясь на файловую систему и page cache ОС, а не только на RAM). Ориентировочные минимумы для одного брокера под небольшую-среднюю нагрузку:

Для честного теста берите VPS с NVMe и запасом по RAM — JVM без памяти начинает часто уходить в GC-паузы, и производительность просядет ещё до того, как упрётесь в диск.

Перед установкой обновите систему и создайте отдельного пользователя — запускать Kafka от root не стоит:

sudo apt update && sudo apt -y upgrade
sudo useradd -m -s /bin/bash kafka
sudo usermod -aG sudo kafka

Если ещё не настроили безопасный вход на сервер, сделайте это заранее — пригодится подключение по SSH-ключу и базовая настройка файрвола на Ubuntu 24.04 — Kafka открывает сетевой порт, и его лучше сразу ограничить.

Устанавливаем Java

Kafka работает на JVM, и без Java она не запустится. Актуальные версии Kafka требуют Java 11 как минимум, но рекомендуется современный LTS-релиз — в Ubuntu 24.04 в штатных репозиториях доступен OpenJDK 21:

sudo apt install -y openjdk-21-jdk-headless
java -version

Команда java -version должна вывести что-то вроде openjdk version "21...". Если в системе несколько версий Java, зафиксируйте нужную через update-alternatives --config java, чтобы Kafka случайно не подхватила старую.

Скачиваем и распаковываем Kafka

Готовых пакетов Kafka в apt-репозиториях Ubuntu нет — её ставят из официального tar-архива с сайта проекта. Уточните актуальную версию на kafka.apache.org/downloads (на момент подготовки статьи актуальна ветка 4.x, полностью на KRaft) и подставьте номер в переменную:

sudo su - kafka
KAFKA_VERSION=4.0.0
SCALA_VERSION=2.13

wget https://downloads.apache.org/kafka/${KAFKA_VERSION}/kafka_${SCALA_VERSION}-${KAFKA_VERSION}.tgz
tar -xzf kafka_${SCALA_VERSION}-${KAFKA_VERSION}.tgz
mv kafka_${SCALA_VERSION}-${KAFKA_VERSION} kafka

В итоге у пользователя kafka в домашней директории появится каталог ~/kafka с подпапками bin/ (скрипты запуска и утилиты) и config/ (шаблоны конфигов). Проверить, что архив не битый, можно сверив контрольную сумму с той, что публикуется рядом со ссылкой на скачивание на сайте проекта — это не лишнее, если сервер тянет пакет через нестабильный канал.

Настраиваем Kafka в режиме KRaft

В config/ лежит готовый шаблон kraft/server.properties (в старых сборках — kraft/broker.properties) — берём его за основу и правим под single-node сервер:

cd ~/kafka
mkdir -p /home/kafka/kraft-logs
cp config/kraft/server.properties config/kraft/server.properties.bak
nano config/kraft/server.properties

Ключевые параметры, которые стоит проверить и поправить:

process.roles=broker,controller
node.id=1
controller.quorum.voters=1@localhost:9093

listeners=PLAINTEXT://0.0.0.0:9092,CONTROLLER://localhost:9093
advertised.listeners=PLAINTEXT://<внешний-ip-или-домен>:9092
controller.listener.names=CONTROLLER

log.dirs=/home/kafka/kraft-logs

# сколько хранить сообщения — по умолчанию 168 часов (7 дней)
log.retention.hours=168

Для single-node сервера один процесс совмещает роль брокера и контроллера (process.roles=broker,controller) — так и должно быть, отдельный контроллер имеет смысл только в кластере из нескольких узлов. advertised.listeners важен, если к Kafka будут подключаться клиенты с других машин: туда нужно указать реальный внешний IP или доменное имя сервера, иначе клиенты извне получат от брокера внутренний адрес, до которого не достучатся.

Перед первым запуском KRaft-хранилище нужно один раз отформатировать — сгенерировать уникальный ID кластера и записать метаданные:

KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"
bin/kafka-storage.sh format -t "$KAFKA_CLUSTER_ID" -c config/kraft/server.properties

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

Автозапуск через systemd

Ручной запуск через bin/kafka-server-start.sh удобен для проверки, но после перезагрузки сервера или падения процесса Kafka не поднимется сама. Создайте юнит:

sudo nano /etc/systemd/system/kafka.service

[Unit]
Description=Apache Kafka (KRaft mode)
After=network.target

[Service]
Type=simple
User=kafka
Group=kafka
Environment="JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64"
ExecStart=/home/kafka/kafka/bin/kafka-server-start.sh /home/kafka/kafka/config/kraft/server.properties
ExecStop=/home/kafka/kafka/bin/kafka-server-stop.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

Путь JAVA_HOME проверьте командой update-alternatives --list java — на разных серверах он может отличаться. LimitNOFILE важен: Kafka активно работает с файловыми дескрипторами (по сегменту лога на партицию), и стандартный лимит в 1024 быстро становится узким местом при росте числа топиков.

sudo systemctl daemon-reload
sudo systemctl enable --now kafka
sudo systemctl status kafka

Если статус active (running) и в логах (journalctl -u kafka -f) нет исключений — брокер поднялся штатно.

Проверка: топик, продюсер, консьюмер и доступ извне

Создайте тестовый топик и прогоните через него сообщение — это надёжнее, чем просто смотреть на статус процесса:

cd ~/kafka
bin/kafka-topics.sh --create --topic test-topic \
  --bootstrap-server localhost:9092 \
  --partitions 3 --replication-factor 1

bin/kafka-topics.sh --list --bootstrap-server localhost:9092

Откройте два терминала: в одном запустите консьюмер, в другом — продюсер:

# терминал 1 — читаем сообщения
bin/kafka-console-consumer.sh --topic test-topic \
  --bootstrap-server localhost:9092 --from-beginning

# терминал 2 — пишем сообщения
bin/kafka-console-producer.sh --topic test-topic \
  --bootstrap-server localhost:9092

Введите пару строк в продюсере и Enter — они должны появиться в окне консьюмера. Если появились — базовая связка работает.

Для доступа с других машин (например, с сервера приложения) откройте порт 9092 только для нужных адресов, а не для всего интернета:

sudo ufw allow from <IP-приложения> to any port 9092 proto tcp
sudo ufw status

Держать 9092 открытым для всех — плохая идея: Kafka в этой конфигурации без аутентификации и TLS, и любой, кто достучится до порта, сможет читать и писать в топики. Для прод-окружения стоит добавить SASL-аутентификацию и TLS-шифрование трафика между клиентами и брокером — это отдельная настройка поверх той, что описана здесь, и без неё выкладывать Kafka в публичный интернет не стоит.

Если сервер параллельно нагружен другими сервисами, полезно сразу поднять базовый мониторинг ресурсов — Prometheus и Grafana на Ubuntu 24.04 покажут, когда JVM-куча Kafka начинает упираться в лимиты памяти, до того как это превратится в падение брокера.

Частые вопросы