此表格仅用于错误报告和功能请求！ 如果您在寻求帮助，请查看[堆栈溢出]（https://stackoverflow.com/questions/tagged/kubernetes）和[故障排除指南]（https://kubernetes.io/docs/tasks/debug-application-群集/问题排查/）。
这是错误报告还是功能请求？ ：
/种类错误
发生了什么：
荚卡住了很长时间
您预期会发生什么：
吊舱终止
如何复制它（尽可能少且精确） ：
- 运行部署
- 删除它
- 豆荚仍在终止
我们还需要知道什么吗？ ：
删除后，Kubernetes吊舱以Terminating身份停留了几个小时。
日志：
kubectl描述吊舱my-pod-3854038851-r1hc3
Name: my-pod-3854038851-r1hc3
Namespace: container-4-production
Node: ip-172-16-30-204.ec2.internal/172.16.30.204
Start Time: Fri, 01 Sep 2017 11:58:24 -0300
Labels: pod-template-hash=3854038851
release=stable
run=my-pod-3
Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"container-4-production","name":"my-pod-3-3854038851","uid":"5816c...
prometheus.io/scrape=true
Status: Terminating (expires Fri, 01 Sep 2017 14:17:53 -0300)
Termination Grace Period: 30s
IP:
Created By: ReplicaSet/my-pod-3-3854038851
Controlled By: ReplicaSet/my-pod-3-3854038851
Init Containers:
ensure-network:
Container ID: docker://guid-1
Image: XXXXX
Image ID: docker-pullable://repo/ensure-network<strong i="27">@sha256</strong>:guid-0
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: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xxxxx (ro)
Containers:
container-1:
Container ID: docker://container-id-guid-1
Image: XXXXX
Image ID: docker-pullable://repo/container-1<strong i="28">@sha256</strong>:guid-2
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
Limits:
cpu: 100m
memory: 1G
Requests:
cpu: 100m
memory: 1G
Environment:
XXXX
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xxxxx (ro)
container-2:
Container ID: docker://container-id-guid-2
Image: alpine:3.4
Image ID: docker-pullable://alpine<strong i="29">@sha256</strong>:alpine-container-id-1
Port: <none>
Command:
X
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
Limits:
cpu: 20m
memory: 40M
Requests:
cpu: 10m
memory: 20M
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xxxxx (ro)
container-3:
Container ID: docker://container-id-guid-3
Image: XXXXX
Image ID: docker-pullable://repo/container-3<strong i="30">@sha256</strong>:guid-3
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
Limits:
cpu: 100m
memory: 200M
Requests:
cpu: 100m
memory: 100M
Readiness: exec [nc -zv localhost 80] delay=1s timeout=1s period=5s #success=1 #failure=3
Environment:
XXXX
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xxxxx (ro)
container-4:
Container ID: docker://container-id-guid-4
Image: XXXX
Image ID: docker-pullable://repo/container-4<strong i="31">@sha256</strong>:guid-4
Port: 9102/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
Limits:
cpu: 600m
memory: 1500M
Requests:
cpu: 600m
memory: 1500M
Readiness: http-get http://:8080/healthy delay=1s timeout=1s period=10s #success=1 #failure=3
Environment:
XXXX
Mounts:
/app/config/external from volume-2 (ro)
/data/volume-1 from volume-1 (ro)
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xxxxx (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
volume-1:
Type: Secret (a volume populated by a Secret)
SecretName: volume-1
Optional: false
volume-2:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: external
Optional: false
default-token-xxxxx:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-xxxxx
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
须藤journalctl -u kubelet | grep“ my-pod”
[...]
Sep 01 17:17:56 ip-172-16-30-204 kubelet[9619]: time="2017-09-01T17:17:56Z" level=info msg="Releasing address using workloadID" Workload=my-pod-3854038851-r1hc3
Sep 01 17:17:56 ip-172-16-30-204 kubelet[9619]: time="2017-09-01T17:17:56Z" level=info msg="Releasing all IPs with handle 'my-pod-3854038851-r1hc3'"
Sep 01 17:17:56 ip-172-16-30-204 kubelet[9619]: time="2017-09-01T17:17:56Z" level=warning msg="Asked to release address but it doesn't exist. Ignoring" Workload=my-pod-3854038851-r1hc3 workloadId=my-pod-3854038851-r1hc3
Sep 01 17:17:56 ip-172-16-30-204 kubelet[9619]: time="2017-09-01T17:17:56Z" level=info msg="Teardown processing complete." Workload=my-pod-3854038851-r1hc3 endpoint=<nil>
Sep 01 17:19:06 ip-172-16-30-204 kubelet[9619]: I0901 17:19:06.591946 9619 kubelet.go:1824] SyncLoop (DELETE, "api"):my-pod-3854038851(b8cf2ecd-8f25-11e7-ba86-0a27a44c875)"
sudo journalctl -u泊坞窗| grep“我的Pod的docker-id”
Sep 01 17:17:55 ip-172-16-30-204 dockerd[9385]: time="2017-09-01T17:17:55.695834447Z" level=error msg="Handler for POST /v1.24/containers/docker-id-for-my-pod/stop returned error: Container docker-id-for-my-pod is already stopped"
Sep 01 17:17:56 ip-172-16-30-204 dockerd[9385]: time="2017-09-01T17:17:56.698913805Z" level=error msg="Handler for POST /v1.24/containers/docker-id-for-my-pod/stop returned error: Container docker-id-for-my-pod is already stopped"
环境：
- Kubernetes版本（使用
kubectl version）：
客户端版本：version.Info {主要：“ 1”，次要：“ 7”，GitVersion：“ v1.7.3”，GitCommit：“ 2c2fe6e8278a5db2d15a013987b53968c743f2a1”，GitTreeState：“ clean”，BuildDate：“ 2017-08-03T15：13： 53Z”，GoVersion：“ go1.8.3”，编译器：“ gc”，平台：“ darwin / amd64”}
服务器版本：version.Info {主要：“ 1”，次要：“ 6”，GitVersion：“ v1.6.6”，GitCommit：“ 7fa1c1756d8bc963f1a389f4a6937dc71f08ada2”，GitTreeState：“ clean”，BuildDate：“ 2017-06-16T18：21： 54Z“，GoVersion：” go1.7.6“，编译器：” gc“，平台：” linux / amd64“}
云提供商或硬件配置**：
AWS操作系统（例如，从/ etc / os-release）：
NAME =“ CentOS Linux”
VERSION =“ 7（Core）”
ID =“ centos”
ID_LIKE =“ rhel fedora”
VERSION_ID =“ 7”
PRETTY_NAME =“ CentOS Linux 7（Core）”
ANSI_COLOR =“ 0; 31”
CPE_NAME =“ cpe：/ o： centos：centos ：7”
HOME_URL =“ https://www.centos.org/ ”
BUG_REPORT_URL =“ https://bugs.centos.org/ ”
CENTOS_MANTISBT_PROJECT =“ CentOS-7”
CENTOS_MANTISBT_PROJECT_VERSION =“ 7”
REDHAT_SUPPORT_PRODUCT =“ centos”
REDHAT_SUPPORT_PRODUCT_VERSION =“ 7”
内核（例如
uname -a）：
Linux ip-172-16-30-204 3.10.0-327.10.1.el7.x86_64＃1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux安装工具：
科普斯其他：
Docker版本1.12.6，内部版本78d1802
@ kubernetes / sig-aws @ kubernetes / sig-scheduling
igorleao
所有181条评论
@ kubernetes / sig-aws @ kubernetes / sig-scheduling
igorleao
于 2017-09-02
通常，卷和网络清理会在终止中花费更多时间。 您可以找到豆荚卡在哪个阶段？ 例如卷清理？
resouer
于 2017-09-03
通常，卷和网络清理会在终止中花费更多时间。
正确。 他们总是怀疑。
@igorleao您也可以尝试kubectl delete pod xxx --now 。
dixudx
于 2017-09-03
嗨@resouer和@dixudx
我不确定。 查看kubelet日志以查找具有相同问题的其他Pod，我发现：
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.
如您所见，该集群具有Calico for CNI。
以下几行引起了我的注意：
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
有没有更好的方法来找出豆荚卡在哪个阶段？
kubectl delete pod xxx --now似乎运行良好，但是我真的很想找出其根本原因并避免人为干预。
igorleao
于 2017-09-04
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
似乎kubelet/mount由于这种文件重命名而无法将configmap挂载为卷。
@igorleao这是可复制的吗？ 还是不稳定，偶尔会发生。 我以前遇到过这样的错误，只是为了确保。
dixudx
于 2017-09-04
@dixudx对于特定群集一天会发生几次。 在同一周内使用相同版本的kops和kubernetes创建的其他集群也可以正常工作。
igorleao
于 2017-09-04
@igorleao日志显示由于设备繁忙，卷管理器无法删除
您能否检查/var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key目录是否仍然挂载？ 谢谢！
jingxu97
于 2017-09-13
@igorleao您如何运行kubelet？ 在容器中？ 如果可以的话，您可以为kubelet发布您的systemd单元或docker config吗？
我们看到了类似的行为。 我们将kubelet作为容器运行，并且通过共享安装/var/lib/kubelet （默认情况下docker mounts volume为rslave）来部分缓解问题。 但是，我们仍然看到类似的问题，但频率较低。 目前，我怀疑应该以其他方式进行其他挂载（例如/var/lib/docker或/rootfs ）
r7vme
于 2017-09-26
@stormltf您能否发布您的kubelet容器配置？
r7vme
于 2017-09-28
@stormltf，您在容器中运行kubelet，并且不使用--containerized标志（这对mount具有一些技巧）。 基本上，这意味着kubelet所做的所有安装都将在容器安装名称空间中完成。 好的是，它们将被提议回到主机的名称空间（因为您将/ var / lib / kubelet共享），但是我不确定删除名称空间会发生什么（当删除kubelet容器时）。
您能为卡住的豆荚做些什么吗？
在运行pod的节点上
docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"- 和节点本身
mount | grep STUCK_POD_UUID。
对于新创建的广告连播，请也执行相同的操作。 我期望看到一些/var/lib/kubelet挂载（例如default-secret）
r7vme
于 2017-09-29
@stormltf您是否在创建前两个Pod之后重新启动kubelet？
r7vme
于 2017-10-11
@stormltf您可以尝试将/var/lib/docker和/rootfs为共享（我在您的docker inspect中看不到，但在容器内部看到）挂载点。
r7vme
于 2017-10-12
/ sig存储
ianchakeres
于 2017-10-22
对于某些人可能会有所帮助。 我们在带有--containerized标志的docker容器中运行kubelet，并且能够通过将/rootfs ， /var/lib/docker和/var/lib/kubelet作为共享安装来解决此问题。 最终安装座看起来像这样
-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/ \
有关更多详细信息。 这不能正确解决问题，因为对于每个绑定安装，您将在kubelet容器中获得3个安装（2个寄生虫）。 但是至少共享的安装允许轻松地一次卸载它们。
CoreOS没有这个问题。 因为对kubelet容器使用rkt而不是docker。 如果我们的情况kubelet在Docker中运行并且kubelet continer中的每个装载都被提议为/var/lib/docker/overlay/...和/rootfs ，这就是为什么每个绑定装载卷都有两个寄生虫装载：
/rootfs中的/rootfs/var/lib/kubelet/<mount>/var/lib/docker中的/var/lib/docker/overlay/.../rootfs/var/lib/kubelet/<mount>
r7vme
于 2017-10-23
-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
stormltf
于 2017-10-25
我在Azure上使用Kubernetes 1.8.1遇到了同样的问题-更改部署并启动新的Pod之后，旧的Pod会终止。
tadas-subonis
于 2017-11-20
我在IBM Cloud的Kubernetes 1.8.2上遇到相同的问题。 新的Pod启动后，旧的Pod会终止。
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"}
我已使用kubectl delete pod xxx --now以及kubectl delete pod foo --grace-period=0 --force无济于事。
wardhane
于 2017-11-24
如果根本原因仍然相同（建议的安装方式不正确），则这是特定于发行版的错误imo。
请描述如何在IBM Cloud中运行kubelet？ 系统单位？ 它有--containerized标志吗？
r7vme
于 2017-11-24
它在--containerized标志设置为false的情况下运行。
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
--containerized标志：否
wardhane
于 2017-11-24
好的，我需要更多信息，请参阅上面的评论https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349
并且还请显示/lib/systemd/system/kubelet.service ，如果/etc/systemd/system有关于kubelet的任何内容，也请分享。
特别是，如果kubelet在docker中运行，我想查看所有绑定挂载-v 。
r7vme
于 2017-11-24
今天，我遇到了一个可能与所描述的问题相同的问题，在该问题中，我们的一个客户系统上的豆荚陷入了几天的终止状态。 我们还看到了有关“错误：卷的UnmountVolume.TearDown失败”的错误，并对每个卡住的Pod重复了“设备或资源繁忙”。
在我们的案例中，这似乎是docker在此Moby问题所涵盖的基于RHEL / Centos 7.4的系统上的一个问题： https : https：// github .com / moby / moby / pull / 34886 / files
对于我们来说，一旦我们在几分钟之内将sysctl选项设置为fs.may_detach_mounts = 1，便会清理掉所有Termination pod。
knisbet
于 2017-11-29
我也面临着这个问题：在1.8.3上，豆荚陷入了终止状态。
来自节点的相关kubelet日志：
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在Ubuntu 16.04上作为systemd单元（不在容器中）运行。
如您所见，有一个到NFS服务器的挂载，kubelet以某种方式尝试删除该挂载目录，因为它认为该目录是未挂载的。
吊舱的体积规格：
volumes:
- name: nfs-mtkylje2oc4xlju1ls9rdwjlcmxhyi1ydw
nfs:
path: /<path>
server: <IP>
- name: default-token-rzqtt
secret:
defaultMode: 420
secretName: default-token-rzqtt
UPD ：我在1.6.6之前也遇到过此问题
nmakhotkin
于 2017-11-29
在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
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"}
描述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
须藤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"}
猫/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
sabbour
于 2017-11-29
看起来有与问题相关的不同错误。 我们都在1.8.3集群上。
- https://github.com/moby/moby/issues/31768。这是docker bug。 在docker-ce = 17.09.0〜ce-0〜ubuntu上可重现。
- 第二个更有趣，可能与kubelet内部的某些比赛条件有关。
我们有很多Pod在容器安装中使用带有指定子路径的NFS持久性卷，以某种方式删除了部署之后，其中一些卡在了终止状态。 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
而且它的真实目录不是空的，它已卸载并且包含我们的“ subpath”目录！
此类行为的一种解释：
- P1：开始创建Pod或同步Pod
- P1：将信号发送到音量管理器以进行安装/重新安装。
- P1：正在等待安装完成。
- P1：接收成功安装信号（实际上只是检查是否已安装所有卷）
- 卷以某种方式卸载。 可能是卸载该文件的另一个删除过程，某个操作系统的错误或某些垃圾回收器的操作。
- P1：继续创建容器，并在安装点创建子目录（已卸载）。
- 上一步之后，由于安装目录不为空，因此无法删除pod。
dreyk
于 2017-12-05
更多日志：
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
当pod处于初始化状态时，某些清理过程（（dswp * desiredStateOfWorldPopulator）findAndRemoveDeletedPods（））开始卸载卷：
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"
初始化和删除pod在同一时间执行。
要重复此错误，您应该开始并立即删除/更新大约10个部署（已针对单个爪牙进行了测试），并且也许您的挂载操作可能不是很快。
dreyk
于 2017-12-07
受GKE上的同一错误影响。 是否有解决此问题的已知方法？ 使用--now不起作用。
gm42
于 2018-01-10
我已修复此错误，但我不确定kubernetes团队会合并该错误。
dreyk
于 2018-01-10
@dreyk您能否提供更多有关此错误的发现信息以及更正的内容的详细信息，以便存储团队看看？ 谢谢！
jingxu97
于 2018-01-10
@ gm42我可以通过以下方式在GKE上手动解决此问题：
- SSH进入计划在其上停留的Pod的节点
- 运行
docker ps | grep {pod name}以获取Docker容器ID - 正在运行
docker rm -f {container id}
alexmunda
于 2018-01-22
在GKE上，升级节点可立即提供帮助。
rahmonov
于 2018-02-02
使用kubeadm在本地群集上设置了相同的错误。
节点上的docker ps | grep {pod name}显示任何内容，并且pod处于终止状态。 我目前在这种状态下有两个豆荚。
如何强制删除窗格？ 或更改吊舱名称？ 我不能用相同的名字旋转另一个吊舱。 谢谢！
z-oo
于 2018-02-03
我在我的1.7.2群集中找到了原因，
因为另一个监视程序安装了根路径/
根路径包含/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
因此，当kubelet删除pod，但无法释放该卷时，消息为：
设备或资源繁忙
脚步：
1）sudo journalctl -u kubelet
这个shell帮我找到错误讯息，
2）sudo docker检查
找到io.kubernetes.pod.uid“：” ddc66e10-0711-11e8-b905-6c92bf70b164“
和
HostConfig->绑定->“ /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
根90225 1.3 0.0 2837164 42580 Ssl Feb01 72:40 ./monitor_program
在我的1.7.2上有相同的错误
为卷“ default-token-bnttf”（唯一名称：“ kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf”）启动了operationExecutor.UnmountVolume）窗格“ ddc66e10-0711-11e8-b905- 6c92bf70b164“ kubelet [94382]：E0205 11：35：50.509169 94382 nestedpendingoperations.go：262]” \“ kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf \”（\\ “ ddc66e10-0711-11e8-b905-6c92bf70b164 \”）失败。 直到2018-02-05 11：37：52.509148953 +0800 CST（durationBeforeRetry 2m2s）才允许重试。 错误：卷“ default-token-bnttf” （唯一名称：“ kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf”）的设备或资源繁忙
allenhaozi
于 2018-02-05
重新启动docker服务会释放锁，并且吊舱会在几分钟内被移除。 这是一个错误。 使用docker 17.03
rambo45
于 2018-02-08
在Azure，Kube 1.8.7上的同一问题
alexvicegrab
于 2018-03-02
几分钟前也发生在我们的1.8.9上，有人要解决吗？ 重新启动docker会有所帮助，但这有点荒谬。
sokoow
于 2018-03-23
在GKE的最新1.9.4版本中，这已经发生了很多事情。 现在正在这样做：
kubectl delete pod NAME --grace-period=0 --force
zackify
于 2018-03-23
GKE 1.9.4-gke.1上的相同问题
似乎与卷安装有关。
每次按如下所述设置文件信号时都会发生这种情况：
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat
Kubelet日志显示以下内容：
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
似乎有效。
也可以重新启动kubelet。
nodefactory-bk
于 2018-03-23
GKE 1.9.4-gke.1上的相同问题
仅发生在特定的filebeat守护程序集上，但是重新创建所有节点也无济于事，只是不断发生。
Tapppi
于 2018-03-26
也达不到这个问题上GKE 1.9.4-gke.1像@Tapppi -舱体从主机节点上的码头工人守护进程中删除，但kubernetes有它停留在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
Stono
于 2018-03-28
对我们来说，刚才发生了一些新情况，当我使用kubectl delete pod NAME --grace-period=0 --force强行卸下卡住的吊舱时，该吊舱所在的节点刚刚不正常。 我们正在运行docker 17-12CE，并在该机器上重启docker deamon帮助并解开了节点。
sokoow
于 2018-03-28
对于在1.9.4-gke.1上看到此问题的人来说，最有可能是由于https://github.com/kubernetes/kubernetes/issues/61178 （已在1.9.5中修复并在GKE中推出）本星期。 该问题与文件（而非目录）的子路径装载的清除有关。 @zackify @ nodefactory-bk @Tapppi @Stono
IIUC，此错误中的原始问题与容器化kubelet的配置有关，这有所不同。
msau42
于 2018-03-28
顺便说一句，为此创建一个版本v1.9.3-gke.0的新节点池是我们的解决方法，因为v1.9.5尚未在gke上推出，已经是复活节了。
Tapppi
于 2018-03-31
有人可以确认此问题已在1.9.3+版本中修复吗？ 由于这种行为，我们遇到了一些严重的麻烦，每次发生这种情况时重新启动docker都是st00pid。
sokoow
于 2018-04-04
为我修复了1.9.6
在2018年4月4日星期三上午10:43索科夫， notifications @ github.com写道：
有人可以确认此问题已在1.9.3+版本中修复吗？ 我们有
由于这种行为会造成一些严重的麻烦，然后重新启动每个docker
发生这种情况的时间太短了。-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
。
Stono
于 2018-04-04
好的，谢谢@Stono 。 这里还要确认一件事。 这是用于容器化kubelet的kubespray模板：
#!/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 \
"$@"
看起来还好吗？ 有人在使用类似的东西吗？
sokoow
于 2018-04-04
我说得太早了。
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
不得不以野蛮的方式摧毁它。
❯ 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您使用的是哪个
sokoow
于 2018-04-04
我在Azure AKS托管群集的1.9.6上仍然遇到此问题。
现在使用此变通办法来选择所有卡住的Pod并将其删除（因为我最终在我的dev / scratch集群中出现了许多Terminate Pod）
kubectl get pods | awk '$3=="Terminating" {print "kubectl delete pod " $1 " --grace-period=0 --force"}' | xargs -0 bash -c
在Azure和AWS群集上都遇到了此问题-解决方法由Mike Elliot提供
https://jira.onap.org/browse/OOM-946
ubuntu @ ip-10-0-0-22 ：〜$ kubectl获取容器--all-namespaces
名称空间名称就绪状态重启年龄
kube-system heapster-76b8cd7b5-4r88h 1/1运行0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3运行0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1正在运行0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1运行0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1正在运行0 25d
kube-system耕种机部署-cc96d4f6b-jzqmz 1/1运行0 25d
onap dev-sms-857f6dbd87-pds58 0/1终止0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1终止0 3h
ubuntu @ ip-10-0-0-22 ：〜$ kubectl删除pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
警告：立即删除不会等待确认正在运行的资源已终止。 资源可能会无限期地继续在群集上运行。
pod“ dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp”已删除
ubuntu @ ip-10-0-0-22 ：〜$ kubectl获取容器--all-namespaces
名称空间名称就绪状态重启年龄
kube-system heapster-76b8cd7b5-4r88h 1/1运行0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3运行0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1正在运行0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1运行0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1正在运行0 25d
kube-system耕种机部署-cc96d4f6b-jzqmz 1/1运行0 25d
onap dev-sms-857f6dbd87-pds58 0/1终止0 3h
ubuntu @ ip-10-0-0-22 ：〜$ kubectl删除pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
警告：立即删除不会等待确认正在运行的资源已终止。 资源可能会无限期地继续在群集上运行。
pod“ dev-sms-857f6dbd87-pds58”已删除
ubuntu @ ip-10-0-0-22 ：〜$ kubectl获取容器--all-namespaces
名称空间名称就绪状态重启年龄
kube-system heapster-76b8cd7b5-4r88h 1/1运行0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3运行0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1正在运行0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1运行0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1正在运行0 25d
kube-system耕种机部署-cc96d4f6b-jzqmz 1/1运行0 25d
obriensystems
于 2018-04-17
我不确定这是否是相同的问题，但是我们已经开始注意到此行为_since_从1.9.3升级到10.10.1。 在那之前从未发生过。 我们正在使用带有SubPath的glusterfs卷。 Kubelet连续记录诸如
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"
而lsof确实表明glusterfs卷下的目录仍在使用中：
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
在1.9.3上一切都很好，所以似乎此问题的修复程序破坏了我们的用例:(
ross-w
于 2018-04-23
@ ross-w此签名看起来与其他签名不同。 您可以打开一个新期刊，还包含您的广告连播规范吗？
msau42
于 2018-04-23
这些问题有任何更新吗？
在我们的案例中（Kubernetes 1.9.7，docker 17.03），在节点内存不足并重新安排Pod之后，pod处于终止状态。 最终，在kubernetes仪表板和“部署”选项卡中，有很多“幽灵”吊舱，我们可以看到带有4/1吊舱的部署。
重新启动kubelet或杀死命名空间中的所有Pod都有帮助，但这是非常糟糕的解决方案。
Adiqq
于 2018-05-12
@Adiqq因为Docker本身存在问题。
看一看您节点上的journalctl -u kubelet -f 。 我收到类似“无法杀死容器的消息
为了解决这个问题，我在每个注释上都重新启动了docker。 在启动处于损坏状态的Docker干净容器期间，请删除所有这些过时的容器。
tuarrep
于 2018-05-14
我昨天在1.9.7中遇到了这个问题，一个豆荚处于终止状态，并且在日志中它只是“需要杀死豆荚”，我不得不--force --grace-period=0摆脱。
Stono
于 2018-05-15
刚获得1.9.7-gke.0也是如此。
1.9.6-gke.1没有问题。
但是确实有1.9.4和1.9.5
卡住的吊舱已连接PV。
nodefactory-bk
于 2018-05-16
重新部署或删除吊舱具有相同的效果。
在有问题的节点上重新启动kubelet无效。 kubelet没有再次启动，我不得不重新启动整个节点。
在此期间，无法将Pod安排在其他任何节点上，因为它说PV已安装在其他位置。
nodefactory-bk
于 2018-05-16
@Stono @ nodefactory-bk你们可以看看有问题的节点上的kubelet日志，看看是否有任何详细的日志可以指出问题？
msau42
于 2018-05-23
抄送@dashpole
dashpole
于 2018-05-23
只是有一个应用陷入终止。
这是在1.9.7-gke.1上
这是kubectl描述已编辑秘密的pod：
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
不确定在Google图片上的gke中在哪里可以找到kubelet.log。 找到了我要附加的内容。
kube.log
kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
杀死并删除了它。
此后开始一切正常，但花费的时间比平常多一点。
nodefactory-bk
于 2018-05-23
提醒您，这种情况并非每次都发生。
我大概说大约1/4倍。
nodefactory-bk
于 2018-05-23
使用k8s 1.9.6达到此目的时，当kubelet无法卸载Cephfs挂载时，节点上的所有Pod将永远终止。 必须重启节点才能恢复，kubelet或docker restart并没有帮助。
tuminoid
于 2018-05-23
@tuminoid ceph问题听起来不同。 您可以打开一个新期刊，并提供该Pod的Pod事件和kubelet日志吗？
msau42
于 2018-05-23
仅供参考，将集群更新（至k8s v1.10.2）似乎已为我们消除了此问题。
darose
于 2018-05-25
附件在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"}
运行它，然后将其删除。 您将获得一个“ nfs-client”，无法删除。 原因是在节点上进行了硬安装，并且首先删除了“服务器”。
donbowman
于 2018-05-27
@donbowman对于首先删除nfs服务器的nfs卸载问题，可以在StorageClass或PV中设置“软”安装选项。
msau42
于 2018-05-29
我没看到吗？ 我可以在PersistentVolumeClaim上进行设置，但这不适用于此处。
我认为StorageClass在这里不适用（那是nfs服务器下方的磁盘下方）。
问题在nfs-client上。
我想念什么吗？
donbowman
于 2018-05-29
对于nfs PV，您可以设置从1.8开始的mountOptions字段以指定软安装。 如果动态配置nfs卷，也可以在StorageClass.mountOptions中进行设置
msau42
于 2018-05-29
是的，但不是通过NFS安装的PV。
它来自我的NFS服务器容器。
没有动态配置。
这是使用Google GCP + GKE。 PVC选择了作为块IO的PV，将其作为ext4安装到容器中，然后将其与NFS一起重新导出。
第二组容器是从nfs-server（本身是一个pod）安装的，它们不将其视为PV。 他们将其视为如下所示的体积。
我没有看到使该nfs-client在挂载中看到“ pvc”的方法，因此无法设置挂载选项。 我也不能将其视为StorageClass。
我想念什么吗？
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用于使用nfs挂载的第二组容器，您可以使用mountOptions设置为该nfs卷手动创建PV，并在所有吊舱中共享该nfs PV的PVC。 不涉及动态配置。
msau42
于 2018-05-29
像这样：
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
谢谢！ 这样就可以了（从某种意义上说，现在是软安装），但不能解决问题：
挂载（在节点上观察到）现在很软：
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)
但是，当我删除整个内容时，我仍然使nfs-client永远陷入终止状态。
附件是我使用的Yaml。 我做了一个“创建”，等待它出现，观察到客户端已经挂载了，可以在其中读取/写入文件，然后对它进行了“删除”。
nfs-server pod会被删除，但nfs-client不会被删除。
在吊舱上看，坐骑一直保持着：
# 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啊，很抱歉，关于软选项我错了。 soft选项仅防止在无法访问服务器时挂起文件系统调用，但实际上并没有帮助卸载nfs卷。 为此，需要进行强制卸载，而我们目前尚无法通过。 现在，您必须手动清理这些安装并确保以正确的顺序删除Pod（首先是nfs客户端，然后是nfs服务器）。
msau42
于 2018-05-30
我尝试添加timeo = 30和intr，但是同样的问题。
这将其锁定，必须登录到该节点并在基础安装上执行umount -f -l，然后可以在pod上执行kubectl delete --force --grace-period 0。
好像是因为它是代表Pod挂载的，因此可以在自动删除时进行umount（或在超时后强制umount）。
donbowman
于 2018-05-30
我有一堆这样的Pod，所以我不得不提出一个命令来清理所有终止的pod：
kubectl get pods -o json | jq -c '.items[] | select(.metadata.deletionTimestamp) | .metadata.name' | xargs -I '{}' kubectl delete pod --force --grace-period 0 '{}'
我认为，对于Google的新文件存储，我们将遇到同样的问题，没有麻烦。
donbowman
于 2018-06-27
@donbowman iirc，您的问题是因为您要在nfs客户端容器之前终止nfs服务器容器。 如果使用文件存储，则不再需要Pod来托管nfs服务器，因此只要不删除整个Firestore实例，就不会出现此问题。
msau42
于 2018-06-27
如果我正在编排文件存储，我会不会遇到同样的问题？ 例如，如果我要为特定的kubernetes部署启动它，然后在最后关闭，则不能保证顺序。
但我也认为问题不仅仅在于命令，nfs客户端pod删除根本没有卸载，它只是使挂接悬挂在节点上。 因此，无论文件存储/服务器是否存在，都存在悬挂的挂载。
donbowman
于 2018-06-27
当Pod终止时，我们将卸载该卷（假设服务器仍在该卷中）。 如果即使服务器存在，您仍然看到悬挂的挂载，那是一个错误。
如果您对PVC和PV使用动态预配置，那么在所有引用它的Pod都已使用完PVC之前，我们不允许删除PVC（及其基础存储）。 如果要自己编排配置，则需要确保在所有吊舱都已使用完服务器之前，不要删除服务器。
msau42
于 2018-06-27
也许这是一种可能的解决方法：＃65936
jomeier
于 2018-07-07
强制删除适用于kubectl delete po $pod --grace-period=0 --force 。 --now标志无效。 我不确定＃65936，但我想在Unknown状态发生时不杀死该节点。
webbrandon
于 2018-07-09
在1.10.5上有相同的问题（由于设备“忙碌”，无法卸载Pod中的文件，Pod仍在终止中）。 对我而言，使用--grace-period=0 --force将导致安装点继续存在。 最终，我获得了超过90000个挂载点，这严重降低了群集的速度。 此处的解决方法是在pod的文件夹中进行查找，然后递归地卸载这些文件，然后递归删除pod文件夹。
就我而言，我正在使用子路径将configmap安装到具有现有文件的现有文件夹中，覆盖现有文件之一。 这对我来说在1.8.6上工作正常。
原始海报提到豆荚会“终止”几个小时，在我看来，这是几天。 我没有看到它们最终会被清除，除非执行手动解决方法。
mvernimmen
于 2018-07-13
由日志聚合器（类似于fluentd）引起的同样问题，它挂载/var/lib/docker/containers文件夹，并且pod挂载了很多：
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
就我而言，有些豆荚可以被kubernetes很好地去除，但是有些豆荚处于“终止”状态。
它可能与https://github.com/kubernetes/kubernetes/issues/45688有关（我也在使用docker 17）
Paxa
于 2018-07-17
我只是有一个问题，因为缺少一个秘密，豆荚没有终止。 在该名称空间中创建了该秘密之后，一切都恢复了正常。
snackycracky
于 2018-07-18
我这样移除了卡住的豆荚：
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>:~$
cbluth
于 2018-07-24
在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>
我尝试使用--now或设置宽限期。 例如
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
吊舱仍在悬挂，这也导致相应的展开卡住。
andreacassioli
于 2018-07-27
在广告连播活动中，这些“需要杀死广告连播”消息也让我感到困扰。 这是什么意思？ _Kubernetes_觉得有必要杀死豆荚，还是_I_应该杀死豆荚？
bronger
于 2018-08-04
这是几天前发生在我身上的事情，我放弃了删除操作，而是将吊舱保留了下来。 然后今天，它消失了，似乎最终被删除了。
emaung
于 2018-08-04
刚刚发生在我身上。 --force --now解决方案对我不起作用。 我发现kubelet日志中的以下行可疑
8月6日15:25:37 kube-minion-1 kubelet [2778]：W0806 15：25：37.986549 2778 docker_sandbox.go：263] NetworkPlugin cni在Pod“ backend-foos-227474871-gzhw0_default”状态挂钩上失败了：意外命令输出nsenter：无法打开：没有这样的文件或目录
这导致我发现以下问题：
https://github.com/openshift/origin/issues/15802
我不是在openshift上，而是在Openstack上，所以我认为这可能是相关的。 我给出了重启docker的建议。
重新启动docker可使卡在“终结”中的豆荚消失。
prein
于 2018-08-07
我知道这只是一个变通办法，但是有时我不会在凌晨3点醒来解决此问题。
并不是说您应该使用此功能，但这可能对某些人有帮助。
睡眠是我将豆荚的终止时间GracePeriodSeconds设置为30秒。 如果生存时间更长，则此cronjob将--force --grace-period = 0并将其完全杀死
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
Rajczyk
于 2018-08-21
我在Kubernetes v1.10.2中看到了相同的错误。 豆荚陷入无限期终止，有关节点上的kubelet反复记录：
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"
我可以手动卸载有问题的子路径卷而不会抱怨（Linux不会告诉我它很忙）。 这将阻止kubelet记录错误消息。 但是，这不会激励Kubernetes继续清理，因为Pod仍显示为处于终止状态。 常规重新启动Docker进行清理实际上不是一个可以接受的解决方案，因为它会对运行中的容器造成破坏。
还要注意的是：容器本身是从docker ps -a消失的，没有证据表明它曾经存在过，因此我不确定这实际上是Docker问题。 我们正在使用Docker版本17.03.2-ce。
erhudy
于 2018-08-21
更新：我们已经配置了节点，以使用符号链接将kubelet根目录重定向到非OS卷（ /var/lib/kubelet是指向不同卷上另一个目录的符号链接）。 当我重新配置东西以将--root-dir传递到kubelet以便直接将其转到所需的目录（而不是通过符号链接）并重新启动kubelet时，它清理了卷安装并清除了卡住的pod无需重启Docker即可终止。
erhudy
于 2018-08-21
我今天在minikube上本地运行一些Pod时第一次遇到这个问题。
由于将configmap / secret挂载为卷，因此我在Terminating卡住了一堆豆荚。 建议/解决方法/解决方案中没有张贴上述工作，除了这一个。
我认为值得注意的一件事是：
- 当我运行
kubectl get pods，我得到了状态为Terminating的豆荚列表。 - 当我运行
docker ps | grep -i {{pod_name}}虽然没有在荚Terminating通过所看到的状态kubectl get pods在minikube VM正在运行。
我期望docker ps返回停留在Terminating状态的Pod列表，但实际上它们都不在运行，但是kubectl get pods返回有关它们的数据？ 有人能解释为什么吗？
walterdolce
于 2018-09-17
我在4个部署中遇到了这个问题。 然后，对于所有安装，我都从“本地卷”切换为“主机路径”，对我而言，它已经消失了。
bronger
于 2018-09-17
我只是有一个问题，因为缺少一个秘密，豆荚没有终止。 在该名称空间中创建了该秘密之后，一切都恢复了正常。
如果名称空间处于“终止”状态，如何在名称空间中创建机密？
SachinHg
于 2018-09-30
kubectl删除-所有吊舱--namespace = xxxxx --force --grace-period = 0
为我工作。
不要忘记“ --grace-period = 0”。 重要
hixichen
于 2018-10-11
kubectl警告我：“警告：立即删除不会等待确认正在运行的资源已终止。该资源可能会无限期地继续在群集上运行。” 当我使用--force --grace-period=0 。
谁能告诉我这是否真的会发生吗？
windoze
于 2018-10-13
实际上，当我们删除某个广告连播时，由于某些原因它可能会延迟删除，
如果我们执行带有标志“ --force --grace-period = 0”的“ kubectl delete”，
资源对象将被立即删除。
zhangxiaoyu-zidif
于 2018-10-14
您可以帮助确认是否可以立即删除广告连播吗？
这是否意味着警告消息实际上是不正确的？
windoze
于 2018-10-16
@windoze ，如果使用--force --grace-period = 0选项，则表示pod API对象将立即从API服务器中删除。 Node kubelet负责清理卷安装并杀死容器。 如果kubelet未运行或在清理吊舱期间出现问题，则该容器可能仍在运行。 但是，只要有可能，Kubelet应该继续尝试清理豆荚。
jingxu97
于 2018-10-16
因此，这仍然意味着删除可能要永久进行，因为kubelet可能会出现故障？
有什么方法可以确保删除吊舱？
我问这个问题是因为我在集群中运行着一些巨大的Pod，并且每个节点上没有足够的内存来运行它们的2个实例。
如果删除失败，则该节点将变得不可用，并且如果多次发生此问题，该服务将完全关闭，因为最终将没有节点可以运行此Pod。
在普通的旧docker环境中，我可以用kill -9或类似的命令强制杀死一个pod，但是k8s似乎没有这样的功能。
windoze
于 2018-10-18
@windoze您知道为什么删除pod经常失败吗？ 是因为kubelet没有运行，还是kubelet试图杀死容器，但由于某些错误而失败了？
jingxu97
于 2018-10-18
几个月前，这种情况在我的集群上发生过几次，kubelet正在运行，但是docker daemon似乎遇到了一些麻烦，并且卡住了并且没有错误日志。
我的解决方案是登录到该节点并强制终止容器进程并重新启动docker守护程序。
经过一些升级后，问题就消失了，我再也没有了。
windoze
于 2018-10-18
kubectl delete pods <podname> --force --grace-period=0为我工作！
shinebayar-g
于 2018-10-27
@ shinebayar-g， --force是它可能意味着您的容器将继续运行。 它只是告诉Kubernetes忘记了该Pod的容器。 更好的解决方案是将SSH连接到运行pod的VM中，并研究Docker发生了什么。 尝试使用docker kill手动杀死容器，如果成功，请尝试再次正常删除容器。
agolomoodysaada
于 2018-11-02
@agolomoodysaada啊，这很有道理。 感谢您的解释。 所以我真的不知道实际的容器是真的被删除还是不正确？
shinebayar-g
于 2018-11-03
所以，这是2018年底，kube 1.12出局了……你们所有人仍然遇到豆荚卡住的问题吗？
sokoow
于 2018-11-03
我有同样的问题，--force --grace-period = 0或--force --now不起作用，以下是日志：
root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat获取pod node-exporter-zbfpx
名称就绪状态重启年龄
node-exporter-zbfpx 0/1终止0 4d
root @ r15-c70-b03-master01 ：〜＃kubectl -n Infra-lmat删除pod node-exporter-zbfpx --grace-period = 0 --force
警告：立即删除不会等待确认正在运行的资源已终止。 资源可能会无限期地继续在群集上运行。
pod“ node-exporter-zbfpx”已删除
root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat获取pod node-exporter-zbfpx
名称就绪状态重启年龄
node-exporter-zbfpx 0/1终止0 4d
root @ r15-c70-b03-master01 ：〜＃kubectl -n红外线-删除删除pod node-exporter-zbfpx --now --force
pod“ node-exporter-zbfpx”已删除
root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat获取pod node-exporter-zbfpx
名称就绪状态重启年龄
node-exporter-zbfpx 0/1终止0 4d
root @ r15-c70-b03-master01 ：〜＃
我试图编辑pod并删除元数据中的终结器部分，但也失败了。
shangxdy
于 2018-11-05
我仍然可以在macOS上使用kubectl 1.13 alpha和Docker for Desktop以100％可重现的方式（相同的资源定义）看到它。 可复制的意思是，解决该问题的唯一方法似乎是将Docker for Mac重置为出厂设置，当我使用相同的资源（部署脚本）再次设置群集时，相同的清理脚本将失败。
我不确定为什么会如此，但是我的清理脚本如下：
#!/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
因为集群是在本地运行的，所以我可以验证Docker中没有运行describe豆荚时，状态列为Status: Terminating (lasts <invalid>)
Benjamin-Dobell
于 2018-11-14
只是再次发生在我身上。 我试图用NFS共享安装percona pmm-server，甚至软件都没有出现，所以我删除了，这发生了。 （永久声明不适用于该软件）。 猜猜我又叫旧的kubectl delete pods <podname> --force --grace-period=0 。 但是问题是我怎么知道这个豆荚生活在哪里？
shinebayar-g
于 2018-11-14
@ shinebayar-g，将SSH插入已打开的VM并运行docker ps 。
agolomoodysaada
于 2018-11-14
嗯，那不在那里。.我的VM很少，所以我问如何找出合适的VM。 :)
shinebayar-g
于 2018-11-14
@ shinebayar-g这可能有效：
kubectl describe pod/some-pod-name | grep '^Node:'
windoze
于 2018-11-23
同样的问题。
docker ps发现容器处于“ Dead”状态，未按预期退出（0）
chestack
于 2018-12-13
手动删除容器，导致以下泊坞窗日志条目：
level=warning msg="container kill failed because of 'container not found' or 'no such process': Cannot kill container
不幸的是，生产线被切断了，但是我想我记得，问题在于该过程不再存在了。
nielsole
于 2018-12-20
我仍然对k8s v1.11.0的这个问题感到困惑。 这是我清理豆荚的检查清单：
- 确保已回收附加到吊舱的所有资源。 在
kubectl get，并非所有人都可见； 其中一些仅是运行Pod的Kubelet知道的，因此您必须在本地跟踪其日志流 - 如果所有其他操作均失败，则
kubectl edit失败的Pod并删除finalizers:→- foregroundDeletion
另外两个提示：
- 在稳定状态下，无混淆的Kubelet不应记录任何定期消息。 释放东西的任何重复失败都是豆荚卡住的症状。
- 您可以在另一个窗口中阻止
kubectl delete命令以监视进度（即使在已经“删除”多次的pod上）。kubectl delete将在释放最后一个阻塞的资源后立即终止。
domq
于 2019-01-25
今天面对这个。
做了什么：
- SSH到节点并手动删除容器
- 之后，
kubectl get pods向我显示了我卡住的容器0/1 terminating（是1/1 terminating） - 从pod中删除
finalizers部分，我是foregroundDeletion（$ kubectl edit pod / name）->从pods列表中删除容器 - 删除部署->删除所有与部署相关的内容。
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"}
0t3dWCE
于 2019-02-09
当我们开始安装秘密（与许多Pod共享）时，我们面临着同样的问题。 豆荚进入terminating状态，并永远停留在那里。 我们的版本是v1.10.0。 附加的docker容器不见了，但除非使用--grace-period=0 --force选项强制删除pod，否则API服务器中的引用仍然保留。
寻找永久解决方案。
anjuls
于 2019-02-22
好吧，最近我在我的登台集群上测试了runc漏洞CVE-2019-5736，正如您已经知道的那样，该漏洞在主机上重写了runc二进制文件。 它具有破坏性。 之后，我在群集上看到了奇怪的行为。 所有吊舱均处于终止状态。 解决方法是耗尽受影响的节点清除docker并重新安装它。 之后，所有的Pod和k8s都可以像以前一样正常运行。 也许它是docker问题，然后重新安装它也可以解决您的问题！。 谢谢
Mormoroth
于 2019-02-26
全新v1.13.3安装在这里。 我也是这样发生这种情况是因为我在几个Pod上安装了相同的NFS卷，这似乎与它有关。
nmors
于 2019-03-01
在创建尝试使用不存在的机密创建卷的部署时，删除该部署/服务会在Terminating pod周围留下我看到的问题。
cgiroua
于 2019-03-01
面对与v.1.12.3相同的问题，并且--grace-period = 0 --force或--now均无效，请删除也属于无效状态集
LareinaH
于 2019-03-02
SMB（我认为呢？）挂载也存在同样的问题（Azure文件共享按照https://docs.microsoft.com/zh-cn/azure/aks/azure-files-volume）。
nathanongit
于 2019-03-06
与13.3相同的问题
KevinRiordan
于 2019-03-06
我有一个问题，即pod处于将近2天的“终止”状态。
我在Linux机器（Debian）上使用Minikube。
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"}
Minikube版本：
minikube version: v0.34.1
ardalanrazavi
于 2019-03-10
@ardalanrazavi为什么会终止两天？ 如果5分钟后仍未删除，则强制删除
nmors
于 2019-03-10
@nmors
为什么要终止两天？
这是个好问题。 我们都想知道这一点。
如果5分钟后仍未删除，则强制删除
强行删除它会使群集处于不一致状态。 （使用minikube，这不是您真正的集群，因此，它不必担心很多）
AndrewSav
于 2019-03-10
@安德鲁·萨夫（AndrewSav）
坦率地说，我没有其他解决方案。
当然，群集将处于“不一致状态”。 我想了解您的确切意思。 强制关闭是不好的。 我也不喜欢它，但就我而言，我很乐意根据需要销毁和重新部署任何资源。
就我而言，它似乎只能终止在装有NFS挂接的吊舱上。 并且仅在客户端尝试关闭之前NFS服务器关闭时才会发生。
nmors
于 2019-03-10
我解决了这个问题，能够隔离所有终止连接的Pod都在一个节点上，重新启动了节点，问题已经消失了。
KevinRiordan
于 2019-03-11
@nmors @AndrewSav我也做了强制删除。
ardalanrazavi
于 2019-03-14
在删除Pod之前先删除nfs服务器会导致卸载永久挂起。 在这种情况下，最好对删除进行排序，以便始终将nfs服务器最后删除。
msau42
于 2019-03-14
@ msau42我的NFS服务器不是k8s群集的一部分-它是一台单独的设备和计算机
nmors
于 2019-03-14
它是否属于k8s集群并不重要。 如果nfs服务器不可访问，则卸载将挂起，直到再次可访问为止。
msau42
于 2019-03-14
@ msau42 ，这很奇怪，因为我很确定，即使当它返回在线状态时，豆荚仍然卡住了。 新的豆荚启动并安装良好。
nmors
于 2019-03-14
我在kubernetes上使用NFS服务器，后面是这个示例，不幸的是，这种情况经常发生。
shinebayar-g
于 2019-03-14
@ shinebayar-g我也遵循该指南，但是现在我摆脱了PV和PVC，直接在部署中定义了卷，如下所示：
volumeMounts:
- mountPath: /my-pod-mountpoint
name: my-vol
volumes:
- name: my-vol
nfs:
server: "10.x.x.x"
path: "/path/on/server"
readOnly: false
从那以后我再也没有任何问题了，我只改变了大约一周的时间，希望更简单的配置更加可靠。
nmors
于 2019-03-14
作为一种变通方法，我编写了一个脚本，该脚本从/var/log/syslog了最后几行，并搜索诸如“操作...删除/ var / lib / kubelet / pods ...目录不为空”或“ nfs”之类的错误。 ..设备正忙... unmount.nfs”或“陈旧的NFS文件句柄”。
然后，它提取pod_id或pod完整目录，并查看其挂载的内容（例如mount | grep $pod_id ），然后全部卸载并删除相应的目录。 最终，kubelet完成了其余工作，并正常关闭并删除了吊舱。 终止状态下没有其他吊舱。
我将该脚本放在cron中以每分钟运行一次。 结果-暂时没有问题，即使是3-4个月后也没问题。
注意：我知道，这种方法不可靠，需要在每次群集升级时都进行检查，但是可以！
nmakhotkin
于 2019-03-14
我正在使用1.10版，今天我遇到了这个问题，我认为我的问题与安装机密卷的问题有关，这可能使某些任务挂起，并且吊舱永远处于终止状态。
我必须使用--grace-period = 0 --force选项来终止豆荚。
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]
usernkey
于 2019-03-21
我发现，如果您使用--force --grace-period=0它所做的全部就是删除引用...如果您使用ssh进入该节点，您仍会看到Docker容器正在运行。
aranair
于 2019-04-03
就我而言，节点上的内存不足。
内核杀死了纤毛剂，这似乎打乱了豆荚的终止。
我只是重新启动了节点并清除了它。
humbledude
于 2019-04-26
以我的经验，节点上的sudo systemctl restart docker有所帮助（但显然会有停机时间）。
而且这仍然会定期发生在以下随机节点上：A）接近内存限制或B）CPU饥饿（某些kswapd0问题的bc可能仍与内存相关，或者是实际负载）
aranair
于 2019-04-26
闲置90天后，问题变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
再过30天不活动后，陈旧的问题就会消失，并最终关闭。
如果现在可以安全解决此问题，请使用/close进行关闭。
将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/ lifecycle stale
fejta-bot
于 2019-07-25
闲置30天后，陈旧问题腐烂。
使用/remove-lifecycle rotten将问题标记为新问题。
闲置30天后，烂问题将关闭。
如果现在可以安全解决此问题，请使用/close进行关闭。
将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/生命周期烂
fejta-bot
于 2019-08-24
闲置30天后，腐烂的问题关闭。
用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。
将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/关
fejta-bot
于 2019-09-23
@ fejta-bot：解决此问题。
针对此：
闲置30天后，腐烂的问题关闭。
用/reopen重新打开问题。
使用/remove-lifecycle rotten将问题标记为新问题。将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/关
可在此处获得使用PR注释与我互动的说明。 如果您对我的行为有任何疑问或建议，请针对kubernetes / test-infra存储库提出问题。
k8s-ci-robot
于 2019-09-23
k8s 1.15.4和RHEL Docker 1.13.1仍然是一个非常活跃的问题。 所有时间豆荚都停留在Terminating但是容器已经不见了，k8s不能弄清楚自己，但是需要人工干预。 使测试脚本真正成为PITA。
/重新打开
/删除生命周期烂
tuminoid
于 2019-10-23
@tuminoid ：除非您创建了一个问题/ PR，否则您无法重新打开它。
针对此：
k8s 1.15.4和RHEL Docker 1.13.1仍然是一个非常活跃的问题。 所有时间豆荚都停留在
Terminating但是容器已经不见了，k8s不能弄清楚自己，但是需要人工干预。 使测试脚本真正成为PITA。/重新打开
/删除生命周期烂
可在此处获得使用PR注释与我互动的说明。 如果您对我的行为有任何疑问或建议，请针对kubernetes / test-infra存储库提出问题。
k8s-ci-robot
于 2019-10-23
/重新打开
/删除生命周期烂
mikesplain
于 2019-11-04
@mikesplain ：重新
针对此：
/重新打开
/删除生命周期烂
可在此处获得使用PR注释与我互动的说明。 如果您对我的行为有任何疑问或建议，请针对kubernetes / test-infra存储库提出问题。
k8s-ci-robot
于 2019-11-04
此处相同：吊舱在终止阶段停留了超过19分钟。 容器已成功终止，但Kubernetes仍然认为它需要等待一些东西。
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>
没有事件，没有日志...
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
0anton
于 2019-11-10
您可以检查kubelet日志，看看是否有关于卷卸载失败或孤立的pod的消息？
msau42
于 2019-11-11
我也看到了
E1206 03：05：40.247161 25653 kubelet_volumes.go：154]找到孤立的吊舱“ 0406c4bf-17e3-4613-a526-34e8a6cee208”，但磁盘上仍存在卷路径：总共有8个类似的错误。 出现冗长即可看到它们。
krisdevopsbot
于 2019-12-06
我也看过无法检查日志，因为kubectl抱怨由于当前存在终止Pod而无法连接到Docker容器并且无法创建新Pod。 有点烦人。
elrok123
于 2019-12-06
也有经验，不得不确认Kubernetes是否正确清洁了旧豆荚，这很烦人。
希望此问题能尽快解决。
FloatingSunfish
于 2019-12-17
那这个问题呢？ 它解决了吗？ 我有一个相同的想法，但是这种情况不会立即开始发生，而是在节点启动后的一段时间内，如果您重置节点，那么一段时间后一切都会好起来的
healfy
于 2019-12-27
您能否检查Pod上是否有终结器，以防止其被删除？
frittentheke
于 2019-12-30
发行的广告连播中没有终结器
healfy
于 2020-01-04
仅供参考，我使用以下命令强制删除解决了此问题：
kubectl delete pods <pod> --grace-period=0 --force
我相信这成功地终止了吊舱。 从那时起，我再也没有遇到这个问题。 从那时起，我可能已经进行了更新，所以可能是版本问题，但是自从我看到问题以来已经很久了，所以可能不是100％。
elrok123
于 2020-01-23
当pod内存不足时会发生这种情况。 直到内存使用率再次下降，它才会终止。
Ejdamm
于 2020-01-29
仅供参考，我使用以下命令强制删除解决了此问题：
kubectl delete pods <pod> --grace-period=0 --force我相信这成功地终止了吊舱。 从那时起，我再也没有遇到这个问题。 从那时起，我可能已经进行了更新，所以可能是版本问题，但是自从我看到问题以来已经很久了，所以可能不是100％。
那对我有用
eduardobcastro
于 2020-01-30
kubectl delete pods <pod> --grace-period=0 --force是一个临时修复程序，我不希望每次受影响的吊舱之一进行故障转移时都运行手动修复程序。 我的动物园管理员吊舱没有在minikube和Azure AKS上终止。
2020年3月9日更新
我使用了preStop生命周期挂钩来手动终止我的Pod。 我的动物园管理员吊舱处于终止状态，不会响应容器内的任期信号。 我基本上在其他地方运行了相同的清单，并且一切都正确终止，不知道根本原因是什么。
ztasre
于 2020-03-02
同样的问题，超级烦人
bitsofinfo
于 2020-03-03
同样的问题:(豆荚卡在终止，因为3天
amanakshe
于 2020-04-06
仅供参考，我使用以下命令强制删除解决了此问题：
kubectl delete pods <pod> --grace-period=0 --force我相信这成功地终止了吊舱。 从那时起，我再也没有遇到这个问题。 从那时起，我可能已经进行了更新，所以可能是版本问题，但是自从我看到问题以来已经很久了，所以可能不是100％。
同样， --force标志并不一定意味着容器已被移走，只是不等待确认（就我的理解而言，放弃引用）。 如警告The resource may continue to run on the cluster indefinetely 。
编辑：我消息不灵通。 请参阅下面的elrok123s评论以获取进一步的动机。
oscarlofwenhamn
于 2020-05-27
仅供参考，我使用以下命令强制删除解决了此问题：
kubectl delete pods <pod> --grace-period=0 --force我相信这成功地终止了吊舱。 从那时起，我再也没有遇到这个问题。 从那时起，我可能已经进行了更新，所以可能是版本问题，但是自从我看到问题以来已经很久了，所以可能不是100％。
同样，
--force标志并不一定意味着容器已被移走，只是不等待确认（就我的理解而言，放弃引用）。 如警告The resource may continue to run on the cluster indefinetely。
是的，但是重点是--grace-period=0强制删除操作:)不知道为什么您的评论有意义：/
elrok123
于 2020-06-04
我觉得他的评论很有意义，因为底层的容器
（泊坞窗或其他工具）可能仍在运行，尚未完全删除。
对其“删除”的幻想有时会引起误解
2020年6月4日，星期四，上午9:16，康纳·斯蒂芬·麦凯布<
[email protected]>写道：
仅供参考，我使用以下命令强制删除解决了此问题：
kubectl删除豆荚
--grace-period = 0 --force 我相信这成功地终止了吊舱。 从那以后我
不再遇到此问题。 从那时起我可能已经更新了，
所以可能是版本问题，但不是100％，因为已经有很长时间了
我已经看到了问题。此外，--force标志不一定表示已将吊舱移除，
只是不等待确认（而是将引用删除了
理解）。 如警告所述，资源可能会继续运行
不确定地在群集上。正确，但要点是--grace-period = 0强制删除
发生:)不确定您的评论为何相关：/-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ，
或退订
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
。
aranair
于 2020-06-04
这确实是我的意思； 使用此方法， --force方法可能会导致基础负载使节点承受压力，并且不一定能解决原始问题。 在最坏的情况下，它是一个“如果我看不到它不存在”的修复程序，它最终将变得更加难以检测。
还是您说--grace-period=0可以保证强制删除基础容器@ elrok123？
如果是这样，我的评论是基于错误的知识，并且是无关紧要的，但是如果在使用--grace-period=0时仍然存在离开运行容器的风险，我的意思也是如此。
oscarlofwenhamn
于 2020-06-05
@oscarlofwenhamn据我所知，这是有效地在该吊舱的所有进程运行SIGKILL，确保僵尸程序的缺失（来源：根据“吊舱的终止” 6点- https://kubernetes.io/docs/concepts / workloads / pods / pod /＃ ：〜：text =当％20the％20grace％20period％20到期时，period％200％20（immediate％20deletion）。），并成功删除了pod（可能不会立即发生，但是会成功发生。）
该指南提到它删除了引用，但并未删除pod本身（来源：``强制删除''-https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ），但是grace-period = 0应该有效地标记您的广告连播，尽管不能立即生效。
我只是在阅读文档和推荐的方式来处理遇到的情况。 我专门遇到的问题不是一个经常发生的问题，而且曾经发生过一次。 我确实相信，针对此的REAL修复可以修复您的部署，但是在您到达那里之前，此方法应该会有所帮助。
elrok123
于 2020-06-05
@ elrok123很棒-我确实不了解情况。 我已经参考以下说明更新了我的回复。 感谢您的详细答复，以及进一步处理疑难豆荚的方法。 干杯!
oscarlofwenhamn
于 2020-06-05
目前，豆荚处于终止状态的时间超过2天。
bitsofinfo
于 2020-06-09
对我来说，名称空间卡在Terminating 。 没有列出豆荚。 没有服务...什么都没有。 命名空间为空。 仍然...停留在终止中。
JoseFMP
于 2020-06-10
@JoseFMP使用kubectl从名称空间请求yaml，它可能有终结器来阻止进程。
JordyBottelier
于 2020-07-08
@JordyBottelier谢谢。
没有终结器。 仍卡在Terminating
JoseFMP
于 2020-07-09
@JoseFMP是一个脚本，可以完全杀死它（实际上是消灭它），只需保存并运行./script_name
```
！/ bin / bash
设置-eo pipefail
die（）{echo“ $ *” 1>＆2; 1号出口； }
need（）{
其中“ $ 1”＆> / dev / null || die“二进制'$ 1'丢失，但是必需的”
}
检查先决条件
需要“ jq”
需要“卷曲”
需要“ kubectl”
PROJECT =“ $ 1”
转移
测试-n“ $ PROJECT” || 死“缺少论点：kill-ns
kubectl代理＆> / dev / null＆
PROXY_PID = $！
killproxy（）{
杀死$ PROXY_PID
}
陷阱杀毒剂退出
睡觉1＃给代理第二次
kubectl获取名称空间“ $ PROJECT” -o json | jq'del（.spec.finalizers [] | select（“ kubernetes”））'| curl -s -k -H“内容类型：application / json” -X PUT -o / dev / null --data-binary @ -http：// localhost ：8001 / api / v1 / namespaces / $ PROJECT / finalize && echo“杀死的名称空间：$ PROJECT”```
JordyBottelier
于 2020-07-10
我似乎也碰到了这一点，终止了多个Pod，其中包括一个Pod，该Pod在我的基础架构中的任何位置都不再可见，但仍作为幽灵运行（它可以处理请求，即使部署规模也可以看到请求被处理零）。
我对这个Pod的视野为零，也没有控制权，问我如何在不强制关闭所有节点的情况下解决这种情况？
peppy
于 2020-08-18
我似乎也碰到了这一点，终止了多个Pod，其中包括一个Pod，该Pod在我的基础架构中的任何位置都不再可见，但仍作为幽灵运行（它可以处理请求，即使部署规模也可以看到请求被处理零）。
我对这个Pod的视野为零，也没有控制权，问我如何在不强制关闭所有节点的情况下解决这种情况？
您必须访问该节点上的docker。
您可以使用我的dink （https://github.com/Agilicus/dink），它将弹出一个带shell的pod（带有docker访问权限）或ssh到该pod。
docker ps -a
docker stop ####
祝好运。
donbowman
于 2020-08-18
感谢您的指导。
我最终能够解决这个问题，但还是有点疑惑（对于我来说，豆荚是完全不可见的）。 由于它在生产过程中有些忙碌，因此我无法执行诊断，但是希望再次发生时，我可以提出更好的错误报告。
peppy
于 2020-08-18
看到类似的症状，豆荚卡在终端中（有趣的是，它们都具有针对就绪/活跃度的exec类型探针）。 查看日志，我可以看到：kubelet [1445]：I1022 10：26：32.203865 1445 prober.go：124]为“ test-service-74c4664d8d-58c96_default（822c3c3d-082a-4dc9-943c-19f04544713e）：测试准备就绪的探测器-service”失败（失败）：OCI运行时exec失败：exec失败：无法执行已停止的容器：未知。 此消息会一直重复，并且将exec探针更改为tcpSocket似乎允许pod终止（基于测试，将对其进行跟踪）。 该pod似乎有一个容器“正在运行”，但没有“就绪”，“正在运行”容器的日志的确显示了该服务已停止。
sciffer
于 2020-10-22
当节点负载很高且vm.max_map_count设置为比默认值高的值时，在容器化1.4.0上会发生这种情况，容器化填充程序不会耗尽stdout fifo并阻止等待其被耗尽，而dockerd无法生成来自容器的事件/确认，表明进程已消失。
discanto
于 2020-11-20
@discanto感谢您分享此信息。 问题是否已解决或得到跟踪？
@ Random-Liu
jingxu97
于 2020-11-22
该错误已打开3年多了。 卡在终端上的豆荚可能是由多种原因引起的。 在报告您的情况时，发布一些kubelet日志以查看吊舱是否卡住将非常有帮助。
jingxu97
于 2020-11-22
相关问题
jadhavnitind
·
3评论
alexferl
·
3评论
errordeveloper
·
3评论
theothermike
·
3评论
broady
·
3评论
最有用的评论
我在IBM Cloud的Kubernetes 1.8.2上遇到相同的问题。 新的Pod启动后，旧的Pod会终止。
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"}我已使用
kubectl delete pod xxx --now以及kubectl delete pod foo --grace-period=0 --force无济于事。