Docker и Kubernetes для начинающего разработчика: когда нужен кластер

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Docker и Kubernetes решают разные части задачи доставки приложения. Разработчик собирает образ и проверяет процесс, сеть и данные; затем выбирает способ запуска. Compose удобен для согласованного окружения на одном Docker Engine. Kubernetes добавляет управление приложениями на узлах кластера. Выбор определяется требованиями к эксплуатации, а не размером YAML-файла.

Что уже переносится, а что придётся описать заново

Service в Kubernetes предоставляет стабильную сетевую точку доступа; Deployment поддерживает экземпляры приложения. Это не прямые синонимы одного сервиса Compose. Kubernetes не собирает исходники вместо Dockerfile и не исправляет ошибки программы. Возможности оркестратора.

Pod — минимальная единица размещения Kubernetes: один или несколько совместно работающих контейнеров с общим сетевым пространством и подключаемыми томами. Контейнеры одного Pod обращаются друг к другу через localhost; два разных Pod так не связываются. Pod имеет жизненный цикл и может быть заменён новым экземпляром, поэтому его IP не следует зашивать в приложение. Модель Pod.

ReplicaSet поддерживает нужное количество подходящих Pod, а Deployment управляет ReplicaSet и развёртыванием новых версий. В обычном примере разработчик меняет шаблон Deployment; контроллер создаёт или обновляет ReplicaSet, а тот обеспечивает Pod. Service выбирает endpoints по меткам и даёт стабильный способ обратиться к готовым экземплярам. Его selector должен совпадать с labels Pod; сам Service не запускает процесс. Deployment и ReplicaSet.

Практика до кластера

Проверьте, что один контейнер имеет понятный контракт. Создайте compose.yaml в отдельной папке:

name: dk-k8s-prep
services:
  web:
    image: nginx:stable-alpine
    ports:
      - "127.0.0.1:18086:80"
    restart: unless-stopped

docker compose config
docker compose up -d
docker compose exec web nginx -t
docker compose logs --tail 20 web
docker compose down

Ожидайте успешную проверку конфигурации Nginx. Пока окружение поднято, страница открывается на http://127.0.0.1:18086. Вы уже определили образ, порт, команду проверки и способ наблюдения. Политика restart работает в рамках Engine; потеря самой машины не создаст копию приложения на другом сервере. Это конкретная граница, после которой может потребоваться оркестрация.

Минимальный перевод в Kubernetes

Этот блок выполняют только в своём учебном кластере с настроенным kubectl. Сначала проверьте kubectl config current-context: команды должны попасть в учебную среду. Создайте отдельное пространство имён и приложение:

kubectl create namespace dk-learning
kubectl -n dk-learning create deployment web --image=nginx:stable-alpine
kubectl -n dk-learning rollout status deployment/web --timeout=120s
kubectl -n dk-learning expose deployment web --port=80 --target-port=80
kubectl -n dk-learning get pods,services
kubectl -n dk-learning port-forward service/web 18086:80

Последняя команда занимает терминал. Откройте локальный адрес; затем завершите port-forward через Ctrl+C. При ImagePullBackOff изучите kubectl -n dk-learning describe pod ИМЯ_ПОДА: узлу нужен доступ к registry. Не начинайте с многократного пересоздания Deployment. После практики удалите только созданное пространство: kubectl delete namespace dk-learning.

Почему Kubernetes может работать без Docker Engine

Kubelet взаимодействует со средой исполнения через CRI, например с containerd. Исторический встроенный dockershim удалён из Kubernetes; наличие образа, собранного Docker, не обязывает кластер использовать Docker Engine. Формат образа и интерфейс runtime — разные уровни. Официальное описание container runtimes.

На ноутбуке docker images показывает локальное хранилище выбранного Engine. Кластерный узел обычно не видит его автоматически. Поэтому работающий локально тег ещё не доказывает, что Deployment сможет скачать образ; нужна публикация в registry или специальная загрузка в конкретный учебный кластер.

Упражнение на выбор решения

Для API и PostgreSQL на ноутбуке предложите Compose. Для API с тремя репликами на разных машинах, автоматическим восстановлением после потери узла и управляемыми обновлениями рассмотрите Kubernetes вместе с его операционными затратами. Для базы отдельно обоснуйте резервное копирование и устойчивое хранилище: несколько Pod сами по себе не делают базу отказоустойчивой.

Запишите контракт своего контейнера: входной порт, обязательная конфигурация, путь данных, сигнал остановки и проверка готовности. Если один из пунктов неизвестен, сначала уточните его локальным экспериментом. Это полезнее начинающему разработчику, чем переносить в кластер непонятную команду run.