С какими проблемами можно столкнуться при работе Apache Kafka в Kubernetes?

А, ну ты про Кафку в кубересах заговорил! Это, блядь, отдельная песня, ёпта. Вроде бы всё красиво: оркестрация, масштабирование, облака на небе... А на деле — овердохуища подводных камней, которые тебя так ебнут, что мало не покажется. Слушай, какие грабли тут самые жирные.

1. Сеть и как брокеры друг друга находят

• В чём засада: Кафка — хитрая жопа. Клиенты и брокеры общаются по адресам из advertised.listeners. А в кубересах у подов IP-шники меняются чаще, чем носки у распиздяя. Скажешь клиенту "коннектсься на kafka-0", а через минуту на этом айпишнике уже сидит какой-нибудь nginx для тестов.
• Как выкрутиться: Используй StatefulSet. Это, бля, святое. Он даёт подам стабильные имена: kafka-0, kafka-1, kafka-2. Плюс к нему headless Service (без кластерного айпи). Эта парочка создаёт DNS-записи вроде kafka-0.kafka-hs.namespace.svc.cluster.local. Вот на эту хуйню с горы и надо настраивать advertised.listeners в конфиге брокера. Тогда при пересоздании пода имя останется тем же, и все будут знать, куда стучаться.

2. Хранилище и скорость

• В чём засада: Кафка жрёт данные и производительность, как не в себя. Если взять стандартный сетевой диск из облака (типа pd-standard в GKE), то при нагрузке латенси взлетит до небес, и твоя система начнёт тормозить так, что волнение ебать.
• Как выкрутиться: Либо локальные тома (Local PersistentVolumes), либо SSD с гарантированными IOPS. Настраиваешь StorageClass с политикой реклайма Retain, чтобы при удалении StatefulSet'а томы не стирались автоматом, а то сам от себя охуеешь, когда все данные накроются медным тазом.

3. Масштабирование и переезд партиций

• В чём засада: Допустим, терпения ноль ебать, и ты увеличиваешь replicas в StatefulSet с 3 до 5. Новые брокеры встали, а партиции на них нихуя не переехали! Весь трафик как лежал на старых трёх, так и лежит. Автоматом это не работает, тут доверия ебать ноль.
• Как выкрутиться: Ручная работа, чувак. Надо брать утилиту kafka-reassign-partitions.sh и вручную или скриптом перекладывать партиции на новые брокеры. Для полного автоматизма можно прикрутить Cruise Control, но это уже отдельная история, сложная, как ёперный театр.

4. Жадность до ресурсов

• В чём засада: Кафка — тот ещё бздун. Может сожрать CPU на компрессии и памяти под кеш страниц (page cache) столько, что соседние пода на ноде начнут дохнуть от нехватки. Шумный сосед, блядь.
• Как выкрутиться: Жёстко настраивай requests и limits в манифесте. Выделяй памяти с запасом, и под heap для JVM, и под тот самый кеш. Идеально — вообще вынести Кафку на отдельные ноды, используя taints и tolerations. Скажи другим сервисам: "Идите вы все нахуй, это моя нода".

Вот тебе кусок StatefulSet, чтобы было понятнее, о чём речь:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: kafka-broker
spec:
  serviceName: kafka-hs # Это тот самый headless Service
  replicas: 3
  selector:
    matchLabels:
      app: kafka
  template:
    metadata:
      labels:
        app: kafka
    spec:
      containers:
      - name: kafka
        image: confluentinc/cp-kafka:latest
        env:
        - name: KAFKA_ADVERTISED_LISTENERS
          # Смотри, магия! Каждый под подставит своё имя в эту DNS-запись
          value: PLAINTEXT://$(POD_NAME).kafka-hs.default.svc.cluster.local:9092
        # ... остальные KAFKA_* переменные
        volumeMounts:
        - name: data
          mountPath: /var/lib/kafka/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      storageClassName: local-ssd # Вот он, быстрый локальный диск
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 200Gi

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