imagens de nó do containerd


Nesta página, você verá informações sobre imagens de nós que usam containerd como o ambiente de execução de contêiner nos nós do Google Kubernetes Engine (GKE).

Sobre o containerd

O ambiente de execução de contêiner é o software responsável pela execução de contêineres e abstrai o gerenciamento de contêineres para o Kubernetes. Há diferentes tempos de execução de contêiner.

O containerd é um ambiente de execução de contêiner padrão do setor compatível com o Kubernetes e usado por muitos outros projetos. O ambiente de execução containerd fornece a abstração de camadas que permite a implementação de um conjunto avançado de recursos, como o gVisor e o streaming de imagens, para ampliar a funcionalidade do GKE.

O ambiente de execução do containerd é considerado mais eficiente e seguro do que o ambiente de execução do Docker.

Como usar imagens de containerd em clusters do GKE

Quando você cria um novo cluster do GKE, um novo pool de nós em um cluster ou quando faz upgrade de um cluster, é possível usar uma imagem de nó do containerd. Os clusters do Autopilot do GKE sempre usam o Container-Optimized OS com containerd.

A tabela a seguir descreve as imagens de nó containerd compatíveis com base no modo de cluster e no sistema operacional do pool de nós:

Cluster mode SO do pool de nós Imagem do nó
Piloto automático Linux cos_containerd
Padrão Linux
  • cos_containerd
  • ubuntu_containerd
Padrão Windows Server

Essas imagens exigem a versão 1.21.1-gke.2200 ou posterior do GKE.

Como usar pods com privilégios para acessar o Docker

Se os usuários acessarem o Docker Engine em um nó com um pod privilegiado, atualize essas cargas de trabalho para que não haja dependência direta no Docker. Por exemplo, considere migrar o processo de extração de geração de registros e monitoramento do Docker Engine para complementos do sistema do GKE.

Como criar imagens de contêiner com o containerd

Não é possível usar o containerd para criar imagens de contêiner. As imagens do Linux com o containerd incluem o binário do Docker para que você possa usar o Docker para criar e enviar imagens por push. No entanto, não recomendamos o uso de contêineres individuais e nós locais para executar comandos para criar imagens.

O Kubernetes não tem conhecimento dos recursos de sistema usados pelos processos locais fora do escopo dele, e o plano de controle do Kubernetes não pode contabilizar esses processos ao alocar recursos. Isso pode prejudicar suas cargas de trabalho de recursos do GKE ou causar instabilidade no nó.

Considere realizar essas tarefas usando outros serviços fora do escopo do contêiner individual, como o Cloud Build, ou use uma ferramenta como o kaniko para criar imagens como uma carga de trabalho do Kubernetes.

Se nenhuma dessas sugestões funcionar para você e você entender os riscos, poderá continuar usando o Docker no nó local para criar imagens. É necessário enviar as imagens para um registro antes de usá-las em um Cluster do GKE. O Kubernetes com containerd não está ciente das imagens criadas localmente usando o Docker.

Como depurar contêineres em nós containerd

Para depurar o nó ou solucionar problemas dele no Linux, use o containerd na ferramenta de linha de comando portátil crictl, criada para os ambientes de execução de contêiner do Kubernetes. O crictl é compatível com funcionalidades comuns para visualizar contêineres e imagens, ler registros e executar comandos nos contêineres. Consulte o guia do usuário básico para um conjunto completo de recursos compatíveis e informações de uso.

Para os nós do Windows Server, o daemon do containerd é executado como um serviço do Windows chamado containerd.

Os registros estão disponíveis da seguinte forma:

  • Windows: C:\etc\kubernetes\logs\containerd.log
  • Linux: execute journalctl -u containerd

Também é possível ver os registros dos nós do Windows e do Linux no Explorador de registros em LOG NAME: "container-runtime".

Problemas conhecidos e solução de problemas

Para solucionar problemas e ver problemas conhecidos com soluções alternativas, consulte Solução de problemas no ambiente de execução do contêiner.

A seguir