Kubernetes: контейнеры на многих серверах

Когда Docker перестаёт хватать

Представь: ты запустил своё приложение в Docker на одном сервере. Всё работает — пользователи довольны, заказы идут.

Сценарий 1: сервер сгорел.
Жёсткий диск умер, дата-центр потерял питание, провайдер что-то уронил. Docker ничего не умеет делать сам — твоё приложение просто недоступно, пока ты вручную не поднимешь всё на другой машине. В 3 часа ночи.

Сценарий 2: нагрузка выросла.
Вышла реклама, пришло 10× больше пользователей. Один контейнер не справляется. Ты вручную запускаешь второй, третий — но как распределить трафик? Нужен балансировщик, нужно следить за каждым, обновлять вручную.

Сценарий 3: плановый рост.
Сначала один сервер с Docker справлялся. Потом стало два сервера. Потом пять. Как следить за тем, что где запущено? Как обновить приложение на всех сразу, не роняя сервис?

Вот для этого и нужен Kubernetes.

Зачем нужен Kubernetes

Kubernetes (или просто k8s) — это система управления контейнерами сразу на множестве серверов:

Сервер упал? Kubernetes автоматически перезапустит контейнеры на других нодах.
Нагрузка выросла? Kubernetes сам добавит нужное количество копий приложения.
Нужно обновить приложение без остановки? Kubernetes выполнит постепенное обновление (rolling update) — по одному контейнеру, без перерыва в работе.

Образно: Docker — это один водитель с одной машиной. Kubernetes — это диспетчер таксопарка из сотни машин. Ты говоришь «мне нужно 10 машин в центре города» — и диспетчер сам разберётся, какие свободны, где они стоят и что делать если одна сломается.

Основные понятия

Node (нода) — отдельный физический или виртуальный сервер в кластере. Kubernetes распределяет работу между нодами.

Cluster (кластер) — вся система целиком: несколько нод плюс управляющий компонент (control plane), который следит за состоянием кластера и принимает решения.

Namespace (пространство имён) — логическое разделение внутри одного кластера. Представь, что кластер — это один большой офис, а namespace — отдельные комнаты в нём. В одном кластере можно держать production, staging и dev — и они не будут мешать друг другу. По умолчанию ресурсы создаются в namespace default.

Pod (под) — минимальная единица запуска в Kubernetes. Kubernetes не запускает контейнеры напрямую — он запускает поды.

kubectl — командная строка для управления кластером. Как docker для Docker, только для Kubernetes.

Pod и контейнер — в чём разница?

Под — это обёртка вокруг одного или нескольких контейнеров. Контейнеры внутри одного пода:

работают на одном сервере
делят одну сеть (видят друг друга через localhost)
могут использовать общее хранилище (тома, или volumes)

В большинстве случаев один под = один контейнер. Это самый распространённый вариант, и именно так ты будешь работать в лабораторных.

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

Kubernetes vs Docker

	Docker	Kubernetes
Запускает контейнеры	✅	✅
Один сервер	✅	✅
Много серверов	❌	✅
Авто-перезапуск при падении	❌	✅
Балансировка нагрузки	❌	✅
Масштабирование	вручную	автоматически

Как выглядит работа с Kubernetes

Чтобы запустить контейнер с nginx внутри пода, выполни:

kubectl run nginx --image=nginx:alpine --restart=Never

Разбор: kubectl отправляет команду в Kubernetes API, run nginx создаёт Pod с именем nginx, --image=nginx:alpine задаёт образ контейнера, --restart=Never говорит создать обычный Pod без контроллера перезапуска вроде Deployment.

Ты увидишь подтверждение:

pod/nginx created

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

kubectl get pods

kubectl get pods запрашивает у сервера API список Pod в текущем пространстве имён. get означает просмотр объектов, а pods — их тип. Если Pod не виден, сначала проверь пространство имён и текущий контекст.

Ты увидишь примерно такой вывод — имя пода, статус и время работы:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          5m

Синтаксис похож на Docker, но вместо контейнеров — поды, вместо хоста — кластер.

Как посмотреть устройство Pod в YAML

Команда kubectl run удобна для первого запуска, но в Kubernetes ресурсы обычно описывают в YAML. Посмотреть полное описание созданного Pod можно так:

kubectl get pod nginx -o yaml

В выводе есть несколько основных частей:

apiVersion - версия API Kubernetes для этого объекта;
kind - тип объекта, в нашем случае Pod;
metadata - имя, пространство имён, метки и другие сведения об объекте;
spec - требуемая конфигурация: какие контейнеры и образы нужно запустить;
status - текущее состояние, которое заполняет сам Kubernetes.

Сохранить вывод в файл можно обычным перенаправлением:

kubectl get pod nginx -o yaml > /root/nginx-pod.yaml

Этот файл показывает не только то, что мы указали при запуске, но и служебные поля, добавленные кластером: идентификатор объекта, IP Pod, выбранную ноду и текущее состояние контейнера. В лабораторной ты откроешь этот файл в VS Code и увидишь структуру своими глазами.

О лабораторной среде

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

Одноузловой кластер — это кластер, в котором управляющие компоненты (control plane) и рабочий узел находятся на одном сервере. Для обучения этого достаточно.