Kubernetes preso no ContainerCreating

100

Um pod no meu cluster Kubernetes fica preso em "ContainerCreating" após executar uma criação. Como vejo os logs desta operação para diagnosticar por que está bloqueada? kubectl logsparece não funcionar, pois o contêiner precisa estar em um estado não pendente.

kubernetes

— four43
fonte

kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/… é a documentação sobre as possíveis fases. Infelizmente ele não inclui ContainerCreating...

— Xiong Chiamiov

Respostas:

126

kubectl describe podslistará todos os eventos associados ao pod, incluindo o recebimento de imagens e o início de contêineres. Pode ser de ajuda.

— Sreekanth Pothanis
fonte

e se o contêiner travasse no ContainerCreating sem nenhum evento? para mim, os eventos são mostrados como "Nenhum evento".

— 2626 Bob

Alguns eventos parecem demorar um pouco para aparecer. Por exemplo, um tempo limite tentando montar um disco para mim leva cerca de 2 minutos antes de aparecer como um evento.

— 28816 jwadsack

Isso acontece quando você está usando segredos e eles não são encontrados (como um erro de digitação no yaml ou você esqueceu de criá-lo antes). Para quase todos os outros erros possíveis, obtém os estados CrashLoopback ou Error, mas com segredos fica preso no ContainerCreating, se você descrever o pod, verá no final uma mensagem dizendo que o segredo não foi encontrado, mas mal diz nada sobre o problema.

— Danius 31/10/16

Sim, geralmente você não tem nenhum evento antes que ele comece a fazer alguma coisa.

— Erikbwork 10/05

Aconteceu comigo esta manhã e foi um erro de digitação em um hostPath para um volume. Yay teclado pegajoso.

— Joe Block

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

minikube stop
minikube delete
export http_proxy=http://user:pass@ip:port
export https_proxy=http://user:pass@ip:port
export no_proxy=192.168.99.0/24

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

export no_proxy=$no_proxy,$(minikube ip)
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 à Internet. Desde que as imagens docker necessários são da ordem de 100 MB, ambos os contentores Docker e vagens Kubernetes permaneceu em \pausee ContainerCreatingafirma por 30 minutos.

Para verificar se a janela de encaixe 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, esvazie.

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

— user477273
fonte

Ficou com esse bug hoje. Ainda não tenho certeza do que causou isso. As coisas estavam funcionando bem em um minuto e no seguinte, esse problema surgiu. Obrigado pela correção. Funcionou para mim.

— Jim

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

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

recursos: limites: CPU: 1000m de memória: 1024m solicitações: CPU: 1000m de 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 fornecido memória suficiente ao meu contêiner.

— Luis Felipe Moura Pereira De S
fonte