Atualizar um cluster do Kubernetes do Nexus do Operador do Azure

Artigo
09/02/2024

Este artigo fornece instruções sobre como atualizar um cluster do Kubernetes do Nexus do Operador para obter os últimos recursos e atualizações de segurança. Parte do ciclo de vida do cluster do Kubernetes envolve a execução de atualizações periódicas para a última versão do Kubernetes. É importante aplicar as últimas versões de segurança ou atualizar para obter os recursos mais recentes. Este artigo mostra como verificar, configurar e aplicar atualizações ao cluster do Kubernetes.

Limitações

O processo de atualização padrão do cluster é uma abordagem de expansão, o que significa que pelo menos um nó extra é adicionado (ou quantos nós forem configurados em pico máximo). Se não houver capacidade suficiente disponível, a atualização não terá êxito.
Quando novas versões do Kubernetes estiverem disponíveis, os clusters de locatários não passarão por atualizações automáticas. Os usuários devem iniciar a atualização quando todas as funções de rede no cluster estiverem prontas para dar suporte à nova versão do Kubernetes. Para obter mais informações, consulte Atualizar o cluster.
O Nexus do Operador oferece atualizações em todo o cluster, garantindo consistência em todos os pools de nós. Não há suporte para a atualização de um único pool de nós. Além disso, a imagem do nó é atualizada como parte da atualização do cluster quando uma nova versão está disponível.
As personalizações feitas nos nós do agente serão perdidas durante as atualizações do cluster. É recomendável colocar essas personalizações em DaemonSet em vez de fazer alterações manuais na configuração do nó para preservá-las após a atualização.
As modificações feitas nas principais configurações de complemento são restauradas para a configuração do complemento padrão como parte do processo de atualização do cluster. Evite personalizar a configuração do complemento (por exemplo, Calico, etc.) para evitar possíveis falhas de atualização. Se a restauração da configuração do complemento encontrar problemas, isso poderá levar a falhas de atualização.
Quando você atualiza o cluster do Kubernetes do Nexus do Operador, as versões secundárias do Kubernetes não podem ser atualizadas. Você deve realizar toas as atualizações sequencialmente por número de versão principal. Por exemplo, atualizações entre 1.14.x ->1.15.x ou 1.15.x ->1.16.x são permitidas; no entanto, 1.14.x ->1.16.x não são permitidas. Se sua versão estiver atrasada em mais de uma versão principal, você deverá executar várias atualizações sequenciais.
Os valores pico máximo e/ou máximo não disponível devem ser definidos durante a criação do cluster. Não é possível alterar esses valores após a criação do cluster. Para obter mais informações, consulte upgradeSettings em Criar um cluster do Kubernetes do Nexus do Operador do Azure.

Pré-requisitos

Um cluster de Kubernetes do Nexus do Operador do Azure implantado em um grupo de recursos em sua assinatura do Azure.
Se você estiver usando a CLI do Azure, este artigo exige que você esteja executando a última versão da CLI do Azure. Se você precisa instalar ou atualizar, consulte Instalar a CLI do Azure
Versão mínima necessária da extensão az-cli networkcloud: 2.0.b3
Entender o conceito de pacotes de versão. Para obter mais informações, consulte Pacotes de versão do Kubernetes do Nexus.

Verificar se há atualizações disponíveis

Verifique quais versões do Kubernetes estão disponíveis para seu cluster usando as seguintes etapas:

Usar a CLI do Azure

O seguinte comando da CLI do Azure retorna as atualizações disponíveis para o cluster:

az networkcloud kubernetescluster show --name <NexusK8sClusterName> --resource-group <ResourceGroup> --output json --query availableUpgrades

Saída de exemplo:

[
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.4-4"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.25.6-1"
  },
  {
    "availabilityLifecycle": "GenerallyAvailable",
    "version": "v1.26.3-1"
  }
]

Use o Portal do Azure

Entre no portal do Azure.
Navegue para o cluster do Kubernetes do Nexus do Operador.
Em Visão geral, selecione a guia Atualizações disponíveis.

Escolha uma versão para a qual atualizar

A saída de atualização disponível indica que há várias versões para escolher para atualização. Nesse cenário específico, o cluster atual está operando na versão v1.25.4-3.. Como resultado, as opções de atualização disponíveis incluem v1.25.4-4 e a última versão do patch v1.25.6-1.. Além disso, uma nova versão secundária também está disponível.

Você tem a flexibilidade para atualizar para qualquer uma das versões disponíveis. No entanto, a ação recomendada é executar a atualização para a última versão de major-minor-patch-versionbundle disponível.

Observação

O formato de entrada da versão é major.minor.patch ou major.minor.patch-versionbundle. A entrada de versão deve ser uma das versões de atualização disponíveis. Por exemplo, se a versão atual do cluster for 1.1.1-1, as entradas de versão válidas serão 1.1.1-2 ou 1.1.1-x. Embora 1.1.1 seja um formato válido, ele não disparará nenhuma atualização porque a versão atual já está 1.1.1. Para iniciar uma atualização, você pode especificar a versão completa com o pacote de versão, como 1.1.1-2. No entanto, 1.1.2 e 1.2.x são uma entrada válida e usarão o pacote de versão mais recente disponível para 1.1.2 ou 1.2.x.

Atualizar o cluster

Durante o processo de atualização do cluster, o Nexus do Operador executa as seguintes operações:

Adicionar um novo nó do painel de controle com a versão do Kubernetes especificada ao cluster.
Depois que o novo nó tiver sido adicionado, isole e esvazie um dos nós antigos do painel de controle, garantindo que as cargas de trabalho em execução nele sejam movidas normalmente para outros nós íntegros do painel de controle.
Depois que o nó antigo do painel de controle tiver sido esvaziado, ele será removido e um novo nó do painel de controle será adicionado ao cluster.
Esse processo se repete até que todos os nós do painel de controle no cluster tenham sido atualizados.
Se estiver atualizando nós de trabalho por meio de pico (padrão):
- Para cada pool de agentes no cluster, adicione um novo nó de trabalho (ou quantos nós forem configurados em pico máximo) com a versão do Kubernetes especificada. Vários pools de agentes são atualizados simultaneamente.
- Isole e esvazie um dos nós de trabalho antigos para minimizar a interrupção dos aplicativos em execução. Se você estiver usando o pico máximo, ele isola e esvazia simultaneamente o mesmo número de nós de trabalho que o número de nós de buffer especificado.
- Depois que o nó de trabalho antigo tiver sido esvaziado, ele será removido e um novo nó de trabalho com a nova versão do Kubernetes será adicionado ao cluster (ou quantos nós forem configurados em pico máximo)
Se estiver atualizando nós de trabalho sem pico:
- Para cada pool de agentes no cluster, um nó de trabalho antigo (ou quantos nós forem configurados por máximo não disponível) é isolado, esvaziado e removido, antes de ser substituído por um novo nó de trabalho com a versão do Kubernetes especificada. Vários pools de agentes são atualizados simultaneamente.
- Durante a atualização, haverá uma redução temporária na capacidade do cluster, pois os pods esvaziados do nó de trabalho antigo não terão imediatamente um novo nó para o qual se mover. Isso pode fazer com que os pods entrem em um estado pendente se não houver capacidade suficiente. Portanto, é crucial projetar seu cluster para atender aos requisitos de capacidade do aplicativo, especialmente durante atualizações sem pico.
Esse processo se repete até que todos os nós de trabalho no cluster tenham sido atualizados.

Observação

A atualização do cluster não criará novos nós e substituirá os antigos se a versão da imagem do sistema operacional (SO) e a versão do Kubernetes permanecerem iguais entre os pacotes de versão. Esse é o comportamento esperado, pois a atualização pode incluir apenas atualizações para versões de complemento em vez de novas versões do sistema operacional ou K8s. Como não há nenhuma atualização sem interrupção envolvida, não há isolamento e esvaziamento nos nós, portanto, as interrupções do pod não ocorrerão.

Importante

Certifique-se de que qualquer PodDisruptionBudgets (PDB) permita que pelo menos uma réplica de pod seja movida por vez, caso contrário, a operação de esvaziamento/remoção falhará. Se a operação de esvaziamento falhar, a operação de atualização também falhará para garantir que os aplicativos não sejam interrompidos. Corrija o que causou a interrupção da operação (por exemplo, PDBs incorretos, falta de cota, etc.) e repita a operação. Também é possível configurar um tempo limite de esvaziamento por pool de nó de trabalho, após o qual o nó será removido mesmo que o esvaziamento dos pods ainda não tenha sido concluído. Isso pode impedir que as atualizações sejam bloqueadas por PDBs configurados incorretamente. A configuração de tempo limite de esvaziamento é definida em segundos e usa 1800 como padrão.

Atualize seu cluster usando o comando networkcloud kubernetescluster update.

az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3

Confirme se a atualização foi bem-sucedida usando o comando show.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output json --query kubernetesVersion

A saída de exemplo a seguir mostra que o cluster agora executa v1.26.3:

"v1.26.3"

Verifique se o cluster está íntegro.

az networkcloud kubernetescluster show --name myNexusK8sCluster --resource-group myResourceGroup --output table

A saída de exemplo a seguir mostra que o cluster está íntegro:

Name                 ResourceGroup          ProvisioningState    DetailedStatus    DetailedStatusMessage             Location
------------------   ---------------------  -------------------  ----------------  --------------------------------  --------------
myNexusK8sCluster    myResourceGroup        Succeeded            Available         Cluster is operational and ready  southcentralus

Personalizar o pico de nó ou atualização de indisponibilidade

Por padrão, o Nexus do Operador configura atualizações para atingirem um pico com um nó de trabalho extra. Um valor padrão de um para as configurações de pico máximo permite que o Nexus do Operador minimize a interrupção da carga de trabalho criando um nó extra antes de isolar/remover os aplicativos existentes para substitui um nó com versão mais antiga. O valor da sobretensão máxima pode ser personalizado por pool de nós para permitir uma compensação entre a velocidade da atualização e a interrupção da atualização. Quando você aumenta o valor da sobretensão máxima, o processo de atualização é concluído mais rapidamente. Se você definir um valor grande para a sobretensão máxima, poderá sofrer interrupções durante o processo de atualização.

Por exemplo, um valor de sobretensão máxima de 100% proporciona o processo de atualização mais rápido possível (duplicando a contagem de nós), mas também faz com que todos os nós no pool de nós sejam esvaziados simultaneamente. Talvez você queira usar um valor alto, como este, para ambientes de teste. Para pools de nós de produção, recomendamos uma configuração de max_surge de 33%.

Nem sempre é apropriado atualizar por meio do pico, por exemplo, em ambientes com restrição de recursos. As atualizações também podem continuar sem o pico, em que um nó de trabalho é removido e, em seguida, substituído. Isso significa que nenhum recurso extra é necessário, mas leva a períodos de capacidade reduzida em que os pods podem não ser capazes de serem agendados para um nó. Esse tipo de atualização é controlado por pool de nós pela configuração Máximo não disponível. Por padrão, máximo não disponível é definido como 0. Isso indica que, no máximo 0 nós podem não estar disponíveis, ou seja, esse tipo de atualização não acontecerá por padrão.

A API aceita valores inteiros e um valor percentual para pico máximo e máximo não disponível. Um inteiro como 5 indica que cinco nós podem atingir um pico/se tornarem não disponíveis. Um valor de 50% indica um valor de pico/indisponibilidade da metade da contagem atual de nós no pool.

Um pico máximo ou máximo não disponível deve ser de pelo menos 1 (ou 1%), caso contrário, não haveria mecanismo pelo qual o cluster poderia ser atualizado. Um valor percentual é arredondado para cima, para a contagem de nós mais próxima. O pico máximo e o máximo não disponível podem ser definidos como um máximo de 100%. 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 como valor máximo de aumento.

O pico máximo e o máximo não disponível podem ser configurados ao mesmo tempo; nesse caso, a atualização continuará por meio de uma combinação de pico e indisponibilidade.

Importante

As cargas de trabalho padrão do Kubernetes circulam nativamente para os novos nós quando são esvaziados dos nós que estão sendo desativados. Lembre-se de que o serviço do Kubernetes do Nexus do Operador não pode fazer promessas de carga de trabalho para comportamentos do Kubernetes não padrão.

Próximas etapas

Saiba mais sobre Pacotes de versão do Kubernetes do Nexus.

Compartilhar via