Кластер перестает выглядеть хаотичным, когда его объекты начинают читаться как модель того, как приложение живет, падает и обновляется.
Для реальных проектных решений глава помогает увидеть, как объекты рабочих нагрузок, планирование размещения, сеть, хранилища, запросы и лимиты ресурсов, проверки готовности и стратегии поэтапного запуска надо связывать с целевым уровнем сервиса, а не настраивать как набор независимых галочек.
Для интервью и инженерных разборов она полезна тем, что помогает честно показывать границу между тем, где платформа дает контроль и масштабируемость, и тем, где она создает лишнюю операционную сложность.
Практическая польза главы
Практика проектирования
Связывайте объекты рабочих нагрузок, планирование размещения и сетевую модель кластера с целевым уровнем сервиса.
Качество решений
Проектируйте запросы ресурсов, лимиты, проверки готовности и стратегии поэтапного запуска как базовые защитные ограничения надёжности.
Аргументация на интервью
Поясняйте, как контур управления, рабочие узлы и границы пространств имён работают вместе в промышленной среде.
Формулировка компромиссов
Подчеркивайте, где платформа дает масштабируемость, а где создает избыточную операционную сложность.
Official docs
Kubernetes Documentation
Официальный источник по архитектуре, объектам, сетям, хранилищам и операционным практикам.
оркестрирует контейнеры: принимает описание , хранит его как API-объекты и через постепенно приводит кластер к этому состоянию. Главная идея не в «магическом деплое», а в постоянном между тем, что описала команда, и тем, что реально запущено на рабочих узлах.
Актуальная версия и контекст
Ветка документации
Документация v1.36
По состоянию на 11 мая 2026 официальная документация проекта отмечает v1.36 как текущую ветку.
Последний релиз
Kubernetes v1.36.0
Релиз 1.36.0 опубликован 22 апреля 2026 на официальной странице релизов.
Практическое правило
Всегда сверяй версию документации
Между минорными версиями программный интерфейс (API) и поведение объектов меняются, поэтому совет из чужой статьи легко даёт не тот результат на твоём кластере. Сначала проверь переключатель версии в документации.
Высокоуровневая архитектура
В кластере хранит и согласует состояние, выбирает рабочие узлы для Pod, kubelet запускает контейнеры, а Service, входящий трафик (Ingress) или Gateway API дают стабильный сетевой доступ.
Клиенты
kubectl, CI и операторы платформы
Контур управления
принимает намерение, хранит состояние и запускает циклы согласования
API-сервер
API, допуск, RBAC
etcd
состояние кластера
планировщик
Pod → узел
менеджер контроллеров
циклы согласования
доступ и допуск
аутентификация, авторизация, политики
облачный контроллер
интеграция с провайдером
Рабочие узлы
запускают контейнеры и отправляют статусы обратно
Узел A
Узел B
Стабильный вход и маршрутизация
Service / Ingress / Gateway API
стабильный адрес, обнаружение сервисов и внешний вход к Pod
Обратная связь
сигналы работоспособности, готовности и фактическое состояние возвращаются в API
Читайте схему слева направо: клиенты описывают желаемое состояние, контур управления принимает и согласует его, рабочие узлы запускают Pod, а сервисный слой даёт стабильный сетевой доступ.
Основные API-объекты
Namespace
разделяет кластер для команд, окружений, квот ресурсов и политик доступа.
Pod
Минимальная единица запуска: один или несколько тесно связанных контейнеров с общим сетевым контуром. Планировщик размещает не отдельный контейнер, а Pod целиком — это и определяет, что упадёт и поднимется вместе.
Deployment
Управляет ReplicaSet, Pod и поддерживает для сервисов .
Service
Даёт стабильную точку доступа к динамичным Pod и включает внутри кластера.
ConfigMap & Secret
Выносит конфигурацию и чувствительные данные за пределы .
PersistentVolume & PVC
Связывает с для систем .
Объекты рабочих нагрузок: что когда использовать
| Объект | Где подходит | Почему |
|---|---|---|
| Deployment | Web/API | , , реплик |
| StatefulSet | Базы данных, брокеры и другие системы | стабильная идентичность, упорядоченный поэтапный запуск, том на каждую реплику — без этого база с состоянием теряет данные при перепланировании |
| DaemonSet | Агенты на уровне | один Pod на каждый рабочий узел: сбор логов, метрик и сигналы безопасности |
| Job / CronJob | Пакетные и периодические задачи | и запуск по расписанию |
Сеть и трафик
Service как базовая точка входа
Service даёт стабильный адрес поверх Pod и обеспечивает . Для внешнего трафика обычно используют или Gateway API.
Статус входящего трафика (Ingress) в документации
В официальной документации входящий трафик (Ingress) отмечен как frozen: новые возможности развиваются только в Gateway API. На практике это значит, что новую платформу разумнее строить сразу на Gateway API — иначе через год придётся мигрировать слой входящего трафика ради функций, которых в Ingress уже не будет.
Хранилище и приложения с состоянием
- описывает реальный ресурс хранилища в кластере или облачном провайдере.
- — это декларативная заявка приложения на хранилище.
- и позволяют создавать диски автоматически.
- Для систем с состоянием чаще используют связку StatefulSet и на каждую реплику — так данные переживают перезапуск и перепланирование Pod.
Минимум безопасности
Доступ и идентичность
Базовый контур: аутентификация, авторизация, и . Пространства имён и дают рабочую модель прав на старте — пропустишь её, и любой Pod в кластере по умолчанию получит больше прав, чем ему нужно.
Секреты и цепочка поставки
Секрет, попавший в образ или Git, остаётся в истории навсегда и утекает вместе с ней. Поэтому держи секреты снаружи: ротация, внешний менеджер секретов и контейнерных образов в конвейере CI/CD.
Чек-лист первого запуска и эксплуатации
- Первый запуск: определить стратегию , , и базовую .
- Первый запуск: договориться о политике и проверках готовности, активности и запуска.
- Эксплуатация: добавить , или , чтобы связать фактическую нагрузку и планирование ёмкости.
- Эксплуатация: обеспечить наблюдаемость по логам, метрикам, трассировкам и событиям кластера.
- Эксплуатация: регулярно пересматривать , и контейнерных образов.
Источники
Связанные главы
- Зачем знать Cloud Native и 12 факторов - Контекст роли кластера в облачно-ориентированной архитектуре и операционной модели.
- Контейнеризация - Слой под платформой Kubernetes: без понимания среды выполнения, образов и жизненного цикла контейнера поведение Pod в кластере остаётся магией.
- Kubernetes Patterns (short summary) - Практический каталог паттернов для проверок готовности, sidecar, операторов и стратегий поэтапного запуска.
- Архитектура сервисной сетки (service mesh) - Когда сервисов становится много, базовых Service и Ingress для входящего трафика уже не хватает: сюда стоит идти за управлением межсервисным трафиком, взаимной аутентификацией на базе протокола защиты транспортного уровня (mTLS) и политиками маршрутизации поверх платформы.
- CKA: подготовка к экзамену - Практический трек по ключевым навыкам эксплуатации кластера, задачам в терминале и диагностике неполадок.
- Identity, Authentication and Authorization - База по аутентификации, авторизации, ролевой модели доступа, сервисным учётным записям, политикам допуска и границам безопасности в кластере.
- Designing Distributed Systems (short summary) - Архитектурные паттерны распределённых систем, которые часто реализуются и автоматизируются через платформенный слой.