Разбираем Kubernetes для начинающих: 4 сущности и цена

Kubernetes — программа-диспетчер, которая следит за вашими контейнерами на одном или нескольких серверах: перезапускает упавшие, раскатывает новую версию без простоя и добавляет копии при росте нагрузки. Вы описываете в текстовом файле желаемое состояние («три копии приложения, каждой по 512 МБ памяти»), а Kubernetes приводит реальность к этому описанию. Работает он поверх обычных машин — подойдёт пара серверов из каталога VPS с Linux, если хватает ядер и памяти. И сразу главная мысль: большинству проектов он не нужен.

Материал для тех, кто умеет запускать приложение в контейнере и слышит от коллег «пора в куб», но не понимает, что это даёт и во что обойдётся. Разберём четыре базовые сущности, посчитаем расход ресурсов на сам кластер, сравним его с docker compose, поднимем учебный стенд за семь шагов и разберём типовые ошибки.

Что такое Kubernetes простыми словами и какую задачу он решает

Контейнер — упакованное со всеми библиотеками приложение, которое запускается одной командой на любом сервере с Linux. Пока контейнер один, им управляет человек: запустил, посмотрел логи, перезапустил после сбоя. Проблемы начинаются, когда контейнеров двадцать, а серверов четыре.

Ручное управление ломается на трёх вещах. Контейнер упал ночью — никто не узнал до утра. Выкатили битую версию — откат занял 40 минут ручной работы. В пятницу пришёл трафик — поднять ещё три копии некому.

Kubernetes закрывает ровно эти три дыры. Он опрашивает контейнеры и, если приложение перестало отвечать, убивает его и поднимает заново — обычно за 10–30 секунд. Обновление делает поэтапно: поднял новую копию, дождался ответа, погасил старую, повторил. Если новая версия не стартует, выкатка останавливается сама, а откат делается одной командой.

«Оркестратор» означает именно это: не «запустить контейнер», а «поддерживать нужное число работающих контейнеров на группе серверов без участия человека». Kubernetes не заменяет Docker, а надстраивается над ним: образы собираются теми же средствами.

Четыре сущности, которых хватит на старте: под, деплоймент, сервис, ингресс

В Kubernetes десятки типов объектов, но для первого приложения нужны четыре. Все они описываются файлами в формате YAML — обычный текст с отступами, где вложенность обозначается двумя пробелами.

Под (pod) — минимальная единица запуска: один или несколько контейнеров, которые живут на одном сервере и делят общий сетевой адрес. В 90% случаев в поде один контейнер. Под одноразовый: он умирает вместе с сервером и сам не воскресает, поэтому вручную поды почти не создают.

Деплоймент (deployment) — описание желаемого состояния: «нужно 3 пода с таким-то образом версии 1.4». Деплоймент следит, чтобы подов всегда было три, умеет пошагово менять версию образа и откатывать её. Это основной объект на каждый день.

Сервис (service) — стабильная точка доступа. Поды пересоздаются и меняют адреса, а сервис даёт одно неизменное имя внутри кластера, за которым прячется список живых подов. Соседнее приложение обращается к имени и переживает перезапуски.

Ингресс (ingress) — вход снаружи: правило вида «запросы на shop.example.com отдавай сервису shop». Работает через обратный прокси внутри кластера — программу, которая принимает запросы снаружи и раздаёт их нужным сервисам. Обычно это nginx или Traefik; он же занимается сертификатами HTTPS на портах 80/TCP и 443/TCP.

Что Kubernetes делает сам, а что всё равно останется на вас

Новички ждут от кластера больше, чем он даёт. Полезно развести две колонки: что автоматизировано и что строится руками поверх.

Автоматизировано: перезапуск упавших подов за 10–30 секунд, распределение их по серверам с учётом свободной памяти, поэтапная выкатка и откат одной командой. Сюда же — переезд подов с выбывшей машины на живые за 1–5 минут и изменение числа копий по загрузке процессора. Это ядро, ради которого всё затевается.

Остаётся на вас: сборка образов, хранение секретов, резервные копии баз, обновление кластера пару раз в год, сеть, хранилища и мониторинг. Отдельная боль — состояние: базы данных живут в кластере хуже приложений, потому что диск привязан к серверу, и переезд пода ломает привязку. Обычный компромисс — держать базу на отдельной машине.

Сколько ресурсов кластер съедает на самого себя

Из-за этого пункта чаще всего разочаровываются. Kubernetes — не тонкая прослойка: служебные компоненты работают постоянно и занимают ощутимую долю сервера ещё до запуска первого приложения.

Кластер делится на два типа узлов. Управляющий хранит состояние кластера и принимает решения; ему нужно минимум 2 ядра и 2 ГБ памяти — и это планка для учебного стенда, а не для боевой нагрузки. Рабочий узел запускает поды, ему хватит 1 ядра и 1 ГБ. На одной машине роли совмещаются, но приложениям остаётся меньше половины ресурсов.

На сервере с 2 ядрами и 2 ГБ после установки полного Kubernetes свободными остаются 800 МБ–1 ГБ. Сборка k3s экономичнее: служебная часть укладывается в 300–500 МБ. Разница в 500–700 МБ на машине за 100–200 ₽/мес — это половина полезной ёмкости.

Kubernetes против docker compose: сравнение по деньгам и времени

Docker compose — один файл с перечнем контейнеров приложения и их связей плюс одна команда, которая всё это поднимает. Работает на одном сервере, ничего не знает про кластеры и не переезжает при отказе машины. Зато понятен за вечер и почти ничего не ест.

Сравнивать их по «мощности» бессмысленно — разный класс задач. Считать надо цену владения: сколько нужно серверов, сколько времени уйдёт на освоение и сколько часов в месяц заберёт поддержка.

Ключевая строка — «минимум серверов». Отказоустойчивый кластер не бывает из одной машины: выключился единственный управляющий узел — кластер перестал принимать решения. Честный старт — три узла, то есть три счёта вместо одного.

Когда Kubernetes не нужен, а когда начинает окупаться

Признак простой: если всё держится на одном сервере и вас это устраивает, кластер не улучшит ситуацию, а размажет её на три машины. Ниже — четыре случая, где он только добавит расходов.

Одно-два приложения: сайт плюс база, бот плюс очередь, API плюс кэш. Здесь Docker и compose-файл покрывают такое целиком, хватит сервера за 59–200 ₽/мес. Редкие релизы: если обновление выходит раз в месяц и 10 минут ночного простоя никого не расстроят, поэтапная выкатка не нужна.

Некому вести кластер: обновления версий и разбор странных состояний подов требуют регулярного внимания. Нагрузка в основном на базу: Kubernetes хорошо управляет приложениями без состояния и плохо — данными на диске.

Обратная сторона — четыре признака, при которых он экономит больше, чем стоит. Много сервисов: когда приложений десять и больше, ручной учёт «что где запущено» съедает часы. Частые релизы: несколько выкаток в день без простоя руками не делаются.

Требование к доступности: если час простоя стоит денег, нужен автоматический переезд подов. Команда из нескольких разработчиков: кластер даёт единый способ выкатки и разграничение прав.

Если ни один из этих признаков не про вас — откладывайте Kubernetes и возвращайтесь к нему через год.

Лёгкие сборки для одного сервера: k3s и minikube

Полный Kubernetes состоит из нескольких компонентов, которые надо связать между собой. Для учёбы и небольших задач есть упрощённые сборки, совместимые по командам.

k3s — тот же Kubernetes, собранный в один исполняемый файл размером около 70 МБ. Редко нужные части выброшены, вместо тяжёлого хранилища состояния используется встроенная база SQLite, ингресс идёт в комплекте. Ставится одной командой примерно за минуту и работает на машине с 1 ядром и 1 ГБ памяти. Для одного-двух серверов это разумный выбор и в боевой работе.

minikube — учебный кластер внутри виртуальной машины на вашем ноутбуке. Для боевой работы не годится: ест 2 ГБ памяти и не показывает сетевых проблем между узлами. Зато ошибки в YAML ловятся на нём бесплатно. Практичная схема: учиться на minikube, а первый настоящий стенд поднимать на k3s.

На каком сервере поднимать учебный кластер и сколько это стоит

Для стенда на k3s хватит машины с 2 ядрами и 2 ГБ памяти: около 1,5 ГБ останутся приложениям. Для двух узлов возьмите вторую подешевле — рабочему хватит 1 ядра и 1 ГБ. Диск нужен небольшой, но быстрый: образы контейнеров распаковываются на диск, и на HDD это заметно медленнее.

В каталоге 44 площадки, и стартовые тарифы различаются в несколько раз. Ниже — базовые конфигурации под стенд: управляющему узлу нужна строка с 2 ядрами, рабочему хватит однопроцессорной.

Данные проверены 04.09.2026.

Стенд из двух узлов обойдётся примерно в 200–250 ₽/мес, отказоустойчивая тройка — от 400 ₽/мес против 59 ₽/мес за один сервер под docker compose. Систему проще взять готовую: подойдёт любой VPS с Ubuntu 24.04, k3s официально поддерживает эту версию.

Пошагово: поднимаем k3s и первое приложение

Дальше — минимальный сценарий на одном сервере с Ubuntu. Команды выполняются по SSH от пользователя с правами администратора. После каждого шага указано, что должно получиться: если результат другой, не идите дальше.

1. Обновите пакеты: sudo apt update && sudo apt upgrade -y. Команда обновляет список пакетов и ставит свежие версии, занимает 1–3 минуты.
2. Установите k3s: curl -sfL https://get.k3s.io | sh -. Скрипт скачивает единственный исполняемый файл, регистрирует системную службу и запускает её примерно за минуту.
3. Проверьте узел: sudo k3s kubectl get nodes. В колонке STATUS должно быть Ready; NotReady дольше 2 минут — переходите к диагностике.
4. Скопируйте файл доступа к кластеру: mkdir -p ~/.kube, затем sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config и sudo chown $USER ~/.kube/config. Первая команда создаёт каталог, вторая кладёт туда настройки подключения, третья делает вас владельцем файла — после этого kubectl работает без sudo.
5. Создайте приложение: kubectl create deployment web --image=nginx:1.27. Появится деплоймент с одним подом, внутри — веб-сервер nginx версии 1.27.
6. Посмотрите поды: kubectl get pods -o wide. Через 10–20 секунд статус сменится на Running, а в колонке NODE появится имя сервера.
7. Дайте приложению стабильный адрес: kubectl expose deployment web --port=80. Создастся сервис, к которому другие поды обращаются по имени web.

Дальше — проверка того, ради чего всё затевалось. Команда kubectl scale deployment web --replicas=3 поднимет число копий до трёх. Удалите один под через kubectl delete pod — замена появится за 10–30 секунд. Смените версию образа командой kubectl set image deployment/web nginx=nginx:1.28, наблюдайте выкатку через kubectl rollout status deployment/web, а откат сделайте командой kubectl rollout undo deployment/web.

Диагностика по слоям: что смотреть первым, вторым и третьим

Когда что-то не работает, новички перезапускают всё подряд. Правильный порядок — от общего к частному: четыре слоя, каждый со своей командой.

Слой 1, узлы. kubectl get nodes. Если узел в состоянии NotReady, дело не в приложении: кончилась память или диск, упала служба k3s. Проверьте место командой df -h — при заполнении выше 85% кластер начинает выселять поды сам.

Слой 2, поды. kubectl get pods. Статус Pending означает, что под некуда поставить: на узлах нет запрошенных ядер или памяти. ImagePullBackOff — не скачался образ: опечатка в имени или недоступный реестр. CrashLoopBackOff — контейнер стартует и сразу падает, причина внутри приложения.

Слой 3, события. kubectl describe pod с именем пода: внизу вывода блок Events, где прямым текстом написана причина — «недостаточно памяти», «образ не найден», «проверка готовности не прошла». Этот шаг закрывает большинство случаев.

Слой 4, логи. kubectl logs с именем пода показывает вывод приложения; ключ --previous покажет логи уже упавшей копии. Загрузку узлов смотрят через kubectl top nodes, а общее состояние машины лучше вынести во внешний мониторинг сервера, чтобы не зависеть от самого кластера.

Частые ошибки новичков

Почти все они повторяются из проекта в проект и стоят денег или ночного разбора. Ниже те, что чаще всего встречаются на первом кластере.

• Кластер из одного узла, названный отказоустойчивым: при выключении машины падает всё, включая механизм восстановления.
• Не заданы лимиты памяти и процессора — одно приложение с утечкой памяти съедает узел целиком и роняет соседей.
• База данных в кластере без продуманного хранилища: под переезжает на другой узел и теряет диск с данными.
• Сервер с 1 ГБ памяти, где полный Kubernetes ставят «всё в одном» — управляющим и рабочим узлом сразу: служебная часть занимает почти всё, приложению остаётся 100–200 МБ.
• Открытый наружу порт 6443/TCP без ограничения по адресам — это порт управления, доступ к нему равен доступу ко всем приложениям.
• Нет резервных копий описаний: YAML-файлы живут только на сервере, и после переустановки кластер собирают по памяти.

Отдельно про пакетный менеджер Helm: им удобно ставить готовые сложные приложения одной командой, но начинать с него не стоит. Пока вы не понимаете, из каких объектов состоит приложение, Helm прячет ровно то, что нужно научиться читать.

Частые вопросы

Нужно ли знать Docker перед Kubernetes? Да, и это не формальность. Kubernetes запускает контейнеры, но не собирает их: вы должны уметь написать Dockerfile и запустить образ локально. Без этого отладка в кластере превращается в гадание.

Можно ли поставить Kubernetes на один сервер? Технически да, особенно в варианте k3s на машине с 1–2 ядрами. Но отказоустойчивости это не даёт: выключился сервер — выключилось всё. Один узел годится для учёбы и небольших внутренних сервисов, не для критичных задач.

Сколько памяти нужно кластеру минимум? Управляющему узлу полного Kubernetes — 2 ГБ, из которых на служебные компоненты уйдёт от 1 ГБ. Рабочему узлу хватит 1 ГБ, свободными останутся 600–700 МБ. У k3s аппетит скромнее: 300–500 МБ.

Kubernetes заменяет docker compose? Нет, задачи разного масштаба. Compose — один сервер, до десятка контейнеров, ручная выкатка, 1–2 часа поддержки в месяц. Kubernetes — несколько серверов, автоматические выкатки и откаты, от 4 часов поддержки. Переходить стоит, когда compose перестал справляться, а не заранее.

Сколько времени занимает освоение? До состояния «поднял стенд и запустил приложение» — один-два вечера на k3s. До «отвечаю за боевой кластер» — от 2 до 6 недель практики, и это если вы уверенно работаете с Linux и контейнерами.

Во сколько обойдётся учебный кластер в месяц? Два узла на стартовых тарифах — 200–250 ₽/мес, три узла для тренировки отказоустойчивости — от 400 ₽/мес, тогда как один сервер под docker compose стоит от 59 ₽/мес.

Итог

Kubernetes — рабочий инструмент для тех, у кого много сервисов, частые релизы и требование к доступности. Он снимает три боли: перезапуск упавшего, выкатку без простоя и переезд при отказе сервера. Цена вопроса — минимум три сервера, от 2 ядер и 2 ГБ на управляющий узел и от 4 часов поддержки в месяц.

Если у вас одно-два приложения на одной машине, честный ответ — docker compose: дешевле, понятнее и покрывает задачу целиком. Начните с учебного стенда на k3s за 145–250 ₽/мес и потрогайте масштабирование и откат руками. Подобрать машину под стенд или под будущий кластер можно в каталоге VPS и VDS: там собраны конфигурации 44 провайдеров с ценами и локациями.