Propagación de recursos de Kubernetes del clúster de concentrador a clústeres miembros

En este artículo se describe el concepto de propagación de recursos de Kubernetes desde clústeres centrales a clústeres miembros mediante Kubernetes Fleet Manager (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 Fleet, puede crear recursos de Kubernetes en el clúster de concentrador y propagarlos a clústeres miembros seleccionados a través de recursos personalizados de Kubernetes: MemberCluster y ClusterResourcePlacement. Fleet admite estos recursos personalizados basados en una soluciónmulti clúster nativa de nube de código abierto. Para obtener más información, consulte la documentación de Fleet ascendente.

Importante

Las características en vista previa de Azure Kubernetes Fleet Manager están disponibles en autoservicio y de manera opcional. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y la garantía limitada. Las versiones preliminares de Azure Kubernetes Fleet Manager reciben cobertura parcial del soporte al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción.

Flujo de trabajo de propagación de recursos

¿Qué es MemberCluster?

Una vez que un clúster se une a una flota, se crea un recurso personalizado correspondiente MemberCluster en el clúster del concentrador. Puede usar este recurso personalizado para seleccionar clústeres de destino en la propagación de recursos.

Las etiquetas siguientes se pueden usar para la selección de clúster de destino en la propagación de recursos y se agregan automáticamente a todos los clústeres miembro:

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

Para obtener más información, consulte la Referencia de la API MemberCluster.

¿Qué es ClusterResourcePlacement?

Se usa un objeto ClusterResourcePlacement para indicar al programador de Fleet cómo colocar un conjunto determinado de objetos con ámbito de clúster desde el clúster de centro 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.
• Especificación de directivas de selección manual o automática de un subconjunto o de todos 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.

El objeto ClusterResourcePlacement admite mediante ConfigMap sobre el objeto para ayudar a propagarse a los clústeres de miembros sin efectos secundarios no deseados. Los métodos de selección incluyen:

• Grupo, versión y tipo: Seleccione y coloque todos los recursos del tipo especificado.
• Grupo, versión, tipo y nombre: Seleccione y coloque un recurso determinado de un tipo determinado.
• Grupo, versión, tipo y etiquetas: Seleccione y coloque todos los recursos de un tipo determinado que coincidan con las etiquetas proporcionadas.

Para más información, consulte la referencia de API ClusterResourcePlacement.

Al crear el ClusterResourcePlacement, se pueden especificar los siguientes tipos de afinidad:

• requiredDuringSchedulingIgnoredDuringExecution: dado que esta afinidad es del tipo necesario durante la programación, filtra los clústeres en función de sus propiedades.
• preferredDuringSchedulingIgnoredDuringExecution: dado que esta afinidad es solo del tipo preferido, pero no es necesaria durante la programación, proporciona clasificación preferencial a los clústeres en función de las propiedades especificadas por usted, como la disponibilidad de los recursos o el coste.

Hay varios tipos de ubicación disponibles para controlar el número de clústeres a los que se debe propagar el recurso de Kubernetes:

• PickAll coloca los recursos en todos los clústeres miembro disponibles. Esta directiva es útil para colocar cargas de trabajo de infraestructura, como la supervisión de clústeres o las aplicaciones de informes.
• PickFixed coloca los recursos en una lista específica de clústeres miembro por nombre.
• 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.

Directiva de selección de ubicación de PickAll

Puede usar una directiva de selección de ubicación de PickAll para implementar una carga de trabajo en todos los clústeres miembros de Fleet (opcionalmente, coincidir con un conjunto de criterios).

En el ejemplo siguiente se muestra cómo implementar un espacio de nombres test-deployment y todos sus objetos en todos los clústeres etiquetados con 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

Esta directiva sencilla toma el espacio de nombres test-deployment y todos los recursos que contiene y lo implementa en todos los clústeres miembro de la flota con la etiqueta environment especificada. Si quiere implementarlo en todos los clústeres, quite el término affinity.

Directiva de selección de ubicación de PickFixed

Si desea implementar una carga de trabajo en un conjunto conocido de clústeres de miembros, puede usar una directiva de selección de ubicación de PickFixed para seleccionar los clústeres por nombre.

En el ejemplo siguiente se muestra cómo implementar el espacio de nombres de test-deployment en clústeres miembros cluster1 y 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

Directiva de selección de ubicación de PickN

La directiva 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.

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. Puede establecer afinidades obligatorias y preferidas. Las afinidades necesarias impiden la colocación en clústeres que no coinciden con esas afinidades especificadas y las afinidades preferidas permiten ordenar el conjunto de clústeres válidos cuando se toma una decisión de selección de ubicación.

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/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 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, 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 de miembros con diferentes días de actualización:

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

Para obtener más información, consulte la documentación de Fleet sobre restricciones de distribución de topología ascendente.

Estrategia de actualización

Fleet usa una estrategia de actualización gradual para controlar cómo se implementan las actualizaciones en varias ubicaciones del clúster.

En el ejemplo siguiente se muestra cómo configurar una estrategia de actualización gradual mediante la configuración predeterminada:

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

El programador 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.

Para obtener más información, consulte la documentación de Fleet sobre la estrategia de implementación ascendente.

Estado de selección de ubicación

El programador Fleet actualiza los detalles y el estado de las decisiones de colocación en el objeto ClusterResourcePlacement. Puede ver esta información mediante el comando kubectl describe crp <name>. 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.

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

Cambios en la 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 ClusterResourcePlacement pueden desencadenar la eliminación y la reprogramación de una carga de trabajo.
  • Las operaciones de escalado horizontal (aumentando numberOfClusters sin ningún otro cambio) colocan cargas de trabajo solo en clústeres nuevos y no afectan a las ubicaciones existentes.
• Cambios en el clúster, entre los que se incluyen:
  • Un nuevo clúster puede desencadenar la selección de ubicación si cumple la directiva de selección de ubicación, por ejemplo, una directiva de PickAll.
  • Un clúster cuya ubicación se quite de Fleet intentará reemplazar todas las cargas de trabajo afectadas sin afectar a sus otras ubicaciones.

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.

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, como NoSchedule.
• operator: el operador de la tolerancia, como Exists o Equal.

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 obtener más información, consulte la documentación de Fleet ascendente.

Acceso a la API de Kubernetes del clúster de recursos de Fleet

Si ha creado un recurso de Azure Kubernetes Fleet Manager con el clúster de concentrador habilitado, puede usarlo para controlar de forma centralizada escenarios como la propagación de objetos de Kubernetes. Para acceder a la API de Kubernetes del clúster de recursos Fleet, siga los pasos descritos en Acceso a la API de Kubernetes del clúster de recursos Fleet con Azure Kubernetes Fleet Manager.

Pasos siguientes

Configure la propagación de recursos de Kubernetes desde el clúster del concentrador a los clústeresmiembros.