Atualizar um cluster do Azure Kubernetes Service (AKS)
Parte do ciclo de vida do cluster AKS envolve a realização de atualizações periódicas para a versão mais recente do Kubernetes. É importante que aplique as versões e atualizações de segurança mais recentes para obter as funcionalidades mais recentes. Este artigo mostra como verificar e aplicar atualizações ao seu cluster AKS.
Atualizações de versão do Kubernetes
Ao atualizar um cluster AKS suportado, você não pode ignorar as versões secundárias do Kubernetes. Você deve executar todas as atualizações sequencialmente pelo número da versão principal. Por exemplo, atualizações entre 1.14.x ->1.15.x ou 1.15.x ->1.16.x são permitidas. 1.14.x ->1.16.x não é permitido. Você só pode ignorar várias versões ao atualizar de uma versão não suportada de volta para uma versão suportada. Por exemplo, você pode executar uma atualização de um 1.10.x sem suporte para um 1.12.x suportado, se disponível.
Quando você executa uma atualização de uma versão sem suporte que ignora duas ou mais versões secundárias, a atualização não tem garantia de funcionalidade e é excluída dos contratos de nível de serviço e da garantia limitada. Se a sua versão estiver significativamente desatualizada, recomendamos que você recrie o cluster.
Antes de começar
- Se você estiver usando a CLI do Azure, este artigo exigirá a CLI do Azure versão 2.34.1 ou posterior. Executar
az --versionpara localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure CLI (Instalar o Azure CLI). - Se você estiver usando o Azure PowerShell, este artigo requer o Azure PowerShell versão 5.9.0 ou posterior. Executar
Get-InstalledModule -Name Azpara localizar a versão. Se precisar de instalar ou atualizar, veja Install Azure PowerShell(Instalar o Azure PowerShell). - A execução de operações de atualização requer a
Microsoft.ContainerService/managedClusters/agentPools/writefunção RBAC. Para obter mais informações sobre as funções do Azure RBAC, consulte as operações do provedor de recursos do Azure. - A partir da versão 1.30 do kubernetes e das versões 1.27 LTS, as APIs beta serão desativadas por padrão quando você atualizar para elas.
Aviso
Uma atualização do cluster do AKS aciona um cordão e esvaziamento dos seus nós. Se você tiver uma cota de computação baixa disponível, a atualização poderá falhar. Para obter mais informações, veja aumentar as quotas.
Verifique se há atualizações de cluster AKS disponíveis
Nota
Para se manter a par das correções, lançamentos e atualizações do AKS, veja o monitorizador de versões do AKS.
Verifique quais versões do Kubernetes estão disponíveis para seu cluster usando o
az aks get-upgradescomando.az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output tableO exemplo de saída a seguir mostra a versão atual como 1.26.6 e lista as versões disponíveis em
upgrades:{ "agentPoolProfiles": null, "controlPlaneProfile": { "kubernetesVersion": "1.26.6", ... "upgrades": [ { "isPreview": null, "kubernetesVersion": "1.27.1" }, { "isPreview": null, "kubernetesVersion": "1.27.3" } ] }, ... }
Solucionar problemas de mensagens de erro de atualização do cluster AKS
A saída de exemplo a seguir significa que a appservice-kube extensão não é compatível com sua versão da CLI do Azure (é necessário um mínimo da versão 2.34.1):
The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Se você receber essa saída, precisará atualizar sua versão da CLI do Azure. O az upgrade comando foi adicionado na versão 2.11.0 e não funciona com versões anteriores à 2.11.0. Você pode atualizar versões mais antigas reinstalando a CLI do Azure conforme descrito em Instalar a CLI do Azure. Se sua versão da CLI do Azure for 2.11.0 ou posterior, execute az upgrade para atualizar a CLI do Azure para a versão mais recente.
Se sua CLI do Azure for atualizada e você receber a saída de exemplo a seguir, isso significa que nenhuma atualização está disponível:
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Se não houver atualizações disponíveis, crie um novo cluster com uma versão suportada do Kubernetes e migre suas cargas de trabalho do cluster existente para o novo cluster. O AKS não suporta a atualização de um cluster para uma versão mais recente do Kubernetes quando az aks get-upgrades mostra que nenhuma atualização está disponível.
Atualizar um cluster do AKS
Durante o processo de atualização do cluster, o AKS executa as seguintes operações:
- Adicione um novo nó de buffer (ou quantos nós configurados em max surge) ao cluster que executa a versão especificada do Kubernetes.
- Corda e drene um dos nós antigos para minimizar a interrupção dos aplicativos em execução. Se você estiver usando max surge, ele corda e drena tantos nós ao mesmo tempo quanto o número de nós de buffer especificado.
- Para pods de longa duração, você pode configurar o tempo limite de drenagem do nó, que permite o tempo de espera personalizado na remoção de pods e terminação graciosa por nó. Se não for especificado, o padrão é 30 minutos. O valor mínimo de tempo limite permitido é de 5 minutos.
- Quando o nó antigo é totalmente drenado, ele é recriado para receber a nova versão e se torna o nó de buffer para o nó seguinte a ser atualizado.
- Opcionalmente, você pode definir uma duração de tempo para aguardar entre drenar um nó e prosseguir para recriar a imagem dele e passar para o próximo nó. Um curto intervalo permite que você conclua outras tarefas, como verificar a integridade do aplicativo a partir de um painel do Grafana durante o processo de atualização. Recomendamos um curto período de tempo para o processo de atualização, o mais próximo de 0 minutos possível. Caso contrário, um tempo de imersão de nó mais alto afeta quanto tempo antes de descobrir um problema. O valor mínimo do tempo de imersão é de 0 minutos, com um máximo de 30 minutos. Se não for especificado, o valor padrão será 0 minutos.
- Esse processo se repete até que todos os nós no cluster sejam atualizados.
- No final do processo, o último nó de buffer é excluído, mantendo a contagem de nós do agente existente e o equilíbrio de zona.
Nota
Se não for especificado nenhum patch, o cluster será atualizado automaticamente para o patch de disponibilidade geral mais recente da versão secundária especificada. Por exemplo, a configuração --kubernetes-version para 1.28 resulta na atualização do cluster para 1.28.9.
Para obter mais informações, veja Atualizações de versão secundária do Kubernetes suportadas no AKS.
Atualize seu cluster usando o
az aks upgradecomando.az aks upgrade \ --resource-group myResourceGroup \ --name myAKSCluster \ --kubernetes-version <KUBERNETES_VERSION>Confirme se a atualização foi bem-sucedida usando o
az aks showcomando.az aks show --resource-group myResourceGroup --name myAKSCluster --output tableA saída de exemplo a seguir mostra que o cluster agora executa 1.27.3:
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn ------------ ---------- --------------- ------------------- ------------------- ---------------------------------------------- myAKSCluster eastus myResourceGroup 1.27.3 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
Definir canal de atualização automática
Você pode definir um canal de atualização automática no cluster. Para obter mais informações, consulte Atualização automática de um cluster AKS.
Personalizar atualização de aumento de nó
Importante
Os picos de nó exigem cota de assinatura para a contagem máxima de surtos solicitada para cada operação de atualização. Por exemplo, um cluster que tem cinco pools de nós, cada um com uma contagem de quatro nós, tem um total de 20 nós. Se cada pool de nós tiver um valor máximo de aumento de 50%, será necessária uma cota adicional de computação e IP de 10 nós (2 nós * 5 pools) para concluir a atualização.
A configuração de pico máximo em um pool de nós é persistente. Atualizações subsequentes do Kubernetes ou atualizações de versão de nó usarão essa configuração. Você pode alterar o valor máximo de surto para seus pools de nós a qualquer momento. Para pools de nós de produção, recomendamos uma configuração de pico máximo de 33%.
Se você estiver usando o Azure CNI, valide se há IPs disponíveis na sub-rede para atender aos requisitos de IP do Azure CNI.
O AKS configura as atualizações para aumentar com um nó extra por padrão. Um valor padrão de um para as configurações máximas de surto permite que o AKS minimize a interrupção da carga de trabalho criando um nó extra antes do cordão/drenagem de aplicativos existentes para substituir um nó versionado mais antigo. Você pode personalizar o valor máximo de aumento por pool de nós. Quando você aumenta o valor máximo de aumento, o processo de atualização é concluído mais rapidamente e você pode sofrer interrupções durante o processo de atualização.
Por exemplo, um valor máximo de aumento de 100% fornece o processo de atualização mais rápido possível, mas também faz com que todos os nós no pool de nós sejam drenados simultaneamente. Talvez você queira usar um valor mais alto como este para ambientes de teste. Para pools de nós de produção, recomendamos uma max_surge configuração de 33%.
O AKS aceita valores inteiros e um valor percentual para o aumento máximo. Um inteiro como 5 indica cinco nós extras a serem aumentados. Um valor de 50% indica um valor de aumento de metade da contagem de nós atual no pool. Os valores máximos de percentagem de sobretensão podem ser um mínimo de 1% e um máximo de 100%. Um valor percentual é arredondado para a contagem de nós mais próxima. Se o valor máximo de aumento for maior do que o número necessário de nós a serem atualizados, o número de nós a serem atualizados será usado para o valor máximo de aumento. Durante uma atualização, o valor máximo de aumento pode ser um mínimo de 1 e um valor máximo igual ao número de nós no pool de nós. Você pode definir valores maiores, mas não pode definir o número máximo de nós usados para aumento máximo maior do que o número de nós no pool no momento da atualização.
Definir valor máximo de surto
Defina valores máximos de aumento para pools de nós novos ou existentes usando o
az aks nodepool addcomando oraz aks nodepool update.# Set max surge for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% # Update max surge for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
Definir valor de tempo limite de drenagem do nó
Às vezes, você pode ter uma carga de trabalho de longa execução em um determinado pod e ela não pode ser reagendada para outro nó durante o tempo de execução, por exemplo, uma carga de trabalho com estado intensivo de memória que deve terminar a execução. Nesses casos, você pode configurar um tempo limite de drenagem de nó que o AKS respeitará no fluxo de trabalho de atualização. Se nenhum valor de tempo limite de drenagem de nó for especificado, o padrão será 30 minutos. O valor mínimo permitido de tempo limite de drenagem é de 5 minutos.
Se o valor de tempo limite de drenagem decorrer e os pods ainda estiverem em execução, a operação de atualização será interrompida. Qualquer operação PUT subsequente deve retomar a atualização interrompida. Também é recomendado para pods de longa duração configurar o [terminationGracePeriodSeconds][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/].
Defina o tempo limite de drenagem do nó para pools de nós novos ou existentes usando o
az aks nodepool addcomando oraz aks nodepool update.# Set drain timeout for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 100 # Update drain timeout for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 45
Definir valor de tempo de imersão do nó
Para permitir um período de tempo de espera entre drenar um nó e prosseguir para recriá-lo e passar para o próximo nó, você pode definir o tempo de imersão para um valor entre 0 e 30 minutos. Se nenhum valor de tempo de imersão do nó for especificado, o padrão será 0 minutos.
Defina o tempo de imersão do nó para pools de nós novos ou existentes usando o
az aks nodepool addcomando ,az aks nodepool updateouaz aks nodepool upgrade.# Set node soak time for a new node pool az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10 # Update node soak time for an existing node pool az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5 # Set node soak time when upgrading an existing node pool az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20
Ver eventos de atualização
Exiba eventos de atualização usando o
kubectl get eventscomando.kubectl get eventsA saída de exemplo a seguir mostra alguns dos eventos acima listados durante uma atualização:
... default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001] ... default 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001 Soak duration 5m0s after draining node: aks-nodepool1-96663640-vmss000001 ... default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool nodepool1 ...
Próximos passos
Para saber como configurar atualizações automáticas, consulte Configurar atualizações automáticas para um cluster AKS.
Para obter uma discussão detalhada sobre as práticas recomendadas de atualização e outras considerações, consulte o patch do AKS e as diretrizes de atualização.
Azure Kubernetes Service