☰

Kubernetes preso no ContainerCreating

tag-icon • tag-icon kubernetes
Kubernetes preso no ContainerCreating

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

Responder1

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

Responder2

Mais informações poderão 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 possuem 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]

Responder3

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

  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)

Então, 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 o download começar.

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 em \pauseestado 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 em minikube e usando VPN, o docker poderá usar sua VPN viaviolinista. Ou seja, o docker estará conectado ao ip:port do fiddler e o fiddler estará conectado à VPN. Caso contrário, a VPN não será compartilhada entre seu host e a VM do minikube.

Responder4

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

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

contra

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

capitalizar esse m faz uma grande diferença no uso de recursos. Fiquei preso no ContainerCreating porque não havia fornecido memória suficiente para meu contêiner.

informação relacionada