Perguntas frequentes – Gerenciador de Frota de Kubernetes do Azure

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

Este artigo aborda as perguntas frequentes sobre o Gerenciador de Frota de Kubernetes do Azure.

Perguntas frequentes sobre o serviço do Fleet Manager

O Fleet Manager é um recurso regional ou global?

O Fleet Manager é um recurso regional. O suporte para failover de região para casos de uso de recuperação de desastre está no roteiro.

Quantos clusters posso conectar ao Fleet Manager?

O Fleet Manager (com ou sem um cluster de hub) dá suporte à junção de até 1.000 clusters do Kubernetes. Os clusters membros podem ser uma combinação de AKS e Kubernetes habilitados para Arc.

Se você quiser que o Fleet Manager dê suporte a mais de 1.000 clusters, adicione comentários.

Quais clusters do Kubernetes posso ingressar como membros?

O Gerenciador de Frota permite que usuários autorizados adicionem qualquer cluster do AKS, do AKS Automático ou do Kubernetes habilitado para Arc em qualquer assinatura e região do Azure, desde que a assinatura do Azure esteja associada com o mesmo locatário do Microsoft Entra ID que o Gerenciador de Frota.

O Gerenciador de frota dá suporte a identidades gerenciadas?

Sim, o Gerenciador de frota dá suporte a identidades gerenciadas atribuídas pelo sistema e atribuídas pelo usuário. Para obter mais informações, consulte a documentação sobre como usar identidades gerenciadas com o Gerenciador de frota.

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

Alterar a identidade de um cluster membro interrompe a comunicação entre o Fleet Manager e esse cluster membro. Embora o agente membro use a nova identidade para se comunicar com o Fleet Manager, o Fleet Manager ainda precisa estar ciente da 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 para Azure Arc

O Fleet Manager oferece suporte a clusters do AKS hospedados no Azure e a clusters do Kubernetes habilitados para o Azure Arc como clusters de membro.

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

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

O Gerenciador de Frotas de Kubernetes do Azure ajuda você a lidar com cenários de escala e multi-cluster para clusters do Serviço de Kubernetes do Azure. O Gerenciador de Frotas do Kubernetes do Azure fornece uma representação de grupo para seus clusters do AKS e ajuda os usuários com a orquestração de 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 do hub do Fleet Manager.

Posso provisionar novos clusters do AKS do Fleet Manager?

A criação e o gerenciamento do ciclo de vida de novos clusters do AKS estão em nosso roteiro. Se o suporte para a criação de agrupamentos for um cenário importante para você, forneça feedback.

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

Não. O cluster de hub do Fleet Manager é um recurso gerenciado pela Microsoft. A Microsoft atualiza automaticamente o cluster hub para a última versão do Kubernetes ou da imagem do nó à medida que eles ficam 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.

Por que meu cluster do hub do Gerenciador de Frota passou de Com falha para Em execução?

O cluster de hub do Fleet Manager é um cluster AKS gerenciado por Microsoft criado em sua assinatura. Você não precisa realizar nenhuma ação no cluster de hub.

Se houver um problema no provisionamento ou na operação do cluster de hub, ele poderá passar para um estado Failed.

O Gerenciador de Frota reconcilia automaticamente o cluster de hub como parte de operações de serviço periódicas padrão, o que pode mover o cluster do hub para um estado Running.

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

Atualizações de vários clusters – perguntas frequentes automatizadas ou manuais

Quais clusters dão suporte a atualizações de vários clusters?

Quais canais de atualização do AKS o Fleet Manager dá suporte?

O Fleet Manager dá suporte aos seguintes canais de atualização do AKS:

• Rápido: Atualizações para a versão mais recente do Kubernetes com suporte do AKS (N).
• Estável: atualizações do canal estável do Kubernetes (N-1), em que 'N' é a versão mais recente do Kubernetes com suporte do AKS.
• NodeImage: VHD de imagem de nó corrigida (bug e segurança) com um agendamento de lançamento semanal.
• TargetKubernetesVersion (Patch do Kubernetes): atualiza os clusters para a versão de patch mais recente da versão de destino especificada quando o patch está disponível. Dá suporte a versões secundárias do Kubernetes que estão disponíveis apenas por meio do AKS Long-Term Support (LTS).
• SecurityPatch (imagens do nó do Linux): atualizações do SO de imagem de nó que fornecem patches de segurança gerenciados pelo AKS aplicados ao VHD existente em execução no nó.

Canais do AKS sem suporte no momento:

• Unmanaged: atualizações do sistema operacional da imagem de nó aplicadas diretamente por meio de patch interno do sistema operacional (somente nós do Linux). No momento, não há planos para o Fleet Manager dar suporte a essa opção.

A versão menor do Kubernetes definida como alvo no meu perfil de auto-upgrade está fora do suporte da comunidade. O que posso fazer?

É possível:

• Permita suporte para versões menores (LTS - Suporte de Longo Prazo) no perfil de atualização automática e habilite-o para qualquer cluster em sua frota que você deseja manter na versão menor específica. Verifique se apenas os clusters LTS estão incluídos na estratégia de atualização que você usa.
• Atualize o perfil de auto-upgrade para uma nova versão menor do Kubernetes alvo. Os clusters são atualizados para o patch mais recente na versão menor especificada do Kubernetes quando liberado.

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

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

Se você deixar as atualizações automáticas do cluster do AKS habilitadas, o Fleet Manager ou a atualização automática do cluster do AKS executarão a atualização, dependendo de qual delas for executada primeiro.

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

Se você quiser que o Fleet Manager gerencie as atualizações automáticas, desabilite a atualização automática em cada cluster membro do AKS.

Suporte a janelas de manutenção para clusters AKS

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

O Fleet Manager respeita as configurações da janela de manutenção por cluster para cada cluster membro.

Quando uma janela de manutenção é aberta, as atualizações não são iniciadas imediatamente. Os motivos incluem:

• Limites de simultaneidade: mesmo que uma janela de manutenção seja aberta, um cluster pode não ser atualizado devido às configurações de simultaneidade da estratégia.
• Verificação periódica: o Fleet Manager verifica se há janelas de manutenção abertas a cada 60 minutos; portanto, o tempo máximo de espera é de 60 minutos a partir da abertura da janela.

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

A consistência do nó só é garantida para todos os clusters contidos em uma única execução de atualização em que você escolhe a opção consistent image .

Não há garantia de consistência para versões de imagem de nó em execuções de atualização separadas.

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

A execução da atualização lista as imagens de nós selecionadas usadas nessa execução. Você pode acessar essas informações mesmo que a execução da atualização não tenha sido iniciada.

Mais de uma imagem de nó pode ser selecionada, porque diferentes pools de nós atuam nos clusters selecionados para atualização.

Para localizar 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"

Você também pode usar a opção View JSON na página Visão Geral da Execução de Atualização no portal do Azure para exibir os dados brutos para uma execução de atualização.

Minha execução de atualização está em um estado pendente por algum tempo. O que devo fazer?

As execuções de atualização do Gerenciador de frota podem estar em um estado pendente por muitos motivos. Você pode exibir o status de uma execução de atualização por meio do portal do Azure ou seguindo a documentação de monitoramento.

Os dois motivos mais comuns para estados pendentes longos 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 entrará em um estado pausado. Essa pausa bloqueia a conclusão do grupo ou estágio de atualização até que a próxima janela de manutenção seja aberta. Para continuar a execução da atualização, ignore o cluster manualmente. Se você ignorar o cluster, ele está fora de sincronia com o restante dos clusters membros na execução da atualização.

• Versão do Kubernetes ou da imagem de nó não disponível na região do Azure: se a nova versão do Kubernetes ou da imagem de nó não estiver publicada na região do Azure em que um dos clusters membros existe, a execução da atualização entrará em estado pendente. Você pode verificar o rastreador de versão do AKS para ver o status regional da versão. Embora você possa ignorar o cluster de membros, se houver outros clusters na mesma região Azure eles também não poderão atualizar.

Minha execução de atualização automática foi iniciada e logo em seguida entrou em estado pendente. Por que?

Consulte a pergunta anterior.

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

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

Esse cenário poderá surgir se o perfil de atualização automática tiver gerado automaticamente a execução da atualização ou se a execução da atualização tiver sido gerada manualmente.

O nome da execução de atualização gerada é baseado 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.

Você geralmente vê esse problema no portal do Azure, onde a execução de atualização existente não é a mais recente. Se você encontrar esse problema e não conseguir localizar a execução de atualização, use a CLI do Azure para gerar a execução e ver o nome da execução de atualização. A Microsoft planeja corrigir este problema no portal do Azure futuramente.

Se você gerar uma execução de atualização e ela existir, a execução de atualização existente não será modificada.

Editar minha estratégia de atualização não alterou as execuções de atualização existentes que a usaram. Por que não?

Quando você cria uma execução de atualização, a estratégia é copiada para a execução da atualização para que as alterações na estratégia não afetem a execução de execuções de atualização.

Como evitar que uma única falha de cluster pare toda a minha execução de atualização?

Use a configuração maxAllowedFailures nos estágios e grupos da sua estratégia de atualização (disponível a partir da versão 2026-06-02-preview da API). Essa configuração permite que você especifique quantas falhas de cluster de membros são toleradas antes que o grupo ou o estágio seja marcado como com falha. Os valores podem ser um inteiro fixo (por exemplo, "3") ou um percentual (por exemplo, "25%"). Quando não definido ou "0", uma única falha interrompe toda a execução.

Para obter mais informações, consulte Máximo de falhas permitidas (versão prévia).

Por que a execução da atualização ou o grupo aparece como Concluído mesmo com falhas nos membros?

Quando você configura maxAllowedFailures, o Fleet Manager avalia apenas o número de atualizações de membros que falharam. Ele 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 limite configurado não seja excedido quando o Fleet Manager tomar decisões de agendamento.

Esse resultado é esperado e intencional, não um bug. Sempre inspecione FailureCount, os status no nível do membro e os motivos de falha antes de considerar a distribuição como íntegra. Para a maioria das estratégias de atualização, os limites baseados em porcentagem são mais fáceis de raciocinar do que valores absolutos.

Quais regras e limitações devo saber ao usar maxAllowedFailures?

Tenha em mente as seguintes regras:

• O recurso está disponível a partir da versão de API 2026-06-02-preview.
• Quando você remove a definição de maxAllowedFailures ou define como "0", o Gerenciador de Frota usa o comportamento fail-fast e para após a primeira falha na atualização de um membro.
• O limite é avaliado somente em relação à contagem de falhas. Ele não impõe uma taxa mínima de sucesso.
• Uma execução, estágio ou grupo pode mostrar Completed mesmo quando ocorrem falhas, desde que o limite configurado não seja excedido.
• FailureCount pode ser maior do que maxAllowedFailures quando as atualizações são executadas em paralelo, pois várias atualizações de membros podem falhar antes que o Fleet Manager pare de agendar mais trabalho.
• Os limites no nível de estágio e de grupo são avaliados de maneira independente, e as falhas no nível de estágio são agregadas considerando todos os grupos do estágio.
• Para a maioria das implantações, os limiares baseados em porcentagem são mais fáceis de entender e escalam melhor do que números fixos, especialmente em grupos pequenos.

Posso pré-aprovar um pedido de aprovação?

Não. Você só pode aprovar uma atualização depois de verificar se os clusters membros estão prontos para atualização ou se a atualização foi concluída com êxito. Se você quiser pré-aprovar, considere não configurar nenhuma aprovação em 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 gate, ignore o grupo ou estágio abrangente. Se você quiser prosseguir com as atualizações, deverá conceder a aprovação.

Como excluir uma aprovação?

Como na pergunta anterior, se você quiser continuar com uma atualização, deverá conceder a aprovação. Se você estiver tentando limpar o recurso de gate subjacente, deverá excluir a execução de atualização associada que exclui todos os gates vinculados à execução da atualização.

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

Sim. A espera após o estágio começa 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 a estratégias de atualização existentes?

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

Como os gates de inicialização agendados interagem com as janelas de manutenção do cluster AKS?

Os gates de inicialização agendados e as janelas de manutenção planejadas do cluster AKS são controles independentes. Ambas as condições devem ser atendidas antes de um cluster iniciar a atualização. Por exemplo, se um gate de inicialização agendado for concluído às 2h, mas a janela de manutenção do cluster só abrir às 6h, o cluster aguardará até as 6h para iniciar sua atualização.

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

Rótulos de membros e grupos de atualização são duas maneiras diferentes de selecionar quais clusters são incluídos em cada estágio e grupo de sua estratégia de atualização. Cada cluster de membros pode ser atribuído a um grupo de atualização, mas pode ter vários rótulos. Os rótulos de membro (usando memberSelector) oferecem mais flexibilidade e dão suporte a cenários de seleção complexos, portanto, eles são a maneira recomendada de selecionar membros da frota para estratégias de atualização. Para obter mais informações, consulte Clusters de grupo usando rótulos de membro.

Preciso especificar grupos se definir um seletor de membro no nível do estágio?

Não. Quando você define memberSelector em um estágio sem definir nenhum grupo, todos os clusters correspondentes são tratados como um único grupo. O estágio maxConcurrency controla quantos clusters são atualizados simultaneamente. Você só precisará definir grupos em um estágio se quiser particionar os membros correspondentes em subconjuntos paralelos com configurações de simultaneidade diferentes.

O que acontece com a atualização de grupos se eu definir um seletor de membro no nível do grupo?

Se você definir um memberSelector no nível do grupo, o campo name do grupo será usado apenas como um identificador de exibição para relatórios de status e registro em log. O memberSelector tem prioridade sobre o nome do grupo de atualização ao selecionar clusters para o grupo.

Perguntas frequentes sobre o posicionamento de recursos do cluster

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

Sim. O Fleet Manager dá suporte ao posicionamento de recursos no escopo do cluster e no escopo do namespace:

• ClusterResourcePlacement: propaga recursos com escopo de cluster e namespaces inteiros (incluindo todo o conteúdo) para clusters membros. Para obter mais informações, consulte Como usar ClusterResourcePlacement para implantar recursos com escopo de cluster.
• ResourcePlacement: fornece controle refinado para selecionar e propagar recursos específicos no escopo do namespace (como ConfigMaps, Segredos, Implantações) em um namespace. Para obter mais informações, consulte Como usar o ResourcePlacement para implantar recursos com escopo de namespace.

Roteiro

O roteiro Azure do Kubernetes Fleet Manager está disponível no GitHub. A equipe recebe solicitações de recursos, perguntas e relatórios de bugs.

Próximas etapas

• Criar uma frota e ingressar clusters membros.
• Guias de solução de problemas para o Fleet Manager.