Создание DaemonSet

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

DaemonSet — это тип рабочей нагрузки Kubernetes, который гарантирует, что pod работает на всех или выбранных узлах в кластере. Когда в кластер добавляется новый узел, контроллер DaemonSet автоматически создает pod на узле. И наоборот, когда узел удаляется, его pod удаляются.

DaemonSets идеальны для поддержания согласованных сервисов во всем кластере. Распространённые сценарии применения включают:

  • Процесс хранения кластера: Необходимо развернуть на каждом узле кластера, чтобы все узлы могли получить доступ к хранилищу backend. К таким процессам относятся GlusterFS и Ceph.
  • Процесс сбора логов: Необходимо развернуть на каждом узле кластера для сбора логов узла и передачи их в единую систему логов. К таким процессам относятся Fluentd и Logstash.
  • Процесс мониторинга: Необходимо развернуть на каждом узле кластера для сбора данных о производительности узла. К таким процессам относится Prometheus node exporter.

Требования

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

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

  1. Войдите в CCE console.
  2. Click the cluster name to go to the cluster console, choose Workloads in the navigation pane, and click Create Workload in the upper right corner.
  3. Настройте basic information о рабочей нагрузке.

    Параметр

    Описание

    Тип нагрузки

    Выберите DaemonSet. Для получения подробной информации о различных типах нагрузок см. Workload Overview.

    Имя нагрузки

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

    Пространство имён

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

    Среда выполнения контейнера

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

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

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

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

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

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

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

        Параметр

        Описание

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

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

        Политика получения

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

        Имя образа

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

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

        Тег образа

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

        Квота CPU

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

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

        Квота памяти

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

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

        (Необязательно) 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.

        (Необязательно) Privileged Container

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

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

        (Необязательно) Init Container

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

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

        (Optional) Run Option

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

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

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

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

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

    • Image Access Credential: выберите учётные данные, используемые для доступа к репозиторию образов. Значение по умолчанию — default-secret. Вы можете использовать default-secret для доступа к образам в SWR Shared Edition. Подробнее о default-secret см. default-secret.
    • (Optional) GPU: по умолчанию выбран All. Экземпляр рабочей нагрузки будет запланирован на узел указанного типа GPU.

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

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

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

  6. (Необязательно) Настройте advanced settings для рабочей нагрузки.

    Parameter

    Description

    Upgrade

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

    Scheduling

    Настройте политики аффинности и анти‑аффинности для гибкого планирования рабочей нагрузки. Предоставляется node affinity.

    • Node Affinity: Предлагаются общие политики аффинности нагрузки для быстрого развертывания аффинности нагрузки.
      • Not configured: Политика node affinity не настроена.
      • Specify node: Pod‑ы рабочей нагрузки могут быть развернуты на указанных узлах с помощью node affinity (nodeAffinity). Если узел не указан, pod‑ы будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию.
      • Specify node pool: Pod‑ы рабочей нагрузки могут быть развернуты в указанном пуле узлов с помощью node affinity (nodeAffinity). Если пул узлов не указан, pod‑ы будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию.
      • Customize affinity: Политики аффинности и анти‑аффинности могут быть настроены. Подробную информацию см. в Configuring Node Affinity Scheduling (nodeAffinity).

    Toleration

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

    Labels and Annotations

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

    DNS

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

    Network 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 с сетевыми интерфейсами dual‑stack 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. Create and edit the nginx-daemonset.yaml file. nginx-daemonset.yaml is an example file name, and you can change it as required.

    vi nginx-daemonset.yaml

    Ниже показано содержимое файла описания. Это лишь пример. Для получения подробной информации о DaemonSets см. Kubernetes official documentation.

    apiVersion: apps/v1
    kind: DaemonSet
    metadata:
    name: nginx-daemonset
    labels:
    app: nginx-daemonset
    spec:
    selector:
    matchLabels:
    app: nginx-daemonset
    template:
    metadata:
    labels:
    app: nginx-daemonset
    spec:
    nodeSelector: # Node selection. A pod is created on a node only when the node meets daemon=need .
    daemon: need
    containers:
    - name: nginx-daemonset
    image: nginx:alpine
    resources:
    limits:
    cpu: 250m
    memory: 512Mi
    requests:
    cpu: 250m
    memory: 512Mi
    imagePullSecrets:
    - name: default-secret

    Параметр replicas, используемый при определении Deployment или StatefulSet, отсутствует в приведённой выше конфигурации DaemonSet, поскольку на каждом узле имеется только одна реплика. Он фиксирован.

    nodeSelector в предыдущем шаблоне pod указывает, что pod создаётся только на узлах, соответствующих daemon=need. Если необходимо создать pod на каждом узле, удалите метку.

  3. Создать DaemonSet.

    kubectl create -f nginx-daemonset.yaml

    Если отображается следующая информация, DaemonSet был создан:

    daemonset.apps/nginx-daemonset created

  4. Получить статус DaemonSet.

    kubectl get ds

    Вывод команды:

    NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
    nginx-daemonset 1 1 0 1 0 daemon=need 116s

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