Partilhar via

Atualizar um cluster do Nexus Kubernetes do Operador do Azure

  • Artigo

Este artigo fornece instruções sobre como atualizar um cluster Kubernetes do Operator Nexus para obter os recursos e atualizações de segurança mais recentes. Parte do ciclo de vida do cluster Kubernetes envolve a execução de atualizações periódicas para a versão mais recente do Kubernetes. É importante que aplique as versões de segurança mais recentes ou atualize para obter as funcionalidades 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 tantos nós quantos configurados em max surge). Se não houver capacidade suficiente disponível, a atualização não será bem-sucedida.
  • 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 suportar a nova versão do Kubernetes. Para obter mais informações, consulte Atualizar o cluster.
  • O Operator Nexus 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 pool de nó único. 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 de cluster. É recomendável colocar essas personalizações em DaemonSet vez de fazer alterações manuais na configuração do nó para preservá-las após a atualização.
  • As modificações feitas nas configurações principais do addon são restauradas para a configuração padrão do addon como parte do processo de atualização do cluster. Evite personalizar a configuração do addon (por exemplo, Calico, etc.) para evitar possíveis falhas de atualização. Se a restauração da configuração do addon encontrar problemas, isso pode levar a falhas de atualização.
  • Quando você atualiza o cluster Kubernetes do Operator Nexus, as versões secundárias do Kubernetes não podem ser ignoradas. 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, no entanto, 1.14.x ->1.16.x não é permitido. Se a sua versão estiver atrasada por mais de uma versão principal, você deverá executar várias atualizações sequenciais.
  • Os valores de pico máximo e/ou máximo indisponível devem ser definidos durante a criação do cluster. Não é possível alterar esses valores depois que o cluster é criado. Para obter mais informações, consulte upgradeSettings Criar um cluster Kubernetes do Nexus do Operador do Azure.

Pré-requisitos

  • Um cluster 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 requer que você esteja executando a versão mais recente da CLI do Azure. Se você precisar instalar ou atualizar, consulte Instalar a CLI do Azure
  • Versão mínima necessária networkcloud da extensão az-cli: 2.0.b3
  • Entenda o conceito de pacotes de versão. Para obter mais informações, consulte Pacotes de versão do Nexus Kubernetes.

Verifique se há atualizações disponíveis

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

Utilizar a CLI do Azure

O seguinte comando da CLI do Azure retorna as atualizações disponíveis para seu 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"
  }
]

Utilizar o portal do Azure

  1. Inicie sessão no portal do Azure.
  2. Navegue até o cluster Nexus Kubernetes do operador.
  3. Em Visão geral, selecione a guia Atualizações disponíveis.

Captura de ecrã das 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. Neste 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 versão v1.25.6-1. mais recente do patch Além disso, uma nova versão secundária também está disponível.

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

Nota

O formato de entrada para a 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 acionará nenhuma atualização porque a versão atual já 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 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 Operator Nexus executa as seguintes operações:

  • Adicione um novo nó de plano de controle com a versão especificada do Kubernetes ao cluster.
  • Depois que o novo nó tiver sido adicionado, faça cordão e drene um dos nós do plano de controle antigo, garantindo que as cargas de trabalho em execução nele sejam movidas graciosamente para outros nós do plano de controle íntegro.
  • Depois que o nó do plano de controle antigo for drenado, ele será removido e um novo nó do plano de controle será adicionado ao cluster.
  • Esse processo se repete até que todos os nós do plano de controle no cluster tenham sido atualizados.
  • Se atualizar os nós de trabalho via surto (padrão):
    • Para cada pool de agentes no cluster, adicione um novo nó de trabalho (ou quantos nós forem configurados em max surge) com a versão especificada do Kubernetes. Vários pools de agentes são atualizados simultaneamente.
    • Conecte e drene 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 corda e drena tantos nós de trabalho ao mesmo tempo quanto o número de nós de buffer especificado.
    • Depois que o nó de trabalho antigo for drenado, 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 max surge)
  • Se atualizar nós de trabalho sem surto:
    • Para cada pool de agentes no cluster, um nó de trabalho antigo (ou quantos nós configurados pelo máximo indisponível) é isolado, drenado e, em seguida, removido, antes de ser substituído por um novo nó de trabalho com a versão especificada do Kubernetes. Vários pools de agentes são atualizados simultaneamente.
    • Durante a atualização, haverá uma redução temporária na capacidade do cluster, uma vez que os pods drenados do nó de trabalho antigo não terão imediatamente um novo nó para 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 upgrades sem surtos.
  • Esse processo se repete até que todos os nós de trabalho no cluster tenham sido atualizados.

Nota

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 as mesmas entre os pacotes de versão. Este é um comportamento esperado, uma vez que a atualização pode incluir apenas atualizações para versões do Addon, em vez de novas versões do SO ou K8s. Como não há nenhuma atualização de rolamento envolvida, não há cordão e drenagem nos nós, portanto, 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 de cada vez, caso contrário, a operação de drenagem/remoção falhará. Se a operação de drenagem falhar, a operação de atualização também falhará, para garantir que os aplicativos não sejam interrompidos. Corrija o que levou à interrupção da operação (ou seja, APO incorretos, falta de quota, etc.) e tente novamente a operação. Também é possível configurar um tempo limite de drenagem por pool de nós de trabalhador, após o qual o nó será removido mesmo que os pods ainda não tenham terminado de drenar. Isso pode impedir que as atualizações sejam bloqueadas por PDBs mal configurados. A configuração de tempo limite de drenagem é configurada em segundos e o padrão é 1800.

  1. Atualize seu cluster usando o networkcloud kubernetescluster update comando.
az networkcloud kubernetescluster update --name myNexusK8sCluster --resource-group myResourceGroup --kubernetes-version v1.26.3
  1. Confirme se a atualização foi bem-sucedida usando o show comando.
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 a v1.26.3:

"v1.26.3"
  1. 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 aumento de nó ou atualização de indisponibilidade

Por padrão, o Operator Nexus configura as atualizações para aumentar com um nó de trabalho extra. Um valor padrão de um para as configurações de surto máximo permite que o Operator Nexus minimize a interrupção da carga de trabalho criando um nó extra antes do corte/drenagem de aplicativos existentes para substituir um nó versionado mais antigo. O valor máximo de aumento pode ser personalizado por pool de nós para permitir uma compensação entre a velocidade de atualização e a interrupção da atualização. Quando você aumenta o valor máximo de surto, o processo de atualização é concluído mais rapidamente. Se você definir um valor grande para o aumento máximo, poderá ocorrer 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 (dobrando a contagem de nós), 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 configuração de max_surge de 33%.

Nem sempre é apropriado atualizar via surto, por exemplo, em ambientes com restrição de recursos. As atualizações também podem prosseguir sem surtos, onde um nó de trabalho é primeiro 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 ser agendados para um nó. Esse tipo de atualização é controlado por pool de nós pela configuração máxima indisponível. Por padrão, max unavailable é definido como 0. Isso indica que no máximo 0 nós podem estar indisponí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 indisponível. Um número inteiro como 5 indica que cinco nós podem ser aumentados/tornados indisponíveis. Um valor de 50% indica um valor de surto/indisponibilidade de metade da contagem de nós atual no pool.

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

Max surto e max indisponível podem ser configurados ao mesmo tempo, caso em que a atualização prosseguirá por meio de uma mistura de surto e indisponibilidade.

Importante

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

Próximos passos