Привет, коллега! 👋 Если ты только начинаешь свой путь в мире контейнеров и оркестрации, эта статья — для тебя. Я постараюсь объяснить всё максимально просто, без заумных фраз и воды. Представь, что мы сидим на кухне с чашкой кофе, и я рассказываю тебе, как самому запустить Kubernetes и не запутаться в терминах.
Поехали!
Сначала ставим инструменты: kubectl и локальный кластер
Прежде чем вообще что-то делать с Kubernetes, нужно подготовить рабочее место. Это как собрать инструмент перед ремонтом: без отвёртки и молотка далеко не уедешь.
Шаг 1: Ставим kubectl
kubectl — это твоя главная палочка-выручалочка. Через эту консольную утилиту ты будешь общаться с кластером: создавать приложения, смотреть логи, чинить то, что сломалось.
Как поставить:
-
Linux: Скачай скрипт с официального сайта, запусти — и бинарник сам упадёт в
/usr/local/bin. -
macOS: Проще всего через Homebrew:
brew install kubectl. -
Windows: Можно скачать
.exeс релизов Kubernetes на GitHub, или использовать Chocolatey/Scoop/winget.
⚠️ Важный момент для Windows: Если у тебя стоит Docker Desktop, в нём уже есть свой kubectl. Это может создать конфликт. Лучше либо убрать путь к версии из Docker Desktop из переменной PATH, либо просто удалить её — и пользоваться своей, отдельно установленной.
Проверяем, что всё работает:
kubectl version --client
Если увидел версию — отлично, утилита на месте.
Шаг 2: Запускаем кластер у себя на машине
Теперь самое интересное — запустить настоящий Kubernetes, но локально. Не на продакшене, не в облаке, а просто у себя на ноутбуке, чтобы потренироваться.
Для этого есть два отличных инструмента:
🔹 Minikube — классика для новичков
Это самый популярный способ. Minikube поднимает одно-узловой кластер внутри виртуалки на твоём компьютере.
Почему он хорош:
-
Работает на Windows, macOS, Linux
-
Одна команда — и кластер готов:
minikube start -
Сам скачивает образы, настраивает API-сервер, etcd, планировщик — всё, что нужно
После запуска проверь:
kubectl get nodes
Должен увидеть один узел со статусом Ready. Поздравляю, у тебя есть свой Kubernetes! 🎉
🔹 Kind — Kubernetes внутри Docker
Если ты уже плотно работаешь с Docker, Kind может понравиться больше. Он запускает узлы Kubernetes как обычные Docker-контейнеры.
Плюсы:
-
Очень быстрый старт и остановка
-
Все зависимости управляются через Docker
-
Легко снести и поднять заново
Запускается так же просто:
kind create cluster
Что выбрать? Если сомневаешься — бери Minikube. Под него больше гайдов, и если что-то пойдёт не так, гуглить будет проще. Когда освоишься — попробуешь Kind.
Шаг 3: Проверяем связь
После запуска кластера убедись, что kubectl его видит:
kubectl cluster-info
Если в ответ получил ссылки на API-сервер и другие компоненты — всё ок, можно работать.
📌 Лайфхак: Версия kubectl должна отличаться от версии кластера не больше чем на одну минорную. Иначе могут быть сюрпризы. Проверить можно через kubectl version.
Три кита Kubernetes: Pod, Deployment, Service
Теперь, когда у тебя есть кластер, давай разберёмся, из чего вообще состоит приложение в Kubernetes. Не буду грузить теорией — объясню на пальцах.
🧱 Pod — самая маленькая единица
Pod — это как коробочка, в которой живёт твой контейнер (или несколько). Все контейнеры внутри одного Pod делят один IP-адрес и могут общаться друг с другом через localhost.
Важно запомнить: Pod’ы — временные. Они могут исчезнуть в любой момент: упало приложение, закончилась память, перезагрузился узел. Если Pod умер — он сам не воскреснет. Именно поэтому мы не работаем с Pod’ами напрямую, а используем следующий уровень.
🚀 Deployment — наш «автопилот»
Deployment — это декларативное описание того, как должно работать твоё приложение. Ты говоришь: «Хочу 3 копии моего приложения на образе my-app:v1.2», а Kubernetes сам следит, чтобы это желание исполнялось.
Что делает Deployment:
-
Если Pod упал — поднимает новый
-
Если нужно обновить версию — делает это плавно, без простоя
-
Если нужно масштабировать — добавляет или убирает реплики
Пример простого Deployment’а:
apiVersion: apps/v1kind: Deploymentmeta name: my-appspec: replicas: 3 selector: matchLabels: app: my-app template: meta labels: app: my-app spec: containers: - name: my-app image: my-app:v1.2 ports: - containerPort: 80
Применяешь так:
kubectl apply -f deployment.yaml
И всё — Kubernetes сам создаст ReplicaSet, а тот — три Pod’а с твоим приложением.
🌐 Service — стабильный адрес для доступа
Каждый Pod получает свой временный IP. Сегодня он один, завтра — другой. Если хранить этот адрес в коде — всё сломается при первом же перезапуске.
Решение — Service. Это как визитка с постоянным телефоном, за которой скрывается группа меняющихся сотрудников (Pod’ов).
Как это работает:
-
Ты вешаешь на Pod’ы метки, например
app: my-app -
Создаёшь Service с селектором
app: my-app -
Kubernetes автоматически направляет трафик на все Pod’ы с этой меткой
Пример:
apiVersion: v1kind: Servicemeta name: my-app-servicespec: selector: app: my-app ports: - port: 8080 # Порт, на котором сервис принимает запросы targetPort: 80 # Порт, на котором слушает приложение в контейнере type: ClusterIP # Доступно только внутри кластера
Хочешь доступ извне? В Minikube есть удобная команда:
minikube service my-app-service
Она сама откроет браузер с адресом твоего приложения. Магия! ✨
В облако: EKS, GKE, AKS — что выбрать?
Когда локальная песочница освоена, хочется чего-то большего. Продакшен, команда, масштабы. Тут на помощь приходят облачные провайдеры.
Почему не стоит поднимать кластер вручную?
Можно, конечно, взять kubeadm и собрать кластер с нуля. Но это как строить дом без прораба: технически возможно, но зачем? Ты потратишь кучу времени на настройку API-сервера, etcd, сети, бэкапов… А потом ещё на поддержку.
Управляемые сервисы (managed Kubernetes) берут всю эту рутину на себя:
-
Провайдер сам держит Control Plane в исправности
-
Сам обновляет версии, чинит сбои, делает бэкапы
-
Ты просто подключаешь рабочие узлы и деплоишь приложение
Три главных варианта:
|
Провайдер |
Сервис |
Кратко |
|---|---|---|
|
AWS |
EKS |
Мощно, гибко, но чуть сложнее в настройке |
|
|
GKE |
Самый «родной» для Kubernetes, отличная интеграция |
|
Azure |
AKS |
Удобно, если уже используешь экосистему Microsoft |
Как создать кластер в облаке?
Есть два пути:
1. Через веб-консоль — нажал, выбрал регион, тип узлов, нажал «Создать». Просто, но не очень воспроизводимо.
2. Через код (IaC) — описал инфраструктуру в файле, применил — и всё создалось само. Это профессиональный подход.
Пример на Terraform для AWS EKS (очень упрощённо):
resource "aws_eks_cluster" "my_cluster" { name = "my-app-cluster" role_arn = aws_iam_role.eks.arn vpc_config { subnet_ids = [/* твои подсети */] }}resource "aws_eks_node_group" "nodes" { cluster_name = aws_eks_cluster.my_cluster.name node_group_name = "app-nodes" node_role_arn = aws_iam_role.nodes.arn scaling_config { desired_size = 2 min_size = 1 max_size = 4 }}
Применил — и через 10–15 минут у тебя готовый кластер. Осталось только подключить kubectl:
aws eks update-kubeconfig --name my-app-cluster
И всё — ты управляешь облачным кластером так же, как локальным.
📌 Совет: Начинай с бесплатных тарифов или триалов. И всегда ставь лимиты на расходы, чтобы случайно не получить счёт на тысячи долларов.
Ловим баги: как чинить, когда всё сломалось
Рано или поздно что-то пойдёт не так. Это нормально. Главное — знать, куда смотреть.
🔍 Алгоритм отладки для новичка
-
Смотри статус:
kubectl get pods-
Running— ок -
Pending— не хватает ресурсов или проблема с планировщиком -
CrashLoopBackOff— приложение падает сразу после запуска -
ImagePullBackOff— не может скачать образ
-
-
Читай логи:
kubectl logs <имя-пода>-
Тут обычно и лежит причина: ошибка в коде, не найдена переменная, не подключилась база
-
-
Смотри детали:
kubectl describe pod <имя-пода>-
Особенно секция Events — там Kubernetes пишет, что он пытался сделать и что пошло не так
-
-
Залезь внутрь (если нужно):
kubectl exec -it <имя-пода> -- /bin/sh-
Можно вручную проверить переменные, файлы, попробовать запустить приложение
-
🚨 Типовые ошибки и как их чинить
❌ Образ не тянется (ImagePullBackOff)
Возможные причины:
-
Опечатка в имени или теге образа
-
Образ приватный, а секреты не настроены
-
Проблемы с сетью на узле
Что делать:
kubectl describe pod <имя> # смотри Events# Исправь имя образа в YAML и примени заново# Для приватных репозиториев добавь imagePullSecrets
❌ Приложение падает (CrashLoopBackOff)
Возможные причины:
-
Ошибка в коде приложения
-
Не хватает памяти (событие
OOMKilled) -
Неправильная команда запуска
Что делать:
kubectl logs <имя> # читаем стектрейсkubectl describe pod <имя> # ищем OOMKilled# Если не хватает памяти — увеличь limits в ресурсах
❌ Сервис не отвечает
Возможные причины:
-
Метки в Service не совпадают с метками в Pod’ах
-
Неверно указаны порты (
port≠targetPort)
Что делать:
kubectl get pods --show-labels # смотрим меткиkubectl describe service <имя> # сверяем селектор# Проверяем, что port в Service = targetPort = containerPort
📌 Про ресурсы: Всегда указывай requests и limits для CPU и памяти. Иначе Pod может «задушить» узел или, наоборот, не запуститься из-за нехватки ресурсов.
Куда расти дальше?
Ты уже умеешь: ✅ Ставить инструменты
✅ Запускать локальный кластер
✅ Деплоить приложение через Deployment
✅ Открывать доступ через Service
✅ Чинить типовые ошибки
✅ Подключаться к облачному кластеру
Что изучать следующим шагом:
🔹 Ingress — чтобы не плодить LoadBalancer на каждое приложение, а маршрутизировать трафик по доменам и путям.
🔹 ConfigMaps и Secrets — чтобы выносить конфиги и пароли из кода приложения.
🔹 Jobs и CronJobs — для фоновых задач и расписаний.
🔹 Метрики и автоскейлинг — чтобы приложение само масштабировалось под нагрузку.
🔔 Важно: Экосистема Kubernetes быстро меняется. Например, старый Ingress-NGINX постепенно уступает место новым стандартам (Gateway API, Istio). Следи за новостями, но не пытайся выучить всё сразу.
Вместо заключения
Знаешь, в чём главный секрет изучения Kubernetes? Не в том, чтобы запомнить все команды. А в том, чтобы не бояться ломать.
У тебя есть локальный кластер? Отлично. Сломай его. Попробуй удалить Pod вручную. Посмотри, как Deployment его восстановит. Поменяй порт в Service — увидишь, что приложение перестало отвечать. Почини.
Каждая такая «авария» — это не провал, а опыт. Через 10–20 таких экспериментов ты начнёшь чувствовать, как работает система. И тогда любые продакшен-задачи перестанут пугать.
Удачи! И помни: даже сеньоры гуглят kubectl-команды. Это нормально 😊
Если статья помогла — сохрани в закладки. Вернёшься, когда понадобится вспомнить, как чинить CrashLoopBackOff в 3 часа ночи. 🌙
ссылка на оригинал статьи https://habr.com/ru/articles/1025558/