Atualizando uma versão do Tanzu Kubernetes depois que a especificação do cluster é convertida na API do Tanzu Kubernetes Grid Service v1alpha2

Para atualizar a versão do Tanzu Kubernetes após a especificação do cluster ter sido convertida para a API v1alpha2, o que normalmente é feito alterando a versão da versão do Tanzu Kubernetes, pode ser necessário fazer um pré-processamento da especificação para evitar erros.

Conversão automática de especificações de cluster

Para atualizar seu ambiente do vSphere with Tanzu para a API Tanzu Kubernetes Grid Service v1alpha2, você atualiza o Supervisor Cluster no qual o serviço é executado.

Quando o Tanzu Kubernetes Grid Service estiver executando a API v1alpha2, o sistema converterá automaticamente todas as especificações de cluster Tanzu Kubernetes existentes do formato v1alpha1 para o formato v1alpha2. Durante o processo de conversão automática, o sistema cria e preenche os campos esperados para cada manifesto de cluster. Adições e depreciações de API lista os campos de especificação do cluster que são novos e obsoletos na API v1alpha2.

Para atualizar a versão de lançamento do Tanzu Kubernetes para um cluster cujo manifesto foi convertido automaticamente para o formato v1alpha2, você precisa realizar um pré-processamento manual para evitar erros. Exemplos de atualização de cluster lista várias opções.

Adições e depreciações de API

A tabela lista as configurações de especificação de cluster que foram descontinuadas na API v1alpha2 e substituídas por novas configurações.

Configurações obsoletas	Novas configurações	Comentários
`spec.distribution.version` `spec.distribution.fullVersion`	`spec.topology.controlPlane.tkr.refernece.name` `spec.topology.nodePools[*].tkr.reference.name`	Deve usar o formato TKR NAME. Veja os exemplos.
`spec.topology.workers`	`spec.topology.nodePools[*]`	Em um cluster convertido, o bloco `spec.topology.workers` se torna `spec.topology.nodePools[0]`. A primeira entrada na lista `nodePools` é `name: workers`.
`spec.topology.controlPlane.count` `spec.topology.workers.count`	`spec.topology.controlPlane.replicas` `spec.topology.nodePools[*].replicas`	`count` é substituído por `replicas`
`spec.topology.controlPlane.class` `spec.topology.workers.class`	`spec.topology.controlPlane.vmClass` `spec.topology.nodePools[*].vmClass`	`class` é substituído por `vmClass`
N/D	`spec.topology.nodePools[*].labels`	Valores de par de chaves opcionais para organizar e categorizar objetos; rótulos são propagados para os nós criados
N/D	`spec.topology.nodePools[*].taints`	Taints opcionais para registrar os nós; As impurezas definidas pelo usuário são propagadas para os nós criados

O formato TKR NAME é obrigatório

Além dos campos spec.distribution.version que estão sendo preteridos, o formato de DISTRIBUIÇÃO para especificar a versão de lançamento do Tanzu Kubernetes não é suportado. Isso significa que você não pode usar os seguintes formatos de cadeia de caracteres para fazer referência à versão de destino: 1.21.2+vmware.1-tkg.1.ee25d55, 1.21.2 e 1.21.

Ao fazer referência à versão de lançamento do Tanzu Kubernetes em uma especificação de cluster de API v1alpha2, você deve usar o formato TKR NAME, não o formato obsoleto DISTRIBUTION. Embora o formato obsoleto seja exibido na coluna ATUALIZAÇÕES DISPONÍVEIS, o único formato com suporte é aquele listado na coluna NOME DO TKR.

kubectl get tanzukubernetescluster
NAMESPACE        NAME            CONTROL PLANE   WORKER   TKR NAME                             AGE    READY   TKR COMPATIBLE   UPDATES AVAILABLE
tkgs-cluster-1   test-cluster    3               3        v1.21.2---vmware.1-tkg.1.ee25d55     38h    True    True             [1.21.2+vmware.1-tkg.1.ee25d55]

Exemplos de atualização de cluster

Como alterar o spec.distribution.version é a maneira mais comum de acionar uma atualização contínua do cluster (consulte Atualizar Tanzu Kubernetes clusters) e esse campo está obsoleto na API v1alpha2, há algumas considerações a serem feitas e algumas recomendações de pré-processamento a seguir para evitar possíveis problemas de atualização do cluster.

Os exemplos a seguir demonstram como atualizar a versão de um cluster do Tanzu Kubernetes que foi provisionado usando a API v1alpha1 para um sistema que está executando a API v1alpha2.

Exemplo de atualização de cluster 1: usar uma única referência de nome TKR no plano de controle

A abordagem recomendada é remover todos os blocos de nodePools[*].tkr.reference.name da especificação convertida e atualizar o controlPlane.tkr.reference.name com o NOME do TKR da versão de destino. Nesse caso, a mesma versão de Tanzu Kubernetes é propagada para todos os nós nodePools[*].

No futuro, as versões de lançamento do Tanzu Kubernetes podem ser diferentes entre controlPlane e nodePools[*]. Atualmente, no entanto, todas as versões em um cluster devem corresponder, portanto, colocar uma única referência de TKR NAME em controlPlane é suficiente.

Por exemplo:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example1
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Exemplo de atualização de cluster 2: usar uma referência de NOME do TKR para cada pool de nós

O segundo exemplo é colocar o NOME do TKR no bloco tkr.reference.name para as topologias controlPlane e nodePools[*].

Essa abordagem tem a vantagem de estar pronta para versões futuras quando a versão Tanzu Kubernetes pode ser diferente entre os pools de nós. Atualmente, eles devem corresponder.

Por exemplo:

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example2
  namespace: tkgs-cluster-ns
spec:
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
      tkr:
        reference:
          name: v1.21.2---vmware.1-tkg.1.ee25d55

Exemplo de atualização de cluster 3: usar campos de distribuição obsoletos

A opção final é usar os campos obsoletos spec.distribution.fullVersion e spec.distribution.version e remover manualmente todos os blocos de tkr.reference.name. Você deve incluir ambos os campos com um usando o formato TKR NAME e o outro anulado. Atalhos de versão como v1.21.2 e v1.21 não são compatíveis.

Observação: Para a versão Tanzu Kubernetes no Ubuntu, não há suporte para o uso de spec.distribution.version.

O exemplo a seguir usa o fullVersion com o NOME do TKR e um valor nulo (vazio) no campo version. Todas as tkr.reference.name entradas são removidas.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3a
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: v1.21.2---vmware.1-tkg.1.ee25d55
    version: ""
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium

Como alternativa, você pode usar o campo version com o NOME do TKR e um valor nulo (vazio) no campo fullVersion. Mesmo que você esteja usando o campo version, os atalhos de versão não são compatíveis. Todas as tkr.reference.name entradas são removidas.

apiVersion: run.tanzu.vmware.com/v1alpha2
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-update-example3b
  namespace: tkgs-cluster-ns
spec:
  distribution:
    fullVersion: ""
    version: v1.21.2---vmware.1-tkg.1.ee25d55
  settings:
    network:
      cni:
        name: antrea
      pods:
        cidrBlocks:
        - 192.0.2.0/16
      serviceDomain: cluster.local
      services:
        cidrBlocks:
        - 198.51.100.0/12
  topology:
    controlPlane:
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium
    nodePools:
    - name: workers
      replicas: 3
      storageClass: vwt-storage-policy
      vmClass: best-effort-medium