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

Создание StatefulSet

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

StatefulSet — это приложение, которое должно сохранять данные или состояние во время работы. StatefulSet подходят для stateful‑приложений, таких как базы данных, кэш‑сервисы и очереди сообщений. В отличие от Deployments, у StatefulSet есть следующие особенности:

  • Fixed identifier: Each pod in a StatefulSet has a fixed identifier, which is associated with the pod name. The identifier is typically in the format of <StatefulSet name>-<Ordinal>. For example, in a StatefulSet named web, the pods would have the names like web-0 and web-1. This naming rule enables each pod to maintain its identity and persistent data even after restart or migration.
  • Ordered deployment and scaling: Pod в StatefulSet создаются, масштабируются или удаляются последовательно. Например, pod с более высокими порядковыми номерами имеют приоритет при масштабировании наружу и удаляются первыми при масштабировании внутрь, что критично для stateful‑приложений, которым необходимо запускаться или останавливаться последовательно, и подходит для сценариев, таких как репликация баз данных в режиме primary‑secondary.
  • Persistent storage: Чтобы обеспечить сохранность данных, вы можете назначить стабильные тома постоянного хранилища каждому pod в StatefulSet, используя VolumeClaimTemplate. Если pod будет перенесён на другие узлы, его исходный том данных остаётся неизменным через PVC, предотвращая потерю данных.

Ограничения

  • При удалении или масштабировании StatefulSet система не удаляет тома хранилища, связанные с StatefulSet, чтобы обеспечить безопасность данных.
  • При удалении StatefulSet уменьшите количество реплик до 0 перед удалением StatefulSet, чтобы pod в StatefulSet могли быть остановлены последовательно.
  • При создании StatefulSet требуется headless Service для доступа к pod. Подробнее см. Headless Services.
  • Когда узел недоступен, pod переходят в состояние Unready. В этом случае вручную удалите pod StatefulSet, чтобы они могли быть перенесены на нормальный узел.

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

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

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

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

    Parameter

    Description

    Workload Type

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

    Workload Name

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

    Namespace

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

    Pods

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

    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.

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

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

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

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

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

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

        (Необязательно) 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
        • StatefulSets поддерживают динамическое присоединение дисков EVS. Для получения подробной информации см. Dynamically Mounting an EVS Disk to a StatefulSet или Dynamically Mounting a Local PV to a StatefulSet.

          Динамическое монтирование достигается с помощью поля volumeClaimTemplates и зависит от возможности динамического создания StorageClass. StatefulSet связывает каждый pod с PVC, используя поле volumeClaimTemplates, а PVC привязывается к соответствующему PV. Поэтому после переназначения pod исходные данные могут быть смонтированы на основе имени PVC.

        • После создания рабочей нагрузки динамически монтируемое хранилище нельзя обновить.
      • (Необязательно) Security Context: Назначьте разрешения контейнера для защиты системы и других контейнеров от воздействия. Введите идентификатор пользователя, чтобы назначить разрешения контейнера и предотвратить воздействие на системы и другие контейнеры.
      • (Необязательно) 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.
    • (Необязательно) GPU: По умолчанию выбрано All. Инстанс рабочей нагрузки будет запланирован на узел указанного типа GPU.

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

    Headless Service предоставляет фиксированное доменное имя доступа для каждого pod в StatefulSet для взаимного доступа pod‑ов. Подробнее см. Headless Services.

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

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

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

  7. (Optional) Configure advanced settings for the workload.

    Parameter

    Description

    Upgrade

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

    Pod Management Policies

    Для некоторых распределённых систем гарантии упорядочения StatefulSet не нужны и/или нежелательны. Такие системы требуют только уникальности и идентификаторов.

    • OrderedReady: Это политика по умолчанию. StatefulSet будет развертывать, удалять или масштабировать поды последовательно, по одному. Продолжение происходит только после того, как предыдущий под будет готов или удалён.
    • Parallel: StatefulSet будет создавать поды параллельно или удалять все поды сразу. Изменения в StatefulSet применяются к подам немедленно.

    Scheduling

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

    • Load Affinity: Предлагаются общие политики Load affinity для быстрого развертывания Load affinity.
      • Not configured: Политика Load affinity не настроена.
      • Multi-AZ deployment preferred: Поды рабочей нагрузки preferentially планируются на узлы в разных AZ через pod anti-affinity.
      • Forcible multi-AZ deployment: Поды рабочей нагрузки принудительно планируются на узлы в разных AZ через pod anti-affinity (podAntiAffinity). Если AZ меньше, чем подов, лишние поды не запустятся.
      • Customize affinity: Политики аффинити и анти‑аффинити могут быть настроены. Подробнее см. Configuring Workload Affinity or Anti-affinity Scheduling (podAffinity or podAntiAffinity).
    • Node Affinity: Предлагаются общие политики Node affinity для быстрого развертывания Load affinity.
      • Not configured: Политика Node affinity не настроена.
      • Specify node: Поды рабочей нагрузки могут быть развернуты на указанных узлах через node affinity (nodeAffinity). Если узел не указан, поды будут распределяться случайным образом в соответствии с политикой планирования кластера по умолчанию.
      • Укажите пул узлов: Подобные рабочие pod'ы могут быть развернуты в указанном пуле узлов с помощью node affinity (nodeAffinity). Если пул узлов не указан, pod'ы будут случайным образом запланированы в соответствии с политикой планирования кластера по умолчанию.
      • Настройте привязку: Политики привязки и антипривязки могут быть настроены. Для получения подробной информации см. 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.

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

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

В этом примере используется нагрузка Nginx, и том EVS динамически монтируется к ней с помощью поля volumeClaimTemplates.

  1. Используйте kubectl для доступа к кластеру. Подробности см. в Accessing a Cluster Using kubectl.
  2. Создайте и отредактируйте файл nginx-statefulset.yaml.

    nginx-statefulset.yaml — пример имени файла, его можно изменить по требованию.

    vi nginx-statefulset.yaml

    Ниже приведённый контент является лишь примером. Подробности о StatefulSets см. в Kubernetes official documentation.

    apiVersion: apps/v1
    kind: StatefulSet
    metadata:
    name: nginx
    spec:
    selector:
    matchLabels:
    app: nginx
    template:
    metadata:
    labels:
    app: nginx
    spec:
    containers:
    - name: container-1
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    resources:
    requests:
    cpu: 250m
    memory: 512Mi
    limits:
    cpu: 250m
    memory: 512Mi
    volumeMounts:
    - name: test
    readOnly: false
    mountPath: /usr/share/nginx/html
    subPath: ''
    imagePullSecrets:
    - name: default-secret
    dnsPolicy: ClusterFirst
    volumes: []
    serviceName: nginx-svc
    replicas: 2
    volumeClaimTemplates: # Dynamically mounts the EVS volume to the workload.
    - apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
    name: test
    namespace: default
    annotations:
    everest.io/disk-volume-type: SAS # SAS EVS volume type.
    labels:
    failure-domain.beta.kubernetes.io/region: ru-moscow-1 # region where the EVS volume is created.
    failure-domain.beta.kubernetes.io/zone: ru-moscow-1a # AZ where the EVS volume is created. It must be the same as the AZ of the node.
    spec:
    accessModes:
    - ReadWriteOnce # The value must be ReadWriteOnce for the EVS volume.
    resources:
    requests:
    storage: 10Gi
    storageClassName: csi-disk # StorageClass name. The value is csi-disk for the EVS volume.
    updateStrategy:
    type: RollingUpdate

    Создайте файл nginx-headless.yaml.

    vi nginx-headless.yaml

    Содержимое файла:

    apiVersion: v1
    kind: Service
    metadata:
    name: nginx-svc
    namespace: default
    labels:
    app: nginx
    spec:
    selector:
    app: nginx
    version: v1
    clusterIP: None
    ports:
    - name: nginx
    targetPort: 80
    nodePort: 0
    port: 80
    protocol: TCP
    type: ClusterIP

  3. Создайте нагрузку.

    kubectl create -f nginx-statefulset.yaml

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

    statefulset.apps/nginx created

    Создайте headless Service.

    kubectl create -f nginx-headless.yaml

    Если отображается следующая информация, headless Service успешно создан.

    service/nginx-svc created

  4. Если к нагрузке будет осуществляться доступ через Service типа ClusterIP или NodePort, настройте режим доступа. Подробности см. в Networking.