Зачем нужен Kubernetes
Какую задачу он решает и почему без него это делает дежурный ночью.
Задача
Допустим, приложение живёт в контейнерах на нескольких машинах. Нужно, чтобы:
- при падении ноды его экземпляры поднялись на другой;
- при росте нагрузки экземпляров стало больше;
- при выкате новой версии старая уходила постепенно, без простоя;
- трафик шёл только на те экземпляры, которые готовы отвечать.
Всё это можно делать руками. Проблема в том, что делать это придётся в три часа ночи.
Желаемое состояние
Kubernetes работает не по командам, а по описанию желаемого состояния. Вы не говорите «запусти контейнер» — вы говорите «должно быть три реплики вот такого приложения». Дальше кластер сам сравнивает желаемое с фактическим и устраняет разницу.
Умерла нода — реплик стало две, кластер поднимает третью в другом месте. Никто никого не будит.
Это же объясняет, почему kubectl delete pod часто «не работает»: под удаляется, контроллер видит нехватку и создаёт новый. Чтобы под исчез, нужно менять желаемое состояние, а не бороться со следствием.
Основные объекты
| Объект | Что описывает |
|---|---|
| Pod | один или несколько контейнеров, запускаемых вместе |
| Deployment | сколько реплик Pod нужно и как их обновлять |
| Service | стабильный адрес для группы подов |
| ConfigMap / Secret | конфигурация и секреты отдельно от образа |
| Ingress | как трафик снаружи попадает в Service |
Почему Pod, а не контейнер
Pod — минимальная единица планирования. Обычно в нём один контейнер, но иногда несколько: контейнеры одного Pod делят сетевое пространство (общаются через localhost) и могут делить тома. Это нужно для вспомогательных процессов рядом с основным — сборщика логов, прокси.
Планировщик размещает Pod целиком на одной ноде. Контейнеры одного Pod не окажутся на разных машинах.
Первое знакомство
kubectl get pods -o wide # что запущено и где
kubectl describe pod <name> # подробности и события внизу
kubectl logs <name> -f # логи
kubectl get events --sort-by=.lastTimestamp
describe — самая полезная команда при разборе: секция Events внизу почти всегда содержит причину проблемы обычным текстом.
Когда он не нужен
Kubernetes добавляет заметный слой сложности. Для одного приложения на одном сервере docker compose и systemd решают задачу лучше. Смысл появляется там, где машин несколько и падения — рутина, а не событие.