Размещение ресурсов Kubernetes из концентратора в кластеры-члены
В этой статье описывается концепция размещения ресурсов Kubernetes из центральных кластеров в кластеры-члены с помощью диспетчера флотов Azure Kubernetes (Kubernetes Fleet).
Администраторы платформы часто должны развертывать ресурсы Kubernetes в нескольких кластерах по различным причинам, например:
- Управление доступом с помощью ролей и привязок ролей в нескольких кластерах.
- Запуск приложений инфраструктуры, таких как Prometheus или Flux, которые должны находиться во всех кластерах.
Разработчики приложений часто должны развертывать ресурсы Kubernetes в нескольких кластерах по различным причинам, например:
- Развертывание приложения для обслуживания видео в нескольких кластерах в разных регионах для низкой задержки при просмотре.
- Развертывание приложения корзины для покупок в двух парных регионах для клиентов, которые будут продолжать работать в магазине во время сбоя в одном регионе.
- Развертывание пакетного вычислительного приложения в кластерах с доступными недорогими пулами точечных узлов.
Он мучен для создания, обновления и отслеживания этих ресурсов Kubernetes в нескольких кластерах вручную. Флот предоставляет распространение ресурсов Kubernetes для обеспечения масштабируемого управления ресурсами Kubernetes. С помощью Парка Kubernetes можно создать ресурсы Kubernetes в кластере концентратора и распространить их на выбранные кластеры членов с помощью пользовательских ресурсов Kubernetes: MemberCluster и ClusterResourcePlacement.
Kubernetes Fleet поддерживает эти пользовательские ресурсы на основе облачного решения с открытым исходным кодом, которое можно узнать больше о документации по открытый код Fleet.
Знакомство с ClusterResourcePlacement
Объект ClusterResourcePlacement используется для того, чтобы сообщить планировщику парка, как поместить заданный набор кластеризованных объектов из кластера концентратора флота в кластеры-члены. Объекты с областью действия пространства имен, такие как Deployments, StatefulSets, DaemonSets, ConfigMaps, Secret и PersistentVolumeClaims, включаются при выборе их содержащего пространства имен.
С помощью ClusterResourcePlacement:
- Выберите, какие ресурсы Kubernetes в области кластера будут распространяться на кластеры-члены.
- Укажите политики размещения, чтобы вручную или автоматически выбрать кластеры-члены в качестве целевых кластеров.
- Укажите стратегии развертывания для безопасного развертывания всех обновлений выбранных ресурсов Kubernetes в нескольких целевых кластерах.
- Просмотрите ход распространения по отношению к каждому целевому кластеру.
Образец показан на следующей схеме.
Инкапсулирование ресурсов
ClusterResourcePlacement поддерживает использование ConfigMap для конверта определенных типов ресурсов Kubernetes, чтобы они могли быть организованы в кластере концентратора без каких-либо непреднамеренных побочных эффектов в кластере концентратора. Список типов ресурсов и сведения о том, как эта функция работает, см. в документации по объекту конверта
Типы размещения
Для управления количеством кластеров, к которым необходимо распространить указанный ресурс Kubernetes, доступны следующие типы размещения:
- При выборе по имени ресурс помещает ресурс в определенный список кластеров-членов.
- PickAll помещает ресурс во все кластеры-члены или все кластеры-члены, соответствующие критериям. Эта политика полезна для размещения рабочих нагрузок инфраструктуры, таких как мониторинг кластера или приложения отчетов.
- PickN — это самый гибкий вариант размещения и позволяет выбирать кластеры на основе ограничений сходства или топологии и полезно при распространении рабочих нагрузок по нескольким соответствующим кластерам, чтобы обеспечить доступность.
Тип размещения PickFixed
Если вы хотите развернуть рабочую нагрузку в известном наборе кластеров-членов, можно использовать PickFixed политику размещения для выбора кластеров по имени.
clusterNames — единственный допустимый параметр политики для этого типа размещения.
В следующем примере показано, как развернуть test-deployment пространство имен в кластерах-членах cluster1 и cluster2.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-fixed
spec:
policy:
placementType: PickFixed
clusterNames:
- cluster1
- cluster2
resourceSelectors:
- group: ""
kind: Namespace
name: test-deployment
version: v1
Тип размещения PickAll
Тип размещения можно использовать PickAll для развертывания рабочей нагрузки во всех кластерах-членах в флоте или в подмножестве кластеров, которые соответствуют заданным критериям.
При создании этого типа размещения можно указать следующие типы сходства кластера:
- requiredDuringSchedulingIgnoredDuringExecution: так как эта политика требуется во время планирования, он фильтрует кластеры на основе указанных критериев.
В следующем примере показано, как развернуть prod-deployment пространство имен и все его объекты во всех кластерах, помеченных следующим environment: productionобразом:
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickall
spec:
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- labelSelector:
matchLabels:
environment: production
resourceSelectors:
- group: ""
kind: Namespace
name: prod-deployment
version: v1
Тип размещения PickN
Тип PickN размещения является наиболее гибким вариантом и позволяет размещать ресурсы в настраиваемом количестве кластеров на основе сходств и ограничений распространения топологии.
При создании этого типа размещения можно указать следующие типы сходства кластера:
- requiredDuringSchedulingIgnoredDuringExecution: так как эта политика требуется во время планирования, он фильтрует кластеры на основе указанных критериев.
- preferredDuringSchedulingIgnoredDuringExecution: так как эта политика предпочтительна, но не требуется во время планирования, он ранжирует кластеры на основе указанных критериев.
Можно задать как обязательные, так и предпочитаемые сходства. Обязательные сходства предотвращают размещение кластеров, которые не соответствуют, и предпочтительный сходства обеспечивают порядок допустимых кластеров.
PickN сходствами
Использование сопоставлений PickN с функциями политики размещения аналогично использованию сходства с планированием pod.
В следующем примере показано, как развернуть рабочую нагрузку на три кластера. Только кластеры с critical-allowed: "true" меткой являются допустимыми целевыми объектами размещения, а предпочтения предоставляются кластерам с меткой critical-level: 1:
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-01
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/v1
kind: ClusterResourcePlacement
metadata:
name: crp-pickn-02
spec:
resourceSelectors:
- ...
policy:
placementType: PickN
topologySpreadConstraints:
- maxSkew: 2
topologyKey: region
whenUnsatisfiable: DoNotSchedule
- maxSkew: 2
topologyKey: updateDay
whenUnsatisfiable: ScheduleAnyway
Дополнительные сведения см. в ограничениях топологии топологии документации по флоту с открытым исходным кодом.
Параметры политики размещения
В таблице перечислены доступные поля политики планирования для каждого типа размещения.
| Поле политики | PickFixed | PickAll | Выбор имени |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Выбор кластеров на основе меток и свойств
Доступные метки и свойства для выбора кластеров
При использовании PickN типов и размещения можно использовать следующие метки и PickAll свойства в рамках политик.
Наклейки
Следующие метки автоматически добавляются во все кластеры-члены и могут использоваться для выбора целевого кластера в политиках размещения ресурсов.
| Label | Description |
|---|---|
| fleet.azure.com/location | Регион Azure кластера (westus) |
| fleet.azure.com/resource-group | Группа ресурсов Azure кластера (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Идентификатор подписки Azure, в котором находится кластер. Форматируется как UUID/GUID. |
Вы также можете использовать любые пользовательские метки, применяемые к кластерам.
Свойства
Следующие свойства доступны для использования в рамках политик размещения.
Свойства ЦП и памяти представлены в виде единиц ресурсов Kubernetes.
Свойства затрат — это десятичные знаки, представляющие затраты за час в долларах США для вычислительных ресурсов Azure, используемых для узлов в кластере. Стоимость основана на общедоступных ценах Azure.
| Имя свойства | Description |
|---|---|
| kubernetes-fleet.io/node-count | Доступные узлы в кластере-члене. |
| resources.kubernetes-fleet.io/total-cpu | Общее количество единиц ресурсов ЦП кластера. |
| resources.kubernetes-fleet.io/allocatable-cpu | Выделенные единицы ресурсов ЦП кластера. |
| resources.kubernetes-fleet.io/available-cpu | Доступные единицы ресурсов ЦП кластера. |
| resources.kubernetes-fleet.io/total-memory | Общая единица ресурсов памяти кластера. |
| resources.kubernetes-fleet.io/allocatable-memory | Единицы ресурсов памяти, доступные для выделения. |
| resources.kubernetes-fleet.io/available-memory | Доступные единицы ресурсов памяти кластера. |
| kubernetes.azure.com/per-cpu-core-cost | Стоимость ядра ЦП кластера. |
| kubernetes.azure.com/per-gb-memory-cost | Затраты на память ГиБ кластера. |
Указание критериев сопоставления выбора
При использовании свойств кластера в критерии политики необходимо указать следующее:
Имя: имя свойства, которое является одним из свойств , перечисленных в свойствах в этой статье.
Оператор: оператор, используемый для выражения условия между ограничением или требуемым значением и наблюдаемым значением в кластере. В настоящее время поддерживаются следующие операторы:
Gt(Больше): наблюдаемое значение данного свойства кластера должно быть больше значения в условии, прежде чем его можно будет выбрать для размещения ресурсов.Ge(Больше или равно): наблюдаемое значение кластера данного свойства должно быть больше или равно значению в условии, прежде чем его можно будет выбрать для размещения ресурсов.Lt(Меньше): наблюдаемое значение кластера данного свойства должно быть меньше значения в условии, прежде чем его можно будет выбрать для размещения ресурсов.Le(Меньше или равно): наблюдаемое значение кластера данного свойства должно быть меньше или равно значению в условии, прежде чем его можно будет выбрать для размещения ресурсов.Eq(Равно): наблюдаемое значение кластера данного свойства должно быть равно значению в условии, прежде чем его можно будет выбрать для размещения ресурсов.Ne(Не равно): наблюдаемое значение данного свойства кластера не должно совпадать со значением в условии, прежде чем его можно будет выбрать для размещения ресурсов.
Если используется оператор
Gt,Ge, ,LtLeEqилиNe, список значений в условии должен иметь ровно одно значение.Значения: список значений, которые являются возможными значениями свойства.
Парк оценивает каждый кластер на основе свойств, указанных в условии. Не удалось выполнить условия, перечисленные в разделе " requiredDuringSchedulingIgnoredDuringExecution Исключить этот кластер-член" из размещения ресурсов.
Примечание.
Если кластер-член не обладает свойством, выраженным в условии, он автоматически завершится сбоем условия.
Ниже приведен пример политики размещения для выбора только кластеров с пятью или более узлами.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
placementType: PickAll
affinity:
clusterAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
clusterSelectorTerms:
- propertySelector:
matchExpressions:
- name: "kubernetes-fleet.io/node-count"
operator: Ge
values:
- "5"
Принцип работы ранжирования свойств
При preferredDuringSchedulingIgnoredDuringExecution использовании сортировщик свойств ранжирует все кластеры в флоте на основе их значений в порядке возрастания или убывания. Весы, используемые для упорядочивания, вычисляются на основе указанного значения.
Сортировщик свойств состоит из следующих элементов:
- Имя: имя свойства кластера.
- Порядок сортировки: порядок сортировки может быть либо
AscendingлибоDescending. ПриAscendingиспользовании порядка предпочтительнее использовать кластеры-члены с более низкими наблюдаемыми значениями. ПриDescendingиспользовании порядка кластеры-члены с более высоким наблюдаемым значением предпочтительнее.
Порядок убывания
Для убывания порядка сортировки пропорциональный вес вычисляется с помощью формулы:
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Например, предположим, что вы хотите ранжировать кластеры на основе свойства доступной емкости ЦП в порядке убывания и что у вас есть парк из трех кластеров со следующим доступным ЦП:
| Кластер | Доступная емкость ЦП |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
В этом случае сортировщик вычисляет следующие весовые значения:
| Кластер | Доступная емкость ЦП | Расчет | Вес |
|---|---|---|---|
cluster-a |
100 | (100 - 10) / (100 - 10) | 100% |
cluster-b |
20 | (20 - 10) / (100 - 10) | 11.11% |
cluster-c |
10 | (10 - 10) / (100 - 10) | 0% |
Порядок возрастания
Для сортировки по возрастанию пропорциональный вес вычисляется с помощью формулы:
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Например, предположим, что вы хотите ранжировать кластеры на основе их затрат на ЦП-ядра в порядке возрастания и что у вас есть флот из трех кластеров со следующими затратами на ЦП:
| Кластер | Затраты на ядро ЦП |
|---|---|
cluster-a |
1 |
cluster-b |
0,2 |
cluster-c |
0,1 |
В этом случае сортировщик вычисляет следующие весовые значения:
| Кластер | Затраты на ядро ЦП | Расчет | Вес |
|---|---|---|---|
cluster-a |
1 | 1 - ((1 - 0.1) / (1 - 0.1)) | 0% |
cluster-b |
0,2 | 1 - ((0.2 - 0.1) / (1 - 0.1)) | 88.89% |
cluster-c |
0,1 | 1 - (0.1 - 0.1) / (1 - 0.1) | 100% |
Использование толерации
ClusterResourcePlacement объекты поддерживают спецификацию толерации, которые применяются к объекту ClusterResourcePlacement . Каждый объект терпимости состоит из следующих полей:
key: ключ терпимости.value: значение толерации.effect: эффект толерации, напримерNoSchedule.operator: оператор толерации, напримерExistsилиEqual.
Каждая терпимость используется для того, чтобы терпеть один или несколько конкретных примечений, примененных к нему ClusterResourcePlacement. После того как все ограничения на наличие ограничений MemberCluster допускаются, планировщик может затем распространять ресурсы в кластер. Невозможно обновить или удалить терпимые данные из ClusterResourcePlacement объекта после создания.
Дополнительные сведения см. в документации по флоту с открытым исходным кодом по терпимости.
Настройка стратегии развертывания
Флот использует стратегию последовательного обновления для управления развертыванием обновлений в кластерах.
В следующем примере планировщик парка развертывает обновления для каждого кластера последовательно, ожидая по крайней мере unavailablePeriodSeconds между кластерами. Состояние развертывания считается успешным, если все ресурсы были правильно применены к кластеру. Проверка состояния развертывания не каскадно выполняется для дочерних ресурсов, поэтому, например, не подтверждается, что модули pod, созданные развертыванием, становятся готовыми.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Дополнительные сведения см. в документации по флоту с открытым исходным кодом по стратегии развертывания.
Определение состояния размещения
Планировщик флота обновляет сведения и состояние о принятии ClusterResourcePlacement решений о размещении на объекте. Выходные данные содержат следующие сведения:
- Условия, которые в настоящее время применяются к размещению, в том числе, если размещение было успешно завершено.
- Раздел состояния размещения для каждого кластера-члена, который показывает состояние развертывания в этом кластере.
В следующем примере показано ClusterResourcePlacement , что развертывание test пространства имен и test-1 ConfigMap в двух кластерах-членах используется PickN. Размещение было успешно завершено, а ресурсы были помещены в aks-member-1 кластеры и aks-member-2 кластеры.
Эти сведения можно просмотреть с помощью kubectl describe crp <name> команды.
kubectl describe crp crp-1
Name: crp-1
Namespace:
Labels: <none>
Annotations: <none>
API Version: placement.kubernetes-fleet.io/v1
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 ) постепенно развертывается в существующих размещениях, но не активируют перепланирование рабочей нагрузки.
Следующие шаги
Azure Kubernetes Service