Solução de problemas do ambiente de execução do contêiner

---

Este documento fornece etapas de solução de problemas comuns que você pode encontrar com o ambiente de execução do contêiner nos nós do Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Os caminhos de montagem com letras simples no Drive falham nos pools de nós do Windows com Containerd

Esse problema foi resolvido na versão 1.6.6 e mais recentes do containerd.

Os clusters do GKE que executam pools de nós do Windows Server que usam o ambiente de execução do containerd antes da versão 1.6.6 podem ter erros ao iniciar contêineres como o seguinte:

failed to create containerd task : CreateComputeSystem : The parameter is incorrect : unknown

Para saber mais, consulte o problema 6589 do GitHub (link em inglês).

Solução

Para resolver esse problema, faça upgrade dos pools de nós para as versões mais recentes do GKE que usam o ambiente de execução do containerd versão 1.6.6 ou superior.

Imagens de contêiner com linhas de comando CMD ou ENTRYPOINT pré-codificadas que não são de matriz falham em pools de nós do Windows com containerd

Esse problema foi resolvido na versão 1.6 e mais recentes do containerd.

Os clusters do GKE que executam pools de nós do Windows Server que usam o ambiente de execução de contêiner 1.5.X podem apresentar erros ao iniciar contêineres como o seguinte:

failed to start containerd task : hcs::System::CreateProcess : The system cannot find the file specified.: unknown

Para saber mais, consulte o problema 5067 e o problema 6300 do GitHub (links em inglês).

Solução

Para resolver esse problema, faça upgrade dos pools de nós para as versões mais recentes do GKE que usam o ambiente de execução do containerd versão 1.6.6 ou superior.

Os volumes de imagem de contêiner com caminhos inexistentes ou caminhos semelhantes ao Linux (barra) falham nos pools de nós do Windows com Containerd

Esse problema foi resolvido na versão 1.6 e mais recentes do containerd.

Os clusters do GKE que executam pools de nós do Windows Server que usam o ambiente de execução de contêiner 1.5.X podem apresentar erros ao iniciar contêineres como o seguinte:

failed to generate spec: failed to stat "<volume_path>": CreateFile : The system cannot find the path specified.

Para saber mais, consulte o problema 5671 do GitHub (link em inglês).

Solução

Para resolver esse problema, faça upgrade dos pools de nós para as versões mais recentes do GKE que usam o ambiente de execução do containerd versão 1.6.x ou superior.

/etc/mtab: arquivo ou diretório não encontrado

Por padrão, o ambiente de execução do contêiner do Docker preenche esse link simbólico no contêiner, mas o ambiente de execução do contêiner não tem.

Para saber mais, consulte o problema 2419 do GitHub (link em inglês).

Solução

Para resolver esse problema, crie manualmente o link simbólico /etc/mtab durante a criação da imagem.

ln -sf /proc/mounts /etc/mtab

Erro de extração de imagem: não é um diretório

Versões afetadas do GKE: todas

Quando você cria uma imagem com o kaniko, ela pode não ser extraída com containerd com a mensagem de erro "não é um diretório". Esse erro acontecerá se a imagem for criada de uma maneira especial: quando um comando anterior remove um diretório e o próximo comando recria os mesmos arquivos nesse diretório.

O exemplo do Dockerfile a seguir com npm que ilustra esse problema.

RUN npm cache clean --force
RUN npm install

Para saber mais, consulte o problema 4659 do GitHub (link em inglês).

Solução

Para resolver esse problema, crie sua imagem usando docker build, que não é afetado por esse problema.

Se docker build não for uma opção para você, combine os comandos em um. O exemplo do Dockerfile a seguir combina RUN npm cache clean --force e RUN npm install:

RUN npm cache clean --force && npm install

Algumas métricas do sistema de arquivos estão ausentes e o formato das métricas é diferente

Observação: esse problema não afeta clientes que usam o Cloud Monitoring.

Versões afetadas do GKE: todas

O endpoint /metrics/cadvisor do Kubelet fornece métricas do Prometheus, conforme documentado em Métricas de componentes do sistema do Kubernetes. Se você instalar um coletor de métricas que depende desse endpoint, talvez veja os seguintes problemas:

• O formato das métricas no nó do Docker é k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>, mas o formato no nó do containerd é <container-id>.

• Algumas métricas do sistema de arquivos estão ausentes no nó containerd, da seguinte maneira:

  container_fs_inodes_free
  container_fs_inodes_total
  container_fs_io_current
  container_fs_io_time_seconds_total
  container_fs_io_time_weighted_seconds_total
  container_fs_limit_bytes
  container_fs_read_seconds_total
  container_fs_reads_merged_total
  container_fs_sector_reads_total
  container_fs_sector_writes_total
  container_fs_usage_bytes
  container_fs_write_seconds_total
  container_fs_writes_merged_total
  

Solução

É possível atenuar esse problema usando o cAdvisor como um daemonset independente.

1. Encontre a versão mais recente do cAdvisor com o padrão de nome vX.Y.Z-containerd-cri (por exemplo, v0.42.0-containerd-cri).
2. Siga as etapas em cAdvisor Kubernetes Daemonset para criar o daemonset.
3. Aponte o coletor de métricas instalado para usar o endpoint /metrics do cAdvisor, que fornece o conjunto completo de métricas de contêiner do Prometheus.

Alternativas

1. Migre sua solução de monitoramento para o Cloud Monitoring, que fornece o conjunto completo de métricas de contêiner.
2. Colete métricas da API de resumo do Kubelet com um endpoint /stats/summary.

As operações baseadas em anexação não funcionam corretamente após reinicializações do ambiente de execução do contêiner no GKE Windows

Versões afetadas do GKE: 1.21 a 1.21.5-gke.1802, 1.22 a 1.22.3-gke.700

Os clusters do GKE que executam pools de nós do Windows Server que usam o ambiente de execução containerd (versão 1.5.4 e 1.5.7-gke.0) podem ter problemas se o ambiente de execução do contêiner for reiniciado à força, com operações anexadas para contêineres em execução existentes não conseguir vincular a E/S novamente. O problema não causará falhas nas chamadas de API, mas os dados não serão enviados ou recebidos. Isso inclui dados para anexar e registrar CLIs e APIs por meio do servidor de API do cluster.

Solução

Para resolver esse problema, faça upgrade para a versão corrigida do ambiente de execução do contêiner (1.5.7-gke.1) com versões mais recentes do GKE.

Os pods exibem a mensagem de erro failed to allocate for range 0: no IP addresses available in range set

Versões do GKE afetadas: 1.24.6-gke.1500 ou anterior, 1.23.14-gke.1800 ou anterior e 1.22.16-gke.2000 ou anterior

Os clusters do GKE que executam pools de nós que usam o containerd podem ter problemas de vazamento de IP e esgotar todos os IPs de pod em um nó. Um pod programado em um nó afetado exibe uma mensagem de erro semelhante a esta:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Para saber mais sobre o problema, consulte o problema 5438 e o problema 5768 do GitHub do containerd.

Há um problema conhecido no GKE Dataplane V2 que pode causar esse problema. No entanto, esse problema pode ser causados por outros fatores, incluindo runc travado.

Solução

Para resolver esse problema, siga as alternativas mencionadas em Soluções alternativas para clusters padrão do GKE para GKE Dataplane V2.

Diferença do comportamento da sondagem Exec quando a sondagem excede o tempo limite

Versões afetadas do GKE: todas

O comportamento da sondagem Exec em imagens do containerd é diferente do comportamento em imagens dockershim. Quando a sondagem de execução, definida para o pod, excede o limite de Kubernetes timeoutSeconds declarado, em imagens dockershim, ela é tratada como uma falha de sondagem. Em imagens de contêiner, os resultados da sondagem retornados após o limite timeoutSeconds declarado são ignorados.

Solução

No GKE, o gate de recurso ExecProbeTimeout está definido como false e não pode ser alterado. Para resolver esse problema, aumente o limite de timeoutSeconds para todas as sondagens de execução afetadas ou implemente a funcionalidade de tempo limite como parte da lógica de sondagem.

Resolver problemas com registros particulares

Nesta seção, apresentamos informações sobre a solução de problemas para configurações de registros particulares no containerd.

A extração de imagem falha com o erro x509: certificado assinado por autoridade desconhecida

Esse problema ocorre quando o GKE não consegue encontrar um certificado para um domínio de registro particular específico. Verifique esse erro no Cloud Logging usando a seguinte consulta:

1. Acesse a página do Explorador de registros no console do Google Cloud:

   Acessar o Explorador de registros

2. Execute esta consulta:

   ("Internal error pulling certificate" OR
   "Failed to get credentials from metadata server" OR
   "Failed to install certificate")
   

Para resolver esse problema, tente o seguinte:

1. No GKE Standard, abra o arquivo de configuração que existe no seguinte caminho:

   /etc/containerd/hosts.d/DOMAIN/config.toml
   

   Substitua DOMAIN pelo FQDN do registro.

2. Verifique se o arquivo de configuração contém o FQDN correto.

3. Verifique se o caminho para o certificado no campo secretURI do arquivo de configuração está correto.

4. Verifique se o certificado existe no Secret Manager.

Certificado ausente

Esse problema ocorre quando o GKE não consegue extrair o certificado do Secret Manager para configurar o containerd nos nós.

Para resolver esse problema, tente o seguinte:

1. Verifique se o nó afetado executa o Container-Optimized OS. Os nós do Ubuntu e do Windows não são aceitos.
2. No arquivo de configuração, verifique se o caminho para o secret no campo secretURI está correto.
3. Verifique se a conta de serviço do IAM do cluster tem as permissões corretas para acessar o secret.
4. Verifique se o cluster tem o escopo de acesso cloud-platform. Para instruções, consulte Verificar os escopos de acesso.

A opção de registro não seguro não está configurada para a rede local (10.0.0.0/8)

Versões afetadas do GKE: todas

Em imagens de contêiner, a opção de registro não seguro não está configurada para a rede local 10.0.0.0/8. Se você usa registros particulares não seguros, talvez encontre erros semelhantes aos seguintes:

pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "IMAGE_NAME": failed to do request: Head "IMAGE_NAME": http: server gave HTTP response to HTTPS client

Para resolver esse problema, tente o seguinte:

• Use o Artifact Registry.
• Configure o TLS nos registros particulares se essa opção for compatível com seu caso de uso. É possível usar um arquivo de configuração do containerd para dizer ao GKE que use certificados armazenados por você no Secret Manager a fim de acessar seu registro particular. Para instruções, consulte Acessar registros particulares com certificados de AC particulares.

Configurar DaemonSets privilegiados para modificar a configuração do containerd

Para clusters padrão, tente as etapas a seguir. Essa solução alternativa não está disponível no Autopilot porque os contêineres privilegiados são um risco à segurança. Se o ambiente estiver exposto à Internet, considere a tolerância de risco antes de implantar esta solução. Em todos os casos, recomendamos firmemente que você configure o TLS para o registro particular e use a opção do Secret Manager.

Cuidado: essa operação requer uma reinicialização do containerd, o que pode causar interrupções em cargas de trabalho que já estão em execução no nó.

1. Analise o seguinte manifesto:

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: insecure-registries
     namespace: default
     labels:
       k8s-app: insecure-registries
   spec:
     selector:
       matchLabels:
         name: insecure-registries
     updateStrategy:
       type: RollingUpdate
     template:
       metadata:
         labels:
           name: insecure-registries
       spec:
         nodeSelector:
           cloud.google.com/gke-container-runtime: "containerd"
         hostPID: true
         containers:
           - name: startup-script
             image: gcr.io/google-containers/startup-script:v1
             imagePullPolicy: Always
             securityContext:
               privileged: true
             env:
             - name: ADDRESS
               value: "REGISTRY_ADDRESS"
             - name: STARTUP_SCRIPT
               value: |
                 set -o errexit
                 set -o pipefail
                 set -o nounset
   
                 if [[ -z "$ADDRESS" || "$ADDRESS" == "REGISTRY_ADDRESS" ]]; then
                   echo "Error: Environment variable ADDRESS is not set in containers.spec.env"
                   exit 1
                 fi
   
                 echo "Allowlisting insecure registries"
                 grep -qxF '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]' /etc/containerd/config.toml || \
                   echo -e '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]\n  endpoint = ["http://'$ADDRESS'"]' >> /etc/containerd/config.toml
                 echo "Reloading systemd management configuration"
                 systemctl daemon-reload
                 echo "Restarting containerd..."
                 systemctl restart containerd

   No campo .spec.containers.env, substitua o valor REGISTRY_ADDRESS da variável ADDRESS pelo endereço do registro HTTP local no formato DOMAIN_NAME:PORT. Por exemplo,

   containers:
   - name: startup-script
     ...
     env:
     - name: ADDRESS
       value: "example.com:5000"
   

2. Implante o DaemonSet:

   kubectl apply -f insecure-registry-ds.yaml
   

O DaemonSet adiciona seu registro não seguro à configuração do containerd em cada nó.

O containerd ignora todos os mapeamentos de dispositivos para pods com privilégios

Versões afetadas do GKE: todas

Para pods privilegiados do Kubernetes, o ambiente de execução do contêiner ignora todos os mapeamentos de dispositivos que volumeDevices.devicePath passaram para ele e, em vez disso, disponibiliza todos os dispositivos no host para o contêiner em /dev.

O containerd vaza processos paliativos quando os nós estão sob pressão de E/S

Versões do GKE afetadas: 1.25.0 a 1.25.15-gke.1040000, 1.26.0 a 1.26.10-gke.1030000, 1.27.0 a 1.27.6-gke.1513000, além de 1.28.0 a 1.28.0 a 1.28.3-gke.1061000

Quando um nó do GKE está sob pressão de E/S, o containerd pode não conseguir excluir os processos containerd-shim-runc-v2 quando um pod é excluído, resultando em vazamentos de processos. Quando o vazamento ocorre em um nó, há mais processos containerd-shim-runc-v2 no nó do que o número de pods nele. Talvez você também note um aumento no uso de memória e CPU com PIDs extras. Para saber mais detalhes, consulte o problema do GitHub Corrigir um processo paliativo vazado devido a uma alta pressão de E/S (link em inglês).

Para resolver esse problema, faça upgrade dos nós para as seguintes versões ou mais recentes:

• 1.25.15-gke.1040000
• 1.26.10-gke.1030000
• 1.27.6-gke.1513000
• 1.28.3-gke.1061000

A família de endereços IPv6 está ativada em pods que executam o containerd

Versões afetadas do GKE: 1.18, 1.19 e de 1.20.0 a 1.20.9

A família de imagens IPv6 está ativada em pods em execução com o containerd. A imagem dockershim desativa o IPv6 em todos os pods, enquanto a imagem do Containerd não. Por exemplo, localhost é resolvido para o endereço IPv6 ::1 primeiro. Normalmente, isso não é um problema, mas pode resultar em um comportamento inesperado em alguns casos.

Solução

Para resolver esse problema, use explicitamente um endereço IPv4, como 127.0.0.1, ou configure um aplicativo em execução no pod para funcionar em ambas as famílias de endereços.

O provisionamento automático de nós provisiona apenas o Container-Optimized OS com pools de nós do Docker

Versões afetadas do GKE: 1.18, 1.19 e de 1.20.0 a 1.20.6-gke.1800

O provisionamento automático de nós permite o escalonamento automático de pools de nós com qualquer tipo de imagem compatível, mas só pode criar novos pools de nós. com o tipo de imagem Container-Optimized OS com Docker.

Solução

Para resolver esse problema, faça upgrade dos clusters do GKE para a versão 1.20.6-gke.1800 ou posterior. Nessas versões do GKE, o tipo de imagem padrão pode ser definido para o cluster.

Conflito com intervalo de endereços IP 172.17/16

Versões afetadas do GKE: de 1.18.0 a 1.18.18

O intervalo de endereços IP 172.17/16 é ocupado pela interface docker0 na VM do nó com o containerd ativado. O tráfego enviado para esse intervalo ou originado nele pode não ser roteado corretamente. Por exemplo, um pod pode não conseguir se conectar a um host conectado à VPN com um endereço IP em 172.17/16.

Métricas de GPU não coletadas

Versões afetadas do GKE: de 1.18.0 a 1.18.18

As métricas de uso de GPU não são coletadas ao usar o containerd como um ambiente de execução nas versões do GKE anteriores à 1.18.18.

Solução

Para resolver esse problema, faça upgrade dos clusters para a versão 1.18.18 ou mais recente do GKE.

Imagens com config.mediaType definido como application/octet-stream não podem ser usadas no containerd

Versões afetadas do GKE: todas

Imagens com config.mediaType definido como "application/octet-stream" não podem ser usadas no containerd. Para saber mais, consulte o problema 4756 do GitHub. Essas imagens não são compatíveis com a especificação da Open Container Initiative e são consideradas incorretas. Essas imagens funcionam com o Docker para fornecer compatibilidade com versões anteriores, mas em contêineres essas imagens não são compatíveis.

Sintoma e diagnóstico

Exemplo de erros nos registros do nó:

Error syncing pod <pod-uid> ("<pod-name>_<namespace>(<pod-uid>)"), skipping: failed to "StartContainer" for "<container-name>" with CreateContainerError: "failed to create containerd container: error unpacking image: failed to extract layer sha256:<some id>: failed to get reader from content store: content digest sha256:<some id>: not found"

O manifesto da imagem geralmente pode ser encontrado no registro em que está hospedado. Quando você tiver o manifesto, verifique config.mediaType para determinar se esse problema ocorreu:

"mediaType": "application/octet-stream",

Solução

Como a comunidade do containerd decidiu não oferecer suporte a essas imagens, todas as versões do containerd foram afetadas e não há correção. A imagem do contêiner precisa ser recriada com a versão 1.11 ou mais recente do Docker. É necessário garantir que o campo config.mediaType não esteja definido como "application/octet-stream".

Configuração da CNI não inicializada

Versões afetadas do GKE: todas

O GKE não cria nós durante um upgrade, redimensionamento ou outra ação.

Sintoma e diagnóstico

Exemplo de erro no Console do Google Cloud:

Error: "runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized".

Esse erro pode ocorrer nas seguintes situações:

• Durante a inicialização do nó nos arquivos de registro enquanto o GKE instala a configuração da CNI.
• Como um status de erro de nó no Console do Google Cloud se um webhook personalizado que intercepta o comando controlador DaemonSet para criar um pod tem erros. Isso impede que o GKE crie um pod netd ou calico-node. Se os pods netd ou calico-node forem iniciados enquanto o erro persistir, entre em contato com o suporte.

Solução

Para resolver esse problema, tente o seguinte:

• Aguarde a conclusão da instalação da configuração da CNI pelo GKE.
• Remova os webhooks configurados incorretamente.
• Configure webhooks para ignorar os pods do sistema.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.