CRD — объект apiextensions.k8s.io, по которому kube-apiserver без единой строчки кода начинает обслуживать новый тип ресурса: хранить его в etcd, проверять по схеме и CEL-правилам, отдавать watch, kubectl get и RBAC. Поведение добавляет контроллер: informer кеширует объекты, очередь схлопывает события в ключи, а Reconcile каждый раз заново приводит мир к желаемому состоянию и записывает status. Оператор — такой контроллер со знаниями администратора конкретной системы: CloudNativePG сам делает failover, обновление и бэкапы PostgreSQL.

Helm упаковывает приложение в чарт — каталог с Chart.yaml, values.yaml и шаблонами Go text/template, — рендерит их с параметрами из values.yaml, -f и --set и отправляет результат в API как релиз. Состояние релиза лежит в самом кластере: по Secret sh.helm.release.v1.<релиз>.v<ревизия> на каждую ревизию, с чартом, значениями и манифестом, поэтому helm rollback работает без исходного чарта. Helm 4 применяет новые релизы через server-side apply, ждёт готовности по kstatus и откатывает неудачу флагом --rollback-on-failure.

Kustomize не шаблонизирует текст, а накладывает изменения на обычные валидные манифесты: в каталоге base лежат общие объекты, в overlay каждого окружения — только отличия вроде namespace, images и патчей strategic merge или JSON 6902. Он встроен в kubectl: kubectl kustomize печатает результат, kubectl apply -k его применяет, а кластер о Kustomize ничего не знает. Генераторы ConfigMap и Secret добавляют к имени хэш содержимого и правят ссылки на него, поэтому смена конфигурации сама запускает rolling update.

Объект из домена связывается с облачным жёстко — по якорю immutableId, равному Base64 от mS-DS-ConsistencyGuid или objectGUID, — или мягко, по основному адресу в proxyAddresses или по UPN; не совпало — облако создаёт второй объект, а совпадающий адрес или UPN уходит в карантин. Защищённым учётным записям с adminCount = 1 синхронизация не может записать якорь и пароль, а права через AdminSDHolder с наследованием «только для дочерних» на них самих не действуют. Перенос пользователя в OU вне области синхронизации удаляет его облачную учётную запись вместе с почтой и OneDrive.

Entra Connect на сервере домена забирает из Active Directory пользователей, группы и их атрибуты и создаёт в Entra ID синхронизированные копии, которые редактируются только в домене; дельта-цикл идёт раз в 30 минут. Объекты связывает якорь sourceAnchor — Base64 от mS-DS-ConsistencyGuid (по умолчанию) или objectGUID, в облаке это immutableId. Рекомендуемый способ входа — синхронизация хешей паролей каждые две минуты, а учётная запись MSOL_… с правами репликации делает сервер синхронизации сервером уровня 0.

Это локальные диски узлов (local-path-provisioner, том local, TopoLVM), бакеты S3, смонтированные через FUSE драйвером вроде k8s-csi-s3, и распределённые хранилища Longhorn, Ceph и OpenEBS с репликацией между узлами. Локальный том самый быстрый, но привязывает под к узлу через nodeAffinity, а local-path к тому же не ограничивает размер; S3 не даёт POSIX-семантики — ни атомарного rename, ни блокировок между узлами, а новые файлы другой узел видит с задержкой; распределённое хранилище переживает отказ узла ценой сети и сложности эксплуатации. Базы данных держат на локальных дисках с репликацией средствами самой СУБД под управлением оператора, бэкапы — в S3.

Драйвер ставится манифестами выпуска в kube-system, пароль служебной учётной записи — в Secret в отдельном неймспейсе, а StorageClass с provisioner: smb.csi.k8s.io задаёт шару, этот Secret и опции монтирования — vers=3, seal, nobrl, nolease, hard. Модуль ядра cifs монтирует шару один раз на узел и PV и ходит к серверу одной сессией от одной учётной записи, а владельца и режим файлов эмулирует из опций, поэтому 0777 и noperm — антипример; fsGroup пода драйвер превращает в gid. Новые опции и новый пароль действуют только при новом монтировании: тома перемонтируют по одному узлу через cordon, а не rollout restart.

Ставим csi-driver-nfs v4.13.6 манифестами проекта: контроллер в hostNetwork на каждый PVC монтирует экспорт с опциями класса и создаёт в нём подкаталог от root, а node-плагин по команде kubelet монтирует подкаталог в каталог пода без шага attach. В StorageClass задаём subDir с ${pv.metadata.name} для уникальности, reclaimPolicy: Retain, onDelete: archive и одинаковые для всего сервера mountOptions (nfsvers=4.2, hard, nconnect=4): клиент NFS у узла один на все тома, и опции соединения задаёт первое монтирование. Права даёт fsGroup пода с fsGroupChangePolicy: OnRootMismatch при no_root_squash и manage-gids=n на сервере, а шифрование xprtsec=tls требует tlshd на каждом узле и Secret с опциями для удаления томов.

На Ubuntu Server с отдельным XFS-диском оставляем только NFSv4.1 и 4.2, маскируем rpcbind и rpc.statd, выключаем manage-gids, без чего не работает fsGroup, и отдаём /srv/nfs/k8s поимённо трём узлам с rw,sync,secure,no_root_squash,mp, а ufw пускает к порту 2049 только их. no_root_squash нужен csi-driver-nfs, но при sec=sys сервер верит удостоверению из запроса, поды выходят через NAT с адресом узла, а containerd 2 разрешает им порты ниже 1024 — ни адрес, ни secure подов не отсекают. Это делает GlobalNetworkPolicy Calico в отдельном tier с defaultAction: Pass: подам к серверу нельзя, а тома монтирует kubelet из сети узла.

TGT, полученный при входе, обменивается у KDC на билет к SPN службы, а служба проверяет его своим ключом из keytab — пароль больше не нужен. Приложения добираются до Kerberos через GSSAPI и SPNEGO, поэтому так работают SSH (gssapi-with-mic), веб по Negotiate, PostgreSQL и NFS. Службе нужны SPN в каталоге и ключ в доступном ей keytab; TGT на сервер попадает только при делегировании, а клиент Windows делегирует его лишь серверам, доверенным для делегирования.