Что такое Kubernetes: понятные схемы и первый запуск приложения

Один пример: должны работать две копии сайта

Копия приложения в этой схеме — отдельный экземпляр программы, а не резервная копия данных. Если экземпляр пропал, Kubernetes может создать замену. Для этого нужны ресурсы, доступный образ и исправная инфраструктура. Прикладные ошибки и потерянные данные он сам не исправляет.

Контейнеры разобраны в предыдущей статье о Docker. Здесь следующий вопрос: кто следит за множеством таких экземпляров и размещает их на серверах?

Где управление, а где работают приложения

Node, или узел — физический сервер либо ВМ, участвующая в кластере. Control plane — управляющая часть: принимает описания, хранит состояние и организует работу. Worker — узел, на котором запускаются приложения. Состав компонентов показан в официальном обзоре.

В управляющей части API server принимает запросы, scheduler подбирает узел для нового Pod, контроллеры следят за соответствием плану. На рабочем узле kubelet и контейнерная среда обеспечивают запуск. Примеры сред — containerd и CRI-O; установка Docker Engine на каждый worker не является обязательным условием Kubernetes.

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

Pod и контейнер: какая коробка внутри какой

Pod — минимальная единица размещения в Kubernetes. В простом примере внутри него один контейнер сайта. Иногда Pod содержит несколько тесно связанных контейнеров с общей сетью и подключёнными ресурсами.

Две копии сайта обычно означают два Pod, а не два одинаковых сайта внутри одного Pod. Их можно разместить на разных узлах при подходящей конфигурации и ресурсах. Это важно для обслуживания и переживания отказов. Размещение на разных физических узлах не гарантируется самим числом replicas.

Как посетитель попадает на нужную копию сайта

Service даёт приложению устойчивую точку обращения к подходящим Pod. Они могут заменяться и получать другие IP, а клиенту не нужно хранить их список вручную. В нашем примере Service выбирает экземпляры по метке app: avg-k8s-web.

Service типа ClusterIP по умолчанию предназначен для доступа внутри кластера. Для внешнего сайта отдельно нужны входной компонент, домен и HTTPS: например, подходящая реализация Gateway или Ingress, либо внешний балансировщик. Объект LoadBalancer требует соответствующей инфраструктурной реализации; в локальном стенде она не появляется автоматически.

Балансировка не гарантирует строго одинаковую долю запросов каждому экземпляру: влияют протокол, соединения и выбранная реализация. Service также не синхронизирует корзины, загруженные файлы и состояние пользователей между копиями приложения.

Что произойдёт, если один экземпляр исчезнет

В примере Deployment задаёт нужное число одинаковых экземпляров приложения. Если удалить управляемый им Pod, контроллер обнаружит, что их стало меньше, и создаст замену. Самостоятельно созданный Pod без такого контроллера не следует считать равнозначной схемой.

Новый экземпляр может появиться не сразу: нет памяти, не скачивается образ, недоступно хранилище, не проходит проверка готовности. При отказе целого узла добавляются обнаружение отказа, правила пересоздания и ограничения данных. Поэтому «самовосстановление» не означает отсутствие паузы для пользователя.

Куда девать данные, если Pod заменяется

Файлы в удаляемом слое контейнера не должны быть единственным местом хранения заказов. Для постоянных данных используют внешние системы или подходящее хранилище. PVC — запрос приложения на постоянный том; PV — ресурс хранения, с которым этот запрос связывается. Фактическое подключение обеспечивает инфраструктура хранения, обычно через CSI-драйвер.

Том на локальном диске одного узла не становится доступным другому узлу автоматически. Режимы доступа, размещение, возможность переподключения и правила удаления тома проверяют по выбранному хранилищу. Три экземпляра СУБД с одним общим каталогом данных — не рецепт исправной репликации.

StatefulSet помогает управлять идентичностью и хранением экземпляров, но сам не создаёт корректную репликацию PostgreSQL или SQL Server. Нужны поддерживаемая схема СУБД, резервные копии и испытание восстановления. Удаление PVC тоже может затронуть данные в зависимости от политики хранения.

«Запущен» и «готов отвечать» — разные состояния

В проверках Kubernetes readiness управляет готовностью к обслуживанию, а liveness может инициировать перезапуск. Startup probe применяют для приложений с длительным стартом.

Неверная проверка способна исключить здоровое приложение из обслуживания или устроить цикл перезапусков. Нельзя заставлять все экземпляры бесконечно перезапускаться из-за краткого отказа общей СУБД. Проверки выбирают под поведение конкретного приложения; факт ответа служебного URL не доказывает успешное выполнение бизнес-операции.

Как добавить мощности и что означает масштабирование

Можно изменить желаемое число экземпляров с двух на три. Kubernetes попытается разместить дополнительный Pod. Если все узлы заполнены, он может остаться в ожидании. Добавление Pod не создаёт новый физический сервер и не ускоряет общую перегруженную базу данных.

Для автоматического изменения числа экземпляров существует HPA. Ему нужны метрики и настройки; это не включённая по умолчанию способность нашего проекта. Увеличение числа узлов — отдельная задача инфраструктуры и, при необходимости, отдельного механизма автомасштабирования.

Requests помогают планировать необходимые ресурсы, limits ограничивают потребление контейнера. В документации ресурсов объяснены CPU и память. 100m CPU — одна десятая CPU; слишком жёсткий лимит может ухудшить время ответа, а превышение memory limit — привести к завершению процесса.

Учебный стенд: сначала проверьте инструменты

Дальше — практическая часть для отдельного компьютера с доступным Docker, установленными kind и kubectl. kind создаёт локальные Kubernetes-узлы в контейнерах. Это учебный кластер, а не production-топология.

docker info
kind version
kubectl version --client

Ожидается информация о доступном Docker и инструментах. Установка зависит от ОС и архитектуры; используйте официальные инструкции. На рабочем месте подготовки статьи Docker, kind и kubectl отсутствуют: реального запуска не было.

kind create cluster --name avg-k8s-demo --wait 120s
kubectl --context kind-avg-k8s-demo get nodes

Первая команда создаёт отдельный локальный кластер. Вторая показывает его узел; ожидается Ready после подготовки. Если имя уже занято, сначала выясните, что это за кластер. Во всех дальнейших kubectl-командах явно указан этот контекст, чтобы не полагаться на случайно выбранный рабочий сервер.

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

Описываем приложение: две копии и Service

Сохраните файл demo.yaml из проекта ниже. Он содержит три объекта: учебное пространство имён, Deployment и внутренний Service.

apiVersion: v1
kind: Namespace
metadata:
  name: avg-k8s-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: avg-k8s-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: avg-k8s-web
  template:
    metadata:
      labels:
        app: avg-k8s-web
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: avg-k8s-demo
spec:
  type: ClusterIP
  selector:
    app: avg-k8s-web
  ports:
    - port: 80
      targetPort: 80

replicas: 2 — хотим два экземпляра. Метки Deployment, Pod и selector Service согласованы: так Service найдёт нужные Pod. Ресурсы заданы для каждого контейнера. Путь / подходит учебному NGINX, но не является универсальным healthcheck для любого сервиса.

В примере нет СУБД и постоянных заказов: это стандартная страница NGINX без изменяемых бизнес-данных. Тег nginx:alpine учебный и изменяемый. Для рабочей поставки выбирают проверенный образ и фиксируют digest.

Применяем описание и проверяем готовность

kubectl --context kind-avg-k8s-demo apply --dry-run=client -f demo.yaml
kubectl --context kind-avg-k8s-demo apply -f demo.yaml
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout status deployment/web --timeout=120s
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo get deployments,pods,services

Первая команда выполняет клиентскую предварительную проверку; это не полное испытание совместимости и не гарантия запуска. Вторая создаёт или обновляет объекты. Третья ожидает развёртывание. Четвёртая показывает результат: у Deployment должны быть доступны две копии, Pod — готовы к работе, Service — создан.

Если rollout завершился по тайм-ауту, объект мог остаться в кластере. Не считайте это автоматическим откатом. Смотрите состояние и события, исправляйте причину либо выполняйте согласованный возврат.

Открываем сайт из браузера

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo port-forward --address 127.0.0.1 service/web 18090:80

Оставьте команду работающей в отдельном терминале и откройте http://127.0.0.1:18090/. Здесь 18090 — порт вашего компьютера, 80 — порт Service. Ожидается стандартная страница NGINX.

curl -I http://127.0.0.1:18090/

Это дополнительная HTTP-проверка из другого терминала. Port-forward — временный учебный доступ через kubectl, а не публикация сайта в интернет и не испытание балансировки между всеми экземплярами. Если выбранный Pod заменился, подключение может потребоваться запустить заново. Для остановки используйте Ctrl+C.

Проверяем изменение числа экземпляров и замену Pod

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo scale deployment/web --replicas=3
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout status deployment/web --timeout=120s
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo get pods -o wide

Ожидается три готовых Pod. В локальном одноузловом стенде они могут находиться на одном узле — это ожидаемо. Учтите, что в demo.yaml по-прежнему записано 2: следующее применение файла может вернуть это число. Для постоянного изменения обновите источник конфигурации.

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo get pods
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo delete pod ИМЯ_ОДНОГО_УЧЕБНОГО_POD
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo get pods -w

Во второй строке подставьте точное имя одного из Pod этого учебного Deployment. После удаления должен появиться новый, чтобы восстановить заданное количество. Наблюдение останавливается Ctrl+C. Это проверка реакции на удаление Pod, а не на отказ узла, потерю СУБД или обрыв внешней сети.

Обновление приложения и возврат

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo set image deployment/web nginx=nginx:stable-alpine
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout status deployment/web --timeout=120s
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout history deployment/web

Учебная команда меняет ссылку на образ контейнера nginx. Kubernetes обновляет Pod согласно стратегии Deployment. Оба тега могут меняться; это демонстрация механизма, а не рекомендация выпускать приложение без фиксированных версий.

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout undo deployment/web
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo rollout status deployment/web --timeout=120s

Возврат использует доступную предыдущую ревизию шаблона Pod. Он не восстанавливает базу данных, удалённые файлы или внешние настройки. История Deployment, доступность старого образа и совместимость схемы данных должны быть частью рабочего плана обновления.

Если приложение не запускается

kubectl --context kind-avg-k8s-demo -n avg-k8s-demo describe deployment web
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo get events --sort-by=.metadata.creationTimestamp
kubectl --context kind-avg-k8s-demo -n avg-k8s-demo logs deployment/web --tail=100

В рабочей системе сохраняют метрики, события и журналы централизованно: CPU, память, перезапуски, готовность, задержки запросов, ошибки и состояние зависимостей. Смена Pod не должна уничтожать единственное свидетельство инцидента.

Что нужно для рабочего кластера помимо запуска

• Доступ: персональные учётные записи, RBAC, защищённый API и аудит.
• Образы: происхождение, исправления, сканирование и хранение точных версий.
• Сеть: разрешённые связи, входной трафик и поддерживаемые сетевые политики.
• Настройки: ConfigMap для обычной конфигурации, защищённый процесс работы с Secret.
• Данные: согласованное хранение, копии и проверка восстановления.
• Обслуживание: обновление узлов и управляющей части, мониторинг и ответственные.

Secret не следует считать автоматически зашифрованным сейфом только из-за названия: нужны права доступа и настройки защиты. Kubeconfig с административными полномочиями нельзя передавать приложению как обычный конфигурационный файл.

etcd хранит состояние Kubernetes, а не заменяет прикладную СУБД. Его резервирование и восстановление нужны управляющей части; данные приложения и внешние системы копируют отдельно. Проверка «кластер снова видит Pod» не равна восстановлению заказов покупателей.

Нужен ли Kubernetes небольшой компании?

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

Сравнивают не только цену ВМ, но и труд сопровождения, хранение, сеть, резервирование, мониторинг, обновления и навыки команды. Управляемый кластер провайдера уменьшает часть инфраструктурных задач, но ответственность за приложение, данные, доступы и приёмку не исчезает.

Хороший первый шаг — выбрать один некритичный сервис без сложного состояния, определить критерии успеха и отработать развёртывание, обновление и восстановление. Установка Kubernetes ради самого названия не является бизнес-результатом.

Завершаем учебный опыт

kubectl --context kind-avg-k8s-demo delete namespace avg-k8s-demo
kind delete cluster --name avg-k8s-demo

Первая команда удаляет объекты в учебном namespace. Вторая уничтожает именно созданный кластер kind; её выполняют только после окончания опыта. Эти действия не подходят для произвольного рабочего кластера. Не используйте вместо них массовое удаление всех Docker-ресурсов.

Материалы для практики и планирования

Файлы проверены статически; реального применения к Kubernetes не выполнялось. Перед запуском проверьте контекст, требования инструментов и доступность образов.

Поможем выбрать и сопровождать инфраструктуру

Вопросы и ответы