Управление Kubernetes-кластером через манифесты: базовые сущности и их роль

В этом материале рассмотрим:

• что такое K8S-манифесты и в каком формате они описываются;

• какие сущности лежат в основе Kubernetes-кластера;

• как они помогают в управлении приложениями.

---

Что такое манифесты в Kubernetes

Манифесты — это файлы описания сущностей, через которые мы управляем ресурсами внутри кластера. Kubernetes понимает два формата:

• JSON — чаще применяется для генераторов и автоматизации;

• YAML — удобен для чтения и редактирования человеком.

Важно: любой корректный JSON одновременно является валидным YAML-документом. Поэтому если вы знакомы с JSON, переход на YAML пройдет без проблем.

Пример простого Pod’а в YAML:

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    role: Testrole
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP

В этом примере описан Pod с контейнером Nginx, доступным по порту 80. В следующих статьях мы подробно разберем все элементы подобного описания.

---

Базовые сущности Kubernetes

Чтобы уверенно управлять кластером, нужно знать «язык» Kubernetes — его ключевые объекты. Вот основные:

• Container — часть Pod’а, сам по себе сущностью не является.

• Pod — минимальная единица развертывания приложения. Может содержать один или несколько контейнеров.

• ReplicaSet — следит за тем, чтобы количество Pod’ов соответствовало заданному.

• Deployment — декларативное обновление Pod’ов и ReplicaSet’ов. Используется для stateless-приложений, например веб-серверов.

• StatefulSet — подходит для приложений с сохранением состояния: базы данных, key-value хранилища.

• DaemonSet — гарантирует запуск определенного Pod’а на каждой ноде. Часто используется для системных сервисов — например, сбора логов.

• Job / CronJob — выполняет задачи до завершения. CronJob позволяет запускать их по расписанию (например, резервные копии).

• Labels и Selectors — «метки» в формате ключ-значение, которые помогают группировать и находить объекты.

• Namespaces — логическое разделение ресурсов внутри кластера, аналог виртуальных машин.

• Service — объединяет Pod’ы в единый сетевой сервис с правилами доступа.

• Annotations — дополнительные метаданные, что-то вроде заметок для объектов.

• ConfigMap — хранение конфигураций.

• Secret — безопасное хранение конфиденциальных данных (пароли, токены).

---

Минимальная «боевая единица» Kubernetes

Основным строительным блоком Kubernetes является Pod. Именно через Pod запускается ваше приложение в кластере. В зависимости от того, как оно должно работать (статически или с динамическим масштабированием, с сохранением состояния или без него), вы будете использовать разные сущности: Deployment, StatefulSet, DaemonSet и другие.

Понимание того, как связаны эти объекты и зачем они нужны, позволит уверенно управлять любым Kubernetes-кластером.

Разберёмся подробнее, чем отличаются ReplicaSet, Deployment, StatefulSet и DaemonSet, зачем они нужны и приведём простые примеры.

🔹 ReplicaSet

Задача: поддерживать нужное количество Pod’ов в кластере.

Представьте, что у вас есть сайт, и вы хотите, чтобы он был доступен всегда. Если один Pod с вашим сайтом «упадёт», ReplicaSet автоматически поднимет новый, чтобы общее количество Pod’ов совпадало с заданным.

👉 Пример:
Вы указали, что должно быть 3 Pod’а с приложением. Если один Pod перестанет работать — ReplicaSet запустит новый.

📌 Используется: когда важно поддерживать доступность приложения.
⚠️ Но! ReplicaSet не умеет обновлять Pod’ы на новую версию — только следит за количеством.

---

🔹 Deployment

Задача: управлять Pod’ами и ReplicaSet’ами, обеспечивая удобное обновление приложений.

Deployment работает «поверх» ReplicaSet. Он позволяет:

• описать приложение декларативно (через YAML-манифест);

• обновлять Pod’ы постепенно (например, выкатывать новую версию без остановки старой);

• откатываться к предыдущей версии, если новая не работает.

👉 Пример:
У вас есть веб-сервер (nginx). Сегодня он версии 1.23, а завтра вышла 1.24. Вы меняете образ в Deployment, и Kubernetes постепенно перезапускает Pod’ы: часть работает на старой версии, часть на новой. Пользователи не заметят перебоев.

📌 Используется: для stateless-приложений (не хранящих данные внутри себя), например: веб-сервер, API, микросервис.

---

🔹 StatefulSet

Задача: управлять приложениями, которые должны сохранять состояние.

Если у Pod’а есть данные, которые нельзя терять при перезапуске (например, база данных), то нужен StatefulSet. Он даёт:

• уникальные имена Pod’ам (mysql-0, mysql-1, mysql-2);

• постоянное хранилище (PersistentVolume), чтобы при пересоздании Pod’а данные не потерялись;

• последовательный запуск и остановку Pod’ов (важно для кластеров БД).

👉 Пример:
Вы запускаете кластер MySQL из трёх Pod’ов. StatefulSet создаст их как mysql-0, mysql-1, mysql-2. Если mysql-1 перезапустится, он сохранит свои данные и имя, чтобы база данных не «сломалась».

📌 Используется: для stateful-приложений:

• базы данных (MySQL, PostgreSQL);

• очереди сообщений (Kafka, RabbitMQ);

• распределённые хранилища (etcd).

---

🔹 DaemonSet

Задача: запускать Pod на каждой ноде (или выбранных нодах) в кластере.

Представьте, что у вас есть 10 серверов (нод), и на каждом нужно запустить сервис, собирающий логи или метрики. Вместо того чтобы руками запускать 10 Pod’ов — вы описываете DaemonSet, и Kubernetes сам развернёт Pod на каждой ноде.

👉 Пример:

• Fluentd или Filebeat для сбора логов с каждого узла;

• Node Exporter для мониторинга ресурсов (CPU, память, диски);

• Антивирус или агент безопасности, который должен работать на всех серверах.

📌 Используется: для системных сервисов, работающих на уровне узлов.

✨ Отличия в двух словах

Сущность	Для чего нужна	Особенности	Пример
ReplicaSet	Поддержание нужного числа Pod’ов	Не умеет обновлять	Всегда держать 3 копии приложения
Deployment	Управление ReplicaSet’ами и обновлениями	Постепенный rollout, откат	Обновление версии веб-сервера
StatefulSet	Приложения с сохранением состояния	Уникальные имена, хранение данных	Кластер MySQL или Kafka
DaemonSet	Сервисы на каждой ноде	Pod на всех узлах	Сбор логов или метрик