Kubernetes для DevOps: полный практический мануал

Архитектура Kubernetes и ключевые концепции

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

Что такое кластер Kubernetes

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

В кластере есть две большие части:

Control Plane — «мозг» кластера: хранит состояние, принимает решения, выдает задания узлам.

Worker Nodes — исполняют контейнеры и предоставляют ресурсы (CPU, RAM, сеть, диск).

!Общая карта компонентов Kubernetes и их связей

Control Plane: компоненты и их роли

Control Plane реализует управление кластером через набор компонентов.

kube-apiserver

kube-apiserver — входная точка в Kubernetes.

Принимает запросы от kubectl, CI/CD, операторов, контроллеров.

Валидирует и применяет изменения к объектам.

Является центральным хабом: остальные компоненты взаимодействуют с кластером через API.

Официально: Компоненты Kubernetes

etcd

etcd — распределенное key-value хранилище, где лежит истина о состоянии кластера.

Хранит желаемое и текущее состояние объектов (Pods, Deployments, Services и т.д.).

Критично для надежности: потеря данных etcd = потеря состояния кластера.

Важно понимать практику:

Резервное копирование etcd — обязательная часть эксплуатации.

Доступ к etcd должен быть максимально ограничен.

Официально: Администрирование кластера — etcd

kube-scheduler

kube-scheduler выбирает, на какую ноду поставить Pod.

Он учитывает:

Доступные ресурсы и requests Pod.

Ограничения (taints/tolerations).

Предпочтения (affinity/anti-affinity).

Топологию (зоны/регионы, spread).

kube-controller-manager

kube-controller-manager запускает набор контроллеров, которые постоянно приводят фактическое состояние к желаемому.

Типичные контроллеры:

Deployment/ReplicaSet controller.

Node controller.

Job controller.

EndpointSlice controller.

Ключевая идея: Kubernetes — это контроллерная система с циклом согласования (reconciliation loop).

cloud-controller-manager

cloud-controller-manager (если кластер в облаке) интегрирует Kubernetes с API облачного провайдера.

Примеры задач:

Создание Load Balancer для Service типа LoadBalancer.

Управление маршрутами и адресами.

Интеграция с дисками (в зависимости от реализации).

Официально: Cloud Controller Manager

Worker Node: что запускает ваши контейнеры

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

kubelet

kubelet — агент на ноде.

Получает от API сведения о Pod, которые должны работать на этой ноде.

Запускает контейнеры через container runtime.

Отчитывается о статусе Pod и ноды.

Следит за probe-проверками (liveness/readiness/startup).

Container runtime

Container runtime — движок, который реально запускает контейнеры.

В современных кластерах обычно используется containerd или CRI-O.

Kubernetes общается с runtime через интерфейс CRI.

Официально: Container Runtime Interface (CRI)

kube-proxy

kube-proxy реализует сетевую абстракцию Service на нодах.

Настраивает правила (обычно iptables или ipvs) для балансировки трафика к Pod.

Обеспечивает стабильные виртуальные IP и порты Service.

Официально: Service

Декларативная модель и объектная модель Kubernetes

Kubernetes управляется через объекты (resources). Вы описываете желаемое состояние, а контроллеры добиваются его выполнения.

Практический вывод для DevOps:

В Git обычно хранится YAML-манифест (GitOps или просто IaC-подход).

В kubectl apply важна не команда, а согласование состояния.

Официально: Объекты Kubernetes

Метаданные: labels, selectors, annotations

Labels — ключ-значение для классификации объектов.

Используются для выборки (например, Service выбирает Pod по labels).

Selectors — правила отбора объектов по labels.

Annotations — произвольные метаданные, обычно не для выборки, а для интеграций.

Официально: Labels и Selectors

Namespace

Namespace — логическая изоляция объектов внутри одного кластера.

Удобно для разделения окружений и команд.

Не является жесткой security-границей сама по себе.

Официально: Namespaces

Базовые workload-объекты

Workload-объекты описывают, как запускать приложения.

Pod

Pod — минимальная единица запуска.

Содержит один или несколько контейнеров, которые разделяют сеть (IP/порты) и могут разделять тома.

Обычно Pod — эфемерен: при пересоздании получает новый IP.

Официально: Pods

ReplicaSet и Deployment

ReplicaSet поддерживает заданное число реплик Pod.

Deployment управляет ReplicaSet и предоставляет:

Rolling Update.

Rollback.

Декларативное обновление версии.

Типичный выбор для stateless-приложений — Deployment.

Официально: Deployments

StatefulSet

StatefulSet предназначен для stateful-нагрузок.

Стабильные имена Pod.

Предсказуемая нумерация.

Часто используется вместе с PersistentVolume.

Официально: StatefulSets

DaemonSet

DaemonSet гарантирует запуск Pod на каждой (или выбранной) ноде.

Логи/агенты мониторинга.

CNI-плагины.

Node-level компоненты.

Официально: DaemonSet

Job и CronJob

Job запускает Pod до успешного завершения.

CronJob запускает Job по расписанию.

Бэкапы.

Периодические задачи.

Batch-обработка.

Официально: Jobs

Сетевые концепции: Service, Ingress и модель сети

Сетевая модель Kubernetes

Kubernetes следует простой модели:

Каждый Pod получает свой IP.

Pod должны уметь общаться друг с другом без NAT.

Ноды должны уметь общаться с Pod.

Это реализуется через CNI-плагин (Calico, Cilium, Flannel и т.д.).

Официально: Модель сети в Kubernetes

Service

Service — стабильная точка доступа к группе Pod.

Основные типы:

ClusterIP — доступ внутри кластера.

NodePort — порт на каждой ноде.

LoadBalancer — внешний балансировщик (обычно через облако).

Service выбирает Pod через selector по labels.

Официально: Service

Ingress и Ingress Controller

Ingress — правила L7-маршрутизации HTTP/HTTPS до Service.

Важно различать:

Ingress — это объект с правилами.

Ingress Controller — это компонент, который эти правила реализует (например, NGINX Ingress, Traefik, HAProxy).

Официально: Ingress

NetworkPolicy

NetworkPolicy ограничивает сетевые взаимодействия между Pod.

Работает только если CNI поддерживает policy enforcement.

Используется для сегментации и принципа наименьших привилегий.

Официально: Network Policies

Хранилище: PV, PVC и CSI

Kubernetes отделяет запрос хранилища от реализации хранилища.

Ключевые объекты:

PersistentVolume (PV) — ресурс хранилища в кластере.

PersistentVolumeClaim (PVC) — запрос на хранилище от приложения.

StorageClass — политика динамического выделения томов.

Подключение хранилищ делается через CSI (Container Storage Interface).

Официально:

Persistent Volumes

Container Storage Interface (CSI)

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

ConfigMap хранит некритичную конфигурацию.

Secret хранит чувствительные данные.

Практические замечания:

Secret в Kubernetes по умолчанию — base64, а не шифрование.

Часто требуется включать шифрование секретов на уровне API Server и использовать внешние менеджеры секретов.

Официально:

ConfigMaps

Secrets

Планирование и изоляция: requests/limits, QoS, taints, affinity

Requests и limits

Requests — гарантируемый минимум ресурсов для Pod при планировании.

Limits — верхняя граница, которую контейнер не должен превышать.

Это влияет на:

Решение scheduler, куда поставить Pod.

Поведение при давлении ресурсов на ноде.

Официально: Managing Resources for Containers

QoS-классы

На основе requests/limits Kubernetes назначает Pod класс качества сервиса (QoS), что влияет на то, кого вытеснять при нехватке ресурсов.

Официально: Pod Quality of Service Classes

Taints и tolerations

Taint ставится на ноду и говорит: «сюда нельзя планировать Pod, если он не терпит taint».

Toleration ставится на Pod и разрешает ему быть запланированным на tainted-ноду.

Это базовый механизм для:

Выделенных нод (например, под базы данных).

Инфраструктурных нод.

Официально: Taints and Tolerations

Affinity и anti-affinity

Affinity позволяет предпочитать или требовать размещение Pod рядом с определенными Pod или на определенных нодах.

Anti-affinity помогает разносить реплики по нодам/зонам для отказоустойчивости.

Официально: Affinity and anti-affinity

Надежность приложений: probes и контроллеры

Kubernetes поддерживает автоматическое восстановление за счет контроллеров и проверок.

Проверки контейнеров:

livenessProbe — «жив ли процесс», иначе перезапуск контейнера.

readinessProbe — «готов ли принимать трафик», иначе исключение из балансировки.

startupProbe — «успешно ли стартовал», полезно для долгого запуска.

Официально: Probes

Безопасность: RBAC, ServiceAccount и admission

RBAC

RBAC определяет, кто и что может делать в API Kubernetes.

Основные сущности:

Role/ClusterRole — набор разрешений.

RoleBinding/ClusterRoleBinding — привязка разрешений к субъектам.

Официально: RBAC

ServiceAccount

ServiceAccount — идентичность для процессов внутри Pod.

По умолчанию Pod получает токен ServiceAccount namespace.

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

Официально: Service Accounts

Admission Controllers

Admission — слой, который может валидировать или мутировать запросы перед записью в etcd.

Политики безопасности.

Валидации.

Автоматические инъекции (например, sidecar).

Официально: Admission Controllers

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

Kubernetes можно расширять.

CRD (CustomResourceDefinition) добавляет новый тип объекта в API.

Operator — контроллер, который управляет вашим CRD и автоматизирует жизненный цикл сложных систем (например, баз данных).

Официально:

Custom Resources

Operator pattern

Как все это работает вместе: жизненный цикл типичного деплоя

Ниже — упрощенная цепочка событий от манифеста до работающего приложения.

Вы применяете YAML (kubectl apply) и отправляете желаемое состояние в kube-apiserver.

kube-apiserver валидирует запрос, запускает admission-цепочки и сохраняет объект в etcd.

Контроллер (например, Deployment controller) видит новое желаемое состояние и создает дочерние объекты (ReplicaSet, затем Pods).

kube-scheduler выбирает подходящие ноды для созданных Pod и записывает привязку (binding).

На выбранной ноде kubelet видит назначенный Pod и просит container runtime запустить контейнеры.

CNI настраивает сеть Pod, kube-proxy обеспечивает доступ через Service.

Readiness-проба становится успешной, Pod попадает в балансировку, приложение начинает принимать трафик.

Что важно запомнить перед переходом к практике

Kubernetes управляет состоянием, а не «запускает контейнеры командой».

Все крутится вокруг API: если понимаете объекты и контроллеры, вы понимаете Kubernetes.

Надежность достигается через контроллеры, probes, правильное планирование и сетевые/безопасностные политики.

В следующих материалах курса мы перейдем от теории к практике: развернем кластер или локальное окружение, научимся работать с kubectl, манифестами и базовыми объектами (Pod, Deployment, Service), а затем закрепим это через типовые production-сценарии.

Установка и управление кластерами: kubeadm, managed, kind

После статьи про архитектуру Kubernetes важно перейти от что внутри кластера к как кластер получить и как им управлять. Для DevOps инженера это означает уметь:

Выбирать подходящий тип кластера под задачу.

Поднимать кластер для лабораторий и CI.

Поднимать и обслуживать production-кластеры.

Понимать границы ответственности: что делает Kubernetes, что делает облако, что делаете вы.

В этой статье разберем три самых практичных подхода:

kubeadm: самостоятельная установка Kubernetes на свои ВМ/серверы.

Managed Kubernetes: управляемые кластеры в облаках (EKS/GKE/AKS).

kind: локальный Kubernetes в Docker для разработки и тестов.

!Схема выбора подхода: kind vs kubeadm vs managed

Как выбрать подход: kind, kubeadm или managed

Ниже — практические критерии выбора.

| Подход | Где работает | Кто управляет Control Plane | Сложность эксплуатации | Типичный сценарий | |---|---|---|---|---| | kind | Локально (Docker) | Вы (но это тестовый формат) | Низкая | Быстрые лаборатории, CI-тесты манифестов/Helm | | kubeadm | Свои ВМ/серверы | Вы | Высокая | On-prem, выделенные среды, полный контроль | | Managed Kubernetes | Облако | Провайдер | Средняя | Production в облаке, фокус на приложениях и политиках |

Практическая рекомендация для обучения и работы:

Начните с kind, чтобы быстро отработать kubectl, манифесты и базовые объекты.

Перейдите к managed (если ваша работа в облаке), чтобы освоить реальные production-практики.

Освойте kubeadm, если вам нужно администрировать кластеры на своих серверах или понимать Kubernetes глубже.

Общие предпосылки: что нужно любому кластеру

Чтобы не было “магии”, зафиксируем базовые зависимости.

Container runtime

Kubernetes не запускает контейнеры сам, он делает это через CRI (Container Runtime Interface). На практике чаще всего используется containerd.

Kubelet на ноде получает описание Pod.

Через CRI обращается к container runtime.

Runtime запускает контейнеры.

Официально: Container Runtimes

CNI-плагин (сеть Pod)

По умолчанию kubeadm-кластер после установки не имеет сети Pod. Сеть добавляет CNI-плагин (например, Calico или Cilium). Пока CNI не установлен, Pods не смогут нормально работать.

Официально: Networking and Network Policy

kubectl и kubeconfig

kubectl — CLI для обращения к kube-apiserver. Доступ описывается файлом kubeconfig (URL API, сертификаты/токены, контексты).

Официально: Configure Access to Multiple Clusters

kind: локальный кластер для практики и CI

kind (Kubernetes IN Docker) запускает Kubernetes-ноды как Docker-контейнеры. Это быстрый способ получать “почти настоящий” Kubernetes без облака и без ручной сборки.

Официально: kind

Установка kind

Установите Docker.

Установите kind.

Проверьте версии.

Ссылки:

Get Docker

kind installation

Создание кластера kind

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

Если нужно несколько worker-нод и проброс портов, используйте конфиг.

Загрузка локального образа в kind

В CI и при локальной разработке часто нужно протестировать образ без публикации в registry.

После этого в манифесте указывайте image: myapp:dev.

Ограничения kind (важно понимать заранее)

kind отлично подходит для обучения и автоматизации, но это не production.

Ноды — это контейнеры, поэтому поведение сети и дисков отличается от реальных ВМ.

LoadBalancer по умолчанию нет (как в облаке), часто используют NodePort или дополнительные решения.

Производительность и изоляция зависят от Docker и ресурсов ноутбука.

Managed Kubernetes: EKS, GKE, AKS и модель ответственности

Managed Kubernetes — это кластеры, где Control Plane управляется облачным провайдером. Обычно вы платите за control plane и за worker-ноды (или за serverless-поды), а провайдер берет на себя часть задач.

Официальные страницы:

Amazon EKS

Google Kubernetes Engine (GKE)

Azure Kubernetes Service (AKS)

Что вы получаете “из коробки”

Это зависит от провайдера, но чаще всего:

Высокодоступный kube-apiserver.

Управляемое хранилище состояния (etcd) и его обслуживание.

Интеграцию с балансировщиками и дисками через облачные реализации.

Упрощенные обновления версии Kubernetes.

За что отвечаете вы

Даже в managed-модели ответственность DevOps не исчезает. Обычно на вас:

Архитектура namespaces, RBAC и политики доступа.

Настройка сетевой сегментации (например, NetworkPolicy) и безопасность workloads.

Observability: логи, метрики, алерты.

Обновления приложений, корректные requests/limits, autoscaling.

Управление worker-нодами (если не serverless), их образами и обновлениями.

Ключевые особенности managed-кластеров

#### Идентификация и доступ

В облаках часто используется интеграция с IAM/Identity:

Аутентификация пользователя происходит через облачную учётку.

Далее запрос сопоставляется с Kubernetes RBAC.

В результате вы управляете доступом на двух уровнях: облако и Kubernetes.

#### Интеграция с балансировщиками

Service типа LoadBalancer обычно создаёт реальный облачный балансировщик. Для DevOps важно понимать стоимость и жизненный цикл таких ресурсов.

Официально: Service type LoadBalancer

#### Обновления Kubernetes

В managed-кластере обычно есть:

Обновление control plane (запускается провайдером по вашему действию или расписанию).

Обновление node pools (вы управляете тем, как обновлять worker-ноды и как делать drain/rollout).

Практический вывод: обновления — это проект, который надо планировать (совместимость версий, окна, откаты, тесты в staging).

Официально: Kubernetes Version Skew Policy

kubeadm: установка Kubernetes на свои ВМ/серверы

kubeadm — официальный инструмент Kubernetes для bootstrap кластера. Он не “управляет” кластером постоянно, а помогает:

Инициализировать control plane.

Подключить worker-ноды.

Выполнить базовые операции апгрейда.

Официально: kubeadm

Когда kubeadm — правильный выбор

kubeadm оправдан, если:

У вас on-prem или выделенные серверы.

Нужен полный контроль над настройками.

Есть требования по изоляции и отсутствию зависимости от облака.

Цена — эксплуатационная сложность: сеть, обновления, сертификаты, резервные копии etcd и восстановление ложатся на вашу команду.

Предварительные требования (минимально необходимые)

Ниже — базовые вещи, которые должны быть выполнены на каждой ноде.

Совместимая ОС (часто Linux, например Ubuntu).

Рабочая сеть между нодами.

Отключенный swap (требование kubelet по умолчанию).

Установленный container runtime (чаще containerd).

Официально: Installing kubeadm

Базовый сценарий установки kubeadm-кластера

Ниже — логика процесса. Команды и пакеты зависят от дистрибутива, поэтому ориентируйтесь на официальную инструкцию установки.

#### Установка компонентов

На всех нодах устанавливают:

kubelet — агент ноды.

kubeadm — bootstrap.

kubectl — CLI (обычно нужен на админ-машине и часто на control plane).

Официально: Installing kubeadm, kubelet and kubectl

#### Инициализация control plane

На первой control plane ноде:

Параметр --pod-network-cidr задает диапазон IP для Pod и должен соответствовать выбранному CNI.

Дальше настраивается kubectl для текущего пользователя (kubeconfig):

На этом этапе нода control plane обычно будет в статусе NotReady, пока не установлен CNI.

#### Установка CNI

Выберите один CNI и установите его манифестом.

Примеры официальных проектов:

Project Calico

Cilium Quick Installation

После установки CNI:

#### Подключение worker-нод

Команду kubeadm join kubeadm печатает после init. Она выглядит примерно так:

Смысл параметров:

<control-plane-endpoint>:6443 — адрес API сервера.

--token — временный токен для присоединения.

--discovery-token-ca-cert-hash — проверка, что вы подключаетесь к правильному кластеру.

#### Разрешить запуск workloads на control plane (только для лабораторий)

По умолчанию control plane ноды “защищены” от обычных workload через taint. Для маленькой домашней лаборатории можно снять taint:

В production так делать обычно не нужно.

Высокая доступность control plane (кратко)

Для production часто делают несколько control plane нод.

Ключевая идея:

Нужен стабильный endpoint для API (обычно внешний балансировщик).

Несколько control plane нод присоединяются командой kubeadm join --control-plane.

etcd может быть stacked (на тех же нодах) или external (отдельный кластер etcd).

Официально: Creating Highly Available Clusters with kubeadm

!Схема HA для kubeadm: endpoint API и варианты размещения etcd

Управление жизненным циклом kubeadm-кластера

#### Обновления

Обновление Kubernetes — это не только kubeadm upgrade. Важно соблюдать совместимость версий компонентов.

Типовая логика:

Планирование версии и чтение release notes.

Обновление control plane.

Поочередное обновление worker-нод с drain.

Официально: Upgrading kubeadm clusters

#### Резервное копирование etcd

Если вы управляете control plane сами, резервные копии etcd — критичны: etcd хранит состояние всех объектов.

Официально: Backing up an etcd cluster

#### Обслуживание нод: cordon и drain

cordon запрещает планирование новых Pod на ноду, drain дополнительно выселяет существующие Pods.

После обслуживания:

Официально: Safely Drain a Node

Практический чеклист: что уметь после этой статьи

Выбирать формат кластера: kind для лабораторий, managed для облака, kubeadm для on-prem.

Понимать, что CNI — обязательная часть кластера, а container runtime — основа запуска контейнеров.

Поднять kind-кластер, загрузить локальный образ и развернуть приложение.

Понимать границы ответственности в managed Kubernetes.

Описать шаги установки kubeadm и основные операции: init/join, установка CNI, базовое обслуживание нод и подход к обновлениям.

В следующих материалах курса логично переходить к практике работы с kubectl и манифестами в выбранном окружении (обычно kind или managed): создание Namespace, Deployment, Service, ConfigMap/Secret, probes и базовые политики доступа.

Workloads и управление приложениями: Pod, Deployment, Job, StatefulSet

После того как вы разобрались с архитектурой и объектной моделью Kubernetes и научились получать кластер (kind/managed/kubeadm), следующий практический шаг DevOps-инженера — уметь правильно выбирать и эксплуатировать workload-объекты.

Workloads отвечают на вопросы:

Как именно запускать контейнеры (сколько реплик, как обновлять, как восстанавливаться).

Как управлять жизненным циклом приложения (rolling update, rollback, завершение задач, стабильность идентичности).

Какие гарантии нужны (статус, готовность, последовательный старт, постоянное хранилище).

В этой статье мы разберем четыре ключевых workload-объекта, которые вы будете использовать чаще всего:

Pod — базовая единица запуска.

Deployment — стандарт для stateless-сервисов и API.

Job — пакетные задачи “до завершения”.

StatefulSet — stateful-системы с дисками и стабильной идентичностью.

!Карта того, кто кем управляет и какие гарантии дает

Общий принцип: желаемое состояние и контроллеры

Kubernetes почти всегда управляет приложением не напрямую, а через контроллер.

Вы описываете желаемое состояние в YAML (например, replicas: 3, image: nginx:1.27).

Kubernetes записывает это состояние в API.

Контроллеры в фоне приводят реальность к желаемому (создают/удаляют Pods, пересоздают упавшие, делают rollout).

Практический вывод:

Не создавайте “голые” Pods для сервисов в production: при падении такой Pod может не восстановиться так, как вы ожидаете, и нет стратегии обновления.

Для долгоживущих сервисов почти всегда нужен Deployment (stateless) или StatefulSet (stateful).

Официально: Workloads

Pod: минимальная единица запуска

Pod — это один или несколько контейнеров, которые:

разделяют один сетевой namespace (общий IP и порты Pod);

могут разделять общие volumes;

планируются на ноду как единое целое.

Официально: Pods

Когда Pod уместен

Отладка и эксперименты (kubectl run, временные манифесты).

Как “продукт” работы контроллеров (Deployment/Job/StatefulSet в итоге создают Pods).

В редких случаях — как часть инфраструктурного паттерна (например, static pods для control plane в некоторых установках).

Манифест Pod: пример

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

Что важно понимать про Pod в эксплуатации

Pod эфемерен: при пересоздании меняется IP и часто меняется нода.

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

Readiness/Liveness/Startup probes определяют, когда Pod принимать трафик и когда его перезапускать. Детально probes уже упоминались в статье про архитектуру, но в workloads это становится практикой.

Официально: Container Probes

Deployment: стандарт для stateless-приложений

Deployment — это контроллер, который управляет обновлениями и масштабированием приложения через ReplicaSet.

Deployment описывает что вы хотите: образ, количество реплик, стратегию обновления.

ReplicaSet обеспечивает сколько Pod должно существовать.

Официально: Deployments

Когда выбирать Deployment

HTTP API, frontend, воркеры без состояния.

Сервисы, где реплики взаимозаменяемы.

Все, что можно безопасно пересоздать на другой ноде.

Манифест Deployment: пример

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

replicas — желаемое число Pod.

selector — какие Pods принадлежат этому Deployment.

template — шаблон Pod, который будет размножаться.

Обновления: RollingUpdate и откаты

По умолчанию Deployment использует стратегию RollingUpdate.

Типичный жизненный цикл релиза:

Вы меняете image (например, nginx:1.27 на nginx:1.27.1).

Deployment создает новый ReplicaSet.

Постепенно поднимает новые Pods и убирает старые.

Если readiness не проходит, rollout может “застрять”.

Команды для управления rollout:

Официально: Rolling Updates

Стратегии обновления: RollingUpdate vs Recreate

| Стратегия | Как работает | Когда применять | |---|---|---| | RollingUpdate | Постепенная замена Pod | Почти всегда для stateless | | Recreate | Сначала убивает старые, потом создает новые | Если нельзя иметь две версии одновременно |

ReplicaSet: почему важно знать о нем

ReplicaSet редко создают руками, но он полезен при диагностике.

Если Deployment “не обновляется”, смотрите kubectl describe rs.

Если Pods не создаются, часто причина видна в событиях ReplicaSet.

Команды:

Job: задачи “выполни и заверши”

Job — это workload для конечных задач, где важен факт успешного завершения.

Job создает один или несколько Pod.

Job считается успешным, когда нужное число Pod завершилось со статусом Succeeded.

Официально: Jobs

Когда выбирать Job

Миграции БД.

Генерация отчетов.

Импорт/экспорт данных.

Batch-обработка.

Важные параметры Job

completions — сколько успешных завершений нужно.

parallelism — сколько Pod можно запускать одновременно.

backoffLimit — сколько раз можно перезапускать упавшие Pod, прежде чем Job станет failed.

Манифест Job: пример

Команды:

CronJob: Job по расписанию

Хотя статья сфокусирована на Job, на практике часто нужен CronJob.

CronJob создает Job по расписанию.

Используется для бэкапов и периодических задач.

Официально: CronJobs

StatefulSet: состояние, диски и стабильная идентичность

StatefulSet предназначен для приложений, где реплики не взаимозаменяемы.

StatefulSet обеспечивает:

Стабильные имена Pod: db-0, db-1, db-2.

Стабильные сетевые идентификаторы (обычно через headless Service).

Стабильные диски: каждый Pod получает свой PVC (обычно через volumeClaimTemplates).

Упорядоченное создание/удаление Pod (важно для кластерных БД).

Официально: StatefulSets

Когда выбирать StatefulSet

Базы данных и очереди: PostgreSQL, MySQL, Kafka, ZooKeeper, RabbitMQ (в зависимости от конкретной архитектуры).

Системы, где узлы кластера имеют роль/идентичность.

Сервисы, которым нужен отдельный persistent volume на реплику.

Headless Service: почти всегда нужен вместе со StatefulSet

Чтобы Pod имели предсказуемые DNS-имена, обычно создают headless Service:

Service с clusterIP: None.

DNS-имя вида db-0.db.default.svc.cluster.local.

Официально: Headless Services

Пример: Headless Service + StatefulSet

Что здесь происходит:

Service db headless нужен для стабильного DNS.

StatefulSet создает Pods db-0, db-1, db-2.

На каждый Pod создается свой PVC: data-db-0, data-db-1, data-db-2.

Проверка:

Обновления StatefulSet: аккуратнее, чем Deployment

StatefulSet тоже умеет обновления, но стратегия и риск отличаются:

StatefulSet по умолчанию обновляет Pods последовательно.

Для stateful-систем важно понимать протокол кластера: нельзя просто “покатить” новую версию без знания совместимости.

Официально: StatefulSet Update Strategies

!Сравнение порядка запуска и обновления у StatefulSet и Deployment

Как выбирать правильный workload: практическая таблица

| Задача | Рекомендуемый workload | Почему | |---|---|---| | Stateless API / web | Deployment | Rolling update, масштабирование, реплики взаимозаменяемы | | Одноразовая задача | Job | Нужно успешное завершение и ретраи | | Расписание (backup/cron) | CronJob | Регулярный запуск Job | | БД/кластер с дисками | StatefulSet | Идентичность, упорядоченность, отдельные PVC | | Отладка/временный запуск | Pod | Быстро и просто, но без гарантий управления |

Типовые ошибки DevOps и как их избегать

Использовать Pod вместо Deployment для сервиса

1. Симптом: приложение “пропадает” после эвикта/рестарта ноды. 2. Исправление: упаковать в Deployment, добавить readinessProbe, настроить стратегию обновления.

Путать readiness и liveness

1. Симптом: контейнер бесконечно перезапускается из-за liveness на медленном старте. 2. Исправление: использовать startupProbe для долгого старта, readiness — для включения в балансировку.

Запускать stateful-систему в Deployment

1. Симптом: потеря данных, конфликт реплик, “прыгающие” диски/идентичность. 2. Исправление: StatefulSet + PVC + (часто) headless Service.

Не задавать requests/limits

1. Симптом: непредсказуемое планирование, OOMKill, вытеснения. 2. Исправление: определить ресурсы и проверить QoS-поведение (это продолжим в следующих практиках про эксплуатацию).

Официально по ресурсам: Managing Resources for Containers

Минимальный практический сценарий после этой статьи

Рекомендуемый порядок практики в kind-кластере:

Развернуть Deployment, проверить rollout и rollback.

Добавить Service ClusterIP, проверить доступность через kubectl port-forward.

Запустить Job, посмотреть статусы Succeeded/Failed и поведение backoffLimit.

Развернуть StatefulSet с headless Service и убедиться, что:

- имена Pod стабильны; - PVC создаются по одному на Pod; - порядок создания последовательный.

В следующих материалах курса логично углубляться в сеть и доступ (Service/Ingress/DNS), конфигурацию (ConfigMap/Secret), а также в production-эксплуатацию (autoscaling, обновления нод, PDB, monitoring).

Сеть и доступ: Service, Ingress, DNS, NetworkPolicy, CNI

После статей про архитектуру, установку кластера и workloads вы уже умеете запускать приложения (Deployment, Job, StatefulSet). Теперь главный практический вопрос DevOps: как к этим Pod попасть и как ограничить сетевые взаимодействия безопасно и предсказуемо.

Kubernetes-сеть строится на нескольких слоях:

CNI дает Pod IP и связность Pod-to-Pod

Service дает стабильную точку доступа к группе Pod

DNS дает имена вместо IP и склеивает сервисы в систему

Ingress публикует HTTP/HTTPS наружу на уровне L7

NetworkPolicy ограничивает, кто с кем может общаться

!Сводная карта: CNI, Service, DNS и Ingress в одном рисунке

Модель сети Kubernetes: что должно работать всегда

У Kubernetes есть базовые требования к сети:

Каждый Pod получает свой IP

Pod на разных нодах должны уметь общаться напрямую без NAT между Pod

Ноды должны уметь общаться с Pod, и наоборот

Эта модель реализуется CNI-плагином.

Ссылки:

Сетевая модель Kubernetes

CNI (Container Network Interface)

CNI: как Pod получает IP и связность

CNI это стандарт и набор плагинов, которые Kubernetes использует для настройки сети Pod. На практике CNI отвечает за:

Выделение IP для Pod (IPAM)

Настройку интерфейсов и маршрутизации на ноде

Доставку трафика Pod-to-Pod между нодами

Иногда реализацию NetworkPolicy (зависит от плагина)

Популярные CNI и что от них ожидать

Calico: часто выбирают за зрелую реализацию NetworkPolicy и маршрутизацию

Cilium: eBPF-ориентированный стек, сильный в наблюдаемости и политиках

Flannel: простой вариант для базовой связности, часто без enforcement NetworkPolicy

Ссылки:

Calico Documentation

Cilium Documentation

Flannel Repository

Практический вывод для DevOps

Если вам нужны сетевые ограничения, заранее убедитесь, что ваш CNI поддерживает enforcement NetworkPolicy.

Диагностика сетевых проблем почти всегда начинается с проверки CNI-подов в kube-system и базовой DNS-резолюции.

Service: стабильный доступ к Pod

Pod эфемерен: пересоздается, меняет IP, переезжает на другую ноду. Service решает это, давая стабильную точку входа к группе Pod.

Service выбирает Pod по labels через selector.

Ссылка:

Service в Kubernetes

Как Service работает внутри

Ключевая идея:

Service имеет виртуальный IP (обычно ClusterIP)

Трафик на этот IP перенаправляется на реальные Pod IP

Реализация зависит от кластера, но классически за это отвечает kube-proxy (iptables или IPVS). В некоторых реализациях (например, с eBPF) роль kube-proxy может быть частично заменена.

Ссылка:

kube-proxy

Типы Service и когда их выбирать

| Тип | Доступ | Когда использовать | |---|---|---| | ClusterIP | Только внутри кластера | Почти всегда для связи сервис-сервис | | NodePort | Порт на каждой ноде | Быстрые тесты, kind, простые окружения | | LoadBalancer | Внешний LB от облака | Публикация сервиса наружу в облаке | | ExternalName | DNS-алиас на внешнее имя | Мягкая интеграция с внешними сервисами |

Пример: Service для Deployment

Предположим, у вас есть Deployment web с labels app: web. Тогда Service может выглядеть так:

Важно:

port это порт Service

targetPort это порт контейнера в Pod

Headless Service: Service без виртуального IP

Headless Service это Service с clusterIP: None. Он не делает балансировку через ClusterIP, а дает DNS-записи на конкретные Pod. Это ключевой компонент для StatefulSet.

Ссылка:

Headless Services

Пример:

EndpointSlice: куда Service реально ведет

Исторически Service опирался на объект Endpoints, но в современных кластерах используется EndpointSlice как более масштабируемая модель.

Ссылка:

EndpointSlices

Полезная диагностика:

Если Service не работает, очень часто причина в том, что EndpointSlice пустой, а значит selector не находит Pod или Pod не Ready.

DNS в Kubernetes: имена вместо IP

В кластере почти всегда работает CoreDNS, который отвечает за резолюцию:

имен Service

имен Pod (опционально и зависит от настроек)

Ссылка:

DNS for Services and Pods

Как выглядят DNS-имена Service

Полное имя обычно такое:

web.default.svc.cluster.local

Где:

web это имя Service

default это namespace

svc это зона сервисов

cluster.local это домен кластера (может быть другим)

Внутри Pod обычно настроены search domains, поэтому в том же namespace часто достаточно:

http://web

Быстрая проверка DNS изнутри кластера

Создать временный Pod и сделать запросы:

Если nslookup не работает:

проверьте Pod CoreDNS: kubectl get pods -n kube-system -l k8s-app=kube-dns

посмотрите логи: kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100

Ссылка:

CoreDNS

Ingress: публикация HTTP/HTTPS (L7)

Ingress это набор правил маршрутизации HTTP/HTTPS. Но сам по себе Ingress ничего не делает без Ingress Controller, который эти правила применяет.

Ссылка:

Ingress

Почему Ingress обычно лучше, чем Service типа LoadBalancer для каждого сервиса

Один Ingress Controller может обслуживать много приложений и доменов

Удобнее управлять TLS, редиректами, роутингом по host и path

Часто дешевле в облаке, чем множество L4 балансировщиков

Ingress Controller: что обычно используют

NGINX Ingress Controller

Traefik

Ссылки:

NGINX Ingress Controller

Traefik Kubernetes Ingress

Минимальный пример Ingress

Предположим, у вас есть Service web на 80 порту, и Ingress Controller уже установлен.

Практические замечания:

Для TLS обычно добавляют tls секцию и Secret с сертификатом

Для конкретного контроллера часто нужны аннотации, но переносимость между контроллерами ограничена

NetworkPolicy: сетевые ограничения между Pod

NetworkPolicy это объект, который описывает, какой трафик разрешен к Pod и от Pod. Это механизм реализации микросегментации и принципа наименьших привилегий.

Критически важно:

NetworkPolicy работает только если CNI поддерживает enforcement

Ссылка:

Network Policies

Ментальная модель NetworkPolicy

NetworkPolicy выбирает целевые Pod по podSelector и задает правила:

ingress: кто может приходить в эти Pod

egress: куда эти Pod могут ходить

Если в namespace есть хотя бы одна policy, которая выбирает Pod, и она ограничивает ingress или egress, то для выбранных Pod включается модель разрешено только явно указанное для соответствующего направления.

Базовый паттерн: default deny

Часто начинают с политики, которая запрещает все входящие подключения в namespace.

Что это означает:

podSelector: {} выбирает все Pod в namespace

policyTypes: Ingress включает контроль входящего трафика

Разрешающих правил нет, значит входящий трафик запрещен

Разрешить вход только от конкретного сервиса

Допустим:

app: api должен принимать трафик только от app: web на TCP 8080

Практический смысл:

В api нельзя стучаться из других Pod, кроме тех, у кого app: web

Даже curl из debug-пода без app: web будет блокироваться

!Иллюстрация того, как policy разрешает конкретный поток и блокирует остальные

Типовые ошибки при внедрении NetworkPolicy

Путают ограничения для Pod и Service: policy применяется к трафику к Pod, Service это только способ адресации

Не учитывают DNS: при жестком egress deny приложения могут перестать резолвить имена

Ожидают работу policy в кластере, где CNI не поддерживает enforcement

Практическая диагностика сетевых проблем

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

Проверить, что Pod вообще готов

Проверить Service и его endpoints

Частый симптом:

Service есть, но endpoints пустые

Типовые причины:

labels у Pod не совпали с selector Service

Pod не Ready из-за readinessProbe или ошибок старта

Проверить DNS

Проверить Ingress

Также почти всегда нужно смотреть логи Ingress Controller в его namespace.

Проверить NetworkPolicy

Если после включения policies внезапно все “сломалось”, чаще всего причина в том, что:

включили deny

забыли разрешить DNS и нужные направления

Что важно запомнить

CNI дает Pod IP и связность Pod-to-Pod, без него кластер функционально неполный

Service дает стабильную адресацию и балансировку к Pod

DNS в Kubernetes это основа сервис-дискавери, чаще всего через CoreDNS

Ingress это L7 публикация HTTP/HTTPS, но он требует Ingress Controller

NetworkPolicy это ключ к сетевой безопасности, но она зависит от возможностей CNI

Хранение и конфигурация: PV/PVC, StorageClass, ConfigMap, Secret

После того как вы научились поднимать кластер (kind/managed/kubeadm), запускать приложения (Deployment/Job/StatefulSet) и настраивать доступ (Service/Ingress/DNS/NetworkPolicy), неизбежно возникает следующий production-вопрос: где хранить данные и как безопасно/управляемо доставлять конфигурацию внутрь Pod.

В Kubernetes это решается двумя большими наборами объектов:

Хранение: Volumes, PV/PVC, StorageClass, CSI

Конфигурация: ConfigMap и Secret

Ключевая идея для DevOps: приложение должно быть пересоздаваемым, а данные и конфигурация должны жить вне контейнерного образа и управляться декларативно.

!Как PVC связывает Pod с реальным хранилищем через StorageClass и CSI

Базовые термины: Volume, persistent и ephemeral

Volume в Kubernetes — это способ подключить данные к контейнеру в Pod. Сами контейнеры по умолчанию имеют эфемерную файловую систему: при пересоздании Pod данные пропадают.

Типы данных по практическому смыслу:

Эфемерные данные: кэш, временные файлы, промежуточные артефакты

Персистентные данные: базы, очереди, хранилища, любые данные, которые должны пережить пересоздание Pod

В Kubernetes устойчивое хранение обычно строится через PersistentVolume (PV) и PersistentVolumeClaim (PVC).

Официально:

Volumes

Persistent Volumes

PersistentVolume и PersistentVolumeClaim: кто за что отвечает

PersistentVolume (PV)

PV — это ресурс кластера, представляющий конкретный кусок хранилища (например, облачный диск или NFS-том), доступный Kubernetes.

Характеристики PV, которые вы будете встречать чаще всего:

capacity: размер

accessModes: режим доступа

persistentVolumeReclaimPolicy: что делать с томом после освобождения

storageClassName: к какому классу хранилища относится PV

PersistentVolumeClaim (PVC)

PVC — это заявка от приложения на хранилище.

PVC обычно описывает:

сколько места нужно (resources.requests.storage)

какие режимы доступа нужны (accessModes)

какой класс хранилища нужен (storageClassName)

PVC создается в namespace приложения и затем подключается в Pod.

Ключевой ментальный переход:

PV — про инфраструктуру хранилища

PVC — про потребность приложения

Binding: как PVC находит PV

Когда вы создаете PVC, Kubernetes пытается привязать его к подходящему PV.

Варианты:

Статическое выделение: PV создан заранее, PVC его подбирает и связывается

Динамическое выделение: при создании PVC Kubernetes создает PV автоматически через StorageClass и CSI-драйвер

StorageClass: политика и автоматизация выделения томов

StorageClass описывает как именно выделять хранилище: какой тип диска, параметры, режим binding, поддержку расширения томов.

Официально:

Storage Classes

Типичные свойства StorageClass:

provisioner: какой драйвер выделяет том (обычно CSI)

parameters: параметры конкретного типа хранилища

reclaimPolicy: Delete или Retain

volumeBindingMode: когда привязывать том к ноде (важно для зональности)

allowVolumeExpansion: можно ли увеличивать PVC

Практика в managed-кластерах:

Обычно есть один или несколько StorageClass “из коробки” (например, SSD/HDD).

Практика в локальных кластерах:

В kind динамическое выделение томов может отсутствовать, и тогда ставят provisioner отдельно.

Частый выбор для лабораторий: local-path-provisioner.

CSI: как Kubernetes подключается к реальному хранилищу

CSI (Container Storage Interface) — стандарт, через который Kubernetes взаимодействует с внешними системами хранения (облака, SAN, Ceph, NFS-решения и т.д.).

Официально:

CSI Volumes

Практический вывод для DevOps:

Если “PVC не биндится” или “том не монтируется”, очень часто это проблема CSI-драйвера или отсутствия provisioner.

Практические режимы доступа и ограничения

accessModes

Самые распространенные режимы:

ReadWriteOnce (RWO): том можно монтировать на запись обычно на одну ноду

ReadOnlyMany (ROX): многим на чтение

ReadWriteMany (RWX): многим на запись (зависит от бэкенда)

Важно: accessModes — это не “права Linux”, а ограничения хранилища и драйвера.

Reclaim policy: что будет после удаления PVC

Политики:

Delete: после удаления PVC underlying-том удаляется (часто по умолчанию в облаках)

Retain: PV остается, данные сохраняются, требуется ручная уборка/перепривязка

Официально:

Reclaim Policy

Минимальный пример: PVC и использование в Deployment

PVC

Deployment, который монтирует PVC

Диагностика:

Типовые статусы:

PVC Pending: не найден подходящий PV и не сработало динамическое выделение

PVC Bound: PVC привязан к PV

StatefulSet и volumeClaimTemplates: правильный путь для stateful

Из предыдущей статьи про workloads: StatefulSet дает стабильную идентичность реплик. Для дисков это дополняется механизмом volumeClaimTemplates.

Ключевой смысл:

на каждый Pod sts-name-0, sts-name-1 создается свой PVC

Официально:

StatefulSets

Частые проблемы с PV/PVC и как их диагностировать

PVC в статусе Pending

Частые причины:

нет StorageClass с таким именем

нет default StorageClass

не установлен CSI/provisioner

требуемый accessModes не поддерживается

volumeBindingMode и топология (зоны/ноды) мешают выделению

Практический алгоритм:

kubectl describe pvc <name> и посмотреть events

kubectl get storageclass

kubectl get pods -n kube-system и проверить компоненты CSI/provisioner

Pod не стартует из-за проблем с томом

Симптомы часто видны в:

kubectl describe pod <pod> в events

Триггеры:

ошибка attach/mount

нехватка прав у ноды в облаке

конфликт режимов доступа

ConfigMap: доставка некритичной конфигурации

ConfigMap хранит конфигурационные данные (переменные окружения, конфиги приложений), которые не являются секретами.

Официально:

ConfigMaps

Способы использовать ConfigMap

Основные способы:

как переменные окружения (через env или envFrom)

как файлы (монтирование ConfigMap как volume)

Пример ConfigMap

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

Важное эксплуатационное поведение:

если ConfigMap поменять, переменные окружения в уже запущенном Pod не обновятся автоматически

чаще всего нужен rollout (перезапуск Pod) через Deployment

ConfigMap как файлы

Поведение обновлений:

при изменении ConfigMap смонтированные файлы обычно обновляются (с задержкой)

приложение может потребовать reload (это зависит от приложения)

Дополнительно (важно для production): можно сделать ConfigMap неизменяемым через immutable: true, если вы деплоите новую версию конфигурации новым именем и хотите защититься от случайных изменений.

Официально:

Immutable ConfigMaps and Secrets

!Два основных способа внедрения конфигурации и их поведение при обновлении

Secret: доставка чувствительных данных

Secret предназначен для хранения чувствительных данных: паролей, токенов, ключей, TLS-сертификатов.

Официально:

Secrets

Важное предупреждение

Secret в Kubernetes по умолчанию:

хранится в etcd

в YAML представляется как base64

Base64 — это кодирование, а не шифрование.

Рекомендации DevOps-уровня:

включать шифрование данных Secret в etcd на уровне API Server

ограничивать доступ через RBAC

не логировать значения секретов и не прокидывать их в CI логи

Официально про шифрование:

Encrypting Secret Data at Rest

Пример Secret (Opaque)

Практическая заметка:

stringData удобен для записи “как есть”; Kubernetes сам преобразует в data (base64)

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

Риск: переменные окружения проще “утекают” в дампы и диагностику приложений. Часто предпочтительнее монтировать Secret как файл.

Secret как файл

TLS Secret и Ingress

Из статьи про Ingress: для HTTPS обычно нужен Secret типа TLS.

Официально:

TLS Secrets

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

Практические паттерны эксплуатации конфигурации

Не менять конфиг “вживую” без стратегии

Для управляемости релизов удобно:

выпускать новую версию ConfigMap/Secret (новое имя)

обновлять Deployment/StatefulSet так, чтобы он “подхватил” новую версию

Преимущество:

проще откатываться

Rollout при изменении ConfigMap/Secret

Kubernetes не делает автоматический rollout Deployment при изменении ConfigMap/Secret. На практике это решают инструментами доставки (Helm/Kustomize/GitOps), которые изменяют шаблон Pod (например, добавляют аннотацию с хэшем конфигурации), из-за чего меняется spec.template и начинается rollout.

Что важно запомнить

PV — ресурс кластера, PVC — запрос приложения

StorageClass и CSI — основа динамического выделения томов

У томов важны accessModes и reclaimPolicy (Delete/Retain)

ConfigMap для некритичной конфигурации, Secret для чувствительных данных

Secret по умолчанию не “зашифрован”, а только base64-кодирован; безопасность обеспечивают RBAC и шифрование at-rest

В следующих материалах курса обычно переходят к эксплуатационным темам: autoscaling, обновления, PDB, мониторинг, логирование и политика безопасности workloads, чтобы связать хранение/конфигурацию с надежностью и управляемостью production-систем.

Безопасность и мультиарендность: RBAC, PSP replacements, OPA, Pod Security

Безопасность Kubernetes для DevOps инженера начинается не с отдельных YAML, а с модели доверия: кто может вызывать Kubernetes API, что именно им разрешено, какие ограничения применяются к Pod при создании, и как гарантировать, что разные команды или сервисы не мешают друг другу в одном кластере.

Связь с предыдущими статьями курса:

В статье про архитектуру мы разбирали, что kube-apiserver и admission это центральная точка контроля.

В статье про workloads мы запускали Deployment/StatefulSet и поняли, что Pod пересоздаются контроллерами, значит безопасность должна быть декларативной и автоматической.

В статье про сеть мы увидели, что NetworkPolicy ограничивает трафик, но не заменяет RBAC и политики Pod.

В статье про Secret/ConfigMap мы обсудили, что Secret это не шифрование по умолчанию, и доступ к ним должен контролироваться.

В этой статье соберем практическую картину Kubernetes security и multi-tenancy:

RBAC: авторизация на уровне Kubernetes API

Pod Security: базовая защита Pod через встроенный admission

PSP replacements: чем заменили PodSecurityPolicy

OPA Gatekeeper: политики как код и кастомные запреты/валидации

!Диаграмма слоев контроля: RBAC и admission до создания объектов, NetworkPolicy после

Мультиарендность в Kubernetes: что это и зачем

Мультиарендность это ситуация, когда один кластер используется несколькими командами, окружениями или даже клиентами. Цели:

изоляция изменений и доступа

ограничение blast radius при ошибках

соблюдение требований безопасности

В Kubernetes мультиарендность чаще всего строится из комбинации:

Namespace как административная граница

RBAC как контроль доступа к API

Pod Security и политики admission как контроль того, какие Pods можно запускать

NetworkPolicy как изоляция сетевого трафика

квоты и лимиты (ResourceQuota, LimitRange) как изоляция ресурсов

Официально: Multi-tenancy

Важно помнить:

Namespace сам по себе не является полноценной security-границей

без RBAC любой, кто имеет доступ к API, сможет влиять на ресурсы других

без Pod security политики арендатор может запустить привилегированный Pod и атаковать ноду

RBAC: контроль доступа к Kubernetes API

RBAC отвечает на вопрос: кто и что может делать в Kubernetes API. RBAC не про сетевой трафик и не про Linux-права внутри контейнера, а про операции вида:

get/list/watch Pods

create/update/patch/delete Deployments

create Secrets

exec в Pod

Официально: Using RBAC Authorization

Термины RBAC

Subject: кому выдаем права

- User (внешний пользователь) - Group (группа) - ServiceAccount (идентичность для Pod)

Role: набор прав внутри namespace

ClusterRole: набор прав на уровне кластера (или для выдачи в namespace)

RoleBinding: привязка Role или ClusterRole к subject в namespace

ClusterRoleBinding: привязка ClusterRole к subject на уровне кластера

Практический принцип: least privilege

Least privilege означает: выдавать минимальные права, необходимые для работы.

Типовые ошибки:

давать cluster-admin “временно” и забывать

давать права на secrets шире, чем нужно

разрешать pods/exec всем разработчикам (это почти всегда доступ к данным и токенам внутри Pod)

Пример: роль для чтения ресурсов в namespace

Ниже Role, которая разрешает читать Pods и их логи в конкретном namespace.

RoleBinding, который выдает эту роль ServiceAccount:

ServiceAccount: идентичность Pod

ServiceAccount это учетная запись для процессов внутри Pod. Если Pod имеет токен ServiceAccount и этот аккаунт привязан RBAC-правами, то приложение может вызывать Kubernetes API.

Официально: ServiceAccounts

Практический минимум для production:

создавать отдельный ServiceAccount под каждое приложение

запрещать автоподстановку токена там, где он не нужен

Пример:

Если приложению действительно нужен доступ к API, включайте токен точечно на Pod-уровне.

Как проверять права: kubectl auth can-i

Проверка, может ли текущий пользователь выполнять действие:

Полезно для отладки RBAC в CI и при инцидентах.

Официально: kubectl auth can-i

PodSecurityPolicy устарел: что произошло и почему

PodSecurityPolicy (PSP) был механизмом контроля безопасности Pod через admission, но он оказался сложным в эксплуатации и был удален.

PSP был объявлен устаревшим и затем удален из Kubernetes

вместо PSP Kubernetes предлагает более простую встроенную модель, а для сложных правил рекомендуют policy engines

Официально: PodSecurityPolicy

Практический вывод:

если вы видите старые инструкции с PSP, воспринимайте их как исторический контекст

в новых кластерах делайте ставку на Pod Security Admission и, при необходимости, на OPA Gatekeeper или Kyverno

Pod Security: стандарты и встроенный admission

Kubernetes предлагает базовые уровни безопасности Pod через два элемента:

Pod Security Standards: модель уровней безопасности

Pod Security Admission (PSA): встроенный admission контроллер, который применяет эти уровни

Официально:

Pod Security Standards

Pod Security Admission

Уровни Pod Security Standards

Pod Security Standards определяют три профиля:

privileged: почти без ограничений

baseline: блокирует очевидно опасные настройки, но совместим со многими приложениями

restricted: самый строгий профиль, ориентирован на сильную изоляцию

Эти профили в основном проверяют такие вещи:

запуск от root и возможности Linux (capabilities)

hostNetwork, hostPID, hostIPC

privileged containers

монтирование опасных volume типов

seccomp профиль

Как включать Pod Security Admission

PSA применяют обычно на уровне namespace через labels. Есть три режима применения:

enforce: запрещает создать Pod, если нарушает правила

audit: позволяет создать Pod, но пишет событие для аудита

warn: позволяет создать Pod, но показывает предупреждение клиенту

Пример: включить строгий режим restricted для namespace app.

Если вы внедряете политики постепенно, удобная стратегия:

поставить warn и audit

исправить манифесты

включить enforce

Что нужно изменить в манифестах для restricted

Ниже типовой пример Pod-спека, который ближе к restricted-профилю.

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

seccompProfile: RuntimeDefault включает дефолтный seccomp-профиль ноды

allowPrivilegeEscalation: false запрещает эскалацию привилегий

runAsNonRoot: true требует запуск не под root

capabilities.drop: ["ALL"] убирает дополнительные Linux capabilities

PSP replacements: чем дополнять Pod Security

Pod Security Admission хорошо закрывает базовые сценарии, но у него есть ограничения:

он не умеет произвольные кастомные правила уровня “только такой registry” или “обязателен label owner”

он не делает мутацию (например, автоматически проставить runAsNonRoot), он в основном валидирует

Поэтому в production часто добавляют policy engine.

Основные варианты

| Подход | Что делает | Сильные стороны | Ограничения | |---|---|---|---| | Pod Security Admission | Встроенные профили privileged/baseline/restricted | Нативно, просто, предсказуемо | Только набор стандартных проверок | | OPA Gatekeeper | Кастомные правила на Rego и Constraints | Очень гибко, хорошо для compliance | Требует разработки и поддержки политики | | Kyverno | Политики на YAML, валидация и мутация | Удобно DevOps-командам, меньше кода | Не все сценарии так же выразимы, как Rego | | Validating Admission Policy | Нативные CEL-политики | Меньше внешних компонентов | Не замена полноценным policy engine |

Ссылки:

OPA Gatekeeper

Kyverno

Validating Admission Policy

OPA Gatekeeper: политики как код для Kubernetes

OPA (Open Policy Agent) это движок политик, а Gatekeeper это его реализация для Kubernetes admission.

Модель Gatekeeper:

вы описываете шаблон политики как ConstraintTemplate

затем создаете конкретные Constraint с параметрами

Gatekeeper валидирует ресурсы при создании и обновлении

Когда Gatekeeper особенно полезен

запрет образов не из разрешенных registry

требование конкретных labels/annotations

запрет latest тега

запрет HostPath, hostNetwork, privileged вне отдельных namespace

контроль допустимых storageClassName

Пример: запрет privileged контейнеров

Ниже показан упрощенный пример структуры. В реальном кластере вы обычно берете проверенные политики из внутреннего каталога или community наборов и адаптируете.

ConstraintTemplate:

Constraint:

Практические замечания:

лучше матчить не только Pod, но и Deployment/StatefulSet/Job, потому что в production вы создаете не Pod напрямую

нужно продумать исключения для системных namespace (kube-system) и инфраструктурных компонентов

Pod Security и мультиарендность: типовая стратегия внедрения

Ниже практический план, который хорошо ложится на реальную эксплуатацию.

Определить модель арендаторов

- namespace на команду или на окружение - отдельные ServiceAccount для приложений

Включить базовые границы

- RBAC на namespace - NetworkPolicy default deny (из прошлой статьи) и разрешающие правила

Включить Pod Security Admission

- начать с warn и audit - затем перейти к enforce на baseline или restricted

Добавить Gatekeeper для кастомных требований

- registry allowlist - запрет latest - обязательные labels

Встроить проверки в CI

- kubectl auth can-i для проверки прав - dry-run apply и policy check в staging

Практические грабли и диагностика

Ошибка: приложение перестало деплоиться после включения Pod Security

Типовые причины:

контейнер запускается под root

отсутствует securityContext

используются запрещенные настройки, например hostNetwork

Диагностика:

Ошибка: сервис внутри Pod не может читать Secret

Типовые причины:

ServiceAccount не имеет прав на secrets

Secret в другом namespace

Диагностика:

Ошибка: разработчики могут делать exec в любые Pod

pods/exec это отдельный ресурс RBAC. Проверьте, нет ли роли вида edit или кастомной роли, которая включает pods/exec слишком широко.

Официально про API ресурсы: RBAC Authorization

Что важно запомнить

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

PodSecurityPolicy это устаревший механизм, в новых кластерах ориентируйтесь на Pod Security Admission

Pod Security Standards дают понятные уровни безопасности, которые удобно раскатывать через warn/audit/enforce

OPA Gatekeeper закрывает кастомные требования compliance и политики организации

Сильная мультиарендность достигается комбинацией: Namespace + RBAC + Pod Security + NetworkPolicy + квоты ресурсов

Продакшн-эксплуатация: мониторинг, логирование, autoscaling, upgrades, backup, GitOps

В предыдущих статьях курса вы разобрали архитектуру Kubernetes, научились поднимать кластеры (kind/managed/kubeadm), запускать workloads (Deployment/Job/StatefulSet), настраивать сеть (Service/Ingress/DNS/NetworkPolicy) и вводить базовую безопасность (RBAC/Pod Security/OPA).

Теперь перейдем к тому, что отличает работающий в демо кластер от управляемого в production: наблюдаемость, логирование, масштабирование, безопасные обновления, резервное копирование и GitOps.

Цель DevOps на этом этапе: сделать систему измеримой, предсказуемой и восстанавливаемой.

!Карта основных продакшн-практик и инструментов вокруг кластера

Наблюдаемость: что именно нужно видеть в production

Наблюдаемость (observability) в Kubernetes обычно делят на три сигнала.

Метрики: численные ряды во времени (CPU, latency, RPS).

Логи: текстовые события (stdout/stderr, системные логи).

Трейсы: цепочки вызовов между сервисами (распределенная трассировка).

Отдельно (и очень практично) стоит выделять:

События Kubernetes (Events): причины рестартов, scheduling, проблемы с volume.

Практический принцип:

Метрики отвечают на вопрос что деградирует и насколько.

Логи отвечают на вопрос почему это произошло.

Трейсы отвечают на вопрос где именно в цепочке запросов проблема.

Мониторинг метрик: Prometheus-стек и что в нем важно

Базовые компоненты мониторинга

Наиболее распространенный вариант в Kubernetes — экосистема Prometheus.

Prometheus: сбор и хранение метрик, PromQL.

Alertmanager: маршрутизация алертов (Slack, email, PagerDuty).

Grafana: дашборды.

kube-state-metrics: метрики из объектов Kubernetes (Deployment/Pod/Node статусы).

node-exporter: метрики нод (CPU, memory, disk, network).

Ссылки:

Prometheus

Alertmanager

Grafana

kube-state-metrics

Метрики приложений и метрики платформы

В production полезно разделять два мира.

Метрики платформы: состояние кластера, нод, API server, kubelet, CNI.

Метрики приложений: RPS, error rate, p95 latency, business-метрики.

Чтобы приложение было мониторируемым, оно обычно экспортирует метрики (часто на /metrics) в формате Prometheus.

Официально про инструменты мониторинга в Kubernetes:

Tools for Monitoring Resources

Metrics Server: обязательный минимум для HPA

Если вы планируете HPA по CPU/памяти, вам почти всегда нужен Metrics Server.

Metrics Server собирает краткоживущие resource-метрики (CPU/memory) для Kubernetes.

Эти метрики используются HPA.

Ссылка:

Metrics Server

Практическая связка с предыдущими статьями:

Без корректных requests/limits (из статьи про архитектуру и планирование) autoscaling и стабильность будут непредсказуемыми.

Подход к алертингу: что алертить в первую очередь

Чтобы не утонуть в алертах, начинайте с небольшого набора.

Доступность API и состояние нод.

Доля ошибок и p95/p99 latency на входных сервисах.

Перезапуски контейнеров и рост CrashLoopBackOff.

Нехватка ресурсов: CPU throttling, OOMKills, заполнение дисков.

Проблемы с PV/PVC (Pending, mount errors).

Официально по отладке кластерных проблем:

Debugging Kubernetes

Логирование: от stdout контейнера до централизованного поиска

Контейнерные логи в Kubernetes: базовая модель

В Kubernetes “правильные” логи приложения обычно пишутся в stdout/stderr.

kubelet и container runtime сохраняют эти логи на ноде.

дальше их нужно собрать и отправить в централизованное хранилище.

Официально:

Logging Architecture

Типовая архитектура: агент на ноде (DaemonSet)

Обычно на каждую ноду ставят log collector как DaemonSet.

Fluent Bit: легкий сборщик/парсер/форвардер.

Fluentd: более тяжелый, но тоже распространен.

Vector: популярный современный агент.

Ссылки:

Fluent Bit

Fluentd

Vector

Куда складывать логи: Loki или Elastic

Два частых подхода.

Grafana Loki: оптимизирован под логи, удобная интеграция с Grafana.

Elastic Stack (Elasticsearch): мощный поиск и аналитика, выше стоимость владения.

Ссылки:

Grafana Loki

Elastic Stack

Практические правила продакшн-логирования

Не логируйте секреты: это связано со статьей про Secret и RBAC.

Добавляйте корреляционные поля: request_id, trace_id, service, env.

Настройте ретеншн и лимиты: логи способны “съесть” бюджет и диски.

Учитывайте multi-tenancy: ограничивайте доступ к логам (RBAC в системе логов и в Kubernetes).

Трейсинг: когда без него уже нельзя

Distributed tracing особенно полезен в микросервисах.

Он показывает путь запроса через несколько сервисов.

Позволяет найти “узкое место” без догадок.

Современная практика — OpenTelemetry.

Инструментирование приложений.

Экспорт трейсов в Jaeger/Tempo/другие бэкенды.

Ссылки:

OpenTelemetry

Jaeger

Autoscaling: HPA, VPA и масштабирование кластера

Горизонтальное масштабирование Pod: HPA

HPA (HorizontalPodAutoscaler) увеличивает или уменьшает число реплик Deployment/StatefulSet на основе метрик.

Чаще всего начинают с CPU utilization.

В более зрелых системах используют пользовательские метрики (RPS, очередь, latency).

Официально:

Horizontal Pod Autoscaling

Ключевой момент из предыдущих статей:

Scheduler и HPA опираются на requests. Если requests занижены или отсутствуют, HPA и планирование будут давать неожиданные эффекты.

Вертикальное масштабирование Pod: VPA

VPA (VerticalPodAutoscaler) подбирает requests/limits на основе наблюдений.

Может рекомендовать значения или применять их.

Применение часто требует пересоздания Pod.

Официально:

Vertical Pod Autoscaling

Практическое правило:

HPA и VPA могут конфликтовать, если оба пытаются активно менять ресурсы и реплики. Обычно требуется продуманная стратегия.

Масштабирование нод: Cluster Autoscaler

Cluster Autoscaler добавляет/удаляет ноды, если:

Pod некуда запланировать (нет ресурсов или constraints).

есть пустующие ноды, которые можно удалить.

Официально:

Cluster Autoscaler

В managed-кластерах (EKS/GKE/AKS) Cluster Autoscaler обычно интегрируется с node pools.

Event-driven autoscaling: KEDA

Если вы масштабируете воркеры по длине очереди, Kafka lag, метрикам Prometheus и т.д., удобна KEDA.

Она умеет включать масштабирование от внешних событий.

Ссылка:

KEDA

Обновления (upgrades): как обновлять кластер и не “уронить” прод

Обновления Kubernetes — это регулярная операционная практика, а не разовая акция.

Важный принцип: версия и совместимость

Kubernetes имеет правила совместимости между компонентами (control plane, kubelet, kubectl).

Перед апгрейдом всегда проверяйте поддерживаемый “skew” версий.

Официально:

Kubernetes Version Skew Policy

Стратегия обновления: control plane и ноды

Типовая безопасная последовательность.

Прочитать release notes целевой версии и список breaking changes.

Обновить control plane.

Обновить add-ons, зависящие от версии (CNI, CoreDNS, Ingress Controller, CSI).

Поочередно обновлять worker-ноды.

Для kubeadm это напрямую связано с предыдущей статьей про установку.

Upgrading kubeadm clusters

Обслуживание ноды: cordon, drain, uncordon

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

cordon запрещает новые Pod.

drain выселяет Pod (кроме DaemonSet) и дает контроллерам пересоздать их на других нодах.

Официально:

Safely Drain a Node

PDB: как защититься от массовой потери реплик при drain

PodDisruptionBudget (PDB) задает, сколько Pod можно “потерять” при добровольных disruptions (drain, обновления).

Это особенно важно для Deployment с небольшой репликацией.

Официально:

Pod Disruption Budgets

Практическая связка:

PDB работает вместе с readinessProbe (из workloads): Pod должен быть Ready, чтобы считаться доступным.

Backup и восстановление: etcd, ресурсы и данные

Backup в Kubernetes состоит из нескольких разных “слоев”, и их нельзя путать.

Backup состояния кластера: etcd

Если вы управляете control plane сами (kubeadm), etcd — критическая точка.

etcd хранит состояние объектов Kubernetes.

бэкап etcd позволяет восстановить “API-состояние” (манифесты, статусы, конфигурации).

Официально:

Backing up an etcd cluster

В managed Kubernetes control plane и etcd обычно обслуживает провайдер, но вам все равно нужны:

бэкапы приложенческих данных (PV).

GitOps как “backup манифестов”.

Backup ресурсов и PV: Velero

Velero делает бэкап Kubernetes-ресурсов и (в зависимости от провайдера и настроек) снапшоты томов.

Ссылка:

Velero

Важно понимать различие:

Backup ресурсов: YAML-объекты в API (Namespace, Deployment, Service и т.д.).

Backup данных: содержимое PV (снапшоты или файловый бэкап).

Практический план восстановления (DR)

Чтобы бэкап имел смысл, нужен проверяемый план восстановления.

Определить RPO и RTO.

- RPO: сколько данных можно потерять. - RTO: за сколько нужно восстановиться.

Документировать процедуру восстановления для критичных систем.

Регулярно проводить тестовые восстановления в отдельной среде.

GitOps: доставка изменений через Git как источник истины

Что такое GitOps в контексте Kubernetes

GitOps — подход, при котором:

Git — источник истины для желаемого состояния.

контроллер в кластере сам синхронизирует фактическое состояние с Git.

На практике это дает:

воспроизводимость окружений.

аудит изменений (кто/что/когда).

упрощение rollback.

Официально (с точки зрения Kubernetes-экосистемы):

CNCF: Flux

Argo CD

!Поток доставки изменений GitOps и цикл reconcile

Инструменты GitOps: Argo CD и Flux

Argo CD: UI-ориентированный GitOps-контроллер, удобен для команд и визуального контроля синхронизации.

Flux: GitOps-набор контроллеров, сильный в автоматизации и “компонентном” подходе.

Оба инструмента реализуют один и тот же принцип: непрерывное сравнение desired и actual.

Что хранить в Git

Типовой минимум.

Namespaces, RBAC, NetworkPolicy, Pod Security labels.

Workloads (Deployment/StatefulSet/Job/CronJob).

Services/Ingress.

ConfigMap (если не содержит секретов).

Для Secret есть варианты.

Хранить в внешнем secret manager и подтягивать в кластер.

Использовать шифрование секретов в Git (например, SOPS) и расшифровку на стороне контроллера.

Ссылка (про SOPS):

Mozilla SOPS

Разделение репозиториев: app vs platform

В продакшене удобно разделять.

Platform repo: базовые компоненты кластера (ingress controller, monitoring stack, policies).

App repo: манифесты приложения.

Это напрямую связано с мультиарендностью из статьи про безопасность: разные команды, разные права доступа, разный жизненный цикл.

Практические чеклисты production-эксплуатации

Минимальный чеклист наблюдаемости

Метрики кластера и нод собраны.

Метрики приложений доступны и имеют базовые дашборды.

Алерты покрывают доступность и деградацию.

Логи централизованы и есть поиск по namespace, pod, container.

Минимальный чеклист масштабирования

У workloads заданы requests/limits.

HPA включен для ключевых stateless-сервисов.

Cluster Autoscaler (или аналог провайдера) настроен для node pools.

Минимальный чеклист апгрейдов

Есть staging-кластер или тестовая среда.

Есть окно обновления и план отката.

PDB настроены для критичных сервисов.

drain используется при обслуживании нод.

Минимальный чеклист backup

Понятно, что является источником истины: GitOps для манифестов.

Для данных определена стратегия: снапшоты/бэкапы PV.

Проводятся тестовые восстановления.

Что важно запомнить

Production Kubernetes требует day-2 практик: мониторинг, логи, алерты, масштабирование, обновления, backup и управляемая доставка.

Autoscaling невозможен без аккуратных requests/limits и понимания поведения workloads.

Обновления делаются по плану, с учетом совместимости версий, с использованием drain и PDB.

Backup — это не “одна кнопка”: отдельно бэкапятся состояние (etcd/ресурсы) и данные (PV).

GitOps превращает кластер в управляемую систему: Git как источник истины и reconcile-контроллер в кластере.