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

通常、ボリュームとネットワークのクリーンアップは、終了時に多くの時間を消費します。 ポッドがスタックしているフェーズを見つけることができますか？ たとえば、ボリュームのクリーンアップ？

通常、ボリュームとネットワークのクリーンアップは、終了時に多くの時間を消費します。

正しい。 彼らは常に疑わしいです。

@igorleao kubectl delete pod xxx --nowも試すことができます。

こんにちは@resouerと@dixudx
よく分かりません。 同じ問題のある別のポッドのkubeletログを見ると、次のことがわかりました。

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.

ご覧のとおり、このクラスターにはCNI用のCalicoがあります。
次の行が私の注意を引きます：

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はかなりうまく機能しているようですが、根本的な原因を突き止め、人間との対話を避けたいと思っています。

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は、特定のクラスターで1日に数回発生します。 同じバージョンのkopsとkubernetesで同じ週に作成された他のクラスターは、問題なく機能します。

@igorleaoログが示すように、デバイスがビジーであるため、ボリュームマネージャーが
ディレクトリ/var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-keyがまだマウントされているかどうかを確認してください。 ありがとう！

@igorleaoどのように

同様の動作が見られます。 kubeletをコンテナーとして実行し、 /var/lib/kubeletを共有としてマウントすることで問題を部分的に軽減しました（デフォルトでは、dockerはボリュームをrslaveとしてマウントします）。 しかし、それでも同様の問題が発生しますが、頻度は低くなります。 現在、他のいくつかのマウントは別の方法で行う必要があると思います（例： /var/lib/dockerまたは/rootfs ）

@stormltf kubeletコンテナの構成を投稿していただけますか？

@stormltfコンテナでkubeletを実行していて、 --containerizedフラグを使用しないでください（マウントでいくつかのトリックを実行し

スタックしたポッドについて、次のことを行ってください。

ポッドが実行されているノード

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• ノード自体も同じですmount | grep STUCK_POD_UUID 。

作成したばかりのポッドについても同じようにしてください。 いくつかの/var/lib/kubeletマウント（例：default-secret）を見ると思います

@stormltf最初の2つのポッドが作成された後、kubeletを再起動しましたか？

@stormltf /var/lib/dockerと/rootfsを共有（docker inspectには表示されませんが、コンテナー内に表示されます）マウントポイントにすることができます。

/ sigストレージ

一部の人にとってはそれが役立つかもしれません。 --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コンテナにはdockerではなくrktを使用するためです。 kubeletがDockerで実行され、kubelet continer内のすべてのマウントが/var/lib/docker/overlay/...と/rootfs提案される場合、バインドマウントボリュームごとに2つの寄生マウントがあります。

• /rootfs/var/lib/kubelet/<mount> /rootfsから1つ
• /var/lib/docker/overlay/.../rootfs/var/lib/kubelet/<mount> /var/lib/dockerから1つ

-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

Azure上のKubernetes1.8.1でも同じ問題が発生します。デプロイが変更され、新しいポッドが開始された後、古いポッドが終了しません。

IBMCloudのKubernetes1.8.2でも同じ問題が発生します。 新しいポッドが開始された後、古いポッドは終了し続けます。

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を使用しましたが無駄になりました。

根本原因が同じである場合（不適切に提案されたマウント）、これはディストリビューション固有のバグimoです。

IBMクラウドでkubeletrunを実行する方法を説明してください。 systemdユニット？ --containerizedフラグはありますか？

--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

-コンテナ化されたフラグ：いいえ

わかりました。詳細が必要です。上記のコメントをご覧くださいhttps://github.com/kubernetes/kubernetes/issues/51835#issuecomment-333090349

また、 /lib/systemd/system/kubelet.service内容を表示してください。また、 /etc/systemd/system kubeletについて何かあれば、共有してください。

特に、kubeletがdockerで実行されている場合、すべてのバインドマウント-vを確認したいと思います。

今日、説明したものと同じ問題が発生しました。お客様のシステムの1つにあるポッドが、数日間終了状態でスタックしていました。 また、「エラー：ボリュームに対してUnmountVolume.TearDownが失敗しました」に関するエラーが発生し、スタックしたポッドごとに「デバイスまたはリソースがビジーです」が繰り返されていました。

私たちの場合、このmobyの問題でカバーされているRHEL / Centos 7.4ベースのシステムのdockerに問題があるようです： https ： https：// github .com / moby / moby / pull / 34886 / files

私たちにとっては、sysctlオプションfs.may_detach_mounts = 1を数分以内に設定すると、すべての終了ポッドがクリーンアップされました。

私もこの問題に直面しています：ポッドは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でも以前にこの問題に直面しました

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"}

ポッドnginx-56ccc998dd-nnsvjについて説明します

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

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

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

cat /etc/systemd/system/kubelet.service

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

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

[Install]
WantedBy=multi-user.target

問題に関連するさまざまなバグがあるようです。 1.8.3クラスターには両方があります。

1. https://github.com/moby/moby/issues/31768 。これはDockerのバグです。 docker-ce = 17.09.0〜ce-0〜ubuntuで再現可能。
2. 2つ目はもっと興味深いもので、おそらくkubelet内の競合状態に関連しています。
   コンテナマウントで指定されたサブパスを持つ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

そして、それは本当のディレクトリが空ではなく、マウント解除されており、「サブパス」ディレクトリが含まれています！
そのような振る舞いの説明の1つ：

1. P1：ポッドの作成またはポッドの同期を開始します
2. P1：マウント/再マウントを行うためにボリュームマネージャーに信号を送信します。
3. P1：マウントが完了するのを待っています。
4. P1：マウント成功信号を受信します（実際には、すべてのボリュームがマウントされていることを確認してください）
5. どういうわけかボリュームがアンマウントになります。 別の削除プロセスがそれをアンマウントするか、OSのバグ、またはガベージコレクターアクションである可能性があります。
6. P1：コンテナの作成を続行し、マウントポイントにサブディレクトリを作成します（すでにマウント解除されています）。
7. マウントディレクトリが空ではないため、前のステップのポッドをすべて削除することはできません。

その他のログ：

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

どういうわけか、いくつかのクリーンアッププロセス（（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"

ポッドの初期化と削除が同時に実行されています。
バグを繰り返すには、約10個のデプロイメント（単一のミニオンでテスト済み）を開始してすぐに削除/更新する必要があります。おそらく、マウント操作はそれほど高速ではないはずです。

GKEの同じバグの影響を受けます。 この問題の既知の回避策はありますか？ --nowは機能しません。

このバグは修正されていますが、kubernetesチームによってマージされるかどうかはわかりません。

@dreykこのバグについて発見したことと、ストレージチームが確認できるように修正したことについて、詳細を教えてください。 ありがとう！

@ gm42 GKEでこの問題を手動で

1. スタックしたポッドがスケジュールされていたノードにSSHで接続する
2. docker ps | grep {pod name}を実行してDockerコンテナIDを取得する
3. docker rm -f {container id}

GKEでは、ノードのアップグレードがすぐに役立ちました。

kubeadmを使用して設定されたローカルクラスターに同じバグがあります。

ノードのdocker ps | grep {pod name}には何も表示されず、ポッドは終了状態でスタックしています。 現在、この状態のポッドが2つあります。

ポッドを強制的に削除するにはどうすればよいですか？ または、ポッドの名前を変更しますか？ 同じ名前で別のポッドを起動することはできません。 ありがとう！

1.7.2クラスターで理由を見つけました。
別の監視プログラムがルートパスをマウントするため/
ルートパスには/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttfが含まれています
したがって、kubeletがポッドを削除しても、ボリュームを解放できない場合、メッセージは次のようになります。
デバイスまたはリソースがビジー

手順：
1）sudo journalctl -u kubelet
このシェルは、エラーメッセージを見つけるのに役立ちます。
2）sudodocker検査
io.kubernetes.pod.uidを見つけます "：" ddc66e10-0711-11e8-b905-6c92bf70b164 "
そして
HostConfig-> Bindings-> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf:/var/run/secrets/kubernetes .io / serviceaccount：ro "

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

/ proc / 90225 / mountinfo
5）ps aux | grep 90225
ルート902251.3 0.0 2837164 42580？ Ssl Feb01 72:40 ./monitor_program

1.7.2にも同じバグがあります

operationExecutor.UnmountVolumeがボリューム "default-token-bnttf"（一意の名前： "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf"）ポッド "ddc66e10-0711-11e8-b905-に対して開始されました6c92bf70b164 "kubelet [94382]：E0205 11：35：50.509169 94382nestedpendingoperations.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"のUnmountVolume.TearDownが失敗しました（一意の名前： "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf"）ポッド "ddc66e10-0711-11e8- b905-6c92bf70b164 "（UID：" ddc66e10-0711-11e8-b905-6c92bf70b164 "）：/ var / lib / kubelet / pods / ddc66e10-0711-11e8-b905-6c92bf70b164 / volumes / kubernetes.io〜secret / default-を削除token-bnttf：デバイスまたはリソースがビジーです

Dockerサービスを再起動するとロックが解除され、ポッドは数分以内に削除されます。 これはバグです。 Docker17.03の使用

Azureの同じ問題、Kube 1.8.7

数分前の1.8.9でも私たちに起こりました-誰かがこれを解決することを探していますか？ dockerを再起動すると役立ちますが、少しばかげています。

これは、GKEの最新の1.9.4リリースで私によく起こっています。 今のところこれを行っています：

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

ここGKE1.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の再起動も動作します。

ここGKE1.9.4-gke.1でも同じ問題
特定のファイルビートデーモンセットでのみ発生しますが、すべてのノードを再作成しても効果はなく、発生し続けます。

@TapppiのようなGKE1.9.4 -gke.1でもこの問題が発生します-ポッドはホストノードのdockerデーモンから削除されましたが、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

私たちにとって、ちょっと前に何か新しいことが起こりました。 kubectl delete pod NAME --grace-period=0 --forceを使用してスタックしたポッドを強制的に削除したとき、このポッドがあったノードが異常になりました。 docker 17-12CEを実行しており、そのボックスでdocker deamonを再起動すると、ノードのコルクが解除されました。

1.9.4-gke.1でこの問題が発生している場合は、 https：//github.com/kubernetes/kubernetes/issues/61178が原因である可能性があり@zackify @ nodefactory-bk @Tapppi @Stono

IIUC、このバグの元の問題は、コンテナ化されたkubeletの構成に関連していますが、これは異なります。

ところで、バージョンv1.9.3-gke.0新しいノードプールを作成することは、これに対する回避策v1.9.5はまだgkeで展開されておらず、すでにイースターであるためです。

これがバージョン1.9.3以降で修正されていることを誰かが確認できますか？ この動作のために深刻な問題が発生し、これが発生するたびにdockerを再起動するのは非常に困難です。

私にとっては1.9.6に修正されました

2018年4月4日水曜日、午前11:43 sokoow、 notifications @ github.comは次のように書いています。

これがバージョン1.9.3以降で修正されていることを誰かが確認できますか？ 我々は持っています
この動作のためにいくつかの深刻な問題が発生し、それぞれDockerを再起動します
これが発生する時間はsoost00pidです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
。

さて、 @ Stonoに感謝し

#!/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 \ "$@"

それは大丈夫ですか？ 他の誰かが同様のものを使用していますか？

私はあまりにも早く話しました。

  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どの

AzureAKS管理対象クラスターの1.9.6でもこの問題が発生します。

現時点でこの回避策を使用して、スタックしているすべてのポッドを選択して削除します（開発/スクラッチクラスターにポッドを終了するスワスができてしまうため）：

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

5月のAzureクラスターとAWSクラスターの両方でこれに遭遇しました-回避策はMikeElliotによって提供されました

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

ubuntu @ ip-10-0-0-22 ：〜$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h1 / 1実行中025d
kube-system kube-dns-5d7b4487c9-s4rsg3 / 3実行中025d
kube-system kubernetes-dashboard-f9577fffd-298r61 / 1実行中025d
kube-システム監視-grafana-997796fcf-wtz7n1 / 1実行中025d
kube-システム監視-influxdb-56fdcd96b-2phd21 / 1実行中025d
kube-system tiller-deploy-cc96d4f6b-jzqmz1 / 1実行中025d
onap dev-sms-857f6dbd87-pds580 / 1終了03h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp0 / 1終了03h
ubuntu @ ip-10-0-0-22 ：〜$ kubectl delete pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
警告：即時削除は、実行中のリソースが終了したことの確認を待ちません。 リソースはクラスター上で無期限に実行され続ける可能性があります。
ポッド「dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp」が削除されました
ubuntu @ ip-10-0-0-22 ：〜$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h1 / 1実行中025d
kube-system kube-dns-5d7b4487c9-s4rsg3 / 3実行中025d
kube-system kubernetes-dashboard-f9577fffd-298r61 / 1実行中025d
kube-システム監視-grafana-997796fcf-wtz7n1 / 1実行中025d
kube-システム監視-influxdb-56fdcd96b-2phd21 / 1実行中025d
kube-system tiller-deploy-cc96d4f6b-jzqmz1 / 1実行中025d
onap dev-sms-857f6dbd87-pds580 / 1終了03h
ubuntu @ ip-10-0-0-22 ：〜$ kubectl delete pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
警告：即時削除は、実行中のリソースが終了したことの確認を待ちません。 リソースはクラスター上で無期限に実行され続ける可能性があります。
ポッド「dev-sms-857f6dbd87-pds58」が削除されました
ubuntu @ ip-10-0-0-22 ：〜$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system heapster-76b8cd7b5-4r88h1 / 1実行中025d
kube-system kube-dns-5d7b4487c9-s4rsg3 / 3実行中025d
kube-system kubernetes-dashboard-f9577fffd-298r61 / 1実行中025d
kube-システム監視-grafana-997796fcf-wtz7n1 / 1実行中025d
kube-システム監視-influxdb-56fdcd96b-2phd21 / 1実行中025d
kube-system tiller-deploy-cc96d4f6b-jzqmz1 / 1実行中025d

これが同じ問題であるかどうかはわかりませんが、1.9.3から10.10.1にアップグレードしてからこの動作に気づき

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この署名は他の署名とは異なって見えます。 新しい号を開いて、ポッドの仕様も含めていただけますか？

これらの問題に関する更新はありますか？
この場合（Kubernetes 1.9.7、docker 17.03）、ノードがメモリ不足になり、ポッドが再スケジュールされた後、ポッドは終了状態になります。 最終的に、kubernetesダッシュボードとデプロイメントタブに多くのゴーストポッドがあり、4/1ポッドのデプロイメントを確認できます。
kubeletを再起動するか、名前空間内のすべてのポッドを強制終了することは役立ちますが、それは非常に貧弱な解決策です。

@AdiqqそれはDocker

ノードの1つでjournalctl -u kubelet -fを見てください。 「コンテナを殺せません」のようなメッセージがありましたgRpcエラー」（これを修正したので、実際のメッセージはありません）。

これを修正するために、各ノートでdockerを再起動しました。 Dockerの起動中に、壊れた状態のコンテナーをクリーンアップし、この古いポッドをすべて削除します。

昨日1.9.7でこれが発生し、ポッドが終了状態でスタックし、ログに「ポッドを強制終了する必要がある」だけだったので、取り除くには--force --grace-period=0を実行する必要がありました。

1.9.7-gke.0でこれも取得しました。
1.9.6-gke.1では問題はありませんでした。
しかし、1.9.4と1.9.5でそれを持っていました

動かなくなったポッドにはPVが取り付けられています。

ポッドを再デプロイまたは削除しても同じ効果があります。
問題のあるノードでkubeletを再起動しても機能しませんでした。 kubeletが再起動せず、ノード全体を再起動する必要がありました。

この間、PVはすでに他の場所にマウントされていると表示されていたため、ポッドを他のノードでスケジュールすることはできませんでした。

@Stono @ nodefactory-bk問題のあるノードのkubeletログを見て、問題を示している可能性のある詳細なログがあるかどうかを確認できますか？

cc @dashpole

1つのアプリが終了でスタックしました。
これは1.9.7-gke.1にあります
秘密が編集されたkubectldescribeポッドは次のとおりです。

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

グーグル画像のgkeでkubelet.logを見つける場所がわからない。 私が添付しているものを見つけました。
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
それを殺し、それを削除しました。
その後は順調にスタートしましたが、いつもより少し時間がかかりました。

念のために言っておきますが、これはそのアプリでは毎回発生するわけではありません。
おそらく1/4倍くらいだと思います。

k8s 1.9.6でこれをヒットすると、kubeletがCephfsマウントをアンマウントできない場合、ノード上のすべてのポッドは永久に終了したままになります。 回復するためにノードを再起動する必要がありましたが、kubeletまたはdockerの再起動は役に立ちませんでした。

@tuminoidCephの問題は異なって聞こえます。 新しい号を開いて、そのポッドのポッドイベントとkubeletログを提供できますか？

参考までに、クラスターを（k8s v1.10.2に）更新することで、この問題は解消されたようです。

添付はgkeで私のためにこれを再現します

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

k8s-nfs-test.yaml.txt

実行してから削除します。 'nfs-client'が削除されたままになります。 その理由は、ノードのハードマウントであり、「サーバー」が最初に削除されます。

最初にnfsサーバーを削除するときのnfsアンマウントの問題に対する@donbowmanは、StorageClassまたはPVで「ソフト」マウントオプションを設定できます。

方法がわかりませんか？ PersistentVolumeClaimで設定できますが、ここでは適用されません。
StorageClassがここに適用されるとは思いません（つまり、nfsサーバーの下のディスク下になります）。

この問題はnfs-clientにあります。
私は何かが足りないのですか？

nfs PVの場合、1.8以降のmountOptionsフィールドを設定して、ソフトマウントを指定できます。 nfsボリュームを動的にプロビジョニングする場合は、StorageClass.mountOptionsで設定することもできます。

はい。ただし、NFSを使用してマウントされているPVではありません。
それは私のNFSサーバーコンテナからのものです。
動的プロビジョニングはありません。

これはGoogleGCP + GKEを使用しています。 PVCは、ブロックIOであるPVを選択し、ext4としてコンテナにマウントしてNFSで再エクスポートします。

nfs-server（それ自体がポッド）からマウントされるコンテナーの2番目のセットは、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: /

nfsマウントを使用する2番目のコンテナセットの@donbowmanでは、

このようなもの：

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が終了状態で永久にスタックします。

k8s-nfs-test.yaml.txt

添付されているのは私が使用したyamlです。 私は「作成」を行い、それが表示されるのを待ち、クライアントにマウントがあり、ファイルの読み取り/書き込みが可能であることを確認してから、「削除」を行いました。

nfs-serverポッドは削除されますが、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ああ、すみません、私はソフトオプションについて間違っていました。 ソフトオプションは、サーバーにアクセスできないときにファイルシステム呼び出しがハングするのを防ぐだけですが、実際にはnfsボリュームのマウントを解除するのに役立ちません。 そのためには強制的なアンマウントを行う必要がありますが、現在は通過する方法がありません。 今のところ、これらのマウントを手動でクリーンアップし、ポッドを正しい順序で削除する必要があります（最初にnfsクライアント、次にnfsサーバー）。

timeo = 30とintrを追加しようとしましたが、同じ問題が発生します。
これにより、ノードがロックされ、ノードにログインして、基になるマウントでumount -f -lを実行する必要があります。その後、ポッドでkubectl delete --force --grace-period0を実行できます。

これはポッドに代わってマウントされているため、削除時に自動的にアンマウント（またはタイムアウト後に強制アンマウント）される可能性があるようです。

私はそのようなポッドをたくさん持っていたので、すべての終了ポッドをクリーンアップするコマンドを考え出す必要がありました。

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

グーグルの新しいファイルストアでも同じ問題が発生すると思います。

@donbowman iirc、問題は、nfsクライアントポッドの前にnfsサーバーポッドを終了していたためです。 ファイルストアを使用する場合、nfsサーバーをホストするためのポッドは不要になります。したがって、ファイアストアのインスタンス全体を削除しない限り、この問題は発生しないはずです。

ファイルストアを調整している場合、同じ問題は発生しませんか？ たとえば、特定のkubernetesデプロイメント用に起動し、最後に停止する場合、順序は保証されません。

しかし、問題は順序だけではなく、nfsクライアントポッドの削除はまったくアンマウントされず、ノードにマウントがぶら下がっているだけだと思います。 したがって、ファイルストア/サーバーが存在するかどうかに関係なく、ぶら下がっているマウントがあります。

ポッドが終了すると、ボリュームをアンマウントします（サーバーがまだそこにあると仮定します）。 サーバーが存在していてもマウントがぶら下がっている場合は、それがバグです。

PVCおよびPVで動的プロビジョニングを使用する場合、PVCを参照するすべてのポッドがそれを使用するまで、PVC（および基盤となるストレージ）を削除することはできません。 プロビジョニングを自分で調整する場合は、すべてのポッドでサーバーの使用が完了するまでサーバーを削除しないようにする必要があります。

多分これは可能な回避策です：＃65936

強制削除はkubectl delete po $pod --grace-period=0 --force 。 --nowフラグが機能していませんでした。 ＃65936についてはよくわかりませんが、 Unknown状態が発生したときにノードを強制終了したくありません。

1.10.5で同じ問題が発生している（デバイスが「ビジー」であるためにポッド内のファイルをアンマウントできないため、ポッドが終了したままになる）。 私にとって--grace-period=0 --forceすると、マウントポイントは引き続き存在します。 最終的には90000を超えるマウントポイントになり、クラスターの速度が大幅に低下しました。 ここでの回避策は、ポッドのフォルダーで検索を実行し、それらのファイルを再帰的にアンマウントしてから、ポッドフォルダーを再帰的に削除することです。
私の場合、サブパスを使用してconfigmapを既存のファイルを含む既存のフォルダーにマウントし、既存のファイルの1つを上書きします。 これは、1.8.6では問題なく機能していました。
元のポスターには、ポッドが数時間「終了」したままであると記載されています。私の場合は数日です。 手動の回避策を実行する場合を除いて、最終的にそれらがクリーンアップされるのを見たことがありません。

ログアグリゲーター（fluentdと同様）が原因で同じ問題が発生し、 /var/lib/docker/containersフォルダーがマウントされ、ポッドには多くのマウントがあります。

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に関連している可能性があります）

シークレットがないためにポッドが終了しないという問題がありました。 その名前空間にその秘密を作成した後、すべてが正常に戻りました。

スタックしたポッドを次のように削除しました。

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>:~$

AzureACSで実行されている同様の問題が発生しました。

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

それでもポッドがぶら下がっているため、対応するデプロイメントもスタックします。

また、ポッドイベントでのこれらの「ポッドを殺す必要がある」というメッセージにも悩まされています。 ちなみにこれはどういう意味ですか？ _Kubernetes_はポッドを強制終了する必要があると感じていますか、それとも_I_はポッドを強制終了する必要がありますか？

これは数日前に私に起こり、私は削除をあきらめてポッドをそのままにしました。 そして今日、それは姿を消し、やがて削除されたようです。

ちょうど今私に起こった。 --force--nowソリューションは私には機能しませんでした。 疑わしいkubeletログに次の行が見つかりました

8月6日15：25：37kube-minion-1 kubelet [2778]：W0806 15：25：37.986549 2778 docker_sandbox.go：263] NetworkPlugin cniがポッド「backend-foos-227474871-gzhw0_default」のステータスフックで失敗しました：予期しないコマンド出力nsenter：開くことができません：そのようなファイルまたはディレクトリはありません

そのため、次の問題が見つかりました。
https://github.com/openshift/origin/issues/15802

私はopenshiftではなくOpenstackを使用しているので、関連している可能性があると思いました。 Dockerを再起動するようにアドバイスしました。
dockerを再起動すると、「終了」でスタックしていたポッドが消えました。

これは回避策にすぎないことはわかっていますが、これを修正するために午前3時に目を覚ますことはありません。
これを使うべきだと言っているわけではありませんが、それは何人かの人々を助けるかもしれません。

スリープは、ポッドのterminationGracePeriodSecondsが（30秒）に設定されているものです。 それより長く存続している場合、このcronジョブは--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

Kubernetesv1.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にクリーンアップを続行するように促しません。 これをクリーンアップするためにDockerを定期的に再起動することは、コンテナーの実行を中断させるため、実際には受け入れられる解決策ではありません。

また、コンテナ自体がdocker ps -aから削除され、存在したという証拠がないため、これが実際にDockerの問題であるかどうかはわかりません。 Dockerバージョン17.03.2-ceを使用しています。

更新：シンボリックリンクを使用して、kubeletルートディレクトリをOS以外のボリュームにリダイレクトするようにノードを構成しました（ /var/lib/kubeletは、別のボリューム上の別のディレクトリを指すシンボリックリンクでした）。 --root-dirをkubeletに渡すように再構成して、シンボリックリンクではなく直接目的のディレクトリに移動し、kubeletを再起動すると、ボリュームマウントがクリーンアップされ、スタックしていたポッドがクリアされました。 Dockerの再起動を必要とせずに終了します。

minikubeでいくつかのポッドをローカルで実行しているときに、今日初めてこの問題を経験しました。

configmap / secretがボリュームとしてマウントされていなかったため、ポッドの束がTerminatingスタックしていました。 上記に投稿された提案/回避策/解決策は、これ以外は機能しませんでした。

ただし、注目に値すると思うことの1つは次のとおりです。

• kubectl get podsを実行すると、 Terminatingステータスのポッドのリストが表示されました。
• 私は走っていない場合はdocker ps | grep -i {{pod_name}} 、けれどもにおけるポッドのどれもTerminatingで見られるような状態kubectl get pods minikube VMで実行されていたが。

docker psがTerminating状態でスタックしたポッドのリストを返すことを期待していましたが、実際にはどれも実行されていませんkubectl get podsが、

この問題は、4つの展開で発生しました。 次に、すべてのマウントで「ローカルボリューム」から「ホストパス」に切り替えましたが、それはなくなりました。

シークレットがないためにポッドが終了しないという問題がありました。 その名前空間にその秘密を作成した後、すべてが正常に戻りました。

名前空間が「終了」状態の場合、どのようにして名前空間にシークレットを作成しますか？

kubectl delete --all pods --namespace = xxxxx --force --grace-period = 0

私のために働きます。

「--grace-period = 0」を忘れないでください。 重要です

kubectlは、「警告：即時削除は、実行中のリソースが終了したことの確認を待ちません。リソースは、クラスター上で無期限に実行され続ける可能性があります。」と警告しました。 --force --grace-period=0を使用する場合。
それが本当に起こるかどうか誰かに教えてもらえますか？

実際、ポッドを削除すると、何らかの理由で削除が遅れる場合があります。
また、フラグ「--force --grace-period = 0」を指定して「kubectldelete」を実行すると、
リソースオブジェクトはすぐに削除されます。

ポッドがすぐに削除されるかどうかを確認するのに役立ちますか？
それは警告メッセージが実際に不正確であることを意味しましたか？

@ windoze 、-force --grace-period = 0オプションを指定すると、ポッドAPIオブジェクトがAPIサーバーからすぐに削除されることを意味します。 Node kubeletは、ボリュームマウントのクリーンアップとコンテナの強制終了を担当します。 kubeletが実行されていないか、ポッドのクリーンアップ中に問題が発生した場合は、コンテナーがまだ実行されている可能性があります。 ただし、Kubeletは、可能な限りポッドをクリーンアップしようとし続ける必要があります。

それでも、kubeletが誤動作している可能性があるため、削除に永遠に時間がかかる可能性があることを意味しますか？
ポッドが削除されていることを確認する方法はありますか？
クラスターで実行されている巨大なポッドがいくつかあり、それらの2つのインスタンスを実行するのに十分なメモリがすべてのノードにないため、質問しています。
削除に失敗した場合、ノードは使用できなくなり、この問題が複数回発生した場合、最終的にこのポッドを実行できるノードがなくなるため、サービスは完全にダウンします。

昔ながらのDocker環境では、 kill -9などでポッドを強制的に強制終了できますが、k8sにはそのような機能がないようです。

@windozeポッドの削除が頻繁に失敗する理由を知っていますか？ kubeletが実行されていないか、kubeletがコンテナーを強制終了しようとしたが、エラーが発生して失敗したことが原因ですか？

このような状況は、数か月前に私のクラスターで数回発生し、kubeletは実行されていましたが、dockerデーモンに問題があるようで、エラーログが表示されずにスタックしました。
私の解決策は、ノードにログインしてコンテナプロセスを強制終了し、dockerデーモンを再起動することでした。
いくつかのアップグレードの後、問題はなくなり、二度と発生しませんでした。

kubectl delete pods <podname> --force --grace-period=0は私のために働いた！

@ shinebayar-g、 --forceの問題は、コンテナが実行を継続することを意味する可能性があることです。 Kubernetesにこのポッドのコンテナを忘れるように指示するだけです。 より良い解決策は、ポッドを実行しているVMにSSHで接続し、Dockerで何が起こっているかを調査することです。 docker killを使用してコンテナを手動で強制終了し、成功した場合は、通常どおりポッドを削除してみてください。

@agolomoodysaadaああ、それは理にかなっています。 説明ありがとう。 だから私は実際のコンテナが本当に削除されているのか正しくないのか本当にわかりませんか？

それで、2018年の終わりです、kube 1.12が出ています、そして...あなたはまだポッドのスタックに問題がありますか？

同じ問題があります。--force--grace-period = 0または--force--nowが機能しません。ログは次のとおりです。

root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat get pod node-exporter-zbfpx
NAME READY STATUS RESTARTS AGE
node-exporter-zbfpx0 / 1終了04d

root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat delete pod node-exporter-zbfpx --grace-period = 0 --force
警告：即時削除は、実行中のリソースが終了したことの確認を待ちません。 リソースはクラスター上で無期限に実行され続ける可能性があります。
ポッド「node-exporter-zbfpx」が削除されました

root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat get pod node-exporter-zbfpx
NAME READY STATUS RESTARTS AGE
node-exporter-zbfpx0 / 1終了04d

root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat delete pod node-exporter-zbfpx --now --force
ポッド「node-exporter-zbfpx」が削除されました

root @ r15-c70-b03-master01 ：〜＃kubectl -n infra-lmat get pod node-exporter-zbfpx
NAME READY STATUS RESTARTS AGE
node-exporter-zbfpx0 / 1終了04d

root @ r15-c70-b03-master01 ：〜＃

ポッドを編集してメタデータのファイナライザーセクションを削除しようとしましたが、失敗しました。

macOS上のkubectl1.13alphaとDockerfor Desktopを使用すると、これを100％再現可能な方法（同じリソース定義）で引き続き確認できます。 再現可能とは、それを修正する唯一の方法はMac用のDockerを出荷時設定にリセットすることであるように思われ、同じリソース（デプロイメントスクリプト）を使用してクラスターを再セットアップすると、同じクリーンアップスクリプトが失敗することを意味します。

なぜそれが関連するのかわかりませんが、私のクリーンアップスクリプトは次のようになります。

#!/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で実行されているコンテナーがないことを確認できます。ポッドの終了時にハングアップしているのは、kubectlだけです。 ポッドをdescribeすると、ステータスはStatus: Terminating (lasts <invalid>)として表示されます。

もう一度私に起こった。 NFS共有を使用してperconapmm-serverをインストールしようとしましたが、ソフトウェアが起動しなかったため、削除しましたが、これが発生しました。 （永続的な主張はこのソフトウェアでは機能しませんでした）。 古き良きkubectl delete pods <podname> --force --grace-period=0もう一度呼んでいると思います。 しかし、問題は、このポッドがどこにあるかをどうやって知るのかということです。

@ shinebayar-g、それがあったVMにSSHで接続し、 docker psます。

そこにはありませんでした。VMが少ないので、どれが正しいかを確認する方法を尋ねました。 :)

@ shinebayar-gこれはうまくいくかもしれません：
kubectl describe pod/some-pod-name | grep '^Node:'

同じ問題。

docker psは、コンテナが期待どおりに終了（0）ではなく「デッド」ステータスにあることを検出しました

コンテナを手動で削除すると、次のDockerログエントリが表示されます。

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

残念ながら、回線が切断されていますが、問題は、プロセスがもう存在しないことでした。

k8sv1.11.0ではまだこの問題に悩まされています。 ポッドをクリーンアップするために行うことのチェックリストは次のとおりです。

• ポッドに接続されているすべてのリソースが再利用されていることを確認してください。 それらのすべてがkubectl get表示されるわけではありません。 それらのいくつかは、ポッドが実行されているKubeletにのみ認識されているため、ローカルでログストリームを追跡する必要があります
  
  
  
  • 特に、 Kubeletがdevice or resource busyメッセージで文句を言うumountディレクトリ
  
  
• 他のすべてが失敗した場合、失敗したポッドをkubectl edit 、 finalizers: → - foregroundDeletionを削除します

さらに2つのヒント：

• 定常状態では、混乱していないKubeletは定期的なメッセージをログに記録しないはずです。 何かを解放するためのあらゆる種類の繰り返しの失敗は、スタックしたポッドの症状です。
• kubectl deleteコマンドを別のウィンドウでブロックしたままにして、進行状況を監視できます（すでに何度も「削除」したポッドでも）。 kubectl deleteは、最後にスタックしたリソースが解放されるとすぐに終了します。

今日これに直面しました。
何が行われたか：

1. ノードにSSHで接続し、コンテナを手動で削除します
2. その後、 kubectl get podsは、スタックしたコンテナ0/1 terminating （以前は1/1 terminating ）を表示します
3. ポッドからfinalizersセクションを削除します。 foregroundDeletion （$ kubectl edit pod / name）->コンテナがポッドリストから削除されました
4. デプロイメントの削除->デプロイメントに関連するすべてのものが削除されました。

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"}

シークレットのマウントを開始したときも同じ問題に直面しています（多くのポッドと共有されています）。 ポッドはterminating状態になり、永久にそこにとどまります。 私たちのバージョンはv1.10.0です。 アタッチされたDockerコンテナーはなくなりましたが、 --grace-period=0 --forceオプションを使用してポッドを強制的に削除しない限り、APIサーバーの参照は残ります。

恒久的な解決策を探しています。

さて、最近、ステージングクラスターでruncエクスプロイトCVE-2019-5736をテストしました。すでにご存知のとおり、エクスプロイトはホストマシン上のruncバイナリを書き換えます。 その破壊的なエクスプロイト。 その後、クラスターで奇妙な動作が見られました。 すべてのポッドが終了状態でスタックしました。 回避策は、影響を受けたノードパージドッカーを排出して再インストールすることでした。 その後、すべてのポッドとk8sクラスターは以前と同じように正常に機能します。 たぶんそれはdockerの問題であり、それを再インストールすることであなたの問題も解決します！。 ありがとう

ここに新しいv1.13.3をインストールします。 これは私にも起こります。 いくつかのポッドに同じNFSボリュームをマウントしたので、それと関係があるようです。

この問題は、存在しないシークレットを使用してボリュームを作成しようとするデプロイメントを作成するときに発生します。そのデプロイメント/サービスを削除すると、 Terminatingポッドが残ります。

v.1.12.3で同じ問題に直面し、-grace-period = 0 --forceまたは--nowは両方とも無効になり、これも無効に属するステートフルセットを削除します

SMB（私は思う？）マウントに関する同じ問題（Azureファイルはhttps://docs.microsoft.com/en-us/azure/aks/azure-files-volumeに従って共有します）。

13.3と同じ問題

ポッドがほぼ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 version: v0.34.1

@ardalanrazaviなぜ2日間終了するのですか？ 5分経っても削除されない場合は、強制的に削除してください

@nmors

なぜ2日間終了するのですか？

それは良い質問です。 私たちは皆それを知りたいのです。

5分経っても削除されない場合は、強制的に削除してください

強制的に削除すると、クラスターは不整合な状態になります。 （minikubeを使用すると、それは実際のクラスターではないので、確かにそれほど心配する必要はありません）

@AndrewSav

率直に言って、ここで他の解決策は見当たりません。

確かに、クラスターは「一貫性のない状態」のままになります。 これが正確に何を意味するのか理解したいと思います。 強制閉鎖は悪いです。 私もそれが好きではありませんが、私の場合は、必要に応じてリソースを破棄して再デプロイすることに抵抗はありません。

私の場合、NFSマウントを備えたポッドでのみ終了するようにスタックしているようです。 また、クライアントがダウンしようとする前にNFSサーバーがダウンした場合にのみ発生します。

私は問題を修正しました。終了してスタックしているすべてのポッドがすべて1つのノード上にあり、ノードが再起動され、問題がなくなったことを特定できました。

@ nmors @ AndrewSav私も強制削除を行いました。

ポッドを削除する前にnfsサーバーを削除すると、アンマウントが永久にハングすることが知られています。 その場合は、nfsサーバーが常に最後に削除されるように、削除を注文することをお勧めします。

@ msau42私のNFSサーバーはk8sクラスターの一部ではありません-それはすべて一緒に別個のアプライアンスとマシンです

k8sクラスターの一部であるかどうかは関係ありません。 nfsサーバーにアクセスできない場合、アンマウントは再びアクセスできるようになるまでハングします。

@ msau42これは奇妙なことです。オンラインに戻ったときでも、ポッドが終了し続けていると確信しているからです。 新しいポッドが起動し、正常にマウントされます。

私はkubernetesでNFSサーバーを使用し、その後にこの例を示しますが、残念ながらこれは非常に頻繁に発生します。

@ 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

それ以来、問題は発生していません。より単純な構成の方が信頼性が高いことを期待して、これを約1週間だけ変更しました。見てみましょう...多分これで問題が解決しますか？

回避策として、 /var/log/syslogから最後の行をいくつか取得し、「Operation for ... remove / var / lib / kubelet / pods ... directorynotempty」や「nfs」などのエラーを検索するスクリプトを作成しました。 ..デバイスがビジーです... unmount.nfs "または"古いNFSファイルハンドル "。
次に、pod_idまたはpod fullディレクトリのいずれかを抽出し、マウントされているもの（ mount | grep $pod_id ）を確認してから、すべてをアンマウントして、対応するディレクトリを削除します。 最終的に、kubeletが残りを実行し、ポッドを正常にシャットダウンして削除します。 終了状態のポッドはもうありません。

そのスクリプトをcronに入れて、毎分実行します。 結果として、3〜4か月後でも、今のところ問題はありません。
注：このアプローチは信頼性が低く、クラスターのアップグレードごとにチェックする必要がありますが、機能します。

私はバージョン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]

--force --grace-period=0を使用すると、参照を削除するだけで済みます...ノードにSSHで接続すると、Dockerコンテナが実行されていることがわかります。

私の場合、ノードにメモリ不足がありました。
そしてカーネルは繊毛剤を殺しました、それはポッドの終了を妨げるようです。
ノードを再起動したところ、クリアされました。

私の経験では、ノードのsudo systemctl restart dockerが役立ちます（ただし、明らかにダウンタイムがあります）。

そして、これは、A）メモリ制限に近いかB）CPUが不足しているランダムノードでまだ定期的に発生しています（まだメモリに関連している可能性のあるkswapd0の問題のbc、または実際の負荷）

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間操作がないと腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

古い問題は、30日間操作がないと腐敗します。
/remove-lifecycle rottenして、問題を新規としてマークします。
腐った問題は、さらに30日間操作がないと終了します。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ライフサイクル腐敗

腐った問題は、30日間操作がないと終了します。
/reopen問題を再開します。
/remove-lifecycle rottenして、問題を新規としてマークします。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/閉じる

@ fejta-bot：この問題を解決します。

これはまだ非常に活発な問題であり、k8s1.15.4とRHELDocker1.13.1です。 ポッドは常にTerminatingとどまりますが、コンテナはすでになくなっており、k8sはそれ自体を理解できませんが、人間の操作が必要です。 テストスクリプトを実際のPITAにします。

/ reopen
/ remove-腐ったライフサイクル

@tuminoid ：課題/ PRを作成したか、共同編集者でない限り、再開することはできません。

/ reopen
/ remove-腐ったライフサイクル

@mikesplain ：この問題を再開しました。

ここでも同じです。ポッドが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

kubeletログをチェックして、ボリュームのアンマウントの失敗や孤立したポッドに関するメッセージがないかどうかを確認できますか？

私もこれを見ました
E1206 03：05：40.247161 25653 kubelet_volumes.go：154]孤立したポッド "0406c4bf-17e3-4613-a526-34e8a6cee208"が見つかりましたが、ボリュームパスがまだディスクに存在します：これと同様のエラーが合計8つありました。 それらを見るために冗長性を上げてください。

私も見ました。 kubectlがDockerコンテナに接続できず、終了ポッドが現在存在するために新しいポッドを作成できないと文句を言うため、ログを確認できません。 むしろ迷惑です。

それも経験していて、Kubernetesが古いポッドを適切にクリーンアップしたかどうかを確認する必要があるのはかなり面倒です。
うまくいけば、これはすぐに修正されます。

そして、この問題はどうですか？ 解決しましたか？ 私も同じですが、これはすぐには起こりませんが、ノードの開始後しばらくして、ノードをリセットすると、しばらくの間、すべてが良好になります

ポッドにファイナライザーがあり、削除されないようになっていることを確認できますか？

発行されたポッドにファイナライザーはありません

参考までに、以下を使用して強制削除でこれを解決しました。

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

そして、これでポッドを正常に終了できたと思います。 それ以来、私はこの問題を二度と経験していません。 それ以来更新している可能性があるので、バージョンの問題である可能性がありますが、問題を確認してからかなり時間が経過しているため、100％ではありません。

これは、ポッドのメモリが不足しているときに発生します。 メモリ使用量が再び減少するまで終了しません。

参考までに、以下を使用して強制削除でこれを解決しました。

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

そして、これでポッドを正常に終了できたと思います。 それ以来、私はこの問題を二度と経験していません。 それ以来更新している可能性があるので、バージョンの問題である可能性がありますが、問題を確認してからかなり時間が経過しているため、100％ではありません。

それは私のために働いた

kubectl delete pods <pod> --grace-period=0 --forceは一時的な修正です。影響を受けるポッドのいずれかでフェイルオーバーが発生するたびに、手動で修正を実行したくありません。 私の飼育係のポッドは、minikubeとAzureAKSで終了していません。

2020年3月9日更新
preStopライフサイクルフックを使用して、ポッドを手動で終了しました。 私の動物園の飼育係のポッドは終了状態で立ち往生していて、コンテナ内からのタームシグナルに応答しませんでした。 私は基本的に同じマニフェストを他の場所で実行していて、すべてが正しく終了しました。根本的な原因が何であるかはわかりません。

同じ問題、非常に迷惑

同じ問題:(ポッドが3日以降終了し続けている

参考までに、以下を使用して強制削除でこれを解決しました。

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

そして、これでポッドを正常に終了できたと思います。 それ以来、私はこの問題を二度と経験していません。 それ以来更新している可能性があるので、バージョンの問題である可能性がありますが、問題を確認してからかなり時間が経過しているため、100％ではありません。

また、 --forceフラグは、必ずしもポッドが削除されたことを意味するわけではなく、確認を待たないだけです（そして、私の理解では、参照を削除します）。 警告The resource may continue to run on the cluster indefinetely述べられているように。

編集：私は情報が不十分でした。 さらなる動機については、以下のelrok123sコメントを参照してください。

参考までに、以下を使用して強制削除でこれを解決しました。

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

そして、これでポッドを正常に終了できたと思います。 それ以来、私はこの問題を二度と経験していません。 それ以来更新している可能性があるので、バージョンの問題である可能性がありますが、問題を確認してからかなり時間が経過しているため、100％ではありません。

また、 --forceフラグは、必ずしもポッドが削除されたことを意味するわけではなく、確認を待たないだけです（そして、私の理解では、参照を削除します）。 警告The resource may continue to run on the cluster indefinetely述べられているように。

正解ですが、要点は--grace-period=0強制的に削除を実行することです:)コメントが関連する理由がわかりません：/

基になるコンテナがあるので、彼のコメントは適切だと思います
（dockerなど）はまだ実行されていて、完全に削除されていない可能性があります。
それが「削除された」という幻想は、時には少し誤解を招くものです

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
。

それは確かに私のポイントです。 これを使用すると、 --forceメソッドは、基になる負荷がノードを圧迫するリスクがあり、必ずしも元の問題を修正するとは限りません。 最悪の場合、それは「私がそれを見ることができない場合、それは存在しない」です-それは検出するのがさらに難しくなる可能性がある修正です。

または、 --grace-period=0は、基になるコンテナ@ elrok123の削除を強制することが保証されていると言っていますか？
その場合、私のコメントは誤った知識に基づいており、無関係ですが、 --grace-period=0を使用しているときに実行中のコンテナーを離れるリスクが残っている場合は、私の主張もそうです。

@oscarlofwenhamn私が知る限り、これはそのポッド内のすべてのプロセスでsigkillを効果的に実行し、ゾンビプロセスを確実に削除します（出典：「ポッドの終了」のポイント6- https ：//kubernetes.io/docs/concepts / pods / pod /＃ ：〜：text = When％20the％20grace％20period％20expires、period％200％20（immediate％20deletion））、ポッドを正常に削除します（すぐには実行されない場合がありますが、実行されます）。起こります。）

ガイドには、参照は削除されますが、ポッド自体は削除されないと記載されています（ソース：「強制削除」-https：//kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ）ただし、grace-period = 0は、すぐにではなく、ポッドを効果的にsigkillする必要があります。

遭遇したシナリオを処理するためのドキュメントと推奨される方法を読んでいます。 私が特に遭遇した問題は、再発する問題ではなく、一度起こった問題でした。 これに対する実際の修正はデプロイメントを修正していると思いますが、そこに到達するまでは、この方法が役立つはずです。

@ elrok123ブリリアント-私は確かに情報

現在、ポッドは終了状態で2日以上スタックしています。

私にとって、名前空間はTerminatingスタックしています。 ポッドはリストされていません。 サービスなし...なし。 名前空間は空です。 それでも...終了で立ち往生。

@JoseFMPはkubectlを使用して名前空間からyamlをリクエストします。これには、プロセスを保留しているファイナライザーが含まれている可能性があります。

@JordyBottelierありがとうございます。

ファイナライザーはありません。 まだ立ち往生Terminating

@JoseFMPは、削除する）スクリプトです。保存して、。/ script_nameを実行するだけです。：
`` `

！/ bin / bash

set -eo pipefail

die（）{echo "$ *" 1>＆2; 出口1; }

need（）{
どの "$ 1"＆> / dev / null || 「バイナリ '$ 1'がありませんが、必須です」
}

前提条件の確認

「jq」が必要
「カール」が必要
「kubectl」が必要

PROJECT = "$ 1"
シフト

test -n "$ PROJECT" || 死ぬ "引数がありません：kill-ns「」

kubectlプロキシ＆> / dev / null＆
PROXY_PID = $！
killproxy（）{
$ PROXY_PIDを殺す
}
トラップkillproxyEXIT

sleep 1＃プロキシに1秒与える

kubectl get namespace "$ PROJECT" -o json | jq'del（.spec.finalizers [] | select（ "kubernetes"）） '| curl -s -k -H "Content-Type：application / json" -X PUT -o / dev / null --data-binary @ -http ：// localhost ：8001 / api / v1 / namespaces / $ PROJECT / finalize && echo "Killed namespace：$ PROJECT" `` `

また、これに遭遇したようです。インフラストラクチャのどこにも表示されなくなったが、ゴーストとして実行されている1つのポッドを含め、複数のポッドが終了し続けています（リクエストを処理し、デプロイスケールでもリクエストが処理されていることを確認できます）ゼロの）。

このポッドの可視性も制御もありません。すべてのノードを強制的にシャットダウンせずに、このような状況をトラブルシューティングする方法を尋ねます。

また、これに遭遇したようです。インフラストラクチャのどこにも表示されなくなったが、ゴーストとして実行されている1つのポッドを含め、複数のポッドが終了し続けています（リクエストを処理し、デプロイスケールでもリクエストが処理されていることを確認できます）ゼロの）。

このポッドの可視性も制御もありません。すべてのノードを強制的にシャットダウンせずに、このような状況をトラブルシューティングする方法を尋ねます。

ノードのdockerにアクセスする必要があります。
私のdink （https://github.com/Agilicus/dink）を使用すると、Dockerアクセス​​付きのシェル付きのポッドまたはポッドへのSSHが表示されます。
docker ps -a
docker stop ####

幸運を。

指示をありがとう。

私は最終的にこれを解決することができましたが、それでもそれがどのように発生するのか少し戸惑いました（私にとってポッドは完全に見えませんでした）。 実稼働中だったので、物事は少し多忙で、診断を実行できませんでしたが、それが再び発生した場合は、より良いバグレポートを作成できることを願っています。

同様の症状が見られると、ポッドは終了し続けます（興味深いことに、ポッドはすべて、準備/活気のためのexecタイプのプローブを備えています）。 ログを見ると、次のように表示されます。kubelet[1445]：I1022 10：26：32.203865 1445prober.go：124]「test-service-74c4664d8d-58c96_default（822c3c3d-082a-4dc9-943c-19f04544713e）：test」の準備プローブ-service "failed（failure）：OCIランタイムexecが失敗しました：execが失敗しました：停止したコンテナーを実行できません：不明。 このメッセージは永遠に繰り返され、execプローブをtcpSocketに変更すると、ポッドを終了できるように見えます（テストに基づいて、フォローアップします）。 ポッドには「実行中」のコンテナの1つがありますが、「準備完了」はないようです。「実行中」のコンテナのログには、サービスが停止したかのように表示されます。

これは、ノードの負荷が高く、vm.max_map_countがデフォルトよりも高い値に設定されている場合、containerd 1.4.0で発生します。containerd-shimは、stdout fifoを排出せず、排出されるのをブロックしますが、dockerdはgeを実行できません。プロセスがなくなったことをcontainerdからのイベント/確認応答。

@discantoこの情報を共有してございます。 問題は修正または追跡されていますか？

@ Random-Liu

バグは3年以上開いています。 ポッドが終了し続けるのは、さまざまな理由で発生する可能性があります。 ケースを報告するときは、ポッドが動かなくなったかどうかを確認するために、いくつかのkubeletログを投稿すると非常に役立ちます。