Uso de invalidaciones de recursos para personalizar los recursos implementados por la colocación de recursos de Azure Kubernetes Fleet Manager

Se aplica a: ✔️ Fleet Manager con clúster central

La asignación inteligente de recursos de Azure Kubernetes Fleet Manager permite implementar el mismo recurso en varios clústeres de una flota. A menudo, debe modificar la configuración de recursos para aplicar reglas en torno al comportamiento en distintos entornos (desarrollo, prueba, prod). Para ello, Fleet Manager proporciona anulaciones de recursos, que ofrecen una capacidad conceptualmente similar al uso de las plantillas de Helm y los parches de Kustomize.

La modificación de una configuración de recursos es útil en situaciones como:

  • Quiere usar un ClusterRole llamado secret-reader en todos los clústeres, pero tener un conjunto más reducido de acciones permitidas para ese rol en sus clústeres de producción.
  • Quieres usar el mismo Deployment en todos los clústeres, pero una imagen de contenedor o un puerto distintos en los clústeres de producción.

En este artículo se muestra cómo crear invalidaciones para los recursos implementados por la colocación de recursos de Fleet Manager.

Azure Kubernetes Fleet Manager admite dos ámbitos para invalidaciones:

  • Limitado a clúster: use ClusterResourceOverride con ClusterResourcePlacement para administradores de flotas que se encarguen de los cambios a nivel de infraestructura.
  • Con ámbito de espacio de nombres: use ResourceOverride con ResourcePlacement para los equipos de gestión de aplicaciones que administran despliegues dentro de sus espacios de nombres específicos.

Seleccione el ámbito más aplicable en las opciones de tipo de ámbito de la parte superior del artículo.

Invalidaciones de recursos con ámbito de clúster

Un ClusterResourceOverride tiene las siguientes propiedades:

  • clusterResourceSelectors: Especifica el conjunto de recursos de clúster seleccionados para sobrescribir.
  • policy: especifica el conjunto de reglas que se aplicarán a los recursos de clúster seleccionados.

Nota:

Las definiciones de Policy son las mismas para los recursos con ámbito de clúster y espacio de nombres.

El siguiente ejemplo ClusterRole, denominado secret-reader, muestra cómo funciona ClusterResourceOverride.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Selección de recursos de clúster

Un ClusterResourceOverride puede incluir uno o varios clusterResourceSelector para elegir qué recursos se van a invalidar. Cada clusterResourceSelector admite los campos siguientes.

  • group: el grupo de API del recurso.
  • version: la versión de API del recurso.
  • kind: el tipo del recurso.
  • name: nombre del recurso.

Nota:

Si selecciona un espacio de nombres en ClusterResourceSelector, la invalidación se aplica a todos los recursos del espacio de nombres.

Con nuestro ejemplo ClusterRole, veamos cómo lo seleccionamos en ClusterResourceOverride.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourceOverride
metadata:
  name: example-cro
spec:
  clusterResourceSelectors:
    - group: rbac.authorization.k8s.io
      kind: ClusterRole
      version: v1
      name: secret-reader

Invalidaciones de recursos con ámbito de espacio de nombres

Un ResourceOverride tiene las siguientes propiedades:

  • resourceSelectors: especifica el conjunto de recursos seleccionados para invalidar.
  • policy: especifica el conjunto de reglas que se aplicarán a los recursos seleccionados.

Nota:

Las definiciones de Policy son las mismas para los recursos con ámbito de clúster y espacio de nombres.

Para demostrar cómo ResourceOverride funciona, use el ejemplo Deployment siguiente denominado nginx-sample.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-sample
  namespace: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

Seleccionar recursos del espacio de nombres

Un ResourceOverride puede incluir uno o varios resourceSelector para elegir qué recursos se van a invalidar. Cada resourceSelector admite los siguientes campos:

  • group: el grupo de API del recurso.
  • version: la versión de API del recurso.
  • kind: el tipo del recurso.
  • name: nombre del recurso.

Usted determina el espacio de nombres del recurso que se va a invalidar especificando el namespace establecido en los metadata de ResourceOverride.

Con el ejemplo Deployment, puede ver cómo seleccionarlo en un ResourceOverride.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourceOverride
metadata:
  name: example-resource-override
  namespace: nginx-demo
spec:
  resourceSelectors:
    -  group: apps
       kind: Deployment
       version: v1
       name: nginx-sample

Importante

  • Si selecciona un espacio de nombres en resourceSelector (kind: Namespace), la invalidación se aplica a todos los recursos del espacio de nombres.
  • Debe ResourceOverride estar en el mismo espacio de nombres que el recurso que se va a invalidar.

Ahora que ha seleccionado el recurso, veamos cómo configurar la anulación usando un policy.

Policy

Un policy consta de un conjunto de overrideRules que especifican los cambios que se aplicarán a los recursos seleccionados. Cada overrideRules admite los siguientes campos:

  • clusterSelector: especifica el conjunto de clústeres al que se aplica la regla de invalidación.
  • jsonPatchOverrides: especifica los cambios que se aplicarán a los recursos seleccionados.

Selector de clústeres

Use el clusterSelector campo de overrideRules para especificar los clústeres a los que se aplica la regla. clusterSelector admite el siguiente campo:

  • clusterSelectorTerms: lista de términos que especifican los criterios para seleccionar clústeres. Cada término incluye un labelSelector campo que define un conjunto de etiquetas para que coincidan.

Importante

Solo se admite labelSelector en el campo clusterSelectorTerms.

Invalidación de revisiones de JSON

Use jsonPatchOverrides en overrideRules para especificar los cambios que se aplicarán a los recursos seleccionados. La JsonPatch propiedad admite los siguientes campos:

  • op: la operación que se va a realizar. Las operaciones admitidas incluyen:

    • add: agrega un nuevo valor a la ruta de acceso especificada.
    • remove: Elimina el valor en la ruta especificada.
    • replace: Reemplaza el valor en la ruta de acceso especificada.
  • path: ruta de acceso al campo que se va a modificar. Las instrucciones sobre cómo especificar rutas de acceso incluyen:

    • Debe comenzar con un carácter de barra diagonal (/).
    • No puede estar vacío ni contener una cadena vacía.
    • No puede ser un TypeMeta campo (/kind o /apiVersion).
    • No puede ser un Metadata campo (/metadata/name o /metadata/namespace), excepto los campos /metadata/labels y /metadata/annotations.
    • No puede ser ningún campo en el estado del recurso.

    Entre los ejemplos de rutas de acceso válidas se incluyen:

    • /metadata/labels/new-label
    • /metadata/annotations/new-annotation
    • /spec/template/spec/containers/0/resources/limits/cpu
    • /spec/template/spec/containers/0/resources/requests/memory
  • value: valor que se va a agregar, quitar o reemplazar. Si op es remove, no se puede especificar value.

Los jsonPatchOverrides campos aplican una revisión JSON a los recursos seleccionados siguiendo RFC 6902.

Siguiendo con nuestro ejemplo, configura un policy para quitar el verbo list del ClusterRole llamado secret-reader en clústeres etiquetados con env:prod.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourceOverride
metadata:
  name: example-cro
spec:
  clusterResourceSelectors:
    - group: rbac.authorization.k8s.io
      kind: ClusterRole
      version: v1
      name: secret-reader
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: prod
        jsonPatchOverrides:
          - op: remove
            path: /rules/0/verbs/2

Siguiendo con nuestro ejemplo, configura un policy para reemplazar la imagen de contenedor en el Deployment por la imagen nginx:1.30.0 para clústeres con la etiqueta env: prod.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourceOverride
metadata:
  name: example-resource-override
  namespace: nginx-demo
spec:
  resourceSelectors:
    -  group: apps
       kind: Deployment
       version: v1
       name: test-nginx
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: prod
        jsonPatchOverrides:
          - op: replace
            path: /spec/template/spec/containers/0/image
            value: "nginx:1.30.0"

Definición de varias invalidaciones

Añada varios campos jsonPatchOverrides a overrideRules para aplicar varios cambios a los recursos de clúster seleccionados. Este es un ejemplo:

En este ejemplo se quitan los verbos list y watch en el ejemplo ClusterRole denominado secret-reader en clústeres con la etiqueta env: prod.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ClusterResourceOverride
metadata:
  name: cro-1
spec:
  clusterResourceSelectors:
    - group: rbac.authorization.k8s.io
      kind: ClusterRole
      version: v1
      name: secret-reader
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: prod
        jsonPatchOverrides:
          - op: remove
            path: /rules/0/verbs/2
          - op: remove
            path: /rules/0/verbs/1

En este ejemplo, se reemplaza la imagen de contenedor y el puerto de Deployment con 443 para los clústeres con la etiqueta env: prod.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourceOverride
metadata:
  name: example-resource-override
  namespace: nginx-demo
spec:
  resourceSelectors:
    -  group: apps
       kind: Deployment
       version: v1
       name: test-nginx
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: prod
        jsonPatchOverrides:
          - op: replace
            path: /spec/template/spec/containers/0/image
            value: "nginx:1.30.0"
          - op: replace
            path: /spec/template/spec/containers/0/ports/0/containerPort
            value: "443"

Las variables reservadas en el parche JSON anulan el valor

El value de la regla de sustitución del parche JSON sustituye las variables reservadas en el momento de la colocación. Variables reservadas admitidas actualmente:

  • ${MEMBER-CLUSTER-NAME}: reemplazado por el nombre de memberCluster.

Por ejemplo, para crear un nombre de host de Azure DNS que contiene el nombre del clúster, en el ejemplo ResourceOverride se agrega un valor de fleet-clustername-eastus en los clústeres de la eastus región de Azure.

apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourceOverride
metadata:
  name: ro-kuard-demo-eastus
  namespace: kuard-demo
spec:
  placement:
    name: crp-kuard-demo
  resourceSelectors:
    -  group: ""
        kind: Service
        version: v1
        name: kuard-svc
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  fleet.azure.com/location: eastus
        jsonPatchOverrides:
          - op: add
            path: /metadata/annotations
            value:
              {"service.beta.kubernetes.io/azure-dns-label-name":"fleet-${MEMBER-CLUSTER-NAME}-eastus"}

Varias reglas de invalidación

Agregue varios overrideRules a un policy campo para aplicar varios cambios a los recursos seleccionados. Este es un ejemplo de ResourceOverride.

En este ejemplo se reemplaza la imagen del contenedor en el Deployment con:

  • La imagen nginx:1.20.0 de los clústeres con la etiqueta env: prod.
  • La imagen nginx:latest de los clústeres con la etiqueta env: test.
apiVersion: placement.kubernetes-fleet.io/v1
kind: ResourceOverride
metadata:
  name: ro-1
  namespace: test
spec:
  resourceSelectors:
    -  group: apps
       kind: Deployment
       version: v1
       name: test-nginx
  policy:
    overrideRules:
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: prod
        jsonPatchOverrides:
          - op: replace
            path: /spec/template/spec/containers/0/image
            value: "nginx:1.20.0"
      - clusterSelector:
          clusterSelectorTerms:
            - labelSelector:
                matchLabels:
                  env: test
        jsonPatchOverrides:
          - op: replace
            path: /spec/template/spec/containers/0/image
            value: "nginx:latest"

Uso con colocación de recursos de clúster

  1. Cree una ClusterResourcePlacement para especificar las reglas de colocación para distribuir las invalidaciones del recurso de clúster en toda la infraestructura del clúster. A continuación puede ver un ejemplo del código. Asegúrese de seleccionar el recurso adecuado.

    apiVersion: placement.kubernetes-fleet.io/v1
    kind: ClusterResourcePlacement
    metadata:
      name: crp
    spec:
      resourceSelectors:
        - group: rbac.authorization.k8s.io
          kind: ClusterRole
          version: v1
          name: secret-reader
      policy:
        placementType: PickAll
        affinity:
          clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      env: prod
    

    En este ejemplo se distribuyen los recursos en todos los clústeres etiquetados con env: prod. A medida que se implementan los cambios, las configuraciones correspondientes ClusterResourceOverride se aplican a los clústeres designados. La selección de un recurso de rol de clúster coincidente, secret-reader, desencadena la aplicación de las configuraciones en los clústeres.

  2. Aplique el ClusterResourcePlacement comando usando kubectl apply:

    kubectl apply -f cluster-resource-placement.yaml
    
  3. Compruebe que ClusterResourceOverride se aplicó a los recursos seleccionados comprobando el estado del ClusterResourcePlacement recurso mediante el kubectl describe comando :

    kubectl describe clusterresourceplacement crp
    

    La salida debe ser similar al ejemplo siguiente:

    Status:
      Conditions:
        ...
        Last Transition Time:   2024-04-27T04:18:00Z
        Message:                The selected resources are successfully overridden in the 10 clusters
        Observed Generation:    1
        Reason:                 OverriddenSucceeded
        Status:                 True
        Type:                   ClusterResourcePlacementOverridden
        ...
      Observed Resource Index:  0
      Placement Statuses:
        Applicable Cluster Resource Overrides:
          example-cro-0
        Cluster Name:  member-50
        Conditions:
          ...
          Message:               Successfully applied the override rules on the resources
          Observed Generation:   1
          Reason:                OverriddenSucceeded
          Status:                True
          Type:                  Overridden
         ...
    

    La ClusterResourcePlacementOverridden condición indica si la invalidación del recurso se aplicó correctamente a los recursos seleccionados en los clústeres. Cada clúster mantiene su propia Applicable Cluster Resource Overrides lista. Esta lista contiene la captura de la invalidación del recurso de clúster, si procede. Los mensajes de estado individuales para cada clúster indican si las reglas de invalidación se aplicaron correctamente.

Uso junto con la colocación de recursos

  1. Cree un recurso de ClusterResourcePlacement para especificar las reglas de colocación para distribuir las invalidaciones del recurso en toda la infraestructura del clúster. A continuación puede ver un ejemplo del código. Asegúrese de seleccionar los espacios de nombres adecuados.

    apiVersion: placement.kubernetes-fleet.io/v1
    kind: ClusterResourcePlacement
    metadata:
      name: crp-example
    spec:
      resourceSelectors:
        - group: ""
          kind: Namespace
          name: test-namespace
          version: v1
      policy:
        placementType: PickAll
        affinity:
          clusterAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              clusterSelectorTerms:
                - labelSelector:
                    matchLabels:
                      env: prod
                - labelSelector:
                    matchLabels:
                      env: test
    

    En este ejemplo, los recursos se distribuyen a través de test-namespace en todos los clústeres etiquetados con env:prod y env:test. A medida que se implementan los cambios, las configuraciones correspondientes ResourceOverride se aplican a los recursos designados. La selección de un recurso de implementación coincidente, my-deployment, desencadena la aplicación de las configuraciones en los recursos designados.

  2. Aplique el ClusterResourcePlacement recurso mediante el kubectl apply comando :

    kubectl apply -f cluster-resource-placement.yaml
    
  3. Compruebe que ResourceOverride se aplicó a los recursos seleccionados comprobando el estado del ClusterResourcePlacement recurso mediante el kubectl describe comando :

    kubectl describe clusterresourceplacement crp-example
    

    La salida debe ser similar al ejemplo siguiente:

    Status:
      Conditions:
        ...
        Message:                The selected resources are successfully overridden in the 10 clusters
        Observed Generation:    1
        Reason:                 OverriddenSucceeded
        Status:                 True
        Type:                   ClusterResourcePlacementOverridden
        ...
      Observed Resource Index:  0
      Placement Statuses:
        Applicable Resource Overrides:
          Name:        ro-1-0
          Namespace:   test-namespace
        Cluster Name:  member-50
        Conditions:
          ...
          Last Transition Time:  2024-04-26T22:57:14Z
          Message:               Successfully applied the override rules on the resources
          Observed Generation:   1
          Reason:                OverriddenSucceeded
          Status:                True
          Type:                  Overridden
         ...
    

    La ClusterResourcePlacementOverridden condición indica si la invalidación del recurso se aplicó correctamente a los recursos seleccionados. Cada clúster mantiene su propia Applicable Resource Overrides lista. Esta lista contiene la instantánea de sobrescritura de recursos, si es relevante. Los mensajes de estado individuales para cada clúster indican si las reglas de invalidación se aplicaron correctamente.