Ubicación de recursos de Kubernetes del clúster de concentrador a clústeres miembro
En este artículo se describe el concepto de ubicación de recursos de Kubernetes de clústeres de concentrador a clústeres miembro mediante Azure Kubernetes Fleet Manager (Kubernetes Fleet).
Los administradores de plataforma suelen necesitar implementar recursos de Kubernetes en varios clústeres por diversos motivos, por ejemplo:
- Administración del control de acceso mediante roles y enlaces de roles en varios clústeres.
- Ejecutar aplicaciones de infraestructura, como Prometheus o Flux, que deben estar en todos los clústeres.
A menudo, los desarrolladores de aplicaciones necesitan implementar recursos de Kubernetes en varios clústeres por varias razones, por ejemplo:
- Implementación de una aplicación de servicio de vídeo en varios clústeres en diferentes regiones para una experiencia de visualización de baja latencia.
- Implementar una aplicación de carro de la compra en dos regiones emparejadas para que los clientes sigan comprando durante una interrupción de una sola región.
- Implementación de una aplicación de proceso por lotes en clústeres con grupos de nodos puntuales económicos disponibles.
Es tedioso crear, actualizar y realizar un seguimiento de estos recursos de Kubernetes en varios clústeres manualmente. Fleet proporciona propagación de recursos de Kubernetes para habilitar la administración a escala de recursos de Kubernetes. Con Kubernetes Fleet, puede crear recursos de Kubernetes en el clúster de concentrador y propagarlos a clústeres miembro seleccionados a través de recursos personalizados de Kubernetes: MemberCluster y ClusterResourcePlacement.
Kubernetes Fleet admite estos recursos personalizados basados en una solución nativa de nube de código abierto de la que puede obtener más información en la documentación de Fleet de código abierto.
Introducción a ClusterResourcePlacement
Se usa un objeto ClusterResourcePlacement para indicar al programador de flotas cómo colocar un conjunto determinado de objetos con ámbito de clúster desde el clúster del centro de flotas en clústeres miembro. Los objetos con ámbito de espacio de nombres como Deployments, StatefulSets, DaemonSets, ConfigMaps, Secrets y PersistentVolumeClaims se incluyen cuando se selecciona su espacio de nombres contenedor.
Con ClusterResourcePlacement, puede:
- Selección de los recursos de Kubernetes con ámbito de clúster que se propagan a los clústeres miembros.
- Especifique las directivas de colocación para seleccionar manualmente o automáticamente los clústeres miembro como clústeres de destino.
- Especificación de estrategias de implementación para implementar de forma segura las actualizaciones de los recursos de Kubernetes seleccionados en varios clústeres de destino.
- Visualización del progreso de propagación hacia cada clúster de destino.
Se muestra un ejemplo en el siguiente diagrama:
Encapsulado de recursos
ClusterResourcePlacement admite el uso de ConfigMap para envolver ciertos tipos de recursos de Kubernetes para que puedan almacenarse en el clúster central sin efectos secundarios no deseados en el clúster central. Para obtener una lista de los tipos de recursos y comprender cómo funciona esta característica, consulte nuestra documentación sobre objetos Envelope.
Tipos de colocación
Los siguientes tipos de ubicación están disponibles para controlar el número de clústeres a los que se debe propagar un recurso de Kubernetes especificado:
- PickFixed coloca el recurso en una lista específica de clústeres miembro por nombre.
- PickAll coloca el recurso en todos los clústeres miembro o en todos los clústeres miembro que cumplen un criterio. Esta directiva es útil para colocar cargas de trabajo de infraestructura, como la supervisión de clústeres o las aplicaciones de informes.
- PickN es la opción de colocación más flexible, ya que permite la selección de clústeres en función de las restricciones de propagación de topología o la afinidad, y resulta útil al distribuir cargas de trabajo entre varios clústeres adecuados para garantizar la disponibilidad deseada.
Tipo de colocación de PickFixed
Si quiere implementar una carga de trabajo en un conjunto conocido de clústeres miembro, puede usar una directiva de colocación PickFixed para seleccionar los clústeres por nombre.
clusterNames es la única opción de directiva válida para este tipo de colocación.
En el ejemplo siguiente se muestra cómo implementar el espacio de nombres de test-deployment en los clústeres miembro cluster1 y 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
Tipo de colocación PickAll
Puede usar un tipo de colocación PickAll para implementar una carga de trabajo en todos los clústeres miembro de la flota o en un subconjunto de clústeres que coincidan con los criterios establecidos.
Al crear este tipo de ubicación, se pueden especificar los siguientes tipos de afinidad de clúster:
- requiredDuringSchedulingIgnoredDuringExecution: como se requiere esta directiva durante la programación, filtra los clústeres en función de los criterios especificados.
En el ejemplo siguiente se muestra cómo implementar un espacio de nombres prod-deployment y todos sus objetos en todos los clústeres etiquetados con 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
Tipo de colocación PickN
El tipo de colocación PickN es la opción más flexible y permite colocar los recursos en un número configurable de clústeres en función de las afinidades y las restricciones de propagación de topología.
Al crear este tipo de ubicación, se pueden especificar los siguientes tipos de afinidad de clúster:
- requiredDuringSchedulingIgnoredDuringExecution: como se requiere esta directiva durante la programación, filtra los clústeres en función de los criterios especificados.
- preferredDuringSchedulingIgnoredDuringExecution: como esta política se prefiere, pero no es obligatoria durante la programación, clasifica los clústeres según criterios específicos.
Puede establecer afinidades obligatorias y preferidas. Las afinidades necesarias impiden la colocación en clústeres que no coinciden y las afinidades preferidas proporcionan la ordenación de clústeres válidos.
PickN con afinidades
El uso de afinidades con una directiva de selección de ubicación de PickN funciona de forma similar al uso de afinidades con la programación de pods.
En el ejemplo siguiente se muestra cómo implementar una carga de trabajo en tres clústeres. Solo los clústeres con la etiqueta critical-allowed: "true" son destinos de selección de ubicación válidos y se da preferencia a los clústeres con la etiqueta 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 con restricciones de propagación de topología
Puede usar restricciones de propagación de topología para forzar la división de las ubicaciones del clúster a través de límites de topología para satisfacer los requisitos de disponibilidad. Por ejemplo, use estas restricciones para dividir las ubicaciones entre regiones o anillos de actualización. También puede configurar restricciones de propagación de topología para evitar la programación si no se puede cumplir la restricción (whenUnsatisfiable: DoNotSchedule) o programar lo mejor posible (whenUnsatisfiable: ScheduleAnyway).
En el ejemplo siguiente se muestra cómo distribuir un conjunto determinado de recursos entre varias regiones e intentar programar entre clústeres miembro con diferentes días de actualización:
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
Para obtener más información, consulte la documentación de Fleet de código abierto sobre restricciones de propagación de topología.
Opciones de directivas de colocación
En la tabla se resumen los campos de directiva de programación disponibles para cada tipo de colocación.
| Campo de directiva | PickFixed | PickAll | PickN |
|---|---|---|---|
placementType |
✅ | ✅ | ✅ |
affinity |
❌ | ✅ | ✅ |
clusterNames |
✅ | ❌ | ❌ |
numberOfClusters |
❌ | ❌ | ✅ |
topologySpreadConstraints |
❌ | ❌ | ✅ |
Selección de clústeres en función de etiquetas y propiedades
Etiquetas y propiedades disponibles para seleccionar clústeres
Al usar los tipos de colocación PickN y PickAll, puede usar las siguientes etiquetas y propiedades como parte de las directivas.
Etiquetas
Las etiquetas siguientes se agregan automáticamente a todos los clústeres miembro y se pueden usar para la selección de clúster de destino en las directivas de colocación de recursos.
| Etiqueta | Descripción |
|---|---|
| fleet.azure.com/location | Región de Azure del clúster (westus) |
| fleet.azure.com/resource-group | Grupo de recursos de Azure del clúster (rg_prodapps_01) |
| fleet.azure.com/subscription-id | Identificador de la suscripción de Azure en la que reside el clúster. Con formato UUID/GUID. |
También puede usar cualquier etiqueta personalizada que aplique a los clústeres.
Propiedades
Las siguientes propiedades están disponibles para su uso como parte de las directivas de colocación.
Las propiedades de CPU y memoria se representan como unidades de recursos de Kubernetes.
Las propiedades de coste son decimales que representan un coste por hora en dólares estadounidenses para el proceso de Azure utilizado para los nodos del clúster. El coste se basa en los precios públicos de Azure.
| Nombre de propiedad | Descripción |
|---|---|
| kubernetes-fleet.io/node-count | Nodos disponibles en el clúster miembro. |
| resources.kubernetes-fleet.io/total-cpu | Total de unidades de recursos de CPU del clúster. |
| resources.kubernetes-fleet.io/allocatable-cpu | Unidades de recursos de CPU asignables del clúster. |
| resources.kubernetes-fleet.io/available-cpu | Unidades de recursos de CPU disponibles del clúster. |
| resources.kubernetes-fleet.io/total-memory | Unidad total de recursos de memoria del clúster. |
| resources.kubernetes-fleet.io/allocatable-memory | Unidades de recursos de memoria asignables del clúster. |
| resources.kubernetes-fleet.io/available-memory | Unidades de recursos de memoria disponibles del clúster. |
| kubernetes.azure.com/per-cpu-core-cost | Coste del núcleo por CPU del clúster. |
| kubernetes.azure.com/per-gb-memory-cost | Coste de memoria por GiB del clúster. |
Especificación de los criterios de selección coincidentes
Al usar las propiedades del clúster en un criterio de directiva, especifique lo siguiente:
Nombre: nombre de la propiedad, que es una de las propiedades enumeradas en las propiedades de este artículo.
Operador: operador que se usa para expresar la condición entre la restricción o el valor deseado y el valor observado en el clúster. Actualmente se admiten los operadores siguientes:
Gt(mayor que): el valor observado de un clúster de la propiedad especificada debe ser mayor que el valor de la condición antes de que se pueda seleccionar para la colocación de recursos.Ge(mayor o igual que): el valor observado de un clúster de la propiedad dada debe ser mayor o igual que el valor de la condición antes de que se pueda seleccionar para la colocación de recursos.Lt(menor que): el valor observado de un clúster de la propiedad especificada debe ser menor que el valor de la condición antes de que se pueda seleccionar para la colocación de recursos.Le(menor o igual que): el valor observado de un clúster de la propiedad especificada debe ser menor o igual que el valor de la condición antes de que se pueda seleccionar para la selección de ubicación de recursos.Eq(igual a): el valor observado de un clúster de la propiedad especificada debe ser igual al valor de la condición antes de que se pueda seleccionar para la colocación de recursos.Ne(no es igual a): el valor observado de un clúster de la propiedad especificada no debe ser igual al valor de la condición antes de que se pueda seleccionar para la selección de ubicación de recursos.
Si usa el operador
Gt,Ge,Lt,Le,EqoNe, la lista de valores de la condición debe tener exactamente un valor.Valores: lista de valores, que son valores posibles de la propiedad.
Fleet evalúa cada clúster en función de las propiedades especificadas en la condición. Si no se cumplen las condiciones enumeradas en requiredDuringSchedulingIgnoredDuringExecution se excluye este clúster miembro de la selección de ubicación de los recursos.
Nota:
Si un clúster miembro no posee la propiedad expresada en la condición, se producirá un error automáticamente en la condición.
Esta es una directiva de colocación de ejemplo para seleccionar solo clústeres con cinco o más nodos.
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"
Funcionamiento de la clasificación de propiedades
Cuando se usa preferredDuringSchedulingIgnoredDuringExecution, un clasificador de propiedades clasifica todos los clústeres de la flota en función de sus valores en el orden ascendente o descendente. Los pesos usados para ordenar se calculan en función del valor especificado.
Un clasificador de propiedades consta de:
- Nombre: nombre de la propiedad del clúster.
- Criterio de ordenación: el criterio de ordenación puede ser
AscendingoDescending. Cuando se usa el ordenAscending, se prefieren los clústeres miembro con un valor observado inferior. Cuando se usa el ordenDescending, se prefieren los clústeres de miembros con un valor observado mayor.
Orden descendente
Para el criterio de ordenación Descendente, el peso proporcional se calcula con la fórmula:
((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value)) * Weight
Por ejemplo, supongamos que quiere clasificar los clústeres en función de la propiedad de la capacidad de CPU disponible en orden descendente y que tiene una flota de tres clústeres con la siguiente CPU disponible:
| Clúster | Capacidad de CPU disponible |
|---|---|
cluster-a |
100 |
cluster-b |
20 |
cluster-c |
10 |
En este caso, el clasificador calcula los pesos siguientes:
| Clúster | Capacidad de CPU disponible | Cálculo | Peso |
|---|---|---|---|
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% |
Orden ascendente
Para el criterio de ordenación Ascendente, el peso proporcional se calcula con la fórmula:
(1 - ((Observed Value - Minimum observed value) / (Maximum observed value - Minimum observed value))) * Weight
Por ejemplo, supongamos que quiere clasificar los clústeres en función de su costo por CPU y núcleo en orden ascendente y que tiene una flota de tres clústeres con los siguientes costos principales de CPU:
| Clúster | Costo de núcleo por CPU |
|---|---|
cluster-a |
1 |
cluster-b |
0,2 |
cluster-c |
0,1 |
En este caso, el clasificador calcula los pesos siguientes:
| Clúster | Costo de núcleo por CPU | Cálculo | Peso |
|---|---|---|---|
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 % |
Uso de tolerancias
Los objetos ClusterResourcePlacement admiten la especificación de tolerancias, que se aplican al objeto ClusterResourcePlacement. Cada objeto de tolerancia consta de los siguientes campos:
key: clave de la tolerancia.value: valor de la tolerancia.effect: el efecto de la tolerancia, comoNoSchedule.operator: el operador de la tolerancia, comoExistsoEqual.
Cada tolerancia se usa para tolerar una o varias marcas específicas aplicadas en el ClusterResourcePlacement. Una vez toleradas todas las marcas en un MemberCluster, el programador puede propagar los recursos al clúster. No se pueden actualizar ni quitar tolerancias de un objeto ClusterResourcePlacement una vez creado.
Para más información, consulte la documentación de Fleet de código abierto sobre las tolerancias.
Configuración de la estrategia de lanzamiento
Fleet usa una estrategia de actualización gradual para controlar cómo se implementan las actualizaciones en los clústeres.
En el ejemplo siguiente, el programador de flotas implementa actualizaciones en cada clúster secuencialmente, esperando al menos unavailablePeriodSeconds entre clústeres. El estado de lanzamiento se considera correcto si todos los recursos se han aplicado correctamente al clúster. La comprobación del estado de lanzamiento no se aplica en cascada a los recursos secundarios; por ejemplo, no confirma que los pods creados por una implementación estén listos.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
name: crp
spec:
resourceSelectors:
- ...
policy:
...
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
unavailablePeriodSeconds: 60
Para más información, consulte la documentación de Fleet de código abierto sobre la estrategia de lanzamiento.
Determinación del estado de colocación
El programador Fleet actualiza los detalles y el estado de las decisiones de colocación en el objeto ClusterResourcePlacement. La salida incluye la siguiente información:
- Las condiciones que se aplican actualmente a la colocación, que incluyen si la colocación se ha completado correctamente.
- Una sección de estado de la colocación para cada clúster miembro, que muestra el estado de implementación en ese clúster.
En el ejemplo siguiente se muestra un ClusterResourcePlacement que implementó el espacio de nombres test y ConfigMap de test-1 en dos clústeres miembro mediante PickN. La colocación se ha completado correctamente y los recursos se han colocado en los clústeres aks-member-1 y aks-member-2.
Puede ver esta información mediante el comando 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
Desencadenadores de cambio de colocación
El programador de Fleet prioriza la estabilidad de las ubicaciones de cargas de trabajo existentes. Esta priorización puede limitar el número de cambios que hacen que se quite y se vuelva a programar una carga de trabajo. Los escenarios siguientes pueden desencadenar cambios de selección de ubicación:
- Los cambios en la directiva de selección de ubicación en el objeto
ClusterResourcePlacementpueden desencadenar la eliminación y la reprogramación de una carga de trabajo.- Las operaciones de escalado horizontal (aumentando
numberOfClusterssin ningún otro cambio) colocan cargas de trabajo solo en clústeres nuevos y no afectan a las ubicaciones existentes.
- Las operaciones de escalado horizontal (aumentando
- Cambios en el clúster, entre los que se incluyen:
- Un nuevo clúster que sea apto puede desencadenar una colocación si el nuevo clúster cumple la directiva de colocación, por ejemplo, una directiva de
PickAll. - Un clúster con colocación se quita de la flota. En función de la directiva, el programador intenta colocar todas las cargas de trabajo afectadas en los clústeres restantes sin que ello afecte a las ubicaciones existentes.
- Un nuevo clúster que sea apto puede desencadenar una colocación si el nuevo clúster cumple la directiva de colocación, por ejemplo, una directiva de
Los cambios de solo recursos (actualizar los recursos o actualizar el ResourceSelector en el objeto ClusterResourcePlacement) se implementan gradualmente en las ubicaciones existentes, pero no desencadenan la reprogramación de la carga de trabajo.
Pasos siguientes
Azure Kubernetes Service