Кластер перестает выглядеть хаотичным, когда его объекты начинают читаться как модель того, как приложение живет, падает и обновляется.
Для реальных проектных решений глава помогает увидеть, как объекты рабочих нагрузок, планирование размещения, сеть, хранилища, запросы и лимиты ресурсов, проверки готовности и стратегии поэтапного запуска надо связывать с целевым уровнем сервиса, а не настраивать как набор независимых галочек.
Для интервью и инженерных разборов она полезна тем, что помогает честно показывать границу между тем, где платформа дает контроль и масштабируемость, и тем, где она создает лишнюю операционную сложность.
Практическая польза главы
Практика проектирования
Связывайте объекты рабочих нагрузок, планирование размещения и сетевую модель кластера с целевым уровнем сервиса.
Качество решений
Проектируйте запросы ресурсов, лимиты, проверки готовности и стратегии поэтапного запуска как базовые защитные ограничения надёжности.
Аргументация на интервью
Поясняйте, как контур управления, рабочие узлы и границы пространств имён работают вместе в промышленной среде.
Формулировка компромиссов
Подчеркивайте, где платформа дает масштабируемость, а где создает избыточную операционную сложность.
Official docs
Kubernetes Documentation
Официальный источник по архитектуре, объектам, сетям, хранилищам и операционным практикам.
оркестрирует контейнеры: принимает описание , хранит его как API-объекты и через постепенно приводит кластер к этому состоянию. Главная идея не в «магическом деплое», а в постоянном между тем, что описала команда, и тем, что реально запущено на рабочих узлах.
Актуальная версия и контекст
Ветка документации
Документация v1.36
По состоянию на 11 мая 2026 официальная документация проекта отмечает v1.36 как текущую ветку.
Последний релиз
Kubernetes v1.36.0
Релиз 1.36.0 опубликован 22 апреля 2026 на официальной странице релизов.
Практическое правило
Всегда сверяй версию документации
API и поведение могут отличаться между minor-версиями, поэтому проверяй переключатель версии документации.
Высокоуровневая архитектура
В кластере хранит и согласует состояние, выбирает рабочие узлы для 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
Минимальная единица запуска: один или несколько тесно связанных контейнеров с общим сетевым контуром.
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. Для новых платформ это важный ориентир при выборе входного слоя.
Хранилище и приложения с состоянием
- описывает реальный ресурс хранилища в кластере или облачном провайдере.
- — это декларативная заявка приложения на хранилище.
- и позволяют создавать диски автоматически.
- Для систем с состоянием чаще используют связку StatefulSet и на каждую реплику.
Минимум безопасности
Доступ и идентичность
Базовый контур: аутентификация, авторизация, и . Пространства имён и дают рабочую модель прав на старте.
Секреты и цепочка поставки
Секреты не должны жить в образах и Git. Добавляй ротацию, внешний менеджер секретов и контейнерных образов в CI/CD.
Чек-лист первого запуска и эксплуатации
- Первый запуск: определить стратегию , , и базовую .
- Первый запуск: договориться о политике и проверках готовности, активности и запуска.
- Эксплуатация: добавить , или , чтобы связать фактическую нагрузку и планирование ёмкости.
- Эксплуатация: обеспечить наблюдаемость по логам, метрикам, трассировкам и событиям кластера.
- Эксплуатация: регулярно пересматривать , и контейнерных образов.
Источники
Связанные главы
- Зачем знать Cloud Native и 12 факторов - Контекст роли кластера в облачно-ориентированной архитектуре и операционной модели.
- Контейнеризация - Фундамент для понимания контейнерной среды выполнения, образов и жизненного цикла контейнеров в кластере.
- Kubernetes Patterns (short summary) - Практический каталог паттернов для проверок готовности, sidecar, операторов и стратегий поэтапного запуска.
- Архитектура сервисной сетки (service mesh) - Как управлять межсервисным трафиком, взаимной TLS-аутентификацией и политиками маршрутизации поверх платформы.
- CKA: подготовка к экзамену - Практический трек по ключевым навыкам эксплуатации кластера, задачам в терминале и диагностике неполадок.
- Identity, Authentication and Authorization - База по аутентификации, авторизации, ролевой модели доступа, сервисным учётным записям, политикам допуска и границам безопасности в кластере.
- Designing Distributed Systems (short summary) - Архитектурные паттерны распределённых систем, которые часто реализуются и автоматизируются через платформенный слой.