Облачная платформаAdvanced

Создание Deployment

Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Deployment — это приложение Kubernetes, которое не сохраняет данные или состояние во время работы. Каждый pod того же Deployment идентичен, что позволяет беспрепятственно создавать, удалять и заменять их без влияния на функциональность приложения. Deployment подходят для безсостояния приложений, таких как веб‑фронтенд‑серверы и микросервисы, которым не требуется хранение данных. Они обеспечивают простое управление жизненным циклом приложений, включая обновления, откаты и масштабирование.

Требования

  • Кластер доступен. Подробную информацию о том, как создать кластер, см. Buying a Standard/Turbo Cluster.
  • В кластере есть доступные узлы. Если узел недоступен, создайте его, обратившись к Creating a Node.

Использование консоли CCE

  1. Войдите в CCE console.
  2. Нажмите имя кластера, чтобы перейти в консоль кластера, выберите Workloads в панели навигации и нажмите Create Workload в правом верхнем углу.
  3. Настройте basic information о рабочей нагрузке.

    Параметр

    Описание

    Тип рабочей нагрузки

    Выберите Deployment. Подробную информацию о различных типах рабочих нагрузок см. в Workload Overview.

    Имя рабочей нагрузки

    Введите имя для рабочей нагрузки. Введите от 1 до 63 символов, начинающихся со строчной буквы и заканчивающихся строчной буквой или цифрой. Допускаются только строчные буквы, цифры и дефисы (-).

    Namespace

    Выберите пространство имён для рабочей нагрузки. Значение по умолчанию — default. Вы также можете нажать Create Namespace, чтобы создать его. Подробнее см. Creating a Namespace.

    Pods

    Введите количество pod'ов рабочей нагрузки.

    Container Runtime

    Кластер CCE стандартного типа использует общий runtime по умолчанию, тогда как кластер CCE Turbo поддерживает как общий, так и защищённый runtime. Подробнее о различиях см. Secure Runtime and Common Runtime.

    Time Zone Synchronization

    Укажите, включить ли синхронизацию часового пояса. После включения этой функции контейнер и узел будут использовать один и тот же часовой пояс. Синхронизация часового пояса опирается на локальный диск, смонтированный в контейнер. Не изменяйте и не удаляйте локальный диск. Подробнее см. Configuring Time Zone Synchronization.

  4. Настройте container settings для рабочей нагрузки.

    • Container Information: нажмите Add Container справа, чтобы настроить несколько контейнеров для pod‑а.
      Caution

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

      • Basic Info: настройте базовую информацию о контейнере.

        Parameter

        Description

        Container Name

        Введите имя контейнера.

        Pull Policy

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

        Image Name

        Нажмите Select Image и выберите образ, используемый контейнером.

        Чтобы использовать сторонний образ, непосредственно введите путь к образу. Убедитесь, что image access credential может использоваться для доступа к репозиторию образов. Подробности см. в Using Third-Party Images.

        Image Tag

        Выберите тег образа для развертывания.

        CPU Quota

        • Request: минимальное количество ядер CPU, требуемое контейнером. Значение по умолчанию — 0.25 ядра.
        • Limit: максимальное количество ядер CPU, которое может использовать контейнер. Это предотвращает чрезмерное использование ресурсов контейнерами.

        Если Request и Limit не указаны, квота не ограничивается. Для получения дополнительной информации и рекомендаций по Request и Limit см. Configuring Container Specifications.

        Memory Quota

        • Request: минимальный объём памяти, требуемый контейнером. Значение по умолчанию — 512 MiB.
        • Limit: максимальный объём памяти, доступный контейнеру. Когда использование памяти превышает указанный лимит, контейнер будет завершён.

        Если Request и Limit не указаны, квота не ограничивается. Для получения дополнительной информации и рекомендаций о Request и Limit см. Configuring Container Specifications.

        (Optional) GPU Quota

        Настраивается только когда кластер содержит GPU‑узлы и установлен аддон CCE AI Suite (NVIDIA GPU).

        • Do not use: GPU не будет использоваться.
        • GPU card: GPU выделяется для контейнера.
        • GPU Virtualization: процент ресурсов GPU, используемых контейнером. Например, если этот параметр установлен в 10%, контейнер будет использовать 10 % ресурсов GPU.

        Для получения подробной информации о том, как использовать GPU в кластере, см. Default GPU Scheduling in Kubernetes.

        (Optional) Privileged Container

        Программы в привилегированном контейнере обладают определёнными привилегиями. Если эта опция включена, контейнеру будут назначены привилегии. Например, привилегированные контейнеры могут управлять сетевыми устройствами на хост‑машине, изменять параметры ядра, получать доступ ко всем устройствам узла.

        Для получения дополнительной информации см. Pod Security Standards.

        (Optional) Init Container

        Определяет, использовать ли контейнер в качестве init‑контейнера. Init‑контейнер не поддерживает проверку состояния.

        Init‑контейнер — это специальный контейнер, который запускается до того, как будут запущены другие контейнеры приложений в pod. Каждый pod может содержать несколько контейнеров. Кроме того, pod может содержать один или несколько init‑контейнеров. Контейнеры приложений в pod запускаются и работают только после завершения выполнения всех init‑контейнеров. Для получения подробной информации см. Init Containers.

        (Optional) Run Option

        Добавьте параметры запуска для контейнера. Для получения подробной информации см. Pod. CCE поддерживает следующие параметры запуска:

        • stdin: позволяет контейнерам получать ввод из внешних источников, таких как терминалы или другие потоки ввода.
        • tty: выделяет псевдотерминал контейнерам, позволяя отправлять им команды так, как если бы вы использовали локальный терминал.

          В большинстве случаев tty включается вместе со stdin, указывая, что терминал (tty) связан со стандартным вводом (stdin) контейнера. Это позволяет выполнять интерактивные операции, аналогично команде kubectl exec -i -t. Разница в том, что этот параметр настраивается при запуске pod.

      • (Необязательно) Lifecycle: Настройте операции, которые будут выполняться в определённой фазе жизненного цикла контейнера, таких как Startup Command, Post-Start и Pre-Stop. Подробнее см. Configuring the Container Lifecycle.
      • (Необязательно) Health Check: Установите пробу живости, пробу готовности и пробу запуска по требованию. Подробнее см. Configuring Container Health Check.
      • (Необязательно) Environment Variables: Настройте переменные среды контейнера с помощью пар «ключ‑значение». Эти переменные передают внешнюю информацию в контейнеры, работающие в pod, и могут гибко изменяться после развертывания приложения. Подробнее см. Configuring Environment Variables.
      • (Необязательно) Data Storage: Подключите локальное хранилище или облачное хранилище к контейнеру. Сценарии применения и режимы монтирования зависят от StorageClass. Подробнее см. Storage.
        Note

        Если рабочая нагрузка содержит более одного pod, тома EVS монтировать нельзя.

      • (Необязательно) Security Context: Назначьте разрешения контейнеру для защиты системы и других контейнеров от воздействия. Укажите идентификатор пользователя, чтобы назначить разрешения контейнеру и предотвратить влияние на систему и другие контейнеры.
      • (Необязательно) Logging: По умолчанию отправляйте стандартные журналы вывода контейнера в AOM без необходимости ручных настроек. При необходимости можно вручную задать путь сбора журналов. Подробнее см. Using ICAgent to Collect Container Logs.

        Чтобы отключить сбор журналов стандартного вывода текущей рабочей нагрузки, добавьте аннотацию kubernetes.AOM.log.stdout: [] в Labels and Annotations в разделе Advanced Settings. Подробнее о том, как использовать эту аннотацию, см. Table 1.

    • Image Access Credential: Select the credential used for accessing the image repository. The default value is default-secret. You can use default-secret to access images in SWR Shared Edition. For details about default-secret, see default-secret.
    • (Необязательно) GPU: По умолчанию выбран All. Инстанс рабочей нагрузки будет запланирован на узел с указанным типом GPU.

  5. (Необязательно) Настройте the settings of the Service, связанную с рабочей нагрузкой.

    Сервис обеспечивает внешний доступ к pod. При наличии статического IP-адреса сервис перенаправляет трафик доступа к pod и автоматически балансирует нагрузку между этими pod.

    Вы также можете создать Service после создания workload. Для получения подробной информации о Service разных типов см. Service Overview.

  6. (Необязательно) Configure advanced settings for the workload.

    Параметр

    Описание

    Обновление

    Укажите режим обновления и параметры workload. Rolling upgrade и Replace upgrade доступны. Для получения подробной информации см. Upgrading and Rolling Back a Workload.

    Планирование

    Настройте политики affinity и anti-affinity для гибкого планирования workload. Предоставляются политики load affinity и node affinity.

    • Load Affinity: Предлагаются общие политики load affinity для быстрой развертки load affinity.
      • Not configured: Политика load affinity не настроена.
      • Multi-AZ deployment preferred: Workload pods are предпочтительно scheduled to nodes in different AZs through pod anti-affinity.
      • Forcible multi-AZ deployment: Поды workload принудительно планируются на узлы в разных AZ через pod anti-affinity (podAntiAffinity). Если AZ меньше, чем подов, лишние поды не запустятся.
      • Customize affinity: Политики affinity и anti-affinity могут быть настроены. Для получения подробной информации см. Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
    • Node Affinity: Предлагаются общие политики node affinity для быстрой развертки load affinity.
      • Not configured: Политика node affinity не настроена.
      • Specify node: Поды рабочей нагрузки могут быть развернуты на указанных узлах с помощью привязки к узлам (nodeAffinity). Если узел не указан, поды будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию.
      • Specify node pool: Поды рабочей нагрузки могут быть развернуты в указанном пуле узлов с помощью привязки к узлам (nodeAffinity). Если пул узлов не указан, поды будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию.
      • Customize affinity: Политики привязки и антипривязки могут быть настроены. Для получения подробной информации см. Configuring Node Affinity Scheduling (nodeAffinity).

    Толерантность

    Использование как taints, так и tolerations позволяет (не принудительно) планировать pod на узел с соответствующими taints и управлять политиками выселения pod после того, как узел, на котором находится pod, будет помечен taint. Для получения подробной информации см. Configuring Tolerance Policies.

    Метки и аннотации

    Добавьте метки или аннотации для pod, используя пары ключ‑значение. После настройки нажмите Confirm. Для получения подробной информации о метках и аннотациях см. Configuring Labels and Annotations.

    DNS

    Настройте отдельную политику DNS для рабочей нагрузки. Для получения подробной информации см. DNS Configuration.

    Настройка сети

    • Ограничение пропускной способности входящего/исходящего трафика pod: Вы можете задать ограничения пропускной способности входящего и исходящего трафика для pod. Для получения подробной информации см. Configuring QoS for a Pod.
    • Включить ли указанную конфигурацию сетевого контейнера: доступно только для кластеров, поддерживающих эту функцию. После включения указанной конфигурации сетевого контейнера рабочая нагрузка будет использовать подсеть и группу безопасности, определённые в конфигурации. Для получения подробной информации см. Binding a Subnet and Security Group to a Namespace or Workload Using a Container Network Configuration.
    • Укажите имя конфигурации сетевого контейнера: можно выбрать только пользовательскую конфигурацию сетевого контейнера, тип связанного ресурса которой — рабочая нагрузка.
    • Общая пропускная способность IPv6: доступно только для кластеров, поддерживающих эту функцию. После включения этой функции вы можете настроить общую пропускную способность для pod с сетевыми интерфейсами двойного стека IPv6. Для получения подробной информации см. Configuring a Shared Bandwidth for Dual-Stack Pods in a CCE Turbo Cluster.

  7. Нажмите Create Workload в правом нижнем углу. Через некоторое время рабочая нагрузка переходит в состояние Running.

Использование kubectl

Nginx используется в качестве примера для описания того, как create a workload using kubectl.

  1. Используйте kubectl для доступа к кластеру. Для получения подробной информации см. Accessing a Cluster Using kubectl.
  2. Создайте файл с именем nginx-deployment.yaml. nginx-deployment.yaml — пример имени файла, при необходимости вы можете переименовать его.

    vi nginx-deployment.yaml

    Ниже приведён пример файла. Для получения подробной информации о конфигурации Deployment см. Kubernetes official documentation.

    apiVersion: apps/v1
    kind: Deployment # Workload type
    metadata:
    name: nginx # Workload name
    namespace: default # Namespace where the workload is located
    spec:
    replicas: 1 # Number of pods in the specified workload
    selector:
    matchLabels: # The workload manages pods based on the pod labels in the label selector.
    app: nginx
    template: # Pod configuration
    metadata:
    labels: # Pod labels
    app: nginx
    spec:
    containers:
    - image: nginx:latest # Specify a container image. If you use an image in My Images , obtain the image path from SWR.
    imagePullPolicy: Always # Image pull policy
    name: nginx # Container name
    resources: # Node resources allocated to the container
    requests: # Requested resources
    cpu: 250m
    memory: 512Mi
    limits: # Resource limit
    cpu: 250m
    memory: 512Mi
    imagePullSecrets: # Secret for image pull
    - name: default-secret

  3. Создайте Deployment.

    kubectl create -f nginx-deployment.yaml

    Если отображается информация, аналогичная следующей, Deployment создаётся:

    deployment.apps/nginx created

  4. Проверьте статус Deployment.

    kubectl get deployment

    Если Deployment находится в состоянии Running, это означает, что Deployment был создан.

    NAME READY UP-TO-DATE AVAILABLE AGE
    nginx 1/1 1 1 4m5s

    Параметры

    • NAME: имя приложения, работающего в pod.
    • READY: указывает количество доступных рабочих нагрузок. Значение отображается как "количество доступных pod/количество ожидаемых pod".
    • UP-TO-DATE: указывает количество реплик, которые были обновлены.
    • AVAILABLE: указывает количество доступных pod.
    • AGE: период, в течение которого Deployment работает

  5. Если к Deployment будет осуществляться доступ через ClusterIP или NodePort Service, создайте такой Service. Для получения подробной информации см. Networking.