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

Biasanya pembersihan volume dan jaringan menghabiskan lebih banyak waktu saat penghentian. Dapatkah Anda menemukan di fase mana pod Anda macet? Pembersihan volume misalnya?

Biasanya pembersihan volume dan jaringan menghabiskan lebih banyak waktu saat penghentian.

Benar. Mereka selalu mencurigakan.

@igorleao Anda dapat mencoba kubectl delete pod xxx --now juga.

Hai @resouer dan @dixudx
Saya tidak yakin. Melihat log kubelet untuk pod berbeda dengan masalah yang sama, saya menemukan:

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.

Seperti yang Anda lihat, cluster ini memiliki Calico untuk CNI.
Baris berikut menarik perhatian saya:

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 

Apakah ada cara yang lebih baik untuk mengetahui fase mana pod yang macet?

kubectl delete pod xxx --now tampaknya bekerja dengan cukup baik, tetapi saya benar-benar ingin mengetahui penyebab utamanya dan menghindari interaksi manusia.

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

Tampaknya kubelet/mount gagal memasang configmap sebagai volume karena penggantian nama file tersebut.

@igorleao Apakah ini dapat direproduksi? Atau tidak begitu stabil, terjadi sesekali. Saya pernah menemui kesalahan seperti itu sebelumnya, hanya untuk memastikan.

@dixudx itu terjadi beberapa kali sehari untuk cluster tertentu. Kluster lain yang dibuat dengan versi kops dan kubernetes yang sama, di minggu yang sama, berfungsi dengan baik.

@igorleao Karena log menunjukkan bahwa pengelola volume gagal menghapus direktori secrete karena perangkat sedang sibuk.
Bisakah Anda memeriksa apakah direktori /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key masih terpasang atau tidak? Terima kasih!

@igorleao bagaimana Anda menjalankan kubelet? dalam wadah? jika demikian, bisakah Anda memposting unit systemd atau konfigurasi buruh pelabuhan untuk kubelet?

Kami melihat perilaku serupa. Kami menjalankan kubelet sebagai container dan masalah diatasi sebagian dengan memasang /var/lib/kubelet sebagai shared (secara default volume mount docker sebagai rslave). Tetapi kami masih melihat masalah serupa, tetapi lebih jarang. Saat ini saya menduga bahwa beberapa pemasangan lain harus dilakukan dengan cara yang berbeda (mis. /var/lib/docker atau /rootfs )

@stormltf Bisakah Anda memposting konfigurasi container kubelet Anda?

@stormltf Anda menjalankan kubelet di container dan tidak menggunakan --containerized flag (yang melakukan beberapa trik dengan mount ). Yang pada dasarnya berarti bahwa semua mount yang dilakukan oleh kubelet akan dilakukan di namespace mount container. Untung mereka akan diusulkan kembali ke namespace mesin host (seperti yang Anda miliki / var / lib / kubelet as shared), tapi saya tidak yakin apa yang terjadi adalah namespace dihapus (ketika kubelet container dihapus).

Bisakah Anda menyenangkan untuk pod macet lakukan berikut ini:

pada node tempat pod dijalankan

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• dan sama pada node itu sendiri mount | grep STUCK_POD_UUID .

Lakukan hal yang sama untuk pod yang baru dibuat. Saya tidak ingin melihat beberapa mount /var/lib/kubelet (misalnya default-secret)

@stormltf apakah Anda merestart kubelet setelah dua pod pertama dibuat?

@stormltf Anda dapat mencoba membuat /var/lib/docker dan /rootfs sebagai shared (yang tidak saya lihat di inspeksi buruh pelabuhan, tapi lihat di dalam container) mountpoint.

/ sig storage

Untuk beberapa hal itu mungkin membantu. Kami menjalankan kubelet dalam container buruh pelabuhan dengan --containerized flag dan dapat memecahkan masalah ini dengan memasang /rootfs , /var/lib/docker dan /var/lib/kubelet sebagai mount bersama. Pemasangan terakhir terlihat seperti ini

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

Untuk lebih jelasnya. Ini tidak menyelesaikan masalah dengan benar karena untuk setiap bind mount Anda akan mendapatkan 3 mount di dalam kubelet container (2 parasit). Tapi setidaknya mount bersama memungkinkan untuk melepasnya dengan mudah dengan satu tembakan.

CoreOS tidak memiliki masalah ini. Karena menggunakan rkt dan bukan buruh pelabuhan untuk kubelet container. Dalam kasus kami kubelet berjalan di Docker dan setiap mount di dalam kubelet continer diusulkan menjadi /var/lib/docker/overlay/... dan /rootfs itulah mengapa kami memiliki dua parasit mount untuk setiap volume mount bind:

• satu dari /rootfs di /rootfs/var/lib/kubelet/<mount>
• satu dari /var/lib/docker di /var/lib/docker/overlay/.../rootfs/var/lib/kubelet/<mount>

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

Saya memiliki masalah yang sama dengan Kubernetes 1.8.1 di Azure - setelah penerapan diubah dan pod baru telah dimulai, pod lama macet saat dihentikan.

Saya memiliki masalah yang sama di Kubernetes 1.8.2 di IBM Cloud. Setelah pod baru dijalankan, pod lama terhenti saat dihentikan.

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

Saya telah menggunakan kubectl delete pod xxx --now serta kubectl delete pod foo --grace-period=0 --force tidak berhasil.

Jika akar penyebab masih sama (pemasangan yang diusulkan tidak benar) maka ini adalah bug khusus distribusi imo.

Jelaskan bagaimana Anda menjalankan kubelet berjalan di cloud IBM? unit systemd? apakah itu memiliki --containerized flag?

ini dijalankan dengan flag --containerized disetel ke 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

--bendera terkontainer: Tidak

oke, saya butuh info lebih lanjut, silakan lihat komentar saya di atas https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

dan juga tolong tunjukkan konten /lib/systemd/system/kubelet.service dan jika ada sesuatu tentang kubelet di /etc/systemd/system tolong bagikan juga.

Secara khusus, jika kubelet berjalan di buruh pelabuhan, saya ingin melihat semua bind mount -v .

Hari ini saya mengalami masalah yang mungkin sama dengan yang dijelaskan, yaitu pod di salah satu sistem pelanggan kami macet dalam status penghentian selama beberapa hari. Kami juga melihat kesalahan tentang "Error: UnmountVolume.TearDown gagal untuk volume" dengan "perangkat atau sumber daya sibuk" berulang untuk setiap pod yang macet.

Dalam kasus kami, tampaknya ada masalah dengan buruh pelabuhan di sistem berbasis RHEL / Centos 7.4 yang tercakup dalam masalah moby ini: https://github.com/moby/moby/issues/22260 dan PR moby ini: https: // github .com / moby / moby / pull / 34886 / files

Bagi kami, setelah kami menyetel opsi sysctl fs.may_detach_mounts = 1 dalam beberapa menit semua Pod Pengakhiran kami dibersihkan.

Saya juga menghadapi masalah ini: Pod macet dalam status Terminating di 1.8.3.

Kubelet log yang relevan dari node:

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 dijalankan sebagai unit systemd (bukan dalam container) di Ubuntu 16.04.
Seperti yang Anda lihat, ada mount ke server NFS dan entah bagaimana kubelet mencoba menghapus direktori mount karena menganggap direktori ini tidak di-mount.

Spesifikasi volume dari pod:

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

UPD : Saya menghadapi masalah ini sebelumnya juga di 1.6.6

Mengalami hal yang sama di Azure ..

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

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

jelaskan pod nginx-56ccc998dd-nnsvj

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

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

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

cat /etc/systemd/system/kubelet.service

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

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

[Install]
WantedBy=multi-user.target

Tampaknya ada bug berbeda yang terkait dengan masalah. Kami memiliki keduanya di cluster 1.8.3 kami.

1. https://github.com/moby/moby/issues/31768 . Ini bug buruh pelabuhan. Dapat direproduksi di docker-ce = 17.09.0 ~ ce-0 ~ ubuntu.
2. Kedua lebih menarik dan mungkin terkait dengan beberapa kondisi balapan di dalam kubelet.
   Kami memiliki banyak pod yang menggunakan volume persistensi NFS dengan sub-jalur yang ditentukan dalam pemasangan kontainer, entah bagaimana beberapa di antaranya macet dalam status penghentian setelah penerapan dihapus. Dan ada banyak pesan di 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

Dan direktori sebenarnya tidak kosong, itu dilepas dan berisi direktori "subpath" kami!
Salah satu penjelasan dari perilaku tersebut:

1. P1: Mulai buat pod atau sinkronkan pod
2. P1: Kirim sinyal ke palungan volume untuk memasang / memasang kembali.
3. P1: Menunggu pemasangan selesai.
4. P1: Menerima sinyal pemasangan yang berhasil (Sebenarnya cukup periksa apakah semua volume sudah terpasang)
5. Entah bagaimana volume menjadi tidak terpasang. Mungkin proses penghapusan lain unmount atau beberapa bug OS, atau tindakan pengumpul sampah.
6. P1: Lanjutkan membuat kontainer dan buat subdirektori di mount point (sudah dilepas).
7. Lagipula pod langkah sebelumnya tidak dapat dihapus, karena direktori pemasangan tidak kosong.

Lebih banyak log:

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

Entah bagaimana beberapa proses pembersihan ((dswp * diinginkanStateOfWorldPopulator) findAndRemoveDeletedPods ()) memulai unmount volume saat pod dalam status inisialisasi:

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"

Inisialisasi dan penghapusan pod dijalankan dalam waktu yang bersamaan.
Untuk mengulang dengan bug, Anda harus memulai dan segera menghapus / memperbarui sekitar 10 penerapan (diuji untuk satu minion) dan mungkin operasi pemasangan Anda harus tidak terlalu cepat.

Dipengaruhi oleh bug yang sama di GKE. Apakah ada solusi yang diketahui untuk masalah ini? Menggunakan --now tidak bekerja.

Saya telah memperbaiki bug ini, tetapi saya tidak yakin itu akan digabungkan oleh tim kubernetes.

@dreyk Bisakah Anda memberikan rincian lebih lanjut tentang apa yang Anda temukan untuk bug ini dan apa perbaikan Anda sehingga tim penyimpanan dapat memeriksanya? Terima kasih!

@ gm42 Saya dapat mengatasi masalah ini secara manual di GKE dengan:

1. SSH ke dalam node tempat pod macet dijadwalkan
2. Menjalankan docker ps | grep {pod name} untuk mendapatkan ID Kontainer Docker
3. Menjalankan docker rm -f {container id}

Di GKE, mengupgrade node membantu secara instan.

Memiliki bug yang sama di cluster lokal saya yang disiapkan menggunakan kubeadm .

docker ps | grep {pod name} pada node tidak menunjukkan apa-apa, dan pod macet dalam status penghentian. Saat ini saya memiliki dua pod di negara bagian ini.

Apa yang dapat saya lakukan untuk menghapus pod secara paksa? Atau mungkin mengubah nama pod? Saya tidak dapat memutar pod lain dengan nama yang sama. Terima kasih!

Saya telah menemukan alasannya di Cluster 1.7.2 saya,
karena program monitor lain memasang jalur root /
jalur root berisi /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
jadi ketika kubelet menghapus pod, tetapi tidak bisa melepaskan volume, pesannya adalah:
perangkat atau sumber daya sibuk

Langkah:
1) sudo journalctl -u kubelet
shell ini membantu saya menemukan pesan kesalahan,
2) sudo buruh pelabuhan memeriksa
temukan io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
dan
HostConfig -> Binds -> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf:/var/run/secrets/kubernetes .io / servi ceaccount: ro "

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

/ proc / 90225 / mountinfo
5) ps aux | grep 90225
root 90225 1,3 0,0 2837164 42580? Ssl 01 Feb 72:40 ./monitor_program

Memiliki bug yang sama di 1.7.2 saya

operationExecutor.UnmountVolume dimulai untuk volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8-b905- 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] Operasi untuk" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf \" (\ "ddc66e10-0711-11e8-b905-6c92bf70b164 \") "gagal. Tidak ada percobaan ulang yang diizinkan hingga 2018-02-05 11: 37: 52.509148953 +0800 CST (durasiBeforeRetry 2m2s). Kesalahan: UnmountVolume.TearDown gagal untuk volume "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-0711-11e8- b905-6c92bf70b164 "(UID:" ddc66e10-0711-11e8-b905-6c92bf70b164 "): hapus /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.iofault token-bnttf: perangkat atau sumber daya sibuk

Memulai ulang layanan buruh pelabuhan melepaskan kunci dan pod dihapus dalam beberapa menit. Ini adalah bug. Menggunakan buruh pelabuhan 17.03

Masalah yang sama di sini di Azure, Kube 1.8.7

Terjadi pada kami beberapa menit yang lalu di 1.8.9 juga - ada yang mencari untuk menyelesaikan ini? Memulai ulang buruh pelabuhan membantu, tapi ini agak konyol.

Hal ini sering terjadi pada saya pada rilis 1.9.4 terbaru di GKE. Sedang melakukan ini untuk saat ini:

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

Masalah yang sama di sini di GKE 1.9.4-gke.1
tampaknya terkait dengan volume mount.
Itu terjadi setiap kali dengan filebeats diatur seperti yang dijelaskan di sini:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

Kubelet log menunjukkan ini:

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
sepertinya berhasil.
juga memulai ulang karya kubelet.

Masalah yang sama di sini di GKE 1.9.4-gke.1
Hanya terjadi dengan daemonset pemukul file tertentu, tetapi membuat ulang semua node juga tidak membantu, itu terus terjadi.

Juga mengenai masalah ini pada GKE 1.9.4-gke.1 seperti @Tapppi - pod telah dihapus dari daemon buruh pelabuhan pada node host tetapi kubernetes telah macet di 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

Bagi kami, sesuatu yang baru baru saja terjadi beberapa saat yang lalu, ketika saya secara paksa menghapus pod yang macet menggunakan kubectl delete pod NAME --grace-period=0 --force , node tempat pod ini berada menjadi tidak sehat. Kami menjalankan buruh pelabuhan 17-12CE, dan memulai ulang docker deamon di kotak itu membantu dan membuka simpul simpul.

Untuk orang-orang yang melihat masalah ini di 1.9.4-gke.1, kemungkinan besar karena https://github.com/kubernetes/kubernetes/issues/61178 , yang telah diperbaiki di 1.9.5 dan sedang diluncurkan di GKE minggu ini. Masalah ini terkait dengan pembersihan mount subpath sebuah file (bukan direktori). @zackify @ nodeactory-bk @Tapppi @So

IIUC, masalah asli dari bug ini terkait dengan konfigurasi kubelet yang di-container, yang berbeda.

BTW, membuat kumpulan node baru dengan versi v1.9.3-gke.0 adalah solusi kami untuk ini, karena v1.9.5 masih belum diluncurkan di gke dan sudah paskah.

Dapatkah seseorang mengonfirmasi bahwa ini sudah diperbaiki dalam versi 1.9.3+? Kami mengalami masalah serius karena perilaku ini, dan memulai ulang buruh pelabuhan setiap kali ini terjadi sangat st00pid.

Memperbaiki 1.9.6 untuk saya

Pada Rabu, 4 Apr 2018, 11:43 sokoow, [email protected] menulis:

Dapatkah seseorang mengonfirmasi bahwa ini sudah diperbaiki dalam versi 1.9.3+? Kita punya
beberapa masalah serius karena perilaku ini, dan restart buruh pelabuhan masing-masing
kali ini terjadi sangat bodoh.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

Oke, terima kasih @Stono . Satu hal lagi yang harus dikonfirmasi di sini. Inilah template kubespray kami untuk kubelet dalam container:

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

Apakah itu terlihat oke? Apakah ada orang lain yang menggunakan yang serupa?

Saya berbicara terlalu cepat.

  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

Harus menghancurkannya dengan cara yang brutal.

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

@Stono versi buruh pelabuhan mana yang Anda gunakan? bagi kami dengan buruh pelabuhan 17.12CE, melakukan penghapusan pod dengan --force --grace-period 0 cukup drastis - hampir selalu berakhir dengan node tidak tersedia karena buruh pelabuhan hang

Saya masih mengalami masalah ini di 1.9.6 pada cluster terkelola Azure AKS.

Menggunakan solusi ini saat ini untuk memilih semua pod yang macet dan menghapusnya (karena saya akhirnya memiliki petak Terminating pod di cluster dev / scratch saya):

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

mengalami hal ini pada kluster Azure dan AWS Mei - solusi disediakan oleh Mike Elliot

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl dapatkan pods --all-namespaces
NAMESPACE NAMA STATUS SIAP DIMULAI USIA
kube-system heapster-76b8cd7b5-4r88h 1/1 Berjalan 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Berjalan 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Berjalan 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Berjalan 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Berjalan 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Berjalan 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Mengakhiri 0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 Mengakhiri 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl hapus pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap --grace-period = 0 --force
peringatan: Penghapusan segera tidak menunggu konfirmasi bahwa sumber daya yang berjalan telah dihentikan. Sumber daya dapat terus berjalan di cluster tanpa batas waktu.
pod "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" dihapus
ubuntu @ ip-10-0-0-22 : ~ $ kubectl dapatkan pods --all-namespaces
NAMESPACE NAMA SIAP STATUS RESTARTS USIA
kube-system heapster-76b8cd7b5-4r88h 1/1 Berjalan 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Berjalan 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Berjalan 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Berjalan 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Berjalan 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Berjalan 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 Mengakhiri 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl delete pod dev-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force
peringatan: Penghapusan segera tidak menunggu konfirmasi bahwa sumber daya yang berjalan telah dihentikan. Sumber daya dapat terus berjalan di cluster tanpa batas waktu.
pod "dev-sms-857f6dbd87-pds58" dihapus
ubuntu @ ip-10-0-0-22 : ~ $ kubectl dapatkan pods --all-namespaces
NAMESPACE NAMA SIAP STATUS RESTARTS USIA
kube-system heapster-76b8cd7b5-4r88h 1/1 Berjalan 0 25d
kube-system kube-dns-5d7b4487c9-s4rsg 3/3 Berjalan 0 25d
kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 Berjalan 0 25d
kube-system monitoring-grafana-997796fcf-wtz7n 1/1 Berjalan 0 25d
kube-system monitoring-influxdb-56fdcd96b-2phd2 1/1 Berjalan 0 25d
kube-system tiller-deploy-cc96d4f6b-jzqmz 1/1 Berjalan 0 25d

Saya tidak yakin apakah ini adalah masalah yang sama, tetapi kami mulai memperhatikan perilaku ini _sejak_ meningkatkan dari 1.9.3 ke 10.10.1. Itu tidak pernah terjadi sebelumnya. Kami menggunakan volume glusterfs, dengan SubPath. Kubelet terus menerus mencatat hal-hal seperti

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"

dan lsof memang menunjukkan bahwa direktori di bawah volume glusterfs masih digunakan:

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

Ini semua baik-baik saja di 1.9.3, jadi sepertinya perbaikan untuk masalah ini telah merusak kasus penggunaan kami :(

@ ross-w signature ini terlihat berbeda dari yang lain. Bisakah Anda membuka terbitan baru dan juga menyertakan spesifikasi pod Anda?

Adakah pembaruan tentang masalah ini?
Dalam kasus kami (Kubernetes 1.9.7, buruh pelabuhan 17.03), pod dalam status Terminating, setelah node kehabisan memori dan pod dijadwalkan ulang. Akhirnya ada banyak pod hantu di dasbor kubernetes dan di tab penerapan, kita bisa melihat penerapan dengan 4/1 pod.
Memulai ulang kubelet atau mematikan semua pod di namespace membantu, tetapi itu solusi yang sangat buruk.

@Adiqq Karena itu adalah masalah dengan Docker itu sendiri.

Lihat journalctl -u kubelet -f di salah satu node Anda. Saya mendapat pesan seperti 'Tidak dapat mematikan kontainergRpc error "(Saya belum mendapatkan pesan yang sebenarnya karena saya telah memperbaikinya).

Untuk memperbaikinya saya telah me-restart buruh pelabuhan di setiap catatan. Selama booting Docker membersihkan kontainer dalam keadaan rusak dan menghapus semua pod basi ini.

Saya mengalami ini kemarin di 1.9.7, dengan pod macet dalam status terminasi dan di log hanya ada "kebutuhan untuk mematikan pod", saya harus --force --grace-period=0 untuk menyingkirkan.

Baru saja mendapatkan ini juga dengan 1.9.7-gke.0.
Tidak memiliki masalah dengan 1.9.6-gke.1.
Tapi memang memilikinya dengan 1.9.4 dan 1.9.5

Pod yang macet memiliki PV yang terpasang.

Menerapkan ulang atau menghapus pod memiliki efek yang sama.
Memulai ulang kubelet pada node yang menyinggung tidak berhasil. kubelet tidak memulai lagi dan saya harus memulai ulang seluruh node.

Selama ini pod tidak bisa dijadwalkan di node lain karena dikatakan PV sudah dipasang di tempat lain.

@Stono @ nodefactory-bk bisakah kalian melihat log kubelet Anda pada node yang melanggar untuk melihat apakah ada log mendetail yang dapat menunjukkan masalah tersebut?

cc @

Baru saja satu aplikasi macet saat dihentikan.
Ini ada di 1.9.7-gke.1
Berikut adalah kubectl mendeskripsikan pod dengan rahasia yang dihapus:

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

Tidak yakin di mana menemukan kubelet.log di gke pada gambar Google. Menemukan sesuatu yang saya lampirkan.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
membunuhnya dan menghapusnya.
Ini dimulai dengan baik setelahnya tetapi membutuhkan waktu sedikit lebih lama dari biasanya.

Pikiran Anda, ini tidak terjadi SETIAP waktu untuk aplikasi itu.
Saya akan mengatakan kira-kira 1/4 kali mungkin.

Lakukan ini dengan k8s 1.9.6, ketika kubelet tidak dapat meng-umount Cephfs mount, semua pod di node tetap Dihentikan selamanya. Harus me-restart node untuk memulihkan, kubelet atau docker restart tidak membantu.

@tuminoid masalah ceph terdengar berbeda. Bisakah Anda membuka terbitan baru dan juga menyediakan event Pod dan log kubelet untuk pod tersebut?

FYI, memperbarui cluster saya (ke k8s v1.10.2) tampaknya telah menghilangkan masalah ini bagi kami.

Terlampir mereproduksi ini untuk saya di 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

jalankan, lalu hapus. Anda akan mendapatkan 'nfs-client' macet saat menghapus. Alasannya adalah hard mount pada node, dan 'server' dihapus terlebih dahulu.

@donbowman untuk masalah unmount nfs saat Anda menghapus server nfs terlebih dahulu, Anda dapat menyetel opsi mount "lunak" di StorageClass atau PV.

Saya tidak mengerti bagaimana caranya? Saya dapat mengaturnya di PersistentVolumeClaim, tetapi itu tidak berlaku di sini.
Saya tidak berpikir StorageClass berlaku di sini (itu akan menjadi disk di bawah, di bawah server nfs).

Masalahnya ada di nfs-client.
apakah saya melewatkan sesuatu?

Untuk PV nfs Anda, Anda dapat menyetel bidang mountOptions mulai dari 1.8 untuk menentukan soft mount. Jika Anda menyediakan volume nfs secara dinamis, Anda juga dapat menyetelnya di StorageClass.mountOptions

ya, tapi bukan PV yang di-mount dengan NFS.
Ini dari container NFS-server saya.
Tidak ada penyediaan dinamis.

Ini menggunakan Google GCP + GKE. PVC memilih PV yang merupakan blok IO, dipasang sebagai ext4 ke dalam wadah yang mengekspor ulang dengan NFS.

Set kontainer ke-2, yang dipasang dari nfs-server (yang juga merupakan sebuah pod), mereka tidak melihatnya sebagai PV. Mereka melihatnya sebagai volume seperti di bawah ini.

Saya tidak melihat cara untuk membuat nfs-client ini melihat 'pvc' untuk mount, jadi saya tidak dapat mengatur opsi mount. Saya juga tidak bisa melihatnya sebagai StorageClass.

Apakah saya melewatkan sesuatu?

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

@donbowman untuk set container ke-2 Anda, yang menggunakan mount nfs, Anda dapat secara manual membuat PV untuk volume nfs tersebut dengan set mountOptions, dan membagikan PVC untuk PV nfs tersebut di semua pod Anda. Tidak ada penyediaan dinamis yang terlibat.

Sesuatu seperti ini:

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

Terima kasih! Jadi itu berhasil (dalam arti sekarang soft-mount) tetapi tidak memperbaiki masalah:

Mount (seperti yang diamati pada Node) sekarang lunak:

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)

Tetapi ketika saya menghapus semuanya, saya masih mendapatkan nfs-client macet selamanya dalam status Penghentian.

k8s-nfs-test.yaml.txt

terlampir adalah yaml yang saya gunakan. Saya melakukan 'create', menunggu sampai muncul, mengamati bahwa klien memiliki mount, dapat membaca / menulis file di dalamnya, kemudian melakukan 'delete' di atasnya.

Pod nfs-server dihapus, tetapi nfs-client tidak.

Melihat podnya, tunggangannya tetap ada:

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

@donbowman ah maaf, saya salah tentang opsi lunak. Opsi lunak hanya mencegah panggilan sistem file agar tidak macet ketika server tidak dapat diakses, tetapi sebenarnya tidak membantu melepas volume nfs. Pelepasan kekuatan perlu dilakukan untuk itu, yang saat ini tidak dapat kami lewati. Untuk saat ini, Anda harus membersihkan mount tersebut secara manual dan memastikan bahwa Anda menghapus pod Anda dalam urutan yang benar (klien nfs terlebih dahulu, kemudian server nfs).

saya mencoba menambahkan timeo = 30 dan intr, tetapi masalah yang sama.
ini akan menguncinya, harus masuk ke node dan melakukan umount -f -l pada mount yang mendasarinya dan kemudian dapat melakukan kubectl delete --force --grace-period 0 pada pod.

sepertinya karena ini telah di-mount atas nama pod sehingga ia dapat di-umount (atau memaksa umount setelah beberapa waktu habis) saat dihapus secara otomatis.

Saya memiliki banyak Pod seperti itu, jadi saya harus menemukan perintah yang akan membersihkan semua pod yang diakhiri:

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

Saya pikir dengan toko file baru

@donbowman iirc, masalah Anda adalah karena Anda menghentikan pod server nfs sebelum pod klien nfs. Jika Anda menggunakan filestore, Anda tidak lagi membutuhkan pod untuk menghosting server nfs Anda, jadi Anda tidak akan mengalami masalah ini selama Anda tidak menghapus seluruh isntance firestore.

tidakkah saya akan memiliki masalah yang sama jika saya mengatur filestore itu? misalnya jika saya mengungkitnya untuk penerapan kubernetes tertentu, dan kemudian turun di akhir, pesanan tidak dijamin.

Tetapi juga menurut saya masalahnya bukan hanya urutannya, penghapusan pod klien nfs tidak umount sama sekali, itu hanya meninggalkan mount yang menggantung pada node. Jadi terlepas dari apakah filestore / server ada atau tidak, ada mount yang menggantung.

Ketika sebuah pod dihentikan, kami melepas volumenya (dengan asumsi bahwa server masih ada). Jika Anda melihat tunggangan yang menjuntai bahkan ketika server ada, maka itu adalah bug.

Jika Anda menggunakan penyediaan dinamis dengan PVC dan PV, maka kami tidak mengizinkan PVC (dan penyimpanan yang mendasarinya) dihapus hingga semua Pod yang mereferensikannya selesai menggunakannya. Jika Anda ingin mengatur sendiri penyediaannya, Anda perlu memastikan bahwa Anda tidak menghapus server sampai semua pod selesai menggunakannya.

Mungkin ini adalah solusi yang mungkin: # 65936

Penghapusan paksa berhasil untuk kubectl delete po $pod --grace-period=0 --force . Bendera --now tidak berfungsi. Saya tidak yakin tentang # 65936 tetapi saya tidak ingin mematikan node ketika Unknown status terjadi.

Memiliki masalah yang sama (pod tetap berhenti karena file di dalam pod tidak dapat dilepas karena perangkat sedang 'sibuk') pada 1.10.5. Bagi saya menggunakan --grace-period=0 --force akan mengakibatkan mountpoint tetap ada. Akhirnya saya berakhir dengan lebih dari 90000 mountpoint, yang sangat memperlambat cluster. Solusinya di sini adalah dengan melakukan pencarian di folder pod dan melepas file tersebut secara rekursif, lalu menghapus folder pod secara rekursif.
Dalam kasus saya, saya memasang configmap menggunakan subpath ke folder yang ada dengan file yang sudah ada, menimpa salah satu file yang ada. Ini dulu berfungsi dengan baik untuk saya di 1.8.6.
Poster asli menyebutkan pod tetap 'berhenti' selama beberapa jam, dalam kasus saya ini berhari-hari. Saya belum melihat mereka akhirnya dibersihkan, kecuali ketika saya melakukan solusi manual.

Memiliki masalah yang sama, yang disebabkan oleh agregator log (mirip dengan fluentd), ia memasang folder /var/lib/docker/containers dan pod memiliki banyak pemasangan:

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

Dalam kasus saya, beberapa pod dapat dihapus dengan baik oleh kubernetes, tetapi beberapa terjebak dalam status "terminating".

Ini bisa terkait dengan https://github.com/kubernetes/kubernetes/issues/45688 (saya juga menggunakan buruh pelabuhan 17)

Saya baru saja mendapat masalah bahwa pod tidak dihentikan karena ada rahasia yang hilang. Setelah saya membuat rahasia itu di namespace itu semuanya kembali normal.

Saya menghapus pod saya yang macet seperti ini:

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

Punya masalah serupa saat menjalankan Azure ACS.

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

Saya telah mencoba menggunakan --now atau menyetel masa tenggang. Misalnya

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

Pod masih hang dan itu menyebabkan penerapan yang sesuai juga terhenti.

Saya juga dihantui oleh pesan “Need to kill Pod” ini di event pod. Apa artinya ini dengan cara? Bahwa _Kubernetes_ merasa perlu untuk mematikan pod, atau bahwa _I_ harus menghentikan pod?

ini terjadi pada saya beberapa hari yang lalu dan saya berhenti menghapus dan membiarkan pod seperti itu. Kemudian hari ini, itu menghilang dan tampaknya pada akhirnya akan dihapus.

Terjadi pada saya sekarang. Solusi --force --now tidak berhasil untuk saya. Saya menemukan baris berikut di log kubelet mencurigakan

Agustus 6 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni gagal pada status hook untuk pod "backend-foos-227474871-gzhw0_default": Tidak terduga output perintah nsenter: tidak dapat membuka: Tidak ada file atau direktori seperti itu

Yang membuat saya menemukan masalah berikut:
https://github.com/openshift/origin/issues/15802

Saya tidak di openshift tetapi di Openstack, jadi saya pikir itu bisa terkait. Saya memberikan saran untuk memulai kembali tembakan buruh pelabuhan.
Memulai ulang buruh pelabuhan membuat pod yang macet di "Terminating" menghilang.

Saya tahu ini hanya solusi, tetapi saya kadang-kadang tidak bangun pada jam 3 pagi untuk memperbaikinya lagi.
Tidak mengatakan Anda harus menggunakan ini, tetapi mungkin membantu beberapa orang.

Tidur adalah apa yang saya setel terminationGracePeriodSeconds pod saya (30 detik). Jika hidup lebih lama dari itu, cronjob ini akan --force --grace-period = 0 dan membunuhnya sepenuhnya

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

Saya melihat kesalahan yang sama dengan Kubernetes v1.10.2. Pod macet saat diakhiri tanpa batas waktu dan kubelet pada node tersebut berulang kali mencatat:

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"

Saya dapat secara manual melepas volume subpath yang dimaksud tanpa keluhan (Linux tidak memberi tahu saya bahwa itu sedang sibuk). Ini menghentikan kubelet untuk mencatat pesan kesalahan. Namun, hal ini tidak menginspirasi Kubernetes untuk melanjutkan pembersihan, karena pod masih ditampilkan dalam status penghentian. Memulai ulang Docker secara rutin untuk membersihkan ini sebenarnya bukan solusi yang dapat diterima karena gangguan yang ditimbulkannya untuk menjalankan kontainer.

Juga catatan: kontainer itu sendiri telah hilang dari docker ps -a tanpa bukti bahwa itu pernah ada, jadi saya tidak yakin ini sebenarnya adalah masalah Docker. Kami menggunakan Docker versi 17.03.2-ce.

Pembaruan: kami telah mengkonfigurasi node kami untuk mengarahkan direktori root kubelet ke volume non-OS dengan symlink ( /var/lib/kubelet adalah symlink yang menunjuk ke direktori lain pada volume yang berbeda). Ketika saya mengkonfigurasi ulang untuk mengirimkan --root-dir ke kubelet sehingga ia pergi ke direktori yang diinginkan secara langsung, daripada melalui symlink, dan memulai ulang kubelet, itu membersihkan volume mount dan membersihkan pod yang macet menghentikan tanpa memerlukan restart Docker.

Saya mengalami masalah ini hari ini untuk pertama kalinya saat menjalankan beberapa pod secara lokal di minikube.

Saya memiliki banyak pod yang terjebak di Terminating karena configmap / secret dipasang sebagai volume yang hilang. Tidak ada saran / solusi / solusi yang diposting di atas berfungsi kecuali yang ini .

Satu hal yang menurut saya perlu diperhatikan adalah sebagai berikut:

• Ketika saya menjalankan kubectl get pods , saya mendapatkan daftar pod dengan status Terminating .
• Ketika saya menjalankan docker ps | grep -i {{pod_name}} meskipun, tidak ada pod dalam status Terminating seperti yang terlihat oleh kubectl get pods yang berjalan di VM minikube.

Saya mengharapkan docker ps untuk mengembalikan daftar pod yang tertahan di status Terminating tetapi kenyataannya tidak ada satupun yang berjalan, namun kubectl get pods mengembalikan data tentang mereka? Adakah yang bisa menjelaskan mengapa demikian?

Saya mengalami masalah ini dengan 4 penerapan. Kemudian saya beralih dari "volume lokal" ke "jalur host" untuk semua tunggangan, dan itu hilang untuk saya.

Saya baru saja mendapat masalah bahwa pod tidak dihentikan karena ada rahasia yang hilang. Setelah saya membuat rahasia itu di namespace itu semuanya kembali normal.

Bagaimana Anda membuat rahasia di namespace jika namespace dalam status "Mengakhiri"?

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

bekerja untuk saya.

Jangan lupa tentang "--grace-period = 0". Itu penting

kubectl memperingatkan saya "peringatan: Penghapusan langsung tidak menunggu konfirmasi bahwa sumber daya yang berjalan telah dihentikan. Sumber daya dapat terus berjalan di cluster tanpa batas." ketika saya menggunakan --force --grace-period=0 .
Adakah yang bisa memberi tahu saya jika itu benar-benar akan terjadi?

faktanya, saat kami menghapus beberapa pod, mungkin penundaan untuk menghapusnya karena beberapa alasan,
dan jika kita menjalankan "kubectl delete" dengan flag "--force --grace-period = 0",
objek sumber daya akan dihapus sekaligus.

Bisakah kamu membantu mengonfirmasi jika pod akan segera dihapus?
Apakah itu berarti pesan peringatan sebenarnya tidak akurat?

@windoze , jika Anda --force --grace-period = 0 option, artinya objek pod API akan segera dihapus dari server API. Node kubelet bertanggung jawab untuk membersihkan volume mount dan mematikan container. Jika kubelet tidak berjalan atau mengalami masalah saat membersihkan pod, container mungkin masih berjalan. Tapi Kubelet harus terus berusaha membersihkan pod jika memungkinkan.

Jadi itu masih berarti penghapusan bisa berlangsung selamanya karena kubelet bisa tidak berfungsi?
Apakah ada cara untuk memastikan pod tersebut dihapus?
Saya mengajukan pertanyaan karena saya memiliki beberapa pod besar yang berjalan di cluster dan tidak ada cukup memori di setiap node untuk menjalankan 2 instance darinya.
Jika penghapusan gagal node menjadi tidak dapat digunakan, dan jika masalah ini terjadi beberapa kali, layanan akan mati total karena pada akhirnya tidak akan ada node yang dapat menjalankan pod ini.

Dalam lingkungan buruh pelabuhan biasa-n-lama saya dapat memaksa mematikan sebuah pod dengan kill -9 atau sesuatu seperti itu, tetapi tampaknya k8s tidak memiliki fungsi seperti itu.

@windoze tahukah Anda mengapa penghapusan pod Anda sering gagal? Itu karena kubelet tidak berjalan, atau kubelet mencoba untuk mematikan kontainer tapi gagal dengan beberapa kesalahan?

Situasi seperti itu terjadi beberapa kali di cluster saya beberapa bulan yang lalu, kubelet sedang berjalan tetapi daemon buruh pelabuhan tampaknya mengalami masalah dan macet tanpa log kesalahan.
Solusi saya adalah masuk ke node dan memaksa mematikan proses kontainer dan memulai ulang daemon buruh pelabuhan.
Setelah beberapa peningkatan, masalahnya hilang dan saya tidak pernah memilikinya lagi.

kubectl delete pods <podname> --force --grace-period=0 berhasil untuk saya!

@ shinebayar-g, masalah dengan --force adalah bahwa container anda akan terus berjalan. Itu hanya memberi tahu Kubernetes untuk melupakan container pod ini. Solusi yang lebih baik adalah menggunakan SSH ke VM yang menjalankan pod dan menyelidiki apa yang terjadi dengan Docker. Coba matikan kontainer secara manual dengan docker kill dan jika berhasil, coba hapus pod secara normal lagi.

@agolomoodysaada Ah, masuk akal. Terima kasih untuk penjelasannya. Jadi saya tidak benar-benar tahu bahwa penampung sebenarnya benar-benar dihapus atau tidak?

jadi, ini akhir tahun 2018, kube 1.12 keluar dan ... kalian semua masih memiliki masalah dengan pod macet?

Saya memiliki masalah yang sama, baik --force --grace-period = 0 atau --force --now tidak berfungsi, berikut ini lognya:

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat dapatkan pod node-eksportir-zbfpx
NAMA SIAP STATUS RESTARTS USIA
node-eksportir-zbfpx 0/1 Menghentikan 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat hapus pod node-eksportir-zbfpx --grace-period = 0 --force
peringatan: Penghapusan segera tidak menunggu konfirmasi bahwa sumber daya yang berjalan telah dihentikan. Sumber daya dapat terus berjalan di cluster tanpa batas waktu.
pod "node-eksportir-zbfpx" dihapus

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat dapatkan pod node-eksportir-zbfpx
NAMA SIAP STATUS RESTARTS USIA
node-eksportir-zbfpx 0/1 Mengakhiri 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat hapus pod node-eksportir-zbfpx --sekarang --force
pod "node-eksportir-zbfpx" dihapus

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat dapatkan pod node-eksportir-zbfpx
NAMA SIAP STATUS RESTARTS USIA
node-eksportir-zbfpx 0/1 Menghentikan 0 4d

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

Saya mencoba mengedit pod dan menghapus bagian finalisator di metadata, tetapi juga gagal.

Saya masih melihat ini dengan cara yang 100% dapat direproduksi (definisi sumber daya yang sama) dengan kubectl 1.13 alpha dan Docker untuk Desktop di macOS. Maksud saya, yang dapat direproduksi adalah satu-satunya cara untuk memperbaikinya adalah dengan mengatur ulang Docker untuk Mac dari pabrik, dan ketika saya mengatur cluster saya lagi menggunakan sumber daya yang sama (skrip penerapan), skrip pembersihan yang sama gagal.

Saya tidak yakin mengapa ini relevan tetapi skrip pembersihan saya terlihat seperti:

#!/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

Karena cluster dijalankan secara lokal, saya dapat memverifikasi bahwa tidak ada container yang berjalan di Docker, hanya kubectl yang terputus pada terminating pod. Ketika saya describe pods status terdaftar sebagai Status: Terminating (lasts <invalid>)

Baru saja terjadi padaku sekali lagi. Saya mencoba menginstal percona pmm-server dengan NFS share dan perangkat lunak bahkan tidak muncul, jadi saya menghapus dan ini terjadi. (Klaim persisten tidak berfungsi untuk perangkat lunak ini). Kurasa aku menelepon tua yang baik kubectl delete pods <podname> --force --grace-period=0 sekali lagi. Tapi pertanyaannya adalah bagaimana saya tahu di mana pod ini hidup?

@ shinebayar-g, SSH ke VM tempatnya berada dan jalankan docker ps .

Memang tidak ada di sana .. Saya memiliki beberapa VM, jadi saya bertanya bagaimana cara mengetahui mana yang benar. :)

@ shinebayar-g ini mungkin berhasil:
kubectl describe pod/some-pod-name | grep '^Node:'

masalah yang sama.

docker ps menemukan bahwa kontainer dalam status "Mati" tidak Keluar (0) seperti yang diharapkan

Menghapus kontainer secara manual, mengarah ke entri log buruh pelabuhan berikut:

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

Sayangnya jalurnya terputus, tapi saya rasa saya ingat, masalahnya adalah prosesnya tidak ada lagi.

Saya masih terjebak dengan masalah ini dengan k8s v1.11.0. Berikut adalah daftar periksa dari apa yang saya lakukan untuk membersihkan pod saya:

• Pastikan bahwa semua sumber daya yang dilampirkan ke pod telah diklaim ulang. Tidak semuanya terlihat di kubectl get ; beberapa di antaranya hanya diketahui oleh Kubelet tempat pod dijalankan, jadi Anda harus mengikuti aliran lognya secara lokal
  
  
  
  • Khususnya, umount direktori yang Kubelet keluhkan dengan device or resource busy pesan
  
  
• Ketika semuanya gagal, kubectl edit pod yang gagal dan hapus finalizers: → - foregroundDeletion

Dua tip lagi:

• Dalam kondisi mapan, Kubelet yang tidak bingung seharusnya tidak mencatat pesan periodik apa pun. Segala jenis kegagalan berulang untuk melepaskan sesuatu, merupakan gejala dari pod yang macet.
• Anda dapat menyimpan perintah kubectl delete di jendela lain untuk memantau kemajuan Anda (bahkan pada pod yang sudah Anda "hapus" berkali-kali). kubectl delete akan dihentikan segera setelah sumber daya macet terakhir dilepaskan.

Menghadapi hari ini.
Apa yang telah dilakukan:

1. ssh untuk membuat node dan menghapus container secara manual
2. Setelah itu kubectl get pods tunjukkan apa wadah saya yang tersangkut 0/1 terminating (dulu 1/1 terminating )
3. Hapus finalizers bagian dari pod, saya adalah foregroundDeletion ($ kubectl edit pod / name) -> container dihapus dari daftar pod
4. Hapus penerapan -> semua hal terkait penerapan dihapus.

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

kami menghadapi masalah yang sama ketika kami mulai memasang rahasia (dibagikan dengan banyak pod). Pod masuk dalam status terminating dan tetap di sana selamanya. Versi kami adalah v1.10.0. Kontainer buruh pelabuhan terlampir hilang tetapi referensi di server API tetap ada kecuali saya secara paksa menghapus pod dengan opsi --grace-period=0 --force .

Mencari solusi permanen.

Nah, Baru-baru ini saya menguji runc exploit CVE-2019-5736 di staging cluster saya, Seperti yang Anda ketahui, exploit menulis ulang biner runc pada mesin host. Eksploitasi yang merusak. Setelah itu saya melihat perilaku aneh di cluster. Semua pod macet di status penghentian. Solusinya adalah menguras pekerja galangan pembersih node yang terpengaruh dan menginstal ulang. Setelah itu semua pod dan cluster k8s berfungsi normal seperti semula. Mungkin ini masalah buruh pelabuhan dan memasangnya kembali akan menyelesaikan masalah Anda juga !. Terima kasih

Instal v1.13.3 baru di sini. Ini juga terjadi pada saya. Terjadi sejak saya memasang volume NFS yang sama di beberapa pod yang tampaknya ada hubungannya dengan itu.

Saya melihat masalah ini saat membuat penerapan yang mencoba membuat volume menggunakan rahasia yang tidak ada, menghapus penerapan / layanan itu menyisakan sekitar Terminating pod.

menghadapi masalah yang sama dengan v.1.12.3, dan --grace-period = 0 --force atau - sekarang keduanya tidak valid, hapus statefulset yang juga tidak valid

Masalah yang sama dengan pemasangan SMB (menurut saya?) (Berbagi File Azure sesuai https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

masalah yang sama dengan 13.3

Saya memiliki masalah yang sama dengan pod dalam status "Terminating" selama hampir 2 hari.
Saya menggunakan Minikube di mesin Linux (Debian).

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

@ardalanrazavi kenapa diakhiri selama dua hari? Hapus paksa saja jika tidak dihapus setelah 5 menit

@tokopedia

mengapa dihentikan selama dua hari?

Itu pertanyaan yang bagus. Kami semua ingin tahu itu.

Hapus paksa saja jika tidak dihapus setelah 5 menit

Menghapusnya secara paksa membuat cluster dalam keadaan tidak konsisten. (Dengan minikube, itu bukan cluster Anda yang sebenarnya, itu memang bukan masalah)

@Distroartonline

Sejujurnya, saya tidak melihat ada solusi lain di sini.

Tentu, cluster akan dibiarkan dalam "status tidak konsisten". Saya ingin memahami apa yang Anda maksud dengan ini. Penutupan paksa itu buruk. Saya juga tidak menyukainya, tetapi dalam kasus saya, saya merasa nyaman untuk menghancurkan dan menggunakan kembali sumber daya apa pun yang diperlukan.

Dalam kasus saya, tampaknya hanya macet untuk mengakhiri pada pod yang memiliki mount NFS. Dan hanya terjadi ketika server NFS turun sebelum klien mencoba turun.

Saya memperbaiki masalah ini, saya dapat mengisolasi bahwa semua pod yang macet, semuanya berada di satu node, node dimulai ulang dan masalah telah hilang.

@nmors @AndrewSav Saya telah melakukan penghapusan paksa juga.

Menghapus server nfs Anda sebelum Anda menghapus pod Anda diketahui menyebabkan unmount hang selamanya. Yang terbaik adalah memesan penghapusan Anda dalam hal ini sehingga server nfs Anda selalu dihapus terakhir.

@ msau42 Server NFS saya bukan bagian dari cluster k8s - ini adalah alat dan mesin yang terpisah bersama-sama

Tidak masalah apakah itu bagian dari cluster k8s atau bukan. Jika server nfs tidak dapat diakses, maka unmount akan hang hingga dapat diakses kembali.

@ msau42 itu aneh, karena saya cukup yakin bahwa meskipun kembali online, pod masih macet dan berhenti. pod baru dimulai dan dipasang dengan baik.

Saya menggunakan NFS server pada kubernetes diikuti oleh ini contoh dan ini terjadi cukup sering sayangnya ..

@ shinebayar-g Saya juga mengikuti panduan itu, tapi sekarang saya telah menyingkirkan PV dan PVC dan menentukan volume saya langsung dalam penerapan, seperti ini:

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

Saya tidak mengalami masalah apa pun sejak itu, saya mengubahnya hanya sekitar seminggu dengan harapan konfigurasi yang lebih sederhana akan lebih dapat diandalkan .. mari kita lihat ... Mungkin ini akan memperbaiki masalah?

Sebagai solusinya saya menulis skrip yang mengambil beberapa baris terakhir dari /var/log/syslog dan mencari kesalahan seperti "Operasi untuk ... hapus / var / lib / kubelet / pods ... direktori tidak kosong" atau "nfs. ..perangkat sedang sibuk ... unmount.nfs "atau" pegangan file NFS basi ".
Kemudian ia mengekstrak direktori lengkap pod_id atau pod dan melihat mount apa yang dimilikinya (seperti mount | grep $pod_id ), kemudian unmount semua dan menghapus direktori terkait. Akhirnya kubelet melakukan sisanya dan mematikan serta menghapus pod dengan anggun. Tidak ada lagi pod dalam status Terminating.

Saya meletakkan skrip itu di cron untuk dijalankan setiap menit. Akibatnya - tidak ada masalah untuk saat ini, bahkan 3-4 bulan kemudian.
Catatan : Saya tahu, pendekatan ini tidak dapat diandalkan dan memerlukan pemeriksaan pada setiap peningkatan cluster tetapi berhasil!

Saya menggunakan versi 1.10 dan saya mengalami masalah ini hari ini dan saya pikir masalah saya terkait dengan masalah pemasangan volume rahasia yang mungkin telah membuat beberapa tugas tertunda dan meninggalkan pod dalam status penghentian selamanya.

Saya harus menggunakan opsi --grace-period = 0 --force untuk menghentikan pod.

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]

Saya telah menemukan bahwa jika Anda menggunakan --force --grace-period=0 semua yang dilakukannya adalah menghapus referensi ... jika Anda ssh ke dalam node, Anda masih akan melihat kontainer buruh pelabuhan berjalan.

Dalam kasus saya, ada kehabisan memori pada node.
Dan kernel membunuh cilium-agent, yang tampaknya mengganggu penghentian polong.
Saya baru saja memulai ulang node dan itu dihapus.

Dalam pengalaman saya, sudo systemctl restart docker pada node membantu (tetapi jelas ada downtime).

Dan ini masih terjadi secara berkala pada node acak yang A) mendekati batas memori atau B) CPU kelaparan (baik bc dari beberapa masalah kswapd0 yang mungkin masih terkait dengan mem, atau pemuatan aktual)

Masalah menjadi basi setelah 90d tidak ada aktivitas.
Tandai terbitan sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup basi

Masalah basi membusuk setelah 30 hari tidak aktif.
Tandai terbitan sebagai baru dengan /remove-lifecycle rotten .
Masalah busuk ditutup setelah 30 hari tambahan tidak aktif.

Jika masalah ini aman untuk ditutup sekarang, lakukan dengan /close .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/ siklus hidup busuk

Masalah busuk ditutup setelah 30 hari tidak aktif.
Buka kembali masalah dengan /reopen .
Tandai terbitan sebagai baru dengan /remove-lifecycle rotten .

Kirimkan masukan ke sig-testing, kubernetes / test-infra dan / atau fejta .
/Menutup

@ fejta-bot: Menutup masalah ini.

Ini masih merupakan masalah yang sangat aktif, k8s 1.15.4 dan RHEL Docker 1.13.1. Pod selalu berada di Terminating tetapi containernya sudah hilang, dan k8s tidak dapat menemukan dirinya sendiri, tetapi membutuhkan interaksi manusia. Membuat uji skrip PITA menjadi nyata.

/ buka kembali
/ hapus-siklus hidup busuk

@tuminoid : Anda tidak dapat membuka kembali masalah / PR kecuali Anda yang membuatnya atau Anda adalah kolaborator.

/ buka kembali
/ hapus-siklus hidup busuk

@mikesplain :

Sama di sini: pod terjebak dalam fase penghentian selama lebih dari 19 menit. Penampung berhasil dihentikan, tetapi Kubernetes masih yakin perlu menunggu sesuatu ..

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>

Tidak ada acara, bukan log ...

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

Dapatkah Anda memeriksa log kubelet Anda dan melihat apakah ada pesan tentang volume unmount yang gagal, atau orphaned pods?

Saya telah melihat ini juga
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] Orphaned pod "0406c4bf-17e3-4613-a526-34e8a6cee208" ditemukan, tetapi jalur volume masih ada di disk: Ada total 8 error yang serupa dengan ini. Tingkatkan verbositas untuk melihatnya.

Saya telah melihatnya juga. Tidak dapat memeriksa log karena kubectl mengeluh tidak dapat terhubung ke kontainer buruh pelabuhan dan tidak dapat membuat pod baru karena keberadaan pod yang dihentikan saat ini. Agak mengganggu.

Mengalaminya juga dan agak menjengkelkan harus mengonfirmasi apakah Kubernetes membersihkan pod lama dengan benar atau tidak.
Semoga ini segera diperbaiki.

Dan bagaimana dengan masalah ini? Apakah itu teratasi? Saya memiliki yang sama, tetapi ini tidak mulai terjadi segera, tetapi beberapa saat setelah dimulainya node, jika Anda mengatur ulang node, maka untuk beberapa waktu semuanya baik-baik saja

Bisakah Anda memeriksa apakah ada Finalizer di pod yang mencegahnya dihapus?

Tidak ada Finalizer di pod yang dikeluarkan

FYI saya menyelesaikan ini dengan menghapus paksa menggunakan:

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

Dan saya yakin ini berhasil menghentikan pod. Sejak itu saya tidak mengalami masalah lagi. Saya mungkin telah memperbarui sejak itu, jadi bisa jadi masalah versi, tetapi tidak 100% karena sudah lama sekali saya tidak melihat masalah tersebut.

Ini terjadi pada saya saat sebuah pod kehabisan memori. Itu tidak berhenti sampai penggunaan memori turun lagi.

FYI saya menyelesaikan ini dengan menghapus paksa menggunakan:

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

Dan saya yakin ini berhasil menghentikan pod. Sejak itu saya tidak mengalami masalah lagi. Saya mungkin telah memperbarui sejak itu, jadi bisa jadi masalah versi, tetapi tidak 100% karena sudah lama sekali saya tidak melihat masalah tersebut.

Itu berhasil untuk saya

kubectl delete pods <pod> --grace-period=0 --force adalah perbaikan sementara, saya tidak ingin menjalankan perbaikan manual setiap kali terjadi failover untuk salah satu pod yang terpengaruh. Pod penjaga kebun binatang saya tidak berhenti di minikube dan di Azure AKS.

Update 9 Maret 2020
Saya menggunakan pengait siklus hidup preStop untuk secara manual menghentikan pod saya. Pod penjaga kebun binatang saya macet dalam status penghentian dan tidak akan menanggapi sinyal istilah dari dalam wadah. Saya pada dasarnya memiliki manifest yang sama yang berjalan di tempat lain dan semuanya berakhir dengan benar, tidak tahu apa penyebab utamanya.

masalah yang sama, sangat menjengkelkan

masalah yang sama :( pod macet dalam penghentian, sejak 3 hari

FYI saya menyelesaikan ini dengan menghapus paksa menggunakan:

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

Dan saya yakin ini berhasil menghentikan pod. Sejak itu saya tidak mengalami masalah lagi. Saya mungkin telah memperbarui sejak itu, jadi bisa jadi masalah versi, tetapi tidak 100% karena sudah lama sekali saya tidak melihat masalah tersebut.

Selain itu, flag --force tidak selalu berarti pod dihapus, hanya tidak menunggu konfirmasi (dan memberikan referensi, menurut pemahaman saya). Seperti yang dinyatakan oleh peringatan The resource may continue to run on the cluster indefinetely .

Edit: Saya kurang informasi. Lihat komentar elrok123s di bawah untuk motivasi lebih lanjut.

FYI saya menyelesaikan ini dengan menghapus paksa menggunakan:

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

Dan saya yakin ini berhasil menghentikan pod. Sejak itu saya tidak mengalami masalah lagi. Saya mungkin telah memperbarui sejak itu, jadi bisa jadi masalah versi, tetapi tidak 100% karena sudah lama sekali saya tidak melihat masalah tersebut.

Selain itu, flag --force tidak selalu berarti pod dihapus, hanya tidak menunggu konfirmasi (dan memberikan referensi, menurut pemahaman saya). Seperti yang dinyatakan oleh peringatan The resource may continue to run on the cluster indefinetely .

Benar, tetapi intinya adalah bahwa --grace-period=0 memaksa penghapusan terjadi :) tidak yakin mengapa komentar Anda relevan: /

Saya rasa komentarnya relevan karena wadah yang mendasarinya
(buruh pelabuhan atau apapun) mungkin masih berjalan dan tidak sepenuhnya dihapus ..,
ilusi tentang itu "dihapus" kadang-kadang sedikit menyesatkan

Pada Kamis, 4 Juni 2020 jam 9:16, Conner Stephen McCabe <
[email protected]> menulis:

FYI saya menyelesaikan ini dengan menghapus paksa menggunakan:

kubectl hapus pod--grace-period = 0 --force

Dan saya yakin ini berhasil menghentikan pod. Sejak itu saya
tidak mengalami masalah lagi. Saya mungkin telah memperbarui sejak itu,
jadi bisa menjadi masalah versi, tetapi tidak 100% karena sudah lama sekali
Saya telah melihat masalahnya.

Selain itu, flag --force tidak selalu berarti pod tersebut dihapus, melainkan
hanya tidak menunggu konfirmasi (dan memberikan referensi, ke my
pemahaman). Seperti yang dinyatakan oleh peringatan, Sumber daya dapat terus berjalan
di kluster tanpa batas waktu.

Benar, tetapi intinya adalah --grace-period = 0 memaksa penghapusan ke
terjadi :) tidak yakin mengapa komentar Anda relevan: /

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

Itu memang maksud saya; menggunakan metode ini --force berisiko meninggalkan beban yang mendasari membebani node Anda, dan tidak serta merta memperbaiki masalah aslinya. Dalam kasus terburuk itu adalah "Jika saya tidak dapat melihatnya, itu tidak ada" -perbaikan yang akhirnya bisa menjadi lebih sulit untuk dideteksi.

Atau apakah Anda mengatakan bahwa --grace-period=0 dijamin memaksa penghapusan penampung yang mendasari, @ elrok123?
Jika demikian, komentar saya didasarkan pada pengetahuan yang salah dan tidak relevan, tetapi jika risiko meninggalkan container yang sedang berjalan tetap ada saat menggunakan --grace-period=0 begitu juga maksud saya.

@oscarlofwenhamn Sejauh yang saya ketahui, ini secara efektif menjalankan sigkill pada semua proses di pod itu, memastikan penghapusan proses zombie (sumber: Poin 6 di bawah 'Penghentian Pod' - https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = Ketika% 20the% 20grace% 20period% 20 kedaluwarsa, periode% 200% 20 (penghapusan% 20 segera).), dan berhasil menghapus pod (mungkin tidak segera terjadi, tetapi akan terjadi.)

Panduan menyebutkan bahwa ia menghapus referensi, tetapi tidak menghapus pod itu sendiri (sumber: 'Force Deletion' - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ), namun masa tenggang = 0 seharusnya efektif menghentikan pod Anda meskipun, tidak langsung.

Saya hanya membaca dokumen dan cara yang disarankan untuk menangani skenario yang saya temui. Masalah yang secara khusus saya temui bukanlah masalah yang berulang, dan sesuatu yang terjadi sekali; Saya yakin perbaikan NYATA untuk ini memperbaiki penerapan Anda, tetapi sampai Anda sampai di sana, metode ini akan membantu.

@ elrok123 Brilian - Saya memang kurang mendapat informasi. Saya telah memperbarui tanggapan saya di atas, merujuk pada penjelasan ini. Terima kasih atas tanggapan mendetail, dan metode termotivasi lebih lanjut untuk menangani pod yang bermasalah. Bersulang!

saat ini pod macet selama 2+ hari dalam status dihentikan.

Bagi saya namespace terjebak di Terminating . Tidak ada pod yang terdaftar. Tidak ada layanan ... tidak ada. Namespace kosong. Masih ... terjebak di Terminating.

@JoseFMP menggunakan kubectl untuk meminta yaml dari namespace, mungkin ada finalizer yang menahan proses tersebut.

@JordyBottelier Terima kasih.

Tidak ada finalisator. Masih terjebak Terminating

@JoseFMP di sini adalah skrip untuk mematikannya sepenuhnya (secara efektif membunuhnya), cukup simpan dan jalankan ./script_name:
``

! / bin / bash

set -eo pipefail

mati () {echo "$ *" 1> & 2; keluar 1; }

kebutuhan () {
yang mana "$ 1" &> / dev / null || mati "Biner '$ 1' hilang tapi wajib"
}

memeriksa prasyarat

butuh "jq"
butuh "curl"
butuh "kubectl"

PROYEK = "$ 1"
bergeser

tes -n "$ PROJECT" || die "Argumen yang hilang: kill-ns"

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

sleep 1 # beri proxy waktu sebentar

kubectl dapatkan namespace "$ PROJECT" -o json | jq 'del (.spec.finalizers [] | pilih ("kubernetes"))' | curl -s -k -H "Jenis-Konten: application / json" -X PUT -o / dev / null --data-binary @ - http: // localhost : 8001 / api / v1 / namespaces / $ PROJECT / finalize && echo "Killed namespace: $ PROJECT" ``

Sepertinya saya juga mengalami hal ini, dengan beberapa pod yang macet dalam penghentian, termasuk satu pod yang tidak lagi terlihat di mana pun di infrastruktur saya tetapi masih berjalan sebagai hantu (ini melayani permintaan dan saya dapat melihat permintaan dilayani bahkan dengan skala penerapan dari nol).

Saya tidak memiliki visibilitas atau kendali atas pod ini dan bertanya bagaimana saya seharusnya memecahkan masalah seperti ini tanpa mematikan semua node secara paksa?

Sepertinya saya juga mengalami hal ini, dengan beberapa pod yang macet dalam penghentian, termasuk satu pod yang tidak lagi terlihat di mana pun di infrastruktur saya tetapi masih berjalan sebagai hantu (ini melayani permintaan dan saya dapat melihat permintaan dilayani bahkan dengan skala penerapan dari nol).

Saya tidak memiliki visibilitas atau kendali atas pod ini dan bertanya bagaimana saya seharusnya memecahkan masalah seperti ini tanpa mematikan semua node secara paksa?

Anda harus mengakses buruh pelabuhan di node.
Anda dapat menggunakan dink (https://github.com/Agilicus/dink) yang akan menampilkan pod dengan akses shell w / buruh pelabuhan, atau ssh ke pod.
docker ps -a
docker stop ####

semoga berhasil.

Terima kasih atas arahannya.

Saya akhirnya bisa menyelesaikan ini, tetapi masih sedikit bingung bagaimana hal itu bisa terjadi (bagi saya podnya sama sekali tidak terlihat). Karena dalam produksi, hal-hal agak sibuk dan saya tidak dapat melakukan diagnostik, tetapi jika itu terjadi lagi mudah-mudahan saya dapat membuat laporan bug yang lebih baik.

Melihat gejala yang sama, pod terhenti di terminating (menariknya mereka semua memiliki probe tipe exec untuk kesiapan / keaktifan). Melihat log, saya dapat melihat: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] Pemeriksaan kesiapan untuk "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): test -service "gagal (kegagalan): OCI runtime exec gagal: exec gagal: tidak dapat mengeksekusi kontainer yang telah berhenti: tidak diketahui. Pesan ini berulang selamanya dan mengubah probe exec ke tcpSocket tampaknya memungkinkan pod untuk dihentikan (berdasarkan pengujian, akan menindaklanjutinya). Pod tersebut tampaknya memiliki salah satu container "Berjalan" tetapi tidak "Ready", log untuk container "Running" memang tampil seolah-olah layanan dihentikan.

Hal ini terjadi pada containerd 1.4.0 ketika beban node tinggi dan vm.max_map_count diset ke nilai yang lebih tinggi dari default, containerd-shim tidak menguras fifo stdout dan blok menunggu untuk dikosongkan, sementara dockerd gagal untuk acara / pengakuan dari containerd bahwa prosesnya telah hilang.

@discanto terima kasih telah membagikan informasi ini. Apakah masalah sedang diperbaiki atau dilacak?

@ Random-Liu

Bug telah dibuka lebih dari 3 tahun. Pod yang macet saat dihentikan dapat disebabkan oleh berbagai alasan. Saat melaporkan kasus Anda, akan sangat membantu jika memposting beberapa log kubelet untuk melihat apakah pod macet.