#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, либо репозитории образов сторонних платформ.

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

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

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 (можно изменить). Если квот нет: Нет значений по умолчанию; задается пользовательский Request. С коэффициентом overcommit: Запросы рассчитываются автоматически как Limits / Overcommit ratio (неизменяемо). Ограничения: Request ≤ Limit ≤ максимальная квота namespace. Изменение коэффициента overcommit требует пересоздания pod для вступления в силу. Коэффициент overcommit отключает ручную настройку request. При отсутствии квот 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. Обновим Pods 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 обновил Pods, создав новый ReplicaSet и масштабируя его до 3 реплик, а старый ReplicaSet масштабируется до 0 реплик.

   kubectl get rs

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

   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 и все связанные Pods.

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 контейнера

#Проверка конфигурации здоровья

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

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

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