Apache Kafka - сопоставление объемов для файлов журнала сообщений в Kubernetes (K8s)

#kubernetes #apache-kafka

Вопрос:

Когда мы развертываем apache kafka в Linux / Windows, у нас есть log.dirs и broker.id свойства. на чистом металле файлы сохраняются на отдельных экземплярах хоста. Однако при развертывании через K8s в общедоступном облаке должна быть какая-то форма подключения тома, чтобы убедиться, что файлы журнала транзакций где-то сохранены?

Кто-нибудь делал это на K8s? Я не имею в виду Confluent (потому что это платная подписка).

1. Диаграммы Confluent Helm не являются платным решением. В любом случае, это все тот же Apache Kafka, и постоянные объемы необходимо настроить… Некоторые люди используют OpenEBS, Portworx или Rook в k8s для решения этой проблемы.

Ответ №1:

Насколько я понимаю, вы просто спрашиваете, как работать с хранилищем в Kubernetes.

Вот отличный клип, в котором рассказывается о хранилище Kubernetes, которое я бы порекомендовал вам.

В Kubernetes используются тома

Файлы на диске в контейнере являются эфемерными, что создает некоторые проблемы для нетривиальных приложений при запуске в контейнерах. Во-первых, при сбое контейнера kubelet перезапустит его, но файлы будут потеряны — контейнер запускается с чистого состояния. Во-вторых, при совместном запуске контейнеров в Pod часто необходимо совместно использовать файлы между этими контейнерами. Volume Абстракция Kubernetes решает обе эти проблемы.

Существует много типов томов, некоторые из которых зависят от облака, такие как awsElasticBlockStore, gcePersistentDisk, azureDisk и azureFile.

Существуют также другие типы, такие как glusterfs, iscsi, nfs и многие другие, которые перечислены здесь.

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

PersistentVolume (PV) — это часть хранилища в кластере, которая была подготовлена администратором. Это ресурс в кластере точно так же, как узел является ресурсом кластера. PV — это плагины для томов, подобные Volumes, но имеют жизненный цикл, независимый от любого отдельного модуля, который использует PV. Этот объект API фиксирует детали реализации хранилища, будь то NFS, iSCSI или система хранения, зависящая от облачного провайдера.

A PersistentVolumeClaim (PVC) — это запрос пользователя на хранение. Это похоже на pod. Модули потребляют ресурсы узла, а PVCS — ресурсы PV. Модули могут запрашивать определенные уровни ресурсов (процессор и память). Заявки могут запрашивать определенный размер и режимы доступа (например, могут быть подключены один раз для чтения / записи или только для чтения много раз).

Вот ссылка на Portworx Kafka Kubernetes в рабочей среде: как запустить HA Kafka на Amazon EKS, GKE и AKS, которые также могут быть полезны для вас.

И если вас интересует производительность, то сравнение производительности хранилища Kubernetes — отличное чтение за 10 минут.

Я надеюсь, что эти материалы помогут вам разобраться в хранилище Kubernetes.