Как задеплоить приложение (step-by-step)

StatefulSet #

StatefulSet разворачивает набор подов с устойчивыми идентификаторами и сохранением данных при перезапуске; гарантирует уникальные имена и устойчивую сетевую идентичность подов.

1. Нажмите + Создать StatefulSet.
2. В блоке Описание задайте имя StatefulSet.
3. При необходимости определите лейблы и совпадающие лейблы подов в блоке Селектор подов.
4. Задайте спецификацию:
   • количество реплик;
   • количество партиций;
   • minReadySeconds;
   • revisionHistoryLimit — по умолчанию 10;
   • podManagementPolicy: OrderedReady (по умолчанию) или Parallel;
   • serviceName;
   • политика хранения PersistentVolumeClaim — whenDeleted и whenScaled (по умолчанию Retain, также доступно Delete).
5. Определите шаблоны PersistentVolumeClaim: нажмите +, задайте имя, Access Modes (по умолчанию ReadWriteOnce), Storage Class Name, размер (B, Ki, Mi, Gi) и нажмите Сохранить.

Доступные режимы доступа PVC:

• ReadWriteOnce (RWO) — чтение и запись только с одного узла;
• ReadOnlyMany (ROX) — только чтение с нескольких узлов;
• ReadWriteMany (RWX) — чтение и запись с нескольких узлов;
• ReadWriteOncePod (RWOP) — чтение и запись только одним подом.

Storage Class Name указывает класс хранилища, например standard, fast или slow. Размер PVC задаётся в стандартных единицах Kubernetes: B, Ki, Mi, Gi.

1. Определите init-контейнеры и/или контейнеры, шаблон пода; при необходимости назначьте Volumes. Параметры шаблона пода и контейнеров — как при создании Pod (см. вкладку Pod ниже).

Просмотр и редактирование StatefulSet #

На странице просмотра доступны вкладки StatefulSet, Pods, Шаблон пода, Шаблоны PVC, Безопасность, Лейблы и аннотации, События, Манифест. Во вкладке StatefulSet отображаются partition, minReadySeconds, revisionHistoryLimit, podManagementPolicy, serviceName, политика хранения PVC, селектор подов и метрики CPU/Memory за последний час.

Редактировать можно спецификацию StatefulSet, политику хранения PVC, шаблон пода, init-контейнеры, контейнеры и volumes. Также можно изменить YAML на вкладке Манифест: после изменения выполните Проверить, затем сохраните результат.

DaemonSet #

DaemonSet обеспечивает запуск пода на каждом узле кластера; количество реплик не задаётся.

1. Нажмите + Создать DaemonSet.
2. В блоке Описание задайте имя DaemonSet.
3. При необходимости определите лейблы и совпадающие лейблы подов в блоке Селектор подов.
4. Задайте спецификацию:
   • minReadySeconds — по умолчанию 0;
   • revisionHistoryLimit — по умолчанию 10;
   • максимальное количество недоступных и дополнительных подов.
5. Определите init-контейнеры и/или контейнеры, шаблон пода; при необходимости назначьте Volumes. Параметры — как при создании Pod (см. вкладку Pod ниже).

Просмотр и редактирование DaemonSet #

На странице просмотра доступны вкладки DaemonSet, Pods, Шаблон пода, Безопасность, Лейблы и аннотации, События, Манифест. Во вкладке DaemonSet отображаются дата создания, статус, состояние, minReadySeconds, revisionHistoryLimit, максимальное количество недоступных и дополнительных подов, селектор подов и метрики CPU/Memory за последний час.

Редактировать можно спецификацию DaemonSet, шаблон пода, init-контейнеры, контейнеры и volumes. YAML доступен на вкладке Манифест; после изменения выполните проверку и сохраните изменения.

Pod #

Pod — минимальная вычислительная единица (один или несколько контейнеров). Отдельные поды подходят для разовых или отладочных задач; для production рекомендуется управлять подами через Deployment, StatefulSet или DaemonSet.

На странице Pods отображаются имя пода, отношение работающих контейнеров к общему количеству контейнеров, количество рестартов, дата создания, неймспейс, статус, родительский объект, узел, QoS и лейблы. Доступны фильтры по имени, неймспейсу, статусу, родительскому объекту, узлу и QoS.

1. Нажмите + Добавить Pod.

1. В блоке Спецификация пода задайте hostPID, сеть хоста, политику перезапуска, Image Pull Secrets, Tolerations, селектор узлов, ServiceAccountName и другие параметры.

Политики перезапуска:

• Always — контейнер перезапускается после любого завершения; значение по умолчанию;
• OnFailure — контейнер перезапускается только при завершении с ошибкой;
• Never — завершённый контейнер не перезапускается автоматически.

При настройке Tolerations можно указать ключ и значение taint узла, оператор Exists или Equal, эффект NoSchedule, PreferNoSchedule, NoExecute или Любой, а также tolerationSeconds. Если выбран эффект NoExecute, tolerationSeconds задаёт период, после которого под будет вытеснен с узла. По умолчанию для этого случая используется 5 минут.

1. Настройте Init контейнеры, Контейнеры и Volumes.

Security context пода #

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

• fsGroup — группа файловой системы для изменения владельца и прав файлов при монтировании тома;
• политика изменения fsGroup: OnRootMismatch или Always. Политика не применяется к томам secret, configMap и emptyDir;
• runAsGroup, runAsUser, runAsNonRoot;
• supplementalGroups;
• параметры ядра sysctl. При небезопасных sysctl под не будет запущен, пока хотя бы на одном узле не будут включены эти параметры;
• профиль Seccomp: профиль по умолчанию, пользовательский профиль на узле или отключение профиля. Подробнее — Seccomp.

Init-контейнеры и контейнеры #

В блоках Init контейнеры и Контейнеры задайте:

• имя контейнера и образ;
• рабочий каталог (Workdir), команды и аргументы;
• Image Pull Policy: Always, IfNotPresent или Never;
• порты, переменные окружения, requests и limits для CPU/Memory;
• mounts томов: mountPath, mountPropagation, subPath, subPathExpr;
• Security context контейнера.

Security context контейнера переопределяет настройки, заданные на уровне пода. Если включён привилегированный режим (privileged: true), контейнер получает все Linux capabilities; профиль Seccomp для такого контейнера в графическом интерфейсе задать нельзя.

Для ресурсов контейнера задавайте requests и limits. Если лимит памяти не указан и в неймспейсе нет лимита по умолчанию, контейнер может использовать всю доступную память узла. Если сумма requests памяти контейнеров пода превышает память узла, под не будет запущен на этом узле.

Volumes #

В блоке Volumes добавьте тома, которые будут смонтированы в контейнеры:

• ConfigMap — данные конфигурации, при необходимости defaultMode;
• DownwardAPI — передача в контейнеры сведений о Pod: аннотации, метки, имя, namespace;
• EmptyDir — эфемерный том для чтения и записи несколькими контейнерами Pod; можно выбрать medium и размер;
• PersistentVolumeClaim — подключение существующего PVC, при необходимости только для чтения;
• Secret — конфиденциальные данные, монтируется read-only;
• HostPath — файл или каталог с файловой системы узла.

Просмотр Pod #

На странице Pod доступны вкладки Pod, Контейнеры, Volumes, Безопасность, Лейблы и аннотации, События, Манифест, Терминал, Логи.

QoS пода определяется по requests и limits контейнеров:

• Guaranteed — у каждого контейнера request CPU/Memory равен limit CPU/Memory;
• Burstable — хотя бы у одного контейнера есть request или limit;
• BestEffort — ни у одного контейнера нет requests и limits.

QoS учитывается при вытеснении подов с узла при Node Pressure: сначала вытесняются BestEffort, затем Burstable, затем Guaranteed.

Вкладка Терминал отображается, если хотя бы в одном контейнере есть shell. Bash не поддерживается. Корректная работа терминала гарантируется только в Google Chrome.

На вкладке Логи можно выбрать контейнер, включить или отключить автообновление, временные метки и предыдущий лог, задать количество записей, диапазон времени, поиск по тексту и скачать .log файл.

Job #

Job управляет выполнением параллельных или одноразовых задач с повторным запуском при сбоях.

1. Нажмите + Добавить Job.
2. Заполните Описание, Шаблон задачи (Template Job) и сведения о контейнере. Параметры init-контейнеров, контейнеров и шаблона пода — как при создании Pod (см. вкладку Pod ниже).
3. Нажмите Сохранить.

На странице просмотра Job доступны вкладки Job, Pods, Шаблон пода, Лейблы и аннотации, События, Безопасность, Манифест. Во вкладке Job отображаются состояние, статус, lastScheduleTime, lastSuccessfulTime, completions, completionMode, ttlSecondsAfterFinished, parallelism, backoffLimit, activeDeadlineSeconds, селектор подов и метрики CPU/Memory за последний час.

CronJob #

CronJob запускает периодические задачи по cron-расписанию.

1. Нажмите + Добавить CronJob.
2. Заполните Описание, Спецификацию CronJob, Шаблон задачи (Template Job) и сведения о контейнере. Параметры контейнеров — как при создании Pod (см. вкладку Pod ниже).
3. Нажмите Сохранить.

На странице CronJob доступны вкладки CronJob, Pods, Jobs, Шаблон Job, Лейблы и аннотации, События, Безопасность, Манифест. Во вкладке CronJob отображаются расписание, concurrencyPolicy, startingDeadlineSeconds, successfulJobsHistoryLimit, failedJobsHistoryLimit, состояние Приостановлено/Не приостановлено, селектор подов и метрики CPU/Memory за последний час.

Вкладка Jobs содержит Jobs, созданные CronJob, со статусом и образом.

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

На странице ReplicaSets отображаются наборы реплик в неймспейсе. Если ReplicaSet входит в Deployment, его параметры на странице ReplicaSet недоступны для редактирования.

На странице просмотра доступны вкладки ReplicaSet, Pods, Шаблон пода, Безопасность, Лейблы и аннотации, События, Манифест. Во вкладке ReplicaSet отображаются дата создания, статус, родительский объект, количество реплик, minReadySeconds, селектор подов и метрики CPU/Memory за последний час. На вкладке Манифест YAML можно просмотреть и скопировать.

Подготовьте YAML-манифесты и примените объекты через Импорт манифестов.

В Kubernetes доступны два основных варианта автоматического масштабирования:

• HPA (Horizontal Pod Autoscaler) — изменяет количество подов Deployment или StatefulSet по метрикам CPU, памяти или кастомным метрикам.
• VPA (Vertical Pod Autoscaler) — подбирает requests/limits контейнеров на основе исторических данных. (Будет реализовано в релизе 2.15.0)

HPA #

Предварительные требования:

• в кластере должен быть установлен shturval-metrics-collector. Если у вас нет доступа к shturvalserviceconfigs, то наличие установленного сервиса вы можете понять по отображению графиков утилизации CPU и RAM в графическом интерфейсе нагрузки;
• для HPA по CPU/Memory у контейнеров должны быть заданы requests, иначе метрики не будут рассчитаны.

Пример HPA:

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

Проверьте статус HPA:

kubectl get hpa my-app-hpa -n my-namespace
kubectl describe hpa my-app-hpa -n my-namespace

В выводе отображаются текущее и желаемое количество реплик, текущие значения метрик и события масштабирования.