@ kubernetes / sig-aws @ kubernetes / sig-scheduling

Por lo general, la limpieza del volumen y la red consume más tiempo en la terminación. ¿Puedes encontrar en qué fase está atascada tu pod? ¿Limpieza de volumen, por ejemplo?

Por lo general, la limpieza del volumen y la red consume más tiempo en la terminación.

Correcto. Siempre son sospechosos.

@igorleao También puedes probar kubectl delete pod xxx --now .

Hola @resouer y @dixudx
No estoy seguro. Mirando los registros de kubelet para un pod diferente con el mismo problema, encontré:

Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Releasing address using workloadID" Workload=my-pod-969733955-rbxhn
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Releasing all IPs with handle 'my-pod-969733955-rbxhn'"
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=warning msg="Asked to release address but it doesn't exist. Ignoring" Workload=my-pod-969733955-rbxhn workloadId=my-pod-969733955-rbxhn
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: time="2017-09-02T15:31:57Z" level=info msg="Teardown processing complete." Workload=my-pod-969733955-rbxhn endpoint=<nil>
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.496132    9620 qos_container_manager_linux.go:285] [ContainerManager]: Updated QoS cgroup configuration
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968147    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (spec.Name: "default-token-wrlv3") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968245    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-token-key" (spec.Name: "token-key") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968537    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-token-key\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968508761 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-token-key" (volume.spec.Name: "token-key") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968744    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-default-token-wrlv3\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968719924 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (volume.spec.Name: "default-token-wrlv3") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/default-token-wrlv3 /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_default-token-wrlv3.deleting~940140790: device or resource busy
--
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778742    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_default-token-wrlv3.deleting~940140790" (spec.Name: "wrapped_default-token-wrlv3.deleting~940140790") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778753    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~850807831" (spec.Name: "wrapped_token-key.deleting~850807831") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778764    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~413655961" (spec.Name: "wrapped_token-key.deleting~413655961") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778774    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~818780979" (spec.Name: "wrapped_token-key.deleting~818780979") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778784    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~348212189" (spec.Name: "wrapped_token-key.deleting~348212189") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778796    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~848395852" (spec.Name: "wrapped_token-key.deleting~848395852") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778808    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_default-token-wrlv3.deleting~610264100" (spec.Name: "wrapped_default-token-wrlv3.deleting~610264100") devicePath: ""
Sep 02 15:33:04 ip-172-16-30-208 kubelet[9620]: I0902 15:33:04.778820    9620 reconciler.go:363] Detached volume "kubernetes.io/secret/GUID-wrapped_token-key.deleting~960022821" (spec.Name: "wrapped_token-key.deleting~960022821") devicePath: ""
Sep 02 15:33:05 ip-172-16-30-208 kubelet[9620]: I0902 15:33:05.081380    9620 server.go:778] GET /stats/summary/: (37.027756ms) 200 [[Go-http-client/1.1] 10.0.46.202:54644]
Sep 02 15:33:05 ip-172-16-30-208 kubelet[9620]: I0902 15:33:05.185367    9620 operation_generator.go:597] MountVolume.SetUp succeeded for volume "kubernetes.io/secret/GUID-calico-token-w8tzx" (spec.Name: "calico-token-w8tzx") pod "GUID" (UID: "GUID").
Sep 02 15:33:07 ip-172-16-30-208 kubelet[9620]: I0902 15:33:07.187953    9620 kubelet.go:1824] SyncLoop (DELETE, "api"): "my-pod-969733955-rbxhn_container-4-production(GUID)"
Sep 02 15:33:13 ip-172-16-30-208 kubelet[9620]: I0902 15:33:13.879940    9620 aws.go:937] Could not determine public DNS from AWS metadata.
Sep 02 15:33:20 ip-172-16-30-208 kubelet[9620]: I0902 15:33:20.736601    9620 server.go:778] GET /metrics: (53.063679ms) 200 [[Prometheus/1.7.1] 10.0.46.198:43576]
Sep 02 15:33:23 ip-172-16-30-208 kubelet[9620]: I0902 15:33:23.898078    9620 aws.go:937] Could not determine public DNS from AWS metadata.

Como puede ver, este grupo tiene Calico para CNI.
Las siguientes líneas me llaman la atención:

Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: I0902 15:31:57.968245    9620 reconciler.go:201] UnmountVolume operation started for volume "kubernetes.io/secret/GUID-token-key" (spec.Name: "token-key") from pod "GUID" (UID: "GUID").
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968537    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-token-key\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968508761 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-token-key" (volume.spec.Name: "token-key") pod "GUID" (UID: "GUID") with: rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy
Sep 02 15:31:57 ip-172-16-30-208 kubelet[9620]: E0902 15:31:57.968744    9620 nestedpendingoperations.go:262] Operation for "\"kubernetes.io/secret/GUID-default-token-wrlv3\" (\"GUID\")" failed. No retries permitted until 2017-09-02 15:31:59.968719924 +0000 UTC (durationBeforeRetry 2s). Error: UnmountVolume.TearDown failed for volume "kubernetes.io/secret/GUID-default-token-wrlv3" (volume.spec.Name: "default-token-wrlv3") pod "GUID" (UID: "GUID") with: rename 

¿Existe una mejor manera de averiguar en qué fase se atasca un pod?

kubectl delete pod xxx --now parece funcionar bastante bien, pero realmente deseo descubrir su causa raíz y evitar la interacción humana.

rename /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/wrapped_token-key.deleting~818780979: device or resource busy

Parece que kubelet/mount no pudo montar configmap como un volumen debido a ese cambio de nombre de archivo.

@igorleao ¿Es reproducible? O simplemente no es tan estable, sucede ocasionalmente. Me he encontrado con tales errores antes, solo para asegurarme.

@dixudx sucede varias veces al día para un determinado clúster. Otros clústeres creados con la misma versión de kops y kubernetes, en la misma semana, funcionan bien.

@igorleao Como muestra el registro, el administrador de volumen no pudo eliminar el directorio secreto porque el dispositivo está ocupado.
¿Podría comprobar si el directorio /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key todavía está montado o no? ¡Gracias!

@igorleao ¿cómo se ejecuta kubelet? en contenedor? si es así, ¿puede publicar su unidad systemd o la configuración de la ventana acoplable para kubelet?

Vemos un comportamiento similar. Ejecutamos kubelet como contenedor y el problema se mitigó parcialmente montando /var/lib/kubelet como compartido (de forma predeterminada, la ventana acoplable monta el volumen como rslave). Pero aún vemos problemas similares, pero menos frecuentes. Actualmente sospecho que algunos otros montajes deberían hacerse de manera diferente (por ejemplo, /var/lib/docker o /rootfs )

@stormltf ¿Puede publicar la configuración de su contenedor de kubelet?

@stormltf está ejecutando kubelet en un contenedor y no usa la bandera --containerized (que hace algunos trucos con los montajes ). Lo que básicamente significa que todos los montajes que hace kubelet se realizarán en el espacio de nombres de montaje de contenedor. Lo bueno es que se volverán a proponer al espacio de nombres de la máquina host (ya que tiene / var / lib / kubelet como compartido), pero no estoy seguro de qué sucede si se elimina el espacio de nombres (cuando se elimina el contenedor de kubelet).

¿Puedes hacer lo siguiente para las vainas atascadas?

en el nodo donde se está ejecutando el pod

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• y lo mismo en el propio nodo mount | grep STUCK_POD_UUID .

Haga lo mismo con la vaina recién creada. Espero ver algunos /var/lib/kubelet montajes (por ejemplo, secreto predeterminado)

@stormltf , ¿reinició kubelet después de que se crearon los dos primeros pods?

@stormltf Puede intentar hacer /var/lib/docker y /rootfs como compartidos (que no veo en la inspección de su ventana acoplable, pero veo dentro del contenedor) mountpoint.

/ sig almacenamiento

Para algunos, podría ayudar. Estamos ejecutando kubelet en un contenedor docker con la bandera --containerized y pudimos resolver este problema montando /rootfs , /var/lib/docker y /var/lib/kubelet como montajes compartidos. Los montajes finales se ven así

      -v /:/rootfs:ro,shared \
      -v /sys:/sys:ro \
      -v /dev:/dev:rw \
      -v /var/log:/var/log:rw \
      -v /run/calico/:/run/calico/:rw \
      -v /run/docker/:/run/docker/:rw \
      -v /run/docker.sock:/run/docker.sock:rw \
      -v /usr/lib/os-release:/etc/os-release \
      -v /usr/share/ca-certificates/:/etc/ssl/certs \
      -v /var/lib/docker/:/var/lib/docker:rw,shared \
      -v /var/lib/kubelet/:/var/lib/kubelet:rw,shared \
      -v /etc/kubernetes/ssl/:/etc/kubernetes/ssl/ \
      -v /etc/kubernetes/config/:/etc/kubernetes/config/ \
      -v /etc/cni/net.d/:/etc/cni/net.d/ \
      -v /opt/cni/bin/:/opt/cni/bin/ \

Para más detalles. Esto no resuelve correctamente el problema, ya que por cada montura de enlace obtendrá 3 monturas dentro del contenedor kubelet (2 parásitos). Pero al menos el soporte compartido permite desmontarlos fácilmente con un solo disparo.

CoreOS no tiene este problema. Porque el uso rkt y no docker para el contenedor kubelet. En caso de que nuestro caso, kubelet se ejecute en Docker y cada montaje dentro del continer kubelet se proponga en /var/lib/docker/overlay/... y /rootfs es por eso que tenemos dos montajes de parásitos para cada volumen de montaje de enlace:

• uno de /rootfs en /rootfs/var/lib/kubelet/<mount>
• uno de /var/lib/docker en /var/lib/docker/overlay/.../rootfs/var/lib/kubelet/<mount>

-v /dev:/dev:rw 
-v /etc/cni:/etc/cni:ro 
-v /opt/cni:/opt/cni:ro 
-v /etc/ssl:/etc/ssl:ro 
-v /etc/resolv.conf:/etc/resolv.conf 
-v /etc/pki/tls:/etc/pki/tls:ro 
-v /etc/pki/ca-trust:/etc/pki/ca-trust:ro
-v /sys:/sys:ro 
-v /var/lib/docker:/var/lib/docker:rw 
-v /var/log:/var/log:rw
-v /var/lib/kubelet:/var/lib/kubelet:shared 
-v /var/lib/cni:/var/lib/cni:shared 
-v /var/run:/var/run:rw 
-v /www:/www:rw 
-v /etc/kubernetes:/etc/kubernetes:ro 
-v /etc/os-release:/etc/os-release:ro 
-v /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime:ro

Tengo el mismo problema con Kubernetes 1.8.1 en Azure: después de que se cambia la implementación y se inician los nuevos pods, los antiguos se bloquean al terminar.

Tengo el mismo problema en Kubernetes 1.8.2 en IBM Cloud. Una vez que se inician los nuevos pods, los antiguos se bloquean al terminar.

versión kubectl
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.2-1+d150e4525193f1", GitCommit:"d150e4525193f1c79569c04efc14599d7deb5f3e", GitTreeState:"clean", BuildDate:"2017-10-27T08:15:17Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

He usado kubectl delete pod xxx --now así como kubectl delete pod foo --grace-period=0 --force sin éxito.

Si la causa raíz sigue siendo la misma (montajes propuestos incorrectamente), entonces este es un error específico de la distribución en mi opinión.

Describa cómo ejecuta kubelet run en IBM Cloud. unidad systemd? ¿Tiene la bandera --containerized ?

se ejecuta con el indicador --containerized establecido en falso.

systemctl status kubelet.service kubelet.service - Kubernetes Kubelet Loaded: loaded (/lib/systemd/system/kubelet.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-11-19 21:48:48 UTC; 4 days ago

- bandera contenida: No

ok, necesito más información, consulte mi comentario anterior https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

y también muestre el contenido de /lib/systemd/system/kubelet.service y si hay algo sobre kubelet en /etc/systemd/system por favor comparta también.

En particular, si kubelet se ejecuta en la ventana acoplable, quiero ver todos los montajes de enlace -v .

Hoy me encontré con un problema que puede ser el mismo que el descrito, donde tuvimos pods en uno de nuestros sistemas de clientes que se atascaron en el estado de terminación durante varios días. También vimos los errores sobre "Error: UnmountVolume.TearDown falló para el volumen" con "dispositivo o recurso ocupado" repetido para cada uno de los pods atascados.

En nuestro caso, parece ser un problema con la ventana acoplable en los sistemas basados ​​en RHEL / Centos 7.4 cubiertos en este problema de moby: https://github.com/moby/moby/issues/22260 y este PR de moby: https: // github .com / moby / moby / pull / 34886 / archivos

Para nosotros, una vez que configuramos la opción sysctl fs.may_detach_mounts = 1 en un par de minutos, todos nuestros pods de terminación se limpiaron.

También me enfrento a este problema: los pods se atascaron en el estado de terminación en 1.8.3.

Registros de kubelet relevantes del nodo:

Nov 28 22:48:51 <my-node> kubelet[1010]: I1128 22:48:51.616749    1010 reconciler.go:186] operationExecutor.UnmountVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "58dc413c-d4d1-11e7-870d-3c970e298d91" (UID: "58dc413c-d4d1-11e7-870d-3c970e298d91")
Nov 28 22:48:51 <my-node> kubelet[1010]: W1128 22:48:51.616762    1010 util.go:112] Warning: "/var/lib/kubelet/pods/58dc413c-d4d1-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" is not a mountpoint, deleting
Nov 28 22:48:51 <my-node> kubelet[1010]: E1128 22:48:51.616828    1010 nestedpendingoperations.go:264] Operation for "\"kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw\" (\"58dc413c-d4d1-11e7-870d-3c970e298d91\")" failed. No retries permitted until 2017-11-28 22:48:52.616806562 -0800 PST (durationBeforeRetry 1s). Error: UnmountVolume.TearDown failed for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/58dc413c-d4d1-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "58dc413c-d4d1-11e7-870d-3c970e298d91" (UID: "58dc413c-d4d1-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/58dc413c-d4d1-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw: directory not empty
Nov 28 22:48:51 <my-node> kubelet[1010]: W1128 22:48:51.673774    1010 docker_sandbox.go:343] failed to read pod IP from plugin/docker: NetworkPlugin cni failed on the status hook for pod "<pod>": CNI failed to retrieve network namespace path: Cannot find network namespace for the terminated container "f58ab11527aef5133bdb320349fe14fd94211aa0d35a1da006aa003a78ce0653"

Kubelet se ejecuta como unidad systemd (no en contenedor) en Ubuntu 16.04.
Como puede ver, hubo un montaje en el servidor NFS y de alguna manera kubelet intentó eliminar el directorio de montaje porque considera que este directorio no está montado.

Volúmenes de especificaciones del pod:

volumes:
  - name: nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw
    nfs:
      path: /<path>
      server: <IP>
  - name: default-token-rzqtt
    secret:
      defaultMode: 420
      secretName: default-token-rzqtt

UPD : Me enfrenté a este problema antes también en 1.6.6

Experimentando lo mismo en Azure ...

NAME                        READY     STATUS        RESTARTS   AGE       IP             NODE
busybox2-7db6d5d795-fl6h9   0/1       Terminating   25         1d        10.200.1.136   worker-1
busybox3-69d4f5b66c-2lcs6   0/1       Terminating   26         1d        <none>         worker-2
busybox7-797cc644bc-n5sv2   0/1       Terminating   26         1d        <none>         worker-2
busybox8-c8f95d979-8lk27    0/1       Terminating   25         1d        10.200.1.137   worker-1
nginx-56ccc998dd-hvpng      0/1       Terminating   0          2h        <none>         worker-1
nginx-56ccc998dd-nnsvj      0/1       Terminating   0          2h        <none>         worker-2
nginx-56ccc998dd-rsrvq      0/1       Terminating   0          2h        <none>         worker-1

versión kubectl

Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

describir pod nginx-56ccc998dd-nnsvj

Name:                      nginx-56ccc998dd-nnsvj
Namespace:                 default
Node:                      worker-2/10.240.0.22
Start Time:                Wed, 29 Nov 2017 13:33:39 +0400
Labels:                    pod-template-hash=1277755488
                           run=nginx
Annotations:               kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"nginx-56ccc998dd","uid":"614f71db-d4e8-11e7-9c45-000d3a25e3c0","...
Status:                    Terminating (expires Wed, 29 Nov 2017 15:13:44 +0400)
Termination Grace Period:  30s
IP:
Created By:                ReplicaSet/nginx-56ccc998dd
Controlled By:             ReplicaSet/nginx-56ccc998dd
Containers:
  nginx:
    Container ID:   containerd://d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07
    Image:          nginx:1.12
    Image ID:       docker.io/library/nginx<strong i="12">@sha256</strong>:5269659b61c4f19a3528a9c22f9fa8f4003e186d6cb528d21e411578d1e16bdb
    Port:           <none>
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-jm7h5 (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  default-token-jm7h5:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-jm7h5
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:
  Type    Reason   Age   From               Message
  ----    ------   ----  ----               -------
  Normal  Killing  41m   kubelet, worker-2  Killing container with id containerd://nginx:Need to kill Pod

sudo journalctl -u kubelet | grep "nginx-56ccc998dd-nnsvj"

Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.124779   64794 kubelet.go:1837] SyncLoop (ADD, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)"
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.160444   64794 reconciler.go:212] operationExecutor.VerifyControllerAttachedVolume started for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.261128   64794 reconciler.go:257] operationExecutor.MountVolume started for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.286574   64794 operation_generator.go:484] MountVolume.SetUp succeeded for volume "default-token-jm7h5" (UniqueName: "kubernetes.io/secret/6171e2a7-d4e8-11e7-9c45-000d3a25e3c0-default-token-jm7h5") pod "nginx-56ccc998dd-nnsvj" (UID: "6171e2a7-d4e8-11e7-9c45-000d3a25e3c0")
Nov 29 09:33:39 worker-2 kubelet[64794]: I1129 09:33:39.431485   64794 kuberuntime_manager.go:370] No sandbox for pod "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)" can be found. Need to start a new one
Nov 29 09:33:42 worker-2 kubelet[64794]: I1129 09:33:42.449592   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerStarted", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}
Nov 29 09:33:47 worker-2 kubelet[64794]: I1129 09:33:47.637988   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerStarted", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:13:14 worker-2 kubelet[64794]: I1129 11:13:14.468137   64794 kubelet.go:1853] SyncLoop (DELETE, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)"
Nov 29 11:13:14 worker-2 kubelet[64794]: E1129 11:13:14.711891   64794 kuberuntime_manager.go:840] PodSandboxStatus of sandbox "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af" for pod "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)" error: rpc error: code = Unknown desc = failed to get task status for sandbox container "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af": process id 0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af not found: not found
Nov 29 11:13:14 worker-2 kubelet[64794]: E1129 11:13:14.711933   64794 generic.go:241] PLEG: Ignoring events for pod nginx-56ccc998dd-nnsvj/default: rpc error: code = Unknown desc = failed to get task status for sandbox container "0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af": process id 0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af not found: not found
Nov 29 11:13:15 worker-2 kubelet[64794]: I1129 11:13:15.788179   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:13:15 worker-2 kubelet[64794]: I1129 11:13:15.788221   64794 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.384411   42337 kubelet.go:1837] SyncLoop (ADD, "api"): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0), kubernetes-dashboard-7486b894c6-2xmd5_kube-system(e55ca22c-d416-11e7-9c45-000d3a25e3c0), busybox3-69d4f5b66c-2lcs6_default(adb05024-d412-11e7-9c45-000d3a25e3c0), kube-dns-7797cb8758-zblzt_kube-system(e925cbec-d40b-11e7-9c45-000d3a25e3c0), busybox7-797cc644bc-n5sv2_default(b7135a8f-d412-11e7-9c45-000d3a25e3c0)"
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.387169   42337 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"d00709dfb00ed5ac99dcd092978e44fc018f44cca5229307c37d11c1a4fe3f07"}
Nov 29 11:46:45 worker-2 kubelet[42337]: I1129 11:46:45.387245   42337 kubelet.go:1871] SyncLoop (PLEG): "nginx-56ccc998dd-nnsvj_default(6171e2a7-d4e8-11e7-9c45-000d3a25e3c0)", event: &pleg.PodLifecycleEvent{ID:"6171e2a7-d4e8-11e7-9c45-000d3a25e3c0", Type:"ContainerDied", Data:"0f539a84b96814651bb199e91f71157bc90c6e0c26340001c3f1c9f7bd9165af"}

cat /etc/systemd/system/kubelet.service

[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=cri-containerd.service
Requires=cri-containerd.service

[Service]
ExecStart=/usr/local/bin/kubelet \
  --allow-privileged=true \
  --anonymous-auth=false \
  --authorization-mode=Webhook \
  --client-ca-file=/var/lib/kubernetes/ca.pem \
  --cluster-dns=10.32.0.10 \
  --cluster-domain=cluster.local \
  --container-runtime=remote \
  --container-runtime-endpoint=unix:///var/run/cri-containerd.sock \
  --image-pull-progress-deadline=2m \
  --kubeconfig=/var/lib/kubelet/kubeconfig \
  --network-plugin=cni \
  --pod-cidr=10.200.2.0/24 \
  --register-node=true \
  --require-kubeconfig \
  --runtime-request-timeout=15m \
  --tls-cert-file=/var/lib/kubelet/worker-2.pem \
  --tls-private-key-file=/var/lib/kubelet/worker-2-key.pem \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Parece que hay diferentes errores relacionados con el problema. Tenemos ambos en nuestro clúster 1.8.3.

1. https://github.com/moby/moby/issues/31768 . Es un error de Docker. Reproducible en docker-ce = 17.09.0 ~ ce-0 ~ ubuntu.
2. El segundo es más interesante y tal vez esté relacionado con alguna condición de carrera dentro de Kubelet.
   Tenemos muchos pods que usaron un volumen de persistencia NFS con una subruta especificada en los montajes de contenedores, de alguna manera algunos de ellos se quedan atascados en un estado de terminación después de eliminar las implementaciones. Y hay muchos mensajes en el syslog:

 Error: UnmountVolume.TearDown failed for volume "nfs-test" (UniqueName: "kubernetes.io/nfs/39dada78-d9cc-11e7-870d-3c970e298d91-nfs-test") pod "39dada78-d9cc-11e7-870d-3c970e298d91" (UID: "39dada78-d9cc-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/39dada78-d9cc-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-test: directory not empty

¡Y es cierto que el directorio no está vacío, está desmontado y contiene nuestro directorio "subruta"!
Una de las explicaciones de tal comportamiento:

1. P1: Comience a crear pod o sincronizar pod
2. P1: Envía señal al administrador de volumen para realizar montajes / montajes.
3. P1: Está esperando que se complete el montaje.
4. P1: Reciba la señal de montaje exitosa (en realidad, solo verifique que todos los volúmenes estén montados)
5. De alguna manera, el volumen se desmonta. Puede ser otro proceso de eliminación, desmontarlo o algún error del sistema operativo, o alguna acción del recolector de basura.
6. P1: Continuar creando contenedor y crea subdirectorio en el punto de montaje (ya desmontado).
7. Después de todos los pasos anteriores, el pod no se puede eliminar porque el directorio de montaje no está vacío.

Más registros:

Dec  5 15:57:08 ASRock kubelet[2941]: I1205 15:57:08.333877    2941 reconciler.go:212] operationExecutor.VerifyControllerAttachedVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "test-df5d868fc-sclj5" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91")
Dec  5 15:57:08 ASRock systemd[1]: Started Kubernetes transient mount for /var/lib/kubelet/pods/005b4bb9-da18-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw.
Dec  5 15:57:12 ASRock kubelet[2941]: I1205 15:57:12.266404    2941 reconciler.go:186] operationExecutor.UnmountVolume started for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "005b4bb9-da18-11e7-870d-3c970e298d91" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91")
Dec  5 15:57:12 ASRock kubelet[2941]: E1205 15:57:12.387179    2941 nestedpendingoperations.go:264] Operation for "\"kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw\" (\"005b4bb9-da18-11e7-870d-3c970e298d91\")" failed. No retries permitted until 2017-12-05 15:57:12.887062059 -0800 PST (durationBeforeRetry 500ms). Error: UnmountVolume.TearDown failed for volume "nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw" (UniqueName: "kubernetes.io/nfs/005b4bb9-da18-11e7-870d-3c970e298d91-nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw") pod "005b4bb9-da18-11e7-870d-3c970e298d91" (UID: "005b4bb9-da18-11e7-870d-3c970e298d91") : remove /var/lib/kubelet/pods/005b4bb9-da18-11e7-870d-3c970e298d91/volumes/kubernetes.io~nfs/nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw: directory not empty

De alguna manera, algún proceso de limpieza ((dswp * deletedStateOfWorldPopulator) findAndRemoveDeletedPods ()) inicia el desmontaje de los volúmenes mientras el pod está en el estado de inicialización:

Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.620655   15875 kubelet_pods.go:886] Pod "test-84cd5ff8dc-kpv7b_4281-kuberlab-test(6e99a8df-dad6-11e7-b35c-3c970e298d91)" is terminated, but some volumes have not been cleaned up
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.686449   15875 kubelet_pods.go:1730] Orphaned pod "6e99a8df-dad6-11e7-b35c-3c970e298d91" found, but volumes not yet removed
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.790719   15875 kuberuntime_container.go:100] Generating ref for container test: &v1.ObjectReference{Kind:"Pod", Namespace:"4281-kuberlab-test", Name:"test-84cd5ff8dc-kpv7b", UID:"6e99a8df-dad6-11e7-b35c-3c970e298d91", APIVersion:"v1", ResourceVersion:"2639758", FieldPath:"spec.containers{test}"}
Dec  6 14:40:20 ASRock kubelet[15875]: I1206 14:40:20.796643   15875 docker_service.go:407] Setting cgroup parent to: "/kubepods/burstable/pod6e99a8df-dad6-11e7-b35c-3c970e298d91"

La inicialización y la eliminación del pod se están ejecutando al mismo tiempo.
Para repetir con error, debe iniciar y eliminar / actualizar inmediatamente alrededor de 10 implementaciones (probadas para un solo minion) y tal vez su operación de montaje no debe ser muy rápida.

Afectado por el mismo error en GKE. ¿Existen soluciones alternativas conocidas para este problema? El uso de --now no funciona.

Tengo una solución para este error, pero no estoy seguro de que el equipo de kubernetes lo fusione.

@dreyk ¿Podría proporcionar más detalles sobre lo que descubrió para este error y cuál es su solución para que el equipo de almacenamiento pueda echar un vistazo? ¡Gracias!

@ gm42 Pude

1. SSH en el nodo en el que se programó el pod atascado
2. Ejecutando docker ps | grep {pod name} para obtener el ID de contenedor de Docker
3. Ejecutando docker rm -f {container id}

En GKE, la actualización de los nodos ayudó al instante.

Tengo el mismo error en mi clúster local configurado usando kubeadm .

docker ps | grep {pod name} en el nodo no muestra nada y el pod se atasca en el estado de terminación. Actualmente tengo dos vainas en este estado.

¿Qué puedo hacer para eliminar a la fuerza el pod? ¿O quizás cambiar el nombre de la vaina? No puedo hacer girar otra cápsula con el mismo nombre. ¡Gracias!

Encontré el motivo en mi clúster 1.7.2,
porque otro programa de monitoreo monta la ruta raíz /
la ruta raíz contiene /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
así que cuando kubelet borra el pod, pero no puede liberar el volumen, el mensaje es:
dispositivo o recurso ocupado

pasos:
1) sudo journalctl -u kubelet
este shell me ayuda a encontrar el mensaje de error,
2) sudo docker inspeccionar
busque el io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
y
HostConfig -> Binds -> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf:/var/run/secrets/kubernetes .io / servi ceaccount: ro "

3) grep -l ddc66e10-0711-11e8-b905-6c92bf70b164 / proc / * / mountinfo

/ proc / 90225 / mountinfo
5) ps aux | grep 90225
raíz 90225 1,3 0,0 2837164 42580? Ssl 01 de febrero 72:40 ./monitor_program

Tengo el mismo error en mi 1.7.2

operationExecutor.UnmountVolume iniciado para el volumen "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8-b905- 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] Operación para" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token" ( Error en "ddc66e10-0711-11e8-b905-6c92bf70b164 \") ". No se permiten reintentos hasta 2018-02-05 11: 37: 52.509148953 +0800 CST (durationBeforeRetry 2m2s). Error: UnmountVolume.TearDown falló para el volumen "default-token-bnttf" (Nombre único: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8- b905-6c92bf70b164 "(UID:" ddc66e10-0711-11e8-b905-6c92bf70b164 "): elimina /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secreto token-bnttf: dispositivo o recurso ocupado

Al reiniciar el servicio de la ventana acoplable, se libera el bloqueo y los pods se eliminan en pocos minutos. Esto es un error. Utilizando Docker 17.03

El mismo problema aquí en Azure, Kube 1.8.7

También nos pasó hace unos minutos en 1.8.9. ¿Alguien está buscando resolver esto? Reiniciar Docker ayuda, pero es un poco ridículo.

Esto me ha estado sucediendo mucho en la última versión 1.9.4 en GKE. He estado haciendo esto por ahora:

kubectl delete pod NAME --grace-period=0 --force

El mismo problema aquí en GKE 1.9.4-gke.1
parece estar relacionado con los montajes de volumen.
Sucede cada vez que se configuran filebeats como se describe aquí:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

El registro de Kubelet muestra esto:

Mar 23 19:44:16 gke-testing-c2m4-1-97b57429-40jp kubelet[1361]: I0323 19:44:16.380949    1361 reconciler.go:191] operationExecutor.UnmountVolume started for volume "config" (UniqueName: "kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config") pod "9a5f1519-2d39-11e8-bec8-42010a8400f3" (UID: "9a5f1519-2d39-11e8-bec8-42010a8400f3")
Mar 23 19:44:16 gke-testing-c2m4-1-97b57429-40jp kubelet[1361]: E0323 19:44:16.382032    1361 nestedpendingoperations.go:263] Operation for "\"kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config\" (\"9a5f1519-2d39-11e8-bec8-42010a8400f3\")" failed. No retries permitted until 2018-03-23 19:44:32.381982706 +0000 UTC m=+176292.263058344 (durationBeforeRetry 16s). Error: "error cleaning subPath mounts for volume \"config\" (UniqueName: \"kubernetes.io/configmap/9a5f1519-2d39-11e8-bec8-42010a8400f3-config\") pod \"9a5f1519-2d39-11e8-bec8-42010a8400f3\" (UID: \"9a5f1519-2d39-11e8-bec8-42010a8400f3\") : error checking /var/lib/kubelet/pods/9a5f1519-2d39-11e8-bec8-42010a8400f3/volume-subpaths/config/filebeat/0 for mount: lstat /var/lib/kubelet/pods/9a5f1519-2d39-11e8-bec8-42010a8400f3/volume-ubpaths/config/filebeat/0/..: not a directory"

kubectl delete pod NAME --grace-period=0 --force
parece funcionar.
también funciona reiniciar kubelet.

El mismo problema aquí en GKE 1.9.4-gke.1
Solo sucede con un conjunto de demonios filebeat específico, pero la recreación de todos los nodos tampoco ayuda, simplemente sigue sucediendo.

También golpeando este problema en GKE 1.9.4-gke.1 como @Tapppi : los pods se eliminaron del demonio docker en el nodo host, pero kubernetes lo tenía atascado en TERMINATING

Events:
  Type    Reason                 Age        From                                                      Message
  ----    ------                 ----       ----                                                      -------
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "data"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "varlibdockercontainers"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "prospectors"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "config"
  Normal  SuccessfulMountVolume  43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  MountVolume.SetUp succeeded for volume "filebeat-token-v74k6"
  Normal  Pulled                 43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Container image "docker.elastic.co/beats/filebeat:6.1.2" already present on machine
  Normal  Created                43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Created container
  Normal  Started                43m        kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Started container
  Normal  Killing                <invalid>  kubelet, gke-delivery-platform-custom-pool-c9b9fe86-fgvh  Killing container with id docker://filebeat:Need to kill Pod
/Users/karl.stoney/git/autotrader/terraform-gcp git/master

Para nosotros, algo nuevo acaba de suceder hace un momento, cuando eliminé por la fuerza un pod atascado usando kubectl delete pod NAME --grace-period=0 --force , el nodo en el que estaba este pod se volvió insalubre. Estamos ejecutando la ventana acoplable 17-12CE, y reiniciar la ventana acoplable deamon en esa caja ayudó y descorchó el nodo.

Para las personas que ven este problema en 1.9.4-gke.1, lo más probable es que se deba a https://github.com/kubernetes/kubernetes/issues/61178 , que se corrigió en 1.9.5 y se implementará en GKE esta semana. El problema está relacionado con la limpieza de los montajes de subrutas de un archivo (no un directorio). @zackify @ nodefactory-bk @Tapppi @Stono

IIUC, el problema original de este error está relacionado con la configuración de kubelet en contenedor, que es diferente.

Por cierto, crear un nuevo grupo de nodos con la versión v1.9.3-gke.0 fue nuestra solución para esto, ya que v1.9.5 todavía no se ha implementado en gke y ya es Pascua.

¿Alguien puede confirmar que esto está solucionado en la versión 1.9.3+, por favor? Tenemos serios problemas debido a este comportamiento, y reiniciar la ventana acoplable cada vez que esto sucede es tan estúpido.

Corregido en 1.9.6 para mí

El miércoles 4 de abril de 2018 a las 11:43 a.m.sokoow, [email protected] escribió:

¿Alguien puede confirmar que esto está solucionado en la versión 1.9.3+, por favor? Tenemos
algunos problemas serios debido a este comportamiento, y reiniciar Docker cada
El momento en que esto sucede es taaan estúpido.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

Bien, gracias @Stono . Una cosa más para confirmar aquí. Aquí está nuestra plantilla de kubespray para kubelet en contenedor:

#!/bin/bash /usr/bin/docker run \ --net=host \ --pid=host \ --privileged \ --name=kubelet \ --restart=on-failure:5 \ --memory={{ kubelet_memory_limit|regex_replace('Mi', 'M') }} \ --cpu-shares={{ kubelet_cpu_limit|regex_replace('m', '') }} \ -v /dev:/dev:rw \ -v /etc/cni:/etc/cni:ro \ -v /opt/cni:/opt/cni:ro \ -v /etc/ssl:/etc/ssl:ro \ -v /etc/resolv.conf:/etc/resolv.conf \ {% for dir in ssl_ca_dirs -%} -v {{ dir }}:{{ dir }}:ro \ {% endfor -%} -v /:/rootfs:ro,shared \ -v /sys:/sys:ro \ -v /var/lib/docker:/var/lib/docker:rw,shared \ -v /var/log:/var/log:rw,shared \ -v /var/lib/kubelet:/var/lib/kubelet:rw,shared \ -v /var/lib/cni:/var/lib/cni:rw,shared \ -v /var/run:/var/run:rw,shared \ -v /etc/kubernetes:/etc/kubernetes:ro \ -v /etc/os-release:/etc/os-release:ro \ {{ hyperkube_image_repo }}:{{ hyperkube_image_tag}} \ ./hyperkube kubelet --containerized \ "$@"

¿Eso se ve bien? ¿Alguien más está usando similar?

Hablé demasiado pronto.

  Type    Reason   Age   From                                                      Message                                                                                                             [53/7752]
  ----    ------   ----  ----                                                      -------
  Normal  Killing  4m    kubelet, gke-delivery-platform-custom-pool-560b2b96-gcmb  Killing container with id docker://filebeat:Need to kill Pod

Tuve que destruirlo de manera brutal.

❯ kks delete pod filebeat-x56v8 --force --grace-period 0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "filebeat-x56v8" deleted

@Stono, ¿ qué versión de la

Todavía tengo este problema en 1.9.6 en el clúster administrado de Azure AKS.

Usando esta solución alternativa en este momento para seleccionar todos los pods atascados y eliminarlos (ya que termino teniendo franjas de terminales de terminación en mi clúster dev / scratch):

kubectl get pods | awk '$3=="Terminating" {print "kubectl delete pod " $1 " --grace-period=0 --force"}' | xargs -0 bash -c

encontré esto en los clústeres de mayo de Azure y AWS; Mike Elliot proporcionó una solución alternativa

https://jira.onap.org/browse/OOM-946

ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NOMBRE NOMBRE ESTADO LISTO REINICIE EDAD
kube-system heapster-76b8cd7b5-4r88h 1/1 En ejecución 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 En ejecución 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Running 0 25d
monitorización del sistema kube-grafana-997796fcf-wtz7n 1/1 En ejecución 0 25d
monitorización del sistema kube-influxdb-56fdcd96b-2phd2 1/1 En ejecución 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 En ejecución 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Finalizando 0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 terminando 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl eliminar pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
advertencia: la eliminación inmediata no espera la confirmación de que el recurso en ejecución ha finalizado. El recurso puede continuar ejecutándose en el clúster de forma indefinida.
Pod "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" eliminado
ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NOMBRE NOMBRE ESTADO LISTO REINICIAR EDAD
kube-system heapster-76b8cd7b5-4r88h 1/1 En ejecución 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 En ejecución 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Running 0 25d
monitorización del sistema kube-grafana-997796fcf-wtz7n 1/1 En ejecución 0 25d
monitorización del sistema kube-influxdb-56fdcd96b-2phd2 1/1 En ejecución 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 En ejecución 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Finalizando 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl eliminar pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
advertencia: la eliminación inmediata no espera la confirmación de que el recurso en ejecución ha finalizado. El recurso puede continuar ejecutándose en el clúster de forma indefinida.
Pod "dev-sms-857f6dbd87-pds58" eliminado
ubuntu @ ip-10-0-0-22 : ~ $ kubectl get pods --all-namespaces
NOMBRE NOMBRE ESTADO LISTO REINICIAR EDAD
kube-system heapster-76b8cd7b5-4r88h 1/1 En ejecución 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 En ejecución 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Running 0 25d
monitorización del sistema kube-grafana-997796fcf-wtz7n 1/1 En ejecución 0 25d
monitorización del sistema kube-influxdb-56fdcd96b-2phd2 1/1 En ejecución 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 En ejecución 0 25d

No estoy seguro de si se trata del mismo problema, pero hemos comenzado a notar este comportamiento desde que pasamos de la versión 1.9.3 a la 10.10.1. Nunca sucedió antes de eso. Estamos usando volúmenes de glusterfs, con SubPath. Kubelet registra continuamente cosas como

Apr 23 08:21:11 int-kube-01 kubelet[13018]: I0423 08:21:11.106779   13018 reconciler.go:181] operationExecutor.UnmountVolume started for volume "dev-static" (UniqueName: "kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static") pod "ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f" (UID: "ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f")
Apr 23 08:21:11 int-kube-01 kubelet[13018]: E0423 08:21:11.122027   13018 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static\" (\"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\")" failed. No retries permitted until 2018-04-23 08:23:13.121821027 +1000 AEST m=+408681.605939042 (durationBeforeRetry 2m2s). Error: "UnmountVolume.TearDown failed for volume \"dev-static\" (UniqueName: \"kubernetes.io/glusterfs/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f-dev-static\") pod \"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\" (UID: \"ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f\") : Unmount failed: exit status 32\nUnmounting arguments: /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static\nOutput: umount: /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static: target is busy.\n        (In some cases useful info about processes that use\n         the device is found by lsof(8) or fuser(1))\n\n"

y lsof muestra de hecho que el directorio bajo los volúmenes de glusterfs todavía está en uso:

glusterfs  71570                     root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterti  71570  71571              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersi  71570  71572              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterme  71570  71573              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersp  71570  71574              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glustersp  71570  71575              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71579              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterio  71570  71580              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71581              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71582              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71583              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71584              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71585              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71586              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterep  71570  71587              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterfu  71570  71592              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere
glusterfu  71570  71593              root   10u      DIR              0,264      4096  9380607748984626555 /var/lib/kubelet/pods/ad8fabbe-4449-11e8-b21a-a2bfb3c62d0f/volumes/kubernetes.io~glusterfs/dev-static/subpathhere

Todo esto estuvo bien en 1.9.3, por lo que es como si la solución para este problema hubiera roto nuestro caso de uso :(

@ ross-w esta firma se ve diferente a las demás. ¿Podría abrir un nuevo problema y también incluir la especificación de su pod?

¿Alguna actualización sobre estos problemas?
En nuestro caso (Kubernetes 1.9.7, ventana acoplable 17.03), los pods están en estado Terminating, después de que el nodo se queda sin memoria y los pods se reprograman. Finalmente, hay muchos pods fantasma en el panel de Kubernetes y en la pestaña de implementaciones, podemos ver implementaciones con 4/1 pods.
Reiniciar kubelet o matar todos los pods en el espacio de nombres ayuda, pero es una solución muy pobre.

@Adiqq Porque fue un problema con Docker en sí.

Eche un vistazo a journalctl -u kubelet -f en uno de sus nodos. Tenía un mensaje como 'No se puede matar el contenedorerror de gRpc "(no tengo el mensaje real desde que solucioné esto).

Para solucionarlo, reinicié la ventana acoplable en cada nota. Durante el arranque de Docker, limpie los contenedores en estado roto y elimine todos estos pods obsoletos.

Tuve esto ayer en 1.9.7, con un pod atascado en estado de terminación y en los registros solo tenía "necesidades para matar pod", tuve que --force --grace-period=0 para deshacerme.

Acabo de obtener esto también con 1.9.7-gke.0.
No tuve problemas con 1.9.6-gke.1.
Pero lo tenía con 1.9.4 y 1.9.5

La cápsula que se atasca tiene un PV adjunto.

Volver a implementar o eliminar un pod tiene el mismo efecto.
Reiniciar kubelet en el nodo infractor no funcionó. kubelet no comenzó de nuevo y tuve que reiniciar todo el nodo.

Durante esto, el módulo no se pudo programar en ningún otro nodo, ya que decía que el PV ya estaba montado en otro lugar.

@Stono @ nodefactory-bk, chicos, ¿podrían echar un vistazo a sus registros de kubelet en los nodos infractores para ver si hay registros detallados que puedan señalar el problema?

cc @dashpole

Acabo de tener una aplicación atascada al terminar.
Esto está en 1.9.7-gke.1
Aquí está kubectl describe pod con secretos redactados:

Name:                      sharespine-cloud-6b78cbfb8d-xcbh5
Namespace:                 shsp-cloud-dev
Node:                      gke-testing-std4-1-0f83e7c0-qrxg/10.132.0.4
Start Time:                Tue, 22 May 2018 11:14:22 +0200
Labels:                    app=sharespine-cloud
                           pod-template-hash=2634769648
Annotations:               <none>
Status:                    Terminating (expires Wed, 23 May 2018 10:02:01 +0200)
Termination Grace Period:  60s
IP:                        10.40.7.29
Controlled By:             ReplicaSet/sharespine-cloud-6b78cbfb8d
Containers:
  sharespine-cloud:
    Container ID:   docker://4cf402b5dc3ea728fcbff87b57e0ec504093ea3cf7277f6ca83fde726a4bba48
    Image:          ...
    Image ID:       ...
    Ports:          9000/TCP, 9500/TCP
    State:          Running
      Started:      Tue, 22 May 2018 11:16:36 +0200
    Ready:          False
    Restart Count:  0
    Limits:
      memory:  1500M
    Requests:
      cpu:      500m
      memory:   1024M
    Liveness:   http-get http://:9000/ delay=240s timeout=1s period=30s #success=1 #failure=3
    Readiness:  http-get http://:9000/ delay=30s timeout=1s period=10s #success=1 #failure=3
    Environment Variables from:
      sharespine-cloud-secrets  Secret  Optional: false
    Environment:
      APP_NAME:  sharespine-cloud
      APP_ENV:   shsp-cloud-dev (v1:metadata.namespace)
      JAVA_XMS:  128M
      JAVA_XMX:  1024M
    Mounts:
      /home/app/sharespine-cloud-home/ from sharespine-cloud-home (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-x7vzr (ro)
  sharespine-cloud-elker:
    Container ID:   docker://88a5a2bfd6804b5f40534ecdb6953771ac3181cf12df407baa81a34a7215d142
    Image:          ...
    Image ID:       ...
    Port:           <none>
    State:          Running
      Started:      Tue, 22 May 2018 11:16:36 +0200
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  200Mi
    Requests:
      cpu:     10m
      memory:  100Mi
    Environment Variables from:
      sharespine-cloud-secrets  Secret  Optional: false
    Environment:
      APP_NAME:                     sharespine-cloud
      APP_ENV:                      shsp-cloud-dev (v1:metadata.namespace)
      ELASTICSEARCH_LOGBACK_PATH:   /home/app/sharespine-cloud-home/logs/stash/stash.json
      ELASTICSEARCH_LOGBACK_INDEX:  cloud-dev
    Mounts:
      /home/app/sharespine-cloud-home/ from sharespine-cloud-home (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-x7vzr (ro)
Conditions:
  Type           Status
  Initialized    True
  Ready          False
  PodScheduled   True
Volumes:
  sharespine-cloud-home:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  sharespine-cloud-home
    ReadOnly:   false
  default-token-x7vzr:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-x7vzr
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason         Age                From                                       Message
  ----     ------         ----               ----                                       -------
  Normal   Killing        20m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  Killing container with id docker://sharespine-cloud-elker:Need to kill Pod
  Normal   Killing        20m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  Killing container with id docker://sharespine-cloud:Need to kill Pod
  Warning  FailedKillPod  18m                kubelet, gke-testing-std4-1-0f83e7c0-qrxg  error killing pod: failed to "KillPodSandbox" for "83d05e96-5da0-11e8-ba51-42010a840176" with KillPodSandboxError: "rpc error: code = DeadlineExceeded desc = context deadline exceeded"
  Warning  FailedSync     1m (x53 over 16m)  kubelet, gke-testing-std4-1-0f83e7c0-qrxg  error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded

No estoy seguro de dónde encontrar kubelet.log en gke en las imágenes de Google. Encontré algo que estoy adjuntando.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
lo mató y lo quitó.
Comenzó bien después, pero tardó un poco más de lo habitual.

Eso sí, esto no sucede TODAS las veces para esa aplicación.
Yo diría que probablemente aproximadamente 1/4 de veces.

Al hacer esto con k8s 1.9.6, cuando kubelet no puede desmontar la montura Cephfs, todos los pods en el nodo permanecen terminados para siempre. Tuve que reiniciar el nodo para recuperar, el reinicio de kubelet o docker no ayudó.

@tuminoid el problema de

Para su información, la actualización de mis clústeres (a k8s v1.10.2) parece habernos eliminado este problema.

El adjunto reproduce esto para mí en gke

kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:17:39Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.2-gke.1", GitCommit:"75d2af854b1df023c7ce10a8795b85d3dd1f8d37", GitTreeState:"clean", BuildDate:"2018-05-10T17:23:18Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

k8s-nfs-test.yaml.txt

ejecútelo y elimínelo. Obtendrá un 'nfs-client' atascado al eliminar. La razón es el montaje duro en el nodo, y primero se elimina el 'servidor'.

@donbowman para el problema de desmontaje de nfs cuando primero elimina el servidor de nfs, puede configurar la opción de montaje "suave" en StorageClass o PV.

No veo como Puedo configurarlo en un PersistentVolumeClaim, pero eso no se aplica aquí.
No creo que StorageClass se aplique aquí (ese sería el debajo del disco, debajo del servidor nfs).

El problema está en nfs-client.
¿Me estoy perdiendo de algo?

Para su PV nfs, puede configurar el campo mountOptions comenzando en 1.8 para especificar un montaje suave. Si aprovisiona dinámicamente volúmenes nfs, también puede configurarlo en StorageClass.mountOptions

sí, pero no es el PV que se está montando con NFS.
Es de mi contenedor de servidor NFS.
No hay aprovisionamiento dinámico.

Esto está usando Google GCP + GKE. El PVC selecciona un PV que es un bloque IO, montado como un ext4 en un contenedor que lo reexporta con NFS.

El segundo conjunto de contenedores, que se monta desde el servidor nfs (que en sí mismo es un pod), no lo ven como un PV. Lo ven como un volumen como el siguiente.

No veo una forma de hacer que este cliente nfs vea un 'pvc' para el montaje, por lo que no puedo configurar las opciones de montaje. Tampoco puedo verlo como StorageClass.

¿Me estoy perdiendo de algo?

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: nfs-client
  labels:
    app: nfs-client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client
    spec:
      containers:
        - name: nfs-client
          image: busybox:latest
          imagePullPolicy: IfNotPresent
          command: ["sleep", "3600"]
          volumeMounts:
            - name: nfs
              mountPath: /registry
      volumes:
        - name: nfs
          nfs:
            server: nfs-server.default.svc.cluster.local
            path: /

@donbowman para su segundo conjunto de contenedores, que usa el montaje nfs, puede crear manualmente un PV para ese volumen nfs con el conjunto mountOptions y compartir el PVC para ese PV nfs en todos sus pods. Sin aprovisionamiento dinámico involucrado.

Algo como esto:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  storageClassName: ""
  capacity:
    # Capacity doesn't actually matter for nfs
    storage: 500G 
  accessModes:
    - ReadWriteMany
  mountOptions:
    - soft
  nfs:
    server: nfs-server.default.svc.cluster.local
    path: /
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-claim
spec:
  # It's necessary to specify "" as the storageClassName
  # so that the default storage class won't be used
  storageClassName: ""
  volumeName: nfs-pv
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 500G

¡Gracias! Así que funcionó (en el sentido de que ahora es un montaje suave) pero no soluciona el problema:

La montura (como se observa en el nodo) ahora es suave:

nfs-server.default.svc.cluster.local:/ on /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.162.0.2,local_lock=none,addr=10.19.241.155)

Pero cuando elimino todo, todavía tengo el cliente nfs atascado para siempre en el estado de terminación.

k8s-nfs-test.yaml.txt

adjunto es el yaml que utilicé. Hice una 'creación', esperé a que apareciera, observé que el cliente tenía el montaje, podía leer / escribir archivos en él, luego hice una 'eliminación'.

El pod nfs-server se elimina, pero el nfs-client no.

Mirando la cápsula, la montura se ha quedado:

# umount -f /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv
umount: /home/kubernetes/containerized_mounter/rootfs/var/lib/kubelet/pods/cbeda204-638d-11e8-9758-42010aa200b4/volumes/kubernetes.io~nfs/nfs-pv: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)

@donbowman ah lo siento mucho, me equivoqué con la opción suave. La opción suave solo evita que las llamadas al sistema de archivos se cuelguen cuando el servidor es inaccesible, pero en realidad no ayuda a desmontar el volumen nfs. Se necesitaría hacer un desmontaje forzado para eso, que actualmente no tenemos una forma de atravesar. Por ahora, tendrá que limpiar manualmente esos montajes y asegurarse de eliminar sus pods en el orden correcto (primero los clientes nfs y luego el servidor nfs).

Intenté agregar timeo = 30 e intr, pero el mismo problema.
esto lo bloquea, debe iniciar sesión en el nodo y hacer un umount -f -l en el montaje subyacente y luego puede hacer un kubectl delete --force --grace-period 0 en el pod.

parece que, dado que esto se montó en nombre del pod, podría desmontarse (o forzar el desmontaje después de un tiempo de espera) al eliminarlo automáticamente.

Tenía un montón de Pod como ese, así que tuve que crear un comando que limpiara todos los pods terminales:

kubectl get pods -o json | jq -c '.items[] | select(.metadata.deletionTimestamp) | .metadata.name' | xargs -I '{}' kubectl delete pod --force --grace-period 0 '{}'

Creo que con el nuevo almacén de archivos de Google tendremos el mismo problema, sin desmontar.

@donbowman iirc, su problema se debe a que estaba terminando el pod del servidor nfs antes que el pod del cliente nfs. Si usa el almacén de archivos, ya no necesita un pod para alojar su servidor nfs, por lo que no debería tener este problema siempre que no elimine todo el archivo del almacén de incendios.

¿No tendré el mismo problema si estoy orquestando el almacén de archivos? Por ejemplo, si lo abro para una implementación de Kubernetes específica y luego lo dejo al final, el pedido no está garantizado.

Pero también creo que el problema no es solo el orden, la eliminación del pod del cliente nfs no se desmonta en absoluto, simplemente deja el montaje colgando en el nodo. Entonces, independientemente de si el almacén de archivos / servidor está presente o no, hay un soporte colgante.

Cuando se termina un pod, desmontamos el volumen (asumiendo que el servidor todavía está allí). Si ve montajes colgantes incluso cuando el servidor existe, entonces eso es un error.

Si usa el aprovisionamiento dinámico con PVC y PV, no permitimos que se elimine el PVC (y el almacenamiento subyacente) hasta que todos los Pods que hacen referencia a él hayan terminado de usarlo. Si desea orquestar el aprovisionamiento usted mismo, debe asegurarse de no eliminar el servidor hasta que todos los pods hayan terminado de usarlo.

Quizás esta sea una posible solución alternativa: # 65936

Forzar la eliminación funcionó para kubectl delete po $pod --grace-period=0 --force . La bandera --now no funcionaba. No estoy seguro acerca de # 65936 pero me gustaría no matar el nodo cuando sucedan los estados Unknown .

Tener el mismo problema (los pods permanecen terminados porque un archivo dentro del pod no se puede desmontar porque el dispositivo está 'ocupado') en 1.10.5. Para mí, usar --grace-period=0 --force dará como resultado que el punto de montaje continúe existiendo. Finalmente terminé con más de 90000 puntos de montaje, lo que ralentizó gravemente el clúster. La solución aquí es hacer una búsqueda en la carpeta del pod y desmontar esos archivos de forma recursiva, y luego eliminar de forma recursiva la carpeta del pod.
En mi caso, estoy montando un mapa de configuración usando subruta en una carpeta existente con archivos existentes, sobrescribiendo uno de los archivos existentes. Esto solía funcionar bien para mí en 1.8.6.
El póster original menciona que las vainas permanecen en 'terminación' durante unas horas, en mi caso son días. No los he visto limpiarse eventualmente, excepto cuando hago la solución manual.

Teniendo el mismo problema, causado por el agregador de registros (similar a fluentd), monta la carpeta /var/lib/docker/containers y el pod tiene muchos montajes:

shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/6691cb9460df75579915fd881342931b98b4bfb7a6fbb0733cc6132d7c17710c/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/4cbbdf53ee5122565c6e118a049c93543dcc93bfd586a3456ff4ca98d59810a3/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/b2968b63a7a1f673577e5ada5f2cda50e1203934467b7c6573e21b341d80810a/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/4d54a4eabed68b136b0aa3d385093e4a32424d18a08c7f39f5179440166de95f/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/0e5487465abc2857446940902d9b9754b3447e587eefc2436b2bb78fd4d5ce4d/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/c73ed0942d77bf43f9ba016728834c47339793f9f1f31c4e566d73be492cf859/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/f9ab13f7f145b44beccc40c158287c4cfcc9dc465850f30d691961a2cabcfc14/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/aa449af555702d04f95fed04d09a3f1d5ae38d677484fc6cc9fc6d4b42182820/shm
shm                      64.0M         0     64.0M   0% /var/lib/docker/containers/f6608e507348b43ade3faa05d0a11b674c29f2038308f138174e8b7b8233633f/shm

En mi caso, algunos pods pueden eliminarse bien con kubernetes, pero algunos se quedan atascados en el estado "terminando".

Podría estar relacionado con https://github.com/kubernetes/kubernetes/issues/45688 (también estoy usando Docker 17)

Solo tuve el problema de que las cápsulas no terminaban porque faltaba un secreto. Después de que creé ese secreto en ese espacio de nombres, todo volvió a la normalidad.

Quité mis vainas atascadas de esta manera:

user<strong i="6">@laptop</strong>:~$ kubectl -n storage get pod
NAME                     READY     STATUS        RESTARTS   AGE
minio-65b869c776-47hql   0/1       Terminating   5          1d
minio-65b869c776-bppl6   0/1       Terminating   33         1d
minio-778f4665cd-btnf5   1/1       Running       0          1h
sftp-775b578d9b-pqk5x    1/1       Running       0          28m
user<strong i="7">@laptop</strong>:~$ kubectl -n storage delete pod minio-65b869c776-47hql --grace-period 0 --force
pod "minio-65b869c776-47hql" deleted
user<strong i="8">@laptop</strong>:~$ kubectl -n storage delete pod minio-65b869c776-bppl6 --grace-period 0 --force
pod "minio-65b869c776-bppl6" deleted
user<strong i="9">@laptop</strong>:~$ kubectl -n storage get pod
NAME                     READY     STATUS    RESTARTS   AGE
minio-778f4665cd-btnf5   1/1       Running   0          2h
sftp-775b578d9b-pqk5x    1/1       Running   0          30m
user<strong i="10">@laptop</strong>:~$

Tiene un problema similar al ejecutarse en Azure ACS.

10:12 $ kubectl describe pod -n xxx triggerpipeline-3737304981-nx85k 
Name:                      triggerpipeline-3737304981-nx85k
Namespace:                 xxx
Node:                      k8s-agent-d7584a3a-2/10.240.0.6
Start Time:                Wed, 27 Jun 2018 15:33:48 +0200
Labels:                    app=triggerpipeline
                           pod-template-hash=3737304981
Annotations:               kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"xxx","name":"triggerpipeline-3737304981","uid":"b91320ff-7a0e-11e8-9e7...
Status:                    Terminating (expires Fri, 27 Jul 2018 09:00:35 +0200)
Termination Grace Period:  0s
IP:                        
Controlled By:             ReplicaSet/triggerpipeline-3737304981
Containers:
  alpine:
    Container ID:  docker://8443c7478dfe1a57a891b455366ca007fe00415178191a54b0199d246ccbd566
    Image:         alpine
    Image ID:      docker-pullable://alpine<strong i="6">@sha256</strong>:e1871801d30885a610511c867de0d6baca7ed4e6a2573d506bbec7fd3b03873f
    Port:          <none>
    Command:
      sh
    Args:
      -c
      apk add --no-cache curl && echo "0 */4 * * * curl -v --trace-time http://myapi:80/api/v1/pipeline/start " | crontab - && crond -f
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-p9qtw (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 
Volumes:
  default-token-p9qtw:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-p9qtw
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     <none>
Events:          <none>

Intenté usar --now o establecer el período de gracia. Por ejemplo

09:00 $  kubectl delete pod -n xxx triggerpipeline-3737304981-nx85k --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "triggerpipeline-3737304981-nx85k" deleted

Aún así, el módulo está colgado y eso hace que la implementación correspondiente también se bloquee.

También estoy atormentado por estos mensajes de "Necesito matar Pod" en los eventos de pod. ¿Qué significa esto por cierto? ¿Que _Kubernetes_ siente la necesidad de matar al grupo, o que _yo_ debería matar al grupo?

esto me pasó hace un par de días y dejé de borrar y dejé el pod como estaba. Luego, hoy, desapareció y parece que finalmente se eliminará.

Me pasó hace un momento. La solución --force --now no funcionó para mí. Encontré sospechosa la siguiente línea en los registros de kubelet

6 de agosto 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni falló en el enlace de estado para el pod "backend-foos-227474871-gzhw0_default": inesperado comando de salida nsenter: no se puede abrir: no existe tal archivo o directorio

Lo que me llevó a encontrar el siguiente problema:
https://github.com/openshift/origin/issues/15802

No estoy en openhift sino en Openstack, así que pensé que podría estar relacionado. Di el consejo de reiniciar Docker una vez.
Al reiniciar la ventana acoplable, las cápsulas bloqueadas en "Terminando" desaparecieron.

Sé que esto es solo una solución, pero a veces ya no me despierto a las 3 de la mañana para solucionarlo.
No digo que debas usar esto, pero podría ayudar a algunas personas.

El sueño es lo que tengo mis pods terminationGracePeriodSeconds está configurado en (30 segundos). Si está vivo más tiempo que eso, este cronjob --force --grace-period = 0 y lo matará por completo

apiVersion: batch/v1beta1 kind: CronJob metadata: name: stuckpod-restart spec: concurrencyPolicy: Forbid successfulJobsHistoryLimit: 1 failedJobsHistoryLimit: 5 schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: stuckpod-restart image: devth/helm:v2.9.1 args: - /bin/sh - -c - echo "$(date) Job stuckpod-restart Starting"; kubectl get pods --all-namespaces=true | awk '$3=="Terminating" {print "sleep 30; echo "$(date) Killing pod $1"; kubectl delete pod " $1 " --grace-period=0 --force"}'; echo "$(date) Job stuckpod-restart Complete"; restartPolicy: OnFailure

Veo el mismo error con Kubernetes v1.10.2. Los pods se atascan al terminar indefinidamente y el kubelet en el nodo en cuestión registra repetidamente:

Aug 21 13:25:55 node-09 kubelet[164855]: E0821 13:25:55.149132  
164855 nestedpendingoperations.go:267] 
Operation for "\"kubernetes.io/configmap/b838409a-a49e-11e8-bdf7-000f533063c0-configmap\" 
(\"b838409a-a49e-11e8-bdf7-000f533063c0\")" failed. No retries permitted until 2018-08-21 
13:27:57.149071465 +0000 UTC m=+1276998.311766147 (durationBeforeRetry 2m2s). Error: "error 
cleaning subPath mounts for volume \"configmap\" (UniqueName: 
\"kubernetes.io/configmap/b838409a-a49e-11e8-bdf7-000f533063c0-configmap\") pod 
\"b838409a-a49e-11e8-bdf7-000f533063c0\" (UID: \"b838409a-a49e-11e8-bdf7-000f533063c0\") 
: error deleting /var/lib/kubelet/pods/b838409a-a49e-11e8-bdf7-000f533063c0/volume-
subpaths/configmap/pod-master/2: remove /var/lib/kubelet/pods/b838409a-a49e-11e8-bdf7-
000f533063c0/volume-subpaths/configmap/pod-master/2: device or resource busy"

Puedo desmontar manualmente el volumen de subruta en cuestión sin quejarme (Linux no me dice que está ocupado). Esto evita que kubelet registre el mensaje de error. Sin embargo, esto no inspira a Kubernetes a continuar con la limpieza, ya que el pod todavía se muestra en estado de terminación. Reiniciar Docker de forma rutinaria para limpiar esto no es realmente una solución aceptable debido a la interrupción que causa en los contenedores en ejecución.

También es de destacar: el contenedor en sí ha pasado de docker ps -a sin evidencia de que alguna vez existió, por lo que no estoy seguro de que esto sea realmente un problema de Docker. Estamos utilizando la versión 17.03.2-ce de Docker.

Una actualización: habíamos configurado nuestros nodos para redirigir el directorio raíz de kubelet a un volumen que no es del sistema operativo con un enlace simbólico ( /var/lib/kubelet era un enlace simbólico que apuntaba a otro directorio en un volumen diferente). Cuando reconfiguré las cosas para pasar --root-dir al kubelet para que fuera al directorio deseado directamente, en lugar de a través de un enlace simbólico, y reinicié el kubelet, limpió los montajes de volumen y borró los pods que estaban atascados terminando sin requerir un reinicio de Docker.

Experimenté este problema hoy por primera vez mientras ejecutaba algunos pods localmente en minikube.

Tenía un montón de pods atascados en Terminating debido a un configmap / secret montado como un volumen que faltaba. Ninguna de las sugerencias / soluciones alternativas publicadas anteriormente funcionó, excepto esta .

Sin embargo, una cosa que creo que vale la pena mencionar es lo siguiente:

• Cuando ejecuté kubectl get pods , obtuve la lista de pods con el estado Terminating .
• Sin embargo, cuando ejecuté docker ps | grep -i {{pod_name}} , ninguno de los pods en el estado Terminating visto por kubectl get pods estaba ejecutando en la máquina virtual minikube.

Esperaba que docker ps devolviera la lista de pods atascados en el estado Terminating , pero en realidad ninguno de ellos se estaba ejecutando, pero kubectl get pods estaba devolviendo datos sobre ellos. ¿Alguien podría explicar por qué es eso?

Experimenté este problema con 4 implementaciones. Luego cambié de "volumen local" a "ruta de host" para todos los montajes, y se acabó para mí.

Solo tuve el problema de que las cápsulas no terminaban porque faltaba un secreto. Después de que creé ese secreto en ese espacio de nombres, todo volvió a la normalidad.

¿Cómo se crea un secreto en el espacio de nombres si el espacio de nombres está en estado "Terminando"?

kubectl eliminar --todos los pods --namespace = xxxxx --force --grace-period = 0

funciona para mi.

No te olvides de "--grace-period = 0". Importa

kubectl me advirtió "advertencia: la eliminación inmediata no espera la confirmación de que el recurso en ejecución ha finalizado. El recurso puede continuar ejecutándose en el clúster de manera indefinida". cuando uso --force --grace-period=0 .
¿Alguien puede decirme si realmente sucederá?

de hecho, cuando eliminamos algún pod, es posible que se demore la eliminación por algunas razones
y si ejecutamos "kubectl delete" con la bandera "--force --grace-period = 0",
el objeto de recurso se eliminaría de una vez.

¿Puede ayudarme a confirmar si el pod se eliminará inmediatamente?
¿Significa eso que el mensaje de advertencia es realmente inexacto?

@windoze , si usted --force --grace-period = 0 opción, significa que el objeto API de pod se eliminará del servidor API inmediatamente. Node kubelet es responsable de limpiar los montajes de volumen y matar los contenedores. Si kubelet no se está ejecutando o tiene problemas durante la limpieza del pod, es posible que el contenedor aún se esté ejecutando. Pero Kubelet debería seguir intentando limpiar las vainas siempre que sea posible.

¿Entonces eso todavía significa que la eliminación podría demorar una eternidad porque kubelet podría estar funcionando mal?
¿Hay alguna forma de asegurarse de que se elimine el pod?
Estoy haciendo la pregunta porque tengo algunos pods enormes ejecutándose en el clúster y no hay suficiente memoria en cada nodo para ejecutar 2 instancias de ellos.
Si la eliminación falla, el nodo se vuelve inutilizable, y si este problema ocurre varias veces, el servicio estará completamente inactivo porque eventualmente no habrá ningún nodo que pueda ejecutar este pod.

En un entorno de docker simple y antiguo, puedo forzar la eliminación de un pod con kill -9 o algo así, pero parece que k8s no tiene esa función.

@windoze , ¿sabe por qué a menudo fallaba la eliminación de su pod? ¿Es porque kubelet no se está ejecutando o porque kubelet estaba intentando eliminar el contenedor pero falló con algunos errores?

Tal situación sucedió varias veces en mi clúster hace varios meses, kubelet se estaba ejecutando pero el demonio de la ventana acoplable parecía tener algunos problemas y se atascó sin un registro de errores.
Mi solución fue iniciar sesión en el nodo y forzar la finalización del proceso del contenedor y reiniciar el demonio de la ventana acoplable.
Después de algunas actualizaciones, el problema desapareció y nunca más lo tuve.

kubectl delete pods <podname> --force --grace-period=0 funcionó para mí!

@ shinebayar-g, el problema con --force es que podría significar que su contenedor seguirá funcionando. Simplemente le dice a Kubernetes que se olvide de los contenedores de este pod. Una mejor solución es SSH en la VM que ejecuta el pod e investigar qué está pasando con Docker. Intente eliminar manualmente los contenedores con docker kill y, si tiene éxito, intente eliminar el pod normalmente nuevamente.

@agolomoodysaada Ah, eso tiene sentido. Gracias por la explicación. ¿Entonces realmente no sabría que el contenedor real está realmente eliminado o no es correcto?

Entonces, es el final de 2018, kube 1.12 está disponible y ... ¿todavía tienen problemas con los pods atascados?

Tengo el mismo problema, ya sea --force --grace-period = 0 o --force --now no funciona, los siguientes son los registros:

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOMBRE ESTADO LISTO REINICIA EDAD
node-exporter-zbfpx 0/1 terminando 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat eliminar pod node-exporter-zbfpx --grace-period = 0 --force
advertencia: la eliminación inmediata no espera la confirmación de que el recurso en ejecución ha finalizado. El recurso puede continuar ejecutándose en el clúster de forma indefinida.
pod "node-exporter-zbfpx" eliminado

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOMBRE ESTADO LISTO REINICIA EDAD
node-exporter-zbfpx 0/1 terminando 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat eliminar pod node-exporter-zbfpx --now --force
pod "node-exporter-zbfpx" eliminado

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
NOMBRE ESTADO LISTO REINICIA EDAD
node-exporter-zbfpx 0/1 terminando 0 4d

root @ r15-c70-b03-master01 : ~ #

Intenté editar el pod y eliminar la sección de finalizadores en metadatos, pero también fallé.

Sigo viendo esto de una manera 100% reproducible (mismas definiciones de recursos) con kubectl 1.13 alpha y Docker for Desktop en macOS. Por reproducible me refiero a que la única forma de solucionarlo parece ser restableciendo de fábrica Docker para Mac, y cuando configuro mi clúster nuevamente usando los mismos recursos (script de implementación), el mismo script de limpieza falla.

No estoy seguro de por qué sería relevante, pero mi script de limpieza se ve así:

#!/usr/bin/env bash
set -e

function usage() {
    echo "Usage: $0 <containers|envs|volumes|all>"
}

if [ "$1" = "--help" ] || [ "$1" = "-h" ] || [ "$1" = "help" ]; then
    echo "$(usage)"
    exit 0
fi

if [ $# -lt 1 ] || [ $# -gt 1 ]; then
    >&2 echo "$(usage)"
    exit 1
fi

MODE=$1

function join_with {
    local IFS="$1"
    shift
    echo "$*"
}

resources=()

if [ "$MODE" = "containers" ] || [ "$MODE" = "all" ]; then
    resources+=(daemonsets replicasets statefulsets services deployments pods rc)
fi

if [ "$MODE" = "envs" ] || [ "$MODE" = "all" ]; then
    resources+=(configmaps secrets)
fi

if [ "$MODE" = "volumes" ] || [ "$MODE" = "all" ]; then
    resources+=(persistentvolumeclaims persistentvolumes)
fi

kubectl delete $(join_with , "${resources[@]}") --all

Debido a que el clúster se ejecuta localmente, puedo verificar que no haya contenedores ejecutándose en Docker, es solo kubectl el que se bloquea en los pods de terminación. Cuando describe las vainas, el estado aparece como Status: Terminating (lasts <invalid>)

Me acaba de pasar una vez más. Estaba intentando instalar percona pmm-server con recurso compartido NFS y el software ni siquiera apareció, así que lo eliminé y sucedió. (El reclamo persistente no funcionaba para este software). Supongo que volveré a llamar al viejo kubectl delete pods <podname> --force --grace-period=0 . Pero la pregunta es, ¿cómo sé dónde vive esta cápsula?

@ shinebayar-g, SSH en la VM en la que estaba y ejecuta docker ps .

Bueno, no estaba allí ... Tengo pocas máquinas virtuales, así que pregunté cómo averiguar cuál es la correcta. :)

@ shinebayar-g esto puede funcionar:
kubectl describe pod/some-pod-name | grep '^Node:'

mismo problema.

docker ps encontró que el contenedor está en estado "Muerto" no Salido (0) como se esperaba

Al eliminar manualmente el contenedor, se genera la siguiente entrada de registro de la ventana acoplable:

level=warning msg="container kill failed because of 'container not found' or 'no such process': Cannot kill container 

Lamentablemente la línea está cortada, pero creo recordar que el problema era que el proceso ya no estaba allí.

Todavía me quedo atascado con este problema con k8s v1.11.0. Aquí hay una lista de verificación de lo que hago para limpiar mis cápsulas:

• Asegúrese de que se hayan recuperado todos los recursos que están adjuntos al pod. No todos son visibles en kubectl get ; algunos de ellos solo son conocidos por el Kubelet en el que se está ejecutando el pod, por lo que tendrá que seguir su flujo de registro localmente
  
  
  
  • En particular, umount directorios de los que se queja Kubelet con mensajes device or resource busy
  
  
• Cuando todo lo demás falla, kubectl edit el módulo fallido y eliminar finalizers: → - foregroundDeletion

Dos consejos más:

• En estado estacionario, un Kubelet no confuso no debería registrar ningún mensaje periódico. Cualquier tipo de falla repetida para liberar algo es síntoma de una cápsula atascada.
• puede mantener un comando kubectl delete bloqueado en otra ventana para monitorear su progreso (incluso en un pod que ya ha "eliminado" muchas veces). kubectl delete terminará tan pronto como se libere el último recurso bloqueado.

Frente a esto hoy.
Lo que fue hecho:

1. ssh al nodo y eliminar el contenedor manualmente
2. Después de eso kubectl get pods me muestra cuál es mi contenedor atascado 0/1 terminating (era 1/1 terminating )
3. Eliminar la sección finalizers del pod, mi era foregroundDeletion ($ kubectl editar pod / nombre) -> contenedor eliminado de la lista de pods
4. Eliminar implementación -> todas las cosas relacionadas con la implementación eliminadas.

kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.3", GitCommit:"2bba0127d85d5a46ab4b778548be28623b32d0b0", GitTreeState:"clean", BuildDate:"2018-05-21T09:05:37Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

nos enfrentamos al mismo problema cuando comenzamos a montar secretos (compartidos con muchos pods). La cápsula entra en el estado terminating y permanece allí para siempre. Nuestra versión es la v1.10.0. El contenedor de la ventana acoplable adjunto se ha ido, pero la referencia en el servidor de API permanece a menos que elimine a la fuerza el pod con la opción --grace-period=0 --force .

Buscando una solución permanente.

Bueno, recientemente probé el exploit runc CVE-2019-5736 en mi clúster de ensayo. Como ya saben, el exploit reescribe el binario runc en la máquina host. Su hazaña destructiva. Después de eso, vi un comportamiento extraño en el clúster. Todas las cápsulas se han quedado en estado de terminación. La solución alternativa fue drenar la ventana acoplable de purga de nodos afectados y volver a instalarla. Después de eso, todos los pods y el clúster k8s funcionan normalmente como antes. ¡Tal vez sea un problema de la ventana acoplable y reinstalarlo también resuelva su problema! Gracias

Instalación nueva v1.13.3 aquí. Esto también me pasa a mí. Sucede desde que monté los mismos volúmenes NFS en algunos pods, lo que parece tener algo que ver con eso.

Veo este problema al crear una implementación que intenta crear un volumen usando un secreto que no existe, eliminar esa implementación / servicio deja alrededor de un Terminating pod.

enfrenta el mismo problema con v.1.12.3, y --grace-period = 0 --force o - ahora ambos inválidos, elimine el conjunto de estado que pertenece también inválido

El mismo problema con un montaje SMB (¿creo?) (Azure Files comparte según https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

mismo problema con 13.3

Tengo el mismo problema de que el pod está en estado "Terminando" durante casi 2 días.
Estoy usando Minikube en una máquina Linux (Debian).

Versión de Kubectl:
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:00:57Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Versión de Minikube:
minikube version: v0.34.1

@ardalanrazavi, ¿

@nmors

¿Por qué termina por dos días?

Buena pregunta. A todos nos gustaría saber eso.

Simplemente fuerce la eliminación si no se elimina después de 5 minutos

Eliminarlo por la fuerza deja el clúster en un estado inconsistente. (Con minikube, ese no es su grupo real, es cierto que es mucho menos preocupante)

@AndrewSav

Para ser franco, no veo ninguna otra solución aquí.

Seguro, el clúster quedará en un "estado inconsistente". Me gustaría entender qué quieres decir exactamente con esto. Forzar el cierre es malo. Tampoco me gusta, pero en mi caso, me siento cómodo destruyendo y reasignando cualquier recurso según sea necesario.

En mi caso, parece que solo se atasca al terminar en los pods que tienen un montaje NFS. Y solo sucede cuando el servidor NFS deja de funcionar antes de que el cliente intente hacerlo.

Solucioné el problema, pude aislar que todos los pods atascados terminando estaban todos en un nodo, el nodo se reinició y el problema desapareció.

@nmors @AndrewSav También he forzado la eliminación.

Se sabe que eliminar su servidor nfs antes de eliminar sus pods hace que unmount se cuelgue para siempre. Es mejor ordenar sus eliminaciones en ese caso para que su servidor nfs siempre se elimine en último lugar.

@ msau42 Mi servidor NFS no es parte del clúster k8s, es un dispositivo y una máquina separados todos juntos

No importa si es parte del clúster k8s o no. Si el servidor nfs es inaccesible, desmontar se bloqueará hasta que vuelva a ser accesible.

@ msau42 eso es extraño, porque estoy bastante seguro de que incluso cuando volvió a estar en línea, los pods seguían bloqueados al terminar. las nuevas cápsulas se inician y montan bien.

Utilizo el servidor NFS en kubernetes seguido de este ejemplo y, lamentablemente, esto sucede con bastante frecuencia.

@ shinebayar-g También seguí esa guía, pero ahora me deshice de los PV y PVC y definí mi volumen directamente en la implementación, así:

        volumeMounts:
        - mountPath: /my-pod-mountpoint
          name: my-vol
      volumes:
        - name: my-vol
          nfs:
            server: "10.x.x.x"
            path: "/path/on/server"
            readOnly: false

No he tenido ningún problema desde entonces, cambié esto solo una semana con la esperanza de que la configuración más simple fuera más confiable ... veamos ... ¿Quizás esto solucione el problema?

Como solución temporal, escribí un script que toma algunas últimas líneas de /var/log/syslog y busca errores como "Operación para ... eliminar / var / lib / kubelet / pods ... directorio no vacío" o "nfs. .. el dispositivo está ocupado ... unmount.nfs "o" identificador de archivo NFS obsoleto ".
Luego extrae pod_id o el directorio completo del pod y ve qué montajes tiene (como mount | grep $pod_id ), luego desmonta todo y elimina los directorios correspondientes. Finalmente, kubelet hace el resto y apaga y elimina los pods con elegancia. No más pods en estado de terminación.

Puse ese script en cron para que se ejecute cada minuto. Como resultado, no hay problema por ahora, incluso 3-4 meses después.
Nota : Lo sé, este enfoque no es confiable y requiere verificar cada actualización del clúster, ¡pero funciona!

Estoy usando la versión 1.10 y experimenté este problema hoy y creo que mi problema está relacionado con el problema del volumen secreto de montaje que podría haber dejado alguna tarea pendiente y dejado el pod en estado de terminación para siempre.

Tuve que usar la opción --grace-period = 0 --force para terminar los pods.

root@ip-10-31-16-222:/var/log# journalctl -u kubelet | grep dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179901 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "config-volume" (UniqueName: "kubernetes.io/configmap/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-config-volume") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179935 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "default-token-xjlgc" (UniqueName: "kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-default-token-xjlgc") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: I0320 15:50:31.179953 528 reconciler.go:207] operationExecutor.VerifyControllerAttachedVolume started for volume "secret-volume" (UniqueName: "kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume") pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds" (UID: "e3d7c57a-4b27-11e9-9aaa-0203c98ff31e") Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:31.310200 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:31.810156118 +0000 UTC m=+966792.065305175 (durationBeforeRetry 500ms). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:31 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:31.885807 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:32.885784622 +0000 UTC m=+966793.140933656 (durationBeforeRetry 1s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxxx-com\" not found" Mar 20 15:50:32 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:32.987385 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:34.987362044 +0000 UTC m=+966795.242511077 (durationBeforeRetry 2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:35 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:35.090836 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:39.090813114 +0000 UTC m=+966799.345962147 (durationBeforeRetry 4s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:39 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:39.096621 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:50:47.096593013 +0000 UTC m=+966807.351742557 (durationBeforeRetry 8s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:50:47 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:50:47.108644 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:51:03.10862005 +0000 UTC m=+966823.363769094 (durationBeforeRetry 16s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:51:03 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:51:03.133029 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:51:35.133006645 +0000 UTC m=+966855.388155677 (durationBeforeRetry 32s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:51:35 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:51:35.184310 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:52:39.184281161 +0000 UTC m=+966919.439430217 (durationBeforeRetry 1m4s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxx-com\" not found" Mar 20 15:52:34 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:34.005027 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:52:34 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:34.005085 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:52:39 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:52:39.196332 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:54:41.196308703 +0000 UTC m=+967041.451457738 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:54:41 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:41.296252 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:56:43.296229192 +0000 UTC m=+967163.551378231 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:54:48 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:48.118620 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:54:48 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:54:48.118681 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:56:43 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:56:43.398396 528 nestedpendingoperations.go:267] Operation for "\"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\" (\"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\")" failed. No retries permitted until 2019-03-20 15:58:45.398368668 +0000 UTC m=+967285.653517703 (durationBeforeRetry 2m2s). Error: "MountVolume.SetUp failed for volume \"secret-volume\" (UniqueName: \"kubernetes.io/secret/e3d7c57a-4b27-11e9-9aaa-0203c98ff31e-secret-volume\") pod \"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds\" (UID: \"e3d7c57a-4b27-11e9-9aaa-0203c98ff31e\") : secrets \"data-platform.xxxx-com\" not found" Mar 20 15:57:05 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:57:05.118566 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:57:05 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:57:05.118937 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc] Mar 20 15:59:22 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:59:22.118593 528 kubelet.go:1640] Unable to mount volumes for pod "dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)": timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume config-volume default-token-xjlgc]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]; skipping pod Mar 20 15:59:22 ip-10-31-16-222.eu-west-2.compute.internal kubelet[528]: E0320 15:59:22.118624 528 pod_workers.go:186] Error syncing pod e3d7c57a-4b27-11e9-9aaa-0203c98ff31e ("dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds_default(e3d7c57a-4b27-11e9-9aaa-0203c98ff31e)"), skipping: timeout expired waiting for volumes to attach or mount for pod "default"/"dp-tag-change-ingestion-com-depl-5bd59f74c4-589ds". list of unmounted volumes=[secret-volume config-volume default-token-xjlgc]. list of unattached volumes=[secret-volume config-volume default-token-xjlgc]

Descubrí que si usa --force --grace-period=0 todo lo que hace es eliminar la referencia ... si ingresa al nodo, aún verá los contenedores docker ejecutándose.

En mi caso, había memoria insuficiente en el nodo.
Y el núcleo mató al agente cilio, que parece perturbar la terminación de la vaina.
Acabo de reiniciar el nodo y se borró.

En mi experiencia, sudo systemctl restart docker en el nodo ayuda (pero obviamente hay tiempo de inactividad).

Y esto todavía sucede periódicamente en nodos aleatorios que están A) cerca de los límites de memoria o B) CPU hambrienta (ya sea debido a algún problema de kswapd0 que aún podría estar relacionado con la memoria o con la carga real)

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Los problemas viejos se pudren después de 30 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle rotten .
Los problemas podridos se cierran después de 30 días adicionales de inactividad.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida podrido

Los problemas podridos se cierran después de 30 días de inactividad.
Vuelva a abrir el problema con /reopen .
Marque el problema como nuevo con /remove-lifecycle rotten .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/cerca

@ fejta-bot: Cerrando este problema.

Este es un problema muy activo todavía, k8s 1.15.4 y RHEL Docker 1.13.1. Todo el tiempo, los pods permanecen en Terminating pero el contenedor ya se ha ido y k8s no puede darse cuenta por sí mismo, pero requiere interacción humana. Hace que los scripts de prueba sean un verdadero PITA.

/reabrir
/ eliminar-ciclo de vida podrido

@tuminoid : no puede volver a abrir un problema / RP a menos que sea el autor o un colaborador.

/reabrir
/ eliminar-ciclo de vida podrido

@mikesplain : reabrió este problema.

Lo mismo aquí: vaina atascada en la fase de terminación durante más de 19 minutos. El contenedor se ha terminado correctamente, pero Kubernetes aún cree que debe esperar algo.

Name:                      worker-anton-nginx-695d8bd9c6-7q4l9
Namespace:                 anton
Priority:                  0
Status:                    Terminating (lasts 19m)
Termination Grace Period:  30s
IP:                        10.220.3.36
IPs:                       <none>
Controlled By:             ReplicaSet/worker-anton-nginx-695d8bd9c6
Containers:
  worker:
    Container ID:   docker://12c169c8ed915bc290c14c854a6ab678fcacea9bb7b1aab5512b533df4683dd6
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Terminated
      Exit Code:    0
      Started:      Mon, 01 Jan 0001 00:00:00 +0000
      Finished:     Mon, 01 Jan 0001 00:00:00 +0000
    Ready:          False
    Restart Count:  0
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Events:          <none>

Sin eventos, sin registros ...

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-17T17:16:09Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.8-gke.2", GitCommit:"188432a69210ca32cafded81b4dd1c063720cac0", GitTreeState:"clean", BuildDate:"2019-10-21T20:01:24Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}
a

¿Puede consultar sus registros de kubelet y ver si hay algún mensaje sobre errores de desmontaje de volumen o pods huérfanos?

Yo también he visto esto
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] Pod huérfano "0406c4bf-17e3-4613-a526-34e8a6cee208", pero las rutas de volumen todavía están presentes en el disco: hubo un total de 8 errores similares a este. Sube la verbosidad para verlos.

Yo también lo he visto. No se pueden verificar los registros porque kubectl se queja de que no puede conectarse al contenedor de la ventana acoplable y no puede crear un nuevo pod debido a la existencia actual del pod de terminación. Bastante molesto.

Experimentarlo también y es bastante molesto tener que confirmar si Kubernetes limpió adecuadamente los pods antiguos o no.
Con suerte, esto se solucionará pronto.

¿Y este tema? ¿Se resolvió? Tengo lo mismo, pero esto no comienza a suceder de inmediato, sino algún tiempo después del inicio del nodo, si restablece el nodo, durante un tiempo todo está bien.

¿Podría comprobar si hay finalizadores en el pod que impiden que se elimine?

No hay finalizadores en el grupo emitido

Para su información, resolví esto con una eliminación forzada usando:

kubectl delete pods <pod> --grace-period=0 --force

Y creo que esto logró terminar con éxito la cápsula. Desde entonces no he vuelto a experimentar el problema. Posiblemente me haya actualizado desde entonces, por lo que podría ser un problema de versión, pero no al 100% ya que ha pasado tanto tiempo desde que vi el problema.

Esto me pasa cuando una cápsula se está quedando sin memoria. No termina hasta que el uso de la memoria vuelve a disminuir.

Para su información, resolví esto con una eliminación forzada usando:

kubectl delete pods <pod> --grace-period=0 --force

Y creo que esto logró terminar con éxito la cápsula. Desde entonces no he vuelto a experimentar el problema. Posiblemente me haya actualizado desde entonces, por lo que podría ser un problema de versión, pero no al 100% ya que ha pasado tanto tiempo desde que vi el problema.

Eso funcionó para mi

kubectl delete pods <pod> --grace-period=0 --force es una solución temporal, no quiero ejecutar una solución manual cada vez que haya una conmutación por error para uno de los pods afectados. Mis pods de cuidador del zoológico no terminan en minikube y en Azure AKS.

Actualización 9 de marzo de 2020
Usé un gancho de ciclo de vida preStop para terminar manualmente mis pods. Mis cápsulas de cuidador del zoológico estaban atascadas en un estado de terminación y no respondían a una señal de término desde dentro del contenedor. Básicamente, tenía el mismo manifiesto ejecutándose en otro lugar y todo termina correctamente, sin idea de cuál es la causa raíz.

mismo problema, super molesto

mismo problema :( pods atascados en la terminación, desde 3 días

Para su información, resolví esto con una eliminación forzada usando:

kubectl delete pods <pod> --grace-period=0 --force

Y creo que esto logró terminar con éxito la cápsula. Desde entonces no he vuelto a experimentar el problema. Posiblemente me haya actualizado desde entonces, por lo que podría ser un problema de versión, pero no al 100% ya que ha pasado tanto tiempo desde que vi el problema.

Además, la --force no significa necesariamente que se elimine el pod, simplemente no espera la confirmación (y, según tengo entendido, elimina la referencia). Como se indica en la advertencia The resource may continue to run on the cluster indefinetely .

Editar: estaba mal informado. Consulte el comentario de elrok123s a continuación para obtener más motivación.

Para su información, resolví esto con una eliminación forzada usando:

kubectl delete pods <pod> --grace-period=0 --force

Y creo que esto logró terminar con éxito la cápsula. Desde entonces no he vuelto a experimentar el problema. Posiblemente me haya actualizado desde entonces, por lo que podría ser un problema de versión, pero no al 100% ya que ha pasado tanto tiempo desde que vi el problema.

Además, la --force no significa necesariamente que se elimine el pod, simplemente no espera la confirmación (y, según tengo entendido, elimina la referencia). Como se indica en la advertencia The resource may continue to run on the cluster indefinetely .

Correcto, pero el punto es que --grace-period=0 fuerza a que se elimine :) No estoy seguro de por qué su comentario es relevante: /

Creo que su comentario es relevante porque el contenedor subyacente
(ventana acoplable o lo que sea) puede que aún se esté ejecutando y no se haya eliminado por completo.
la ilusión de que se "eliminó" es un poco engañosa a veces

El jueves 4 de junio de 2020 a las 9:16 a. M., Conner Stephen McCabe <
[email protected]> escribió:

Para su información, resolví esto con una eliminación forzada usando:

kubectl eliminar pods--grace-period = 0 --force

Y creo que esto logró terminar con éxito la cápsula. Desde entonces yo
no he vuelto a experimentar el problema. Posiblemente he actualizado desde entonces,
por lo que podría ser un problema de versión, pero no al 100% ya que ha pasado tanto tiempo
He visto el problema.

Además, la marca --force no significa necesariamente que se elimine el pod,
simplemente no espera la confirmación (y suelta la referencia, a mi
comprensión). Como se indica en la advertencia, el recurso puede continuar ejecutándose
en el grupo de forma indefinida.

Correcto, pero el punto es que --grace-period = 0 fuerza la eliminación a
suceder :) No estoy seguro de por qué su comentario es relevante: /

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

Ese es de hecho mi punto; al usar esto, el método --force corre el riesgo de dejar la carga subyacente sobre sus nodos y no necesariamente soluciona el problema original. En el peor de los casos, es un "Si no puedo verlo, no existe", corrección que puede terminar siendo aún más difícil de detectar.

¿O está diciendo que --grace-period=0 está garantizado para forzar la eliminación del contenedor subyacente, @ elrok123?
Si ese es el caso, mi comentario se basa en un conocimiento defectuoso y es irrelevante, pero si el riesgo de dejar contenedores en ejecución permanece al usar --grace-period=0 lo hace mi punto.

@oscarlofwenhamn Hasta donde yo sé, esto está ejecutando efectivamente sigkill en todos los procesos en ese pod, asegurando la eliminación de los procesos zombies (fuente: Punto 6 en 'Terminación de Pods' - https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = Cuando% 20the% 20grace% 20period% 20 expire, el período% 200% 20 (eliminación% 20 inmediata).), y la eliminación exitosa del pod (puede que no suceda inmediatamente, pero lo hará ocurrir.)

La guía menciona que elimina la referencia, pero no elimina el pod en sí (fuente: 'Forzar eliminación' - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ), sin embargo, el período de gracia = 0 debería eliminar eficazmente su pod, aunque no de inmediato.

Solo estoy leyendo los documentos y las formas recomendadas de manejar el escenario que encontré. El problema que encontré específicamente no fue un problema recurrente, sino algo que sucedió una vez; Creo que la solución REAL para esto es arreglar su implementación, pero hasta que llegue allí, este método debería ayudar.

@ elrok123 Brillante - De hecho, estaba mal informado. Actualicé mi respuesta anterior, haciendo referencia a esta explicación. Gracias por la respuesta detallada y un método más motivado para lidiar con los grupos problemáticos. ¡Salud!

actualmente tienen vainas atascadas durante más de 2 días en estado de terminación.

Para mí, el espacio de nombres está atascado en Terminating . No se enumeran vainas. Sin servicios ... nada. El espacio de nombres está vacío. Aún así ... atrapado en Terminating.

@JoseFMP usa kubectl para solicitar el yaml del espacio de nombres, es posible que tenga finalizadores que retrasen el proceso.

@JordyBottelier Gracias.

Sin finalizadores. Aún atascado Terminating

@JoseFMP aquí hay una secuencia de comandos para eliminarlo por completo (destruirlo de manera efectiva), simplemente guárdelo y ejecútelo ./script_name:
''

! / bin / bash

set -eo pipefail

die () {echo "$ *" 1> & 2; salida 1; }

necesitar() {
cuál "$ 1" &> / dev / null || muere "Falta el '$ 1' binario, pero es obligatorio"
}

comprobar los requisitos previos

necesita "jq"
necesito "rizo"
necesita "kubectl"

PROYECTO = "$ 1"
cambio

prueba -n "$ PROJECT" || die "Faltan argumentos: kill-ns"

proxy kubectl &> / dev / null &
PROXY_PID = $!
killproxy () {
matar $ PROXY_PID
}
trampa killproxy EXIT

dormir 1 # darle al proxy un segundo

kubectl obtiene el espacio de nombres "$ PROJECT" -o json | jq 'del (.spec.finalizers [] | select ("kubernetes"))' | curl -s -k -H "Tipo de contenido: aplicación / json" -X PUT -o / dev / null --data-binary @ - http: // localhost : 8001 / api / v1 / namespaces / $ PROJECT / finalize && echo "Espacio de nombres eliminado: $ PROJECT" `` `

Aparentemente, también me encontré con esto, con varios pods atascados en la terminación, incluido un pod que ya no es visible en ninguna parte de mi infraestructura pero que aún se ejecuta como un fantasma (atiende solicitudes y puedo ver solicitudes que se atienden incluso con una escala de implementación de cero).

No tengo visibilidad ni control sobre este módulo y pregunto cómo se supone que debo solucionar una situación como esta sin cerrar todos los nodos a la fuerza.

Aparentemente, también me encontré con esto, con varios pods atascados en la terminación, incluido un pod que ya no es visible en ninguna parte de mi infraestructura pero que aún se ejecuta como un fantasma (atiende solicitudes y puedo ver solicitudes que se atienden incluso con una escala de implementación de cero).

No tengo visibilidad ni control sobre este módulo y pregunto cómo se supone que debo solucionar una situación como esta sin cerrar todos los nodos a la fuerza.

tendrás que acceder a la ventana acoplable en el nodo.
Puede usar mi dink (https://github.com/Agilicus/dink) que mostrará un pod con un shell con acceso a la ventana acoplable, o ssh al pod.
docker ps -a
docker stop ####

buena suerte.

Gracias por la dirección.

Finalmente pude resolver esto, pero todavía un poco desconcertado de cómo podría suceder (para mí, la cápsula era completamente invisible). Como estaba en producción, las cosas estaban un poco agitadas y no pude realizar diagnósticos, pero si vuelve a ocurrir, espero poder hacer un mejor informe de errores.

Al ver un síntoma similar, las vainas se atascaron al terminar (curiosamente, todas tienen una sonda de tipo ejecutivo para la preparación / vivacidad). Al mirar los registros, puedo ver: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] Sonda de preparación para "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): prueba -servicio "falló (fallo): ejecución de OCI error de ejecución: error de ejecución: no se puede ejecutar un contenedor que se ha detenido: desconocido. Este mensaje se repite para siempre y el cambio de la sonda ejecutiva a tcpSocket parece permitir que el pod termine (según una prueba, se hará un seguimiento). El pod parece tener uno de los contenedores "En ejecución" pero no "Listo", los registros del contenedor "En ejecución" se muestran como si el servicio se detuviera.

Esto sucede en containerd 1.4.0 cuando la carga del nodo es alta y vm.max_map_count se establece en un valor más alto que el predeterminado, el containerd-shim no drena la salida estándar y los bloques esperando a que se drene, mientras que dockerd no logra obtener la evento / reconocimiento de containerd que los procesos se han ido.

@discanto gracias por compartir esta información. ¿Se está solucionando o realizando un seguimiento del problema?

@ Random-Liu

El error lleva abierto más de 3 años. Los pods atascados al terminar pueden deberse a varias razones. Al informar su caso, sería muy útil publicar algunos de los registros de kubelet para ver si los pods se atascaron.