Kubernetes для начинающих: что это, зачем и как развернуть первый кластер

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш и за 15+ лет администрирования серверов видел, как инфраструктура эволюционировала от «один сервер — одно приложение» до контейнеризированных кластеров с автоматическим масштабированием. Kubernetes за последние пять лет стал отраслевым стандартом, но вокруг него вьётся облако мифов и страхов. Я всегда начинаю объяснение для клиентов с простой метафоры: если Docker — это контейнер с грузом, то Kubernetes — это морской порт, который знает, куда какой контейнер поставить, как снять с упавшего крана и как быстро перегрузить на другой корабль.

Что такое Kubernetes и откуда он взялся

Kubernetes — это система оркестрации контейнеров, которая автоматизирует их развёртывание, масштабирование и управление жизненным циклом. Google использовал внутреннюю систему Borg для управления своими сервисами больше десяти лет, и в 2014 году выпустил Kubernetes как open-source переосмысление этого опыта. Сейчас проект живёт под CNCF и поддерживается сотнями корпораций.

Главная идея такая. Вы описываете желаемое состояние системы в YAML-файле: «хочу, чтобы запустилось пять реплик моего веб-приложения, каждая с 500 МБ памяти, слушала порт 8080 и была доступна извне по домену app.example.ru». Kubernetes берёт этот манифест и делает так. А если один из подов падает или узел перезагружается — сам поднимает замену на другой ноде, чтобы заявленное количество реплик соблюдалось.

Архитектура: control-plane и worker-узлы

Кластер Kubernetes делится на две роли. Control-plane (управляющие узлы) отвечают за принятие решений — какой под где запустить, какие сервисы зарегистрированы, каков текущий статус. Worker-узлы выполняют реальные рабочие нагрузки, запуская контейнеры пользователя.

Компоненты control-plane:

• kube-apiserver — единственная точка входа для всех операций. С ней разговаривают kubectl, контроллеры и узлы.
• etcd — распределённое key-value хранилище, где лежит всё состояние кластера.
• kube-scheduler — решает, на каком worker-узле запустить новый под.
• kube-controller-manager — следит за тем, чтобы реальное состояние соответствовало желаемому.

На worker-узлах работают kubelet (агент, который управляет контейнерами по приказу от apiserver), kube-proxy (настраивает сетевые правила iptables/ipvs для сервисов) и среда выполнения контейнеров — containerd или CRI-O.

Базовые объекты Kubernetes

Чтобы начать работать, достаточно понять пять сущностей. В документации их гораздо больше, но для первого приложения хватит этих.

Устанавливаем первый кластер на kubeadm

Для обучения я обычно беру три виртуальные машины на Ubuntu 22.04 с 4 vCPU и 8 ГБ RAM. Одна станет control-plane, две — воркерами. Дальше на каждой машине ставим containerd и kubeadm:

sudo apt update && sudo apt install -y apt-transport-https ca-certificates curl
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] \
  https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt update && sudo apt install -y kubelet kubeadm kubectl containerd
sudo apt-mark hold kubelet kubeadm kubectl
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

На будущем control-plane:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Команда kubeadm init в конце выведет команду kubeadm join с токеном — её копируем и выполняем на каждом worker-узле. Через минуту kubectl get nodes покажет три Ready-ноды.

Запускаем первое приложение

Возьмём простое nginx и раскатаем его с тремя репликами. Создаём файл nginx-app.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-app
  template:
    metadata:
      labels:
        app: nginx-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
        resources:
          requests: { cpu: "100m", memory: "64Mi" }
          limits:   { cpu: "500m", memory: "256Mi" }
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx-app
  ports:
  - port: 80
    targetPort: 80
  type: NodePort

Применяем и проверяем:

kubectl apply -f nginx-app.yaml
kubectl get pods -o wide
kubectl get svc nginx-svc
curl http://<любой-worker-IP>:<NodePort>

Мини-кейс: внедрение для интернет-магазина одежды

В марте 2025 мы перевели клиента — интернет-магазин женской одежды, около 18 000 заказов в месяц — с одного виртуального сервера на кластер Kubernetes из 6 узлов. Выделили три сервера Dell PowerEdge R650 с Xeon Platinum 8280, 384 ГБ RAM на каждый, и объединили их сетью 40G Mellanox ConnectX-5. Железо разместили в дата-центре МТС в Москве, под собственную стойку с резервным питанием.

До переезда сайт раз в неделю уходил в даунтайм на 20-30 минут из-за пиковых нагрузок в вечерние часы. После перехода на Kubernetes с автомасштабированием (HorizontalPodAutoscaler по CPU) приложение само поднимало дополнительные реплики при росте RPS и гасило их ночью. За полгода — ни одного инцидента с недоступностью, среднее время ответа сократилось с 480 мс до 160 мс. Стоимость железа окупилась за 14 месяцев за счёт отказа от аренды облачных серверов с запасом по мощности.

Типичные ошибки новичков

У нас на практике вижу одни и те же грабли у админов, которые впервые трогают Kubernetes:

• Не задают resources.requests и limits. Без них планировщик не знает, сколько ресурсов нужно поду, и может напихать их на узел пока тот не начнёт OOM-киллить всё подряд.
• Используют latest-теги образов. При рестарте пода образ может обновиться втихую и сломать прод. Всегда пиню конкретные версии: nginx:1.27-alpine, никогда nginx:latest.
• Ставят один control-plane. Работает, пока не упал — и тогда кластер превращается в тыкву.
• Хранят секреты в ConfigMap. Секреты нужно в Secret, и желательно зашифрованные через KMS или Sealed Secrets.
• Не настраивают ресурсные квоты на namespace. Один разработчик может съесть все ресурсы кластера одним циклом kubectl apply.

FAQ — частые вопросы по Kubernetes

Нужен ли Kubernetes офису на 30 человек?

Обычно нет. Если у вас 3-5 небольших приложений, хватает обычного Docker Compose или systemd-юнитов на паре серверов. Kubernetes оправдан, когда приложений десятки, нужны отказоустойчивость, автодеплой и горизонтальное масштабирование.

Сколько узлов минимально для production?

Три control-plane узла и минимум три worker-узла. Один control-plane — это обучение и тест, но не прод.

Чем отличается Deployment от StatefulSet?

Deployment создаёт взаимозаменяемые поды без постоянной идентичности — подходит для stateless веб-приложений. StatefulSet даёт подам стабильные имена и персистентные тома — нужен для баз данных и очередей.

Можно ли обойтись без ingress-контроллера?

Да, через Service типа LoadBalancer или NodePort, но каждому сервису придётся выделять отдельный порт или IP. Ingress-контроллер (nginx, traefik) решает вопрос маршрутизации по доменам и TLS в одном месте.

Что лучше: managed Kubernetes или self-hosted?

Если у вас нет выделенного DevOps — берите managed. Self-hosted экономит деньги, но требует постоянного внимания: обновления etcd, ротация сертификатов, мониторинг control-plane.