#Deployments

#Понимание Deployments

Обратитесь к официальной документации Kubernetes: Deployments

Deployment — это ресурс высокого уровня в Kubernetes, используемый для декларативного управления и обновления реплик Pod для ваших приложений. Он предоставляет надежный и гибкий способ определить, как должно работать ваше приложение, включая количество поддерживаемых реплик и безопасное выполнение rolling update.

Deployment — это объект в API Kubernetes, который управляет Pods и ReplicaSets. При создании Deployment Kubernetes автоматически создает ReplicaSet, который отвечает за поддержание указанного количества реплик Pod.

Используя Deployments, вы можете:

• Декларативное управление: определить желаемое состояние вашего приложения, и Kubernetes автоматически обеспечит соответствие фактического состояния кластера желаемому.
• Контроль версий и откат: отслеживать каждую ревизию Deployment и легко откатываться к предыдущей стабильной версии в случае проблем.
• Обновления без простоя: постепенно обновлять приложение с помощью стратегии rolling update без прерывания сервиса.
• Самовосстановление: Deployment автоматически заменяет экземпляры Pod, если они аварийно завершаются, удаляются или теряются на узле, обеспечивая постоянное наличие указанного количества Pod.

Как это работает:

1. Вы определяете желаемое состояние приложения через Deployment (например, какой образ использовать, сколько реплик запускать).
2. Deployment создает ReplicaSet для обеспечения указанного количества запущенных Pod.
3. ReplicaSet создает и управляет фактическими экземплярами Pod.
4. При обновлении Deployment (например, смена версии образа) создается новый ReplicaSet, который постепенно заменяет старые Pod новыми согласно стратегии rolling update, пока все новые Pod не будут запущены, после чего удаляется старый ReplicaSet.

#Создание Deployments

#Создание Deployment с помощью CLI

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

• Убедитесь, что kubectl настроен и подключен к вашему кластеру.

#Пример YAML файла

# example-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment # Имя Deployment
  labels:
    app: nginx # Метки для идентификации и выбора
spec:
  replicas: 3 # Желаемое количество реплик Pod
  selector:
    matchLabels:
      app: nginx # Селектор для выбора Pod, управляемых этим Deployment
  template:
    metadata:
      labels:
        app: nginx # Метки Pod, должны совпадать с selector.matchLabels
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2 # Образ контейнера
          ports:
            - containerPort: 80 # Открытый порт контейнера
          resources: # Лимиты и запросы ресурсов
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

#Создание Deployment через YAML

# Шаг 1: Создать Deployment через yaml
kubectl apply -f example-deployment.yaml

# Шаг 2: Проверить статус Deployment
kubectl get deployment nginx-deployment # Просмотр Deployment
kubectl get pod -l app=nginx # Просмотр Pod, созданных этим Deployment

#Создание Deployment через веб-консоль

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

Получите адрес образа. Источником образов могут быть репозитории образов, интегрированные администратором платформы через toolchain, либо сторонние репозитории образов.

• В первом случае администратор обычно назначает репозиторий образов вашему проекту, и вы можете использовать образы из него. Если нужный репозиторий образов не найден, обратитесь к администратору для выделения.
• Если это сторонний репозиторий образов, убедитесь, что образы можно напрямую подтягивать из него в текущем кластере.
• Если для реестра образов требуется аутентификация, необходимо настроить соответствующий image pull secret. Подробнее см. Add ImagePullSecrets to ServiceAccount.

#Процедура — Настройка базовой информации

1. В Container Platform перейдите в Workloads > Deployments в левой боковой панели.
2. Нажмите Create Deployment.
3. Выберите или введите образ и нажмите Confirm.

4. В разделе Basic Info настройте декларативные параметры для workloads Deployment:

   Параметры	Описание
   Replicas	Определяет желаемое количество реплик Pod в Deployment (по умолчанию: 1). Настраивается в зависимости от требований нагрузки.
   More > Update Strategy	Настраивает стратегию rollingUpdate для обновлений без простоя: Max surge (maxSurge): Максимальное количество Pod, превышающее желаемое количество реплик во время обновления. Принимает абсолютные значения (например, 2) или проценты (например, 20%). Вычисление процентов: ceil(current_replicas × percentage). Пример: 4.1 → 5 при расчете от 10 реплик. Max unavailable (maxUnavailable): Максимальное количество Pod, которые могут быть временно недоступны во время обновления. Процентные значения не могут превышать 100%. Вычисление процентов: floor(current_replicas × percentage). Пример: 4.9 → 4 при расчете от 10 реплик. Примечания: 1. Значения по умолчанию: maxSurge=1, maxUnavailable=1, если не указано явно. 2. Неработающие Pod (например, в состояниях Pending/CrashLoopBackOff) считаются недоступными. 3. Одновременные ограничения: maxSurge и maxUnavailable не могут оба быть 0 или 0%. Если процентные значения для обоих параметров равны 0, Kubernetes принудительно устанавливает maxUnavailable=1 для обеспечения прогресса обновления. Пример: Для Deployment с 10 репликами: maxSurge=2 → Общее количество Pod во время обновления: 10 + 2 = 12. maxUnavailable=3 → Минимальное количество доступных Pod: 10 - 3 = 7. Это обеспечивает доступность при контролируемом развертывании.

#Процедура — Настройка Pod

Примечание: В кластерах с разной архитектурой, при развертывании образов одной архитектуры, убедитесь в правильной настройке Node Affinity Rules для планирования Pod.

1. В разделе Pod настройте параметры контейнерного рантайма и управления жизненным циклом:

   Параметры	Описание
   Volumes	Монтирование постоянных томов в контейнеры. Поддерживаемые типы томов: PVC, ConfigMap, Secret, emptyDir, hostPath и др. Подробности реализации см. в Volume Mounting Guide.
   Pull Secret	Требуется только при подтягивании образов из сторонних реестров (при ручном вводе URL образа). Примечание: Секрет для аутентификации при подтягивании образа из защищенного реестра.
   Close Grace Period	Время (по умолчанию: 30s), отведенное Pod для корректного завершения работы после получения сигнала завершения. - В этот период Pod завершает текущие запросы и освобождает ресурсы. - Установка 0 приводит к немедленному удалению (SIGKILL), что может вызвать прерывание запросов.

2. Node Affinity Rules

Параметры	Описание
More > Node Selector	Ограничение Pod узлами с определенными метками (например, kubernetes.io/os: linux).
More > Affinity	Определение тонких правил планирования на основе существующих. Типы Affinity: Pod Affinity: Планирование новых Pod на узлы, где уже размещены определённые Pod (одинаковый топологический домен). Pod Anti-affinity: Запрет совместного размещения новых Pod с определёнными Pod. Режимы применения: requiredDuringSchedulingIgnoredDuringExecution: Pod планируются только если правила соблюдены. preferredDuringSchedulingIgnoredDuringExecution: Приоритет узлам, удовлетворяющим правилам, но допускаются исключения. Поля конфигурации: topologyKey: Метка узла, определяющая топологические домены (по умолчанию: kubernetes.io/hostname). labelSelector: Фильтрация целевых Pod с помощью запросов по меткам.

3. Настройка сети

   • Kube-OVN

     Параметры	Описание
     Bandwidth Limits	Ограничение QoS для сетевого трафика Pod: Ограничение исходящего трафика: Максимальная скорость исходящего трафика (например, 10Mbps). Ограничение входящего трафика: Максимальная скорость входящего трафика.
     Subnet	Назначение IP из предопределенного пула подсетей. Если не указано, используется подсеть по умолчанию для namespace.
     Static IP Address	Привязка постоянных IP-адресов к Pod: Несколько Pod из разных Deployments могут претендовать на один IP, но одновременно использовать его может только один Pod. Критично: Количество статических IP должно быть ≥ количеству реплик Pod.

   • Calico

     Параметры	Описание
     Static IP Address	Назначение фиксированных IP с строгой уникальностью: Каждый IP может быть привязан только к одному Pod в кластере. Критично: Количество статических IP должно быть ≥ количеству реплик Pod.

#Процедура — Настройка контейнеров

1. В разделе Container настройте соответствующую информацию согласно следующим инструкциям.

   Параметры	Описание
   Resource Requests & Limits	Requests: Минимальные CPU/память, необходимые для работы контейнера. Limits: Максимальные CPU/память, разрешённые во время выполнения контейнера. Для определения единиц см. Resource Units. Коэффициент overcommit namespace: Без коэффициента overcommit: Если существуют квоты ресурсов namespace: Запросы/лимиты контейнера наследуют значения по умолчанию namespace (можно изменить). Без квот namespace: Нет значений по умолчанию; настраивается вручную. С коэффициентом overcommit: Запросы рассчитываются автоматически как Limits / Overcommit ratio (неизменяемо). Ограничения: Request ≤ Limit ≤ максимальная квота namespace. Изменение коэффициента overcommit требует пересоздания pod для вступления в силу. Коэффициент overcommit отключает ручную настройку запросов. Отсутствие квот namespace → отсутствие ограничений ресурсов контейнера.
   Extended Resources	Настройка расширенных ресурсов, доступных в кластере (например, vGPU, pGPU).
   Volume Mounts	Конфигурация постоянного хранилища. См. Инструкции по монтированию томов. Операции: Существующие тома pod: Нажмите Add Отсутствуют тома pod: Нажмите Add & Mount Параметры: mountPath: Путь в файловой системе контейнера (например, /data) subPath: Относительный путь к файлу/директории внутри тома. Для ConfigMap/Secret: Выбор конкретного ключа readOnly: Монтировать только для чтения (по умолчанию: чтение-запись) См. Kubernetes Volumes.
   Ports	Открытие портов контейнера. Пример: Открыть TCP порт 6379 с именем redis. Поля: protocol: TCP/UDP Port: Открываемый порт (например, 6379) name: DNS-совместимый идентификатор (например, redis)
   Startup Commands & Arguments	Переопределение стандартных ENTRYPOINT/CMD: Пример 1: Выполнить top -b - Command: ["top", "-b"] - ИЛИ Command: ["top"], Args: ["-b"] Пример 2: Вывести $MESSAGE: /bin/sh -c "while true; do echo $(MESSAGE); sleep 10; done" См. Определение команд.
   More > Environment Variables	Статические значения: Прямые пары ключ-значение Динамические значения: Ссылки на ключи ConfigMap/Secret, поля pod (fieldRef), метрики ресурсов (resourceFieldRef) Примечание: Переменные окружения переопределяют настройки образа/конфигурационных файлов.
   More > Referenced ConfigMaps	Внедрение полного ConfigMap/Secret как переменных окружения. Поддерживаемые типы Secret: Opaque, kubernetes.io/basic-auth.
   More > Health Checks	Liveness Probe: Проверка здоровья контейнера (перезапуск при сбое) Readiness Probe: Проверка доступности сервиса (удаление из endpoints при сбое) См. Параметры проверки здоровья.
   More > Log Files	Настройка путей логов: - По умолчанию: сбор stdout - Шаблоны файлов: например, /var/log/*.log Требования: Драйвер хранения overlay2: поддерживается по умолчанию devicemapper: необходимо вручную примонтировать EmptyDir к каталогу логов Узлы Windows: обеспечить монтирование родительского каталога (например, c:/a для c:/a/b/c/*.log)
   More > Exclude Log Files	Исключение определённых логов из сбора (например, /var/log/aaa.log).
   More > Execute before Stopping	Выполнение команд перед завершением контейнера. Пример: echo "stop" Примечание: Время выполнения команды должно быть меньше terminationGracePeriodSeconds pod.

2. Нажмите Add Container (вверху справа) ИЛИ Add Init Container.

   См. Init Containers. Init Container:

   1. Запускается перед контейнерами приложения (последовательное выполнение).
   2. Освобождает ресурсы после завершения.
   3. Удаление разрешено, если:
      • Pod содержит >1 контейнера приложения И ≥1 init контейнер.
      • Не разрешено для pod с одним контейнером приложения.

3. Нажмите Create.

#Справочная информация

#Инструкции по монтированию томов

#Проверки здоровья

• Пример YAML файла для проверок здоровья
• Параметры настройки проверок здоровья в веб-консоли

#Управление Deployments

#Управление Deployment с помощью CLI

#Просмотр Deployment

• Проверьте, что Deployment создан.

  kubectl get deployments

• Получите подробности о вашем Deployment.

  kubectl describe deployments

#Обновление Deployment

Выполните следующие шаги для обновления Deployment:

1. Обновим Pod nginx, чтобы использовать образ nginx:1 .16.1.

   kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1

   или используйте команду:

   kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1

   Также можно отредактировать Deployment и изменить .spec.template.spec.containers[0].image с nginx:1.14.2 на nginx:1.16.1:

   kubectl edit deployment/nginx-deployment

2. Чтобы увидеть статус развертывания, выполните:

   kubectl rollout status deployment/nginx-deployment

   Выполните kubectl get rs, чтобы увидеть, что Deployment обновил Pod, создав новый ReplicaSet и масштабировав его до 3 реплик, а также уменьшил старый ReplicaSet до 0 реплик.

   kubectl get rs

   Выполнение kubectl get pods теперь должно показать только новые Pod:

   kubectl get pods

#Масштабирование Deployment

Вы можете масштабировать Deployment с помощью следующей команды:

kubectl scale deployment/nginx-deployment --replicas=10

#Откат Deployment

• Предположим, вы допустили опечатку при обновлении Deployment, указав имя образа как nginx:1.161 вместо nginx:1.16.1:

  kubectl set image deployment/nginx-deployment nginx=nginx:1.161

• Развертывание застряло. Вы можете проверить это, посмотрев статус развертывания:

  kubectl rollout status deployment/nginx-deployment

#Удаление Deployment

Удаление Deployment также удалит управляемый им ReplicaSet и все связанные Pod.

kubectl delete deployment <deployment-name>

#Управление Deployment через веб-консоль

#Просмотр Deployment

Вы можете просмотреть Deployment, чтобы получить информацию о вашем приложении.

1. В Container Platform перейдите в Workloads > Deployments.
2. Найдите нужный Deployment.
3. Нажмите на имя Deployment для просмотра Details, Topology, Logs, Events, Monitoring и др.

#Обновление Deployment

1. В Container Platform перейдите в Workloads > Deployments.
2. Найдите нужный Deployment.
3. В выпадающем меню Actions выберите Update для перехода на страницу редактирования Deployment.

#Удаление Deployment

1. В Container Platform перейдите в Workloads > Deployments.
2. Найдите нужный Deployment.
3. В выпадающем меню Actions нажмите кнопку Delete в колонке операций и подтвердите удаление.

#Устранение неполадок с помощью CLI

Если у Deployment возникают проблемы, вот несколько распространенных методов диагностики.

#Проверка статуса Deployment

kubectl get deployment nginx-deployment
kubectl describe deployment nginx-deployment # Просмотр подробных событий и статуса

#Проверка статуса ReplicaSet

kubectl get rs -l app=nginx
kubectl describe rs <replicaset-name>

#Проверка статуса Pod

kubectl get pods -l app=nginx
kubectl describe pod <pod-name>

#Просмотр логов

kubectl logs <pod-name> -c <container-name> # Просмотр логов конкретного контейнера
kubectl logs <pod-name> --previous         # Просмотр логов ранее завершенного контейнера

#Вход в Pod для отладки

kubectl exec -it <pod-name> -- /bin/bash # Вход в shell контейнера

#Проверка конфигурации Health

Убедитесь, что livenessProbe и readinessProbe настроены корректно, а конечные точки проверки здоровья вашего приложения отвечают правильно. Устранение неполадок с probe

#Проверка лимитов ресурсов

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