Kubernetes
| Тип | система оркестрации контейнеров |
|---|---|
| Разработчик | Google, затем Cloud Native Computing Foundation (CNCF) |
| Анонс | июнь 2014 |
| Версия 1.0 | июль 2015 |
| Язык | Go |
| Лицензия | Apache 2.0 |
| Цикл выпусков | три минорные версии в год |
| Предшественник | Borg (внутренняя система Google) |
| Сайт | kubernetes.io |
Kubernetes (от греч. κυβερνήτης — «кормчий», «рулевой»; сокращённо K8s — между «K» и «s» восемь букв) — открытая платформа для оркестрации контейнеров. Kubernetes управляет кластером из многих машин как единым ресурсом: решает, на каком узле запустить контейнер, перезапускает упавшие, распределяет трафик, масштабирует приложения под нагрузку и обновляет их без простоя. Пользователь описывает желаемое состояние — «три копии этого сервиса, доступные по такому адресу», — а Kubernetes непрерывно приводит к нему фактическое.[1]
Kubernetes — стандарт индустрии для запуска контейнерных приложений: управляемые кластеры предлагают все крупные облака, а для небольших установок есть облегчённые дистрибутивы.
История
В Google больше десяти лет работала внутренняя система управления кластерами Borg, запускавшая практически все сервисы компании.[4] В 2014 году инженеры Google — Джо Беда, Брендан Бёрнс и Крейг Маклаки — представили открытый проект, вобравший опыт Borg и его преемника Omega. Версия 1.0 вышла в июле 2015 года, и одновременно Google передала проект новой организации Cloud Native Computing Foundation (CNCF) при Linux Foundation; в 2018 году Kubernetes стал первым «выпускником» CNCF.[7]
Новая минорная версия выходит примерно три раза в год, каждая поддерживается около 14 месяцев.[3] В версии 1.24 (2022) была удалена встроенная прослойка для Docker (dockershim): кластеры работают с containerd или CRI-O через интерфейс CRI, а образы, собранные Docker, по-прежнему совместимы благодаря стандарту OCI.[5]
Архитектура
Кластер состоит из управляющего слоя (control plane) и рабочих узлов (nodes):[2]
| Компонент | Где | Роль |
|---|---|---|
| kube-apiserver | control plane | единая точка входа: REST API для всех операций |
| etcd | control plane | распределённое хранилище ключ-значение с состоянием кластера |
| kube-scheduler | control plane | выбирает узел для каждого нового пода |
| kube-controller-manager | control plane | контроллеры, приводящие состояние к желаемому |
| kubelet | каждый узел | запускает контейнеры подов через среду выполнения |
| kube-proxy | каждый узел | сетевые правила для сервисов |
| Среда выполнения | каждый узел | containerd или CRI-O |
Ключевая идея — цикл согласования (reconciliation loop): контроллеры постоянно сравнивают желаемое состояние, записанное в etcd, с фактическим и устраняют расхождения. Если узел выходит из строя, контроллер замечает нехватку копий и создаёт их на других узлах.
Основные объекты
Все ресурсы описываются как объекты API, обычно в YAML-манифестах:[6]
- Pod — минимальная единица запуска: один или несколько контейнеров с общей сетью и томами.
- Deployment — поддерживает заданное число одинаковых подов и выполняет плавные обновления с возможностью отката.
- Service — стабильный адрес и балансировка для набора подов; Ingress и Gateway API — маршрутизация внешнего HTTP-трафика.
- ConfigMap и Secret — конфигурация и секреты отдельно от образа.
- PersistentVolume — постоянное хранилище для баз данных и файлов.
- Namespace — логическое разделение кластера между командами и окружениями.
- StatefulSet, DaemonSet, Job, CronJob — приложения с состоянием, агенты на каждом узле, разовые и периодические задачи.
Пример манифеста
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels: {app: web}
template:
metadata:
labels: {app: web}
spec:
containers:
- name: web
image: ghcr.io/example/web:1.4.2
ports: [{containerPort: 8000}]
resources:
requests: {cpu: 100m, memory: 128Mi}
limits: {memory: 256Mi}
readinessProbe:
httpGet: {path: /health, port: 8000}
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector: {app: web}
ports: [{port: 80, targetPort: 8000}]
kubectl apply -f web.yaml # создать или обновить объекты
kubectl get pods -l app=web # поды приложения
kubectl rollout status deployment/web # ход обновления
kubectl logs -f deployment/web # логи
kubectl scale deployment/web --replicas=5
Работа с кластером ведётся утилитой kubectl; приложения из многих манифестов упаковывают в чарты Helm.
Расширяемость
Kubernetes расширяется через собственные типы ресурсов (CRD) и операторы — контроллеры, которые автоматизируют эксплуатацию сложных систем вроде PostgreSQL или Kafka. Сеть подключается через плагины CNI, хранилища — через CSI. Количество подов может меняться автоматически по нагрузке (HPA).
Когда Kubernetes не нужен
Kubernetes сложен в установке и сопровождении. Для одного сервера и нескольких сервисов обычно достаточно Docker Compose, а для простых веб-приложений — PaaS или бессерверных платформ. Кластер оправдан, когда много сервисов и команд, нужна отказоустойчивость, автоматическое масштабирование и единый способ развёртывания. Для небольших кластеров и периферийных устройств есть облегчённые дистрибутивы — k3s, k0s, MicroK8s, — а для локальной разработки — kind и minikube.
См. также
Источники
- Kubernetes Documentation — Overview
- Kubernetes Documentation — Kubernetes Components
- Kubernetes — Releases
- Verma et al. — Large-scale cluster management at Google with Borg (EuroSys 2015)
- Kubernetes Documentation — Migrating from dockershim
- Kubernetes Documentation — Objects in Kubernetes
- CNCF — Kubernetes project