Visão geral do cluster de hub do Fleet Manager

Quando habilitado, o cluster de hub do Fleet Manager serve como ponto de gerenciamento central para a propagação de recursos do Kubernetes entre clusters membros usando o posicionamento de recursos.

O que são os clusters de hub do Fleet Manager?

No Azure Kubernetes Fleet Manager, os clusters hub desempenham um papel crucial na gestão de clusters de múltiplos membros, mas são opcionais.

O cluster hub facilita a colocação de recursos e os Espaços de Nomes Geridos pela Frota através de uma versão gerida do KubeFleet.

Nesta configuração, uma frota é composta pelos seguintes componentes:

• fleet-hub-agent: um controlador Kubernetes que cria e reconcilia todos os recursos personalizados (CRs) relacionados à frota no cluster de hub.
• fleet-member-agent: um controlador Kubernetes que cria e reconcilia todas as CRs relacionadas à frota nos clusters de membros. Este controlador extrai as CRs mais recentes do cluster de hub e reconcilia consistentemente os clusters membros para corresponder ao estado desejado.

Configuração do cluster de hub

Um cluster de hub do Fleet Manager é um cluster do Serviço Kubernetes (AKS) do Azure totalmente gerenciado que tem as seguintes propriedades:

• Nome e localização do cluster: o cluster de hub é sempre nomeado hub e é criado na mesma região do Azure que o Fleet Manager.
• Grupo de Recursos do Azure para cluster de hub: o recurso AKS do cluster de hub é criado em um grupo de recursos gerenciado com o formato FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}de nomenclatura.
• pt-PT: Grupo de Recursos do Azure para recursos de cluster de hub: como qualquer cluster AKS, o cluster de hub tem recursos do Azure, como um conjunto de escala de máquinas virtuais para o pool de nós do agente e rede virtual, que são criados num grupo de recursos gerido com o formato de nomenclatura MC_FL_{fleet_manager_resource_group}_{fleet_manager_name}_{azure_region}.
• Nó do cluster de hub: O cluster de hub tem um pool de nós com um único nó executando o Azure Linux. O nó não executa nenhum pod e não afeta o desempenho do cluster hub. Ao criar um cluster de hub na CLI do Azure, pode-se escolher o tipo de SKU de máquina virtual (VM) do nó usando o parâmetro --vm-size.
• Configuração de rede: os clusters de hub público têm um servidor de API público, com um endereço IP público associado. Quando configurado para acesso privado, o servidor de API só é acessível através de uma rede virtual do Azure.

Restrições de cluster de hub

O cluster de hub tem as seguintes restrições que garantem que ele funcione conforme necessário para propagação e gerenciamento de recursos:

• Invocação de comando desativada: O uso da invocação de comando por meio da CLI do Azure (az aks command invoke) está desabilitado para clusters de hub.
• Autenticação local desativada: O acesso via admin kubeconfig está desativado, garantindo que a autenticação seja tratada exclusivamente através do Microsoft Entra ID, aumentando a segurança ao centralizar o controle de acesso. Use az fleet get-credentials para obter o kubeconfig para o cluster principal.
• Negar atribuições: As alterações na configuração do Azure do cluster de hub e dos recursos associados são bloqueadas por meio das Atribuições de Negação do Azure. As seguintes atribuições de negação são usadas:
  • FLRG-DenyAssignments-{guid}: Aplicado ao grupo de recursos do cluster hub, impedindo que os utilizadores modifiquem o cluster hub.
  • kubernetes.azure.com/{guid} (opcional): Esta atribuição de negação impede que os usuários modifiquem os recursos AKS do cluster de hub (Conjuntos de Escala de Máquina Virtual, redes), conforme descrito no bloqueio do grupo de recursos do nó AKS.
• Recursos aplicados não instanciados: O cluster de hub não agenda recursos Kubernetes aplicados no nó do cluster de hub. Alguns recursos do Kubernetes devem ser aplicados usando um objeto envelope para evitar efeitos colaterais no cluster de hub. Para obter mais informações sobre objetos de envelope, consulte a documentação de Objetos de envelope.

Restrições de acesso a recursos protegidos

Os seguintes pedidos da API Kubernetes são negados:

• Todos os pedidos de falsificação de identidade.
• Todas as operações exceto get, list, e watch em namespaces com nomes que começam por fleet- ou kube-.
• get, list, e watch pedidos para pods, segredos, contas de serviço, roles e associações de roles em namespaces com nomes que começam por fleet- ou kube-.
• Requisições entre namespaces list e watch para pods, segredos, contas de serviço, roles e role bindings.
• Escreva pedidos para ClusterRole e ClusterRoleBinding.
• Leia e escreva pedidos para o nodes/proxy sub-recurso.
• Escreva pedidos para validar políticas de admissão, validar vinculações de políticas de admissão e validar configurações de webhooks com nomes que começam por fleet-builtin-.
• Pedidos de eliminação de coleções para validação de políticas de admissão, validação de associações de políticas de admissão e validação de configurações de webhooks.

Outras operações suportadas em namespaces geridos pelo cliente continuam disponíveis.

Identificar os recursos e a automação do Gestor de Frota afetados

Um recurso do Gestor de Frotas pode ser afetado se tiver um cluster hub ativado. Utilize o Azure Resource Graph Explorer para encontrar estes recursos:

Resources
| where type =~ "microsoft.containerservice/fleets"
| where isnotnull(properties.hubProfile)
| project id, name, subscriptionId, resourceGroup, location

Ter um cluster de hub não significa necessariamente que tenhas de agir. Só és afetado se os teus utilizadores, scripts, controladores ou pipelines CI/CD enviarem um dos pedidos restritos para o cluster do hub.

Reveja a automação que acede ao cluster do hub para:

• Opções ou cabeçalhos de representação, incluindo --as e --as-group.
• Solicitações para nodes/proxy.
• Acesso a namespaces com nomes que começam por fleet- ou kube-.
• Pedidos a nível de cluster ou --all-namespaces pedidos de listagem e monitorização de recursos protegidos.
• Alterações aos ClusterRoles ou ClusterRoleBindings.
• Alterações aos recursos de validação com nomes que começam por fleet-builtin-.
• Eliminação da coleção de recursos de validação.

Atualizar a automação afetada

Antes de 31 de janeiro de 2027:

• Retirar recursos e automação pertencentes ao cliente de namespaces com nomes que começam por fleet- ou kube-.
• Restringir os pedidos de lista e observação para pods, segredos, contas de serviço, roles e role bindings a namespaces geridos pelo cliente.
• Para a colocação de recursos, coloque ClusterRole e ClusterRoleBinding dentro de ClusterResourceEnvelope. Para mais informações, consulte Usar objetos envelope para colocar recursos em segurança.
• Para acesso programático ao cluster do hub, use uma identidade Microsoft Entra dedicada, atribua-lhe a função RBAC de Gestor de Frotas menos privilegiada exigida e não use a representação de identidade.
• Pare de usar o nodes/proxy subrecurso.
• Não modifique recursos de validação com nomes que comecem por fleet-builtin-.
• Substituir a eliminação da coleção de recursos de validação por pedidos limitados a recursos geridos pelo cliente.
• Teste a automação atualizada antes da data de aplicação.

Se não atualizar a automação afetada antes de 31 de janeiro de 2027, os pedidos restritos dessa automação recebem respostas com autorização negada. Scripts, controllers, implementações ou fluxos de trabalho operacionais que dependem dessas solicitações podem falhar ou tentar novamente repetidamente. Se não usares nenhuma operação restrita, não é necessária qualquer ação.

Requisitos dos clientes

Para que o Fleet Manager possa criar e manter os clusters de hubs atualizados com os patches mais recentes, assegure-se de que:

• A política do Azure não bloqueia a criação de clusters. O cluster de hub é um cluster AKS gerenciado. Se não consegues criar clusters AKS, não podes criar um cluster de hub no Fleet Manager.

• A subscrição tem quota suficiente. Uma instância de VM extra do nó do cluster de hub é necessária durante o processo de atualização do cluster. Para obter mais informações sobre o aumento da quota, consulte a documentação sobre quota.

• O cluster de hub tem acesso à Internet. A conectividade de saída é necessária para instalar atualizações. Hubs privados em redes com regras de roteamento definido pelo usuário (UDR) ou firewall podem bloquear a conectividade de saída. Para obter mais informações sobre conectividade de saída, consulte a documentação sobre a rede de saída AKS.

• O servidor API pode aceder aos nós hub. Se as regras NSG num cluster hub privado com integração VNet de servidor API restringirem o tráfego entre sub-redes, permita tráfego de entrada da sub-rede do servidor API para a sub-rede do cluster na porta TCP 10250. Sem esta regra, as operações que utilizam a API kubelet, como recuperar logs ou executar exec, falham. Para ver todas as regras necessárias, consulte regras de segurança NSG para integração de VNet do servidor API.

• Não há necessidade de gerenciar atualizações para o cluster de hub do Fleet Manager. A Microsoft atualiza automaticamente o cluster de hub para a versão mais recente do Kubernetes ou a imagem do nó à medida que se tornam disponíveis no AKS. As versões de atualização podem ser acompanhadas no AKS Release Tracker.

Conteúdo relacionado

• Posicionamento inteligente de recursos do Kubernetes entre clusters com base nas propriedades dos clusters membros.
• Acesse a API Kubernetes do cluster de hub do Fleet Manager.
• Perguntas frequentes sobre o gestor de frotas.