View source for Безопасность (RBAC, SA) и хранилища данных (Volumes)

=== 1. Повторение: Аутентификация и Контексты ===
Для подключения к API-серверу извне (вне кластера) необходима аутентификация.

* '''Механизм:''' Используются сертификаты (CA, CRT) и файлы конфигурации (<code>kubeconfig</code>).
* '''Контексты (Contexts):''' Это связка '''User + Cluster + Namespace'''. В одном <code>kubeconfig</code> может быть много контекстов для разных кластеров (Dev, Prod, QA).
* '''Совет по работе с кластерами:''' Чтобы не запутаться, в каком кластере вы находитесь (особенно если у мастеров одинаковые hostname), рекомендуется создавать разных пользователей в ОС (например, <code>user-prod</code>, <code>user-dev</code>) и класть соответствующие конфиги в их домашние папки.

=== 2. Service Account (SA) и доступ внутри кластера ===
Если обычные User/Group нужны для людей (внешний доступ), то '''Service Account''' нужен для приложений (подов) внутри кластера.

* '''Зачем это нужно?''' Многим инструментам (Vault, Prometheus, Provisioners) нужно "смотреть" на кластер изнутри: листить поды, читать секреты или конфигмапы.
* '''Токены:''' В новых версиях Kubernetes токены для SA больше не создаются автоматически. Их нужно создавать вручную как объект типа <code>Secret</code> с аннотацией <code>kubernetes.io/service-account.name</code>.
* '''Пример использования:'''
*# Создаем '''Service Account'''.
*# Создаем '''Role''' (например, разрешение на <code>get</code>, <code>list</code> подов).
*# Создаем '''RoleBinding''', привязывая Role к SA.
*# В манифесте пода указываем <code>serviceAccountName: <имя_са></code>.
* '''Как это работает технически:''' Kubernetes монтирует токен и сертификат внутрь пода по пути <code>/var/run/secrets/kubernetes.io/serviceaccount</code>. Приложение (или команда <code>curl</code>) использует этот токен для запросов к API-серверу.

=== 3. Хранилища данных (Volumes): Начало ===
В Kubernetes поды эфемерны: если под удалится, данные внутри него пропадут. Для сохранения данных используются вольюмы.

==== A. emptyDir (Общая папка между контейнерами) ====

* '''Суть:''' Временная папка, которая создается при запуске пода и удаляется при его удалении.
* '''Кейс:''' Обмен данными между основным контейнером и '''Sidecar-контейнером'''.
* '''Пример с логами:''' Основной контейнер пишет логи в файл, а Sidecar-контейнер (например, Fluentd) читает их из этой же папки <code>emptyDir</code> и отправляет в центральное хранилище.

==== B. hostPath (Монтирование из ноды) ====

* '''Суть:''' Монтирует папку напрямую с физической (или виртуальной) ноды, на которой запущен под.
* '''Проблема:''' Если под переедет на другую ноду, он не увидит данных со старой ноды.
* '''Кейс:''' Системные поды, которым нужен доступ к ресурсам хоста (например, доступ к <code>/var/log</code> ноды через DaemonSet).

=== 4. Persistent Volumes (PV) и Claims (PVC) ===
Это профессиональный способ работы с дисками, разделяющий обязанности администратора и разработчика.

* '''PVC (Persistent Volume Claim):''' "Запрос" разработчика. В нем указывается: "Мне нужно 500 МБ места и доступ ReadWriteOnce".
* '''PV (Persistent Volume):''' "Ресурс" администратора. Реальный диск (NFS, AWS EBS, Ceph), который "отвечает" на запрос.
* '''Связывание (Binding):''' Kubernetes ищет подходящий PV для PVC. Если PVC просит 500 МБ, а есть PV на 1 ГБ и 10 ГБ, он выберет ближайший (1 ГБ).

==== Режимы доступа (Access Modes): ====

# '''ReadWriteOnce (RWO):''' Монтируется только к одной ноде (типично для блочных дисков типа AWS EBS).
# '''ReadOnlyMany (ROX):''' Многие ноды могут читать.
# '''ReadWriteMany (RWX):''' Многие ноды могут и читать, и писать (типично для сетевых файловых систем, например, '''NFS''').

=== 5. Практические нюансы: NFS и монтирование ===

* '''Зависимости:''' Чтобы под мог использовать NFS-хранилище, на '''каждой воркер-ноде''' должен быть установлен пакет <code>nfs-common</code> (для Ubuntu/Debian) или аналогичный. Без него <code>kubelet</code> не сможет выполнить команду <code>mount</code>.
* '''Storage Class (SC):''' Чтобы не создавать PV вручную (Static Provisioning), используется '''Dynamic Provisioning'''. Мы создаем Storage Class, и когда появляется PVC, система сама идет в хранилище (например, в облако или Ceph), создает там диск и делает PV автоматически.

=== Термины урока для запоминания: ===

* '''Sidecar Container:''' Дополнительный контейнер в поде для вспомогательных задач (сбор логов, прокси).
* '''DaemonSet:''' Гарантирует, что на каждой ноде (или выбранных) запущен ровно один экземпляр пода (идеально для агентов логов).
* '''Reclaim Policy:''' Что делать с данными на PV после удаления PVC (<code>Retain</code> — оставить, <code>Delete</code> — удалить).