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

Семёнов Евгений Сергеевич, директор ITFresh. Вот что я вам скажу: за пятнадцать с хвостиком лет, которые я провёл в серверном администрировании, инфраструктура изменилась до неузнаваемости. Помню, как мы переходили от 'один сервер — одно приложение' к сложным контейнеризированным кластерам, которые сами умеют масштабироваться. Последние лет пять 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, или, как мы в ITFresh привыкли говорить, управляющие узлы. Эти ребята — мозг всей операции: они решают, какой под где стартануть, какие сервисы вообще живы и работают, и, конечно, держат в курсе о текущем состоянии всей системы. А есть ещё 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 ГБ оперативки. Одна из них станет нашим 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, состоящий из шести узлов! Для этого выделили три сервера Dell PowerEdge R650. Каждый из них 'под капотом' имеет Xeon Platinum 8280 и 384 ГБ оперативки, а ещё мы связали их высокоскоростной сетью 40G Mellanox ConnectX-5. Всю эту красоту разместили в дата-центре МТС, прямо в Москве, где у нас своя отдельная стойка с полным резервным питанием. Серьёзная заявка, да?

Помню те времена, ещё до переезда: наш клиентский сайт стабильно 'падал' раз в неделю! Двадцать-тридцать минут простоя, как штык. А всё почему? Пиковые нагрузки, которые обрушивались каждый вечер. Ну, это было до того, как мы внедрили Kubernetes с автомасштабированием через HorizontalPodAutoscaler, работающий по загрузке CPU. Теперь приложение само, как по волшебству, поднимало новые копии, стоило RPS подскочить, и тут же убирало их глубокой ночью, когда активность падала. Результат? За целых полгода — ни одной проблемы с доступностью, а время ответа сократилось почти в три раза: с 480 мс до 160 мс! И что тут самое приятное? Все вложения в 'железо' окупились всего за четырнадцать месяцев. Ведь мы просто перестали платить за дорогущую аренду облачных серверов, которые приходилось держать с огромным запасом по мощности, 'на всякий случай'.

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

Мы в ITFresh постоянно сталкиваемся с тем, что админы, впервые взявшиеся за 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.