Share via

Распространение ресурсов Kubernetes из концентратора в кластеры-члены (предварительная версия)

  • Статья

В этой статье описывается концепция распространения ресурсов Kubernetes из центральных кластеров в кластеры-члены с помощью диспетчера флотов Azure Kubernetes (Fleet).

Администраторы платформы часто должны развертывать ресурсы Kubernetes в нескольких кластерах по различным причинам, например:

  • Управление доступом с помощью ролей и привязок ролей в нескольких кластерах.
  • Запуск приложений инфраструктуры, таких как Prometheus или Flux, которые должны находиться во всех кластерах.

Разработчики приложений часто должны развертывать ресурсы Kubernetes в нескольких кластерах по различным причинам, например:

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

Он мучен для создания, обновления и отслеживания этих ресурсов Kubernetes в нескольких кластерах вручную. Флот предоставляет распространение ресурсов Kubernetes для обеспечения масштабируемого управления ресурсами Kubernetes. С помощью Fleet можно создать ресурсы Kubernetes в кластере концентратора и распространить их на выбранные кластеры-члены с помощью пользовательских ресурсов Kubernetes: MemberCluster и ClusterResourcePlacement. Fleet поддерживает эти пользовательские ресурсы на основе облачного решения с открытым исходным кодом с несколькими кластерами. Дополнительные сведения см. в документации по вышестоящий Fleet.

Внимание

Предварительные версии функций Azure Kubernetes Fleet Manager доступны на основе самообслуживания. Предварительные версии предоставляются "как есть" и "при наличии". На них не распространяются соглашения об уровне обслуживания и ограниченная гарантия. Предварительные версии Диспетчера флотов Azure Kubernetes частично охватываются поддержкой клиентов на основе лучших усилий. Следовательно, эти функции не предназначены для использования в рабочей среде.

Рабочий процесс распространения ресурсов

Схема, показывая, как ресурс Kubernetes распространяется на кластеры-члены.

Что такое MemberCluster?

После присоединения кластера к флоту создается соответствующий MemberCluster пользовательский ресурс в кластере концентратора. Этот пользовательский ресурс можно использовать для выбора целевых кластеров в распространении ресурсов.

Следующие метки можно использовать для выбора целевого кластера в распространении ресурсов и автоматически добавляться во все кластеры-члены:

  • fleet.azure.com/location
  • fleet.azure.com/resource-group
  • fleet.azure.com/subscription-id

Дополнительные сведения см. в справочнике по API MemberCluster.

Что такое ClusterResourcePlacement?

Объект ClusterResourcePlacement используется для того, чтобы сообщить планировщику парка, как поместить заданный набор объектов, область кластеров из кластера концентратора в кластеры-члены. Объекты namespace-область d, такие как Deployments, StatefulSets, DaemonSets, Config Карты, Secret и PersistentVolumeClaims, включаются при выборе их содержащего пространства имен.

С помощью ClusterResourcePlacement:

  • Выберите, какие ресурсы Kubernetes кластера область для распространения в кластеры-члены.
  • Укажите политики размещения, чтобы вручную или автоматически выбрать подмножество или все кластеры-члены в качестве целевых кластеров.
  • Укажите стратегии развертывания для безопасного развертывания всех обновлений выбранных ресурсов Kubernetes в нескольких целевых кластерах.
  • Просмотрите ход распространения по отношению к каждому целевому кластеру.

Объект ClusterResourcePlacement поддерживает использование ConfigMap для конверта объекта для распространения в кластеры-члены без каких-либо непреднамеренных побочных эффектов. К методам выбора относятся:

  • Группа, версия и тип: выберите и поместите все ресурсы заданного типа.
  • Группа, версия, тип и имя: выберите и поместите один конкретный ресурс заданного типа.
  • Группа, версия, тип и метки: выберите и поместите все ресурсы заданного типа, соответствующие предоставленным меткам.

Дополнительные сведения см. в справочнике ClusterResourcePlacement по API.

При создании ClusterResourcePlacementможно указать следующие типы сходства:

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

Для управления количеством кластеров, в которых необходимо распространить ресурс Kubernetes, доступны несколько типов размещения:

  • PickAll помещает ресурсы во все доступные кластеры-члены. Эта политика полезна для размещения рабочих нагрузок инфраструктуры, таких как мониторинг кластера или приложения отчетов.
  • PickFixed помещает ресурсы в определенный список кластеров-членов по имени.
  • PickN является наиболее гибким вариантом размещения и позволяет выбирать кластеры на основе ограничений сходства или топологии и полезно при распространении рабочих нагрузок по нескольким соответствующим кластерам, чтобы обеспечить доступность.

PickAll Политика размещения

Политику размещения можно использовать PickAll для развертывания рабочей нагрузки во всех кластерах-членах в флоте (при необходимости соответствует набору критериев).

В следующем примере показано, как развернуть test-deployment пространство имен и все его объекты во всех кластерах, помеченных следующим environment: productionобразом:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-1
spec:
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1

Эта простая политика принимает test-deployment пространство имен и все ресурсы, содержащиеся в нем, и развертывает его во всех кластерах-членах в флоте с заданной environment меткой. Если все кластеры нужны, можно полностью удалить affinity термин.

PickFixed Политика размещения

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

В следующем примере показано, как развернуть test-deployment пространство имен в кластерах-членах cluster1 и cluster2:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-2
spec:
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-deployment
      version: v1

PickN Политика размещения

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

PickN сходствами

Использование сопоставлений PickN с функциями политики размещения аналогично использованию сходства с планированием pod. Можно задать как обязательные, так и предпочитаемые сходства. Обязательные сходства предотвращают размещение кластеров, которые не соответствуют им указанным сходствам, и предпочтительный сходства позволяют упорядочивать набор допустимых кластеров при принятии решения о размещении.

В следующем примере показано, как развернуть рабочую нагрузку в трех кластерах. Только кластеры с critical-allowed: "true" меткой являются допустимыми целевыми объектами размещения, а предпочтения предоставляются кластерам с меткой critical-level: 1:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

PickN с ограничениями распространения топологии

Ограничения распространения топологии можно использовать для принудительного разделения размещения кластера по границам топологии, чтобы удовлетворить требования к доступности, например разделение размещения между регионами или кольцами обновления. Можно также настроить ограничения распространения топологии, чтобы предотвратить планирование, если ограничение не удается выполнить (whenUnsatisfiable: DoNotSchedule) или запланировать максимально возможное (whenUnsatisfiable: ScheduleAnyway).

В следующем примере показано, как распределить заданный набор ресурсов между несколькими регионами и попытаться запланировать кластеры членов с разными днями обновления:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: region
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Дополнительные сведения см. в документации по вышестоящий ограничениям распространения топологии Fleet.

Стратегия обновления

Флот использует стратегию последовательного обновления для управления развертыванием обновлений в нескольких размещениях кластера.

В следующем примере показано, как настроить стратегию последовательного обновления с помощью параметров по умолчанию:

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp
spec:
  resourceSelectors:
    - ...
  policy:
    ...
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Планировщик развертывает обновления для каждого кластера последовательно, ожидая по крайней мере unavailablePeriodSeconds между кластерами. Состояние развертывания считается успешным, если все ресурсы были правильно применены к кластеру. Состояние развертывания проверка не каскадно для дочерних ресурсов, например, не подтверждает, что модули pod, созданные развертыванием, становятся готовыми.

Дополнительные сведения см. в документации по стратегии развертывания вышестоящий Fleet.

Состояние размещения

Планировщик флота обновляет сведения и состояние о принятии ClusterResourcePlacement решений о размещении на объекте. Эти сведения можно просмотреть с помощью kubectl describe crp <name> команды. Выходные данные содержат следующие сведения:

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

В следующем примере показано ClusterResourcePlacement , что развертывание test пространства имен и test-1 ConfigMap в двух кластерах-членах используется PickN. Размещение было успешно завершено, а ресурсы были помещены в aks-member-1 кластеры и aks-member-2 кластеры.

Name:         crp-1
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  placement.kubernetes-fleet.io/v1beta1
Kind:         ClusterResourcePlacement
Metadata:
  ...
Spec:
  Policy:
    Number Of Clusters:  2
    Placement Type:      PickN
  Resource Selectors:
    Group:
    Kind:                  Namespace
    Name:                  test
    Version:               v1
  Revision History Limit:  10
Status:
  Conditions:
    Last Transition Time:  2023-11-10T08:14:52Z
    Message:               found all the clusters needed as specified by the scheduling policy
    Observed Generation:   5
    Reason:                SchedulingPolicyFulfilled
    Status:                True
    Type:                  ClusterResourcePlacementScheduled
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               All 2 cluster(s) are synchronized to the latest resources on the hub cluster
    Observed Generation:   5
    Reason:                SynchronizeSucceeded
    Status:                True
    Type:                  ClusterResourcePlacementSynchronized
    Last Transition Time:  2023-11-10T08:23:43Z
    Message:               Successfully applied resources to 2 member clusters
    Observed Generation:   5
    Reason:                ApplySucceeded
    Status:                True
    Type:                  ClusterResourcePlacementApplied
  Placement Statuses:
    Cluster Name:  aks-member-1
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-1 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
    Cluster Name:            aks-member-2
    Conditions:
      Last Transition Time:  2023-11-10T08:14:52Z
      Message:               Successfully scheduled resources for placement in aks-member-2 (affinity score: 0, topology spread score: 0): picked by scheduling policy
      Observed Generation:   5
      Reason:                ScheduleSucceeded
      Status:                True
      Type:                  ResourceScheduled
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully Synchronized work(s) for placement
      Observed Generation:   5
      Reason:                WorkSynchronizeSucceeded
      Status:                True
      Type:                  WorkSynchronized
      Last Transition Time:  2023-11-10T08:23:43Z
      Message:               Successfully applied resources
      Observed Generation:   5
      Reason:                ApplySucceeded
      Status:                True
      Type:                  ResourceApplied
  Selected Resources:
    Kind:       Namespace
    Name:       test
    Version:    v1
    Kind:       ConfigMap
    Name:       test-1
    Namespace:  test
    Version:    v1
Events:
  Type    Reason                     Age                    From                                   Message
  ----    ------                     ----                   ----                                   -------
  Normal  PlacementScheduleSuccess   12m (x5 over 3d22h)    cluster-resource-placement-controller  Successfully scheduled the placement
  Normal  PlacementSyncSuccess       3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Successfully synchronized the placement
  Normal  PlacementRolloutCompleted  3m28s (x7 over 3d22h)  cluster-resource-placement-controller  Resources have been applied to the selected clusters

Изменения размещения

Планировщик флота определяет стабильность существующих размещения рабочих нагрузок. Эта приоритетность может ограничить количество изменений, из-за которых рабочая нагрузка будет удалена и перепланирована. Следующие сценарии могут активировать изменения размещения:

  • Изменения политики размещения в объекте ClusterResourcePlacement могут активировать удаление и изменение планирования рабочей нагрузки.
    • Операции горизонтального масштабирования (увеличивающееся numberOfClusters без других изменений) размещают рабочие нагрузки только в новых кластерах и не влияют на существующие размещения.
  • Изменения кластера, в том числе:
    • Новый кластер, который становится допустимым, может активировать размещение, если он соответствует политике размещения, например, политике PickAll .
    • Кластер с размещением удаляется из парка, попытается заменить все затронутые рабочие нагрузки, не затрагивая их другие размещения.

Изменения только для ресурсов (обновление ресурсов или обновление ResourceSelector в объекте ClusterResourcePlacement ) постепенно развертывается в существующих размещениях, но не активируют перепланирование рабочей нагрузки.

Допуски

ClusterResourcePlacement объекты поддерживают спецификацию толерации, которые применяются к объекту ClusterResourcePlacement . Каждый объект терпимости состоит из следующих полей:

  • key: ключ терпимости.
  • value: значение толерации.
  • effect: эффект толерации, например NoSchedule.
  • operator: оператор толерации, например Exists или Equal.

Каждая терпимость используется для того, чтобы терпеть один или несколько конкретных запятых, примененных к .ClusterResourcePlacement После того как все ограничения на наличие ограничений MemberCluster допускаются, планировщик может затем распространять ресурсы в кластер. Невозможно обновить или удалить терпимые данные из ClusterResourcePlacement объекта после его создания.

Дополнительные сведения см. в документации по вышестоящий Fleet.

Доступ к API Kubernetes кластера ресурсов Fleet

Если вы создали ресурс Azure Kubernetes Fleet Manager с включенным кластером концентратора, его можно использовать для централизованного управления сценариями распространения объектов Kubernetes. Чтобы получить доступ к API Kubernetes кластера ресурсов Fleet, выполните действия, описанные в статье "Доступ к API Kubernetes кластера ресурсов флота" с помощью диспетчера флота Azure Kubernetes.

Следующие шаги

Настройте распространение ресурсов Kubernetes из концентратора в кластеры-члены.