Como usar uma imagem de nó com containerd

Nesta página, você terá mais informações sobre como usar o Container-Optimized OS com containerd (cos_containerd) e o Ubuntu com containerd (ubuntu_containerd) em nós do Google Kubernetes Engine (GKE). Com as imagens cos_containerd e ubuntu_containerd, você usa containerd como o ambiente de execução de contêiner em seu cluster do GKE.

Como usar imagens de containerd em clusters do GKE

Selecione cos_containerd ou ubuntu_containerd como o tipo de imagem ao criar um novo cluster do GKE, criar um novo pool de nós em um cluster atual ou atualizar um cluster atual do GKE. Ambas as imagens exigem v1.14.3 ou superior.

Como executar comandos docker em nós containerd

O Docker ainda está disponível em cada nó containerd, mas o Kubernetes usa o containerd como o ambiente de execução de contêiner. Como o Docker não gerencia contêineres do Kubernetes em nós, não é possível visualizar ou interagir com seus contêineres usando comandos do Docker ou a API do Docker.

Solução de problemas de contêineres em nós containerd

Para inspecionar ou resolver problemas nos seus contêineres, use o crictl pré-instalado. O é portátil em todos os ambientes de execução compatíveis com a especificação da interface de ambiente de execução de contêiner (CRI, na sigla em inglês). crictl é a ferramenta recomendada para interagir com o containerd e o Docker Engine. Acesse o Guia do usuário sobre crictl (em inglês) para mais informações.

Como acessar o Docker Engine a partir de pods privilegiados

Atualmente, alguns usuários acessam o Docker Engine em um nó a partir de pods privilegiados. É recomendável atualizar suas cargas de trabalho para que elas não dependam diretamente do Docker. Por exemplo, se você atualmente extrai registros de aplicativos ou dados de monitoramento do Docker Engine, considere o uso de complementos do sistema do GKE para criação de registros e monitoramento.

Como criar imagens

O containerd não é compatível com a criação de imagens porque o recurso não é compatível com o Kubernetes.

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ó. Por isso, não é recomendado executar comandos em nós locais. Em vez disso, pense em 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 (em inglês) para criar imagens como uma carga de trabalho do Kubernetes.

Se nenhuma dessas sugestões funcionar e você entender os riscos, continue a usar o Docker para criar imagens. É preciso enviar as imagens para um registro antes de tentar usá-las em um cluster do GKE. O Kubernetes não tem conhecimento das imagens criadas localmente.

A seguir

Saiba mais sobre a integração de containerd no comunicado do Kubernetes 1.11 (em inglês). Para ver ainda mais informações, acesse a documentação do containerd e dos plug-ins de CRI (ambas em inglês).

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine