Usar Substituições de Recursos para personalizar recursos implantados pela alocação de recursos do Gerenciador de Frota do Kubernetes do Azure

Aplica-se a: ✔️ Gerenciador de Frota com cluster do hub

O posicionamento inteligente de recursos do Azure Kubernetes Fleet Manager pode implantar o mesmo recurso em vários clusters em toda a frota. Muitas vezes, você precisa modificar a configuração de recursos para impor regras em torno do comportamento em ambientes diferentes (desenvolvimento, teste, prod). Para essa finalidade, o Gerenciador de Frota fornece substituições de recursos, que oferecem uma funcionalidade conceitualmente semelhante à maneira como os modelos do Helm e os patches do Kustomize são usados.

Modificar uma configuração de recurso é útil em situações como:

  • Você deseja usar uma ClusterRole chamada secret-reader em todos os clusters, mas tem um conjunto menor de ações permitidas para a função nos clusters de produção.
  • Você deseja usar o mesmo Deployment em todos os clusters, mas usar uma imagem ou porta de contêiner diferente em seus clusters de produção.

Este artigo mostra como criar substituições para os recursos implantados pelo posicionamento de recursos do Gerenciador de Frota.

O Gerenciador de Frota do Kubernetes do Azure dá suporte a dois escopos para substituições:

  • Escopo do cluster: usar ClusterResourceOverride juntamente com ClusterResourcePlacement para os administradores de frota gerenciando as alterações no nível da infraestrutura.
  • Escopo do namespace: usar ResourceOverride junto com ResourcePlacement para as equipes de aplicativos que estejam gerenciando as distribuições em seus respectivos namespaces específicos.

Selecione o escopo mais aplicável a você nas opções de tipo de escopo na parte superior do artigo.

Substituições de recursos no escopo do cluster

Um ClusterResourceOverride tem as propriedades a seguir:

  • clusterResourceSelectors: especifica o conjunto de recursos de cluster selecionados para substituição.
  • policy: especifica o conjunto de regras a serem aplicadas aos recursos de cluster selecionados.

Observação

Policy as definições são as mesmas para recursos com escopo de cluster e namespace.

O exemplo ClusterRole a seguir nomeado secret-reader demonstra como ClusterResourceOverride funciona.

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

Selecionando recursos de cluster

Um ClusterResourceOverride pode incluir um ou mais clusterResourceSelector para escolher quais recursos substituir. Cada um clusterResourceSelector dá suporte aos campos a seguir.

  • group: o grupo de API do recurso.
  • version: a versão da API do recurso.
  • kind: o tipo do recurso.
  • name: o nome do recurso.

Observação

Se você selecionar um namespace em ClusterResourceSelector, a substituição se aplicará a todos os recursos no namespace.

Usando nosso exemplo ClusterRole, vamos ver como o selecionamos em um 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

Substituições de recursos no escopo do namespace

Um ResourceOverride tem as propriedades a seguir:

  • resourceSelectors: especifica o conjunto de recursos selecionados para substituição.
  • policy: especifica o conjunto de regras a serem aplicadas aos recursos selecionados.

Observação

Policy as definições são as mesmas para recursos com escopo de cluster e namespace.

Para demonstrar como ResourceOverride funciona, use o exemplo Deployment a seguir chamado 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

Selecionando recursos de namespace

Um ResourceOverride pode incluir um ou mais resourceSelector para escolher quais recursos substituir. Cada um resourceSelector dá suporte aos seguintes campos:

  • group: o grupo de API do recurso.
  • version: a versão da API do recurso.
  • kind: o tipo do recurso.
  • name: o nome do recurso.

Você determina o namespace do recurso a ser substituído especificando o conjunto de namespace nos metadata da ResourceOverride.

Usando o exemplo Deployment, você pode ver como selecioná-lo em um 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

  • Se você selecionar um namespace em resourceSelector (kind: Namespace), a substituição se aplicará a todos os recursos no namespace.
  • O ResourceOverride precisa estar no mesmo namespace que o recurso a ser sobrescrito.

Agora que você selecionou o recurso, vamos examinar como configurar a substituição usando uma policy.

Policy

Um policy consiste em um conjunto de overrideRules que especificam as alterações a serem aplicadas aos recursos selecionados. Cada um overrideRules dá suporte aos seguintes campos:

  • clusterSelector: especifica o conjunto de clusters ao qual a regra de substituição se aplica.
  • jsonPatchOverrides: especifica as alterações a serem aplicadas aos recursos selecionados.

Seletor de cluster

Use o clusterSelector campo overrideRules para especificar os clusters aos quais a regra se aplica. clusterSelector suporta o seguinte campo:

  • clusterSelectorTerms: uma lista de termos que especificam os critérios para selecionar clusters. Cada termo inclui um campo labelSelector que define um conjunto de rótulos para correspondência.

Importante

Somente labelSelector é suportado no campo clusterSelectorTerms.

Substituições de patch JSON

Use jsonPatchOverrides em overrideRules para especificar as alterações a serem aplicadas aos recursos selecionados. A JsonPatch propriedade dá suporte aos seguintes campos:

  • op: a operação a ser executada. As operações com suporte incluem:

    • add: adiciona um novo valor ao caminho especificado.
    • remove: remove o valor no caminho especificado.
    • replace: substitui o valor no caminho especificado.

  • path: o caminho para o campo a ser modificado. As diretrizes sobre como especificar caminhos incluem:

    • Deve começar com um caractere de barra (/).
    • Não pode estar vazio ou conter uma cadeia de caracteres vazia.
    • Não pode ser um TypeMeta campo (/kind ou /apiVersion).
    • Não pode ser um Metadata campo (/metadata/name ou /metadata/namespace), exceto os campos /metadata/labels e /metadata/annotations.
    • Não pode ser nenhum campo no status do recurso.

    Exemplos de caminhos válidos incluem:

    • /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: o valor a ser adicionado, removido ou substituído. Se op estiver remove, não é possível especificar value.

Os jsonPatchOverrides campos aplicam um patch JSON nos recursos selecionados seguindo RFC 6902.

Estendendo nosso exemplo, você configura um policy para remover o verbo list do ClusterRole chamado secret-reader nos clusters rotulados com 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

Estendendo nosso exemplo, você configura um policy para substituir a imagem do contêiner em Deployment pela imagem nginx:1.30.0 para clusters com o rótulo 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"

Definir várias substituições

Adicione vários campos jsonPatchOverrides a overrideRules para aplicar várias alterações aos recursos do cluster selecionados. Veja um exemplo:

Este exemplo remove os verbos list e watch no exemplo ClusterRole nomeado secret-reader em clusters com o rótulo 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

Este exemplo substitui tanto a imagem do contêiner quanto a porta no Deployment com 443 para clusters com o rótulo 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"

Variáveis reservadas no valor de substituição do patch JSON

O value da regra de substituição de patch JSON substitui variáveis reservadas no posicionamento. Variáveis reservadas com suporte no momento:

  • ${MEMBER-CLUSTER-NAME}: substituído pelo nome do memberCluster.

Por exemplo, para criar um nome de host do DNS do Azure que contenha o nome do cluster, o exemplo ResourceOverride adiciona um valor de fleet-clustername-eastus aos clusters na região do Azure eastus.

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"}

Várias regras de substituição

Adicione vários overrideRules a um policy campo para aplicar várias alterações aos recursos selecionados. Aqui está um exemplo para ResourceOverride.

Este exemplo substitui a imagem de contêiner no Deployment por:

  • A imagem nginx:1.20.0 para os clusters com o rótulo env: prod.
  • A imagem nginx:latest para os clusters com o rótulo 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"

Usar com o posicionamento de recursos do cluster

  1. Crie um ClusterResourcePlacement para especificar as regras de posicionamento de modo a distribuir as substituições de recursos do cluster na infraestrutura do cluster. O código a seguir é um exemplo. Certifique-se de selecionar o recurso apropriado.

    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

    Este exemplo distribui recursos em todos os clusters rotulados com env: prod. À medida que as alterações são implementadas, as configurações correspondentes ClusterResourceOverride são aplicadas aos clusters designados. A seleção de um recurso de função de cluster correspondente, secret-reader, dispara a aplicação das configurações nos clusters.

  2. Aplique o ClusterResourcePlacement usando o comando kubectl apply.

    kubectl apply -f cluster-resource-placement.yaml

  3. Verifique se o ClusterResourceOverride recurso foi aplicado aos recursos selecionados verificando o status do ClusterResourcePlacement recurso por meio do kubectl describe comando:

    kubectl describe clusterresourceplacement crp

    Sua saída deve ser semelhante ao exemplo a seguir:

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

    A condição ClusterResourcePlacementOverridden indica se a substituição de recursos foi aplicada com êxito aos recursos selecionados nos clusters. Cada cluster mantém sua própria Applicable Cluster Resource Overrides lista. Essa lista contém o instantâneo da substituição do recurso de cluster, se relevante. Mensagens de status individuais para cada cluster indicam se as regras de substituição foram aplicadas com êxito.

Usar com posicionamento de recursos

  1. Crie um recurso ClusterResourcePlacement para especificar as regras de posicionamento de modo a distribuir as substituições de recursos na infraestrutura do cluster. O código a seguir é um exemplo. Selecione os namespaces apropriados.

    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

    Distribui recursos dentro de test-namespace em todos os clusters rotulados com env:prod e env:test. À medida que as alterações são implementadas, as configurações correspondentes ResourceOverride são aplicadas aos recursos designados. A seleção de um recurso my-deploymentde implantação correspondente dispara a aplicação das configurações para os recursos designados.

  2. Aplique o ClusterResourcePlacement recurso usando o kubectl apply comando:

    kubectl apply -f cluster-resource-placement.yaml

  3. Verifique se o ResourceOverride recurso foi aplicado aos recursos selecionados verificando o status do ClusterResourcePlacement recurso por meio do kubectl describe comando:

    kubectl describe clusterresourceplacement crp-example

    Sua saída deve ser semelhante ao exemplo a seguir:

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

    A condição ClusterResourcePlacementOverridden indica se a substituição de recursos foi bem-sucedida nos recursos selecionados. Cada cluster mantém sua própria Applicable Resource Overrides lista. Esta lista contém o instantâneo de substituição de recursos, se relevante. Mensagens de status individuais para cada cluster indicam se as regras de substituição foram aplicadas com êxito.

Conteúdo relacionado

  • Last updated on