Kubernetes перестает выглядеть хаотичным, когда его объекты начинают читаться как модель того, как приложение живет, падает и обновляется в кластере.
Для реальных проектных решений глава помогает увидеть, как workload-объекты, scheduling, сеть, storage, requests/limits, probes и rollout-стратегии надо связывать с SLO конкретного сервиса, а не настраивать как набор независимых галочек.
Для интервью и инженерных разборов она полезна тем, что помогает честно показывать границу между тем, где Kubernetes дает контроль и масштабируемость, и тем, где он создает лишнюю платформенную сложность.
Практическая польза главы
Практика проектирования
Связывайте workload-объекты, scheduling и сетевую модель кластера с SLO конкретного сервиса.
Качество решений
Проектируйте limits/requests, probes и rollout-стратегии как базовые guardrails надежности.
Interview articulation
Поясняйте, как control plane, data plane и namespace boundaries работают вместе в production.
Trade-off framing
Подчеркивайте, где Kubernetes дает масштабируемость, а где создает избыточную операционную сложность.
Official docs
Kubernetes Documentation
Официальный источник по архитектуре, объектам, сетям, storage и операционным практикам.
Kubernetes — система оркестрации контейнеров для автоматизации deployment, scaling и эксплуатации приложений. Базовая идея Kubernetes: описываешь желаемое состояние через API-объекты, а control plane через reconciliation loop приводит кластер к этому состоянию.
Актуальная версия и контекст
Docs channel
Latest docs: v1.35
По состоянию на 10 февраля 2026 в official docs текущая ветка отмечена как v1.35.
Latest release
Kubernetes v1.35.0
Релиз 1.35.0 опубликован 17 декабря 2025 на официальной странице релизов.
Практическое правило
Всегда сверяй версию docs
API и поведение могут отличаться между minor-версиями, поэтому проверяй docs selector.
High-Level Architecture
В Kubernetes control plane управляет состоянием, scheduler выбирает ноды для Pod'ов, kubelet исполняет workload на нодах, а Service/Ingress (или Gateway API) обеспечивает стабильный сетевой доступ.
Вертикальная схема показывает путь сверху вниз: API-запросы попадают в control plane, scheduler/controllers размещают и синхронизируют workload, а worker-ноды исполняют Pods и отправляют статус обратно в контур reconciliation.
Основные API-объекты
Namespace
Логическое разделение кластера для команд, окружений и quota/policy-границ.
Pod
Минимальная deployable единица: один или несколько тесно связанных контейнеров.
Deployment
Декларативный rollout/rollback stateless workload'ов через ReplicaSet.
Service
Стабильная точка доступа и service discovery поверх динамичных Pod IP.
ConfigMap & Secret
Внешняя конфигурация и чувствительные данные вне container image.
PersistentVolume & PVC
Абстракция хранилища и декларативный запрос volume для stateful приложений.
Workload primitives: что когда использовать
| Primitive | Best fit | Почему |
|---|---|---|
| Deployment | stateless web/API | rolling updates, rollback, auto-healing реплик |
| StatefulSet | stateful systems (DB, brokers) | stable identity, ordered rollout, volume per replica |
| DaemonSet | node-level agents | один Pod на ноду: logging, metrics, security agents |
| Job / CronJob | batch workloads | run-to-completion задачи и периодические джобы |
Сеть и трафик
Service как базовый вход
Service дает стабильный endpoint поверх Pod'ов и обеспечивает service discovery. Для внешнего трафика обычно используют Ingress Controller или Gateway API.
Ingress статус в docs
В official docs Ingress отмечен как frozen: новые фичи развиваются в Gateway API. Для новых платформ это важный архитектурный ориентир.
Storage и stateful-нагрузки
- PersistentVolume описывает реальный volume-ресурс в кластере или cloud backend.
- PersistentVolumeClaim — декларативный запрос хранилища приложением.
- StorageClass + dynamic provisioning позволяют автоматически выделять тома.
- Для stateful систем чаще используют связку StatefulSet + PVC per replica.
Security минимум
Доступ и идентичность
Базовый контур: authentication + authorization + admission control и RBAC. Namespace boundaries и ServiceAccount дают рабочую модель прав на старте.
Секреты и supply chain
Secrets не должны жить в образах и git; добавляй ротацию, external secret manager и сканирование контейнерных образов в CI/CD pipeline.
Day 1 / Day 2 checklist
- Day 1: определить namespace strategy, resource requests/limits и network policy baseline.
- Day 1: договориться о rollout-политике (rolling/canary/blue-green) и health probes.
- Day 2: добавить HPA/VPA (или cluster autoscaling), чтобы связывать load и capacity.
- Day 2: обеспечить observability по четырем сигналам: logs, metrics, traces, events.
- Day 2: ревизия RBAC, Secrets management и supply-chain сканирование образов.
Официальные материалы
Связанные главы
- Зачем знать Cloud Native и 12 факторов - Контекст роли Kubernetes в платформенной архитектуре и операционной модели cloud-native систем.
- Контейнеризация - Фундамент для понимания runtime-изоляции, образов и жизненного цикла контейнеров в кластере.
- Kubernetes Patterns (short summary) - Практический каталог production-паттернов: probes, sidecar, operator-подход и rollout-стратегии.
- Service Mesh Architecture - Как управлять service-to-service коммуникацией, mTLS и traffic policy поверх Kubernetes workloads.
- CKA: подготовка к экзамену - Практический трек по ключевым навыкам эксплуатации Kubernetes в формате задач и troubleshooting.
- Identity, Authentication and Authorization - База по AuthN/AuthZ для RBAC, ServiceAccount, policy enforcement и security boundary в кластере.
- Designing Distributed Systems (short summary) - Архитектурные паттерны распределённых систем, которые часто реализуются и автоматизируются через Kubernetes.