Kubernetes для начинающих: запуск сервисов с минимальной конфигурацией

Что такое 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-устройств. Потребляет меньше ресурсов, ставится одной командой.

Для обучения выбирайте minikube. Он дает изолированное окружение с привычным поведением кластера и минимумом сюрпризов при настройке сети и хранилищ.

Установка 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

Запустите кластер:

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 - стабильный доступ к подам

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 автоматически балансирует нагрузку между репликами.

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

Соберем все вместе: развернем 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

Вывод покажет три 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.

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

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

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

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