Você pode iniciar uma atualização sem interrupção de um cluster TKG 2 em Supervisor atualizando a versão Tanzu Kubernetes release, atualizando a classe de máquina virtual e atualizando a classe de armazenamento. Antes de fazer isso, você deve verificar a compatibilidade do cluster e se familiarizar com o processo de atualização sem interrupção.

Modelo de atualização sem interrupção para clusters TKG 2

O controlador TKG é executado em Supervisor. Quando você atualiza o Supervisor, o controlador TKG é atualizado automaticamente se uma atualização estiver disponível. Cada atualização do controlador TKG pode incluir atualizações para serviços de suporte, como CNI, CSI, CPI, bem como atualizações de configuração para clusters. Para oferecer suporte à compatibilidade, o sistema realiza pré-verificações e impõe a conformidade.

A TKG usa um modelo de atualização sem interrupção para atualizar clusters de carga de trabalho. O modelo de atualização sem interrupção garante que haja um tempo de inatividade mínimo durante o processo de atualização do cluster. As atualizações contínuas incluem a atualização das versões do software Kubernetes e a infraestrutura e os serviços que oferecem suporte aos clusters, como configurações e recursos de máquinas virtuais, serviços e namespaces e recursos personalizados. Para que a atualização seja bem-sucedida, sua configuração deve atender a vários requisitos de compatibilidade, para que o sistema imponha condições de nova verificação para garantir que os clusters estejam prontos para atualizações e ofereça suporte à reversão se a atualização do cluster não for bem-sucedida.

Você pode iniciar uma atualização sem interrupção de um TKG 2 usando um dos seguintes métodos:

Uma atualização sem interrupção do cluster também pode ser iniciada pelo sistema. Por exemplo, quando uma atualização do vSphere Namespaces é executada, o sistema propaga imediatamente as configurações atualizadas para todos os clusters de carga de trabalho. Essas atualizações podem acionar uma atualização sem interrupção de nós de cluster. Além disso, uma alteração em qualquer um dos elementos de configuração também pode iniciar uma atualização sem interrupção. Por exemplo, renomear ou substituir o VirtualMachineImage que corresponde a uma versão de distribuição inicia uma atualização sem interrupção, pois o sistema tenta executar todos os nós na nova imagem. Além disso, a atualização de um Supervisor provavelmente acionará uma atualização sem interrupção dos clusters de carga de trabalho implantados lá. Por exemplo, quando o vmware-system-tkg-controller-manager é atualizado, o sistema introduz novos valores no gerador de manifesto e o controlador inicia uma atualização sem interrupção para implantar esses valores.

O processo de atualização sem interrupção para substituir os nós do cluster é semelhante à atualização sem interrupção de pods em uma implantação do Kubernetes. Há dois controladores distintos responsáveis por executar uma atualização sem interrupção de clusters de carga de trabalho: o controlador de complementos e o controlador de cluster. Nesses dois controladores, há três estágios principais para uma atualização sem interrupção: atualização de complementos, atualização do plano de controle e atualização dos nós do trabalhador. Esses estágios ocorrem em ordem, com pré-verificações que impedem que uma etapa seja iniciada até que a etapa anterior tenha progredido o suficiente. Essas etapas poderão ser ignoradas se forem consideradas desnecessárias. Por exemplo, uma atualização pode afetar apenas os nós do trabalhador e, portanto, não exigir nenhuma atualização de complemento ou plano de controle.

Durante o processo de atualização, o sistema adiciona um novo nó de cluster e aguarda que o nó fique online com a versão de destino do Kubernetes. Em seguida, o sistema marca o nó antigo para exclusão, passa para o próximo nó e repete o processo. O nó antigo não é excluído até que todos os pods sejam removidos. Por exemplo, se um pod for definido com PodDisruptionBudgets que impedem que um nó seja totalmente drenado, o nó será isolado, mas não será removido até que esses pods possam ser despejados. O sistema atualiza primeiro todos os nós do plano de controle e, em seguida, os nós do trabalhador. Durante uma atualização, o status do cluster muda para "atualizando". Após a conclusão do processo de atualização sem interrupção, o status do cluster muda para "em execução".

Os pods em execução em um cluster que não são controlados por um controlador de replicação serão excluídos durante uma atualização de versão do Kubernetes como parte da drenagem do nó do trabalhador durante a atualização do cluster. Isso será verdadeiro se a atualização do cluster for acionada manual ou automaticamente por uma atualização de vSphere Namespaces ou Supervisor. Os pods não regidos por um controlador de replicação incluem pods que não são criados como parte de uma especificação de implantação ou ReplicaSet. Consulte Ciclo de vida do pod: vida útil do pod na documentação do Kubernetes para obter mais informações.

Disparadores do sistema para atualizações contínuas automatizadas

Em cada versão de Supervisor, podem ser feitas alterações em um ou mais dos seguintes objetos:
  • kubeadmcontrolplanetemplate/kubeadmcontrolplane
  • kubeadmconfigtemplate/kubeadmconfig
  • vspheremachinetemplate/vspheremachine (para vSphere 8.x)
  • wcpmachinettemplate/wcpmachine (para vSphere 7.x)
Quando o Supervisor for atualizado, os controladores principais de Cluster API (CAPI) acionarão uma distribuição de atualização para clusters de carga de trabalho TKG para corresponder ao estado desejado dos objetos acima nos clusters de carga de trabalho em execução.

Em vSphere with Tanzu, o TKG Controller executado em Supervisor gera e mantém esses objetos sincronizados com o código do sistema. Isso significa que quando os controladores são atualizados para um código mais recente, as alterações em qualquer um dos objetos acima causam uma atualização contínua dos clusters TKG existentes. Em suma, as alterações no código do sistema que afetam Supervisor resultam em atualizações contínuas de clusters TKG.

A tabela descreve as condições sob as quais você pode esperar uma atualização sem interrupção automatizada de clusters de carga de trabalho sempre que o Supervisor for atualizado.
Cenário de upgrade Descrição
Fazendo upgrade de qualquer versão do vSphere v7.x para qualquer versão do vSphere v7.x

Disparará uma atualização sem interrupção de todos os clusters TKG.
Fazendo upgrade de qualquer versão do vSphere v7.x para qualquer versão do vSphere v8.x Disparará uma atualização sem interrupção de todos os clusters TKG porque as seguintes alterações de código precisam ser propagadas:
  • Os provedores CAPI subjacentes precisam ser movidos de CAPW para CAPV
  • Migrar os clusters de clusters CAPI sem classes para um cluster CAPI elegante
Fazendo upgrade da versão vSphere v8.0 GA para a versão vSphere 8.0 MP1 ou posterior Disparará uma atualização sem interrupção dos clusters TKG especificados se qualquer um dos seguintes casos se aplicar:
  • Qualquer cluster TKG que estava usando configurações de proxy com uma lista noProxy não vazia.
  • Todos os clusters TKG se o Habor Registry Service integrado tiver sido ativado em Supervisor.
Além disso, alterar a Biblioteca de Conteúdo que hospeda as imagens TKR pode acionar atualizações contínuas de clusters TKG. A adição de novas imagens, por meio de uma assinatura ou manualmente, não aciona uma atualização contínua de clusters TKG. No entanto, alterar a Biblioteca de Conteúdo e adicionar imagens com nomes diferentes acionará uma atualização contínua de todos os clusters TKG.

Por exemplo, considere um cenário em que você está usando uma Biblioteca de Conteúdo Assinado que usa automaticamente os nomes OVA definidos pelo sistema. Em seguida, você alterna para uma Biblioteca de Conteúdo Local e a preenche com os mesmos OVAs, mas atribui a eles nomes diferentes. Isso acionará uma atualização sem interrupção de todos os clusters TKG porque a Biblioteca de Conteúdo de substituição tem os mesmos OVAs, mas com nomes diferentes definidos pelo usuário.

Verificando a compatibilidade do cluster do TKG 2 para atualização

Antes de atualizar um cluster de carga de trabalho, você deve verificar sua compatibilidade para atualização. Se um cluster for incompatível com a infraestrutura de destino, atualize o cluster antes de continuar com a atualização do sistema.

Você pode listar Tanzu Kubernetes releases e visualizar a compatibilidade e a capacidade de atualização para cada versão usando o seguinte comando. 
kubectl get tanzukubernetesreleases

A coluna COMPATIBLE indica se esse Tanzu Kubernetes release é compatível com o Supervisor atual. A coluna UPDATES AVAILABLE indica se há um upgrade do Kubernetes disponível e o próximo Tanzu Kubernetes releases recomendado a ser usado.

Essas mesmas informações também estão disponíveis usando kubectl get tkc <tkgs-cluster-name> e kubectl get cluster <tkgs-cluster-name>.