Справочник по Kubernetes

СПРАВОЧНИК

Назначение

CLI, конфигурация и типовые сценарии Kubernetes (DevOps, CI/CD, инфраструктура). Учебный курс: раздел.

Краткое пояснение

Шпаргалка по Kubernetes: таблицы синтаксиса, API, команд и параметров — для быстрого поиска фактов. Полная официальная структура разделов (концепции, настройка, API, kubectl, сеть, хранилище, безопасность, задачи) — в навигаторе документации Kubernetes и на kubernetes.io/ru.

Официальная документация (kubernetes.io)

Тема	Ссылка	Примечание
Что такое Kubernetes	overview/what-is-kubernetes	RU
Компоненты	overview/components	control plane + node
API Kubernetes	overview/kubernetes-api	версии, группы, OpenAPI
Объекты	working-with-objects	metadata, spec, labels
Справочник API	reference/kubernetes-api	все kind и поля
kubectl	reference/kubectl	EN, полный CLI
Настройка / инструменты	setup, tasks/tools	Minikube, kubeadm
Сертификаты вручную	administer-cluster/certificates	EN
Pod и контейнеры	concepts/workloads/pods	probes, resources
Сеть	services-networking	Service, Ingress
Хранилище	concepts/storage	PV, PVC, StorageClass
ConfigMap / Secret	configuration	EN
RBAC / Security	concepts/security	EN
Policies	concepts/policy	Quota, PSA
Планирование	scheduling-eviction	RU
Расширения / Windows	extend-kubernetes, windows	CRD, Windows nodes
Tasks	docs/tasks	пошаговые сценарии

Интерактивный каталог с фильтрами: навигатор. Учебная глава: Docker Swarm и Kubernetes.

Быстрый старт

minikube start
kubectl apply -f deploy.yaml
kubectl get pods
kubectl logs <pod>
kubectl port-forward svc/app 8080:80

Разбор:

minikube start поднимает локальный одноднодовый кластер в VM или контейнере.
Устанавливает kubectl context minikube для последующих команд.
kubectl apply -f deploy.yaml создаёт/обновляет объекты из манифеста.
kubectl get pods — статус Pod'ов в namespace по умолчанию.
kubectl logs <pod> — stdout/stderr контейнера.
kubectl port-forward svc/app 8080:80 — доступ к Service с локальной машины.

Справочные таблицы

Содержание справочника

Официальная документация (kubernetes.io)
Общая архитектура Kubernetes
Основные понятия Kubernetes
Структура объекта Kubernetes
Core API Resources
Workload Controllers
Конфигурация и секреты
Сетевые ресурсы
Хранилище
Безопасность
Мониторинг и логирование
Расширяемость
Инструменты
kubectl — шпаргалка команд
CI/CD и GitOps
Сетевые модели и CNI-плагины
Мультикластерное управление
Отладка и диагностика
Резервное копирование: Velero
Производительность и масштабируемость

Общая архитектура Kubernetes

Kubernetes — это распределённая система оркестрации контейнеров, обеспечивающая автоматизацию развёртывания, масштабирования и управления приложениями в контейнерах.

Компоненты Control Plane (управляющей плоскости)

Control Plane управляет состоянием кластера и принимает решения о его работе.

kube-apiserver
Центральный компонент, предоставляющий REST API для взаимодействия с кластером. Все операции чтения и записи проходят через него. Поддерживает аутентификацию, авторизацию и валидацию запросов.
etcd
Распределённое хранилище ключ-значение, используемое для хранения всего состояния кластера. Является единственным источником правды для Kubernetes.
kube-scheduler
Отвечает за назначение Pod’ов на подходящие Node’ы на основе доступных ресурсов, политик размещения, толерантности к taint’ам и других ограничений.
kube-controller-manager
Запускает контроллеры, которые наблюдают за состоянием кластера и стремятся привести его к желаемому. Включает:
- Node Controller
- ReplicaSet
- Endpoints Controller
- Service Account & Token Controllers
cloud-controller-manager (опционально)
Изолирует облачно-зависимую логику от основного control plane. Управляет взаимодействием с облачными провайдерами (например, AWS, GCP, Azure).

Компоненты Data Plane (рабочей плоскости)

Data Plane состоит из узлов (Node), на которых выполняются рабочие нагрузки.

kubelet
Агент, работающий на каждом Node. Отвечает за запуск Pod’ов, мониторинг их состояния и взаимодействие с container runtime.
kube-proxy
Сетевой прокси, управляющий сетевыми правилами на Node для обеспечения сетевой связи с Service’ами внутри и вне кластера. Поддерживает режимы:
- iptables
- IPVS
- userspace (устаревший)
Container Runtime
Программное обеспечение, отвечающее за выполнение контейнеров. Поддерживаемые runtimes:
- containerd
- CRI-O
- Docker Engine (через dockershim до версии 1.20, далее не поддерживается напрямую)

Основные понятия Kubernetes

Кластер (Cluster)

Набор машин (физических или виртуальных), объединённых в единую систему управления контейнерами. Состоит из Control Plane и одного или нескольких Node.

Node (Узел)

Рабочая машина в кластере. Может быть физическим сервером или виртуальной машиной. Выполняет Pod’ы.

Pod

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

Сеть (один IP-адрес)
Хранилище (Volumes)
Спецификацию жизненного цикла

Pod’ы создаются и управляются контроллерами (например, Deployment, StatefulSet).

Жизненный цикл Pod (краткая схема)

Развёрнутое объяснение с примерами диагностики — в главе Docker Swarm и Kubernetes. Здесь — справочная цепочка этапов.

Этап	Компонент	Действие
1	kube-apiserver + etcd	Приём объекта Pod, хранение spec/status
2	kube-scheduler	Выбор Node по ресурсам и политикам
3	kubelet + CRI	Pod Sandbox, pull образов, тома, CNI, старт контейнеров
4	kubelet	Мониторинг, restartPolicy, probes
5	kubelet + CNI	SIGTERM → grace period → SIGKILL → удаление контейнеров и сети

Фазы (status.phase): Pending, Running, Succeeded, Failed, Unknown.

При удалении: metadata.deletionTimestamp → Terminating → terminationGracePeriodSeconds → освобождение CPU/RAM, IP, локальных томов.

Полезные поля и команды:

Что смотреть	Где
Фаза и READY	`kubectl get pod <name>`
Scheduling, pull, probes	`kubectl describe pod <name>` → Events
Логи до рестарта	`kubectl logs <name> --previous`
Grace period	`spec.terminationGracePeriodSeconds` в манифесте

Namespace

Механизм изоляции ресурсов внутри одного кластера. Позволяет разделить кластер на логические зоны (например, dev, staging, prod).

Системные Namespace:

default — используется по умолчанию
kube-system — системные компоненты
kube-public — общедоступные ресурсы
kube-node-lease — информация о состоянии Node

Label и Selector

Label — пары ключ-значение, прикрепляемые к объектам (Pod, Service и др.) для организации и выбора подмножеств.
Selector — выражение, используемое для фильтрации объектов по Label’ам.

Пример Label:

labels:
  app: nginx
  environment: production
  tier: frontend

Разбор:

labels в metadata — пары ключ-значение для селекторов и политик.
app: nginx — типичный селектор для Service и Deployment.
environment: production — разделение сред в одном кластере.
tier: frontend — слой архитектуры для NetworkPolicy и маршрутизации.

Типы Selector’ов:

Equality-based: environment = production
Set-based: environment in (production, staging)

Annotation

Произвольные метаданные, не используемые Kubernetes напрямую, но полезные для инструментов, библиотек или пользователей. Например, информация о билде, контактные данные команды, политики.

Структура объекта Kubernetes

Каждый объект Kubernetes описывается в YAML или JSON. В манифесте вы задаёте apiVersion, kind, metadata и (для большинства типов) spec. Поле status заполняет API-сервер — его не указывают в kubectl apply.

kubectl apply

Разбор:

Базовая команда применения манифеста (YAML/JSON) к API-серверу.
Создаёт объект при отсутствии или патчит при совпадении name+kind+namespace.
Полный путь: kubectl apply -f file.yaml или каталог -f ./manifests/.
См. пояснение в тексте раздела выше или ниже.

apiVersion: <строка>
kind: <строка>
metadata:
  name: <строка>
  namespace: <строка>   # опционально; иначе default
  labels: <карта>
  annotations: <карта>
spec: <желаемое состояние>
# status: <фактическое состояние> — только в ответе API, не в apply

Разбор:

apiVersion — группа и версия API (v1, apps/v1, networking.k8s.io/v1).
kind — тип ресурса (Pod, Deployment, Service).
metadata — имя, namespace, labels, annotations.
spec — желаемое состояние (задаёт пользователь в манифесте).
Поле status заполняет control plane — в apply не указывают.
apiVersion — указывает версию API, необходимую для создания объекта. Примеры:
- v1 — для Pod, Service, Namespace
- apps/v1 — для Deployment, StatefulSet, DaemonSet
- batch/v1 — для Job, CronJob
- networking.k8s.io/v1 — для Ingress
kind — тип объекта. Примеры — Pod, Service, Deployment, ConfigMap.
metadata.name — уникальное имя объекта в пределах Namespace.
metadata.namespace — пространство имён, в котором создаётся объект.

В манифестах поле всегда называется metadata: (не meta), ключи ConfigMap/Secret — data: (не переводить на кириллицу). Системный namespace — kube-system.

spec — желаемое состояние объекта. Определяется пользователем.
status — текущее состояние объекта. Обновляется системой автоматически.

Core API Resources

Pod

Структура spec

Код ITЗагрузка примера кода…

Разбор:

spec.containers — список контейнеров в Pod (минимум один).
image, command, args — образ и переопределение entrypoint/CMD.
ports.containerPort — порт контейнера (для Service и probes).
env / valueFrom — переменные из литерала, ConfigMap или Secret.
resources.requests/limits — планирование и лимиты CPU/RAM.
volumeMounts + volumes — монтирование ConfigMap, Secret, PVC, emptyDir.
livenessProbe / readinessProbe / startupProbe — проверки здоровья.
restartPolicy, nodeSelector, tolerations, affinity — планирование Pod.

Важные параметры контейнера

image: URI образа (например, nginx:1.25, registry.example.com/app:v1)
command и args: переопределяют ENTRYPOINT и CMD из Dockerfile
ports: информационное поле; не публикует порты наружу
resources.requests/limits:
- CPU: значения в миллиядрах (100m = 0.1 ядра) или ядрах (2)
- Memory: в байтах с суффиксами (64Mi, 1Gi)
livenessProbe: проверяет, жив ли контейнер. При провале — перезапуск.
readinessProbe: проверяет, готов ли контейнер принимать трафик. При провале — исключение из Service.
startupProbe: отключает liveness/readiness до успешного завершения. Полезен для медленно стартующих приложений.

Типы Volume

emptyDir: временный том, существует пока Pod жив
hostPath: монтирует файл/директорию с Node (опасно, только для одиночных нод)
configMap, secret: монтирует данные как файлы или переменные окружения
persistentVolumeClaim: запрос на постоянное хранилище

Service

Абстракция, определяющая логический набор Pod’ов и политику доступа к ним.

Типы Service

ClusterIP (по умолчанию): внутренний IP, доступен только внутри кластера
NodePort: открывает статический порт на всех Node, перенаправляет на ClusterIP
LoadBalancer: создаёт внешний балансировщик (в облаке)
ExternalName: возвращает CNAME записи вместо IP (редко используется)

Структура spec

spec:
  type: ClusterIP|NodePort|LoadBalancer|ExternalName
  selector:
    app: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
      nodePort: 30007 # только для NodePort/LoadBalancer
  clusterIP: <авто или задано>
  externalIPs: [<IP>, ...]
  sessionAffinity: None|ClientIP

Разбор:

type — ClusterIP, NodePort, LoadBalancer, ExternalName.
selector — Label Pod'ов, на которые направляется трафик Service.
port — порт Service внутри кластера; targetPort — порт контейнера.
nodePort — статический порт на Node (30000–32767) для NodePort/LB.
sessionAffinity: ClientIP — привязка сессии к одному backend Pod.
selector — выбирает Pod’ы по Label’ам
port — порт Service’а
targetPort — порт контейнера (может быть числом или именем порта из Pod spec)
nodePort — диапазон по умолчанию: 30000–32767

Объекты Endpoints / EndpointSlice связывают Service с IP и портами подходящих Pod’ов (обновляются автоматически).

Namespace

Простой объект:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    team: backend
  annotations:
    owner: "devops@example.com"

Разбор:

apiVersion: v1, kind: Namespace — объект изоляции ресурсов.
metadata.name — имя namespace (my-namespace).
labels / annotations — квоты, PSA, владелец команды.
См. пояснение в тексте раздела выше или ниже.

Используется для изоляции ресурсов, квот и политик.

Node

Объект, представляющий физическую или виртуальную машину.

Код ITЗагрузка примера кода…

Разбор:

spec.podCIDR — подсеть Pod'ов на этом Node (зависит от CNI).
taints — "метки отталкивания"; Pod без toleration не планируется.
effect: NoSchedule — запрет новых Pod без matching toleration.
status.capacity / allocatable — ресурсы Node для scheduler.
conditions[type=Ready] — готовность Node принимать Pod'ы.
taints — помечает Node, чтобы на него не назначались Pod’ы без соответствующих tolerations
unschedulable — запрещает планировщику назначать новые Pod’ы на этот Node

Workload Controllers

Контроллеры управляют жизненным циклом Pod’ов, обеспечивая соответствие текущего состояния желаемому.

Deployment

Используется для управления бессостоятельными приложениями. Обеспечивает декларативные обновления, откаты и масштабирование.

Структура spec

Код ITЗагрузка примера кода…

Разбор:

replicas — желаемое число Pod'ов ReplicaSet.
selector.matchLabels — должен совпадать с labels в template.
strategy.type: RollingUpdate — постепенная замена Pod'ов.
maxUnavailable / maxSurge — допуск недоступности и "лишних" Pod при rollout.
template.spec — шаблон Pod (образ, probes, resources).

Параметры стратегии обновления

RollingUpdate (по умолчанию): постепенно заменяет старые Pod’ы новыми.
- maxUnavailable: максимальное количество Pod’ов, которые могут быть недоступны во время обновления. Значение по умолчанию — 25%.
- maxSurge: максимальное количество Pod’ов сверх желаемого числа. Значение по умолчанию — 25%.
Recreate: сначала удаляет все старые Pod’ы, затем создаёт новые. Приводит к downtime.

Полезные команды

kubectl rollout status deployment/<name>   # прогресс обновления
kubectl rollout history deployment/<name>  # история ревизий
kubectl rollout undo deployment/<name>     # откат к предыдущей версии

Разбор:

rollout status — ждёт завершения обновления Deployment.
rollout history — список ревизий ReplicaSet (для отката).
rollout undo — откат к предыдущей ревизии образа/манифеста.
См. пояснение в тексте раздела выше или ниже.

StatefulSet

Используется для приложений с состоянием, таких как базы данных, кэши, распределённые системы.

Обеспечивает:

Уникальные, стабильные имена Pod’ов (web-0, web-1, ...)
Упорядоченный запуск и завершение
Постоянное хранилище, привязанное к каждому Pod’у

Структура spec

Код ITЗагрузка примера кода…

Разбор:

serviceName — Headless Service для стабильного DNS (pod-0.service).
volumeClaimTemplates — отдельный PVC на каждый Pod (data-web-0).
podManagementPolicy: OrderedReady — строгий порядок создания/удаления.
updateStrategy — rolling или OnDelete для StatefulSet.

Особенности

serviceName должен ссылаться на Headless Service (clusterIP: None)
volumeClaimTemplates автоматически создаёт PersistentVolumeClaim для каждого Pod’а
podManagementPolicy:
- OrderedReady (по умолчанию): строгий порядок запуска/удаления
- Parallel: все Pod’ы управляются одновременно

DaemonSet

Запускает по одному Pod’у на каждом подходящем Node. Используется для системных агентов — log collectors, monitoring agents, network plugins.

Структура spec

Код ITЗагрузка примера кода…

Разбор:

selector — на каких Node запускать Pod DaemonSet (по labels Node).
template — Pod на каждом подходящем Node (логи, CNI, мониторинг).
updateStrategy.maxUnavailable — сколько Pod можно обновлять одновременно.
Поле replicas отсутствует — число Pod = число подходящих Node.

DaemonSet игнорирует replicas. Число Pod’ов равно числу подходящих Node’ов.

Job

Выполняет однократную задачу до успешного завершения. Подходит для миграций, обработки данных, пакетных заданий (ETL, bulk load, checkpoint).

Структура spec

spec:
  parallelism: <целое> # сколько Pod’ов запускать одновременно
  completions: <целое> # сколько успешных завершений требуется
  backoffLimit: <целое> # максимум попыток после неудачи
  activeDeadlineSeconds: <целое> # максимальное время выполнения
  ttlSecondsAfterFinished: <целое> # через сколько удалять завершённый Job
  template: # шаблон Pod
    spec:
      restartPolicy: OnFailure|Never # Always запрещён
      containers: [...]

Разбор:

parallelism — одновременно работающих Pod Job.
completions — сколько успешных завершений нужно для успеха Job.
backoffLimit — повторы после падения Pod.
activeDeadlineSeconds — жёсткий таймаут всего Job.
restartPolicy: OnFailure|Never — в Job нельзя Always.
Если completions не указано, Job завершается после первого успешного Pod’а.
restartPolicy не может быть Always.

CronJob

Запускает Job по расписанию в формате cron.

Структура spec

spec:
  schedule: "0 */6 * * *" # каждые 6 часов
  timeZone: "Europe/Moscow" # опционально, начиная с v1.29
  startingDeadlineSeconds: <целое> # макс. задержка запуска
  concurrencyPolicy: Allow|Forbid|Replace
  suspend: true|false
  successfulJobsHistoryLimit: <целое> # сколько успешных Job хранить
  failedJobsHistoryLimit: <целое> # сколько неудачных Job хранить
  jobTemplate:
    spec:
      template:
        spec:
          containers: [...]

Разбор:

schedule — cron-выражение запуска Job (0 */6 * * *).
timeZone — часовой пояс (Kubernetes 1.29+).
concurrencyPolicy — Allow / Forbid / Replace параллельных Job.
jobTemplate.spec — шаблон Pod для каждого запуска CronJob.
successfulJobsHistoryLimit — сколько успешных Job хранить в истории.
concurrencyPolicy:
- Allow (по умолчанию): разрешает параллельные запуски
- Forbid: пропускает новый запуск, если предыдущий ещё работает
- Replace: завершает текущий Job и запускает новый

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

ConfigMap

Хранит нечувствительные конфигурационные данные в виде пар ключ-значение.

Способы использования

Как переменные окружения:

   envFrom:
     - configMapRef:
         name: app-config

Разбор:

envFrom.configMapRef — все ключи ConfigMap как переменные окружения.
Имена ключей ConfigMap становятся именами env (с учётом допустимых символов).
Удобно для набора настроек без перечисления каждого env.name.
См. пояснение в тексте раздела выше или ниже.

Как отдельные переменные:

   env:
     - name: DB_HOST
       valueFrom:
         configMapKeyRef:
           name: app-config
           key: database.host

Разбор:

valueFrom.configMapKeyRef — одно значение по ключу из ConfigMap.
name — ConfigMap; key — поле в data (например database.host).
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

Как Volume (файлы в директории):

   volumes:
     - name: config-volume
       configMap:
         name: app-config

Разбор:

volumes.configMap — монтирование ключей как файлов в каталог.
Имя volume связывается с volumeMounts в контейнере.
Обновление ConfigMap обновляет файлы в Pod (с задержкой kubelet).
См. пояснение в тексте раздела выше или ниже.

Структура объекта

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database.host: "postgres"
  log.level: "info"
binaryData:
  cert.pem: <base64>

Разбор:

kind: ConfigMap, data — текстовые пары ключ-значение (UTF-8).
binaryData — бинарные файлы в base64.
Не храните секреты в ConfigMap — для них объект Secret.
См. пояснение в тексте раздела выше или ниже.
data — текстовые значения (UTF-8)
binaryData — двоичные данные в base64

Secret

Хранит чувствительные данные: пароли, токены API, TLS-ключи, учётные данные registry. Официальная страница: Secret. Практика "приложение + БД": лабораторный пример.

Base64 — не шифрование. Поле data кодирует значения в base64 для хранения в etcd; любой с правом get secret в namespace прочитает их в открытом виде (kubectl get secret -o yaml). Для шифрования в etcd — EncryptionConfiguration; для секретов в Git — вне Git и GitOps.

`data` и `stringData`

Поле	Когда использовать
`data`	Значения уже в base64 (как в API после создания)
`stringData`	Пишете открытым текстом в манифесте — apiserver кодирует в `data` при сохранении

В одном Secret нельзя дублировать один ключ в data и stringData. Лимит объекта — 1 MiB (сумма ключей).

Структура (Opaque)

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
  namespace: default
type: Opaque
stringData:
  username: app
  password: change-me-in-prod
immutable: false

Разбор:

type: Opaque — произвольные пары ключ–значение (тип по умолчанию).
stringData — удобно в учебных YAML; в проде предпочитают kubectl create или операторы, без паролей в Git.
immutable: true — запрет изменений после создания (защита от случайной перезаписи; для смены пароля создают новый Secret и обновляют Pod).

Создание через kubectl

kubectl create secret generic db-secret \
  --from-literal=username=app \
  --from-literal=password='s3cr3t'

kubectl create secret generic app-certs \
  --from-file=tls.crt=./certs/tls.crt \
  --from-file=tls.key=./certs/tls.key

kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=user \
  --docker-password='token' \
  --docker-email=user@example.com

Разбор:

generic — тип Opaque; --from-literal, --from-file, --from-env-file.
docker-registry — тип kubernetes.io/dockerconfigjson для imagePullSecrets.
Просмотр ключей без вывода значений: kubectl get secret db-secret -o jsonpath='{.data}' (значения остаются base64).

Типы Secret

`type`	Назначение	Ожидаемые ключи
`Opaque`	Пароли, токены, произвольные данные	любые
`kubernetes.io/tls`	TLS для Ingress / приложений	`tls.crt`, `tls.key`; опционально `ca.crt`
`kubernetes.io/dockerconfigjson`	Pull из приватного registry	`.dockerconfigjson`
`kubernetes.io/basic-auth`	HTTP basic	`username`, `password`
`kubernetes.io/ssh-auth`	SSH-ключ	`ssh-privatekey`, опционально `ssh-publickey`
`bootstrap.kubernetes.io/token`	Токены присоединения узлов (kubeadm)	по схеме bootstrap
`kubernetes.io/service-account-token`	Устаревший авто-Secret SA (до 1.24)	токен в Secret

Токены ServiceAccount с Kubernetes 1.24+ по умолчанию не создают отдельный Secret; Pod получает projected volume с JWT (см. ServiceAccount).

Способы использования в Pod

Одна переменная (secretKeyRef):

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password
        optional: false

Все ключи как env (envFrom):

envFrom:
  - secretRef:
      name: db-secret

Имена ключей Secret должны быть допустимыми именами переменных окружения (буквы, цифры, _).

Том (файлы) — предпочтительно для паролей и сертификатов: значения не попадают в spec.containers.env и не видны в kubectl describe pod так же явно, как env:

volumeMounts:
  - name: db-creds
    mountPath: /etc/db-creds
    readOnly: true
volumes:
  - name: db-creds
    secret:
      secretName: db-secret
      defaultMode: 0400
      items:
        - key: password
          path: password

Разбор:

Смонтированный Secret — tmpfs в памяти узла; при удалении Pod том исчезает.
defaultMode — права файлов (octal), по умолчанию 0644.
items — выборочные ключи и имена файлов в каталоге.

Pull образов — в spec Pod или ServiceAccount:

spec:
  imagePullSecrets:
    - name: regcred

Projected volume — несколько источников в одном mount (Secret + ConfigMap + downwardAPI):

volumes:
  - name: all-in-one
    projected:
      sources:
        - secret:
            name: db-secret
            items:
              - key: password
                path: db-password
        - configMap:
            name: app-config

Пример TLS Secret

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <base64>
  tls.key: <base64>

Разбор:

type: kubernetes.io/tls — стандартный TLS Secret.
tls.crt / tls.key — сертификат и ключ в base64 в data.
Используется в Ingress tls.secretName и монтировании в Pod.
Автовыпуск: cert-manager (CRD Certificate → Secret).

Шифрование Secret в etcd

По умолчанию etcd хранит объекты Secret без прикладного шифрования. Администратор кластера настраивает EncryptionConfiguration (KMS или локальный ключ) для ресурса secrets:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-32-byte-key>
      - identity: {}

Разбор:

Первый provider в списке — шифрование при записи; identity — чтение старых незашифрованных записей при миграции.
Управляемые облака (EKS, GKE, AKS) часто включают encryption at rest отдельной настройкой.
Это не заменяет запрет хранения паролей в Git и RBAC на secrets.

Секреты вне Git и GitOps

Подход	Суть
`kubectl create secret` / CI pipeline	Секрет создаётся при деплое, в репозитории только ссылка по имени
External Secrets Operator	Синхронизация из Vault, AWS SM, GCP SM в native `Secret` — см. ИБ, Vault и ESO
Sealed Secrets	В Git лежит зашифрованный `SealedSecret`; контроллер создаёт `Secret` только в своём кластере
SOPS	Зашифрованные файлы в Git; расшифровка в CI или при `kustomize`/Helm
HashiCorp Vault	Приложение или sidecar читает секрет напрямую, без объекта `Secret`

Ответ на типовой экзаменационный вопрос "без пароля в манифесте" — в Deployment только secretKeyRef / volume на имя Secret, сам Secret — из оператора, CI или kubectl, не из открытого YAML в Git.

RBAC и риски

Доступ к Secret — ресурс secrets, глаголы get, list, watch, create, update, patch, delete.
Роль с get pods + get secrets позволяет читать все секреты namespace.
Переменные из secretKeyRef отображаются в API Pod (ограниченно в describe; полный YAML Pod с env — риск утечки в логи CI).
Не кладите секреты в ConfigMap, annotations, labels, образы (ENV в Dockerfile) — см. безопасность контейнеров.

Отладка

Симптом	Проверка
`CreateContainerConfigError`	`kubectl get secret`, имя и ключ в `secretKeyRef`
`secret "x" not found`	namespace, имя, RBAC
Ingress без TLS	`kubectl get secret tls-secret`, ключи `tls.crt` / `tls.key`
ImagePullBackOff на приватном registry	`imagePullSecrets`, тип `dockerconfigjson`

kubectl get secret db-secret -o yaml
kubectl describe pod <pod> | grep -A2 Secret

Сетевые ресурсы

Ingress

Управляет входящим HTTP/HTTPS-трафиком на уровне кластера. Требует установленного Ingress Controller (NGINX, Traefik, HAProxy).

Структура spec

Код ITЗагрузка примера кода…

Разбор:

ingressClassName — выбор Ingress Controller (nginx, traefik).
tls.hosts + secretName — HTTPS для указанных host.
rules.host — виртуальный хост HTTP-маршрутизации.
path / pathType: Prefix — префикс URL; backend.service — целевой Service.

Типы путей (pathType)

Exact — точное совпадение
Prefix — префиксное совпадение
ImplementationSpecific — зависит от контроллера

Аннотации (часто используются)

nginx.ingress.kubernetes.io/rewrite-target
traefik.ingress.kubernetes.io/router.entrypoints: websecure

NetworkPolicy

Определяет правила сетевого трафика между Pod’ами. Требует CNI с поддержкой политик (Calico, Cilium, kube-router).

Пример — разрешить вход только из frontend

Код ITЗагрузка примера кода…

Разбор:

podSelector — к каким Pod применяется политика (labels backend).
policyTypes — Ingress и/или Egress (без типа правило не активно).
ingress.from.podSelector — трафик только от Pod с app: frontend.
egress.to.namespaceSelector — исходящий трафик в namespace monitoring.
Без NetworkPolicy в namespace трафик разрешён по умолчанию (зависит от CNI).
Без NetworkPolicy весь трафик разрешён.
policyTypes явно указывает, применяются ли правила к входящему, исходящему или обоим типам трафика.

Хранилище

PersistentVolume (PV)

Ресурс кластера, представляющий физическую или облачную единицу хранения.

Типы провайдеров

hostPath — локальная директория (только для одиночных нод)
nfs, iscsi, cephfs — сетевые файловые системы
awsElasticBlockStore, gcePersistentDisk, azureDisk — облачные диски
CSI-драйверы — универсальный интерфейс для любых хранилищ

Структура PV

spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
    - ReadOnlyMany
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain|Recycle|Delete
  storageClassName: fast-ssd
  hostPath:
    path: /mnt/data

Разбор:

capacity.storage — размер тома на уровне кластера.
accessModes — RWO, ROX, RWX (совместимость с PVC).
persistentVolumeReclaimPolicy: Retain|Delete — судьба данных после удаления PVC.
storageClassName — класс для динамического связывания с PVC.

Access Modes

ReadWriteOnce (RWO) — один Node, чтение и запись
ReadOnlyMany (ROX) — много Node, только чтение
ReadWriteMany (RWX) — много Node, чтение и запись

Reclaim Policy

Retain — сохраняет данные после удаления PVC
Delete — удаляет PV и физическое хранилище
Recycle — устаревший, не рекомендуется

PersistentVolumeClaim (PVC)

Запрос на использование PV от имени Pod’а.

spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: fast-ssd
  volumeName: <имя PV> # прямая привязка (опционально)
  dataSource: # для клонирования или восстановления из снапшота
    name: backup-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

Разбор:

resources.requests.storage — запрашиваемый объём у provisioner.
accessModes — должны поддерживаться выбранным StorageClass/PV.
volumeName — явная привязка к существующему PV (static provisioning).
dataSource — клон или восстановление из VolumeSnapshot.

PVC автоматически связывается с подходящим PV при динамическом provision’инге.

StorageClass

Определяет классы хранилища для динамического создания PV.

provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer|Immediate

Разбор:

provisioner — CSI или in-tree драйвер (создание PV).
parameters — параметры облака (type: gp3 для EBS).
allowVolumeExpansion: true — разрешение kubectl patch увеличения PVC.
volumeBindingMode: WaitForFirstConsumer — PV создаётся при назначении Pod на зону.
provisioner — драйвер, создающий тома
allowVolumeExpansion — разрешает увеличение размера PVC после создания
volumeBindingMode:
- Immediate — PV создаётся сразу при создании PVC
- WaitForFirstConsumer — PV создаётся только когда Pod, использующий PVC, будет назначен на Node (полезно для зональных томов)

Безопасность

Role-Based Access Control (RBAC)

Kubernetes использует RBAC для управления доступом к API на основе ролей.

Основные объекты

Role — определяет права в пределах одного Namespace.
ClusterRole — определяет права на уровне всего кластера.
RoleBinding — связывает пользователя или группу с Role в Namespace.
ClusterRoleBinding — связывает пользователя или группу с ClusterRole глобально.

Структура Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Разбор:

rules — список разрешений — apiGroups, resources, verbs.
resources: ["pods"] — объект Pod в core API (apiGroups: [""]).
verbs — ["get", "list", "watch"] — только чтение без create/delete.
Role действует в одном namespace (metadata.namespace).

Допустимые глаголы (verbs)

get, list, watch — чтение
create, update, patch, delete, deletecollection — запись
impersonate — подмена пользователя
bind, escalate — специфичные для RBAC

Пример RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
  - kind: User
    name: alice
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Разбор:

subjects — кому выданы права (User, Group, ServiceAccount).
roleRef — ссылка на Role pod-reader в том же namespace.
Имя User alice должно совпадать с аутентификацией (OIDC, cert).
См. пояснение в тексте раздела выше или ниже.

subjects может ссылаться на:

User
Group
ServiceAccount

ServiceAccount

Специальный тип аккаунта для процессов внутри Pod’ов.

Каждый Pod по умолчанию использует default ServiceAccount в своём Namespace.
Для доступа к API в Pod монтируется projected volume с ограниченным по времени токеном (путь вида /var/run/secrets/kubernetes.io/serviceaccount/). В старых кластерах использовался долгоживущий Secret-токен — в новых версиях предпочтителен bound token.

Создание ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: prod

Разбор:

kind: ServiceAccount — идентичность для процессов в Pod.
Токен для API монтируется projected volume (bound service account token).
По умолчанию Pod использует SA default в своём namespace.
См. пояснение в тексте раздела выше или ниже.

Привязка к Pod:

spec:
  serviceAccountName: app-sa
  containers: [...]

Разбор:

serviceAccountName: app-sa — Pod работает от имени этого SA.
Токен API монтируется в /var/run/secrets/kubernetes.io/serviceaccount/.
RBAC RoleBinding на SA даёт права приложению к API Kubernetes.
Без явного указания используется SA default в namespace Pod.

SecurityContext

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

Уровень Pod

spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seccompProfile:
      type: RuntimeDefault

Разбор:

runAsUser / runAsGroup — UID/GID процессов в Pod (все контейнеры по умолчанию).
fsGroup — GID для томов с volumePermission.
seccompProfile.type: RuntimeDefault — профиль seccomp узла.
См. пояснение в тексте раздела выше или ниже.

Уровень контейнера

containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]

Разбор:

allowPrivilegeEscalation: false — запрет эскалации привилегий.
readOnlyRootFilesystem: true — корень ФС только для чтения.
capabilities.drop: ["ALL"] — сброс Linux capabilities.
capabilities.add: ["NET_BIND_SERVICE"] — разрешение слушать порт <1024 без root.

Ключевые поля

runAsUser — UID, от которого запускается процесс
runAsNonRoot — требует, чтобы контейнер не запускался от root
readOnlyRootFilesystem — делает корневую ФС только для чтения
capabilities.add/drop — управление Linux capabilities
seccompProfile.type — RuntimeDefault, Localhost, Unconfined

PodSecurity Admission (PSA)

Механизм, заменивший PodSecurityPolicy (устаревший с v1.25).

Работает через метки Namespace:

pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/warn: restricted
pod-security.kubernetes.io/audit: privileged

Уровни безопасности

Privileged — без ограничений
Baseline — минимальные ограничения, совместимо с большинством приложений
Restricted — строгие требования (например, запрет root, обязательные capabilities drop)

Пример меток:

apiVersion: v1
kind: Namespace
metadata:
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest

Разбор:

Метки PSA на Namespace задают уровень Pod Security Admission.
enforce: restricted — отклонение Pod, не проходящих строгий профиль.
enforce-version: latest — версия политики PSA.
См. пояснение в тексте раздела выше или ниже.

Мониторинг и логирование

Metrics Server

Лёгкий компонент, собирающий метрики CPU и памяти с Node и Pod’ов. Требуется для kubectl top и Horizontal Pod Autoscaler.

Устанавливается как Deployment в kube-system.

Prometheus

Система мониторинга с pull-моделью. Использует ServiceMonitor и PodMonitor (через Prometheus Operator) для обнаружения целей. Учебный стенд — Практикум Prometheus и Grafana; мониторинг VM и bare metal — Практикум Zabbix; справочник — Справочник по Prometheus.

Пример ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
    - port: metrics
      interval: 30s

Разбор:

CRD Prometheus Operator: ServiceMonitor для scrape метрик.
selector.matchLabels — Service с меткой app: my-app.
endpoints.port: metrics — имя порта в Service, не номер.
interval: 30s — период опроса Prometheus.

Loki

Система агрегации логов от Grafana Labs. Хранит логи без полнотекстового индекса, используя метки (labels) для фильтрации. Практикум — Loki и Tempo, шаг 7; справочник — Справочник по Loki.

Интегрируется с Promtail — агентом, отправляющим логи из Pod’ов.

Расширяемость

CustomResourceDefinition (CRD)

Позволяет создавать пользовательские ресурсы в Kubernetes API.

Пример CRD

Код ITЗагрузка примера кода…

Разбор:

CustomResourceDefinition регистрирует новый тип Database в API.
group: example.com, versions[].schema — OpenAPI валидация полей CR.
scope: Namespaced — объекты CR в пределах namespace.
names.plural/kind — kubectl get databases, kind: Database.

После применения можно создавать объекты:

apiVersion: example.com/v1
kind: Database
metadata:
  name: my-db
spec:
  size: "10Gi"

Разбор:

Пример пользовательского ресурса после установки CRD.
apiVersion: example.com/v1 — версия из CRD.
spec.size: "10Gi" — доменное поле, валидируется схемой CRD.
См. пояснение в тексте раздела выше или ниже.

Operators

Паттерн расширения Kubernetes, реализующий доменную логику через контроллер, управляющий CRD.

Оператор наблюдает за состоянием CR и выполняет действия:

Создание PVC, Service, Secret
Выполнение SQL-миграций
Резервное копирование

Инструменты

Helm

Менеджер пакетов для Kubernetes. Пакет называется Chart.

Структура Chart

my-chart/
├── Chart.yaml
├── values.yaml
├── charts/          # зависимости
└── templates/       # шаблоны YAML
    ├── deployment.yaml
    ├── service.yaml
    └── _helpers.tpl

Разбор:

Chart.yaml — метаданные чарта — name, version, appVersion, зависимости (dependencies).
values.yaml — параметры по умолчанию; переопределяют -f values-prod.yaml при helm install/upgrade.
charts/ — вложенные subchart'ы (зависимости), подтягиваются helm dependency build.
templates/ — Go-шаблоны манифестов K8s; рендер: {{ .Values.replicaCount }}.
_helpers.tpl — именованные фрагменты шаблонов (labels, selectors) для переиспользования.
Дерево каталогов — соглашение Helm 3; helm package упаковывает его в .tgz.

Ключевые команды

helm install my-release ./my-chart
helm upgrade my-release ./my-chart
helm rollback my-release 2
helm template ./my-chart    # рендеринг без установки

Разбор:

helm install — развёртывание chart с релизом my-release.
helm upgrade — обновление релиза новыми values/шаблонами.
helm rollback — откат к ревизии 2.
helm template — рендер YAML без применения в кластер.

Kustomize

Инструмент для декларативной настройки манифестов без шаблонов.

Использует файл kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
namePrefix: staging-
namespace: staging
commonLabels:
  env: staging
patches:
  - path: patch.yaml

Разбор:

resources — базовые манифесты для Kustomize.
namePrefix: staging- — префикс имён всех ресурсов.
namespace: staging — переопределение namespace.
commonLabels — labels на все объекты.
patches — стратегические или JSON6902 патчи.

Kustomize (рекомендуемый синтаксис patches вместо patchesStrategicMerge):

kubectl apply -k overlays/staging/

Разбор:

kubectl apply -k — сборка overlay Kustomize и применение в кластер.
Путь overlays/staging/ должен содержать kustomization.yaml.
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

kubectl — шпаргалка команд

Типовые команды kubectl, сгруппированные по задачам. Краткая версия — в учебной шпаргалке; полный справочник CLI — reference/kubectl.

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

Команда	Назначение
`kubectl config view`	Показать настройки kubeconfig
`kubectl config view -o jsonpath='{.users[*].name}'`	Список пользователей в конфиге
`kubectl config get-contexts`	Все контексты (кластер + пользователь + namespace)
`kubectl config current-context`	Текущий контекст
`kubectl config use-context <имя>`	Переключить контекст по умолчанию
`kubectl config set-credentials <user>@<cluster> --username=... --password=...`	Добавить учётные данные
`kubectl config set-context --current --namespace=<ns>`	Запомнить namespace для всех последующих команд
`kubectl config unset users.<имя>`	Удалить пользователя из kubeconfig

Просмотр и поиск ресурсов

Команда	Назначение
`kubectl get <ресурсы>`	Список объектов в namespace текущего контекста
`kubectl get pods --all-namespaces`	Все Pod во всех namespace (`-A` — то же)
`kubectl get pods -o wide`	Pod с node, IP и прочими колонками
`kubectl describe nodes <node>`	Подробности ноды: условия, ёмкость, события
`kubectl events --types=Warning`	Предупреждающие события кластера
`kubectl diff -f ./manifest.yaml`	Отличия манифеста от состояния кластера перед `apply`

Обновление ресурсов

Команда	Назначение
`kubectl rollout history deployment/<имя>`	История ревизий Deployment
`kubectl rollout undo deployment/<имя>`	Откат к предыдущей ревизии
`kubectl rollout restart deployment/<имя>`	Rolling restart без смены образа
`kubectl label pods <pod> <key>=<value>`	Добавить или изменить label
`kubectl annotate pods <pod> <key>-`	Удалить annotation (дефис после ключа)
`kubectl autoscale deployment <имя> --min=2 --max=10`	Создать HPA для Deployment

Создание ресурсов

Команда	Назначение
`kubectl apply -f ./manifest.yaml`	Декларативно создать или обновить объекты
`kubectl create deployment nginx --image=nginx`	Императивно создать Deployment
`kubectl explain pods`	Справка по полям API (`.spec.containers` и т. д.)

Масштабирование

Команда	Назначение
`kubectl scale --replicas=3 rs/<имя>`	Масштабировать ReplicaSet
`kubectl scale --current-replicas=2 --replicas=3 deployment/<имя>`	Масштабировать только если текущее число реплик совпадает
`kubectl scale --replicas=5 rc/foo rc/bar rc/baz`	Несколько ReplicationController за раз

Работа с запущенными Pod

Команда	Назначение
`kubectl logs <pod>`	Логи контейнера (stdout/stderr)
`kubectl logs <pod> -c <container>`	Логи конкретного контейнера в multi-container Pod
`kubectl logs -f <pod>`	Поток логов в реальном времени
`kubectl run nginx --image=nginx -n <ns>`	Одноразовый Pod (для экспериментов; в проде — манифесты)
`kubectl attach <pod> -i`	Подключиться к stdin работающего контейнера
`kubectl port-forward <pod> 5000:6000`	Локальный порт 5000 → порт 6000 в Pod
`kubectl exec --stdin --tty <pod> -- /bin/sh`	Интерактивный shell в Pod
`kubectl debug <pod> -it --image=busybox`	Ephemeral debug-контейнер (K8s 1.23+)
`kubectl top pod <имя> --containers`	CPU/RAM по Pod и контейнерам (нужен Metrics Server)

Deployment и Service

Команда	Назначение
`kubectl logs deploy/<имя>`	Логи Pod'а Deployment (один контейнер)
`kubectl port-forward svc/<имя> 5000`	Локальный порт → порт Service
`kubectl exec deploy/<имя> -- <команда>`	Команда в первом Pod и контейнере Deployment

Дополнительно — права, Kustomize и метрики нод:

kubectl auth can-i create pods --namespace dev
kubectl top nodes
kubectl apply -k overlays/staging/

Разбор:

config view / get-contexts / use-context — работа с ~/.kube/config; set-context --current --namespace избавляет от -n в каждой команде.
get -o wide, describe, events --types=Warning — быстрая диагностика без входа в Pod.
diff -f — dry-run отличий; удобно в CI перед apply.
rollout history / undo / restart — жизненный цикл Deployment; restart пересоздаёт Pod'ы с тем же образом.
label и annotate с суффиксом - у ключа — удаление метаданных.
autoscale создаёт HorizontalPodAutoscaler; для кастомных метрик нужны metrics-server или Prometheus adapter.
apply — основной декларативный путь; create и run — императивные, для отладки.
explain — встроенная документация API; альтернатива веб-справочнику.
scale --current-replicas — оптимистичная блокировка при параллельных изменениях.
logs -f, exec -it, port-forward, debug — отладка без SSH на ноду.
logs deploy/... и exec deploy/... — сокращения для workload-контроллеров; выбирается один из Pod'ов.
auth can-i — проверка RBAC перед действием; top — метрики узлов и Pod'ов.

CI/CD и GitOps

Argo CD

Инструмент GitOps, синхронизирующий состояние кластера с манифестами в Git.

Отслеживает ветку репозитория
Автоматически применяет изменения
Предоставляет UI и CLI для управления

Application CR

Код ITЗагрузка примера кода…

Разбор:

Argo CD Application — GitOps-связь репозитория и кластера.
source.repoURL / path — откуда брать манифесты.
destination.server — API кластера (in-cluster: kubernetes.default.svc).
destination.namespace — целевой namespace развёртывания.

Tekton

Фреймворк для CI/CD на основе Kubernetes. Использует CRD — Task, Pipeline, PipelineRun.

Пример Task

В новых установках предпочтителен API tekton.dev/v1; ниже — распространённый вариант v1beta1.

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-image
spec:
  steps:
    - name: build
      image: gcr.io/kaniko-project/executor:v1.9.1
      args:
        - --dockerfile=/workspace/Dockerfile
        - --destination=my-registry/app:$(inputs.params.version)

Разбор:

Tekton Task — один шаг CI в Kubernetes.
steps[].image — образ с инструментом (Kaniko для сборки).
args — параметры executor (--destination — push в registry).
inputs.params.version — подстановка тега образа из PipelineRun.

Tekton хорошо интегрируется с Argo Events, GitHub Actions и другими триггерами.

Сетевые модели и CNI-плагины

Kubernetes требует реализации Container Network Interface (CNI) для обеспечения сетевой связи между Pod’ами.

Общие требования к CNI

Каждый Pod получает уникальный IP-адрес (IP-per-Pod)
Pod’ы могут общаться напрямую без NAT
Узлы могут общаться с Pod’ами без NAT
Поддержка политик безопасности (опционально)

Calico

Высокопроизводительный CNI с поддержкой сетевых политик, BGP и eBPF.

Особенности

Использует BGP для маршрутизации между Node
Поддерживает режимы:
- IPIP — инкапсуляция трафика (подходит для облака)
- VXLAN — альтернатива IPIP
- eBPF — ускорение dataplane без iptables
Полная поддержка NetworkPolicy
Встроенный контроллер для управления политиками

Установка

Через Helm или manifest (актуальный URL — на странице установки Calico):

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml

Разбор:

Применение манифеста Calico (CNI + NetworkPolicy).
Версию v3.28.0 сверяйте с документацией Tigera.
После apply Pod'ы kube-system должны перейти в Running.
См. пояснение в тексте раздела выше или ниже.

Cilium

CNI на основе eBPF, обеспечивающий высокую производительность и расширенную безопасность.

Особенности

Полная замена iptables на eBPF
Поддержка L3–L7 политик (включая HTTP, Kafka, gRPC)
Встроенная видимость трафика (Hubble)
Безопасность на уровне identity, а не IP
Поддержка Service Mesh без sidecar (Cilium Service Mesh)

Установка

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set hubble.enabled=true

Разбор:

helm install cilium — CNI на eBPF в namespace kube-system.
hubble.enabled=true — UI/CLI наблюдаемость трафика L3–L7.
Требуется совместимое ядро Linux и отключение конфликтующего CNI.
См. пояснение в тексте раздела выше или ниже.

Flannel

Простой и лёгкий CNI, использующий VXLAN по умолчанию.

Особенности

Минимальная конфигурация
Не поддерживает NetworkPolicy (требуется дополнительный компонент)
Подходит для тестовых и небольших кластеров
Хранит конфигурацию в etcd или kube-api

Установка

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Разбор:

Официальный manifest Flannel — простой overlay CNI (VXLAN).
Не включает NetworkPolicy — для политик нужен Calico/Cilium поверх или вместо.
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

Мультикластерное управление

Karmada

Проект CNCF для управления несколькими кластерами через единый control plane.

Возможности

Распределение рабочих нагрузок по кластерам
Failover между регионами
Единая политика размещения (PropagationPolicy)
Поддержка федеративных ресурсов

Архитектура

Control plane в отдельном кластере
Агенты (karmada-agent) в управляемых кластерах
Ресурсы дублируются через ResourceBinding

Cluster API (CAPI)

Декларативный подход к управлению жизненным циклом Kubernetes-кластеров.

Компоненты

Cluster: описание кластера
Machine: описание Node
Provider — облачный или bare-metal провайдер (AWS, Azure, Metal3)

Пример

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: my-cluster
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSManagedCluster
    name: my-cluster
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: my-cluster-control-plane

Разбор:

Cluster API: декларативное описание кластера.
infrastructureRef — провайдер инфраструктуры (AWS, Azure).
controlPlaneRef — KubeadmControlPlane для мастеров.
См. пояснение в тексте раздела выше или ниже.

Позволяет автоматизировать создание, масштабирование и удаление кластеров.

Rancher

Платформа с UI для управления множеством кластеров (включая EKS, GKE, AKS, RKE).

Функции

Централизованная аутентификация (LDAP, SAML)
RBAC на уровне проектов
Мониторинг и логирование из коробки
CI/CD через Fleet и GitRepo CRD
Поддержка Windows Node

Отладка и диагностика

Чек-лист диагностики Pod’а

Проверка статуса

   kubectl get pod <name>

Разбор:

kubectl get pod <name> — краткий статус (READY, STATUS, RESTARTS).
Фазы — Pending, Running, Succeeded, Failed, Unknown — см. жизненный цикл Pod и учебный раздел.

Описание Pod’а

   kubectl describe pod <name>

Разбор:

describe pod — Events — FailedScheduling, ImagePullBackOff, OOMKilled.
Показывает requests/limits, node, volumes, conditions.
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

Показывает события — FailedScheduling, ImagePullBackOff, CrashLoopBackOff.

Логи контейнера

   kubectl logs <pod> -c <container>
   kubectl logs <pod> --previous  # предыдущий запуск

Разбор:

logs -c <container> — логи конкретного контейнера.
--previous — логи упавшего контейнера до рестарта.
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

Интерактивный доступ

   kubectl exec -it <pod> -- sh

Разбор:

exec -it — интерактивная отладка в running Pod.
Требует shell в образе; для distroless — debug ephemeral containers (K8s 1.23+).
См. пояснение в тексте раздела выше или ниже.
См. пояснение в тексте раздела выше или ниже.

Проверка сети

   kubectl run debug --image=busybox --rm -it --restart=Never -- sh
   nslookup service-name
   wget http://service-name:80

Разбор:

Временный Pod debug на busybox для сетевой диагностики.
nslookup service-name — DNS Service внутри кластера.
wget http://service-name:80 — проверка доступности Service.
См. пояснение в тексте раздела выше или ниже.

Типичные проблемы и решения

Проблема	Причина	Решение
`ImagePullBackOff`	Неверный образ или нет доступа к registry	Проверить имя образа, добавить `imagePullSecrets`
`CrashLoopBackOff`	Контейнер завершается с ошибкой	Проверить логи, readinessProbe, зависимости
`Pending`	Недостаточно ресурсов или taints	Увеличить capacity, добавить tolerations
`Service unreachable`	Неправильный selector или порт	Сверить `selector` и `targetPort`
`Ingress not working`	Нет Ingress Controller	Установить NGINX/Traefik

Резервное копирование — Velero

Инструмент для резервного копирования и восстановления кластера.

Возможности

Резервное копирование Namespace, PVC, PV
Восстановление в другой кластер
Планирование через CronJob
Интеграция с AWS S3, Azure Blob, GCS

Установка

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.8.0 \
  --bucket k8s-backups \
  --secret-file ./credentials-velero

Разбор:

velero install — деплой Velero в кластер с плагином AWS.
--bucket — S3 bucket для backup объектов и PV снапшотов.
--secret-file — credentials для облачного API.
См. пояснение в тексте раздела выше или ниже.

Создание бэкапа

velero backup create full-backup --include-namespaces=prod
velero backup get
velero restore create --from-backup full-backup

Разбор:

backup create — снимок ресурсов namespace prod.
backup get — список бэкапов.
restore create --from-backup — восстановление в тот же или другой кластер.
См. пояснение в тексте раздела выше или ниже.

Производительность и масштабируемость

Официальные лимиты Kubernetes (v1.29+)

До 5000 Node’ов
До 150 000 Pod’ов
До 110 Pod’ов на Node
До 10000 сервисов
До 200000 total objects

Best Practices

Использовать HPA вместо ручного масштабирования
Ограничивать ресурсы через requests/limits
Избегать hostPath в production
Использовать PodDisruptionBudget для отказоустойчивости
Включать livenessProbe и readinessProbe
Разделять критические и некритические нагрузки по Namespace
Использовать nodeSelector или affinity для размещения GPU-нагрузок

PodDisruptionBudget (PDB)

Гарантирует минимальное количество доступных Pod’ов при добровольных прерываниях (например, обновление Node).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

Разбор:

PodDisruptionBudget ограничивает добровольные eviction (drain node).
minAvailable: 2 — минимум 2 Pod с label app: web всегда доступны.
Альтернатива: maxUnavailable: 1 — не более одного недоступного Pod.
selector должен совпадать с labels Pod'ов Deployment/StatefulSet.

Альтернатива: maxUnavailable: 1

Ошибки

Ситуация	Что проверить
Команда не найдена	PATH, установка пакета, alias
Permission denied	пользователь, группа, sudo, ACL
Неверная версия	см. "Совместимость", `--version`

Совместимость

Область	Примечание
Версии	актуальные LTS/стабильные релизы Kubernetes
Платформы	официальная матрица поддержки вендора
Стандарты	RFC, ISO, спецификация API — см. таблицы выше

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

В подборках

Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:

Справочники — Справочник по Docker, Справочник по Roblox, Справочник по Apache Kafka, Справочник по Unity, Справочник по RabbitMQ, Справочник по Adobe Photoshop.

Назначение​

Краткое пояснение​

Официальная документация (kubernetes.io)​

Быстрый старт​

Справочные таблицы​

Содержание справочника​

Общая архитектура Kubernetes​

Компоненты Control Plane (управляющей плоскости)​

Компоненты Data Plane (рабочей плоскости)​

Основные понятия Kubernetes​

Кластер (Cluster)​

Node (Узел)​

Pod​

Жизненный цикл Pod (краткая схема)​

Namespace​

Label и Selector​

Annotation​

Структура объекта Kubernetes​

Core API Resources​

Pod​

Структура spec​

Важные параметры контейнера​

Типы Volume​

Service​

Типы Service​

Структура spec​

Namespace​

Node​

Workload Controllers​

Deployment​

Структура spec​

Параметры стратегии обновления​

Полезные команды​

StatefulSet​

Структура spec​

Особенности​

DaemonSet​

Структура spec​

Job​

Структура spec​

CronJob​

Структура spec​

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

ConfigMap​

Способы использования​

Структура объекта​

Secret​

data и stringData​

Структура (Opaque)​

Создание через kubectl​

Типы Secret​

Способы использования в Pod​

Пример TLS Secret​

Шифрование Secret в etcd​

Секреты вне Git и GitOps​

RBAC и риски​

Отладка​

Сетевые ресурсы​

Ingress​

Структура spec​

Типы путей (pathType)​

Аннотации (часто используются)​

NetworkPolicy​

Пример — разрешить вход только из frontend​

Хранилище​

PersistentVolume (PV)​

Типы провайдеров​

Структура PV​

Access Modes​

Reclaim Policy​

PersistentVolumeClaim (PVC)​

StorageClass​

Безопасность​

Role-Based Access Control (RBAC)​

Основные объекты​

Структура Role​

Допустимые глаголы (verbs)​

Пример RoleBinding​

ServiceAccount​

Создание ServiceAccount​

Назначение

Краткое пояснение

Официальная документация (kubernetes.io)

Быстрый старт

Справочные таблицы

Содержание справочника

Общая архитектура Kubernetes

Компоненты Control Plane (управляющей плоскости)

Компоненты Data Plane (рабочей плоскости)

Основные понятия Kubernetes

Кластер (Cluster)

Node (Узел)

Pod

Жизненный цикл Pod (краткая схема)

Namespace

Label и Selector

Annotation

Структура объекта Kubernetes

Core API Resources

Pod

Структура spec

Важные параметры контейнера

Типы Volume

Service

Типы Service

Структура spec

Namespace

Node

Workload Controllers

Deployment

Структура spec

Параметры стратегии обновления

Полезные команды

StatefulSet

Структура spec

Особенности

DaemonSet

Структура spec

Job

Структура spec

CronJob

Структура spec

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

ConfigMap

Способы использования

Структура объекта

Secret

`data` и `stringData`

Структура (Opaque)

Создание через kubectl

Типы Secret

Способы использования в Pod

Пример TLS Secret

Шифрование Secret в etcd

Секреты вне Git и GitOps

RBAC и риски

Отладка

Сетевые ресурсы

Ingress

Структура spec

Типы путей (pathType)

Аннотации (часто используются)

NetworkPolicy

Пример — разрешить вход только из frontend

Хранилище

PersistentVolume (PV)

Типы провайдеров

Структура PV

Access Modes

Reclaim Policy

PersistentVolumeClaim (PVC)

StorageClass

Безопасность

Role-Based Access Control (RBAC)

Основные объекты

Структура Role

Допустимые глаголы (verbs)

Пример RoleBinding

ServiceAccount

Создание ServiceAccount