Introducción a la ubicación inteligente de recursos de Azure Kubernetes Fleet Manager

Se aplica a ✔️ Administrador de flota ✔️ Administrador de flota con clúster central

La administración de recursos de Kubernetes en varios clústeres presenta desafíos significativos tanto para los administradores de plataformas como para los desarrolladores de aplicaciones. A medida que las organizaciones escalan su infraestructura de Kubernetes más allá de un único clúster, a menudo encuentran complejidades relacionadas con la distribución de recursos, la coherencia y la sobrecarga de administración manual. El enfoque tradicional de administrar cada clúster de forma independiente crea silos operativos cada vez más difíciles de mantener a medida que crece el tamaño de la flota.

Los administradores de plataformas suelen necesitar implementar recursos de Kubernetes en varios clústeres por varias razones, entre las que se incluyen:

• 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 y potencialmente propenso a errores crear, actualizar y realizar un seguimiento de los recursos de Kubernetes en varios clústeres manualmente.

En este artículo se analiza cómo puede usar la funcionalidad de asignación inteligente de recursos del administrador de flota para gestionar la distribución de recursos de Kubernetes limitados a clústeres y espacios de nombres en los clústeres miembros de una flota.

La funcionalidad de selección de ubicación de recursos de Fleet Manager se basa en el proyecto CNCF KubeFleet.

Visión general del proceso de ubicación de recursos

Para usar la ubicación inteligente de recursos de Fleet Manager, siga estos pasos:

1. Preparar recursos en el clúster hub: utilice la implementación continua, GitOps o un método similar para aplicar los manifiestos de las distribuciones de recursos en el clúster hub de Fleet Manager.
2. Crear una ubicación de recursos: cree un manifiesto de selección de ubicación que seleccione el recurso y defina una directiva para elegir qué clústeres miembros reciben el recurso.
3. Aplicar la ubicación de recursos en el clúster concentrador: aplique el manifiesto de ubicación al clúster concentrador para comenzar a distribuir el recurso.
4. Fleet Manager programa recursos: Fleet Manager observa la ubicación de los recursos y el ámbito seleccionado, y realiza la distribución de los recursos.
5. Observe la distribución a través de la ubicación de los recursos: consulte la ubicación del recurso en el clúster del centro para comprobar el estado del recurso a medida que se implementa.

Fleet Manager tiene una experiencia en el portal de Azure para la colocación de recursos que proporciona una representación más visual del despliegue.

Componentes de colocación de recursos

Una ubicación de recursos, independientemente del ámbito (clúster o espacio de nombres), consta de los siguientes componentes:

• Selectores de recursos: seleccione los recursos que se van a incluir a través de resourceSelectors.
• Directiva de ubicación: defina cómo seleccionar clústeres mediante placementType usando uno de los tipos PickAll, PickFixed o PickN.
• Estrategia de implementación: controle cómo se implementan los recursos en los clústeres seleccionados mediante la inclusión de un opcional strategy.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll   

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Selectores de recursos

Seleccione recursos usando uno o varios resourceSelectors en un emplazamiento. Cada selector de recursos puede especificar:

• Group, Version, Kind (GVK): el tipo de recurso de Kubernetes que se va a seleccionar.
• Nombre: nombre de un recurso específico.
• Selectores de etiquetas: etiquetas para que coincidan con varios recursos.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: namespace-only-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly
  policy:
    placementType: PickAll

Política de ubicación

La colocación de recursos de Fleet Manager admite los siguientes tipos de directiva de selección de ubicación para controlar cómo selecciona clústeres:

• PickFixed coloca los recursos en los clústeres de miembros mediante sus nombres de clúster.
• PickAll coloca los recursos en todos los clústeres de miembros o en todos los clústeres de miembros 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 ubicación más flexible. Le permite seleccionar clústeres en función de la afinidad o de las restricciones de dispersión de topología. Use esta directiva al distribuir cargas de trabajo entre varios clústeres similares para garantizar que se mantenga la disponibilidad.

Tipo de colocación de PickFixed

Use PickFixed para seleccionar los clústeres por nombre. Proporcione nombres en la clusterNames matriz.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Tipo de colocación PickAll

Use PickAll para distribuir recursos entre todos los clústeres de miembros o todos los clústeres que coincidan con los criterios especificados.

Al crear este tipo de selección de ubicación, especifique 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.

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

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                        environment: production

Tipo de colocación PickN

Use PickN para distribuir 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 selección de ubicación, especifique 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. Las afinidades preferidas proporcionan la ordenación de los clústeres coincidentes.

PickN con afinidades

Usar afinidades con una PickN política de ubicación funciona igual que usar afinidades con la planificación de pods en un único clúster de Kubernetes.

En el ejemplo siguiente se muestra cómo implementar un recurso 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-critical-preferences
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    numberOfClusters: 3
    affinity:
        clusterAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
              weight: 20
              preference:
              - labelSelector:
                  matchLabels:
                    critical-level: 1
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      critical-allowed: "true"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-critical-preferences
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 distribución de topología

Utilice restricciones de distribución entre topologías para forzar la ubicación entre distintos dominios topológicos y así satisfacer los requisitos de disponibilidad.

Puede configurar el comportamiento de las restricciones de propagación de topología mediante la whenUnsatisfiable propiedad :

• DoNotSchedule: si no se puede cumplir la restricción, se rechaza la solicitud de asignación de ubicación.
• ScheduleAnyway: si no se puede cumplir la restricción, coloque los recursos de todos modos.

El siguiente ejemplo muestra cómo distribuir recursos entre varias regiones de Azure e intenta programarlos en los clústeres miembro con distintos días de actualización mediante el uso de una etiqueta personalizada updateDay.

Cuando no se puede cumplir la distribución entre regiones de Azure, se produce un error en la colocación. Si no se cumple la restricción updateDay, aun así se realiza la colocación.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pickn-locations-updates
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickn-locations-updates
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickN
    topologySpreadConstraints:
    - maxSkew: 2
      topologyKey: fleet.azure.com/location
      whenUnsatisfiable: DoNotSchedule
    - maxSkew: 2
      topologyKey: updateDay
      whenUnsatisfiable: ScheduleAnyway

Para obtener más información, consulte la documentación de KubeFleet sobre restricciones de propagación de topología.

Selección de clústeres mediante etiquetas y propiedades

La colocación inteligente de recursos de Fleet Manager proporciona un conjunto de criterios eficaces que puede usar al determinar cómo seleccionar clústeres al usar los PickN tipos de ubicación y PickAll . En esta sección, aprenderá a usar estas opciones para crear directivas que se adapten a sus necesidades.

Opciones de directivas de colocación

En la tabla siguiente se muestran los campos disponibles de la política de programación para cada tipo de ubicación.

Etiquetas de miembros del clúster

Puede etiquetar el MemberCluster recurso en el clúster de concentrador, como cualquier recurso de Kubernetes.

Además, Fleet Manager agrega automáticamente las siguientes etiquetas de solo lectura a todos los clústeres miembro.

Propiedades de clúster

Use las siguientes propiedades como parte de las directivas de selección de ubicación.

• Las unidades de recursos de Kubernetes representan las propiedades de CPU y memoria. Para más información, consulte Unidades de recursos en Kubernetes.

• Las propiedades de coste son valores decimales que representan un coste por hora en dólares estadounidenses de la capacidad de proceso de Azure que usan los nodos del clúster. El coste se basa en los precios públicos de Azure.

Criterios de coincidencia de selección

Al usar las propiedades del clúster en un criterio de directiva, especifique:

• Nombre: nombre de la propiedad, que es una de las propiedades enumeradas en las propiedades de este artículo.

• Operador: operador que expresa la condición entre la restricción o el valor deseado y el valor observado en el clúster. Actualmente se admiten los siguientes operadores:

  • 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 colocación de recursos.

  Si usa el operador Gt, Ge, Lt, Le, Eq o Ne, 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 que especifique en la condición. Si un clúster no cumple las condiciones enumeradas en requiredDuringSchedulingIgnoredDuringExecution, Fleet excluye el clúster de la ubicación de los recursos.

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-pickall-five-nodes
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
    affinity:
        clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
                clusterSelectorTerms:
                - propertySelector:
                    matchExpressions:
                    - name: "kubernetes-fleet.io/node-count"
                      operator: Ge
                      values:
                      - "5"

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-five-nodes
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  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 orden ascendente o descendente. Los pesos usados para la ordenación 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 Ascending o Descending. Al usar Ascending el orden, se prefieren los clústeres de miembros con valores observados inferiores. Cuando se usa Descending el orden, se prefieren los clústeres de miembros con un valor observado mayor.

Para obtener más información, consulte la documentación de KubeFleet sobre la programación basada en propiedades.

Configuración de la estrategia de lanzamiento

La colocación de recursos de Fleet Manager usa una estrategia predeterminada RollingUpdate para controlar cómo se distribuyen los recursos a los clústeres miembro.

En el ejemplo siguiente, la implementación se realiza en cada clúster miembro de manera secuencial, esperando al menos unavailablePeriodSeconds entre los clústeres.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: crp-pick-all-rolling
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: prod-deployment
      version: v1
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

El estado del despliegue se considera satisfactorio si todos los recursos se aplican correctamente al clúster. Este estado no aplica en cascada el estado de los recursos secundarios, por lo que no confirma que los pods creados en un clúster miembro por una implementación estén listos.

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

Uso de tolerancias

Puede aplicar taints a los clústeres miembro, igual que a los nodos de un clúster.

La distribución de recursos admite el uso de tolerancias en las que cada una consta de los campos siguientes:

• 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 sirve para que se puedan poner una o varias marcas de exclusión específicas aplicadas en un MemberCluster. Una vez que se toleren todas las marcas de exclusión, el administrador de flota puede distribuir los recursos en el clúster miembro.

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: test-ns
spec:
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: test-ns
      version: v1
  revisionHistoryLimit: 10
  strategy:
    type: RollingUpdate

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp-pickall-rolling
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickAll
    tolerations:
      - key: app-team-a
        operator: Exists
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
      unavailablePeriodSeconds: 60

Para obtener más información, consulte la documentación sobre tolerancias.

Uso de recursos de envolvente

El clúster del centro de Fleet Manager también es un clúster de Kubernetes. Primero, aplique cualquier recurso que desee distribuir al clúster hub. Este enfoque puede conducir a:

1. Efectos secundarios no deseados: ValidatingWebhookConfigurations, MutatingWebhookConfigurations o los controladores de admisión se activan en el clúster central, lo que podría interceptar y afectar las operaciones del clúster central.

2. Riesgos de seguridad: los recursos de RBAC (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) destinados a los clústeres miembros podrían conceder o restringir permisos en el clúster central.

3. Limitaciones de recursos: los ResourceQuotas, FlowSchema o LimitRanges definidos para los clústeres miembro se aplican en el clúster central.

Para evitar efectos secundarios innecesarios, Fleet Manager proporciona recursos de sobre personalizados (ClusterResourceEnvelope y ResourceEnvelope) para encapsular objetos y evitar estos posibles problemas.

El recurso contenedor se aplica al clúster central, pero los recursos que contiene se extraen y aplican cuando llegan a los clústeres miembro.

Para obtener más información, consulte la documentación sobre objetos de sobre.

Determinación del estado de colocación

La asignación de ubicación de recursos del administrador de flota incluye dos maneras de ver el estado en función del nivel de acceso y los requisitos del clúster central:

kubectl describe resourceplacement place-cmap-1

kubectl describe clusterresourceplacement 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

apiVersion: placement.kubernetes-fleet.io/v1beta1
kind: ClusterResourcePlacement
metadata:
  name: crp-with-status-reporting
spec:
  statusReportingScope: NamespaceAccessible
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
  policy:
    placementType: PickAll

kubectl describe clusterresourceplacementstatuses.v1beta1.placement.kubernetes-fleet.io crp-with-status-reporting -n my-app

Desencadenadores de cambio de colocación

El programador de Fleet Manager prioriza la estabilidad de las ubicaciones de recursos existentes. Esta prioridad limita el número de cambios que quitan y vuelven a programar un recurso.

Los escenarios siguientes pueden desencadenar cambios de selección de ubicación:

• Los cambios en la política de ubicación de recursos (ClusterResourcePlacement o ResourcePlacement) pueden desencadenar la eliminación y reprogramación de un recurso.
  • Las operaciones de escalado horizontal (al aumentar numberOfClusters sin ningún otro cambio) colocan las cargas de trabajo únicamente en clústeres nuevos y no afectan a las asignaciones existentes.
• Cambios en el clúster de miembros, entre los que se incluyen:
  • Un nuevo clúster miembro que pasa a ser apto y cumple la política de colocación, por ejemplo, una política PickAll.
  • Eliminación de un clúster miembro de la flota. En función de la directiva, el programador intenta colocar todos los recursos afectados en los clústeres restantes sin afectar a las ubicaciones existentes.

Actualizar los recursos seleccionados (por ejemplo, modificar un Deployment) o actualizar en resourceSelector una ubicación de recursos hace que Fleet Manager implemente gradualmente las ubicaciones existentes, pero no desencadena la reprogramación (es decir, cambiar los clústeres seleccionados) del recurso.

Trabajar con ResourcePlacement y ClusterResourcePlacement juntos

Aunque ClusterResourcePlacement supone que los espacios de nombres representan límites de aplicación, los patrones de uso del mundo real suelen ser más complejos. Las organizaciones suelen usar espacios de nombres como límites de equipo en lugar de límites de aplicación, lo que conduce a varios desafíos que ResourcePlacement abordan directamente:

Espacios de nombres de varias aplicaciones: en muchas organizaciones, un único espacio de nombres contiene varias aplicaciones independientes que pertenecen al mismo equipo. Estas aplicaciones pueden tener:

• Requisitos de ciclo de vida diferentes (una aplicación puede necesitar actualizaciones frecuentes mientras que otra permanece estable).
• Diferentes necesidades de selección de ubicación del clúster (desarrollo frente a aplicaciones de producción).
• Requisitos de escalado y recursos independientes.
• Separe los requisitos de cumplimiento o gobernanza.

Decisiones de programación individuales: muchas cargas de trabajo, especialmente los trabajos de IA/ML, requieren decisiones de programación individuales:

• Trabajos de INTELIGENCIA ARTIFICIAL: las cargas de trabajo de aprendizaje automático suelen constar de trabajos de corta duración, intensivos en recursos que se deben programar en función de la disponibilidad de recursos del clúster, la disponibilidad de GPU o la localidad de datos.
• Cargas de trabajo por lotes: diferentes trabajos por lotes dentro del mismo espacio de nombres pueden tener como destino distintos tipos de clúster en función de los requisitos de cálculo.

Control completo del equipo de la aplicación: ResourcePlacement proporciona a los equipos de aplicaciones control directo sobre su ubicación de recursos sin necesidad de intervención del equipo de plataforma:

• Operaciones de autoservicio: Teams puede administrar sus propias estrategias de distribución de recursos.
• Ciclos de implementación independientes: diferentes aplicaciones dentro de un espacio de nombres pueden tener programaciones de lanzamiento independientes.
• Capacidades de anulación granulares: Los equipos pueden personalizar las configuraciones de recursos por clúster sin afectar a otras aplicaciones en el espacio de nombres.

Este enfoque pormenorizados garantiza que pueda adaptarse a diversas estructuras organizativas y patrones de carga de trabajo, a la vez que ResourcePlacement mantiene la simplicidad y la eficacia del marco de programación de flotas.

Diferencias clave entre ResourcePlacement y ClusterResourcePlacement

En la tabla siguiente se resaltan las diferencias clave entre ResourcePlacement y ClusterResourcePlacement:

Tanto ResourcePlacement como ClusterResourcePlacement comparten las mismas capacidades básicas para todos los demás aspectos que no están enumerados en la tabla de diferencias.

Escenario de ejemplo con ResourcePlacement y ClusterResourcePlacement

ResourcePlacement funciona con ClusterResourcePlacement (CRP) para proporcionar una solución completa de administración de recursos de varios clústeres. Comprender esta relación es fundamental para la gestión eficaz de flotas.

Flujo de trabajo típico:

1. Administradores de la plataforma: Use ClusterResourcePlacement para desplegar espacios de nombres en toda la flota.
2. Equipos de aplicación: Use ResourcePlacement para administrar recursos específicos dentro de los espacios de nombres ya establecidos.

En los ejemplos siguientes se muestra cómo coordinar CRP y RP.

Administrador de la plataforma: cree el espacio de nombres mediante ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourcePlacement
metadata:
  name: app-namespace-crp
spec:
  resourceSelectors:
    - group: ""
      kind: Namespace
      name: my-app
      version: v1
      selectionScope: NamespaceOnly # only namespace itself is placed, no resources within the namespace
  policy:
    placementType: PickAll # If placement type is not PickAll, the application teams needs to know what are the clusters they can place their applications.

Equipo de aplicación: administre recursos específicos dentro del espacio de nombres mediante ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourcePlacement
metadata:
  name: app-configs-rp
  namespace: my-app
spec:
  resourceSelectors:
    - group: ""
      kind: ConfigMap
      version: v1
      labelSelector:
        matchLabels:
          app: my-application
  policy:
    placementType: PickFixed
    clusterNames:
    - cluster1
    - cluster2

Procedimientos recomendados para ResourcePlacement y ClusterResourcePlacement

Al usar ResourcePlacement con ClusterResourcePlacement, siga estos procedimientos recomendados:

• Establecer primero espacios de nombres: implemente siempre espacios de nombres a través de CRP antes de crear ResourcePlacement objetos.
• Supervisión de dependencias: use la función de supervisión de flotas para confirmar que los CRP para espacios de nombres sean correctos antes de implementar los RP dependientes.
• Coordine las directivas: alinee las directivas de ubicación de CRP y RP para evitar conflictos. Por ejemplo, si CRP coloca el espacio de nombres en los clústeres A, B y C, RP puede tener como destino cualquier subconjunto de esos clústeres.
• Límites del equipo: use CRP para recursos administrados por la plataforma (espacios de nombres, RBAC) y RP para recursos administrados por aplicaciones (configuraciones de aplicaciones, secretos).

Este enfoque coordinado garantiza que ResourcePlacement proporcione la flexibilidad que los equipos necesitan mientras mantienen la infraestructura básica administrada por los operadores de plataforma.

Selección de recursos, colocación, y despliegue

ResourcePlacement usa los mismos patrones de selección de ubicación que ClusterResourcePlacement:

• Directiva de selección de ubicación: PickAlllas directivas , PickFixedy PickN funcionan de forma idéntica para ambas API.
• Estrategia de implementación: controle cómo se propagan las actualizaciones entre clústeres con los mismos mecanismos de actualización graduales.
• Estado y observabilidad: supervise el progreso de la implementación mediante kubectl describe resourceplacement <name> -n <namespace>.
• Características avanzadas: Usar tolerancias, anulaciones de recursos, restricciones de propagación de topología y reglas de afinidad.

La diferencia clave es el ámbito de selección de recursos . Aunque ClusterResourcePlacement normalmente selecciona espacios de nombres completos y su contenido, ResourcePlacement proporciona un control específico sobre los recursos con ámbito de espacio de nombres individuales.

:::zone-end

Pasos siguientes

• Use la ubicación de recursos de Fleet Manager para implementar cargas de trabajo en varios clústeres.
• Uso de ResourcePlacement para desplegar recursos delimitados por espacio de nombres.
• Ubicación inteligente de recursos de Kubernetes entre clústeres en función de las propiedades de los clústeres de miembros.
• Control del desalojo y la interrupción en la asignación de recursos.
• Definir una estrategia de despliegue para una asignación de recursos
• Preguntas frecuentes sobre la ubicación de recursos de Fleet Manager.