Что такое Kubernetes
Kubernetes (часто пишут K8s — восемь букв между K и s) — это система оркестрации контейнеров с открытым исходным кодом. В одну строку: вы описываете в YAML, какое состояние приложения хотите видеть в кластере, а Kubernetes непрерывно приводит реальность к этому описанию. Когда узел падает, Kubernetes перезапускает Pod на другом. Когда трафик растёт, Kubernetes масштабирует количество реплик. Когда вы выкатываете новую версию, Kubernetes делает rolling update с проверкой здоровья. Это очень короткий ответ, но он скрывает контролируемую сложность, к которой мы будем возвращаться все 20 модулей курса.
Краткая история: от Borg к Kubernetes
В Google с начала 2000-х работала внутренняя система оркестрации Borg. Borg запускал почти все сервисы Google — поиск, Gmail, YouTube — на десятках тысяч машин. Сотрудники, чьи поды (тогда они назывались allocs) падали в три часа ночи, начали накапливать опыт: что работает, что нет, какие абстракции масштабируются на 100k узлов, какие нет.
В 2013 году Google запустил преемника — Omega, переосмысление Borg с lock-free scheduler и общим оптимистичным state store. Omega так и не стал основной системой production, но дал команде понимание, какую архитектуру стоит публиковать наружу.
В июне 2014 года Google открыл исходный код Kubernetes (греч. kybernetes — «кормчий», «рулевой»). С самого начала проект был open-source, написан на Go, и спроектирован с учётом всех уроков Borg/Omega: декларативная модель (вы описываете что, а не как), reconcile loops (контроллеры непрерывно сравнивают желаемое и реальное), API-first архитектура (всё проходит через kube-apiserver).
В июле 2015 года вышел Kubernetes v1.0, и в тот же день Google вместе с Linux Foundation объявили о создании CNCF (Cloud Native Computing Foundation). Kubernetes стал первым (seed) проектом фонда. В августе 2018 года Kubernetes получил статус graduated в CNCF — это высшая зрелость проекта, означающая production-ready использование и устойчивое сообщество поддержки.
Сегодня (на май 2026) Kubernetes — фактический стандарт оркестрации контейнеров. Он работает в каждом крупном облаке как managed-сервис (EKS, GKE, AKS, Yandex MK), в private cloud (OpenShift, Rancher), и на лаптопах разработчиков (kind, minikube, k3d).
Что Kubernetes решает
Представьте, что у вас 200 контейнеров на 30 виртуальных машинах. Без оркестратора вам придётся вручную решать:
- На какой ВМ запустить новый контейнер? У какой больше свободной памяти?
- Что делать, когда ВМ падает? Кто перезапустит контейнеры на других машинах?
- Как 10 экземпляров одного сервиса найдут друг друга и balance traffic между собой?
- Как выкатить новую версию без downtime?
- Как зафиксировать «должно быть 5 реплик», чтобы система сама держала это число при падениях?
- Как роллбекнуть деплой, когда что-то пошло не так?
Это и есть оркестрация. Kubernetes реализует её через декларативную модель: вы описываете желаемое состояние (desired state) в YAML или JSON, отправляете в кластер, и набор контроллеров непрерывно сравнивает это с реальным состоянием (actual state), внося изменения для устранения разницы. Этот цикл называется reconcile loop — он повторяется бесконечно, пока живёт ваш объект.
Декларативность отличает Kubernetes от bash-скриптов и Ansible-плейбуков. В скрипте вы пишете «сделать X, потом Y». В Kubernetes вы пишете «должно быть 5 реплик такого Pod», и не заботитесь, как именно система этого достигнет — создаст новые, удалит лишние, переместит на другой узел при падении.
Концептуальная модель кластера
Сначала запомним базовые сущности. Дальше в курсе мы разберём каждую до уровня исходного кода, но сейчас — обзорная карта.
Каждый объект в Kubernetes — это запись в etcd (распределённое key-value хранилище), описывающая желаемое состояние. Когда вы делаете kubectl apply -f deployment.yaml, kubectl отправляет YAML на kube-apiserver, тот валидирует, конвертирует во внутренний формат, и записывает в etcd. Дальше в работу включаются контроллеры — каждый следит за своим типом объектов и приводит реальность к описанию.
Например, при создании Deployment последовательно срабатывают:
- Deployment controller видит новый Deployment и создаёт ReplicaSet.
- ReplicaSet controller видит, что нужно 3 Pod-а, а есть 0, и создаёт 3 Pod-объекта.
- Scheduler видит Pod-ы без
spec.nodeNameи подбирает им узлы. - kubelet на каждом выбранном узле видит «свой» Pod и просит container runtime его запустить.
Всё это — независимые reconcile loops. Они не вызывают друг друга напрямую — каждый смотрит на состояние в etcd через kube-apiserver и реагирует.
Зачем нужен Docker Compose: от контейнеров к сервисам
Декларативность против docker-compose
Если вы работали с docker-compose, у вас может возникнуть вопрос: разве docker-compose не делает то же самое? Вы описываете сервисы в YAML, запускаете docker compose up, получаете контейнеры. Разница принципиальная.
| Аспект | docker-compose | Kubernetes |
|---|---|---|
| Имеет state-store | Нет, всё на одной машине | etcd — распределённое хранилище |
| Reconciliation | Только при up | Непрерывно, всегда |
| Self-healing | Только restart: always для контейнера | Полное: упал Pod — пересоздаётся, упал узел — Pod переедет |
| Multi-host | Нет (Swarm — отдельно) | Изначально multi-host |
| Service discovery | DNS внутри сети | DNS + Services + Endpoints + headless |
| Rolling updates | Нет встроенных | Deployment делает это автоматически |
| Resource scheduling | Нет | Scheduler с фильтрами и приоритетами |
| API | CLI-only | REST API + watch streams + RBAC |
docker-compose — отличный инструмент для локальной разработки и простых однонодовых развёртываний. Kubernetes — это инфраструктура для production-кластера, где десятки узлов и сотни сервисов должны работать с минимальным human intervention.
Чем Kubernetes НЕ является
Распространённое заблуждение — что Kubernetes делает «всё». Уточним границы:
- Kubernetes — не PaaS (Platform-as-a-Service). Он не предоставляет middleware вроде баз данных или message queues. Heroku/Cloud Foundry — PaaS. Kubernetes — фундамент, на котором можно построить PaaS (OpenShift это и делает).
- Kubernetes — не serverless. Lambda/Cloud Run сами решают, когда запускать функцию по событию. Kubernetes запускает то, что вы описали в манифесте. Knative и OpenFaaS добавляют serverless поверх K8s, но это дополнительные слои.
- Kubernetes — не container runtime. Он не запускает контейнеры сам. Этим занимается containerd, CRI-O или (исторически) Docker shim. Kubernetes говорит с runtime через CRI (Container Runtime Interface) — gRPC API.
- Kubernetes — не build-система. Он не собирает образы. Этим занимаются Docker, Buildah, Kaniko, BuildKit. Kubernetes только запускает уже собранные образы из registry.
- Kubernetes — не CI/CD. Он не делает деплой по push в git. Этим занимаются Argo CD, Flux, Jenkins, GitHub Actions — они вызывают Kubernetes API.
- Kubernetes — не monitoring. Он не показывает дашборды и не шлёт алерты. Этим занимаются Prometheus, Grafana, Loki, OpenTelemetry — они работают в Kubernetes как обычные workloads.
- Kubernetes — не messaging system. Kafka, NATS, RabbitMQ — отдельные системы, которые работают в K8s, но не часть его.
Понимание этих границ важно: на CKAD вас не спросят про Kafka tuning, но спросят, как правильно деплоить Kafka StatefulSet с PersistentVolumeClaim и headless Service.
Хорошая ментальная модель: Kubernetes — это операционная система для кластера. Как Linux абстрагирует процессы и память от железа, так Kubernetes абстрагирует workloads и сети от конкретных машин. Всё остальное — приложения, работающие на этой ОС.
Что дальше
В следующем уроке посмотрим, когда Kubernetes уместен, а когда — оверкилл. После — формат CKAD-экзамена. Затем — версионирование, релиз-цикл и API-эволюция, чтобы понимать, какие фичи на каком кластере будут работать.