Esta página foi traduzida pela API Cloud Translation.

Migrar nós para o containerd 2

Autopilot Standard

Os clusters do Google Kubernetes Engine (GKE) usam imagens de nó conteinerizadas com todos os nós de trabalho que executam a versão 1.24 e mais recentes. Os nós de trabalho usam uma versão específica do containerd, com base na versão do GKE:

Os nós que executam o GKE 1.32 ou versões anteriores, com imagens de nó do containerd, usam o containerd 1.7 ou versões anteriores.
Os nós que executam o GKE 1.33 usam o containerd 2.0.

Quando os nós do GKE são atualizados da versão 1.32 para a 1.33, eles migram do uso do containerd 1.7 para a nova versão principal, o containerd 2.0. Não é possível mudar a versão do containerd que uma versão do GKE usa.

Pule esta página se você souber que suas cargas de trabalho são executadas conforme o esperado no containerd 2.

Como o GKE está fazendo a transição para o containerd 2

Analise o cronograma a seguir para entender como o GKE está fazendo a transição de clusters atuais para usar o containerd 2:

Com a versão secundária 1.32, o GKE usa o containerd 1.7. O containerd 1.7 descontinua as imagens do esquema 1 do Docker e a API Container Runtime Interface (CRI) v1alpha2. Para saber mais sobre outros recursos descontinuados em versões anteriores, consulte Propriedades de configuração descontinuadas.
Com a versão secundária 1.33, o GKE usa o containerd 2.0, que remove o suporte para imagens do esquema 1 do Docker e a API CRI v1alpha2.
As seguintes propriedades de configuração do containerd no plug-in CRI foram descontinuadas e serão removidas no containerd 2.1, com uma versão do GKE ainda a ser anunciada: registry.auths, registry.configs, registry.mirrors.

Para saber o tempo aproximado dos upgrades automáticos para versões secundárias mais recentes, como 1.33, consulte a Programação estimada para canais de lançamento.

Impacto da transição para o containerd 2

Leia a próxima seção para entender o impacto dessa transição para o containerd 2.

Upgrades automáticos pausados

O GKE pausa os upgrades automáticos para a versão 1.33 quando detecta que um cluster usa os recursos descontinuados. No entanto, se os nós do cluster usarem esses recursos, recomendamos criar uma exclusão de manutenção para evitar upgrades de nós. A exclusão de manutenção garante que seus nós não sejam atualizados se o GKE não detectar o uso.

Depois de migrar do uso desses recursos, se a versão 1.33 for um upgrade automático para os nós do cluster e não houver outros fatores bloqueando os upgrades automáticos, o GKE vai retomar os upgrades menores automáticos para a versão 1.33. Para pools de nós de cluster padrão, também é possível fazer o upgrade manual do pool de nós.

Fim do suporte e o impacto de não se preparar para a migração

O GKE pausa os upgrades automáticos até o fim do suporte padrão. Se o cluster estiver registrado no canal estendido, os nós poderão permanecer em uma versão até o fim do suporte estendido. Para mais detalhes sobre upgrades automáticos de nós após o fim do suporte, consulte Upgrades automáticos após o fim do suporte.

Se você não migrar esses recursos, quando a versão 1.32 chegar ao fim do suporte e os nós do cluster forem atualizados automaticamente para a versão 1.33, poderá ocorrer um dos seguintes problemas com os clusters:

As cargas de trabalho que usam imagens do esquema 1 do Docker falham.
Os apps que chamam a API CRI v1alpha2 apresentam falhas ao fazer chamadas para a API.

Migrar de recursos descontinuados

Leia o conteúdo a seguir para entender como migrar de recursos descontinuados com o containerd 2.

Migrar de imagens do esquema 1 do Docker

Identifique as cargas de trabalho que usam imagens que precisam ser migradas e migre essas cargas de trabalho.

Encontrar imagens para migrar

Você pode usar ferramentas diferentes para encontrar imagens que precisam ser migradas.

Usar o Cloud Logging.

Use a consulta a seguir no Cloud Logging para verificar os registros do containerd e encontrar imagens do Docker Schema 1 no cluster:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Se mais de 30 dias se passaram desde que a imagem foi extraída, talvez você não encontre os registros dela.

Use o comando `ctr` diretamente em um nó

Para consultar um nó específico e retornar todas as imagens não excluídas que foram extraídas como Esquema 1, execute o comando a seguir em um nó:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Esse comando pode ser útil se, por exemplo, você estiver solucionando problemas em um nó específico e não encontrar entradas de registro no Cloud Logging porque já se passaram mais de 30 dias desde que a imagem foi extraída.

Usar a ferramenta de código aberto `crane`

Também é possível usar ferramentas de código aberto, como o crane, para verificar imagens.

Execute o comando crane a seguir para verificar a versão do esquema de uma imagem:

crane manifest $tagged_image | jq .schemaVersion

Preparar cargas de trabalho

Para preparar cargas de trabalho que executam imagens do esquema 1 do Docker, migre essas cargas de trabalho para imagens do esquema 2 do Docker ou da Iniciativa de contêineres abertos (OCI, na sigla em inglês). Considere as seguintes opções de migração:

Encontre uma imagem substituta:talvez você encontre uma imagem de código aberto disponível publicamente ou fornecida pelo fornecedor.
Converter a imagem atual:se você não encontrar uma imagem de substituição, converta as imagens do esquema 1 do Docker em imagens OCI seguindo estas etapas:
1. Extraia a imagem do Docker para o containerd, que a converte automaticamente em uma imagem OCI.
2. Envie a nova imagem OCI para o registro.

Migrar da API CRI v1alpha2

A API CRI v1alpha2 foi removida no Kubernetes 1.26. Identifique as cargas de trabalho que acessam o soquete do containerd e atualize esses aplicativos para usar a API v1.

Identificar cargas de trabalho

É possível usar técnicas diferentes para identificar as cargas de trabalho que precisam ser migradas.

Usar o kubectl

O comando a seguir ajuda a encontrar cargas de trabalho que acessam o soquete containerd. Esse comando retorna cargas de trabalho que montam diretórios hostPath que incluem o soquete. Essa consulta pode levar a falsos positivos porque algumas cargas de trabalho montam esses diretórios ou outros diretórios filhos, mas não acessam o soquete do contêiner.

Execute este comando:

kubectl get pods --all-namespaces -o json | jq -r '.items[] |
select(.spec.volumes[]? | select(.hostPath.path? and (.hostPath.path |
startswith("/run") or startswith("/var/run") or . == "/"))) |
.metadata.namespace + "/" + .metadata.name'

Verificar o código do aplicativo

Verifique o código do aplicativo para saber se ele está importando as bibliotecas de cliente da API CRI v1alpha2.

Por exemplo, confira o seguinte código golang:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

Aqui, o aplicativo importa a biblioteca v1alpha2 e a usa para emitir RPCs. Se os RPCs usarem a conexão com o soquete containerd, esse aplicativo fará com que o GKE pause os upgrades automáticos do cluster.

Siga estas etapas para pesquisar e atualizar o código do aplicativo:

Identifique aplicativos golang problemáticos executando o comando a seguir para procurar o caminho de importação v1alpha2:
```
  grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```
Se a saída desse comando mostrar que a biblioteca v1alpha2 é usada no arquivo, você precisará atualizar o arquivo.

Por exemplo, substitua o seguinte código do aplicativo:
```
  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
```

Atualize o código para usar a v1:

  runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"