Поды (Pods) — набор из одного и более контейнеров для совместного развертывания на ноде в Cloud Managed Kubernetes. Cloud Managed Kubernetes предоставляет пользователям параметры для настройки конфигураций рабочей нагрузки. Примеры параметров:

• проверки работоспособности,
• переменные среды,
• команды запуска.

Под указывается при создании развертываний, наборов состояния или набора даемона.

Настройки подов

Реплики подов

Установите количество реплицированных подов, щелкнув  или  в поле .spec.replicas файла манифеста. Эта опция недоступна для набора даемона.

Если  создаете развертывания в многокластерном проекте, выберите режим планирования реплик в разделе Replica Scheduling Mode:

• Specify Replicas: выберите кластеры и установите количество реплик подов в каждом кластере
• Specify Weights: выберите кластеры, установите общее количество реплик подов в Total Replicas и укажите емкость для каждого кластера. Реплики пропорционально распределяются по кластерам в соответствии с указанной емкостью. Чтобы отредактировать емкость после создания развертывания, перейдите на страницу сведений, щелкните имя развертывания и измените емкость в разделе Weights вкладки Resource Status

Если создаете наборы состояния в проекте с несколькими кластерами, выберите кластеры и установите количество реплик подов в каждом кластере раздела Replicas Pod.

Добавление контейнера

Нажмите кнопку Add Container, чтобы добавить контейнер.

Поле поиска изображений

При необходимости щелкните кнопку, чтобы выбрать изображение из списка или ввести имя изображения для его поиска. Cloud Managed Kubernetes предоставляет образы Docker Hub и вличный репозиторий образов. Если хотите использовать свой репозиторий, создайте секретную переменную реестра образов раздела Secrets в Configuration.

Тег изображения

При необходимости укажите тег, например, imagename:tag. Если тег не указан, по умолчанию устанавливается последняя версия контейнера.

Имя контейнера

Cloud Managed Kubernetes автоматически создает имя контейнера, на которое указывает .spec.containers.name.

Тип контейнера

Выбор Init container означает, что контейнер инициализации создается для рабочей нагрузки.

Задание ресурсов

Зарезервированная контейнером квота включает ресурсы CPU и памяти. Резервирование означает, что контейнер монополизирует ресурс, не позволяя другим сервисам или процессам конкурировать за ресурсы из-за нехватки ресурсов.

• Запрос CPU обозначается как .spec.containers[].resources.requests.cpu в файле манифеста. Запрос CPU может быть превышен.
• Запрос памяти обозначается как .spec.containers[].resources.requests.memory в файле манифеста. Запрос может быть превышен, но контейнер может очиститься, когда памяти ноды недостаточно.

Лимит ресурсов

При необходимости укажите верхний лимит ресурсов, которые может использовать приложение, включая CPU, память и GPU. Лимиты предотвращают чрезмерную занятость ресурсов.

• Ограничение CPU указывается с помощью .spec.containers[].resources.limits.cpu в файле манифеста. Лимит CPU может быть превышен на непродолжительное время, и контейнер не будет остановлен.
• Ограничение памяти указывается с помощью .spec.containers[].resources.limits.memory в файле манифеста. Лимит памяти не может быть превышен. В случае превышения контейнер может быть остановлен или назначен на другой компьютер с достаточными ресурсами.

Для установки GPU Type выберите его из раскрывающегося списка (по умолчанию nvidia.com/gpu). GPU Limit по умолчанию не установлено.

Настройки портов

Установите протокол доступа для контейнера и информацию о порте. Нажмите кнопку Use Default Ports, чтобы использовать настройку по умолчанию.

Политика извлечения изображений

Политика извлечения изображений — политика, при которой kubelet пытается извлечь указанное вами изображение. Значение параметра указывается полем imagePullPolicy в файле манифеста. В дашборде при необходимости выберите один из следующих трех вариантов раскрывающегося списка:

• Use Local Image First. Образ подтягивается только в том случае, если он не существует локально.
• Pull Image Always. Изображение извлекается всякий раз, когда запускается под.
• Use Local Image Only. Изображение не извлекается независимо от факта существования.

Проверка состояния приложения

Cloud Managed Kubernetes предлагает три типа проверок:

• Liveness Check (Поддержка проверки работоспособности). Проверка используется, чтобы узнать, запущен ли контейнер. На это указывает тег livenessProbe
• Readiness Check (Проверка готовности). Проверка используется, чтобы узнать, готов ли контейнер обслуживать запросы. На это указывает тег readinessProbe
• Startup Check (Проверка запуска). Проверка используется, чтобы узнать, запущено ли приложение-контейнер. На это указывает тег startupProbe

Поддержка проверки работоспособности, проверка готовности и проверка запуска включают в себя следующие конфигурации:

• HTTP-запрос,
• Порт TCP,
• Команды.

HTTP-запрос

Выполните HTTP-запрос Get для указанного порта и пути по IP-адресу контейнера. Если код состояния ответа больше или равен 200 и меньше 400, диагностика считается успешной. Поддерживаемые параметры включают в себя:

Порт TCP

Выполните проверку TCP на указанном порту на IP-адресе контейнера. Если порт открыт, проверка успешна. Поддерживаемые параметры включают в себя:

Команды

Выполняется команда в контейнере. Если при ее завершении код возврата равен 0, проверка успешна. Поддерживаемые параметры включают в себя:

Команда запуска

По умолчанию контейнер запускает команду изображения:

• Команда относится к полю command контейнеров в файле манифеста.
• Параметры относятся к полю args контейнеров в файле манифеста.

Переменные среды

Настройте переменные среды для подов в виде пар ключ-значение.

• name: Имя переменной окружения. Задается env.name.
• value: значение переменной, на которую ссылаются. Задается env.value.

Нажмите From configmap или From secret, чтобы использовать существующий ConfigMap или секретную переменную.

Среда безопасности контейнера

Среда безопасности определяет привилегии и параметры управления доступом для пода или контейнера.

Синхронизация часового пояса хоста

Часовой пояс контейнера должен соответствовать часовому поясу хоста после синхронизации.

Обновление стратегии

Обновление пода

Стратегии обновления различаются для разных рабочих нагрузок.

Развертывание приложений

Поле .spec.strategy указывает стратегию, используемую для замены старых подов новыми. .spec.strategy.type может быть Recreate или Rolling Update. Rolling Update — значение по умолчанию.

• Rolling Update (рекомендованное значение для выбора). Последовательное обновление означает, что экземпляры старой версии постепенно заменяются новыми. В процессе обновления трафик балансируется по нагрузке и распределяется между старым и новым экземплярами одновременно, поэтому работа сервиса не прерывается.
• Simultaneous Update. Все существующие поды удаляются до создания новых.

Набор состояния

Раскрывающееся меню в разделе Update Strategy обозначается полем .spec.updateStrategy в файле манифеста. Поле позволяет обрабатывать обновления контейнеров подов, тегов, запросов ресурсов или ограничений, аннотаций. Предусмотрены две стратегии:

• Rolling Update (рекомендованная). Если .spec.template обновлен, поды в StatefulSet будут автоматически удалены, а новые поды будут созданы в качестве замены. Поды обновляются в обратном порядке, последовательно удаляются и создаются. Новое обновление пода не начнется, пока предыдущий не заработает после его обновления
• Update on Deletion. Если .spec.template обновлен, поды в StatefulSet не будут обновляться автоматически. Необходимо вручную удалить старые поды, чтобы контроллер мог создавать новые

Более подробно в статье.

Набор даемона

Раскрывающееся меню в разделе Update Strategy обозначается полем .spec.updateStrategy набора даемонов файла манифеста. Набор позволяет обрабатывать обновления контейнеров подов, тегов, запросов ресурсов или ограничений, аннотаций. Предусмотрены две стратегии:

• Rolling Update (рекомендованная). Если .spec.template обновлен, старые поды набора даемонов удаляются, а новые создаются автоматически. В течение всего процесса обновления на каждой ноде работает не более одного пода набора даемонов.
• Update on Deletion. Если .spec.template обновлен, новые поды набора даемонов создаются только при ручном удалении старых.

Параметры непрерывного обновления

Развертывание приложений

Параметры непрерывного обновления в развертывании отличаются от параметров набора состояния.

• Maximum Unavailable Pods. Максимальное количество подов, которые могут быть недоступны во время обновления. Задается параметром maxUnreachable. Значение по умолчанию — 25%
• Maximum Extra Pods. Максимальное количество подов, которое можно запланировать сверх желаемого количества. Задается параметром maxSurge. Значение по умолчанию — 25%

Набор состояния

Ordinal for Dividing Pod Replicas: когда вы разделяете обновление, все поды с порядковым номером, большим или равным установленным в разделе значением, обновляются при обновлении спецификации пода StatefulSet. Это поле определяется параметром .spec.updateStrategy.rollingUpdate.partition. Значение параметра по умолчанию равно 0.

Более подробно в статье.

Набор даемона

Параметры последовательного обновления в наборе даемона отличаются от набора состояния.

• Maximum Unavailable Pods: максимальное количество подов, которые могут быть недоступны во время обновления. Задается параметром maxUnreachable. Значение по умолчанию — 20%.
• Minimum Running Time for Pod Readiness: минимальное количество секунд, прежде чем вновь созданный под DaemonSet будет считаться доступным. Задается параметром minReadySeconds. Значение по умолчанию — 0.

Среда безопасности пода

Среда безопасности пода определяет привилегии и параметры управления доступом для пода или контейнера.

Правила планирования пода

При необходимости выберите режимы развертывания, чтобы переключаться между соответствием и анти-соответствием между подами. Привязка между подами указывается как поле podAffinity поля affinity, а антипривязка между блоками  — как поле podAntiAffinity. Для podAffinity и podAntiAffinity задано значение selectedDuringSchedulingIgnoredDuringExecution. При необходимости нажмите кнопку Edit YAML в правом верхнем углу, чтобы увидеть детали поля.

• Децентрализованное планирование — правила раздельного существования между подами (affinity-правила).
• Централизованное планирование — правила совместного существования между подами.
• Пользовательские правила — пользовательские правила планирования.

В начало 🡱
К следующему разделу 🡲
К предыдущему разделу 🡰