Экспериментальная установка PostgresXL на Kubernetes с локальными томами

Я делаю Геданкенэксперимент о развертывании PostgresXL на Kubernetes (k8s), где каждый узел данных использует местный (непосредственно прикрепленный) место хранения.

Представьте, что у нас есть следующие узлы:

• 2x Высокопроизводительные машины с невероятно быстрыми твердотельными накопителями Optane DC и NVDIMM. Эти узлы зарегистрированы с помощью k8s и помечены как type: datanode.
• 1x машина зарегистрирована с k8s и помечена как type: GTM.
• 2x машины, зарегистрированные с помощью k8s и маркированные как type: coodinator.

Допустим, каждая метка создает «группу узлов» (например, type: datanode метка составляет группу с двумя узлами).
Предположим также, что у каждого узла есть /data точка монтирования (в ОС хоста), которая сопоставлена ​​с ее базовым самым быстрым диском (или логическим томом LVM).

Я бы развернул такую ​​архитектуру:

                        --------------
                        |   gtm_0    |
                        --------------
                       / |          | \
                     /   |          |   \
                   /     |          |     \
                 /       |          |       \
               /         |          |         \
             /           |          |           \
           /             |          |             \
         /               |          |               \
       /       ------------        ------------      \
      |        | coord_0  |        | coord_1  |       |
      |        ------------        ------------       |
      |       /             \    /             \      |
      |     /                 \/                 \    |
------------      ------------/\------------      ------------
|  data_0  |     /                          \     |  data_1  |
------------ ----                            ---- ------------

Которая пришла из postgres-xl docker создать образ.

Я хочу в конечном итоге масштабировать по горизонтали каждую из трех категорий узлов, и мне нужно стабильное имя для каждой из них, поэтому я бы создал три StatefulSets (каждый из которых поддерживается той же безголовой службой): ss-datanodes, ss-gtms и ss-coords. В каждом из этих StatefulSet шаблон модуля выберет только соответствующие узлы (например: type: datanode узлы для ss-datanodes pods) и иметь соответствующее изображение (например, GTM для ss-gtms устанавливать).

Это позволит k8s «перемешивать» поды в одной группе узлов.

Тем не менее, я не хочу использовать NAS, каждая капсула должна использовать только DAS для максимальной производительности.
Для этого я создаю StorageClass без подготовки и с режимом привязки, установленным на «WaitForFirstConsumer».
Затем я бы создал три PersistentVolumes, эти PV будут типа localукажите на /data точка монтирования и отличается только nodeAffinity.
Я бы также создал три PersistenceVolumeClaim (PVC) соответствие сопутствующим PV.

Наконец, я бы добавил PVC в шаблоны модулей в StatefulSetс.

Это должно позволить k8s:

• Запланируйте компоненты (GTM, Координатор, DataNode) только в их группе узлов.
• Перемешайте модули в их группе узлов.
• Пусть /data точка монтирования будет доступна на каждом модуле.

Я делаю следующее предположение о PostgresXL:

• Компоненты можно вызывать в любом порядке (например, координата_0, данные_1, gtm_0, данные_0, координата_1).
• Каждый компонент может обрабатывать данные, записанные другим компонентом того же типа (например, модули data_0 и data_1 можно поменять местами и заставить использовать другие данные и продолжать работу). Это не кажется необоснованным, поскольку единственная идентификация модуля - это его имя хоста.

Подойдет ли эта установка для PostgresXL и что я получу, используя k8s?

Одна вещь, которая полезна в k8s, - это HPA, которую можно использовать для автоматического добавления еще одного узла datanode и масштабирования ss-datanodes вверх.
Однако по всему Интернету я прочитал, что управление состоянием сложно в рамках k8s. Но это не сложно, поэтому я должен кое-что пропустить.