• Русский
  • Создание приложений из образа

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

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

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

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

    Процедура 1 — Workloads

    1. В Container Platform перейдите в Applications > Applications в левой боковой панели.

    2. Нажмите Create.

    3. Выберите способ создания Create from Image.

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

    INFO

    Примечание: При использовании образов из репозитория, интегрированного в веб-консоль, можно фильтровать образы по параметру Already Integrated. Название интеграционного проекта, например, образы (registry-projectname), включает имя проекта projectname в этой веб-консоли и имя проекта containers в репозитории образов.

    При использовании образов из приватного реестра необходимо настроить соответствующий секрет для image pull. Подробнее см. Add ImagePullSecrets to ServiceAccount.

    1. Следуйте приведённым ниже инструкциям для настройки соответствующих параметров.

    Workload 1 — Настройка базовой информации

    В разделе Workload > Basic Info настройте декларативные параметры для workloads

    ПараметрыОписание
    ModelВыберите нужный workload:
    • Deployment: Подробное описание параметров см. в Creating Deployment.
    • DaemonSet: Подробное описание параметров см. в Creating DaemonSet.
    • StatefulSet: Подробное описание параметров см. в Creating StatefulSet.
    ReplicasОпределяет желаемое количество реплик Pod в Deployment (по умолчанию: 1). Настраивается в зависимости от требований workload.
    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.
    • Это обеспечивает доступность при контролируемом развёртывании.

    Workload 2 — Настройка Pod

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

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

      ПараметрыОписание
      VolumesМонтирование персистентных томов в контейнеры. Поддерживаемые типы томов: PVC, ConfigMap, Secret, emptyDir, hostPath и др. Для деталей реализации см. Storage Volume Mounting Instructions.
      Image CredentialТребуется только при подтягивании образов из сторонних реестров (при ручном вводе URL образа).
      Примечание: Образы из интегрированного реестра платформы автоматически наследуют связанные секреты.
      More > Close Grace PeriodВремя (по умолчанию: 30s), отведённое Pod для корректного завершения работы после получения сигнала завершения.
      - В этот период Pod завершает текущие запросы и освобождает ресурсы.
      - Установка 0 приводит к немедленному удалению (SIGKILL), что может вызвать прерывание запросов.
    1. Node Affinity Rules
    ПараметрыОписание
    More > Node SelectorОграничение Pod узлами с определёнными метками (например, kubernetes.io/os: linux).
    Node OS Selector
    More > AffinityОпределение тонких правил планирования на основе существующих Pod.

    Типы Pod Affinity:
    • Inter-Pod Affinity: Планирование новых Pod на узлах, где размещены определённые Pod (одна топологическая область).
    • Inter-Pod Anti-affinity: Запрет совместного размещения новых Pod с определёнными Pod.

    Режимы применения:
    • RequiredDuringSchedulingIgnoredDuringExecution: Pod планируются только при выполнении правил.
    • PreferredDuringSchedulingIgnoredDuringExecution: Предпочтение узлам, удовлетворяющим правилам, но допускаются исключения.

    Поля конфигурации:
    • topologyKey: Метка узла, определяющая топологические области (по умолчанию: kubernetes.io/hostname).
    • labelSelector: Фильтр целевых Pod с помощью запросов по меткам.
    1. Настройка сети
      • Kube-OVN
        ПараметрыОписание
        Bandwidth LimitsОбеспечение QoS для сетевого трафика Pod:
        • Ограничение скорости исходящего трафика: Максимальная скорость исходящего трафика (например, 10Mbps).
        • Ограничение скорости входящего трафика: Максимальная скорость входящего трафика.
        SubnetНазначение IP из предопределённого пула подсетей. Если не указано, используется подсеть по умолчанию для namespace.
        Static IP AddressПривязка постоянных IP-адресов к Pod:
        • Несколько Pod из разных Deployment могут претендовать на один IP, но одновременно использовать его может только один Pod.
        • Критично: Количество статических IP должно быть ≥ количеству реплик Pod.
      • Calico
        ПараметрыОписание
        Static IP AddressНазначение фиксированных IP с жёстким ограничением уникальности:
        • Каждый IP может быть привязан только к одному Pod в кластере.
        • Критично: Количество статических IP должно быть ≥ количеству реплик Pod.

    Workload 3 — Настройка контейнеров

    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 MountКонфигурация персистентного хранилища. См. Storage Volume Mounting Instructions.
      Операции:
      • Для существующих томов pod: нажмите Add
      • Если томов pod нет: нажмите Add & Mount
      Параметры:
      • mountPath: Путь в файловой системе контейнера (например, /data)
      • subPath: Относительный путь файла/каталога внутри тома.
        Для ConfigMap/Secret: выбор конкретного ключа
      • readOnly: Монтировать только для чтения (по умолчанию: чтение-запись)
      См. Kubernetes Volumes.
      PortОткрытие портов контейнера.
      Пример: Открыть 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 ConfigMapВнедрение всего ConfigMap/Secret как переменных окружения. Поддерживаемые типы Secret: Opaque, kubernetes.io/basic-auth.
      More > Health Checks
      • Liveness Probe: Проверка здоровья контейнера (перезапуск при сбое)
      • Readiness Probe: Проверка доступности сервиса (удаление из endpoints при сбое)
      См. Health Check Parameters.
      More > Log FileНастройка путей логов:
      - По умолчанию: сбор stdout
      - Паттерны файлов: например, /var/log/*.log
      Требования:
      • Драйвер хранения overlay2: поддерживается по умолчанию
      • devicemapper: необходимо вручную монтировать EmptyDir в каталог логов
      • Windows-узлы: убедитесь, что родительский каталог смонтирован (например, c:/a для c:/a/b/c/*.log)
      More > Exclude Log FileИсключение определённых логов из сбора (например, /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.

    Процедура 2 — Services

    ПараметрыОписание
    ServiceKubernetes Service, обеспечивает доступ к приложению, работающему в вашем кластере, через единый внешний endpoint, даже если workload распределён по нескольким backend. Для подробного описания параметров см. Creating Services.

    Примечание: Префикс имени по умолчанию для внутреннего маршрута, создаваемого под приложением, — это имя вычислительного компонента. Если тип вычислительного компонента (режим развёртывания) — StatefulSet, рекомендуется не менять имя внутреннего маршрута (имя workload), иначе могут возникнуть проблемы с доступностью workload.

    Процедура 3 — Ingress

    ПараметрыОписание
    IngressKubernetes Ingress, позволяет сделать ваш HTTP (или HTTPS) сетевой сервис доступным с помощью протокольно-ориентированной конфигурации, понимающей веб-концепции, такие как URI, имена хостов, пути и др. Концепция Ingress позволяет направлять трафик на разные backend в зависимости от правил, определённых через Kubernetes API. Для подробного описания параметров см. Creating Ingresses.

    Примечание: Service, используемый при создании Ingress под приложением, должен быть ресурсом, созданным в рамках текущего приложения. При этом убедитесь, что Service связан с workload под приложением, иначе обнаружение и доступ к workload не будут работать.
    1. Нажмите Create.

    Операции управления приложением

    Для изменения конфигураций приложения используйте один из следующих способов:

    1. Нажмите вертикальное многоточие (⋮) справа от списка приложений.
    2. Выберите Actions в правом верхнем углу страницы с деталями приложения.
    ОперацияОписание
    Update
    • Update: Изменяет только целевой workload с использованием его определённой стратегии обновления (пример — стратегия Deployment). Сохраняет текущее количество реплик и конфигурацию развёртывания.
    • Force Update: Запускает полное развёртывание приложения с использованием стратегии обновления каждого компонента.
      1. Сценарии использования:
      • Пакетные изменения конфигураций, требующие немедленного распространения по всему кластеру (например, обновления ConfigMap/Secret, используемых как переменные окружения).
      • Координированные перезапуски компонентов для критических обновлений безопасности.
      2. Предупреждение:
      • Может вызвать временное ухудшение качества сервиса из-за массовых перезапусков.
      • Не рекомендуется использовать в production без проверки непрерывности бизнес-процессов.
    • Сетевые последствия:
      • Удаление правил Ingress: Внешний доступ остаётся доступным через LB_IP:NodePort, если:
        1) Service типа LoadBalancer использует порты по умолчанию.
        2) Сохранившиеся правила маршрутизации ссылаются на компоненты приложения.
        Полное прекращение внешнего доступа требует удаления Service.
      • Удаление Service: Необратимая потеря сетевого подключения к компонентам приложения. Связанные правила Ingress перестают работать, несмотря на сохранение объектов в API.
    Delete
    • Каскадное удаление:
      1. Удаляет все дочерние ресурсы, включая Deployments, Services и правила Ingress.
      2. Persistent Volume Claims (PVC) обрабатываются согласно политике хранения, определённой в StorageClass.
    • Перед удалением:
      1. Убедитесь, что через связанные Services не идёт активный трафик.
      2. Подтвердите резервное копирование данных для stateful компонентов.
      3. Проверьте зависимости ресурсов с помощью kubectl describe ownerReferences.

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

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

    ТипНазначение
    Persistent Volume ClaimПривязывает существующий PVC для запроса персистентного хранилища.

    Примечание: Выбираются только привязанные PVC (с ассоциированным PV). Непривязанные PVC приведут к ошибкам создания pod.
    ConfigMapМонтирует полные или частичные данные ConfigMap в виде файлов:
    • Полный ConfigMap: создаёт файлы с именами ключей под путём монтирования
    • Выбор подпути: монтирует конкретный ключ (например, my.cnf)
    SecretМонтирует полные или частичные данные Secret в виде файлов:
    • Полный Secret: создаёт файлы с именами ключей под путём монтирования
    • Выбор подпути: монтирует конкретный ключ (например, tls.crt)
    Ephemeral VolumesВременный том, предоставляемый кластером, с возможностями:
    • Динамическое выделение
    • Жизненный цикл связан с pod
    • Поддержка декларативной конфигурации

    Сценарий использования: временное хранение данных. См. Ephemeral Volumes
    Empty DirectoryВременное хранилище, общее для контейнеров в одном pod:
    - Создаётся на узле при старте pod
    - Удаляется при удалении pod

    Сценарий использования: обмен файлами между контейнерами, временное хранение данных. См. EmptyDir
    Host PathМонтирует директорию хост-машины (должна начинаться с /, например, /volumepath).

    Параметры проверки здоровья

    Общие параметры

    ПараметрыОписание
    Initial DelayВремя ожидания (в секундах) перед началом проверок. По умолчанию: 300.
    PeriodИнтервал между проверками (1-120 с). По умолчанию: 60.
    TimeoutВремя ожидания ответа проверки (1-300 с). По умолчанию: 30.
    Success ThresholdМинимальное количество последовательных успешных проверок для признания контейнера здоровым. По умолчанию: 0.
    Failure ThresholdМаксимальное количество последовательных неудач для запуска действия:
    - 0: отключение действий при ошибках
    - По умолчанию: 5 неудач → перезапуск контейнера.

    Параметры, специфичные для протоколов

    ПараметрПрименимые протоколыОписание
    ProtocolHTTP/HTTPSПротокол проверки здоровья
    PortHTTP/HTTPS/TCPЦелевой порт контейнера для проверки.
    PathHTTP/HTTPSПуть конечной точки (например, /healthz).
    HTTP HeadersHTTP/HTTPSПользовательские заголовки (добавление пар ключ-значение).
    CommandEXECКоманда для проверки, выполняемая в контейнере (например, sh -c "curl -I localhost:8080 | grep OK").
    Примечание: Экранируйте специальные символы и проверьте работоспособность команды.