Perguntas frequentes - Azure Kubernetes Fleet Manager

Aplica-se a: ✔️ Fleet Manager ✔️ Fleet Manager com cluster de hub

Este artigo aborda as perguntas frequentes sobre o Azure Kubernetes Fleet Manager.

Perguntas frequentes sobre o serviço Fleet Manager

O Gestor de Frota é um recurso regional ou global?

O Gestor de Frota é um recurso regional. O suporte para failover de região para casos de uso de recuperação de desastres está no roteiro.

Quantos clusters posso aderir ao Fleet Manager?

O Fleet Manager (com ou sem cluster hub) suporta a ligação a até 1.000 clusters Kubernetes. Os clusters membros podem ser uma mistura de Kubernetes com AKS e Arc.

Se quiser que o Fleet Manager suporte mais de 1.000 clusters, adicione feedback.

A que clusters do Kubernetes posso aderir como membro?

O Fleet Manager permite que utilizadores autorizados adicionem qualquer cluster Kubernetes com AKS, AKS Automatic ou Arc em qualquer subscrição e região do Azure, desde que a subscrição do Azure esteja associada ao mesmo tenant do Microsoft Entra ID que o Fleet Manager.

O Fleet Manager suporta identidades geridas?

Sim, o Fleet Manager suporta identidades geridas atribuídas pelo sistema e pelo utilizador. Para obter mais informações, consulte a documentação sobre como usar identidades gerenciadas com o Fleet Manager.

O que acontece quando altero a identidade do cluster de um cluster associado?

A alteração da identidade de um cluster de membros interrompe a comunicação entre o Fleet Manager e esse cluster de membros. Embora o agente membro use a nova identidade para se comunicar com o Gerente de Frota, o Gerente de Frota ainda precisa ser informado sobre a nova identidade. Execute este comando para resolver:

az fleet member create \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${MEMBER_NAME} \
    --member-cluster-id ${MEMBER_CLUSTER_ID}

Relação com o Kubernetes habilitado pelo Azure Arc

O Fleet Manager suporta quer clusters AKS alojados no Azure quer clusters do Kubernetes ativados pelo Azure Arc enquanto clusters membros.

Relação com clusters do Serviço Kubernetes do Azure

O Serviço Kubernetes do Azure (AKS) simplifica a implantação de um cluster Kubernetes gerenciado no Azure descarregando a sobrecarga operacional para o Azure. Como um serviço Kubernetes hospedado, o Azure lida com tarefas críticas, como monitoramento e manutenção de integridade. Como o plano de controle do Kubernetes é gerenciado pelo Azure, você mantém apenas os nós do agente. Você executa suas cargas de trabalho reais nos clusters AKS.

O Azure Kubernetes Fleet Manager ajuda você a abordar cenários em escala e multicluster para clusters do Serviço Kubernetes do Azure. O Azure Kubernetes Fleet Manager fornece uma representação de grupo para seus clusters AKS e ajuda os usuários a orquestrar atualizações de cluster, propagação de recursos do Kubernetes e balanceamento de carga de vários clusters. As cargas de trabalho do usuário não podem ser executadas no cluster de hub do Fleet Manager.

Posso provisionar novos clusters AKS do Fleet Manager?

A criação e gestão do ciclo de vida de novos clusters AKS está no nosso roteiro. Forneça comentários se o suporte para a criação de clusters for um cenário importante para você.

Preciso gerenciar atualizações para o cluster de hub do Fleet Manager?

Não. O cluster de hub do Fleet Manager é um recurso gerenciado pela Microsoft. A Microsoft atualiza automaticamente o hub cluster para a versão mais recente do Kubernetes ou da imagem de nó à medida que se tornam disponíveis.

Se você tentar atualizar ou modificar o cluster de hub (que é um cluster AKS de nó único chamado hub), um conjunto de regras de negação impedirá que suas alterações sejam aplicadas.

Porque é que o meu cluster de hub do Fleet Manager passou de Falha para Em execução?

O cluster hub do Fleet Manager é um cluster AKS gerido pela Microsoft criado na sua subscrição. Não é necessário realizar qualquer ação no cluster hub.

Se houver algum problema no provisionamento ou no funcionamento do cluster de hub, este pode passar para o estado Failed.

O Fleet Manager faz automaticamente a reconciliação do cluster central como parte das operações periódicas padrão do serviço, o que pode colocar o cluster central num estado Running.

Quando existe um cluster Failed de hubs, não gera um custo, mas quando se move para Running um custo é gerado.

Atualizações multi-cluster - perguntas frequentes automatizadas ou manuais

Que clusters suportam as atualizações multi-cluster?

Que canais de atualização AKS são suportados pelo Fleet Manager?

O Fleet Manager suporta os seguintes canais de atualização do AKS:

• Rápido: Atualizações para a versão mais recente do Kubernetes suportada pelo AKS (N).
• Estável: Atualizações para o canal estável do Kubernetes (N-1), onde 'N' é a versão mais recente do Kubernetes suportada pelo AKS.
• NodeImage: Imagem de nó VHD corrigida (bug e segurança) com um calendário de lançamento semanal.
• TargetKubernetesVersion (Patch Kubernetes): Atualiza clusters para a versão mais recente do patch da versão alvo especificada quando o patch está disponível. Suporta versões secundárias do Kubernetes que estão disponíveis apenas via AKS Long-Term Support (LTS).
• SecurityPatch (imagens de nós Linux): Atualizações do sistema operativo das imagens dos nós que fornecem correções de segurança geridas pelo AKS aplicadas ao VHD existente em execução no nó.

Canais AKS atualmente não suportados:

• Não gerido: Atualizações do SO das imagens dos nós aplicadas diretamente através do mecanismo de aplicação de patches incorporado no SO (apenas para nós Linux). Atualmente, não há planos para o Fleet Manager apoiar esta opção.

A versão menor do Kubernetes no meu perfil de atualização automática do sistema não é mais suportada pela comunidade. Que posso eu fazer?

É possível:

• Permita o Suporte de Longo Prazo (LTS) no perfil de atualização automática e ative-o para quaisquer clusters na sua frota que deseje manter no minor específico. Certifique-se de que apenas clusters LTS estejam incluídos na estratégia de atualização usada.
• Atualize o perfil de atualização automática para uma nova versão secundária do Kubernetes de destino. Os clusters são atualizados para o patch mais recente no Kubernetes minor especificado quando lançado.

Para obter informações sobre como habilitar o LTS em perfis de atualização automática, consulte Atualizações de versão do Kubernetes de destino. Para obter informações sobre como habilitar o LTS em clusters gerenciados, consulte Suporte de longo prazo.

O que acontece se eu deixar as atualizações automáticas do cluster AKS ativadas?

Se deixares as atualizações automáticas do cluster do AKS ativadas, a atualização automática do Fleet Manager ou do AKS faz a atualização, dependendo de qual delas é executada primeiro.

O Fleet Manager não altera a configuração das definições de atualização automática do cluster do AKS.

Se quiseres que o Fleet Manager gere upgrades automáticos, desativa a atualização automática em cada cluster AKS dos membros.

Suporte para janelas de manutenção de clusters do AKS

Uma janela de manutenção define quando um cluster pode ser atualizado em segurança.

O Gestor de Frotas respeita as definições da janela de manutenção por cluster para cada cluster membro.

Quando uma janela de manutenção abre, as atualizações não começam imediatamente. As razões incluem:

• Limites de concorrência: mesmo que uma janela de manutenção se abra, um cluster pode não ser atualizado devido às definições de concorrência da estratégia.
• Consulta regular: o Gestor da Frota consulta janelas de manutenção abertas a cada 60 minutos, pelo que o tempo máximo de espera é de 60 minutos desde a abertura da janela.

Qual é o escopo das atualizações consistentes de imagem de nó?

A consistência dos nós só é garantida para todos os clusters contidos numa única execução de atualização onde escolhe a consistent image opção.

Não há garantia de consistência para as versões da imagem do nó em ciclos de atualização distintos.

Como posso descobrir quais imagens de nó foram usadas em uma execução de atualização?

A execução de atualização lista as imagens dos nós selecionadas usadas para a execução. Pode aceder a esta informação mesmo que a atualização ainda não tenha começado.

Podem ser selecionadas mais do que uma imagem de nó porque diferentes pools de nós operam em todos os clusters selecionados para atualização.

Para encontrar as imagens selecionadas, use este comando CLI do Azure:

az fleet updaterun show \
    --resource-group ${GROUP} \
    --fleet-name ${FLEET} \
    --name ${UPDATE_RUN_NAME} \
    --query "status.nodeImageSelection.selectedNodeImageVersions"

Pode também utilizar a opção View JSON na página Visão Geral da Execução de Atualização no portal Azure para visualizar os dados brutos de uma execução de atualização.

O meu processo de atualização está em estado pendente há bastante tempo. O que devo fazer?

As execuções de atualização do Fleet Manager podem estar em um estado pendente por vários motivos. Pode ver o estado de uma atualização executada através do portal do Azure ou seguindo a documentação de monitorização.

As duas razões mais comuns para estados pendentes há muito tempo são:

• Janelas de manutenção do cluster membro: Se a janela de manutenção de um cluster membro não estiver aberta, a execução da atualização entra num estado pausado. Esta pausa bloqueia a conclusão do grupo ou etapa de atualização até à abertura da próxima janela de manutenção. Para prosseguir com a execução da atualização, ignore manualmente o cluster. Se você ignorar o cluster, ele estará fora de sincronia com o restante dos clusters membros na execução da atualização.

• Versão do Kubernetes ou da imagem do nó não disponível na região do Azure: Se a nova versão do Kubernetes ou da imagem do nó não estiver publicada na região do Azure na qual existe um cluster membro, a execução da atualização fica em estado pendente. Você pode verificar o rastreador de lançamento do AKS para ver o status regional da versão. Embora possas ignorar o cluster membro, se houver outros clusters na mesma região do Azure, também não podem ser atualizados.

Minha execução de atualização automática começou e, então, entrou imediatamente num estado pendente. Porquê?

Ver pergunta anterior.

Tentei gerar uma execução de atualização a partir do meu perfil de atualização automática, mas não consigo ver a execução da atualização.

Quando gera manualmente uma execução de atualização a partir de um perfil de atualização automática, a execução de atualização resultante pode já existir.

Este cenário pode ocorrer se o perfil de atualização automática gerou automaticamente a execução da atualização, ou se a execução da atualização foi anteriormente gerada manualmente.

O nome da execução de atualização gerada baseia-se na especificação de atualização do perfil de atualização automática, que só muda quando propriedades como a imagem do nó ou a versão do Kubernetes são atualizadas.

Este problema é mais comum ver no portal do Azure, onde a execução de atualização existente não é a mais recente. Se tiveres este problema e não conseguires encontrar a execução de atualização, usa a CLI do Azure para gerar a execução e visualizar o nome da execução de atualização. A Microsoft prevê corrigir este problema no portal do Azure futuramente.

Se gerar uma execução de atualização e ela existir, a execução de atualização existente não é modificada.

A edição da minha estratégia de atualização não alterou as execuções de atualização existentes que a utilizaram. Porque não?

Quando crias uma corrida de atualização, a estratégia é copiada para a execução da atualização para que as alterações à estratégia não afetem as execuções de atualização.

Como é que evito que uma única falha do cluster pare toda a minha execução de atualizações?

Utilize a definição maxAllowedFailures nas fases e nos grupos da sua estratégia de atualização (disponível a partir da versão da API 2026-06-02-preview). Esta configuração permite-lhe especificar quantas falhas de cluster de membros são toleradas antes de o grupo ou estágio ser marcado como falhado. Os valores podem ser um inteiro fixo (por exemplo, "3") ou uma percentagem (por exemplo, "25%"). Quando não definido ou "0", uma única falha interrompe toda a execução.

Para mais informações, veja Falhas Máximas permitidas (pré-visualização).

Porque é que a minha atualização corre ou mostra em grupo como Concluída mesmo que os membros tenham falhado?

Quando defines maxAllowedFailures, o Fleet Manager avalia apenas o número de atualizações falhadas dos membros. Não impõe uma taxa mínima de sucesso. Uma execução, etapa ou grupo de atualização pode, portanto, terminar em Completed mesmo que alguns ou todos os membros tenham falhado, desde que o limiar configurado não seja ultrapassado quando o Fleet Manager toma as suas decisões de agendamento.

Este resultado é esperado e intencional, não um bug. Inspecione sempre FailureCount, os estados ao nível de membro e as razões da falha antes de considerar a implementação saudável. Para a maioria das estratégias de atualização, os limiares baseados em percentagens são mais fáceis de raciocinar do que os valores absolutos.

Que regras e limitações devo conhecer ao usar maxAllowedFailures?

Tenha em mente as seguintes regras:

• A funcionalidade está disponível a partir da versão API 2026-06-02-preview.
• Quando não define maxAllowedFailures ou o define como "0", o Fleet Manager utiliza o comportamento de falha rápida e interrompe após a primeira falha na atualização de um membro.
• O limiar é avaliado apenas com base na contagem de falhas. Não impõe uma taxa mínima de sucesso.
• Uma execução, etapa ou grupo pode aparecer Completed mesmo quando ocorrem falhas, desde que o limiar configurado não seja ultrapassado.
• FailureCount pode ser maior do que maxAllowedFailures quando as atualizações são executadas em paralelo, porque as atualizações de vários membros podem falhar antes do Gestor de Frotas deixar de agendar mais trabalho.
• Os limiares ao nível do estágio e ao nível do grupo são avaliados independentemente, e as falhas ao nível do estágio agregam-se em todos os grupos do estágio.
• Para a maioria dos lançamentos, os limiares baseados em percentagens são mais fáceis de ponderar e escalar melhor do que números fixos, especialmente em pequenos grupos.

Posso pré-aprovar uma aprovação?

Não. Só pode aprovar uma atualização depois de verificar se os clusters de membros estão prontos para a atualização ou que a atualização foi concluída com sucesso. Se quiser pré-aprovação, considere não incluir uma etapa de aprovação na sua estratégia.

As aprovações expiram?

Não, as aprovações aguardam até serem aprovadas. Não é possível configurar uma janela de tempo para aprovações.

Posso ignorar uma aprovação?

Se você quiser ignorar as atualizações do cluster de membros junto com a aprovação de regulação, ignore o grupo ou estágio abrangente. Se você quiser continuar com as atualizações, você deve conceder a aprovação.

Como faço para excluir uma aprovação?

Como na pergunta anterior, se você quiser continuar com uma atualização, você deve conceder a aprovação. Se estiveres a tentar remover o recurso subjacente do gate, tens de eliminar a execução de atualização associada, o que elimina todas as portas ligadas à execução de atualização.

Posso configurar uma aprovação após a etapa em conjunto com uma espera após a etapa?

Yes. A espera da fase posterior tem início ao mesmo tempo que a aprovação. Ambos devem ser concluídos antes que a execução da atualização continue.

Posso adicionar aprovações às estratégias de atualização existentes?

Yes. Você pode editar a estratégia existente para incluir aprovações. No entanto, as execuções de atualização existentes que criou com a estratégia não são atualizadas.

Como é que os portais de arranque programado interagem com as janelas de manutenção do cluster AKS?

Os portões de início programados e as janelas de manutenção planeada do cluster AKS são controlos independentes. Ambas as condições devem ser cumpridas antes de um cluster começar a ser atualizado. Por exemplo, se um portal de início programado termina às 2:00 da manhã mas a janela de manutenção de um cluster só abre às 6:00, o cluster espera até às 6:00 para iniciar a atualização.

Como posso controlar a ordem das atualizações do cluster numa execução de atualização?

Os rótulos dos membros e os grupos de atualização são duas formas diferentes de selecionar quais os clusters incluídos em cada etapa e grupo da sua estratégia de atualização. Cada cluster de membros pode ser atribuído a um grupo de atualização, mas pode ter múltiplos rótulos. As etiquetas de membros (usando memberSelector) oferecem mais flexibilidade e suportam cenários de seleção complexos, por isso são a forma recomendada de selecionar membros da frota para estratégias de atualização. Para mais informações, consulte Clusters de Grupo usando rótulos de membros.

Preciso de especificar grupos se definir um seletor de membros ao nível da fase?

Não. Quando se coloca memberSelector numa fase sem definir nenhum grupo, todos os clusters correspondentes são tratados como um único grupo. Os maxConcurrency níveis controlam quantos clusters são atualizados simultaneamente. Só precisa de definir grupos dentro de uma fase se quiser dividir os membros correspondentes em subconjuntos paralelos com diferentes configurações de concorrência.

O que acontece para atualizar grupos se eu definir um seletor de membros ao nível do grupo?

Se definires a memberSelector ao nível do grupo, o campo name do grupo é usado apenas como identificador de visualização para relatórios de estado e registo. O memberSelector tem precedência sobre o nome do grupo de atualização ao selecionar clusters para o grupo.

Perguntas frequentes sobre posicionamento de recursos de cluster

Posso selecionar recursos dentro de um namespace para propagação?

Yes. O Gestor de Frotas suporta tanto o posicionamento de recursos com âmbito de cluster como com âmbito de namespace.

• ClusterResourcePlacement: Propaga recursos com âmbito de cluster e namespaces inteiros (incluindo todo o seu conteúdo) para clusters membros. Para mais informações, consulte Utilizar o ClusterResourcePlacement para implementar recursos à escala do cluster.
• ResourcePlacement: Fornece controlo detalhado para selecionar e propagar recursos específicos com âmbito de namespace (como ConfigMaps, Secrets, Deployments) dentro de um namespace. Para mais informações, veja Using ResourcePlacement para implementar recursos com âmbito de namespace.

Mapa

O roadmap do Azure Kubernetes Fleet Manager está disponível no GitHub. A equipa aceita pedidos de funcionalidades, perguntas e relatos de bugs.

Próximos passos

• Crie uma frota e junte-se a clusters de membros.
• Guias de solução de problemas para o Fleet Manager.