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

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

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

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

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

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

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

    2. Нажмите Create.

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

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

    INFO

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

    При использовании образов из приватного реестра необходимо настроить соответствующий секрет для подтягивания образов. Подробнее см. 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(текущее_число_реплик × процент).
    • Пример: 4.1 → 5 при расчёте от 10 реплик.
    Max unavailable (maxUnavailable):
    • Максимальное количество Pod, которые могут быть временно недоступны во время обновления.
    • Процентные значения не могут превышать 100%.
    • Расчёт процентов: floor(текущее_число_реплик × процент).
    • Пример: 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 из разных Deployments могут претендовать на один 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, обеспечивает доступ к приложению, работающему в вашем кластере, через единую внешнюю точку доступа, даже если 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").
    Примечание: Экранируйте специальные символы и проверяйте работоспособность команды.