Kubernetes для начинающих: minikube и запуск сервисов — пошаговый гайд

Что такое Kubernetes и зачем он нужен

Kubernetes управляет контейнерами на группе серверов. Он автоматизирует развертывание, масштабирование и восстановление приложений после сбоев. Если контейнер падает, Kubernetes перезапускает его. Если нагрузка растет, добавляет реплики. Если узел выходит из строя, переносит нагрузку на исправные машины.

Представьте дирижера оркестра. Каждый музыкант играет свою партию, но без координации получится шум. Kubernetes задает ритм: указывает, какие контейнеры должны работать, сколько копий держать и как связывать их между собой. Он следит за фактическим состоянием системы и приводит его к желаемому.

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

Перед погружением в практику полезно понимать архитектуру кластера: control plane управляет состоянием, worker nodes выполняют нагрузку. Подробный разбор компонентов и объектов API есть в руководстве по архитектуре Kubernetes.

Установка и настройка минимального кластера

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

Выбор инструмента: minikube, kind или k3s

Три популярных варианта для локального запуска Kubernetes:

• minikube - полноценный кластер в виртуальной машине. Максимально приближен к реальному окружению, поддерживает большинство фич Kubernetes. Оптимален для начала.
• kind - кластер в Docker-контейнерах. Быстрый, легкий, удобен для CI/CD и тестирования. Не требует гипервизора.
• k3s - легковесная сборка Kubernetes для продакшена и edge-устройств. Потребляет меньше ресурсов, ставится одной командой.

Ниже приведено практическое сравнение. Версии указаны как ориентир для 2026 года: перед установкой проверьте доступный стабильный релиз инструмента и совместимость образа Kubernetes.

Для обучения выбирайте minikube. Он дает изолированное окружение с привычным поведением кластера и минимумом сюрпризов при настройке сети и хранилищ. kind удобнее, если кластер должен быстро создаваться внутри Docker, а k3s - если нужно проверить работу легковесного Kubernetes на отдельном сервере.

Установка kubectl

kubectl - основная утилита для управления кластером. Установите её до запуска minikube.

На Linux:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

На macOS:

brew install kubectl

На Windows:

winget install Kubernetes.kubectl

Проверьте установку:

kubectl version --client

Команда выводит версию клиента. Если вместо этого появляется ошибка, проверьте, что бинарник находится в PATH.

Запуск кластера с minikube

Установите minikube с официального сайта проекта или через пакетный менеджер. На Linux и macOS удобно использовать brew:

brew install minikube

На Windows установку можно выполнить через winget:

winget install Kubernetes.minikube

Установка minikube на Windows: Hyper-V и WSL2

Перед запуском проверьте, что в BIOS/UEFI включена аппаратная виртуализация. Для Hyper-V также должен быть доступен компонент Hyper-V. Узнать имена виртуальных коммутаторов можно в PowerShell:

Get-VMSwitch

Вариант с hyperv подходит для Windows, где Hyper-V уже используется как основной гипервизор. Замените Default Switch на имя коммутатора из вывода предыдущей команды, если оно отличается:

minikube start --driver=hyperv --hyperv-virtual-switch="Default Switch"

Вариант с WSL2 обычно используют вместе с Docker Desktop и включенной WSL2-интеграцией. Запускайте команду из WSL2 или Windows Terminal:

minikube start --driver=docker

WSL2 в этом сценарии предоставляет Linux-окружение, а minikube использует Docker driver. Если Docker Desktop не запущен или WSL2-интеграция отключена, запуск завершится ошибкой.

Для Linux и macOS запустите кластер командой:

minikube start

Команда скачает образ виртуальной машины, развернет control plane и настроит контекст kubectl на новый кластер. Первый запуск занимает несколько минут.

Проверьте состояние:

minikube status
kubectl get nodes

Вывод должен показать один узел в статусе Ready. Это означает, что кластер работает и готов принимать нагрузку.

Основные объекты Kubernetes: Pod, Deployment, Service

Kubernetes оперирует декларативными объектами. Вы описываете желаемое состояние в YAML-манифесте, а система приводит реальность к этому описанию. Три базовых объекта закрывают большинство стартовых задач.

Pod - минимальная единица

Pod - наименьшая единица планирования в Kubernetes. Он содержит один или несколько контейнеров, которые разделяют сеть и хранилище. Контейнеры внутри Pod всегда запускаются на одном узле.

Пример манифеста Pod с одним контейнером:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.27
    ports:
    - containerPort: 80

Поле apiVersion указывает версию API, kind - тип объекта. В metadata.name задается имя, в spec.containers - список контейнеров с образом и портами.

Pod эфемерен. Его могут удалить, пересоздать или переместить на другой узел. Прямое создание Pod применяется редко, обычно Pod запускается через контроллер.

Deployment - управление репликами и обновлениями

Deployment поддерживает заданное количество реплик Pod и управляет обновлениями. Если Pod упадет, Deployment создаст новый. Если вы измените версию образа, Deployment выполнит rolling update без простоя.

Пример Deployment с тремя репликами:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80

Поле replicas задает количество копий. selector определяет, какие Pod относятся к этому Deployment. template описывает шаблон Pod, который будет создаваться. Подробнее о стратегиях обновления и откатах читайте в руководстве по Deployment.

Service - стабильный доступ к подам: Kubernetes Service ClusterIP, пример

Pod получает случайный IP-адрес и может быть пересоздан в любой момент. Обращаться к нему напрямую ненадежно. Service создает стабильную точку доступа: постоянный IP и DNS-имя, которые не меняются при пересоздании Pod.

Пример Service типа ClusterIP:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Поле selector связывает Service с Pod по меткам. Трафик, пришедший на порт 80 Service, направляется на порт 80 выбранных Pod. Service автоматически балансирует нагрузку между репликами. Если поле type не указано, Kubernetes использует тип ClusterIP. Такой Kubernetes Service ClusterIP пример подходит для связи компонентов внутри кластера.

NodePort и LoadBalancer: когда менять тип Service

NodePort открывает порт Service на каждом узле и позволяет обращаться к приложению через IP узла. Чтобы изменить тип уже созданного Service:

kubectl patch service nginx-service -p '{"spec":{"type":"NodePort"}}'
kubectl get service nginx-service

После изменения Kubernetes назначит внешний порт из диапазона NodePort. В minikube URL можно получить командой:

minikube service nginx-service --url

LoadBalancer предназначен для окружений, где инфраструктура умеет выделять внешний балансировщик. В локальном minikube внешний IP может оставаться в статусе Pending, пока не запущен туннель:

kubectl patch service nginx-service -p '{"spec":{"type":"LoadBalancer"}}'
minikube tunnel

Для обычной проверки приложения на локальном компьютере достаточно ClusterIP и kubectl port-forward. NodePort и LoadBalancer нужны, когда сервис должен быть доступен по адресу узла или через внешний IP.

Деплой первого приложения

Соберем все вместе: развернем Nginx через Deployment и опубликуем его через Service. Используем готовый образ, чтобы исключить ошибки сборки.

Создание манифестов Deployment и Service

Сохраните два YAML-файла из предыдущего раздела: deployment.yaml и service.yaml. Они содержат полную конфигурацию для запуска Nginx с тремя репликами и внутренним доступом по порту 80.

Ключевые поля Deployment:

• replicas: 3 - три копии приложения
• selector.matchLabels - критерий принадлежности Pod
• template.metadata.labels - метки, которые проставляются каждому Pod
• containers.image - образ для запуска

Ключевые поля Service:

• selector - выбор Pod по метке app: nginx
• port - порт, на котором Service принимает трафик
• targetPort - порт контейнера, куда направляется трафик

Применение манифестов и проверка

Примените оба файла:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Проверьте состояние объектов:

kubectl get pods
kubectl get deployments
kubectl get services

Пример вывода команды kubectl get pods после запуска Deployment:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6f7f7b9d8c-2m5kq   1/1     Running   0          48s
nginx-deployment-6f7f7b9d8c-7v9rx   1/1     Running   0          48s
nginx-deployment-6f7f7b9d8c-k4n8p   1/1     Running   0          48s

• NAME - имя Pod. Суффикс генерируется Deployment, поэтому в вашем выводе он будет другим.
• READY - число готовых контейнеров и общее число контейнеров внутри Pod. Значение 1/1 означает, что единственный контейнер готов.
• STATUS - текущее состояние Pod. Running означает, что контейнер запущен.
• RESTARTS - количество перезапусков контейнера. Нулевое значение обычно означает, что с момента создания сбоев не было.
• AGE - сколько времени прошло с момента создания Pod.

Вывод покажет три Pod в статусе Running, Deployment с тремя готовыми репликами и Service с присвоенным ClusterIP. Если Pod долго в статусе ContainerCreating, дождитесь загрузки образа.

Доступ к сервису извне

Service типа ClusterIP доступен только внутри кластера. Для доступа с хост-машины используйте проброс порта:

kubectl port-forward service/nginx-service 8080:80

Теперь откройте http://localhost:8080 в браузере. Вы увидите страницу Nginx. Команда работает, пока открыт терминал. Для постоянного внешнего доступа нужен Service типа NodePort или LoadBalancer, а для HTTP-маршрутизации - Ingress.

Если вы разворачиваете приложение не локально, а на облачной инфраструктуре, Timeweb Cloud предоставляет готовые ресурсы для размещения кластеров и сопутствующих сервисов.

Ключевые команды kubectl для повседневной работы

Шпаргалка по основным командам, которые закрывают большинство ежедневных задач:

• kubectl get pods - список Pod с кратким статусом
• kubectl get deployments - список Deployment с количеством реплик
• kubectl get services - список Service с портами и IP
• kubectl describe pod <имя> - детальная информация о Pod, включая события
• kubectl logs <имя-pod> - логи контейнера
• kubectl exec -it <имя-pod> -- sh - интерактивная оболочка внутри контейнера
• kubectl delete pod <имя> - удаление Pod
• kubectl delete -f файл.yaml - удаление объекта по манифесту
• kubectl get events --sort-by=.metadata.creationTimestamp - события кластера, полезны при отладке

Добавьте флаг -w к kubectl get для наблюдения за изменениями в реальном времени. Флаг -o wide выводит дополнительные колонки: IP Pod, узел, на котором он запущен.

Типичные ошибки и их решение

Три статуса Pod вызывают больше всего вопросов у новичков. Разберем причины и способы диагностики.

ImagePullBackOff - Kubernetes не может скачать образ. Причины: опечатка в имени образа, несуществующий тег, закрытый реестр без авторизации. Проверьте имя образа в манифесте и доступность реестра:

kubectl describe pod <имя-pod>

В секции Events будет точная ошибка: Failed to pull image с деталями.

CrashLoopBackOff - контейнер запускается и сразу падает. Приложение завершается с ошибкой. Смотрите логи:

kubectl logs <имя-pod> --previous

Флаг --previous показывает логи предыдущей попытки запуска, где обычно и находится причина.

Pending - Pod не может быть запланирован на узел. Частая причина на локальном кластере - нехватка ресурсов. Проверьте запросы ресурсов в манифесте и доступные ресурсы узла:

kubectl describe pod <имя-pod>
kubectl top nodes

Если kubectl top недоступен, установите metrics-server через minikube addons enable metrics-server.

Мини-FAQ по minikube и kubectl

Что делать, если minikube не стартует?

Сначала проверьте состояние и диагностический вывод. Частые причины - отключенная аппаратная виртуализация, неработающий Docker или неподходящий драйвер:

minikube status
minikube logs --problems

Если локальный кластер можно пересоздать, удалите профиль и запустите его с подходящим драйвером. Команда minikube delete удаляет локальный кластер вместе с его объектами, поэтому не используйте её для окружения с нужными данными.

Как сменить драйвер minikube?

Для нового локального кластера задайте драйвер по умолчанию или укажите его только для одного запуска:

minikube config set driver docker
minikube start

Разовый вариант не меняет настройку по умолчанию:

minikube start --driver=hyperv

Если существующий профиль не запускается с новым драйвером, сначала удалите его командой minikube delete, затем задайте драйвер и создайте кластер заново.

Как переключить контекст kubectl?

Если команды выполняются не в том кластере, посмотрите доступные контексты и выберите нужный:

kubectl config get-contexts
kubectl config use-context minikube
kubectl config current-context

Команда kubectl config current-context должна вывести minikube. Перед удалением или изменением объектов всегда проверяйте текущий контекст.

Что дальше: следующие шаги в изучении Kubernetes

Базовые объекты закрывают запуск простых сервисов. Для реальных проектов добавьте в арсенал:

• ConfigMap и Secret - вынос конфигурации и чувствительных данных из образов
• Ingress - HTTP-маршрутизация по доменам и путям, замена множеству Service типа LoadBalancer
• Helm - пакетный менеджер для Kubernetes, шаблонизация манифестов и управление релизами
• Prometheus и Grafana - сбор метрик и визуализация состояния кластера

Для перехода от локального окружения к production-кластеру изучите пошаговую установку кластера с kubeadm. Если нужно развернуть микросервисную архитектуру с несколькими компонентами, обратитесь к гайду по развертыванию микросервисов. Для системного понимания проектирования production-окружений подойдет руководство по проектированию кластеров.