Kubernetes для начинающих: полное руководство по внедрению в 2025 году

Развернуть тестовый кластер Kubernetes можно за 15 минут. Довести его до продакшена — за несколько недель мучительной отладки. Разница между этими двумя этапами и есть настоящая сложность Kubernetes. В этом руководстве мы разберём каждый аспект, который нужно продумать до развёртывания, а не после.

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

Kubernetes (K8s) — система оркестрации контейнеров, которая автоматически управляет развёртыванием, масштабированием и отказоустойчивостью приложений. Кластер состоит из управляющих узлов (Control Plane) и рабочих узлов (Worker Nodes).

Ключевой принцип — декларативность: вы описываете желаемое состояние системы, а Kubernetes сам приводит реальность в соответствие. Если под упал — пересоздаст. Если узел вышел из строя — перенесёт нагрузку.

Распределённая база etcd хранит всю конфигурацию и состояние кластера. Для продакшена etcd рекомендуется размещать на выделенных узлах, отдельно от Control Plane, с ограничением базы до 8 ГБ (лимит etcd по умолчанию).

Когда Kubernetes действительно нужен

Прежде чем инвестировать месяцы в изучение K8s, ответьте на вопросы:

• Нужна ли отказоустойчивость с автоматическим восстановлением?
• Требуется ли динамическое масштабирование под нагрузкой?
• Необходимы ли частые обновления без простоя (rolling updates)?
• Есть ли микросервисная архитектура или план перехода на неё?

Если на большинство ответов «нет» — вам, скорее всего, хватит Docker Compose или простого VPS. Как справедливо замечают опытные инженеры: «Не усложняйте инфраструктуру ради маленьких проектов».

Архитектура кластера: Control Plane и Worker Nodes

Control Plane включает несколько компонентов:

• kube-apiserver — точка входа для всех API-запросов
• etcd — распределённое key-value хранилище состояния
• kube-scheduler — распределяет поды по узлам
• kube-controller-manager — следит за соответствием реального и желаемого состояния

Worker Nodes выполняют рабочую нагрузку:

• kubelet — агент на каждом узле, управляющий подами
• kube-proxy — обеспечивает сетевую маршрутизацию к сервисам
• Container Runtime — запускает контейнеры (containerd, CRI-O)

Важный нюанс: etcd — часть Control Plane

Распространённое заблуждение — считать etcd отдельным компонентом. Технически etcd входит в состав Control Plane, но для продакшена его часто выносят на отдельные узлы для повышения надёжности и производительности.

Способы установки: от песочницы до продакшена

Начните с Minikube — локальной песочницы на вашем компьютере. Она позволяет разобраться с базовыми концепциями (Pod, Service, Deployment) без риска что-то сломать.

Kubeadm — путь самурая

Официальный инструмент установки. Максимальный контроль, но и максимум ручной работы. Не рекомендуется для первого развёртывания.

Kubespray — рекомендованный выбор

Использует Ansible для автоматизации установки. Покрывает ~90% рутины: установка компонентов, настройка сети, certificates management.

# Клонируем Kubespray
git clone https://github.com/kubernetes-sigs/kubespray.git
cd kubespray

# Устанавливаем зависимости
pip install -r requirements.txt

# Копируем шаблон инвентаря
cp -rfp inventory/sample inventory/mycluster

# Генерируем инвентарь для наших узлов
declare -a IPS=(10.10.1.3 10.10.1.4 10.10.1.5)
CONFIG_FILE=inventory/mycluster/hosts.yaml \
  python3 contrib/inventory_builder/inventory.py ${IPS[@]}

# Запускаем установку
ansible-playbook -i inventory/mycluster/hosts.yaml \
  --become --become-user=root cluster.yml

Специализированные дистрибутивы

Talos OS — минимализм: нет shell, управление только через API. Максимальная безопасность, но требует изменения парадигмы администрирования.

Fedora CoreOS / Flatcar — read-only root filesystem, атомарные обновления, конфигурация через Ignition.

Выбор ОС для узлов кластера

Для стандартных задач — Ubuntu LTS (22.04 или 24.04). Хорошо документирована, огромное сообщество, стабильные LTS-циклы.

Debian — чуть более консервативный выбор с ещё большей стабильностью. CentOS Stream / Rocky Linux — для тех, кто привык к RHEL-экосистеме.

Container Runtime: почему containerd, а не Docker

Docker как runtime удалён из Kubernetes начиная с версии 1.24. Это не значит, что Docker-образы перестали работать — они по-прежнему совместимы. Но runtime теперь другой.

• containerd (рекомендация) — де-факто стандарт, нативная поддержка CRI
• CRI-O — альтернатива от Red Hat, функционально аналогична
• Kata Containers — для сценариев с требованиями изоляции (легковесные VM)

Хранилище данных: никогда не используйте локальные диски

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

Kubernetes использует CSI (Container Storage Interface) для подключения различных систем хранения.

Ceph + Rook — основное решение

Rook — оператор, который управляет Ceph прямо внутри Kubernetes. Ceph объединяет диски всех узлов в распределённый пул с автоматической репликацией.

Как это работает: приложение запрашивает PVC (Persistent Volume Claim) → Kubernetes провиженит PV → Ceph создаёт блочное устройство → монтирует в под.

Альтернативы

• LINSTOR — потенциально лучшая производительность в специфических сценариях
• Облачные CSI: EBS (AWS), Persistent Disk (GCP), Azure Disk
• StorageClass — абстракция, позволяющая выбирать fast-ssd, slow-hdd, cloud-premium
• Local Volumes + Helm — для dev/staging, где потеря данных допустима

Сеть в Kubernetes: самая сложная тема

Сеть — «пожалуй, самая сложная тема» даже для опытных администраторов. Минимальный набор знаний: IP-адресация, маршрутизация, файрволы.

Каждый под получает виртуальный IP. Поды на разных узлах общаются через оверлейную сеть, управляемую CNI-плагином.

Cilium — лидер среди CNI

Использует eBPF для оптимизации на уровне ядра. Включает Hubble — инструмент визуализации сетевых потоков и зависимостей между сервисами. Мощные возможности отладки.

Calico — проверенный выбор

Зрелый и популярный. Поддерживает оверлейные сети (VXLAN, IPIP) и нативную BGP-маршрутизацию. По умолчанию используется в Kubespray.

Типы сервисов

• ClusterIP — только внутренний IP. Для бэкенд-сервисов.
• NodePort — открывает порт на всех узлах. Неудобно и небезопасно для продакшена.
• LoadBalancer — в облаке создаёт внешний балансировщик. Для bare metal нужен MetalLB.

Ingress и балансировка трафика

Ingress работает как HTTP/HTTPS реверс-прокси с маршрутизацией по хостнеймам и путям, терминацией TLS.

• Nginx Ingress — знакомый и мощный, но обнаружены уязвимости безопасности
• Traefik — автоматически получает сертификаты Let's Encrypt
• HAProxy Ingress — высокая производительность

Безопасность: секреты, RBAC и пространства имён

Никогда не хардкодьте пароли в коде или YAML-манифестах.

• Secrets — хранение паролей, токенов, сертификатов (base64 в etcd, шифрование at-rest)
• ConfigMaps — несекретная конфигурация (URL, параметры)
• External Secrets Operator или HashiCorp Vault — для централизованного управления

RBAC — управление доступом

Золотое правило — минимальные привилегии. Определяйте Role/ClusterRole с конкретными разрешениями (get, list, create, update, delete) и привязывайте через RoleBinding.

Namespace — логическая изоляция ресурсов по команде, проекту или среде. Упрощает RBAC, но для настоящей изоляции сред рекомендуются отдельные кластеры.

Мониторинг и логирование: не летите вслепую

Без мониторинга кластер управляется «вслепую». Три столпа наблюдаемости:

Метрики

• Metrics Server — базовый компонент (CPU/RAM узлов и подов)
• Prometheus + Grafana — отраслевой стандарт
• Приложения должны экспортировать кастомные метрики через /metrics

Логирование

• Контейнеры пишут в stdout/stderr → агенты собирают логи
• Fluent Bit или Promtail на каждом узле
• ELK (Elasticsearch + Kibana) или Loki + Grafana
• Обязательно структурированные логи (JSON)

Трассировка

Для микросервисов: Jaeger, Zipkin или Tempo. Требует поддержки в приложении — передача trace headers.

Автомасштабирование: горизонтальное, вертикальное, кластерное

HPA (Horizontal Pod Autoscaler) — самый полезный. Автоматически регулирует количество реплик по метрикам (CPU, RAM, кастомные метрики из Prometheus).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

VPA (Vertical Pod Autoscaler) — анализирует потребление и корректирует requests/limits. Используйте осторожно вместе с HPA.

Cluster Autoscaler — добавляет/удаляет узлы. В managed K8s работает «из коробки». Для self-hosted нужен Cluster API.

Операторы: автоматизация сложных приложений

Операторы — контроллеры, управляющие сложными приложениями (базы данных, очереди, мониторинг). Расширяют API Kubernetes через CRD (Custom Resource Definitions).

Пример: установив PostgreSQL Operator, вы создаёте простой YAML с kind: PostgresCluster, replicas: 3, а оператор автоматически настраивает StatefulSets, PVC, репликацию и бэкапы.

Подготовка приложений: принципы 12-Factor App

Kubernetes требует, чтобы приложения были готовы к эфемерной среде:

• Конфигурация через переменные окружения или подмонтированные файлы
• Логи — только в stdout/stderr
• Stateless-дизайн (состояние — во внешнем хранилище)
• Быстрый запуск и корректная обработка SIGTERM
• Health-check и metrics эндпоинты
• Лёгкие Docker-образы (multi-stage build)

CI/CD: от коммита до продакшена

Типичный пайплайн:

1. Разработчик коммитит в Git
2. CI собирает Docker-образ и пушит в реестр (Harbor, GitLab Registry)
3. Обновляются YAML-манифесты с новым тегом образа
4. CD инструмент (Argo CD, Flux) применяет изменения
5. Выполняются post-deployment тесты
6. При ошибке — автоматический rollback

Helm: пакетный менеджер Kubernetes

Helm — один из инструментов, которые не упоминают в «быстрых стартах», но без которого невозможно представить реальную эксплуатацию Kubernetes. Это пакетный менеджер, аналог apt или yum для кластера. С помощью Helm Charts вы устанавливаете сложные приложения одной командой вместо десятков YAML-манифестов.

# Установка Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Добавление репозитория
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Установка PostgreSQL в кластер одной командой
helm install my-postgres bitnami/postgresql \
  --set auth.postgresPassword=secretpassword \
  --set primary.persistence.size=50Gi \
  --namespace databases --create-namespace

# Просмотр установленных чартов
helm list -A

Chart можно кастомизировать через values-файл — это YAML с параметрами, которые переопределяют настройки по умолчанию. Создавайте свои чарты для внутренних приложений — это драматически упрощает CI/CD.

Практический пример: развёртывание веб-приложения

Рассмотрим типичный сценарий — деплой веб-приложения с базой данных в Kubernetes. Этот пример покажет, как все компоненты связываются вместе на практике.

Шаг 1: Namespace и секреты

apiVersion: v1
kind: Namespace
metadata:
  name: webapp
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: webapp
type: Opaque
stringData:
  DB_HOST: "postgres-svc"
  DB_USER: "webapp"
  DB_PASS: "strongpassword123"
  DB_NAME: "webapp_production"

Шаг 2: Deployment с health checks

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: myregistry/webapp:v1.2.3
        ports:
        - containerPort: 8080
        envFrom:
        - secretRef:
            name: db-credentials
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

Шаг 3: Service и Ingress

apiVersion: v1
kind: Service
metadata:
  name: webapp-svc
  namespace: webapp
spec:
  selector:
    app: webapp
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: webapp
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: webapp-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-svc
            port:
              number: 80

Обратите внимание на ключевые элементы: resources задают гарантированные и максимальные ресурсы, livenessProbe перезапускает зависший контейнер, readinessProbe убирает под из балансировки, пока он не готов принимать трафик.

Сетевые политики (Network Policies)

По умолчанию все поды в Kubernetes могут общаться друг с другом. Для продакшена это неприемлемо — нужна изоляция. Network Policies работают как файрвол внутри кластера:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-webapp-to-db
  namespace: webapp
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: webapp
    ports:
    - protocol: TCP
      port: 5432

Эта политика разрешает подключение к PostgreSQL только от подов с меткой app: webapp. Все остальные подключения будут заблокированы. Для работы Network Policies CNI-плагин должен их поддерживать — Calico и Cilium поддерживают, Flannel — нет.

Troubleshooting: типичные проблемы новичков

На основе реального опыта сообщества — самые частые грабли при первом знакомстве с Kubernetes:

Pod в статусе CrashLoopBackOff

Контейнер запускается и сразу падает. Диагностика:

# Посмотреть логи контейнера
kubectl logs pod-name -n namespace --previous

# Описание пода — события, причины ошибок
kubectl describe pod pod-name -n namespace

# Запустить интерактивную оболочку для отладки
kubectl run debug --image=busybox --rm -it -- sh

Частые причины: неправильные переменные окружения, отсутствие зависимых сервисов, нехватка памяти (OOMKilled), ошибка в CMD/ENTRYPOINT образа.

Под не может подключиться к сервису

Проверьте: 1) Сервис существует и label selector совпадает с подом, 2) Pod находится в правильном namespace, 3) Network Policy не блокирует трафик, 4) DNS работает (kubectl run test --image=busybox --rm -it -- nslookup service-name.namespace).

Persistent Volume не монтируется

Если PVC завис в статусе Pending — проверьте: StorageClass существует, provisioner работает, есть свободное место на дисках. Для Ceph/Rook проверьте статус кластера: kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph status.

Ресурсы для продолжения обучения

Kubernetes — это марафон, а не спринт. Вот проверенный путь обучения:

1. Minikube — установите, поиграйте с kubectl, создайте свой первый Deployment
2. Официальный туториал — kubernetes.io/docs/tutorials/ — пройдите все базовые модули
3. Kubespray — поднимите кластер из 3 узлов на VPS — это научит вас больше, чем любая книга
4. Книги: «Production Kubernetes» (O'Reilly), «Kubernetes Patterns» (Red Hat), «Networking and Kubernetes» (O'Reilly)
5. Lens IDE — графический интерфейс для управления кластерами, существенно упрощает навигацию
6. CKA сертификация — когда освоите основы, подготовка к Certified Kubernetes Administrator структурирует знания

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

Можно ли использовать Kubernetes на одном сервере?

Технически да (single-node кластер через Minikube или k3s), но это убивает главное преимущество — отказоустойчивость. Для одного сервера Docker Compose проще и эффективнее.

Почему Docker удалён из Kubernetes?

Docker включал слишком много лишнего для K8s. Containerd — это тот же runtime, что использовался внутри Docker, но без оверхеда. Ваши Docker-образы по-прежнему работают.

Helm — обязательный инструмент?

Не обязательный, но крайне рекомендуемый. Helm — пакетный менеджер для Kubernetes, упрощающий развёртывание сложных приложений через переиспользуемые чарты.

Ceph — единственный вариант хранилища?

Нет. Для облаков используйте нативные CSI-драйверы (EBS, Persistent Disk). Для bare metal также есть LINSTOR, OpenEBS, Longhorn. Ceph — самый функциональный, но и самый сложный.

Что делать, если сертификаты истекли?

Ротация сертификатов зависит от сценария, обычно раз в год. Kubespray может автоматизировать обновление. Для критичных систем (финансы, 100+ TPS) настройте мониторинг сроков.

Стоит ли писать Kubernetes на AI?

Генеративный AI может помочь с шаблонами YAML и отладкой, но доверять ему архитектурные решения рискованно. Всегда проверяйте сгенерированные конфигурации вручную.

Какие книги рекомендуете для изучения?

«Production Kubernetes» (O'Reilly, есть на русском), «Networking and Kubernetes» (O'Reilly), «Kubernetes Patterns» (Red Hat). Начните с официальных туториалов на kubernetes.io.

Читайте также

• Мониторинг серверов на Debian
• Аудит перезагрузок Windows Server
• Память Dell PowerEdge R640
• Мониторинг SSL-сертификатов