Вчера произошло столкновение моего стенда с чугунной жопой реальности 😁

Ничего особо страшного не случилось, просто после перезагрузки моего сервера все поды создались заново, а сохраненная конфигурация кластера 1С сбросилась в дефолт. Почему? А потому, что надо было не лениться и сразу создать volume для каталога кластера, также, как я это сделал для лицензий.

Но я не расстраиваюсь, потому что все равно хотел рассказать о хранении данных в Kubernetes подробнее. Теперь же для этого появился повод!

Итак, если поду нужно работать с файловой системой, то в его спецификации можно указать volumes и\или volumeMounts.
Типов volumes много, но они делятся на две больших группы: эфемерные (ephemeral) и постоянные (persistent). Эфемерные я сегодня не рассматриваю, потому что они удаляются сразу после перезапуска контейнера или после удаления пода (подов).
Кстати, можно сделать так, чтобы разные контейнерам внутри одного пода или вообще разные поды могли работать с одним и тем же volume совместно.

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

Дано: на узлах кластера Kubernetes или где-то рядом с ними есть "диски" разных типов, например, HDD, SSD, iSCSI, и прочие.
Администратор создает в кластере объекты типа StorageClass. Например, под быстрые ssd-диски он создаст класс с именем freaking-fast-ssd, а под hdd - horrifically-slow-hdd

Разработчик приложения в спецификации своего StatefulSet перечисляет volumeClaimTemplates (некие шаблоны). Каждый из шаблонов определяет, какой объем из какого хранилища нужно выделить каждому поду. Например, нужно 1 ГБ на быстрых дисках и еще 500 МБ на медленных дисках. А в спецификации пода он указывает, по какому пути монтировать какое хранилище:

...
kind: StatefulSet
...
spec:
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: freaking-fast-ssd
      resources:
        requests:
          storage: 1Gi
  - metadata:
      name: logs
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: horrifically-slow-hdd
      resources:
        requests:
          storage: 500Mi
  template:
    spec:
      containers:
      - name: app01
        volumeMounts:
        - name: data # имя совпадает с volumeClaimTemplate
          mountPath: /opt/my-app/data
        - name: logs # имя совпадает с volumeClaimTemplate
          mountPath: /var/log/my-app

Когда Kubernetes будет планировать размещение пода из этого StatefulSet, то возможны два варианта:
1️⃣ в контейнер будет смонтирован созданный ранее volume (упрощенно)
2️⃣ кластер создаст новый PersistentVolume с указанными параметрами и монтирует его в файловую систему контейнера

Как кластер понимает, что PersistentVolume относится к конкретному поду?
Он понимает это с помощью уникальных имен подов в StatefulSet и с помощью объекта под названием PersistentVolumeClaim.

Стоп. А что такое PersistentVolumeClaim?
Объясню простыми словами: PersistentVolume - это ресурс, а PersistentVolumeClaim - заявка на выделение ресурса. В динамической модели PersistentVolume формируются кластером автоматически по "заявкам" в виде PersistentVolumeClaim.
В случае StatefulSet, в котором перечислены volumeClaimTemplates, жизненный цикл PersistentVolumeClaim не зависит от жизненного цикла пода: при удалении пода PersistentVolumeClaim остается, а раз есть PersistentVolumeClaim, то и volume удален не будет.

В статической модели администратор создает PersistentVolume заранее.

Это был супер-краткий экскурс в Kubernetes Storage #k8s_101 🎓

Манифесты в README в 03-kind-hello-world-1c обновлены.
Дополнительно указал:
🟡 как работать с кластером 1С в Kubernetes с локальной машины, если на нее установлен rac (спасибо @nixel2007, что обратил на это мое внимание)
🟡 как сделать так, чтобы настройки DNS на локальной машине переживали перезагрузку

В следующей серии наглядно покажу, как кластер 1С умеет переживать удаление пода. Он буквально возрождается из пепла, как феникс 🔥