Kubernetes atascado en ContainerCreating

Kubernetes atascado en ContainerCreating

Un pod en mi clúster de Kubernetes está bloqueado en "ContainerCreating" después de ejecutar una creación. ¿Cómo veo los registros de esta operación para diagnosticar por qué está bloqueada? kubectl logsno parece funcionar ya que el contenedor debe estar en un estado no pendiente.

Respuesta1

kubectl describe podslistaráalguno(probablemente la mayoría, pero no todos) de los eventos asociados con el pod, incluida la extracción de imágenes y el inicio de contenedores.

Respuesta2

Se podría proporcionar más información en los eventos.

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

Sin embargo, tenga en cuenta que es posible que la clasificación de eventos no funcione correctamente debido a este error:https://github.com/kubernetes/kubernetes/issues/29838


Alternativamente:

A partir de Kubernetes 1.18, todos los objetos nuevos tienen metadatos para aplicar en el lado del servidor, lo que nos brinda una nueva forma de ordenar eventos:

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

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


En mi caso tuve un evento relacionado con un 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]

Respuesta3

En mi caso, se bloqueó el acceso de Docker a Internet. Se resolvió usando un proxy (usando el comentario 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)

Luego, para comprobar si Docker tiene acceso a Internet, ejecute:

$ docker pull tutum/hello-world

en el clúster (conéctese al clúster usando minikube ssh); detenga el proceso si comienza a descargarse.

Mi segundo problema fue la conexión lenta a Internet. Dado que las imágenes de la ventana acoplable requeridas son del orden de 100 MB, tanto los contenedores de la ventana acoplable como los pods de Kubernetes permanecieron en los estados \pausey ContainerCreatingdurante 30 minutos.

Para comprobar si Docker está descargando las imágenes, ejecute:

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

en el clúster, que muestra los archivos de imagen temporales que se están descargando; de lo contrario, está vacío.

Si está desarrollando en minikube y usando VPN, Docker puede usar su VPN a través deviolinista. Es decir, Docker se conectará al puerto ip: de Fiddler y Fiddler se conectará a la VPN. De lo contrario, la VPN no se comparte entre su host y la máquina virtual minikube.

Respuesta4

La única vez que llegué a esto fue porque mis declaraciones de recursos fueron accidentalmente muy, muy pequeñas.

recursos: límites: cpu: 1000 m memoria: 1024 M solicitudes: cpu: 1000 m memoria: 1024 M

vs

recursos: límites: cpu: 1000 m memoria: 1024 m solicitudes: cpu: 1000 m memoria: 1024 m

capitalizar ese m hace una gran diferencia en el uso de recursos. Me quedé atrapado en ContainerCreating porque no le había dado suficiente memoria a mi contenedor.

información relacionada