Compartilhar via

Usando ResourcePlacement para implantar recursos com escopo de namespace (versão prévia)

Este artigo descreve a ResourcePlacement API, que permite o controle refinado sobre recursos do Kubernetes com escopo de namespace em clusters membros usando o Gerenciador de Frotas de Kubernetes do Azure.

Importante

Os recursos de versão prévia do Gerenciador de Frotas do Kubernetes do Azure estão disponíveis por autoatendimento e opt-in. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. A versão prévia do Gerenciador de Frota de Kubernetes do Azure é parcialmente coberta pelo suporte ao cliente em regime de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção.

Visão geral

ResourcePlacement é uma API com escopo de namespace que permite a seleção dinâmica e a propagação de vários clusters de recursos com escopo de namespace. Ele fornece controle refinado sobre como recursos específicos em um namespace são distribuídos entre clusters membros em uma frota.

Importante

ResourcePlacement usa a versão da placement.kubernetes-fleet.io/v1beta1 API e está atualmente em versão prévia. Alguns recursos demonstrados neste artigo, como selectionScope no ClusterResourcePlacement, também fazem parte da API v1beta1 e não estão disponíveis na API v1.

Principais características:

  • Escopo do namespace: tanto o objeto ResourcePlacement quanto os recursos que ele gerencia existem no mesmo namespace.
  • Seletivo: pode direcionar recursos específicos por tipo, nome ou rótulos em vez de namespaces inteiros.
  • Declarativo: usa os mesmos padrões de posicionamento que ClusterResourcePlacement para um comportamento consistente.

Um ResourcePlacement consiste em três componentes principais:

  • Seletores de Recursos: defina quais recursos com escopo de namespace incluir.
  • Política de Posicionamento: Determinar clusters de destino usando estratégias PickAll, PickFixed ou PickN.
  • Estratégia de distribuição: controlar como as alterações se propagam entre clusters selecionados.

Quando usar ResourcePlacement

ResourcePlacement é ideal para cenários que exigem controle granular sobre recursos com escopo de namespace:

  • Distribuição seletiva de recursos: implante ConfigMaps, Segredos ou Serviços específicos sem afetar todo o namespace.
  • Ambientes multilocatários: permitir que equipes diferentes gerenciem seus recursos de forma independente em namespaces compartilhados.
  • Gerenciamento de configuração: distribua configurações específicas do ambiente em diferentes ambientes de cluster.
  • Conformidade e governança: aplique políticas diferentes a diferentes tipos de recursos no mesmo namespace.
  • Distribuições progressivas: implante com segurança atualizações de recursos em clusters com estratégias de tempo de inatividade zero.

Em ambientes de vários clusters, as cargas de trabalho geralmente consistem em recursos com escopo de cluster e com escopo de namespace que precisam ser distribuídos entre clusters diferentes. Embora ClusterResourcePlacement (CRP) gerencie recursos com escopo de cluster de forma eficaz, incluindo namespaces inteiros e seu conteúdo, há cenários em que você precisa de um controle mais detalhado sobre os recursos com escopo de namespace dentro dos namespaces existentes.

ResourcePlacement (RP) foi projetado para resolver essa lacuna fornecendo:

  • Gerenciamento de recursos com escopo de namespace: direcionar recursos específicos em um namespace sem afetar todo o namespace.
  • Flexibilidade operacional: permita que as equipes gerenciem recursos diferentes no mesmo namespace de forma independente.
  • Funcionalidade complementar: trabalhe junto com o CRP para fornecer uma solução completa de gerenciamento de recursos de vários clusters.

Observação

ResourcePlacement pode ser usado em conjunto com ClusterResourcePlacement no modo somente namespace. Por exemplo, você pode usar o CRP para implantar o namespace, ao mesmo tempo em que usa RP para gerenciamento refinado de recursos específicos, como ConfigMaps ou Segredos específicos do ambiente dentro desse namespace.

Padrões de uso do namespace do mundo real

Embora o CRP assuma que os namespaces representam os limites do aplicativo, os padrões de uso do mundo real geralmente são mais complexos. As organizações frequentemente usam namespaces como limites de equipe em vez de limites de aplicativo, levando a vários desafios que ResourcePlacement abordam diretamente:

Namespaces de vários aplicativos: em muitas organizações, um único namespace contém vários aplicativos independentes pertencentes à mesma equipe. Esses aplicativos podem ter:

  • Requisitos de ciclo de vida diferentes (um aplicativo pode precisar de atualizações frequentes, enquanto outro permanece estável).
  • Diferentes necessidades de posicionamento de cluster (desenvolvimento versus aplicativos de produção).
  • Requisitos independentes de dimensionamento e recursos.
  • Requisitos de conformidade ou governança separados.

Decisões de agendamento individuais: muitas cargas de trabalho, particularmente trabalhos de IA/ML, exigem decisões de agendamento individuais:

  • Trabalhos de IA: as cargas de trabalho de machine learning geralmente consistem em trabalhos de curta duração e com uso intensivo de recursos que precisam ser agendados com base na disponibilidade de recursos de cluster, disponibilidade de GPU ou localidade de dados.
  • Cargas de trabalho em lote: trabalhos em lotes diferentes no mesmo namespace podem ter como destino diferentes tipos de cluster com base nos requisitos computacionais.

Controle completo da equipe de aplicativos: ResourcePlacement fornece às equipes de aplicativos controle direto sobre o posicionamento de recursos sem a necessidade de intervenção da equipe de plataforma:

  • Operações de autoatendimento: as equipes podem gerenciar suas próprias estratégias de distribuição de recursos.
  • Ciclos de implantação independentes: aplicativos diferentes em um namespace podem ter agendas de distribuição independentes.
  • Funcionalidades de substituição granular: o Teams pode personalizar as configurações de recursos por cluster sem afetar outros aplicativos no namespace.

Essa abordagem granular garante que ResourcePlacement possa se adaptar a estruturas organizacionais diversas e padrões de carga de trabalho, mantendo a simplicidade e o poder da estrutura de agendamento da Frota.

Principais diferenças entre ResourcePlacement e ClusterResourcePlacement

A tabela a seguir realça as principais diferenças entre ResourcePlacement e ClusterResourcePlacement:

Aspecto ResourcePlacement (RP) ClusterResourcePlacement (CRP)
Âmbito Somente aplicável a recursos com escopo de namespace Recursos com escopo de cluster (especialmente namespaces e seus conteúdos)
Recurso Objeto de API com escopo de namespace Objeto de API com escopo de cluster
Limite de seleção Limitado a recursos no mesmo namespace que o RP Pode selecionar qualquer recurso com escopo de cluster
Casos de uso típicos Trabalhos de IA/ML, cargas de trabalho individuais, ConfigMaps/Secrets específicas que precisam de decisões de posicionamento independentes Pacotes de aplicativos, namespaces inteiros, políticas em todo o cluster
Propriedade da equipe Pode ser gerenciado por proprietários/desenvolvedores de namespace Normalmente gerenciados por operadores de plataforma

Ambos ResourcePlacement e ClusterResourcePlacement compartilhem os mesmos recursos principais para todos os outros aspectos não listados na tabela de diferenças.

Trabalhando com ClusterResourcePlacement

ResourcePlacement foi projetado para trabalhar em coordenação com o ClusterResourcePlacement (CRP) para fornecer uma solução completa de gerenciamento de recursos de vários clusters. Entender essa relação é crucial para o gerenciamento efetivo de frotas.

Requisitos Essenciais do Namespace

Importante

ResourcePlacement só pode colocar recursos com escopo de namespace em clusters que já têm o namespace de destino. É recomendável usar ClusterResourcePlacement para o estabelecimento do namespace.

Fluxo de trabalho típico:

  1. Administrador de plataforma: usa ClusterResourcePlacement para implantar namespaces em toda a frota.
  2. Equipes de Aplicativos: use ResourcePlacement para gerenciar recursos específicos dentro desses namespaces estabelecidos.

Os exemplos a seguir mostram como coordenar CRP e RP:

Observação

Os exemplos a seguir usam a versão da placement.kubernetes-fleet.io/v1beta1 API. O selectionScope: NamespaceOnly campo é um recurso de visualização disponível na v1beta1 e não está disponível na API v1.

Administrador da plataforma: primeiro, crie o namespace usando ClusterResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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.

Equipe de Aplicativos: em seguida, gerencie recursos específicos no namespace usando ResourcePlacement:

apiVersion: placement.kubernetes-fleet.io/v1beta1
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

Práticas recomendadas

Ao usar ResourcePlacement com ClusterResourcePlacement, siga estas práticas recomendadas:

  • Estabeleça namespaces primeiro: sempre verifique se os namespaces são implantados via CRP antes de criar ResourcePlacement objetos.
  • Monitorar dependências: use o monitoramento da Frota para garantir que os CRPs no nível do namespace estejam íntegros antes de implantar RPs dependentes.
  • Políticas coordenadas: alinhe as políticas de posicionamento de CRP e RP para evitar conflitos (por exemplo, se o CRP posicionar o namespace nos clusters A, B, C, o RP pode direcionar a qualquer subconjunto desses clusters).
  • Limites de equipe: use CRP para recursos gerenciados por plataforma (namespaces, RBAC) e RP para recursos gerenciados pelo aplicativo (configurações de aplicativo, segredos).

Essa abordagem coordenada garante que ResourcePlacement forneça a flexibilidade de que as equipes precisam, ao mesmo tempo em que mantém a infraestrutura fundamental gerenciada pelos operadores de plataforma.

Seleção, posicionamento e distribuição de recursos

ResourcePlacement usa os mesmos padrões de posicionamento que ClusterResourcePlacement:

  • Tipos de posicionamento: PickAll, PickFixed, e PickN as estratégias funcionam de forma idêntica para ambas as APIs.
  • Estratégia de distribuição: controlar como as atualizações se propagam entre clusters com os mesmos mecanismos de atualização sem interrupção.
  • Status e observabilidade: Monitorar o progresso da implantação usando kubectl describe resourceplacement <name> -n <namespace>.
  • Recursos avançados: Usar tolerâncias, substituições de recursos, restrições de propagação de topologia e regras de afinidade.

A principal diferença está no escopo de seleção de recursos . Embora ClusterResourcePlacement normalmente selecione namespaces inteiros e seu conteúdo, ResourcePlacement fornece controle refinado sobre recursos individuais com escopo de namespace.

Para obter detalhes completos sobre esses recursos, consulte a documentação ClusterResourcePlacement.

Próximas etapas

  • Last updated on