Конфигурация и постоянное хранилище в Kubernetes

В теме 7 было показано, как Kubernetes поддерживает желаемое состояние нагрузки: Deployment создаёт ReplicaSet, тот — поды, планировщик выбирает узлы, kubelet запускает контейнеры, а Service даёт им общий адрес. Все поды в этих примерах были взаимозаменяемыми: если под погибал, контроллер создавал новый с другим именем на другом узле, и ничего не терялось, потому что терять было нечего. Такая модель хорошо подходит для backend приложения «Заметки», но не для его базы данных. Остаются два вопроса, на которые тема 7 сознательно не отвечала. Первый: откуда контейнер получает параметры, пароли и конфигурационные файлы, если образ один для всех сред. Второй: где хранить данные, которые должны пережить под, узел и обновление.

Из темы 3 известно, что корневая файловая система контейнера — это слои образа и верхний слой записи overlay2, который исчезает вместе с контейнером. В теме 5 эта проблема решалась на одном хосте Docker-томами и bind mounts: каталог хоста монтировался в контейнер и переживал его пересоздание. В кластере такой приём не работает: под может быть перезапущен на другом узле, где каталога нет, а узел может исчезнуть целиком. Нужен механизм, который отделяет данные от узла, выделяет их по заявке и подключает туда, где запланирован под.

Kubernetes решает обе задачи набором объектов API. Конфигурация хранится в ConfigMap и Secret и доставляется в контейнер переменными окружения или файлами; от способа доставки зависит, увидит ли работающий процесс изменения. Данные хранятся в томах, которые описываются парой PersistentVolume и PersistentVolumeClaim, создаются по профилю StorageClass и подключаются драйвером по стандарту CSI. Приложения, которым нужна устойчивая идентичность и собственный том у каждой реплики, управляются контроллером StatefulSet.

Изложение построено в порядке движения данных. Сначала рассматривается конфигурация и семантика её обновления, затем Secret и то, от чего он на самом деле защищает. Далее — модель томов, жизненный цикл PV, классы хранения и режимы доступа, затем путь тома через CSI от заявки до точки монтирования в поде. Завершают тему StatefulSet, снимки томов и операторы баз данных, а также раздел об ограничениях и типичных ошибках. Сквозной пример — PostgreSQL приложения «Заметки».

Конфигурация вне образа: ConfigMap

Почему конфигурация отделяется от образа

Методология «The Twelve-Factor App» определяет конфигурацию как всё, что меняется между развёртываниями одного и того же кода: адреса баз данных, учётные данные внешних сервисов, флаги функций, уровни журналирования, — и требует хранить её вне кода ¹. В контейнерном мире это требование усиливается принципом неизменяемости из темы 5: образ собирается один раз, получает digest и без изменений проходит через тестовую и рабочую среды. Если адрес базы данных зашит в образ, для каждой среды нужен свой образ, и тестировалось уже не то, что выкатывается. Если в образ зашит пароль, он попадает в каждый слой реестра и в каждую копию образа на узлах.

Отсюда два требования к механизму конфигурации. Он должен связывать один образ с разными наборами параметров без пересборки. И он должен быть частью декларативного описания: параметры хранятся в API-сервере как объекты, версионируются в Git вместе с манифестами и попадают в под через тот же цикл согласования, что и всё остальное.

Объект ConfigMap

ConfigMap (англ. ConfigMap) — объект API, хранящий несекретные данные в виде пар «ключ — значение» ². Значение может быть короткой строкой (LOG_LEVEL: info) или содержимым целого файла (nginx.conf, postgresql.conf). Строковые данные лежат в поле data, двоичные — в binaryData в кодировке base64. Размер объекта ограничен 1 МиБ ²: ConfigMap предназначен для параметров, а не для больших данных.

ConfigMap удобно создавать из файла, чтобы не переписывать содержимое вручную в YAML:

kubectl create configmap pg-config --from-file=postgresql.conf --dry-run=client -o yaml

apiVersion: v1
data:
  postgresql.conf: |
    listen_addresses = '*'
    max_connections = 50
    work_mem = 4MB
kind: ConfigMap
metadata:
  name: pg-config

Сам по себе ConfigMap ни на что не влияет: это просто данные в etcd. Чтобы приложение их увидело, под должен на них сослаться, а приложение — прочитать. Для PostgreSQL это означает, что файл нужно не только смонтировать, но и указать серверу: postgres -c config_file=/etc/postgresql/postgresql.conf. Смонтированный в произвольный каталог файл, на который сервер не смотрит, остаётся мёртвым грузом, и проверять применение конфигурации нужно со стороны приложения (SHOW max_connections;), а не по наличию файла.

Три способа доставки в контейнер

Данные ConfigMap попадают в контейнер тремя способами, и различия между ними важнее, чем кажется по синтаксису.

Первый способ — переменные окружения: отдельный ключ через env.valueFrom.configMapKeyRef или все ключи сразу через envFrom.configMapRef. Значения подставляются kubelet при создании контейнера; через переменные их можно передать и в аргументы команды: запись $(VAR) в command или args раскрывается Kubernetes до запуска процесса.

Второй способ — том типа configMap: каждый ключ становится файлом в смонтированном каталоге. Список items позволяет выбрать отдельные ключи и переименовать файлы, defaultMode — задать права.

Третий способ — тот же том, но смонтированный с полем subPath: в заданный путь контейнера подключается не каталог, а один файл из тома. Так поступают, когда нужно положить файл в каталог, где уже есть другие файлы образа (например, /etc/nginx/conf.d/default.conf), и монтирование целого каталога спрятало бы их.

containers:
  - name: probe
    image: busybox:1.37.0
    env:
      - name: LEVEL                  # способ 1: переменная окружения
        valueFrom:
          configMapKeyRef:
            name: probe-config
            key: level
    volumeMounts:
      - name: cfg                    # способ 2: каталог /cfg-dir/level
        mountPath: /cfg-dir
      - name: cfg                    # способ 3: один файл через subPath
        mountPath: /cfg-sub/level
        subPath: level
volumes:
  - name: cfg
    configMap:
      name: probe-config

Схема на рисунке ниже показывает, что физически стоит за каждым способом: копия значения в окружении процесса, каталог на узле, который kubelet обновляет, и bind-монтирование конкретного файла, привязанное к его первой версии.

Обновление конфигурации: что видит работающий процесс

Когда ConfigMap изменён в API-сервере, вопрос «применилась ли конфигурация» распадается на два: обновились ли данные внутри контейнера и перечитал ли их процесс.

Переменные окружения процесса — это копия, сделанная при execve. Ни Linux, ни Kubernetes не умеют менять окружение работающего процесса, поэтому значение в env остаётся прежним до пересоздания контейнера ².

Том configMap kubelet обновляет сам. Устроен он так: в каталоге тома лежит скрытый каталог с меткой времени (..2026_10_22_10_15_00.123456789), символическая ссылка ..data указывает на него, а видимые файлы — это ссылки level -> ..data/level. При обновлении kubelet записывает новый каталог с меткой времени и атомарно переставляет ссылку ..data вызовом rename. Приложение никогда не видит наполовину записанный набор файлов: либо все старые, либо все новые.

Вид каталога изнутри контейнера (вывод сокращён; метка времени будет другой):

kubectl exec cm-probe -- ls -la /cfg-dir

drwxr-xr-x    2 root  root   60 Oct 22 10:15 ..2026_10_22_10_15_00.123456789
lrwxrwxrwx    1 root  root   32 Oct 22 10:15 ..data -> ..2026_10_22_10_15_00.123456789
lrwxrwxrwx    1 root  root   12 Oct 22 10:15 level -> ..data/level

Задержка обновления не нулевая. Документация оценивает её как период синхронизации kubelet плюс задержку распространения кэша; при стратегии по умолчанию (watch) последняя мала, а период синхронизации по умолчанию — 1 минута ². На практике новое содержимое появляется в поде через десятки секунд, в худшем случае — немного больше минуты, и рассчитывать на мгновенное применение нельзя.

Монтирование через subPath не обновляется никогда ². Причина в механизме: при старте контейнера kubelet разрешает путь level внутри тома (а это ссылка на файл в каталоге с меткой времени) и делает bind-монтирование конкретного файла. Когда kubelet создаёт новый каталог и переставляет ..data, смонтированный файл по-прежнему указывает на старый inode, и контейнер продолжает видеть первую версию.

Последний столбец не менее важен, чем предпоследний. Новый файл в каталоге ещё не означает новой конфигурации: nginx перечитывает её по сигналу SIGHUP (nginx -s reload), PostgreSQL — по вызову SELECT pg_reload_conf(), а многие приложения читают конфигурацию только при старте. Даже после перечитывания часть параметров не применяется: в PostgreSQL work_mem или log_statement меняются на лету, а max_connections и shared_buffers требуют перезапуска сервера, о чём сообщает столбец pending_restart представления pg_settings ¹⁴.

Поэтому в эксплуатации применяют два приёма, которые делают обновление предсказуемым. Первый — хэш конфигурации в аннотации шаблона пода: инструмент развёртывания вычисляет SHA-256 от содержимого ConfigMap и записывает его в spec.template.metadata.annotations. Изменилась конфигурация — изменился шаблон — Deployment или StatefulSet выполняет штатное поэтапное обновление из темы 7, с пробами готовности и возможностью отката. Тот же эффект даёт генератор Kustomize, добавляющий хэш к имени ConfigMap (pg-config-7b9k2m5f4c), и ручная команда kubectl rollout restart, которая записывает в шаблон аннотацию с временем перезапуска. Второй приём — неизменяемые ConfigMap (immutable: true, стабильно с Kubernetes 1.21): объект нельзя изменить, только создать новый под другим именем, а kubelet перестаёт следить за ним, что снижает нагрузку на API-сервер в больших кластерах ².

Secret: что он защищает и чего не защищает

Устройство объекта Secret

Secret (англ. Secret) — объект API для небольших объёмов конфиденциальных данных: паролей, токенов, ключей TLS ³. Синтаксически он почти совпадает с ConfigMap и доставляется в контейнер теми же тремя способами с той же семантикой обновления. Отличия — в поле type и в обращении с данными на узле.

Поле type задаёт ожидаемую структуру: Opaque — произвольные ключи, kubernetes.io/tls — обязательные tls.crt и tls.key, kubernetes.io/dockerconfigjson — учётные данные реестра образов, kubernetes.io/basic-auth и kubernetes.io/ssh-auth — типовые учётные данные. Тип проверяется API-сервером, но на хранение не влияет.

В поле data значения записываются в base64, в поле stringData — открытым текстом, который API-сервер сам перекодирует при записи. Base64 — кодирование, а не шифрование: оно нужно, чтобы в JSON и YAML помещались произвольные байты, и обращается одной командой без всякого ключа. Шестибайтовый пароль s3cr3t превращается в восемь символов czNjcjN0 (base64 увеличивает объём в 4/3 раза), и любой, кто видит манифест, видит и пароль:

kubectl -n lab08 get secret pg-auth -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d

Там, где Secret всё же обрабатывается иначе, чем ConfigMap, речь идёт об узле. Kubelet получает секрет только для подов, запланированных на этот узел, и при монтировании тома хранит его копию в tmpfs — в оперативной памяти, а не на диске узла ³. Команда kubectl describe secret показывает только имена ключей и размеры значений. Это защита от случайного раскрытия, а не от злоумышленника с правами в кластере.

Кто может прочитать секрет

Значение Secret доступно каждому, кто может получить объект через API: RBAC-правила с глаголами get, list или watch на ресурс secrets в пространстве имён дают доступ ко всем его секретам. Ошибка понимания здесь распространённая: list выглядит как «посмотреть список», но ответ на него содержит объекты целиком, вместе с данными.

Документация указывает и на менее очевидный канал: любой, кто может создать под в пространстве имён, может смонтировать в него любой Secret этого пространства и прочитать его изнутри контейнера ³. Права на создание Deployment, Job или CronJob эквивалентны тому же. Поэтому граница доступа к секретам на деле — пространство имён, а не отдельный объект, и секреты разных команд держат в разных пространствах. Подробная настройка RBAC — в теме 11.

Ещё три канала связаны с доставкой. Переменная окружения видна в /proc/PID/environ любому процессу с правами того же пользователя, наследуется дочерними процессами и нередко попадает в журналы и отчёты об аварии; файл в томе этих недостатков лишён, поэтому для секретов монтирование предпочтительнее. Секрет, созданный командой kubectl create secret --from-literal=password=..., остаётся в истории оболочки и виден в списке процессов во время выполнения. И наконец, резервная копия etcd содержит все секреты кластера — а в каком виде, зависит от настройки шифрования.

Шифрование в etcd: EncryptionConfiguration

По умолчанию Secret хранится в etcd незашифрованным ³. API-сервер сериализует объект в protobuf и записывает в ключ /registry/secrets/<namespace>/<name>; любой, у кого есть доступ к etcd, его снимку или диску узла управления, читает пароли без всякого ключа. Для минимальных кластеров вроде minikube или kubeadm с настройками по умолчанию это именно так; управляемые облачные кластеры, как правило, включают шифрование на стороне провайдера, но это нужно проверять в документации конкретного сервиса, а не предполагать.

Шифрование включается флагом API-сервера --encryption-provider-config, который указывает на файл EncryptionConfiguration ⁴:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - secretbox:                 # первый провайдер шифрует новые записи
          keys:
            - name: key1
              secret: <32 байта в base64>
      - identity: {}               # позволяет читать ещё не зашифрованные объекты

Порядок провайдеров имеет смысл. Первый в списке используется для записи, все — для чтения: API-сервер узнаёт, каким провайдером зашифрован объект, по префиксу значения вида k8s:enc:secretbox:v1:key1:. Провайдер identity означает «без шифрования»; если он стоит первым, шифрования нет, и именно такова конфигурация по умолчанию ⁴.

Документация сравнивает провайдеры по стойкости и удобству. aescbc не рекомендуется из-за уязвимости режима CBC к атаке padding oracle, aesgcm требует ротации ключа каждые 200 000 записей, secretbox (XSalsa20 и Poly1305) — быстрый и стойкий вариант с локальным ключом ⁴. У всех трёх ключ лежит в файле на узле управления, и злоумышленник, получивший этот узел, получает и ключ. Провайдер kms v2 (стабилен с Kubernetes 1.29) использует конвертное шифрование: данные шифруются ключом данных, а тот — ключом во внешней службе управления ключами (облачный KMS, HSM, Vault), который никогда не покидает её ⁴.

Включение шифрования не трогает уже записанные объекты: они остаются открытыми до следующей записи. Поэтому после перезапуска API-сервера все секреты перезаписывают, а результат проверяют прямо в etcd:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -
etcdctl get /registry/secrets/default/secret1 | hexdump -C | head -3

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 73 65 63 72 65 74  |s/default/secret|
00000020  31 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |1.k8s:enc:aescbc|

Пример вывода взят из документации и показывает провайдер aescbc ⁴; без шифрования в том же месте был бы виден protobuf с именами ключей и значениями открытым текстом.

Внешние хранилища секретов

Шифрование в etcd закрывает только один канал — носитель данных. Остаются две задачи, которые Secret не решает: как хранить секреты в Git вместе с остальными манифестами и как управлять их ротацией и аудитом централизованно. Для них используются внешние инструменты; ни один не отменяет остальных мер, потому что почти все в итоге создают обычный Secret в кластере.

Sealed Secrets устроен асимметрично: утилита kubeseal шифрует секрет открытым ключом контроллера, получившийся объект SealedSecret можно хранить в публичном репозитории, а закрытый ключ существует только в кластере. SOPS шифрует значения, оставляя ключи YAML открытыми, поэтому изменения видны в истории Git. External Secrets Operator вводит объекты SecretStore (как подключиться к хранилищу) и ExternalSecret (что из него взять и в какой Secret положить). Vault Agent Injector и Secrets Store CSI Driver доставляют секрет файлом прямо в под; второй — через CSI-драйвер, устроенный так же, как драйверы томов, рассмотренные ниже в разделе о CSI. Наиболее сильная модель — динамические учётные данные: Vault создаёт пользователя PostgreSQL на время жизни пода и удаляет его по истечении срока, так что утечка пароля перестаёт быть вечной.

Тома и постоянное хранилище: PV, PVC и StorageClass

От слоя записи к тому

Том (англ. volume) в Kubernetes — каталог, доступный контейнерам пода и подключаемый в их файловые системы через volumeMounts. Тома делятся на эфемерные, живущие столько же, сколько под, и постоянные, существующие независимо от него.

Самый простой эфемерный том — emptyDir: пустой каталог на диске узла (или в памяти при medium: Memory), создаваемый при размещении пода и удаляемый вместе с ним. Он переживает перезапуск контейнера, в отличие от слоя записи overlay2, но не переживает пересоздание пода. Его типичное назначение — обмен файлами между контейнерами пода и кэш. Тома configMap и secret из предыдущих разделов тоже эфемерные. Том hostPath монтирует каталог узла, как bind mount из темы 5, и наследует его недостатки: данные привязаны к узлу, а под получает доступ к его файловой системе, что в многопользовательском кластере опасно.

Постоянному хранилищу нужны два свойства, которых нет у перечисленного: данные не должны зависеть от узла и должны выделяться по запросу, без ручной работы администратора для каждого приложения. Kubernetes разделяет эту задачу между тремя объектами. Схема на рисунке ниже показывает разделение ответственности: разработчик описывает потребность (заявку), администратор — профили хранилища, а драйвер превращает одно в другое.

PersistentVolume и PersistentVolumeClaim

PersistentVolume (PV) — объект уровня кластера, представляющий конкретный экземпляр хранилища: облачный диск, LUN системы хранения, экспорт NFS, образ Ceph RBD ⁵. PV не принадлежит пространству имён и описывает свойства тома: ёмкость, режимы доступа, класс, политику освобождения и источник (для CSI — имя драйвера и идентификатор тома в системе хранения).

PersistentVolumeClaim (PVC) — заявка на хранилище в пространстве имён приложения: «нужно 10 ГиБ класса standard с доступом ReadWriteOnce». Под ссылается на заявку, а не на том, поэтому манифест приложения не меняется от того, работает ли кластер в облаке или в собственном центре обработки данных ¹².

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: scratch
  namespace: lab08
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: standard     # пропущено — класс по умолчанию; "" — без динамического выделения
  resources:
    requests:
      storage: 100Mi

Связывание (англ. binding) выполняет контроллер томов в kube-controller-manager. Он ищет PV, который удовлетворяет заявке по классу, режимам доступа, ёмкости (не меньше запрошенной) и селектору, и записывает связь в обе стороны: в PV — поле claimRef с именем и UID заявки, в PVC — volumeName. Связь взаимно-однозначная: один PV связан не более чем с одной заявкой, даже если ёмкость тома больше запрошенной ⁵. Если подходящего тома нет и класс допускает динамическое выделение, том создаётся по заявке; если нет и этого, PVC остаётся в фазе Pending, а использующий его под — неразмещённым.

Жизненный цикл PV и политика освобождения

У PV четыре фазы ⁵. Available — том свободен. Bound — связан с заявкой. Released — заявка удалена, но том ещё не возвращён в оборот. Failed — автоматическое освобождение не удалось. У PVC фазы Pending, Bound и Lost (связанный том исчез). Диаграмма на рисунке ниже показывает переходы и роль политики освобождения.

Что случится с данными при kubectl delete pvc, определяет поле PV persistentVolumeReclaimPolicy. При Delete том удаляется вместе с объектом PV и данными в системе хранения; это значение по умолчанию для динамически созданных томов, наследуемое из reclaimPolicy класса. При Retain объект PV переходит в Released, данные остаются, но новая заявка к такому тому сама не привяжется: в claimRef ещё записан UID удалённой заявки. Администратор либо копирует данные и удаляет PV, либо очищает claimRef, после чего том становится Available. Политика Recycle (rm -rf содержимого) объявлена устаревшей ⁵.

kubectl patch pv pvc-3f1c... -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
kubectl delete pvc scratch
kubectl get pv

NAME          CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM           STORAGECLASS
pvc-3f1c...   100Mi      RWO            Retain           Released   lab08/scratch   standard

Удаление защищено финализаторами. Пока заявку использует хотя бы один под, финализатор kubernetes.io/pvc-protection не даёт ей исчезнуть: kubectl delete pvc переводит её в состояние Terminating, и удаление завершается после остановки пода ⁵. Аналогично kubernetes.io/pv-protection защищает связанный PV. Это частая причина «зависшего» удаления, и чинится она не снятием финализатора, а поиском пода, который держит том.

Политику полезно выбирать по ценности данных. Для базы данных рабочей среды Retain в классе хранения — страховка от опечатки в kubectl delete; ценой становится ручная уборка освобождённых томов, которые продолжают занимать место и, в облаке, оплачиваться.

StorageClass и динамическое выделение

Статическое выделение — администратор заранее создаёт PV, заявки связываются с ними — сохранилось для особых случаев (импорт существующего диска, локальные диски), но основной путь — динамическое выделение (англ. dynamic provisioning): том создаётся в ответ на заявку по профилю, описанному объектом StorageClass ⁶.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: ebs.csi.aws.com           # какой драйвер создаёт тома
parameters:                            # передаются драйверу как есть
  type: gp3
  iops: "3000"
reclaimPolicy: Retain                  # по умолчанию Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Поле provisioner называет драйвер, parameters интерпретирует только он (тип диска, число реплик, файловая система). Аннотация is-default-class делает класс классом по умолчанию для заявок без storageClassName; в minikube это класс standard с провайдером k8s.io/minikube-hostpath, который создаёт каталоги внутри узла.

Поле volumeBindingMode определяет момент создания тома. При Immediate (по умолчанию) том создаётся сразу после появления заявки, ещё до того, как известен под и его узел. При WaitForFirstConsumer создание откладывается, пока планировщик не выберет узел для первого пода, использующего заявку; выбор записывается в аннотацию PVC volume.kubernetes.io/selected-node, и драйвер создаёт том в топологии этого узла ⁶.

Разница существенна в кластере из нескольких зон доступности. Облачный блочный диск существует в одной зоне и подключается только к ВМ той же зоны. Рассмотрим численный пример: кластер в трёх зонах, база данных из трёх реплик со строгим правилом антиаффинности «не более одной реплики в зоне». При Immediate зона каждого диска выбирается без учёта будущего пода; если считать выбор равновероятным и независимым, все три диска окажутся в разных зонах с вероятностью

P = \frac{3!}{3^3} = \frac{6}{27} \approx 0{,}22.

С вероятностью около 0,78 два диска попадут в одну зону, и одна из реплик никогда не будет размещена: планировщик сообщит о конфликте узловой аффинности тома (volume node affinity conflict). При WaitForFirstConsumer сначала выбирается узел с учётом всех ограничений пода, затем в его зоне создаётся диск, и конфликт исключён по построению. По той же причине режим WaitForFirstConsumer обязателен для локальных томов, существующих на одном узле.

Поле allowVolumeExpansion: true разрешает увеличивать заявку: пользователь меняет spec.resources.requests.storage в PVC, драйвер расширяет том, а файловая система расширяется на узле, у большинства CSI-драйверов — без остановки пода ⁵. Уменьшить том нельзя. Класс хранения после создания почти неизменяем: поменять parameters или reclaimPolicy существующего класса нельзя, и для новых свойств создают новый класс.

Режимы доступа

Поле accessModes описывает, как том может быть подключён ⁵.

Две детали понимаются неверно чаще всего. Во-первых, RWO ограничивает узел, а не под: несколько подов на одном узле могут одновременно смонтировать RWO-том на запись. Именно для исключения этого введён режим ReadWriteOncePod, стабильный с Kubernetes 1.29 и доступный только для CSI-томов ⁵. Для базы данных, у которой файлы данных должен открывать ровно один сервер, RWOP точнее выражает требование. Во-вторых, режимы доступа используются для сопоставления заявок и томов и для ограничения подключения, но не обеспечивают защиту от записи после монтирования ⁵. Том, поддерживающий несколько режимов, в каждый момент подключён в одном из них.

Режим доступа отличается от режима тома volumeMode. При Filesystem (по умолчанию) драйвер создаёт на устройстве файловую систему и монтирует каталог; при Block под получает сырое блочное устройство, что нужно некоторым СУБД и системам хранения, управляющим диском самостоятельно.

Container Storage Interface: как том попадает в под

Зачем понадобился CSI

В ранних версиях Kubernetes код подключения каждой системы хранения — AWS EBS, GCE PD, Cinder, Ceph RBD, GlusterFS — находился в основном репозитории (так называемые встроенные, англ. in-tree, плагины). Исправление ошибки в драйвере требовало выпуска новой версии Kubernetes, производители систем хранения зависели от его цикла выпусков, а ошибка в драйвере могла уронить kubelet. Промежуточное решение FlexVolume требовало устанавливать исполняемые файлы на каждый узел.

Container Storage Interface (CSI) — спецификация gRPC-интерфейса между оркестратором и драйвером хранилища ⁷. Драйвер работает отдельными контейнерами, Kubernetes обращается к нему через Unix-сокет, а один и тот же драйвер пригоден для любого оркестратора, реализующего спецификацию. Спецификация делит интерфейс на три службы:

• Identity — сведения о драйвере и его возможностях (GetPluginInfo, GetPluginCapabilities, Probe);
• Controller — операции, не привязанные к узлу: создание и удаление томов, подключение к узлу, снимки, расширение;
• Node — операции на конкретном узле: подготовка устройства и монтирование.

Встроенные плагины популярных систем хранения сегодня работают через механизм миграции на CSI: старое поле в PV транслируется в вызовы соответствующего CSI-драйвера, а часть встроенных плагинов удалена из кода полностью ⁵.

Четыре вызова: путь тома от заявки до точки монтирования

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

1. CreateVolume (служба Controller). Сайдкар external-provisioner видит новую PVC с классом этого драйвера (при WaitForFirstConsumer — после выбора узла) и вызывает CreateVolume с размером, параметрами класса и требованиями к топологии. Драйвер создаёт диск через API облака и возвращает его идентификатор; external-provisioner создаёт объект PV, который контроллер томов связывает с заявкой.
2. ControllerPublishVolume (Controller). Когда под с этой заявкой назначен на узел, контроллер attach/detach в kube-controller-manager создаёт объект VolumeAttachment, сайдкар external-attacher видит его и вызывает ControllerPublishVolume с идентификаторами тома и узла. Для облачного диска это вызов API «подключить диск к ВМ»: на узле появляется блочное устройство. Для сетевых файловых систем, где подключать нечего, драйвер объявляет отсутствие этой возможности, и шаг пропускается.
3. NodeStageVolume (Node). Kubelet на узле вызывает драйвер напрямую через сокет. Драйвер находит устройство, при необходимости создаёт файловую систему и монтирует её в промежуточный каталог узла вида /var/lib/kubelet/plugins/kubernetes.io/csi/<драйвер>/<хэш>/globalmount. Это делается один раз на узел, сколько бы подов узла ни использовали том.
4. NodePublishVolume (Node). Kubelet просит драйвер подключить том в каталог конкретного пода /var/lib/kubelet/pods/<UID пода>/volumes/kubernetes.io~csi/<имя PV>/mount; обычно это bind-монтирование из промежуточного каталога. Именно этот каталог container runtime затем подключает в контейнер по mountPath.

При удалении пода вызовы выполняются в обратном порядке: NodeUnpublishVolume, NodeUnstageVolume (когда том не нужен ни одному поду узла), ControllerUnpublishVolume (отключение диска от ВМ), и при удалении заявки с политикой Delete — DeleteVolume. Разделение stage и publish объясняет поведение RWO: на одном узле устройство подготовлено один раз, и несколько подов узла получают к нему bind-монтирования; на другой узел тот же диск не будет подключён, пока не отключён от первого, и под второго узла ждёт в ContainerCreating с событием Multi-Attach error.

Компоненты драйвера и сайдкары

CSI-драйвер в кластере состоит из двух частей. Контроллерная часть — Deployment (или StatefulSet) из одной-двух реплик с контейнером драйвера и набором стандартных сайдкаров. Узловая часть — DaemonSet, под которого работает на каждом узле с доступом к /dev и каталогам kubelet. Сайдкары — общие для всех драйверов контейнеры проекта kubernetes-csi, которые следят за объектами API и переводят их в вызовы CSI, так что автору драйвера не нужно писать контроллеры Kubernetes ⁸.

Объект CSIDriver сообщает Kubernetes свойства драйвера, например attachRequired: false для драйверов без шага подключения к узлу. Объект CSINode хранит, какие драйверы зарегистрированы на узле и какой топологии он принадлежит. Когда под висит в ContainerCreating с событием о неудачном подключении тома, именно по этой цепочке ищут место обрыва: есть ли PV, есть ли VolumeAttachment и в каком он состоянии, что в журналах сайдкара и узловой части драйвера.

Снимки и клонирование: VolumeSnapshot

API снимков томов (стабилен с Kubernetes 1.20) повторяет модель PV и PVC ¹⁰. VolumeSnapshotClass — профиль, аналог StorageClass; VolumeSnapshot — запрос пользователя на снимок конкретной PVC в пространстве имён; VolumeSnapshotContent — объект кластера, представляющий снимок в системе хранения, аналог PV. Работу выполняют снимковый контроллер и сайдкар external-snapshotter, вызывающий CreateSnapshot драйвера; поэтому снимки доступны только для CSI-драйверов с этой возможностью, а объекты API — пользовательские ресурсы, которые устанавливаются в кластер отдельно.

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: data-pg-0-before-upgrade
  namespace: lab08
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: data-pg-0
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pg-restore
  namespace: lab08
spec:
  storageClassName: fast-ssd
  dataSource:                       # новый том из снимка
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: data-pg-0-before-upgrade
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Восстановление — это создание новой заявки с полем dataSource; так же, указав в dataSource существующую PVC, выполняется клонирование тома.

Снимок тома и резервная копия базы данных — не одно и то же ¹³. Снимок фиксирует блоки диска в некоторый момент, и для работающей СУБД он согласован лишь на уровне аварийного отключения (англ. crash-consistent): после восстановления PostgreSQL выполнит восстановление по журналу предзаписи (WAL), как после внезапного отключения питания. Обычно это работает, но гарантию даёт согласованность на уровне приложения: pg_basebackup и архивирование WAL, позволяющие восстановиться на произвольный момент времени. Кроме того, место хранения снимка зависит от системы: снимки дисков AWS EBS хранятся в отдельной службе, а снимки Ceph RBD — в том же кластере Ceph, и его потеря уносит и том, и снимки. Наконец, ни том, ни снимок не защищают от логической ошибки: DELETE без WHERE успешно реплицируется и сохраняется. Резервная копия — это копия, хранящаяся вне системы, которую она защищает, и проверенная восстановлением; объектное хранилище из темы 10 — типичное место для неё.

Приложения с состоянием: StatefulSet

Идентичность реплик и почему Deployment не подходит

Deployment из темы 7 исходит из того, что реплики взаимозаменяемы: у подов случайные суффиксы имён, при обновлении новые поды создаются раньше, чем удаляются старые, а все реплики используют один и тот же шаблон, в том числе одну и ту же заявку на том. Для базы данных каждое из этих свойств — проблема. Реплики кластера PostgreSQL неравноправны (одна ведущая, остальные — ведомые), им нужны стабильные адреса друг друга и у каждой свой каталог данных.

Даже одиночная база в Deployment требует осторожности. При стратегии RollingUpdate новый под стартует до остановки старого; если оба оказались на одном узле, RWO-том успешно смонтируется в оба, и два процесса PostgreSQL откроют один каталог данных. Поэтому для базы данных в Deployment обязательна стратегия Recreate, а при отказе узла Deployment создаёт замену, не дожидаясь подтверждения, что старый под действительно остановлен. В курсовом проекте PostgreSQL допустимо запускать в Deployment с одной репликой и стратегией Recreate — это простейший вариант, — но различие стоит понимать и обосновывать.

StatefulSet (англ. StatefulSet) — контроллер, который управляет подами из одного шаблона, но закрепляет за каждым устойчивую идентичность: порядковый номер, имя, DNS-имя и собственный том ⁹¹². Поды StatefulSet pg с тремя репликами называются pg-0, pg-1, pg-2; при пересоздании pg-1 новый под получит то же имя, тот же DNS-адрес и тот же том, на каком бы узле он ни оказался. Контроллер гарантирует, что под с данной идентичностью существует не более чем в одном экземпляре: замена создаётся только после того, как старый под удалён из API. Поэтому при отказе узла под StatefulSet остаётся в состоянии Terminating или Unknown, пока узел не вернётся или администратор не убедится, что узел выключен, и не удалит под принудительно. Принудительное удаление без такой проверки разрушает именно ту гарантию, ради которой StatefulSet выбран.

Headless Service и стабильные DNS-имена

Обычный Service из темы 7 даёт виртуальный ClusterIP и балансирует соединения между подами. Для реплик базы данных это неприемлемо: запись должна идти на ведущую реплику, а не на случайную. Headless Service (англ. headless service) — Service с clusterIP: None: у него нет виртуального адреса, а DNS-запрос к его имени возвращает A-записи всех готовых подов ⁹. Для StatefulSet, у которого поле serviceName указывает на такой Service, DNS дополнительно публикует имя каждого пода по шаблону $(имя пода).$(имя Service).$(пространство имён).svc.cluster.local.

apiVersion: v1
kind: Service
metadata:
  name: pg-headless
  namespace: lab08
spec:
  clusterIP: None
  selector:
    app: pg
  ports:
    - name: postgres
      port: 5432

Примерный вывод для StatefulSet из двух реплик (адреса будут другими):

kubectl -n lab08 exec pg-client -- nslookup pg-headless.lab08.svc.cluster.local
kubectl -n lab08 exec pg-client -- nslookup pg-0.pg-headless.lab08.svc.cluster.local

Name:   pg-headless.lab08.svc.cluster.local
Address: 10.244.0.12
Name:   pg-headless.lab08.svc.cluster.local
Address: 10.244.0.14

Name:   pg-0.pg-headless.lab08.svc.cluster.local
Address: 10.244.0.12

IP-адрес пода после пересоздания изменится, а имя pg-0.pg-headless — нет; на это и рассчитана настройка репликации, где ведомый указывает адрес ведущего. Схема на рисунке ниже сводит вместе имена подов, DNS-записи и персональные заявки на тома.

Две оговорки. В DNS попадают только готовые поды, если у Service не задано publishNotReadyAddresses: true, — это важно для баз данных, которым нужно найти друг друга до прохождения проб. И DNS кэширует отрицательные ответы: если имя запрошено до создания пода, клиент может ещё некоторое время получать «не найдено»; документация упоминает кэш CoreDNS в 30 секунд ⁹.

volumeClaimTemplates, порядок запуска и обновления

Поле volumeClaimTemplates — шаблон заявки, по которому контроллер создаёт отдельную PVC для каждого пода с именем <имя шаблона>-<имя пода>: data-pg-0, data-pg-1. Под pg-1 всегда подключает data-pg-1, поэтому после пересоздания на другом узле он получает свои данные, а не данные соседа.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: pg
  namespace: lab08
spec:
  serviceName: pg-headless
  replicas: 2
  podManagementPolicy: OrderedReady
  selector:
    matchLabels:
      app: pg
  template:
    metadata:
      labels:
        app: pg
    spec:
      containers:
        - name: postgres
          image: postgres:17.11-alpine
          args:
            - "-c"
            - "config_file=/etc/postgresql/postgresql.conf"
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

Заявки, созданные по шаблону, не удаляются ни при уменьшении числа реплик, ни при удалении самого StatefulSet ⁹. Это сделано намеренно: данные ценнее автоматической уборки. Если уменьшить StatefulSet с трёх реплик до одной, data-pg-1 и data-pg-2 останутся связанными со своими томами, а при обратном увеличении pg-1 и pg-2 получат прежние данные. Поведение настраивается полем persistentVolumeClaimRetentionPolicy (стабильно с Kubernetes 1.32) с политиками whenDeleted и whenScaled, каждая из которых равна Retain (по умолчанию) или Delete ⁹. Обратная сторона — забытые тома: три реплики по 50 ГиБ, уменьшенные до одной, оставляют 100 ГиБ занятого и оплачиваемого хранилища, которое не видно в списке подов.

Поле podManagementPolicy задаёт порядок создания и удаления. По умолчанию действует OrderedReady: поды создаются по порядку от 0 до N−1, и следующий создаётся только после того, как предыдущий стал Running и Ready; удаляются в обратном порядке ⁹. Это удобно для систем, где первый экземпляр инициализирует кластер, а остальные присоединяются к нему. Политика Parallel создаёт и удаляет все поды одновременно. Цена порядка — время: если PostgreSQL с инициализацией каталога данных становится готовым за 40 с, то StatefulSet из трёх реплик в режиме OrderedReady поднимается примерно за 3 × 40 = 120 с, а в режиме Parallel — примерно за 40 с. Политика касается только масштабирования; обновления подчиняются отдельному полю updateStrategy.

Стратегия обновления RollingUpdate (по умолчанию) пересоздаёт поды по одному в обратном порядке номеров — от N−1 до 0, дожидаясь готовности каждого. Параметр partition ограничивает обновление подами с номером не меньше заданного: при partition: 2 новый шаблон получит только pg-2, что позволяет проверить новую версию на одной реплике (канареечное обновление). Стратегия OnDelete не обновляет поды сама — новый шаблон применяется, когда под удалён вручную, — что используют операторы, управляющие порядком обновления реплик сами.

Наконец, у StatefulSet есть неизменяемые поля: после создания нельзя поменять volumeClaimTemplates, serviceName и selector. Чтобы увеличить том, изменяют каждую PVC отдельно (при allowVolumeExpansion: true в классе), а шаблон остаётся старым; чтобы поменять класс хранения, StatefulSet пересоздают, сохраняя PVC (kubectl delete statefulset pg --cascade=orphan удаляет контроллер, не трогая поды).

Операторы баз данных

StatefulSet даёт идентичность и тома, но ничего не знает о PostgreSQL. Две реплики StatefulSet — это два независимых сервера с двумя независимыми каталогами данных; потоковую репликацию между ними, выбор ведущего, переключение при отказе, резервное копирование и обновление основной версии кто-то должен выполнять. Это работа администратора баз данных, и оператор (англ. operator) автоматизирует её по образцу цикла согласования из темы 7: пользовательский ресурс описывает желаемое состояние кластера баз данных, а контроллер-оператор приводит к нему реальное.

CloudNativePG — оператор PostgreSQL, проект CNCF. Кластер описывается ресурсом Cluster:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: notes-db
spec:
  instances: 3
  storage:
    storageClass: fast-ssd
    size: 20Gi

По этому описанию оператор создаёт ведущий экземпляр и две реплики с потоковой репликацией, Service для записи (notes-db-rw, всегда указывает на ведущий) и для чтения (notes-db-ro), при отказе ведущего повышает одну из реплик и переключает Service, а резервное копирование выполняет в объектное хранилище. Показательно, что CloudNativePG не использует StatefulSet: он управляет подами и PVC напрямую собственным контроллером ¹¹. Документация проекта объясняет это ограничениями StatefulSet, в частности невозможностью изменить размер томов через шаблон и жёстким порядком обновления, в котором неизвестно, какая реплика ведущая. Это хороший пример того, что StatefulSet — универсальный строительный блок, а не готовое решение для конкретной СУБД. Другие операторы PostgreSQL — Zalando Postgres Operator (на основе Patroni), Crunchy PGO, StackGres.

Ограничения и типичные ошибки интерпретации

Ошибки в работе с конфигурацией и секретами

«Изменил ConfigMap — приложение перенастроилось». Это верно только для тома без subPath и только если приложение перечитывает файл. Переменные окружения и subPath не обновляются никогда, а том обновляется с задержкой порядка минуты. Надёжный способ применить конфигурацию — изменить шаблон пода (хэш конфигурации в аннотации) и получить контролируемое поэтапное обновление.

«Смонтировал файл — конфигурация применилась». Файл, о котором приложение не знает, ничего не меняет; PostgreSQL читает postgresql.conf из каталога данных, пока ему не указан -c config_file=.... Обратная ошибка — полная замена конфигурации: файл, переданный через config_file, заменяет весь postgresql.conf, и если в нём нет listen_addresses = '*', сервер будет слушать только localhost, а проба pg_isready изнутри пода при этом продолжит проходить.

«Secret зашифрован». В etcd по умолчанию — нет; в манифесте — тем более нет, base64 обращается без ключа. Secret отличается от ConfigMap доставкой на узел (tmpfs, только нужным узлам) и тем, что на него обычно навешивают более строгие правила RBAC. Без EncryptionConfiguration резервная копия etcd — это открытый файл со всеми паролями кластера. Манифест Secret с data в публичном репозитории — утечка, даже если «там только base64».

«Права на секреты закрыты RBAC». Чтение через API закрыто, но право создавать поды в пространстве имён позволяет прочитать любой его Secret через монтирование. Граница доверия для секретов — пространство имён.

Ошибки в работе с томами

«Удалю PVC, а данные останутся на PV». При политике Delete, которая по умолчанию стоит у динамически созданных томов, удаление заявки удаляет и том с данными. Политику проверяют командой kubectl get pv до, а не после удаления; для ценных данных ставят Retain в классе хранения или заранее меняют её на конкретном PV.

«RWO значит один под». RWO ограничивает узел; два пода на одном узле, например старый и новый при RollingUpdate, оба получат том на запись. Нужна стратегия Recreate, StatefulSet или режим ReadWriteOncePod.

«Том реплицирован, значит есть резервная копия». Репликация в системе хранения защищает от отказа диска, снимок — от неудачного обновления в пределах той же системы, и ни то ни другое не защищает от DROP TABLE, ошибки приложения и потери всей системы хранения. Резервная копия хранится отдельно и проверяется восстановлением.

«PVC в Pending — значит, кончилось место». Причин несколько: нет класса с указанным именем, нет класса по умолчанию, драйвер не установлен или не может создать том, а при WaitForFirstConsumer заявка законно ждёт первого пода. Разбор начинается с kubectl describe pvc, где в событиях указана причина.

«Обновлю образ базы — данные на томе подхватятся». Внутри одной основной версии PostgreSQL это так, между основными — нет: формат файлов данных несовместим, и переход требует pg_upgrade или выгрузки и загрузки. Кроме того, официальный образ PostgreSQL 18 перенёс каталог данных по умолчанию из /var/lib/postgresql/data в /var/lib/postgresql/18/docker, и манифест, монтирующий том по старому пути без явного PGDATA, с новым образом не запустится. Поэтому тег образа базы данных в манифесте фиксируется как минимум до основной версии (postgres:17.11-alpine, а не postgres:alpine).

Отдельная оговорка касается учебной среды. В minikube из одного узла провайдер k8s.io/minikube-hostpath создаёт тома как каталоги /tmp/hostpath-provisioner/<пространство имён>/<имя PVC> внутри узла. Такие тома не ограничивают размер (запрошенные 1 ГиБ — лишь число в объекте), не имеют шагов attach и stage и не могут переехать на другой узел. На одном узле нельзя наблюдать ни ошибку Multi-Attach, ни топологию зон, ни перенос пода с томом между узлами: механизмы те же, но их физическая сторона в учебном стенде вырождена.

Когда базе данных не место в Kubernetes

Kubernetes дал базам данных всё необходимое: устойчивые имена, персональные тома, порядок запуска, операторы. Из этого не следует, что любую базу нужно держать в кластере. Против говорят три обстоятельства. Отказ узла для StatefulSet не обрабатывается автоматически, и без оператора восстановление требует ручной работы администратора, знающего и Kubernetes, и СУБД. Производительность базы определяется системой хранения, и сетевой блочный том с задержкой в доли миллисекунды на операцию ведёт себя иначе, чем локальный NVMe-диск. Наконец, управляемая облачная СУБД снимает с команды резервное копирование, обновления и переключение при отказе, а её цена часто ниже стоимости компетенции, нужной для безопасной эксплуатации собственного кластера.

Разумная практика выглядит так: учебные и тестовые базы, а также базы, для которых есть зрелый оператор и команда, умеющая с ним работать, — в Kubernetes через оператор вроде CloudNativePG; критичные базы рабочей среды без такого опыта — в управляемом сервисе; одиночный StatefulSet без оператора — только там, где потеря данных за период между резервными копиями приемлема.

Итоги темы

Конфигурация отделяется от образа объектами ConfigMap и Secret, и главное, что нужно о них помнить, — семантика обновления. Переменные окружения и subPath фиксируются при создании контейнера, том обновляется kubelet атомарной перестановкой ссылки ..data с задержкой порядка минуты, а применение новой конфигурации зависит ещё и от того, перечитывает ли её приложение и не требует ли параметр перезапуска. Предсказуемое обновление получают изменением шаблона пода, то есть тем же механизмом поэтапного обновления, что и для новой версии образа.

Secret — это не хранилище секретов, а объект с более аккуратной доставкой на узел. Base64 не шифрует, в etcd данные по умолчанию лежат открытыми, а читать секреты может любой, кто может создавать поды в пространстве имён. Шифрование включается EncryptionConfiguration на API-сервере, лучше с провайдером KMS v2; хранение секретов в Git и их ротацию решают Sealed Secrets, SOPS, External Secrets Operator и Vault.

Постоянное хранилище построено на разделении заявки и тома. PVC описывает потребность приложения, PV — конкретный том, StorageClass — профиль, по которому том создаётся динамически. Судьбу данных при удалении заявки определяет политика освобождения, момент создания тома — volumeBindingMode, и в многозонном кластере WaitForFirstConsumer исключает тома, недоступные из зоны пода. Драйвер подключается по стандарту CSI, и путь тома всегда один и тот же: CreateVolume, ControllerPublishVolume, NodeStageVolume, NodePublishVolume, причём первые два выполняют сайдкары контроллерной части, а последние два — kubelet.

StatefulSet даёт каждой реплике устойчивое имя, DNS-адрес через headless Service и персональную PVC, которая не удаляется вместе с подом, а по умолчанию — и вместе с самим StatefulSet. Но он не знает ничего о репликации и резервном копировании конкретной СУБД; эту работу выполняют операторы, такие как CloudNativePG, а снимки томов и резервные копии остаются разными инструментами.

Тема 9 переходит от объектов внутри кластера к описанию самой инфраструктуры кодом: кластеры, сети и диски создаются OpenTofu по тому же декларативному принципу. Тема 10 рассматривает объектное хранилище, куда уходят резервные копии баз данных и вложения «Заметок», а тема 11 — RBAC и политики, которые закрывают доступ к секретам, упомянутый здесь лишь в общих чертах.

Литература

1. Wiggins A. The Twelve-Factor App. — 2011. https://12factor.net/ (дата обращения: 22.10.2026).
2. Kubernetes Documentation. ConfigMaps. — https://kubernetes.io/docs/concepts/configuration/configmap/ (дата обращения: 22.10.2026).
3. Kubernetes Documentation. Secrets. — https://kubernetes.io/docs/concepts/configuration/secret/ (дата обращения: 22.10.2026).
4. Kubernetes Documentation. Encrypting Confidential Data at Rest. — https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ (дата обращения: 22.10.2026).
5. Kubernetes Documentation. Persistent Volumes. — https://kubernetes.io/docs/concepts/storage/persistent-volumes/ (дата обращения: 22.10.2026).
6. Kubernetes Documentation. Storage Classes. — https://kubernetes.io/docs/concepts/storage/storage-classes/ (дата обращения: 22.10.2026).
7. Container Storage Interface (CSI) Specification. Version 1.13.0. — https://github.com/container-storage-interface/spec/blob/master/spec.md (дата обращения: 22.10.2026).
8. Kubernetes CSI Developer Documentation. — https://kubernetes-csi.github.io/docs/ (дата обращения: 22.10.2026).
9. Kubernetes Documentation. StatefulSets. — https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ (дата обращения: 22.10.2026).
10. Kubernetes Documentation. Volume Snapshots. — https://kubernetes.io/docs/concepts/storage/volume-snapshots/ (дата обращения: 22.10.2026).
11. CloudNativePG Documentation. Custom Pod Controller. — https://cloudnative-pg.io/docs/current/controller (дата обращения: 22.10.2026).
12. Luksa M. Kubernetes in Action. — Manning, 2018.
13. Burns B., Beda J., Hightower K., Evenson L. Kubernetes: Up and Running. 3rd ed. — O'Reilly Media, 2022.
14. PostgreSQL 17 Documentation. 19.1. Setting Parameters. — https://www.postgresql.org/docs/17/config-setting.html (дата обращения: 22.10.2026).

Дополнительные материалы

Вопросы для самопроверки

1. Почему конфигурацию и пароли не встраивают в образ контейнера? Какие два требования к механизму конфигурации из этого следуют?
2. Перечислите три способа доставки ConfigMap в контейнер. Какие из них увидят изменение ConfigMap без пересоздания пода и почему?
3. Как kubelet обновляет том configMap так, что приложение никогда не видит наполовину записанный набор файлов?
4. Файл конфигурации в поде обновился, а приложение работает со старыми параметрами. Назовите две возможные причины на примере PostgreSQL.
5. Как добиться, чтобы изменение ConfigMap применялось штатным поэтапным обновлением Deployment? Приведите два способа.
6. Чем Secret отличается от ConfigMap? Почему base64 не является защитой и кто в кластере может прочитать Secret?
7. Как Secret хранится в etcd по умолчанию? Что задаёт EncryptionConfiguration, зачем в ней провайдер identity и почему после включения шифрования секреты перезаписывают?
8. Сравните Sealed Secrets, SOPS и External Secrets Operator: где хранится исходный секрет и как он попадает в кластер?
9. Опишите фазы PV и что происходит с данными при kubectl delete pvc при политиках Delete и Retain. Как вернуть том из Released в оборот?
10. Кластер в трёх зонах, база данных из трёх реплик с правилом «одна реплика на зону», класс хранения с volumeBindingMode: Immediate. Оцените вероятность, что все реплики будут размещены, если зона диска выбирается равновероятно. Что изменит WaitForFirstConsumer?
11. Чем ReadWriteOnce отличается от ReadWriteOncePod? Почему два пода могут одновременно писать в RWO-том?
12. Перечислите по порядку четыре вызова CSI, которые выполняются при запуске пода с облачным блочным диском, и укажите, какой компонент выполняет каждый.
13. Дано: StatefulSet pg из трёх реплик, узел с подом pg-1 перестал отвечать. Что происходит по шагам, почему замена не создаётся сразу и чем опасно принудительное удаление пода?
14. Что останется в кластере после kubectl scale statefulset pg --replicas=1 и после kubectl delete statefulset pg? Каким полем это настраивается?
15. Почему снимок тома не заменяет резервную копию базы данных и почему оператор CloudNativePG не использует StatefulSet?

Глоссарий темы

Шпаргалка по инструментам

Конфигурация и секреты:

# ConfigMap из файла (с --dry-run=client -o yaml — только сгенерировать YAML)
kubectl create configmap pg-config --from-file=postgresql.conf
# изменить один ключ
kubectl patch configmap probe-config --type merge -p '{"data":{"level":"2"}}'
# пересоздать поды после изменения конфигурации
kubectl rollout restart statefulset pg

# Secret без пароля в истории: ввод без эха и передача через канал
read -rs -p 'Пароль: ' PGPASS; echo
printf '%s' "$PGPASS" | kubectl create secret generic pg-auth \
  --from-literal=POSTGRES_USER=notes --from-file=POSTGRES_PASSWORD=/dev/stdin
unset PGPASS
# прочитать значение (доступно каждому, у кого есть get на secrets)
kubectl get secret pg-auth -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d
# проверить, можно ли мне читать секреты
kubectl auth can-i get secrets -n lab08

Тома и заявки:

kubectl get storageclass                       # классы и класс по умолчанию
kubectl get pvc,pv                             # фазы, политика освобождения, связь
kubectl describe pvc data-pg-0                 # события выделения и связывания
kubectl get pv PV -o jsonpath='{.spec.claimRef}'
kubectl patch pv PV -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
kubectl patch pv PV --type merge -p '{"spec":{"claimRef":null}}'   # Released → Available
kubectl get volumeattachments                  # подключение томов к узлам (CSI)
kubectl get csidrivers,csinodes                # установленные CSI-драйверы

StatefulSet:

kubectl scale statefulset pg --replicas=2
kubectl rollout status statefulset pg
kubectl get endpointslices -l kubernetes.io/service-name=pg-headless
kubectl delete statefulset pg --cascade=orphan     # удалить контроллер, оставить поды и PVC

PostgreSQL изнутри пода:

kubectl exec pg-0 -- psql -U notes -d notes -c 'SHOW config_file;' -c 'SHOW max_connections;'
kubectl exec pg-0 -- psql -U notes -d notes -c 'SELECT pg_reload_conf();'
kubectl exec pg-0 -- psql -U notes -d notes \
  -c "SELECT name, setting, pending_restart FROM pg_settings WHERE pending_restart;"

Что почитать и посмотреть

• Kubernetes Documentation. ConfigMaps и Secrets — https://kubernetes.io/docs/concepts/configuration/configmap/ , https://kubernetes.io/docs/concepts/configuration/secret/ . Первоисточник семантики обновления (env, том, subPath) и раздел «Information security for Secrets» о том, кто может читать секреты.
• Kubernetes Documentation. Good practices for Kubernetes Secrets — https://kubernetes.io/docs/concepts/security/secrets-good-practices/ . Короткий практический список мер: шифрование, RBAC, ограничение доступа контейнеров, внешние хранилища.
• Kubernetes Documentation. Encrypting Confidential Data at Rest — https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ . Пошаговое включение EncryptionConfiguration, сравнительная таблица провайдеров и проверка через etcdctl.
• Kubernetes Documentation. Persistent Volumes и Storage Classes — https://kubernetes.io/docs/concepts/storage/persistent-volumes/ , https://kubernetes.io/docs/concepts/storage/storage-classes/ . Полное описание жизненного цикла, режимов доступа, расширения томов и режимов связывания.
• Container Storage Interface Specification — https://github.com/container-storage-interface/spec/blob/master/spec.md . Сама спецификация; стоит прочитать раздел о жизненном цикле тома с диаграммами состояний и описания NodeStageVolume и NodePublishVolume.
• Kubernetes CSI Developer Documentation — https://kubernetes-csi.github.io/docs/ . Как устроен драйвер в Kubernetes: сайдкары, развёртывание, объекты CSIDriver и CSINode; пригодится при диагностике томов, зависших в подключении.
• Kubernetes Documentation. StatefulSets и учебник «StatefulSet Basics» — https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/ , https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/ . Гарантии порядка, стратегии обновления, partition и политика удаления PVC на живом примере.
• Kubernetes Documentation. Force Delete StatefulSet Pods — https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ . Почему StatefulSet не создаёт замену при отказе узла и чем рискует принудительное удаление.
• CloudNativePG Documentation — https://cloudnative-pg.io/docs/current/ . Архитектура оператора PostgreSQL, раздел «Custom Pod Controller» о причинах отказа от StatefulSet, резервное копирование в объектное хранилище.
• PostgreSQL Documentation. Setting Parameters — https://www.postgresql.org/docs/17/config-setting.html . Как сервер читает конфигурацию, что делает pg_reload_conf() и какие параметры требуют перезапуска.
• Luksa M. Kubernetes in Action. — Manning, 2018. Главы о томах, ConfigMap и Secret и о StatefulSet с подробными опытами; изложение старше текущих версий, но механизмы описаны очень наглядно.
• Kleppmann M. Designing Data-Intensive Applications. — O'Reilly Media, 2017. Глава о репликации объясняет, почему две реплики StatefulSet ещё не кластер базы данных и что именно автоматизирует оператор.

Углубление (по желанию)

Почему Secret остался base64, а не стал зашифрованным объектом

Secret появился в первых версиях Kubernetes как способ отделить чувствительные данные от остальной конфигурации, чтобы на них можно было навесить отдельные правила доступа и доставлять их на узлы аккуратнее. Base64 в нём — не попытка защиты, а следствие формата: JSON не умеет хранить произвольные байты, а ключи TLS и файлы .dockerconfigjson двоичные или многострочные. Шифрование на стороне API-сервера добавили позже как отдельный слой, не меняя API, — поэтому для пользователя Secret выглядит одинаково с шифрованием и без него, и отличить одно от другого можно только заглянув в etcd. Отсюда и устойчивое заблуждение «секреты в Kubernetes зашифрованы»: в API их никогда не было видно зашифрованными.

Локальные тома и операторы на них

Сетевые тома удобны тем, что переживают отказ узла: диск подключается к другой ВМ. Но у базы данных есть своя репликация, и для неё два уровня избыточности — реплики СУБД и реплики системы хранения — означают двойную плату за одно и то же и лишнюю сетевую задержку на каждую запись. Поэтому высоконагруженные базы в Kubernetes часто размещают на локальных NVMe-дисках узлов (тома типа local или CSI-драйверы локальных дисков вроде TopoLVM и OpenEBS LocalPV) с WaitForFirstConsumer. Такой том привязан к узлу навсегда: при отказе узла под не может переехать, и восстановлением занимается оператор — он создаёт новую реплику на другом узле и наполняет её из ведущей. Это хороший пример того, как решение о хранилище меняет распределение ответственности между Kubernetes и приложением.

История режима ReadWriteOncePod

Режим ReadWriteOnce с самого начала ограничивал узел, а не под, потому что для облачных блочных дисков ограничение «подключён к одной ВМ» естественно, а дальше том — обычная файловая система узла. Для большинства приложений этого хватало, но не для тех, кому нужна гарантия единственного писателя: при поэтапном обновлении старый и новый под на одном узле получали один том. Режим ReadWriteOncePod появился как альфа-функция в Kubernetes 1.22 и стал стабильным в 1.29; его проверку выполняет планировщик (под с занятым RWOP-томом не размещается) и kubelet. Ограничение «только CSI» объясняется тем, что для проверки понадобились изменения в сайдкарах CSI, а встроенные плагины к тому времени уже переводились на CSI.

Лабораторная работа 8. Конфигурация и постоянное хранилище PostgreSQL в Kubernetes

• Раздел курса: тема 8 «Конфигурация и постоянное хранилище в Kubernetes»

Введение

В лабораторной работе 7 в кластере работал backend приложения «Заметки» — набор взаимозаменяемых подов без состояния. Эта работа переходит к его базе данных: PostgreSQL получает конфигурацию из ConfigMap, учётные данные — из Secret, а данные хранит на постоянном томе, который переживает удаление пода. Каждое из этих утверждений в работе проверяется опытом, а не принимается на веру: применилась ли конфигурация, проверяется запросом к серверу, сохранились ли данные — чтением после пересоздания пода, а судьба тома после удаления заявки — по состоянию объекта PV.

Особое внимание уделено двум местам, где интуиция чаще всего подводит. Первое — обновление конфигурации: один и тот же ключ ConfigMap, доставленный тремя способами, ведёт себя по-разному после изменения, а новый файл ещё не означает новых параметров сервера. Второе — жизненный цикл тома: что именно удаляется вместе с заявкой, почему освобождённый том не подключается к новой заявке сам и что остаётся после уменьшения StatefulSet.

Кластер в работе однонодовый (minikube). Это честное ограничение: перенос пода с томом на другой узел, ошибку Multi-Attach и выбор зоны при WaitForFirstConsumer на одном узле наблюдать нельзя; механизмы, которые за ними стоят, изучаются по теории, а здесь проверяется всё, что воспроизводится на одном узле.

Работа состоит из базовой части (части 1–8) и продвинутой (часть 9).

Цель работы

Научиться передавать конфигурацию и секреты приложению в Kubernetes с предсказуемой семантикой обновления и развёртывать PostgreSQL в StatefulSet с постоянными томами, понимая жизненный цикл PV и PVC.

После выполнения работы можно будет:

• создать Secret так, чтобы пароль не остался в истории оболочки, и объяснить, почему base64 не защищает его;
• предсказать и проверить, какие из трёх способов доставки ConfigMap (env, том, subPath) увидят изменение;
• применить конфигурацию из ConfigMap к PostgreSQL и отличить параметры, применяемые перечитыванием, от требующих перезапуска;
• проследить связывание PVC и PV и объяснить по выводу kubectl get pv, что произойдёт с данными при удалении заявки;
• вернуть освобождённый том (Released) в оборот и подключить его к новой заявке;
• развернуть StatefulSet из двух реплик и показать по DNS и PVC, что у каждой реплики своя идентичность и свой том;
• найти по симптомам (kubectl describe, события, журналы) ошибки в манифесте StatefulSet.

Теоретический минимум

Теория изложена в теме 8: разделы «Конфигурация вне образа: ConfigMap», «Secret: что он защищает и чего не защищает», «Тома и постоянное хранилище: PV, PVC и StorageClass», «Приложения с состоянием: StatefulSet». Ниже — сжатая справка.

Учебный стенд:

minikube, профиль lab08 (один узел, драйвер docker)
└── пространство имён lab08
    ├── ConfigMap probe-config, под cm-probe            (часть 3)
    ├── Secret pg-auth (создаётся вручную)              (часть 2)
    ├── ConfigMap pg-config  → /etc/postgresql/postgresql.conf
    ├── Service pg-headless (clusterIP: None)
    ├── StatefulSet pg (postgres:17.11-alpine)
    │     └── pg-0, pg-1 → PVC data-pg-0, data-pg-1 → PV pvc-…
    ├── под pg-client (psql, nslookup)
    └── PVC scratch, под writer                          (часть 6)

StorageClass standard (по умолчанию): провайдер k8s.io/minikube-hostpath,
reclaimPolicy Delete, volumeBindingMode Immediate;
тома — каталоги /tmp/hostpath-provisioner/<пространство имён>/<PVC> внутри узла

Основные команды:

Параметры PostgreSQL, используемые в работе:

Столбец pending_restart представления pg_settings показывает t для параметров, изменённых в файле, но ожидающих перезапуска.

Перечень оснащения

Архив окружения: lr-env. В нём up.sh и down.sh, каталог manifests/ с манифестами базовой части, broken/ с манифестом для части 8 (не открывайте его до части 8) и advanced/ для части 9.

Ресурсы: 2 ядра и 3 ГБ памяти для узла minikube, около 5 ГБ на диске.

Почему зафиксирована основная версия 17. В образах PostgreSQL 18 изменилось расположение данных: переменная PGDATA по умолчанию указывает на /var/lib/postgresql/18/docker, а объявленный том — на /var/lib/postgresql. Манифест, который полагается на PGDATA по умолчанию и монтирует том в привычный /var/lib/postgresql/data, с образом 18 не запустится: скрипт запуска обнаруживает смонтированный, но неиспользуемый каталог /var/lib/postgresql/data и завершается с ошибкой, предлагая монтировать /var/lib/postgresql. В этой работе PGDATA задан явно, поэтому чистая установка на 18 прошла бы, но том с данными версии 17 сервер 18 не откроет: файлы данных несовместимы между основными версиями, и переход требует pg_upgrade или выгрузки и загрузки. Поэтому тег образа базы данных фиксируется как минимум до основной версии, а лучше — до дополнительной.

Порядок выполнения работы

Стенд поднимается скриптом ./up.sh из каталога архива и удаляется скриптом ./down.sh (вместе со всеми томами). up.sh создаёт профиль minikube lab08, пространство имён lab08 и делает его текущим, поэтому дальше флаг -n lab08 можно опускать. Манифесты применяются по одному, в порядке частей; команду kubectl apply -f manifests/ целиком не используйте: файл 51-scratch-rebind.yaml содержит заполнитель, который нужно заменить.

Базовая часть — части 1–8, продвинутая — часть 9. Прежде чем выполнять команду, которая что-то меняет, запишите предсказание результата, затем сравните с выводом.

Индивидуальный вариант задаёт параметры PostgreSQL и тома. Номер варианта выберите сами.

Часть 1. Стенд и класс хранения по умолчанию

Задание

1. Распакуйте архив и поднимите стенд:

   cd lr-env
   ./up.sh
   

2. Изучите класс хранения по умолчанию:

   kubectl get storageclass
   kubectl get storageclass standard -o yaml
   

   Запишите значения provisioner, reclaimPolicy и volumeBindingMode. Ответьте письменно: что произойдёт с данными тома этого класса при удалении заявки и в какой момент создаётся том.

3. Найдите под провайдера томов: kubectl -n kube-system get pod storage-provisioner. Это не CSI-драйвер, а простой внешний провайдер; отметьте, каких из четырёх вызовов CSI в его работе нет и почему (подсказка: тома — каталоги на единственном узле).

Что должно получиться

NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   k8s.io/minikube-hostpath   Delete          Immediate           false                  1m

Класс standard помечен как класс по умолчанию, политика Delete (удаление заявки удаляет том и каталог с данными), режим Immediate (том создаётся сразу при появлении заявки). У провайдера hostpath нет подключения диска к узлу и подготовки устройства — значит, нет аналогов ControllerPublishVolume и NodeStageVolume; есть только создание каталога (аналог CreateVolume) и монтирование его в под как hostPath. Если под storage-provisioner не в состоянии Running, PVC в следующих частях останутся в Pending: включите аддоны командой minikube -p lab08 addons enable storage-provisioner и default-storageclass.

Часть 2. Secret без следов в истории оболочки

Задание

1. Создайте Secret pg-auth с ключами POSTGRES_USER (значение notes) и POSTGRES_PASSWORD. Пароль вводится с клавиатуры без отображения и передаётся в kubectl через стандартный ввод — в истории и в списке процессов его не будет:

   read -rs -p 'Пароль PostgreSQL: ' PGPASS; echo
   printf '%s' "$PGPASS" | kubectl create secret generic pg-auth \
     --from-literal=POSTGRES_USER=notes \
     --from-file=POSTGRES_PASSWORD=/dev/stdin
   unset PGPASS
   

   printf — встроенная команда оболочки, отдельный процесс для неё не создаётся, а --from-file читает значение из канала. Используйте printf '%s', а не echo и не <<<: оба добавляют перевод строки, и он станет частью пароля.

2. Убедитесь, что пароля нет в истории: в выводе history | tail -5 есть строки с read и --from-file, но нет самого значения.

3. Посмотрите, как секрет выглядит для того, у кого есть право get:

   kubectl describe secret pg-auth
   kubectl get secret pg-auth -o yaml
   kubectl get secret pg-auth -o jsonpath='{.data.POSTGRES_PASSWORD}' | base64 -d; echo
   

4. Для сравнения создайте ненужный секрет «плохим» способом и найдите пароль в истории:

   kubectl create secret generic bad-example --from-literal=password=Qwerty123
   history | tail -3
   kubectl delete secret bad-example
   

   Удалите эту строку из истории (history -d НОМЕР).

Что должно получиться

kubectl describe показывает только имена ключей и размеры (POSTGRES_PASSWORD: N bytes), а -o yaml — значения в base64, которые третья команда превращает обратно в пароль без всякого ключа. Вывод: защита Secret определяется не кодированием, а тем, кто имеет право get или list на секреты и право создавать поды в пространстве имён. Если пароль после декодирования оканчивается переводом строки (команда echo выводит лишнюю пустую строку), секрет создан через echo или <<<; пересоздайте его.

Часть 3. Три способа доставки ConfigMap

Задание

1. Прочитайте манифест manifests/11-cm-probe.yaml: один ключ level ConfigMap probe-config доставлен в переменную LEVEL, в каталог /cfg-dir и через subPath в файл /cfg-sub/level. Процесс каждые 5 секунд печатает все три значения.

2. Примените манифесты и смотрите журнал в отдельном терминале:

   kubectl apply -f manifests/10-probe-config.yaml -f manifests/11-cm-probe.yaml
   kubectl wait --for=condition=Ready pod/cm-probe --timeout=120s
   kubectl logs -f cm-probe
   

3. Запишите предсказание: какие из трёх значений изменятся после смены level на 2 и через какое время. Затем засеките время и измените ConfigMap:

   date +%T; kubectl patch configmap probe-config --type merge -p '{"data":{"level":"2"}}'
   

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

   kubectl exec cm-probe -- ls -la /cfg-dir
   kubectl exec cm-probe -- cat /proc/1/environ | tr '\0' '\n' | grep LEVEL
   

5. Пересоздайте под и проверьте, что теперь все три способа показывают 2:

   kubectl delete pod cm-probe
   kubectl apply -f manifests/11-cm-probe.yaml
   

Что должно получиться

Журнал после изменения ConfigMap (время условное):

10:15:05 env=1 volume=1 subPath=1
10:15:10 env=1 volume=1 subPath=1
...
10:15:55 env=1 volume=2 subPath=1

Меняется только значение из каталога, с задержкой от нескольких секунд до примерно минуты (период синхронизации kubelet). Переменная окружения и subPath остаются 1 до пересоздания пода. В каталоге /cfg-dir видны скрытый каталог с меткой времени, ссылка ..data на него и ссылка level -> ..data/level; после изменения метка времени новая. Окружение процесса (/proc/1/environ) по-прежнему содержит LEVEL=1. Если volume не изменился и через две минуты, проверьте, что изменение действительно попало в ConfigMap: kubectl get configmap probe-config -o yaml.

Часть 4. PostgreSQL в StatefulSet с конфигурацией из ConfigMap

Задание

1. Прочитайте манифесты 20-pg-config.yaml, 30-pg-headless.yaml и 31-pg-statefulset.yaml. Найдите и объясните письменно:

   • как файл из ConfigMap становится конфигурацией сервера (поле args и то, что образ подставляет postgres перед аргументом, начинающимся с -);
   • почему ConfigMap смонтирован каталогом /etc/postgresql, а не через subPath;
   • зачем PGDATA указывает на подкаталог pgdata смонтированного тома.

2. Подставьте значения своего варианта: max_connections в 20-pg-config.yaml и размер тома storage в 31-pg-statefulset.yaml. Примените манифесты и наблюдайте за созданием заявки и пода:

   kubectl apply -f manifests/20-pg-config.yaml -f manifests/30-pg-headless.yaml
   kubectl apply -f manifests/31-pg-statefulset.yaml
   kubectl get pvc,pv
   kubectl get pods -l app=pg -w
   

3. Проверьте, что сервер работает с конфигурацией из ConfigMap, а не с postgresql.conf из каталога данных:

   kubectl exec pg-0 -- psql -U notes -d notes -c 'SHOW config_file;' -c 'SHOW max_connections;' -c 'SHOW work_mem;'
   

4. Измените в ConfigMap work_mem на значение варианта (команда kubectl edit configmap pg-config или правка файла и kubectl apply). Дождитесь, пока новое значение появится в файле внутри пода (повторяйте команду):

   kubectl exec pg-0 -- grep work_mem /etc/postgresql/postgresql.conf
   

   Предскажите, что покажет SHOW work_mem; до и после SELECT pg_reload_conf();, и проверьте.

5. Теперь измените max_connections на значение «после изменения» из варианта, дождитесь обновления файла и снова выполните pg_reload_conf(). Проверьте:

   kubectl exec pg-0 -- psql -U notes -d notes -c 'SELECT pg_reload_conf();' \
     -c "SELECT name, setting, pending_restart FROM pg_settings WHERE name IN ('max_connections','work_mem');"
   kubectl logs pg-0 --tail=5
   

6. Примените новое значение перезапуском пода и убедитесь, что оно действует: kubectl delete pod pg-0, дождаться готовности, SHOW max_connections;.

Что должно получиться

После создания StatefulSet заявка data-pg-0 сразу переходит в Bound (режим Immediate), появляется PV с именем вида pvc-<UID> и политикой Delete, под pg-0 через несколько секунд становится 1/1 Running. Запрос показывает:

           config_file
---------------------------------
 /etc/postgresql/postgresql.conf

 max_connections
-----------------
 40

(значение — из вашего варианта). Если config_file указывает на /var/lib/postgresql/data/pgdata/postgresql.conf, сервер запущен без args, и ConfigMap ни на что не влияет — это та ошибка, ради которой задание и проверяет SHOW, а не наличие файла.

work_mem после обновления файла остаётся старым, пока не выполнен pg_reload_conf(), после него — новый. С max_connections иначе: после перечитывания setting остаётся старым, pending_restart равен t, а в журнале сервера появляется сообщение вида parameter "max_connections" cannot be changed without restarting the server. После пересоздания пода значение новое. Итог части: путь «ConfigMap → файл в поде» занимает до минуты, а путь «файл → действующий параметр» зависит от приложения и параметра.

Часть 5. Данные переживают под

Задание

1. Создайте таблицу заметок и добавьте число записей из варианта:

   kubectl exec -i pg-0 -- psql -U notes -d notes <<'SQL'
   CREATE TABLE notes (id serial PRIMARY KEY, title text NOT NULL, created_at timestamptz DEFAULT now());
   INSERT INTO notes (title) SELECT 'заметка ' || g FROM generate_series(1, 3) AS g;
   SELECT count(*) FROM notes;
   SQL
   

   (замените 3 на число из варианта).

2. Запишите IP-адрес пода и UID пода (kubectl get pod pg-0 -o wide, kubectl get pod pg-0 -o jsonpath='{.metadata.uid}'), имя PV (kubectl get pvc data-pg-0). Предскажите, что из этого изменится после удаления пода.

3. Удалите под и наблюдайте за пересозданием:

   kubectl delete pod pg-0
   kubectl get pods -l app=pg -w
   

4. Проверьте данные, IP-адрес, UID и имя PV. Найдите каталог тома на узле:

   kubectl exec pg-0 -- psql -U notes -d notes -c 'SELECT count(*) FROM notes;'
   minikube -p lab08 ssh -- sudo ls /tmp/hostpath-provisioner/lab08/data-pg-0/pgdata
   

Что должно получиться

Под создан заново с тем же именем pg-0, но с новым UID и, как правило, новым IP-адресом; заявка data-pg-0 и PV — прежние, число записей совпадает с вариантом. В журнале нового пода нет строк инициализации (initdb), зато есть строка PostgreSQL Database directory appears to contain a database; Skipping initialization: скрипт запуска нашёл PG_VERSION в PGDATA и пропустил создание базы — пароль и имя пользователя из Secret при этом уже не применяются, они были использованы один раз при инициализации. На узле в каталоге тома лежат файлы PostgreSQL (base, global, pg_wal, PG_VERSION). На одном узле под возвращается туда же, где был; в многоузловом кластере с сетевыми томами тот же опыт показал бы переподключение тома к другому узлу, но здесь его наблюдать нельзя.

Часть 6. Жизненный цикл PV: Released и возвращение в оборот

Задание

1. Создайте отдельную заявку и под, который пишет в том метку времени:

   kubectl apply -f manifests/50-scratch.yaml
   kubectl logs writer
   PV=$(kubectl get pvc scratch -o jsonpath='{.spec.volumeName}'); echo "$PV"
   kubectl get pv "$PV"
   

2. Измените политику освобождения этого тома на Retain:

   kubectl patch pv "$PV" -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
   

3. Предскажите, что произойдёт при удалении заявки, пока под writer работает. Выполните без ожидания и посмотрите на состояние:

   kubectl delete pvc scratch --wait=false
   kubectl get pvc scratch
   kubectl get pvc scratch -o jsonpath='{.metadata.finalizers}'; echo
   

4. Удалите под и проверьте состояние тома и данных на узле:

   kubectl delete pod writer
   kubectl get pv "$PV"
   minikube -p lab08 ssh -- sudo cat /tmp/hostpath-provisioner/lab08/scratch/stamp
   

5. Попробуйте подключить этот том к новой заявке. В manifests/51-scratch-rebind.yaml замените PV_NAME на имя тома и примените:

   sed "s/PV_NAME/$PV/" manifests/51-scratch-rebind.yaml | kubectl apply -f -
   kubectl get pvc scratch2
   kubectl describe pvc scratch2 | tail -5
   

6. Освободите том вручную, удалив ссылку на старую заявку, и проверьте, что заявка связалась, а под reader прочитал старую метку:

   kubectl get pv "$PV" -o jsonpath='{.spec.claimRef}'; echo
   kubectl patch pv "$PV" --type merge -p '{"spec":{"claimRef":null}}'
   kubectl get pv "$PV" -w
   kubectl logs reader
   

Что должно получиться

После шага 2 в столбце RECLAIM POLICY тома — Retain. На шаге 3 заявка не исчезает, а находится в Terminating с финализатором kubernetes.io/pvc-protection: её использует под. После удаления пода заявка удаляется, а том переходит в фазу Released, в столбце CLAIM остаётся lab08/scratch; файл stamp на узле на месте.

Заявка scratch2 остаётся в Pending, хотя явно указывает на том: в claimRef тома записан UID удалённой заявки scratch, и контроллер не отдаёт его другой. После удаления claimRef том кратко проходит Available и связывается со scratch2 (Bound), а reader печатает метку времени, записанную в шаге 1. Если бы политика осталась Delete, на шаге 4 исчезли бы и PV, и каталог; это поведение наблюдается в части 9 на заявке data-pg-1.

Особенность провайдера minikube: каталог тома определяется пространством имён и именем заявки. Если пересоздать заявку с прежним именем scratch, провайдер создаст новый PV, указывающий на тот же каталог, и старые данные «найдутся» — это свойство учебного провайдера, а не Kubernetes; облачный провайдер создал бы новый пустой диск.

Часть 7. StatefulSet из двух реплик

Задание

1. Примените клиентский под. Предскажите порядок появления подов при увеличении StatefulSet до двух реплик и запустите наблюдение:

   kubectl apply -f manifests/40-pg-client.yaml
   kubectl scale statefulset pg --replicas=2
   kubectl get pods -l app=pg -w
   

2. Проверьте заявки и DNS-имена:

   kubectl get pvc
   kubectl exec pg-client -- nslookup pg-headless.lab08.svc.cluster.local
   kubectl exec pg-client -- nslookup pg-1.pg-headless.lab08.svc.cluster.local
   kubectl get endpointslices -l kubernetes.io/service-name=pg-headless
   

3. Обратитесь к каждой реплике по её имени. Пароль клиент получает из Secret через переменные окружения пода:

   kubectl exec pg-client -- psql -h pg-0.pg-headless -c 'SELECT count(*) FROM notes;'
   kubectl exec pg-client -- psql -h pg-1.pg-headless -c 'SELECT count(*) FROM notes;'
   

   Объясните результат второй команды.

4. Создайте на pg-1 метку: kubectl exec pg-1 -- psql -U notes -d notes -c "CREATE TABLE marker AS SELECT 'pg-1' AS who;". Уменьшите StatefulSet до одной реплики и проверьте заявки. Затем снова увеличьте до двух и проверьте метку:

   kubectl scale statefulset pg --replicas=1
   kubectl get pods,pvc
   kubectl scale statefulset pg --replicas=2
   kubectl rollout status statefulset pg
   kubectl exec pg-1 -- psql -U notes -d notes -c 'SELECT * FROM marker;'
   

Что должно получиться

pg-1 создаётся только после того, как pg-0 стал Ready (политика OrderedReady), и получает собственную заявку data-pg-1 со своим PV. DNS-имя pg-headless возвращает два адреса, pg-0.pg-headless… и pg-1.pg-headless… — по одному; у Service нет ClusterIP.

Вторая команда шага 3 завершается ошибкой relation "notes" does not exist: pg-1 — отдельный сервер PostgreSQL с собственным пустым каталогом данных, инициализированным при первом запуске. StatefulSet не реплицирует данные — он даёт идентичность и тома; репликацию настраивает СУБД или оператор. После уменьшения до одной реплики под pg-1 удалён, а заявка data-pg-1 осталась в Bound; после увеличения pg-1 получает ту же заявку, и таблица marker на месте.

Часть 8. Сломать и починить: StatefulSet, который не запускается

Задание

В файле broken/pgx-broken.yaml описан ещё один экземпляр PostgreSQL (pgx) с тремя ошибками. Не читайте манифест заранее: найдите ошибки по симптомам, как в эксплуатации.

1. Примените манифест и наблюдайте:

   kubectl apply -f broken/pgx-broken.yaml
   kubectl get pods,pvc -l app=pgx
   kubectl get pvc data-pgx-0
   

2. Для каждого симптома запишите: состояние пода или заявки, команду, которая показала причину (kubectl describe pod, kubectl describe pvc, kubectl get events --sort-by=.lastTimestamp, kubectl logs), причину и исправление. Ошибки проявляются по очереди: следующая видна только после исправления предыдущей.

3. Исправьте манифест и добейтесь, чтобы pgx-0 стал 1/1 Running, а SHOW max_connections; на нём вернул значение из pgx-config. Учтите, что часть полей StatefulSet после создания изменить нельзя: если kubectl apply отвечает ошибкой Forbidden: updates to statefulset spec for fields other than ..., удалите StatefulSet и заявку и создайте заново.

Что должно получиться

Ожидаемая цепочка симптомов:

Первую ошибку нельзя исправить правкой StatefulSet: volumeClaimTemplates неизменяемо, а созданная заявка с неверным классом останется висеть. Нужно kubectl delete statefulset pgx, kubectl delete pvc data-pgx-0 и повторный apply. Вторая и третья исправляются правкой и повторным apply (для третьей можно переименовать ключ ConfigMap или указать items с path: postgresql.conf). Но после третьей ошибки заявку тоже придётся пересоздать: при первом запуске скрипт образа успел выполнить initdb, а на следующем шаге, настройке pg_hba.conf, упал из-за отсутствующего файла конфигурации. Каталог данных остался инициализированным наполовину, и при следующих запусках скрипт считает базу существующей и инициализацию пропускает — правило доступа по сети в pg_hba.conf так и не появится. Это хороший пример того, почему ошибка при первом запуске базы данных оставляет след в томе, а не только в поде. После исправлений SHOW max_connections; на pgx-0 возвращает 30. В конце удалите pgx вместе с заявкой.

Часть 9. Продвинутая: отложенное связывание, удаление PVC при масштабировании, секрет в etcd

Задание

1. Отложенное связывание. Создайте класс lab-wffc и заявку на него, убедитесь, что тома нет, затем создайте потребителя:

   kubectl apply -f advanced/60-sc-wffc.yaml -f advanced/61-wffc-claim.yaml
   kubectl get pvc late
   kubectl describe pvc late | tail -3
   kubectl apply -f advanced/62-wffc-consumer.yaml
   kubectl get pvc late -o jsonpath='{.metadata.annotations}'; echo
   kubectl get pv
   

   Объясните, какую проблему многозонного кластера решает этот режим и почему на одном узле её не видно.

2. Политика удаления PVC у StatefulSet. Включите удаление заявок при уменьшении числа реплик, уменьшите StatefulSet до одной реплики и проверьте заявки и тома:

   kubectl patch statefulset pg --type merge --patch-file advanced/63-pvc-retention.yaml
   kubectl scale statefulset pg --replicas=1
   kubectl get pvc,pv
   

3. Секрет в etcd. Прочитайте, как Secret pg-auth хранится в etcd кластера minikube, где шифрование не включено (пути к сертификатам — стандартные для minikube; если команда не находит файлы, посмотрите их в kubectl -n kube-system get pod etcd-lab08 -o yaml):

   kubectl -n kube-system exec etcd-lab08 -- etcdctl \
     --endpoints=https://127.0.0.1:2379 \
     --cacert=/var/lib/minikube/certs/etcd/ca.crt \
     --cert=/var/lib/minikube/certs/etcd/server.crt \
     --key=/var/lib/minikube/certs/etcd/server.key \
     get /registry/secrets/lab08/pg-auth | strings
   

Что должно получиться

Заявка late остаётся в Pending с событием о том, что она ждёт первого потребителя (waiting for first consumer to be created before binding); PV не создан. После создания пода у заявки появляется аннотация volume.kubernetes.io/selected-node: lab08, создаётся PV, заявка переходит в Bound. В многозонном кластере эта последовательность гарантирует, что диск создаётся в зоне узла, выбранного планировщиком; на одном узле выбирать нечего, и разница видна только во времени создания тома. Если заявка не переходит в Bound и после создания пода, провайдер minikube не поддерживает отложенное связывание в вашей версии — зафиксируйте события kubectl describe pvc late и объясните, какой компонент должен был отреагировать на аннотацию.

После уменьшения StatefulSet с политикой whenScaled: Delete заявка data-pg-1 удаляется, а за ней — PV (политика Delete класса standard) и каталог на узле: метка marker из части 7 потеряна безвозвратно.

В выводе etcd видны путь ключа, имя секрета, имена ключей POSTGRES_USER, POSTGRES_PASSWORD и сам пароль открытым текстом. Префикса k8s:enc: нет — шифрование в etcd не включено. Сравните с примером из раздела теории о EncryptionConfiguration.

По завершении работы удалите стенд: ./down.sh.

Журнал работы

Ведите журнал для себя: для каждого опыта записывайте предсказание, команду, фактический вывод и объяснение расхождения. Особенно ценны записи, где предсказание не совпало с результатом: задержка обновления тома в части 3, pending_restart в части 4, Pending заявки scratch2 в части 6, пустая база на pg-1 в части 7. Для части 8 сохраните таблицу «симптом — команда — причина — исправление»: она пригодится при отладке курсового проекта.

Контрольные вопросы

1. Почему после изменения ConfigMap значение из каталога тома обновилось, а значение через subPath — нет, хотя оба взяты из одного и того же тома? Опишите механизм на уровне ссылок ..data и bind-монтирования.
2. В части 4 новый postgresql.conf появился в поде, но SHOW work_mem показал старое значение. Какие два независимых условия нужны, чтобы изменение конфигурации вступило в силу?
3. Какой приём позволяет применять изменения ConfigMap через штатное поэтапное обновление Deployment или StatefulSet, и чем он лучше ручного kubectl delete pod?
4. Пароль в Secret закодирован в base64. Перечислите, кто в кластере может его прочитать, и что из этого закрывает включение EncryptionConfiguration, а что — нет.
5. Почему заявка scratch2 в части 6 не связалась с томом в фазе Released, хотя явно указывала на него через volumeName? Что сделал бы администратор с данными этого тома в рабочей среде?
6. Почему удаление заявки scratch на шаге 3 части 6 не завершилось сразу? Какую ошибку предотвращает этот механизм?
7. Чем отличается фаза Released тома от фазы Available? Можно ли по выводу kubectl get pv до удаления заявки предсказать, что станет с данными?
8. Почему вторая реплика StatefulSet в части 7 не содержит таблицы notes? Что нужно добавить, чтобы получить настоящую реплику PostgreSQL?
9. В курсовом проекте PostgreSQL можно развернуть в Deployment с одной репликой. Какие свойства StatefulSet при этом теряются и почему для такого Deployment обязательна стратегия Recreate?
10. Что произошло бы с подом pg-1 при отказе его узла в многоузловом кластере, и почему контроллер StatefulSet не создаёт замену немедленно?
11. Какие из четырёх вызовов CSI выполнялись бы при запуске pg-0, если бы том был облачным диском, и в каком порядке? Почему на стенде minikube этих шагов нет?
12. Почему тег образа базы данных фиксируется как минимум до основной версии? Что сломалось бы в этой работе при замене образа на postgres:18-alpine?