#Deployments

#Understanding Deployments

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

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

Deployment — это объект в Kubernetes API, который управляет Pod'ами и ReplicaSet'ами. При создании 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.

#Creating Deployments

#Creating a Deployment by using CLI

#Prerequisites

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

#YAML file example

# 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

#Creating a Deployment via 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

#Creating a Deployment by using web console

#Prerequisites

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

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

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

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

#Procedure - Configure Basic Info

1. В Container Platform перейдите в Workloads > Deployments в левом меню.

2. Нажмите Create Deployment.

3. Выберите или введите образ и нажмите Confirm.

4. В разделе Basic Info настройте декларативные параметры для 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. Это обеспечивает доступность при контролируемом развертывании.

#Procedure - Configure 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. Network Configuration

   • 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.

#Procedure - Configure Containers

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

   Параметры	Описание
   Resource Requests & Limits	Requests: Минимальные CPU/память, необходимые для работы контейнера. Limits: Максимальные CPU/память, разрешённые во время выполнения контейнера. Для определения единиц см. Resource Units. Коэффициент overcommit в namespace: Без overcommit: Если в namespace заданы квоты ресурсов: Requests/limits контейнера наследуют значения по умолчанию из namespace (можно изменить). Без квот в namespace: Нет значений по умолчанию; задается кастомный Request. С overcommit: Requests рассчитываются автоматически как Limits / Overcommit ratio (неизменяемо). Ограничения: Request ≤ Limit ≤ максимальная квота namespace. Изменение коэффициента overcommit требует пересоздания pod для вступления в силу. При overcommit отключается ручная настройка Request. Отсутствие квот в namespace → отсутствие ограничений ресурсов контейнера.
   Extended Resources	Настройка расширенных ресурсов, доступных в кластере (например, vGPU, pGPU).
   Volume Mounts	Конфигурация постоянного хранилища. См. Storage Volume Mounting Instructions. Операции: Для существующих томов 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" См. Defining Commands.
   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 при сбое) См. Health Check Parameters.
   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.

#Reference Information

#Storage Volume Mounting instructions

#Heath Checks

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

#Managing Deployments

#Managing a Deployment by using CLI

#Viewing a Deployment

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

  kubectl get deployments

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

  kubectl describe deployments

#Updating a 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

#Scaling a Deployment

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

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

#Rolling Back a 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

#Deleting a Deployment

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

kubectl delete deployment <deployment-name>

#Managing a Deployment by using web console

#Viewing a Deployment

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

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

#Updating a Deployment

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

#Deleting a Deployment

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

#Troubleshooting by using CLI

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

#Check Deployment status

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

#Check ReplicaSet status

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

#Check Pod status

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

#View Logs

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

#Enter Pod for debugging

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

#Check Health configuration

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

#Check Resource Limits

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