Opções de atualização para clusters do Serviço de Kubernetes do Azure (AKS)

Este artigo aborda as diferentes opções de atualização dos clusters do AKS. Para executar uma atualização básica da versão do Kubernetes, confira Atualizar um cluster do AKS.

Para clusters do AKS que usam vários pools de nós ou nós do Windows Server, confira Atualizar um pool de nós no AKS. Para atualizar um pool de nós específico sem fazer uma atualização de cluster do Kubernetes, confira Atualizar um pool de nós específico.

Executar atualizações manuais

Você pode executar atualizações manuais para controlar quando o cluster é atualizado para uma nova versão do Kubernetes. Atualizações manuais são úteis quando você deseja testar uma nova versão do Kubernetes antes de atualizar seu cluster de produção. Você também pode usar atualizações manuais para atualizar seu cluster para uma versão específica do Kubernetes que não é a versão mais recente disponível.

Para executar atualizações manuais, confira os seguintes artigos:

• Atualizar um cluster AKS
• Atualizar a imagem do nó
• Personalizar a atualização de pico de nó
• Atualizações do sistema operacional do nó de processo
• Upgrade de vários clusters do AKS por meio do Gerenciador de Frota de Kubernetes do Azure

Configurar atualizações automáticas

Você pode configurar atualizações automáticas para atualizar automaticamente o cluster para a versão mais recente do Kubernetes disponível. Atualizações automáticas são úteis quando você deseja garantir que o cluster esteja sempre executando a versão mais recente do Kubernetes. Você também pode usar atualizações automáticas para garantir que o cluster esteja sempre executando uma versão do Kubernetes com suporte.

Para configurar atualizações automáticas, confira os seguintes artigos:

• Atualizar automaticamente um cluster do AKS
• Usar a manutenção planejada para agendar e controlar atualizações para o cluster do AKS
• Parar atualizações de cluster do AKS automaticamente em alterações interruptivas da API (versão prévia)
• Atualizar automaticamente imagens do sistema operacional do nó de cluster do AKS
• Aplicar atualizações de segurança a nós do AKS automaticamente usando o GitHub Actions

Considerações especiais para pools de nós que abrangem várias zonas de disponibilidade

O AKS usa o balanceamento de zonas de melhor esforço em grupos de nós. Durante uma sobretensão da atualização, as zonas para os nós de sobretensão nos Conjuntos de Dimensionamento de Máquinas Virtuais são desconhecidas com antecedência, o que pode causar temporariamente uma configuração de zona desequilibrada durante uma atualização. No entanto, o AKS exclui os nós de sobretensão quando a atualização é concluída e preserva o equilíbrio da zona original. Se quiser manter suas zonas equilibradas durante as atualizações, você pode aumentar a sobretensão para um múltiplo de três nós, e os Conjuntos de Dimensionamento de Máquinas Virtuais equilibra seus nós entre as zonas de disponibilidade com o balanceamento de zona de melhor esforço. Com melhor balanceamento de zona possível, o conjunto de dimensionamento tenta reduzir e expandir mantendo o balanceamento. No entanto, se por alguma razão não for possível (por exemplo, se uma zona ficar inativa, o conjunto de dimensionamento não poderá criar uma nova VM nessa zona), o conjunto de dimensionamento permitirá o desbalanceamento temporário para expandir ou reduzir corretamente.

As declarações de volume persistente (PVCs) com suporte do armazenamento com redundância local (LRS) do Azure são associadas a uma zona específica e podem não se recuperar imediatamente se o nó de aumento não corresponder à zona de PVC. Se as zonas não corresponderem, isso poderá causar tempo de inatividade em seu aplicativo quando a operação de atualização continuar a esvaziar nós, mas as PVs estiverem associadas a uma zona. Para lidar com esse caso e manter a alta disponibilidade, configure um Orçamento de Interrupção de Pod em seu aplicativo para permitir que o Kubernetes respeite seus requisitos de disponibilidade durante a operação de esvaziamento.

Otimizar atualizações para melhorar o desempenho e minimizar interrupções

A combinação de Janela de Manutenção Planejada, Pico Máximo, Orçamento de Interrupção do Pod, tempo limite de drenagem de nó e tempo de estabilização do nó pode aumentar significativamente a probabilidade de as atualizações de nós serem concluídas com sucesso até o final da janela de manutenção, ao mesmo tempo que minimiza as interrupções.

• A janela de manutenção planejada permite que as equipes de serviço agendem a atualização automática durante uma janela predefinida, normalmente, um período de baixo tráfego, para minimizar o impacto na carga de trabalho. Recomendamos uma duração de janela de pelo menos quatro horas.
• O Pico máximo no pool de nós permite a solicitação de cota extra durante o processo de atualização e limita o número de nós selecionados para atualização simultaneamente. Um pico máximo maior resulta em um processo de atualização mais rápido. Não recomendamos defini-lo como 100%, pois isso atualiza todos os nós simultaneamente, o que pode causar interrupções na execução de aplicativos. Recomendamos uma cota máxima de aumento de 33% para pools de nós de produção.
• O Orçamento de Interrupção do Pod é definido para aplicativos de serviço e limita o número de pods que podem ficar inativos durante interrupções voluntárias, como atualizações de nó controladas pelo AKS. Ele pode ser configurado como réplicas minAvailable, indicando o número mínimo de pods de aplicativo que precisam estar ativos ou réplicas maxUnavailable, indicando o número máximo de pods de aplicativo que podem ser encerrados, garantindo alta disponibilidade para o aplicativo. Consulte as diretrizes fornecidas para configurar PDBs (Orçamentos de Interrupção de Pod). Os valores do PDB devem ser validados para determinar as configurações que funcionam melhor para seu serviço específico.
• Tempo limite de drenagem de nó no pool de nós permite que você configure a duração de espera para remoção de pods e terminação normal por nó durante uma atualização. Essa opção é útil ao lidar com cargas de trabalho de execução prolongada. Quando o tempo limite de drenagem do nó é especificado (em minutos), o AKS respeita a espera dos orçamentos de interrupção do pod. Se não for especificado, o tempo limite padrão será 30 minutos.
• O tempo de estabilização do nó ajuda a equilibrar atualizações de nó de maneira controlada e pode minimizar o tempo de inatividade do aplicativo durante uma atualização. Você pode especificar um tempo de espera, preferencialmente o mais razoavelmente próximo possível de 0 minutos, para verificar a preparação do aplicativo entre atualizações de nó. Se não for especificado, o valor padrão será 0 minutos. O tempo de estabilização do nó funciona em conjunto com as propriedades máximas de tempo limite de drenagem de nó e aumento máximo disponíveis no pool de nós para fornecer os resultados certos em termos de velocidade de atualização e disponibilidade do aplicativo.

Próximas etapas

Este artigo listou diferentes opções de atualização para clusters do AKS. Para obter uma discussão detalhada sobre as melhores práticas de atualização e outras considerações, veja Diretrizes de patch e atualização do AKS.