Início / server / Perguntas / 728727
Accepted
four43
Asked: 2015-10-14 12:40:43 +0800 CST

Kubernetes travado no ContainerCreating

  • 772

Um pod no meu cluster Kubernetes está preso em "ContainerCreating" depois de executar um create. Como vejo os logs dessa operação para diagnosticar por que ela está travada? kubectl logsnão parece funcionar, pois o contêiner precisa estar em um estado não pendente.

kubernetes

5 respostas

  1. Best Answer

    kubectl describe podslistará alguns (provavelmente a maioria, mas não todos) dos eventos associados ao pod, incluindo extração de imagens, inicialização de contêineres.

    • 279

  2. Mais informações podem ser fornecidas nos eventos.

    kubectl get events --all-namespaces  --sort-by='.metadata.creationTimestamp'

    No entanto, observe que a classificação de eventos pode não funcionar corretamente devido a este bug: https://github.com/kubernetes/kubernetes/issues/29838

    Alternativamente:

    A partir do Kubernetes 1.18, todos os novos objetos têm metadados para aplicação no lado do servidor, o que nos dá uma nova maneira de classificar eventos:

    kubectl get events --sort-by=".metadata.managedFields[0].time"

    De: https://github.com/kubernetes/kubernetes/issues/29838#issuecomment-789660546

    No meu caso, tive um evento relacionado a um pod:

    default       13s         Warning   FailedMount               Pod          Unable to mount volumes for pod "restore-db-123-1-5f24s_default(9b7df264-2976-11ea-bb8f-42010a9a002c)": timeout expired waiting for volumes to attach or mount for pod "default"/"restore-db-123-1-5f24s". list of unmounted volumes=[nfsv]. list of unattached volumes=[nfsv default-token-hxrng]
    • 46

  3. No meu caso, o acesso do docker à internet foi bloqueado. Foi resolvido usando um proxy ( usando o comentário de sandylss ):

    1. minikube stop
    2. minikube delete
    3. export http_proxy=http://user:pass@ip:port
    4. export https_proxy=http://user:pass@ip:port
    5. export no_proxy=192.168.99.0/24
    6. minikube start --logtostderr --v=0 --bootstrapper=localkube --vm-driver hyperv 
  --hyperv-virtual-switch "Primary Virtual Switch" --docker-env HTTP_PROXY=$http_proxy \
  --docker-env HTTPS_PROXY=$https_proxy --docker-env NO_PROXY=$no_proxy
    7. export no_proxy=$no_proxy,$(minikube ip)
    8. export NO_PROXY=$no_proxy,$(minikube ip)

    Em seguida, para verificar se o docker tem acesso à internet, execute:

    $ docker pull tutum/hello-world

    no cluster (conecte-se ao cluster usando minikube ssh); interrompa o processo se ele iniciar o download.

    Meu segundo problema foi a conexão lenta com a internet. Como as imagens do docker necessárias são da ordem de 100 MB, os contêineres do docker e os pods do Kubernetes permaneceram nos \pauseestados ContainerCreatingpor 30 minutos.

    Para verificar se o docker está baixando as imagens, execute:

    $ ls -l /var/lib/docker/tmp

    no cluster, que mostra os arquivos de imagem temporários que estão sendo baixados, caso contrário, vazio.

    Se você estiver desenvolvendo no minikube e usando VPN, o docker pode usar sua VPN via fiddler . Ou seja, o docker será conectado ao ip:port do violinista e o violinista será conectado à VPN. Caso contrário, a VPN não é compartilhada entre seu host e a VM minikube.

    • 6

  4. A única vez que eu bati isso foi porque minhas declarações de recursos foram acidentalmente muito, muito pequenas.

    recursos: limites: CPU: 1000m memória: 1024M solicitações: CPU: 1000m memória: 1024M

    vs

    recursos: limites: CPU: 1000m memória: 1024m solicitações: CPU: 1000m memória: 1024m

    capitalizar que m faz uma diferença muito grande no uso de recursos. Eu estava preso no ContainerCreating porque não havia dado memória suficiente ao meu contêiner.

    • 3

  5. No meu caso, um pod ficou preso em ' ContainerCreating ' porque um pull de imagem do docker foi travado (algumas camadas foram baixadas, algumas ficaram presas em "download").

    $ kubectl get events --all-namespaces  --sort-by='.metadata.creationTimestamp'

    mostrou um evento "Puxando imagem"

    Tentei puxar essa imagem usando o docker image pull... e vi que estava travando.

    Descobriu-se que há um bug em pulls simultâneos de camadas. Alterar a configuração do docker para limitar a simultaneidade resolveu o problema.

    Adicionado isso à configuração do docker (no Windows, interface do usuário do docker-desktop, configurações, Docker Engine) para limitar a simultaneidade:

      "max-concurrent-downloads": 1,
  "max-concurrent-uploads": 1
    • 2

relate perguntas