@ kubernetes / sig-aws @ kubernetes / sig-Scheduling

عادةً ما يستغرق تنظيف الحجم والشبكة وقتًا أطول في الإنهاء. هل يمكنك العثور في أي مرحلة على جرابك عالق؟ تنظيف الصوت على سبيل المثال؟

عادةً ما يستغرق تنظيف الحجم والشبكة وقتًا أطول في الإنهاء.

صيح. هم دائما مشتبه بهم.

igorleao يمكنك تجربة kubectl delete pod xxx --now أيضًا.

مرحبًا resouer وdixudx
لست متأكدا. بالنظر إلى سجلات kubelet للحصول على حجرة مختلفة بنفس المشكلة ، وجدت:

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

كما ترون ، هذه المجموعة لديها كاليكو لـ CNI.
الأسطر التالية تلفت انتباهي:

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

هل هناك طريقة أفضل لمعرفة المرحلة التي علق فيها الكبسولة؟

يبدو أن kubectl delete pod xxx --now يعمل بشكل جيد ، لكنني أرغب حقًا في معرفة السبب الجذري له وتجنب التفاعل البشري.

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

يبدو أن kubelet/mount فشل في تحميل configmap كوحدة تخزين بسبب إعادة تسمية هذا الملف.

igorleao هل هذا قابل للتكرار؟ أو أنه ليس مستقرًا ، يحدث أحيانًا. لقد واجهت مثل هذه الأخطاء من قبل ، فقط للتأكد.

dixudx يحدث ذلك عدة مرات في اليوم لمجموعة معينة. المجموعات الأخرى التي تم إنشاؤها بنفس الإصدار من kops و kubernetes ، في نفس الأسبوع ، تعمل بشكل جيد.

igorleao حيث يوضح السجل أن مدير وحدة التخزين فشل في إزالة الدليل
هل يمكنك التحقق مما إذا كان الدليل /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key لا يزال محملاً أم لا؟ شكر!

igorleao كيف تدير kubelet؟ في الحاوية؟ إذا كان الأمر كذلك ، هل يمكنك إرسال وحدة النظام أو تكوين عامل الإرساء لـ kubelet؟

نرى سلوكًا مشابهًا. نقوم بتشغيل kubelet كحاوية وتم تخفيف المشكلة جزئيًا عن طريق تركيب /var/lib/kubelet كمشترك (بواسطة وحدة تخزين التحميل الافتراضية مثل rslave). لكن ما زلنا نرى مشكلات مماثلة ، ولكن أقل تكرارًا. أظن حاليًا أنه يجب إجراء بعض عمليات التثبيت الأخرى بطريقة مختلفة (على سبيل المثال ، /var/lib/docker أو /rootfs )

stormltf هل يمكنك من فضلك نشر تكوين حاوية kubelet الخاصة بك؟

stormltf أنت تقوم بتشغيل kubelet في الحاوية ولا تستخدم علامة --containerized (والتي تقوم ببعض الحيل باستخدام الحوامل ). مما يعني أساسًا أن جميع عمليات التحميل التي يقوم بها kubelet ستتم في مساحة اسم تحميل الحاوية. من الجيد أنه سيتم اقتراحها مرة أخرى إلى مساحة اسم الجهاز المضيف (كما هو الحال لديك / var / lib / kubelet كمشاركة) ، لكنني لست متأكدًا مما يحدث هو إزالة مساحة الاسم (عند إزالة حاوية kubelet).

هل يمكنك من فضلك بالنسبة للقرون العالقة القيام بما يلي:

على العقدة حيث يتم تشغيل الكبسولة

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• ونفس الشيء على العقدة نفسها mount | grep STUCK_POD_UUID .

يرجى أيضًا فعل الشيء نفسه بالنسبة للقرن المعد حديثًا. أتوقع أن أرى بعض حوامل /var/lib/kubelet (مثل السر الافتراضي)

stormltf هل أعدت تشغيل kubelet بعد إنشاء أول جرابين؟

stormltf يمكنك محاولة جعل /var/lib/docker و /rootfs كمشتركة (والتي لا أراها في فحص عامل الإرساء ، لكن انظر داخل الحاوية).

/ تخزين سيج

بالنسبة للبعض قد يساعد. نقوم بتشغيل kubelet في حاوية عامل إرساء بعلامة --containerized وتمكنا من حل هذه المشكلة من خلال تركيب /rootfs و /var/lib/docker و /var/lib/kubelet كتصاعد مشتركة. تبدو الحوامل النهائية هكذا

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

لمزيد من التفاصيل. هذا لا يحل المشكلة بشكل صحيح لأن كل حامل ربط ستحصل على 3 حوامل داخل حاوية kubelet (طفيليان). لكن يسمح التثبيت المشترك على الأقل بفكها بسهولة بطلقة واحدة.

لا يوجد لدى CoreOS هذه المشكلة. لأن استخدام rkt وليس docker لحاوية kubelet. في حالة تشغيل kubelet في Docker ويتم اقتراح كل تحميل داخل kubelet كونتينر في /var/lib/docker/overlay/... و /rootfs لهذا السبب لدينا اثنين من الطفيليات لكل حجم تحميل ربط:

• واحد من /rootfs في /rootfs/var/lib/kubelet/<mount>
• واحد من /var/lib/docker في /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

لدي نفس المشكلة مع Kubernetes 1.8.1 على Azure - بعد تغيير النشر وبدء القرون الجديدة ، تتعطل القرون القديمة.

لدي نفس المشكلة على Kubernetes 1.8.2 على IBM Cloud. بعد بدء تشغيل القرون الجديدة ، تتعطل القرون القديمة.

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

لقد استخدمت kubectl delete pod xxx --now بالإضافة إلى kubectl delete pod foo --grace-period=0 --force دون جدوى.

إذا كان السبب الجذري لا يزال كما هو (تصاعد مقترحة بشكل غير صحيح) ، فهذا خطأ IMO خاص بالتوزيع.

يرجى وصف كيفية تشغيل kubelet run في IBM cloud؟ وحدة النظام؟ هل بها علم --containerized ؟

يتم تشغيله بعلامة --containerized مضبوطة على false.

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

- علم محتوي: لا

حسنًا ، أحتاج إلى مزيد من المعلومات ، يرجى الاطلاع على تعليقي أعلاه https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349

ويرجى أيضًا إظهار محتويات /lib/systemd/system/kubelet.service وإذا كان هناك أي شيء عن kubelet في /etc/systemd/system يرجى المشاركة أيضًا.

على وجه الخصوص ، إذا كان kubelet يعمل في docker ، فأنا أريد أن أرى كل روابط الربط -v .

لقد واجهت اليوم مشكلة قد تكون هي نفسها التي تم وصفها ، حيث كان لدينا كبسولات على أحد أنظمة العملاء لدينا عالقة في حالة الإنهاء لعدة أيام. كما رأينا الأخطاء حول "خطأ: UnmountVolume.TearDown فشل لوحدة التخزين" مع تكرار "الجهاز أو المورد مشغول" لكل من البودات المتوقفة.

في حالتنا ، يبدو أن هناك مشكلة في عامل الإرساء على الأنظمة المستندة إلى RHEL / Centos 7.4 التي تمت تغطيتها في هذه المشكلة المتنقلة: https://github.com/moby/moby/issues/22260 وهذا moby PR: https: // github .com / moby / moby / pull / 34886 / files

بالنسبة لنا ، بمجرد أن نضبط خيار sysctl fs.may_detach_mounts = 1 في غضون دقيقتين ، تم تنظيف جميع كبسولات الإنهاء.

أواجه هذه المشكلة أيضًا: علقت Pods في حالة الإنهاء في 1.8.3.

سجلات kubelet ذات الصلة من العقدة:

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

Kubelet يعمل كوحدة systemd (ليست في حاوية) على Ubuntu 16.04.
كما ترى ، كان هناك تحميل لخادم NFS وبطريقة ما حاول kubelet حذف دليل التحميل لأنه يعتبر هذا الدليل غير محمّل.

مواصفات الأحجام من الكبسولة:

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

محدث : لقد واجهت هذه المشكلة من قبل أيضًا في 1.6.6

تواجه نفس الشيء على Azure ..

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

نسخة kubectl

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

وصف جراب nginx-56ccc998dd-nnsvj

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

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

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

cat /etc/systemd/system/kubelet.service

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

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

[Install]
WantedBy=multi-user.target

يبدو أن هناك أخطاء مختلفة تتعلق بالمشكلة. لدينا كلاهما في مجموعة 1.8.3 الخاصة بنا.

1. https://github.com/moby/moby/issues/31768 . إنه خطأ عامل ميناء. قابل للتكرار على وحدة الإرساء = 17.09.0 ~ ce-0 ~ ubuntu.
2. الثاني هو أكثر إثارة للاهتمام وربما يتعلق ببعض حالات السباق داخل kubelet.
   لدينا الكثير من البودات التي تستخدم حجم استمرارية NFS مع مسار فرعي محدد في حوامل الحاوية ، بطريقة ما يتعطل بعضها في حالة الإنهاء بعد حذف عمليات النشر. وهناك الكثير من الرسائل في سجل النظام:

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

والدليل الحقيقي ليس فارغًا ، فهو غير مُركب ويحتوي على دليل "المسار الفرعي"!
ومن تفسيرات هذا السلوك:

1. P1: ابدأ في إنشاء pod أو مزامنة pod
2. P1: إرسال إشارة إلى مدير مستوى الصوت لإجراء عمليات تحميل / إعادة تحميل.
3. P1: في انتظار اكتمال التثبيت.
4. P1: تلقي إشارة تحميل ناجحة (في الواقع فقط تحقق من تركيب جميع وحدات التخزين)
5. بطريقة ما يصبح الحجم غير صاعد. قد تكون عملية حذف أخرى لإلغاء تحميلها أو بعض أخطاء نظام التشغيل أو بعض إجراءات أداة تجميع البيانات المهملة.
6. P1: استمر في إنشاء الحاوية وإنشاء دليل فرعي في نقطة التحميل (غير مثبت بالفعل).
7. بعد كل الخطوات السابقة لا يمكن حذفها ، لأن دليل التحميل ليس فارغًا.

المزيد من السجلات:

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

بطريقة ما ، تبدأ بعض عمليات التنظيف ((dswp * requiredStateOfWorldPopulator) findAndRemoveDeletedPods ()) بإلغاء تحميل وحدات التخزين بينما يكون pod في حالة التهيئة:

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

التهيئة وحذف الكبسولة قيد التنفيذ في نفس الوقت.
للتكرار مع الخطأ ، يجب أن تبدأ وحذف / تحديث 10 عمليات نشر على الفور (تم اختبارها للتابع الفردي) وربما يجب ألا تكون عملية التحميل سريعة جدًا.

متأثر بنفس الخطأ في GKE. هل هناك أي حلول معروفة لهذه المشكلة؟ استخدام --now لا يعمل.

لدي إصلاح لهذا الخطأ ، لكنني لست متأكدًا من أنه سيتم دمجه بواسطة فريق kubernetes.

dreyk هل يمكنك تقديم مزيد من التفاصيل حول ما اكتشفته لهذا الخطأ وما هو الإصلاح الذي

@ gm42 تمكنت من

1. SSH في العقدة التي تم جدولة الكبسولة العالقة عليها
2. تشغيل docker ps | grep {pod name} للحصول على معرف حاوية Docker
3. تشغيل docker rm -f {container id}

في GKE ، ساعدت ترقية العقد على الفور.

لديك نفس الخطأ في المجموعة المحلية الخاصة بي التي تم إعدادها باستخدام kubeadm .

لا يظهر docker ps | grep {pod name} على العقدة أي شيء ، والجزء عالق في حالة الإنهاء. لدي حاليًا جرابان في هذه الحالة.

ما الذي يمكنني فعله لحذف الكبسولة بقوة؟ أو ربما تغيير اسم الكبسولة؟ لا يمكنني تدوير جراب آخر بنفس الاسم. شكر!

لقد وجدت السبب في مجموعة 1.7.2 الخاصة بي ،
لأن برنامج مراقبة آخر يقوم بتركيب مسار الجذر /
مسار الجذر يحتوي على /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf
لذلك عندما يحذف kubelet pod ، لكن لا يمكنه تحرير وحدة التخزين ، تكون الرسالة:
الجهاز أو الموارد مشغول

خطوات:
1) sudo journalctl -u kubelet
هذه القذيفة تساعدني في العثور على رسالة الخطأ ،
2) فحص sudo docker
ابحث عن io.kubernetes.pod.uid ":" ddc66e10-0711-11e8-b905-6c92bf70b164 "
و
HostConfig -> روابط -> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~secret/default-token-bnttf:/var/run/secrets/kubernetes .io / servi ceaccount: ro "

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

/ proc / 90225 / mountinfo
5) ps aux | جريب 90225
جذر 90225 1.3 0.0 2837164 42580؟ SSL فبراير 01 72:40 ./monitor_program

لدي نفس الخطأ في 1.7.2 الخاص بي

تم بدء تشغيل operationExecutor.UnmountVolume لوحدة التخزين "default-token-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token-bnttf") pod "ddc66e10-075--11e8-b90 6c92bf70b164 "kubelet [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262] عملية لـ" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bf70b164-default-token "-bn فشل "ddc66e10-0711-11e8-b905-6c92bf70b164 \") ". لا يُسمح بإعادة المحاولة حتى 2018-02-05 11: 37: 52.509148953 +0800 CST (periodBeforeRetry 2m2s). خطأ: فشل UnmountVolume.TearDown لوحدة التخزين "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 "): إزالة /var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kubernetes.io~ token-bnttf: الجهاز أو المورد مشغول

تؤدي إعادة تشغيل خدمة عامل الإرساء إلى تحرير القفل وإزالة البودات في غضون دقائق قليلة. هذا خطأ. باستخدام عامل الإرساء 17.03.2020

نفس المشكلة هنا على Azure ، Kube 1.8.7

حدث لنا منذ بضع دقائق في 1.8.9 أيضًا - أي شخص يبحث عن حل هذا؟ تساعد إعادة تشغيل عامل الإرساء ، لكنها سخيفة بعض الشيء.

كان هذا يحدث لي كثيرًا في أحدث إصدار 1.9.4 على GKE. تم القيام بذلك الآن:

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

نفس المشكلة هنا في GKE 1.9.4-gke.1
يبدو أنه مرتبط بتركيب وحدة التخزين.
يحدث ذلك في كل مرة مع إعداد Filebeats كما هو موضح هنا:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

يوضح سجل Kubelet هذا:

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

kubectl delete pod NAME --grace-period=0 --force
يبدو أنه يعمل.
أيضا إعادة تشغيل أعمال kubelet.

نفس المشكلة هنا في GKE 1.9.4-gke.1
يحدث فقط مع مجموعة معينة من الملفات ، ولكن إعادة إنشاء جميع العقد لا تساعد أيضًا ، فهي تستمر في الحدوث.

ضرب هذه المشكلة أيضًا على GKE 1.9.4-gke.1 مثل Tapppi - تمت إزالة البودات من برنامج TERMINATING

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

بالنسبة لنا ، حدث شيء جديد منذ لحظة ، عندما أزلت بالقوة حجرة معلقة باستخدام kubectl delete pod NAME --grace-period=0 --force ، أصبحت العقدة التي كان هذا الكبسولة غير صحية. نحن نشغل docker 17-12CE ، وساعدنا إعادة تشغيل docker deamon على هذا الصندوق في فك العقدة.

بالنسبة للأشخاص الذين يشاهدون هذه المشكلة على 1.9.4-gke.1 ، فمن المرجح أن يرجع ذلك إلى https://github.com/kubernetes/kubernetes/issues/61178 ، الذي تم إصلاحه في 1.9.5 ويتم طرحه في GKE هذا الاسبوع. تتعلق المشكلة بتنظيف عمليات تحميل المسار الفرعي لملف (وليس دليل). MustafaHosny اللهم امين يارب

IIUC ، ترتبط المشكلة الأصلية في هذا الخطأ بتكوين الكوبيليت الحاوية ، وهو أمر مختلف.

راجع للشغل ، كان إنشاء تجمع عقدة جديد بالإصدار v1.9.3-gke.0 هو الحل البديل لذلك ، نظرًا لأن v1.9.5 لم يتم طرحه على gke وهو عيد الفصح بالفعل.

هل يمكن لأحد أن يؤكد أن هذا تم إصلاحه في الإصدار 1.9.3+ من فضلك؟ لدينا بعض المشاكل الخطيرة بسبب هذا السلوك ، وإعادة تشغيل عامل الإرساء في كل مرة يحدث هذا هو ما يصل إلى st00pid.

ثابت على 1.9.6 بالنسبة لي

في يوم الأربعاء ، 4 أبريل 2018 ، الساعة 11:43 صباحًا ، كتب [email protected] :

هل يمكن لأحد أن يؤكد أن هذا تم إصلاحه في الإصدار 1.9.3+ من فضلك؟ لدينا
بعض المشاكل الخطيرة بسبب هذا السلوك ، وإعادة تشغيل عامل الإرساء
وقت حدوث ذلك هو st00pid.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-378557636 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABaviW5yfj64zVjBYFGUToe2MH3dKwpTks5tlKPNgaJpZM4PKs9r
.

حسنًا ، شكرًا لك @ ستونو . شيء آخر لتأكيده هنا. إليك نموذج kubespray الخاص بنا للكوبيليت المعبأ بالحاويات:

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

هل هذا يبدو جيدا؟ هل أي شخص آخر يستخدم نفس الشيء؟

لقد تحدثت في وقت مبكر جدا.

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

اضطررت إلى تدميرها بطريقة وحشية.

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

Stono أي إصدار عامل ميناء تستخدمه؟ بالنسبة لنا مع عامل الإرساء 17.12CE ، فإن إجراء حذف البودات باستخدام --force - grace-period 0 هو إجراء صارم للغاية - ينتهي به الأمر دائمًا مع عدم توفر العقدة بسبب تعليق عامل الإرساء

ما زلت أواجه هذه المشكلة في 1.9.6 على مجموعة Azure AKS المُدارة.

باستخدام هذا الحل البديل في الوقت الحالي لتحديد جميع البودات العالقة وحذفها (حيث انتهى بي الأمر إلى وجود مساحات كبيرة من القرون النهائية في مجموعة dev / scratch):

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

واجهت هذا في كل من مجموعات May Azure و AWS - تم توفير الحل البديل بواسطة Mike Elliot

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl احصل على قرون - جميع مساحات الأسماء
اسم NAMESPACE اسم الوضع الجاهز يعود إلى العمر
نظام kube heapster-76b8cd7b5-4r88h 1/1 تشغيل 0 25d
نظام kube-dns-5d7b4487c9-s4rsg 3/3 الجري 0 25d
نظام kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 تشغيل 0 25d
مراقبة نظام kube-grafana-997796fcf-wtz7n 1/1 تشغيل 0 25d
مراقبة نظام kube-influxdb-56fdcd96b-2phd2 1/1 تشغيل 0 25d
نظام الحراثة kube-publish-cc96d4f6b-jzqmz 1/1 الجري 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 إنهاء 0 3h
onap dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp 0/1 إنهاء 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl حذف pod dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp -n onap - فترة السماح = 0 - فرض
تحذير: لا ينتظر الحذف الفوري التأكيد على إنهاء المورد قيد التشغيل. قد يستمر المورد في العمل على الكتلة إلى أجل غير مسمى.
تم حذف القرص "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp"
ubuntu @ ip-10-0-0-22 : ~ $ kubectl احصل على قرون - جميع مساحات الأسماء
اسم NAMESPACE اسم الوضع الجاهز يعود إلى العمر
نظام kube heapster-76b8cd7b5-4r88h 1/1 تشغيل 0 25d
نظام kube-dns-5d7b4487c9-s4rsg 3/3 الجري 0 25d
نظام kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 تشغيل 0 25d
مراقبة نظام kube-grafana-997796fcf-wtz7n 1/1 تشغيل 0 25d
مراقبة نظام kube-influxdb-56fdcd96b-2phd2 1/1 تشغيل 0 25d
نظام الحراثة kube-publish-cc96d4f6b-jzqmz 1/1 الجري 0 25d
onap dev-sms-857f6dbd87-pds58 0/1 إنهاء 0 3h
ubuntu @ ip-10-0-0-22 : ~ $ kubectl حذف pod dev-sms-857f6dbd87-pds58 -n onap - فترة السماح = 0 - فرض
تحذير: الحذف الفوري لا ينتظر التأكيد على أنه تم إنهاء المورد قيد التشغيل. قد يستمر المورد في العمل على الكتلة إلى أجل غير مسمى.
تم حذف الجراب "dev-sms-857f6dbd87-pds58"
ubuntu @ ip-10-0-0-22 : ~ $ kubectl احصل على قرون - جميع مساحات الأسماء
اسم NAMESPACE اسم الوضع الجاهز يعود إلى العمر
نظام kube heapster-76b8cd7b5-4r88h 1/1 تشغيل 0 25d
نظام kube-dns-5d7b4487c9-s4rsg 3/3 الجري 0 25d
نظام kube-system kubernetes-dashboard-f9577fffd-298r6 1/1 تشغيل 0 25d
مراقبة نظام kube-grafana-997796fcf-wtz7n 1/1 تشغيل 0 25d
مراقبة نظام kube-influxdb-56fdcd96b-2phd2 1/1 تشغيل 0 25d
نظام الحراثة kube-publish-cc96d4f6b-jzqmz 1/1 الجري 0 25d

لست متأكدًا مما إذا كانت هذه هي نفس المشكلة ، لكننا بدأنا في ملاحظة هذا السلوك _ منذ _ الترقية من 1.9.3 إلى 10.10.1. لم يحدث قبل ذلك. نحن نستخدم مجلدات glusterfs ، مع SubPath. Kubelet يسجل باستمرار أشياء مثل

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

و lsof يوضح بالفعل أن الدليل الموجود أسفل مجلدات glusterfs لا يزال قيد الاستخدام:

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

كان كل هذا جيدًا في 1.9.3 ، لذلك يبدو الأمر كما لو أن إصلاح هذه المشكلة قد كسر حالة الاستخدام الخاصة بنا :(

@ ross-w هذا التوقيع يبدو مختلفًا عن الآخرين. هل يمكنك فتح إصدار جديد وتضمين مواصفات البود أيضًا؟

أي تحديثات على هذه القضايا؟
في حالتنا (Kubernetes 1.9.7 و docker 17.03) ، تكون البودات في حالة إنهاء ، بعد أن تنفد العقدة من الذاكرة ويتم إعادة جدولتها. في النهاية ، يوجد الكثير من وحدات الأشباح في لوحة معلومات kubernetes وفي علامة تبويب عمليات النشر ، يمكننا أن نرى عمليات النشر باستخدام 4/1 pods.
إعادة تشغيل kubelet أو قتل جميع القرون في مساحة الاسم يساعد ، لكنه حل ضعيف للغاية.

Adiqq لأنها كانت مشكلة مع Docker it self.

ألق نظرة على journalctl -u kubelet -f على إحدى عقدتك. تلقيت رسالة مثل "لا يمكنني قتل الحاويةخطأ gRpc "(ليست لدي الرسالة الحقيقية منذ أن أصلحت هذا الخطأ).

لإصلاح ذلك قمت بإعادة تشغيل عامل الإرساء في كل ملاحظة. أثناء تمهيد Docker ، قم بتنظيف الحاويات في حالة مكسورة وإزالة كل هذه القرون التي لا معنى لها.

حصلت على هذا بالأمس في 1.9.7 ، مع وجود الكبسولة عالقة في حالة الإنهاء وفي السجلات كان لديها للتو "يحتاج إلى قتل البود" ، كان علي أن أتخلص من --force --grace-period=0 للتخلص.

حصلت للتو على هذا أيضًا مع 1.9.7-gke.0.
لم يكن لدي مشاكل مع 1.9.6-gke.1.
لكنها حصلت عليها مع 1.9.4 و 1.9.5

الكبسولة التي تتعثر لديها PV متصلة.

إعادة نشر أو حذف جراب له نفس التأثير.
إعادة تشغيل kubelet على العقدة المخالفة لم تنجح. لم يبدأ kubelet مرة أخرى واضطررت إلى إعادة تشغيل العقدة بأكملها.

خلال هذا ، لا يمكن جدولة الكبسولة على أي عقدة أخرى لأنها قالت إن الكهروضوئية مثبتة بالفعل في مكان آخر.

Stono @ nodefactory-bk هل يمكنكم يا رفاق إلقاء نظرة على سجلات kubelet الخاصة بك على العقد المخالفة لمعرفة ما إذا كانت هناك أي سجلات مفصلة يمكن أن تشير إلى المشكلة؟

ccdashpole

كان هناك تطبيق واحد فقط توقف في الإنهاء.
هذا هو 1.9.7-gke.1
هنا وصف kubectl البود مع الأسرار المنقحة:

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

لست متأكدًا من مكان العثور على kubelet.log في gke على صور googles. وجدت شيئًا أرفقه.
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
قتلته وإزالته.
بدأ الأمر جيدًا بعد ذلك ولكنه استغرق وقتًا أطول قليلاً من المعتاد.

ضع في اعتبارك أن هذا لا يحدث في كل مرة لهذا التطبيق.
ربما أقول ما يقرب من 1/4 مرات.

عند الوصول إلى k8s 1.9.6 ، عندما يتعذر على kubelet إلغاء تحميل Cephfs ، تظل جميع القرون الموجودة على العقدة منتهية إلى الأبد. اضطررت إلى إعادة تشغيل العقدة للتعافي ، ولم يساعد إعادة تشغيل kubelet أو Docker.

tuminoid تبدو قضية ceph مختلفة. هل يمكنك فتح إصدار جديد وتقديم أحداث Pod وسجلات kubelet لهذه الحجرة؟

لمعلوماتك ، يبدو أن تحديث مجموعاتي (إلى k8s v1.10.2) قد أزال هذه المشكلة بالنسبة لنا.

المرفق يعيد إنتاج هذا بالنسبة لي على gke

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

k8s-nfs-test.yaml.txt

قم بتشغيله ، ثم احذفه. سوف تتعثر "nfs-client" في الحذف. السبب هو التثبيت الصلب على العقدة ، ويتم حذف "الخادم" أولاً.

donbowman لمشكلة إلغاء

لا ارى كيف؟ يمكنني ضبطه على PersistentVolumeClaim ، لكن هذا لا ينطبق هنا.
لا أعتقد أن StorageClass ينطبق هنا (سيكون هذا هو القرص السفلي ، أسفل خادم nfs).

هذه المسألة على nFS- العميل.
هل فاتني شيء؟

بالنسبة إلى nfs PV الخاص بك ، يمكنك تعيين حقل mountOptions بدءًا من 1.8 لتحديد تثبيت ناعم. إذا قمت بتوفير وحدات تخزين nfs ديناميكيًا ، فيمكنك أيضًا تعيينها في StorageClass.mountOptions

نعم ، ولكن ليس PV الذي يتم تركيبه مع NFS.
إنها من حاوية خادم NFS الخاصة بي.
لا يوجد توفير ديناميكي.

هذا باستخدام Google GCP + GKE. يختار PVC PV وهو عبارة عن كتلة IO ، يتم تثبيته على شكل ext4 في حاوية تعيد تصديره باستخدام NFS.

المجموعة الثانية من الحاويات ، والتي يتم تحميلها من خادم nfs (والتي هي نفسها جراب) ، لا يرونها على أنها PV. يرون أنه حجم مثل أدناه.

لا أرى طريقة لجعل عميل nfs هذا يرى "pvc" للتثبيت ، لذلك لا يمكنني تعيين خيارات التثبيت. ولا يمكنني رؤيته على أنه فئة التخزين.

هل فاتني شيء؟

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

donbowman لمجموعة الحاويات الثانية الخاصة بك ، والتي تستخدم nfs mount ، يمكنك يدويًا إنشاء PV لهذا الحجم nfs مع مجموعة mountOptions ، ومشاركة PVC لهذا nfs PV في جميع القرون الخاصة بك. لا يوجد توفير ديناميكي متضمن.

شيء من هذا القبيل:

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

شكر! لقد نجح ذلك (بمعنى أنه أصبح الآن ضعيفًا) ولكنه لا يصلح المشكلة:

أصبح الحامل (كما لوحظ على العقدة) ناعمًا الآن:

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

ولكن عندما أحذف كل شيء ، ما زلت أجد عميل nfs عالقًا إلى الأبد في حالة الإنهاء.

k8s-nfs-test.yaml.txt

المرفق هو yaml الذي استخدمته. لقد قمت بإنشاء "إنشاء" ، وانتظرت ظهوره ، ولاحظت أن العميل لديه وحدة التحميل ، ويمكنه قراءة / كتابة الملفات فيه ، ثم قمت بإجراء "حذف" عليه.

يتم حذف جراب nfs-server ، لكن nFS-client لا يتم حذفه.

بالنظر إلى الكبسولة ، ظل الحامل:

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

donbowman آه آسف جدا ، كنت مخطئا بشأن الخيار اللين. يمنع الخيار soft فقط استدعاءات نظام الملفات من التوقف عندما يتعذر الوصول إلى الخادم ، ولكنه لا يساعد في الواقع في إلغاء تحميل وحدة تخزين nfs. يجب القيام بفك القوة من أجل ذلك ، وهو أمر ليس لدينا حاليًا طريقة لتمريره. في الوقت الحالي ، سيتعين عليك تنظيف عمليات التحميل هذه يدويًا والتأكد من حذف البودات بالترتيب الصحيح (عملاء nfs أولاً ، ثم خادم nfs).

حاولت إضافة timeo = 30 و intr ، لكن نفس المشكلة.
يؤدي هذا إلى قفله ، ويجب تسجيل الدخول إلى العقدة وإجراء umount -f -l على الحامل الأساسي ، ومن ثم يمكن إجراء حذف kubectl --force --grace-period 0 على pod.

يبدو أنه نظرًا لأنه تم تركيبه نيابة عن pod ، فمن الممكن أن يكون umount (أو فرض umount بعد بعض المهلة) عند الحذف تلقائيًا.

كان لدي مجموعة من البودات من هذا القبيل لذلك كان علي أن أتوصل إلى أمر من شأنه تنظيف جميع القرون النهائية:

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

أعتقد أنه مع متجر Google الجديد

donbowman iirc ، مشكلتك هي أنك كنت تنهي جراب خادم nfs قبل جراب عميل nfs. إذا كنت تستخدم filestore ، فلن تحتاج بعد الآن إلى pod لاستضافة خادم nfs الخاص بك ، لذلك يجب ألا تواجه هذه المشكلة طالما لم تحذف ملف firestore بأكمله.

ألن أواجه نفس المشكلة إذا كنت أقوم بتنسيق الملف؟ على سبيل المثال ، إذا كنت أحضره لنشر kubernetes معين ، ثم انخفض في النهاية ، فلن يكون الطلب مضمونًا.

ولكني أعتقد أيضًا أن المشكلة لا تتعلق بالترتيب فقط ، فحذف nfs client pod لا يتم حذفه على الإطلاق ، بل يترك التثبيت متدليًا على العقدة. لذلك ، بغض النظر عما إذا كان مخزن الملفات / الخادم موجودًا أم لا ، هناك تثبيت متدلي.

عندما يتم إنهاء الكبسولة ، نقوم بإلغاء تحميل وحدة التخزين (على افتراض أن الخادم لا يزال موجودًا). إذا كنت ترى تصاعدًا متدليًا حتى في حالة وجود الخادم ، فهذا خطأ.

إذا كنت تستخدم توفيرًا ديناميكيًا مع PVCs و PVs ، فإننا لا نسمح بحذف PVC (والتخزين الأساسي) حتى يتم الانتهاء من استخدامه. إذا كنت ترغب في تنسيق التوفير بنفسك ، فأنت بحاجة إلى التأكد من عدم حذف الخادم حتى تنتهي جميع البودات من استخدامه.

ربما يكون هذا حلًا ممكنًا: # 65936

نجح فرض الحذف مقابل kubectl delete po $pod --grace-period=0 --force . لم يكن العلم --now يعمل. لست متأكدًا من # 65936 ولكني لا أرغب في قتل العقدة عند حدوث حالات Unknown .

وجود نفس المشكلة (تظل البودات قيد الإنهاء لأنه لا يمكن إلغاء تحميل ملف داخل البود لأن الجهاز "مشغول") على 1.10.5. بالنسبة لي ، فإن استخدام --grace-period=0 --force سيؤدي إلى استمرار وجود نقطة التثبيت. في النهاية انتهى بي الأمر بأكثر من 90000 نقطة تثبيت ، مما أدى إلى إبطاء الكتلة بشدة. الحل هنا هو البحث في مجلد البود وإلغاء تحميل هذه الملفات بشكل متكرر ، ثم حذف مجلد البود بشكل متكرر.
في حالتي ، أقوم بتركيب configmap باستخدام مسار فرعي في مجلد موجود بالملفات الموجودة ، والكتابة فوق أحد الملفات الموجودة. كان هذا يعمل بشكل جيد بالنسبة لي على 1.8.6.
يذكر الملصق الأصلي أن الكبسولات تبقى في "إنهاء" لبضع ساعات ، وفي حالتي كانت أيامًا. لم أرهم يتم تنظيفهم في النهاية ، إلا عندما أقوم بإجراء الحل اليدوي.

مع وجود نفس المشكلة ، بسبب مجمع السجل (مشابه لـ fluentd) ، فإنه يقوم بتركيب مجلد /var/lib/docker/containers ويحتوي البود على الكثير من عمليات التحميل:

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

في حالتي ، يمكن إزالة بعض الكبسولات جيدًا بواسطة kubernetes ، لكن بعضها عالق في حالة "إنهاء".

قد يكون مرتبطًا بـ https://github.com/kubernetes/kubernetes/issues/45688 (أنا أستخدم عامل الإرساء 17 أيضًا)

لقد واجهت للتو مشكلة أن البودات لم تكن منتهية بسبب فقد أحد الأسرار. بعد أن أنشأت هذا السر في مساحة الاسم تلك ، عاد كل شيء إلى طبيعته.

لقد أزلت البودات العالقة مثل هذا:

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

حصلت على مشكلة مماثلة تعمل على Azure ACS.

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

لقد حاولت استخدام --now أو تعيين فترة السماح. على سبيل المثال

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

لا تزال الكبسولة معلقة وهذا يتسبب في توقف النشر المقابل أيضًا.

أنا أيضًا تطاردني رسائل "Need to kill Pod" في أحداث الكبسولة. ماذا يعني هذا بالمناسبة؟ أن _Kubernetes_ يشعر بالحاجة إلى قتل الكبسولة ، أم أنه _I_ يجب أن يقتل الكبسولة؟

حدث هذا لي منذ يومين وتخلت عن الحذف وتركت الكبسولة كما هي. ثم اختفى اليوم ويبدو أنه تم حذفه في النهاية.

حدث لي الآن. لم يعمل حل --force --now الآن بالنسبة لي. لقد وجدت السطر التالي في سجلات kubelet مريبة

6 أغسطس 15:25:37 kube-minion-1 kubelet [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] فشلت NetworkPlugin cni في ربط الحالة للقرص "backend-foos-227474871-gzhw0_default": غير متوقع إخراج الأمر nsenter: لا يمكن فتح: لا يوجد مثل هذا الملف أو الدليل

الأمر الذي قادني إلى إيجاد المشكلة التالية:
https://github.com/openshift/origin/issues/15802

أنا لست في وضع مفتوح ولكن على Openstack ، لذلك اعتقدت أنه يمكن أن يكون مرتبطًا. أعطيت النصيحة لإعادة تشغيل عامل الميناء.
أدت إعادة تشغيل عامل الإرساء إلى اختفاء البودات العالقة في "الإنهاء".

أعلم أن هذا مجرد حل بديل ، لكنني لا أستيقظ أحيانًا في الثالثة صباحًا لإصلاح هذا بعد الآن.
لا أقول أنه يجب عليك استخدام هذا ، لكنه قد يساعد بعض الناس.

النوم هو ما لدي إنهاء قرون بلدي تم تعيين GracePeriodSeconds على (30 ثانية). إذا كان على قيد الحياة لفترة أطول من ذلك ، فإن هذا cronjob سوف يفرض - فترة السماح = 0 ويقضي عليه تمامًا

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

أرى نفس الخطأ مع Kubernetes v1.10.2. تتعطل القرون في النهاية إلى أجل غير مسمى ويسجل الكوبيليت الموجود على العقدة المعنية بشكل متكرر:

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

يمكنني إلغاء تحميل حجم المسار الفرعي المعني يدويًا دون شكوى (لا يخبرني Linux أنه مشغول). هذا يمنع kubelet من تسجيل رسالة الخطأ. ومع ذلك ، لا يلهم هذا Kubernetes لمواصلة التنظيف ، حيث لا يزال الكبسولة معروضة في حالة الإنهاء. إعادة تشغيل Docker بشكل روتيني لتنظيف هذا ليس حلاً مقبولاً حقًا بسبب الاضطراب الذي يسببه لتشغيل الحاويات.

تجدر الإشارة أيضًا إلى أن الحاوية نفسها اختفت من docker ps -a بدون أي دليل على وجودها على الإطلاق ، لذلك لست متأكدًا من أن هذه مشكلة في Docker بالفعل. نحن نستخدم Docker الإصدار 17.03.2-ce.

تحديث: لقد قمنا بتكوين العقد الخاصة بنا لإعادة توجيه دليل kubelet الجذر إلى وحدة تخزين بخلاف نظام التشغيل مع ارتباط رمزي (كان /var/lib/kubelet رابطًا رمزيًا يشير إلى دليل آخر على وحدة تخزين مختلفة). عندما أعدت تكوين الأشياء لتمرير --root-dir إلى kubelet بحيث انتقل إلى الدليل المطلوب مباشرةً ، بدلاً من رابط رمزي ، وأعدت تشغيل kubelet ، فقد قام بتنظيف حوامل الحجم ومسح الكبسولات التي كانت عالقة الإنهاء دون الحاجة إلى إعادة تشغيل Docker.

لقد واجهت هذه المشكلة اليوم لأول مرة أثناء تشغيل بعض البودات محليًا على minikube.

كان لدي مجموعة من البودات عالقة في Terminating بسبب configmap / secret الذي تم تركيبه كوحدة تخزين مفقودة. لم تنجح أي من الاقتراحات / الحلول / الحلول المنشورة أعلاه باستثناء هذا .

الشيء الوحيد الذي أعتقد أنه جدير بالملاحظة هو ما يلي:

• عندما قمت بتشغيل kubectl get pods ، حصلت على قائمة الكبسولات بالحالة Terminating .
• عندما قمت بتشغيل docker ps | grep -i {{pod_name}} الرغم من ذلك ، لم يكن أي من البودات في حالة Terminating كما يراها kubectl get pods تعمل في minikube VM.

كنت أتوقع أن يقوم docker ps بإرجاع قائمة البودات العالقة في حالة Terminating لكن في الواقع لم يكن أي منها يعمل ، لكن kubectl get pods كان يعيد بيانات عنها؟ هل يمكن لأي شخص أن يشرح لماذا هذا؟

لقد واجهت هذه المشكلة مع 4 عمليات نشر. ثم قمت بالتبديل من "وحدة التخزين المحلية" إلى "مسار المضيف" لجميع الحوامل ، وذهبت بالنسبة لي.

لقد واجهت للتو مشكلة أن البودات لم تكن منتهية بسبب فقد أحد الأسرار. بعد أن أنشأت هذا السر في مساحة الاسم تلك ، عاد كل شيء إلى طبيعته.

كيف تنشئ سرًا في مساحة الاسم إذا كانت مساحة الاسم في حالة "إنهاء"؟

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

يعمل لدي.

لا تنسى "- فترة السماح = 0". لا يهم

حذرني kubectl "تحذير: الحذف الفوري لا ينتظر التأكيد على أنه تم إنهاء المورد قيد التشغيل. قد يستمر المورد في العمل على الكتلة إلى أجل غير مسمى." عندما أستخدم --force --grace-period=0 .
هل يمكن لأي شخص أن يخبرني ما إذا كان هذا سيحدث بالفعل؟

في الواقع ، عندما نحذف بعض البودات ، فقد يتأخر الحذف لبعض الأسباب ،
وإذا قمنا بتنفيذ "kubectl delete" with flag "--force --grace-period = 0" ،
سيتم حذف كائن المورد مرة واحدة.

هل يمكنك المساعدة في تأكيد ما إذا كان سيتم حذف البود على الفور؟
هل يعني ذلك أن رسالة التحذير غير دقيقة بالفعل؟

windoze ، إذا قمت بفرض الخيار --grace-period = 0 ، فهذا يعني أنه سيتم حذف كائن pod API من خادم API على الفور. تعتبر Node kubelet مسؤولة عن تنظيف حوامل الحجم وقتل الحاويات. إذا لم يكن kubelet قيد التشغيل أو واجه مشاكل أثناء تنظيف الكبسولة ، فقد تكون الحاوية لا تزال قيد التشغيل. لكن يجب أن يواصل Kubelet محاولة تنظيف القرون كلما أمكن ذلك.

ما زال هذا يعني أن الحذف قد يستغرق إلى الأبد لأن kubelet قد يكون معطلاً؟
هل هناك أي طريقة للتأكد من حذف الكبسولة؟
أطرح السؤال لأن لدي بعض البودات الضخمة التي تعمل في الكتلة ولا توجد ذاكرة كافية على كل عقدة لتشغيل مثيلين منها.
إذا فشل الحذف ، تصبح العقدة غير قابلة للاستخدام ، وإذا حدثت هذه المشكلة عدة مرات ، فستتعطل الخدمة تمامًا لأنه في النهاية لن تكون هناك عقدة يمكنها تشغيل هذا الكبسولة.

في بيئة عامل الإرساء القديمة ، يمكنني أن أجبر على قتل حجرة باستخدام kill -9 أو شيء من هذا القبيل ، ولكن يبدو أن k8s لا تملك مثل هذه الوظيفة.

windoze هل تعرف لماذا فشل حذف البود الخاص بك غالبًا؟ هل هذا لأن kubelet لا يعمل ، أو أن kubelet كان يحاول قتل الحاوية لكنه فشل مع بعض الأخطاء؟

حدث مثل هذا الموقف عدة مرات على مجموعتي قبل عدة أشهر ، كان kubelet يعمل ولكن يبدو أن برنامج Docker daemon لديه بعض المشاكل وتعثر بدون سجل أخطاء.
كان الحل هو تسجيل الدخول إلى العقدة وإيقاف عملية الحاوية بالقوة وإعادة تشغيل برنامج Docker daemon.
بعد بعض الترقيات ، اختفت المشكلة ولم أعود إليها مرة أخرى.

kubectl delete pods <podname> --force --grace-period=0 عمل لي!

@ shinebayar-g ، المشكلة مع --force هي أنها قد تعني أن الحاوية الخاصة بك ستستمر في العمل. إنه يخبر Kubernetes فقط أن ينسى حاويات هذه الكبسولة. الحل الأفضل هو إدخال SSH في الجهاز الظاهري الذي يقوم بتشغيل الكبسولة والتحقيق في ما يحدث مع Docker. حاول قتل الحاويات يدويًا باستخدام docker kill وإذا نجحت ، فحاول حذف الحاوية بشكل طبيعي مرة أخرى.

agolomoodysaada آه ، هذا منطقي. شكرا على الشرح. لذلك لا أعرف حقًا أن الحاوية الفعلية محذوفة حقًا أم أنها ليست صحيحة؟

إذن ، إنها نهاية عام 2018 ، خرج kube 1.12 و ... هل ما زلت تواجه مشاكل مع القرون العالقة؟

لدي نفس المشكلة ، إما --force --grace-period = 0 أو --force - الآن لا تعمل ، فيما يلي السجلات:

الجذر @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
إعادة تعيين الوضع الجاهز للاسم العمر
node-exporter-zbfpx 0/1 إنهاء 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat حذف pod node-exporter-zbfpx - فترة السماح = 0 --force
تحذير: الحذف الفوري لا ينتظر التأكيد على أنه تم إنهاء المورد قيد التشغيل. قد يستمر المورد في العمل على الكتلة إلى أجل غير مسمى.
تم حذف جراب "node-exporter-zbfpx"

الجذر @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
إعادة تعيين الوضع الجاهز للاسم العمر
node-exporter-zbfpx 0/1 إنهاء 0 4d

root @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat حذف pod node-exporter-zbfpx --now --force
تم حذف جراب "node-exporter-zbfpx"

الجذر @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat get pod node-exporter-zbfpx
إعادة تعيين الوضع الجاهز للاسم العمر
node-exporter-zbfpx 0/1 إنهاء 0 4d

الجذر @ r15-c70-b03-master01 : ~ #

حاولت تحرير الكبسولة وحذف قسم الصيغ النهائية في البيانات الوصفية ، لكنه فشل أيضًا.

ما زلت أرى هذا بطريقة قابلة للتكرار بنسبة 100٪ (نفس تعريفات الموارد) باستخدام kubectl 1.13 alpha و Docker for Desktop على macOS. من خلال إعادة الإنتاج ، أعني أن الطريقة الوحيدة لإصلاحها هي إعادة تعيين Docker لنظام التشغيل Mac ، وعندما أقوم بإعداد مجموعتي مرة أخرى باستخدام نفس الموارد (نص النشر) ، يفشل نفس البرنامج النصي للتنظيف.

لست متأكدًا من سبب كونه ملائمًا ولكن يبدو أن برنامج التنظيف الخاص بي يشبه:

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

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

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

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

MODE=$1

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

resources=()

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

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

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

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

نظرًا لأن المجموعة تعمل محليًا ، يمكنني التحقق من عدم وجود حاويات تعمل في Docker ، فإن kubectl هو فقط الذي يتم تعليقه عند إنهاء البودات. عندما أقوم بـ describe البودات ، يتم إدراج الحالة كـ Status: Terminating (lasts <invalid>)

فقط حدث لي مرة أخرى. كنت أحاول تثبيت خادم percona pmm مع مشاركة NFS ولم يظهر البرنامج ، لذلك أزلت وحدث هذا. (الادعاء المستمر لم يكن يعمل مع هذا البرنامج). أعتقد أنني أتصل بـ kubectl delete pods <podname> --force --grace-period=0 مرة أخرى. لكن السؤال هو كيف أعرف أين يعيش هذا الكبسولة؟

@ shinebayar-g ، SSH في الجهاز الظاهري الذي كان يعمل عليه وتشغيله docker ps .

حسنًا ، لم يكن هناك .. لدي عدد قليل من أجهزة VM ، لذلك سألت كيف أعرف أيها هو الصحيح. :)

@ shinebayar-g هذا قد يعمل:
kubectl describe pod/some-pod-name | grep '^Node:'

المشكلة نفسها.

وجد docker ps أن الحاوية في حالة "ميتة" ولم يتم الخروج منها (0) كما هو متوقع

يؤدي حذف الحاوية يدويًا إلى إدخال سجل عامل الإرساء التالي:

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

لسوء الحظ ، تم قطع الخط ، لكنني أعتقد أنني أتذكر ، كانت المشكلة أن العملية لم تعد موجودة.

ما زلت أتعثر مع هذه المشكلة مع k8s v1.11.0. فيما يلي قائمة تحقق لما أفعله لتنظيف القرون الخاصة بي:

• تأكد من استعادة جميع الموارد المرفقة بالجراب. ليست جميعها مرئية في kubectl get ؛ بعضها معروف فقط لـ Kubelet الذي يعمل عليه الكبسولة ، لذلك سيتعين عليك متابعة تدفق السجل محليًا
  
  
  
  • على وجه الخصوص ، الدلائل umount التي يشكو منها Kubelet برسائل device or resource busy
  
  
• عندما يفشل كل شيء آخر ، kubectl edit البود الفاشل وإزالة finalizers: → - foregroundDeletion

نصيحتان أخريان:

• في حالة الاستقرار ، يجب ألا يسجل Kubelet غير المرتبك أي رسائل دورية على الإطلاق. أي نوع من الفشل المتكرر في إطلاق شيء ما ، هو أحد أعراض الكبسولة العالقة.
• يمكنك الاحتفاظ بأمر kubectl delete محظورًا في نافذة أخرى لمراقبة تقدمك (حتى على الكبسولة التي "حذفت" بالفعل مرات عديدة). kubectl delete سينتهي بمجرد تحرير آخر مورد عالق.

في مواجهة هذا اليوم.
ما تم إنجازه:

1. ssh إلى العقدة وإزالة الحاوية يدويًا
2. بعد ذلك ، يظهر لي kubectl get pods الحاوية المتوقفة 0/1 terminating (كان 1/1 terminating )
3. قم بإزالة قسم finalizers من الكبسولة ، كان foregroundDeletion ($ kubectl تحرير pod / name) -> تمت إزالة الحاوية من قائمة pods
4. حذف النشر -> تمت إزالة جميع العناصر المتعلقة بالنشر.

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

نواجه نفس المشكلة عندما بدأنا في تجميع الأسرار (مشتركة مع العديد من الكبسولات). يذهب الكبسولة في حالة terminating وتبقى هناك إلى الأبد. نسختنا هي v1.10.0. اختفت حاوية عامل الإرساء المرفقة ولكن المرجع في خادم واجهة برمجة التطبيقات يبقى ما لم أحذف الكبسولة بالقوة باستخدام الخيار --grace-period=0 --force .

أبحث عن حل دائم.

حسنًا ، لقد اختبرت مؤخرًا runc استغلال CVE-2019-5736 على مجموعة التدريج الخاصة بي ، كما تعلم بالفعل ، فإن الاستغلال يعيد كتابة ملف runc الثنائي على الجهاز المضيف. استغلالها المدمر. بعد ذلك رأيت سلوكًا غريبًا على الكتلة. جميع القرون عالقة في حالة الإنهاء. كان الحل هو استنزاف عامل إرساء تطهير العقدة المتأثر وإعادة تثبيته. بعد ذلك تعمل جميع القرون و k8s بشكل طبيعي كما كان من قبل. ربما تكون مشكلة عامل الإرساء وإعادة تثبيته تحل مشكلتك أيضًا!. شكر

تثبيت الإصدار 1.13.3 الجديد هنا. هذا يحدث لي أيضا. يحدث منذ أن قمت بتركيب نفس وحدات تخزين NFS عبر عدد قليل من الكبسولات التي يبدو أن لها علاقة بها.

أرى هذه المشكلة عند إنشاء عملية نشر تحاول إنشاء وحدة تخزين باستخدام سر غير موجود ، يؤدي حذف هذا النشر / الخدمة إلى ترك حوالي Terminating pod.

تواجه نفس المشكلة مع الإصدار 1.1.12.3 ، و - فترة السماح = 0 - فرض أو - الآن كلاهما غير صالح ، احذف مجموعة الحالة التي تنتمي أيضًا إلى غير صالحة

نفس المشكلة مع SMB (أعتقد؟) تحميل (مشاركة ملفات Azure وفقًا لـ https://docs.microsoft.com/en-us/azure/aks/azure-files-volume).

نفس المشكلة مع 13.3

لدي نفس المشكلة التي تكون البود في حالة "إنهاء" لمدة يومين تقريبًا.
أنا أستخدم Minikube على جهاز Linux (Debian).

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

ardalanrazavi لماذا تنتهي لمدة يومين؟ ما عليك سوى فرض الحذف إذا لم يتم الحذف بعد 5 دقائق

تضمين التغريدة

لماذا ينتهي ليومين؟

هذا سؤال جيد. كلنا نود معرفة ذلك.

ما عليك سوى فرض الحذف إذا لم يتم الحذف بعد 5 دقائق

يؤدي حذفه بالقوة إلى ترك الكتلة في حالة غير متسقة. (مع minikube ، هذه ليست مجموعتك الحقيقية ، ومن المسلم به أنها أقل أهمية بكثير)

تضمين التغريدة

لا أرى أي حلول أخرى هنا لأكون صريحًا.

بالتأكيد ، سيتم ترك الكتلة في "حالة غير متناسقة". أود أن أفهم ما تعنيه بهذا بالضبط. الإغلاق الإجباري سيء. أنا أيضًا لا أحب ذلك ، ولكن في حالتي ، أشعر بالراحة في تدمير وإعادة نشر أي موارد كما هو مطلوب.

في حالتي ، يبدو أنه يتعطل فقط عند إنهاء البودات التي تحتوي على NFS mount. ويحدث فقط عندما ينخفض ​​خادم NFS قبل أن يحاول العميل النزول.

لقد أصلحت المشكلة ، وتمكنت من عزل أن جميع البودات العالقة كانت جميعها في عقدة واحدة ، وتمت إعادة تشغيل العقدة وانتهت المشكلة.

nmorsAndrewSav لقد فعلت ذلك بفرض الحذف أيضًا.

من المعروف أن حذف خادم nfs قبل حذف البودات يتسبب في توقف التحميل إلى الأبد. من الأفضل طلب عمليات الحذف في هذه الحالة بحيث يتم دائمًا حذف خادم nfs أخيرًا.

@ msau42 خادم NFS الخاص بي ليس جزءًا من مجموعة k8s - إنه جهاز وجهاز منفصلان معًا

لا يهم ما إذا كان جزءًا من مجموعة k8s أم لا. إذا تعذر الوصول إلى خادم nfs ، فسيتم تعليق إلغاء التحميل حتى يصبح الوصول إليه مرة أخرى.

@ msau42 هذا غريب ، لأنني متأكد تمامًا من أنه حتى عندما عاد عبر الإنترنت ، كانت البودات لا تزال عالقة. تبدأ البودات الجديدة وتتصاعد بشكل جيد.

أستخدم خادم NFS على kubernetes متبوعًا بهذا المثال وهذا يحدث كثيرًا للأسف ..

@ shinebayar-g لقد اتبعت هذا الدليل أيضًا ، لكنني الآن تخلصت من PVs و PVCs وحدد الحجم الخاص بي مباشرةً في النشر ، مثل:

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

لم أواجه أي مشاكل منذ ذلك الحين ، لقد غيرت هذا الأمر لمدة أسبوع تقريبًا على أمل أن يكون التكوين الأبسط أكثر موثوقية .. دعنا نرى ... ربما سيؤدي هذا إلى حل المشكلة؟

كحل بديل ، قمت بكتابة نص برمجي يلتقط بعض الأسطر الأخيرة من /var/log/syslog وابحث عن أخطاء مثل "عملية ... إزالة / var / lib / kubelet / pods ... الدليل ليس فارغًا" أو "nfs. .. الجهاز مشغول ... unmount.nfs "أو" مقبض ملف NFS الذي لا معنى له ".
ثم يقوم باستخراج الدليل الكامل pod_id أو pod ومعرفة ما يحمله (مثل mount | grep $pod_id ) ، ثم يقوم بإلغاء تحميل الكل وإزالة الدلائل المقابلة. في النهاية يقوم kubelet بالباقي ويغلق بأمان ويحذف القرون. لا مزيد من البودات في حالة الإنهاء.

أضع هذا النص في cron ليتم تشغيله كل دقيقة. نتيجة لذلك - لا توجد مشكلة في الوقت الحالي ، حتى بعد 3-4 أشهر.
ملاحظة : أعلم أن هذا النهج غير موثوق به ويتطلب التحقق من كل ترقية للكتلة ولكنها تعمل!

أنا أستخدم الإصدار 1.10 وقد واجهت هذه المشكلة اليوم وأعتقد أن مشكلتي تتعلق بمسألة تحميل وحدة تخزين سرية والتي ربما تكون قد تركت بعض المهام معلقة وتركت البود في حالة الإنهاء إلى الأبد.

اضطررت إلى استخدام خيار --grace-period = 0 - force لإنهاء البودات.

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

لقد وجدت أنه إذا كنت تستخدم --force --grace-period=0 فكل ما يفعله هو إزالة المرجع ... إذا قمت بإدخال العقدة ، فستظل تشاهد حاويات عامل التحميل.

في حالتي ، كان هناك نفاد الذاكرة على العقدة.
ونواة قتل cilium-agent الذي يبدو أنه يزعج إنهاء القرون.
لقد قمت للتو بإعادة تشغيل العقدة ومسحها.

في تجربتي ، يساعد sudo systemctl restart docker على العقدة (ولكن من الواضح أن هناك فترة تعطل).

ولا يزال هذا يحدث بشكل دوري على العقد العشوائية التي تكون إما A) قريبة من حدود الذاكرة أو B) تعطلت وحدة المعالجة المركزية (إما قبل الميلاد لبعض مشكلات kswapd0 والتي قد لا تزال متعلقة بالذاكرة أو التحميل الفعلي)

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

تتعفن المشكلات التي لا معنى لها بعد 30 يومًا من عدم النشاط.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .
يتم إغلاق المشكلات الفاسدة بعد 30 يومًا إضافيًا من عدم النشاط.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة حياة فاسدة

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

@ fejta-bot: إغلاق هذه القضية.

هذه مشكلة نشطة للغاية ، k8s 1.15.4 و RHEL Docker 1.13.1. تظل البودات طوال الوقت في Terminating ولكن الحاوية قد اختفت بالفعل ، ولا يمكن لـ k8s اكتشاف نفسها ، ولكنها تتطلب تفاعلًا بشريًا. يجعل اختبار البرمجة النصية الحقيقية بيتا.

/ إعادة الفتح
/ إزالة دورة الحياة فاسدة

tuminoid : لا يمكنك إعادة فتح قضية / العلاقات العامة إلا إذا قمت بتأليفها أو كنت متعاونًا.

/ إعادة الفتح
/ إزالة دورة الحياة فاسدة

mikesplain : أعيد فتح هذه القضية.

نفس الشيء هنا: البود عالق في مرحلة الإنهاء لأكثر من 19 دقيقة. تم إنهاء الحاوية بنجاح ، لكن Kubernetes ما زالت تعتقد أنها بحاجة إلى انتظار شيء ما ..

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

لا أحداث ولا سجلات ...

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

هل يمكنك التحقق من سجلات kubelet الخاصة بك ومعرفة ما إذا كانت هناك أية رسائل حول فشل تحميل وحدة التخزين أو البودات اليتيمة؟

لقد رأيت هذا أيضًا
تم العثور على E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] الجزء المعزول "0406c4bf-17e3-4613-a526-34e8a6cee208" ، ولكن مسارات الحجم لا تزال موجودة على القرص: كان هناك إجمالي 8 أخطاء مشابهة لهذا. احضر الإسهاب لرؤيتهم.

لقد رأيت ذلك أيضًا. لا يمكن التحقق من السجلات لأن kubectl يشكو من أنه لا يمكنه الاتصال بحاوية عامل الإرساء ولا يمكنه إنشاء جراب جديد بسبب الوجود الحالي لحجرة الإنهاء. مزعج بالأحرى.

تعاني من ذلك أيضًا ومن المزعج إلى حد ما أن تضطر إلى تأكيد ما إذا كان Kubernetes قد قام بتنظيف القرون القديمة بشكل صحيح أم لا.
نأمل أن يتم إصلاح هذا قريبًا.

وماذا عن هذه القضية؟ هل تم حلها؟ لدي نفس الشيء ، لكن هذا لا يحدث على الفور ، ولكن بعد مرور بعض الوقت على بدء العقدة ، إذا قمت بإعادة تعيين العقدة ، فكل شيء جيد لبعض الوقت

هل يمكنك التحقق مما إذا كانت هناك أدوات نهائية على الكبسولة تمنع حذفها؟

لا توجد نهائيات في البود الذي تم إصداره

لمعلوماتك لقد حللت هذا الأمر بقوة حذف باستخدام:

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

وأعتقد أن هذا نجح في إنهاء الكبسولة. منذ ذلك الحين لم أختبر المشكلة مرة أخرى. من المحتمل أن أكون قد قمت بالتحديث منذ ذلك الحين ، لذلك قد تكون مشكلة في الإصدار ، ولكن ليس بنسبة 100٪ منذ أن مر وقت طويل منذ أن رأيت المشكلة.

يحدث هذا لي عندما تنفد ذاكرة الكبسولة. لا ينتهي حتى ينخفض ​​استخدام الذاكرة مرة أخرى.

لمعلوماتك لقد حللت هذا الأمر بقوة حذف باستخدام:

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

وأعتقد أن هذا نجح في إنهاء الكبسولة. منذ ذلك الحين لم أختبر المشكلة مرة أخرى. من المحتمل أن أكون قد قمت بالتحديث منذ ذلك الحين ، لذلك قد تكون مشكلة في الإصدار ، ولكن ليس بنسبة 100٪ منذ أن مر وقت طويل منذ أن رأيت المشكلة.

هذا عمل معي

kubectl delete pods <pod> --grace-period=0 --force هو إصلاح مؤقت ، لا أريد تشغيل إصلاح يدوي في كل مرة يحدث فيها تجاوز فشل لأحد البودات المتأثرة. لا تنتهي قرون zookeeper الخاصة بي في minikube وعلى Azure AKS.

تحديث 9 مارس 2020
لقد استخدمت خطاف دورة حياة preStop لإنهاء القرون الخاصة بي يدويًا. كانت قرون حراس الحديقة الخاصة بي عالقة في حالة إنهاء ولن تستجيب لإشارة مصطلح من داخل الحاوية. كان لدي نفس البيان يعمل في مكان آخر وينتهي كل شيء بشكل صحيح ، ولا يوجد دليل على السبب الجذري.

نفس المشكلة ، مزعج للغاية

نفس المشكلة :( البودات عالقة في الإنهاء منذ 3 أيام

لمعلوماتك لقد حللت هذا الأمر بقوة حذف باستخدام:

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

وأعتقد أن هذا نجح في إنهاء الكبسولة. منذ ذلك الحين لم أختبر المشكلة مرة أخرى. من المحتمل أن أكون قد قمت بالتحديث منذ ذلك الحين ، لذلك قد تكون مشكلة في الإصدار ، ولكن ليس بنسبة 100٪ منذ أن مر وقت طويل منذ أن رأيت المشكلة.

أيضًا ، لا تعني العلامة --force بالضرورة إزالة البود ، فهي لا تنتظر التأكيد (وتسقط المرجع ، حسب فهمي). كما جاء في التحذير The resource may continue to run on the cluster indefinetely .

تحرير: لم أكن على علم. انظر تعليق elrok123s أدناه لمزيد من التحفيز.

لمعلوماتك لقد حللت هذا الأمر بقوة حذف باستخدام:

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

وأعتقد أن هذا نجح في إنهاء الكبسولة. منذ ذلك الحين لم أختبر المشكلة مرة أخرى. من المحتمل أن أكون قد قمت بالتحديث منذ ذلك الحين ، لذلك قد تكون مشكلة في الإصدار ، ولكن ليس بنسبة 100٪ منذ أن مر وقت طويل منذ أن رأيت المشكلة.

أيضًا ، لا تعني العلامة --force بالضرورة إزالة البود ، فهي لا تنتظر التأكيد (وتسقط المرجع ، حسب فهمي). كما جاء في التحذير The resource may continue to run on the cluster indefinetely .

صحيح ، لكن النقطة المهمة هي أن --grace-period=0 يفرض إجراء الحذف :) لست متأكدًا من سبب صلة تعليقك: /

أشعر أن تعليقه مناسب لأن الحاوية الأساسية
(عامل الإرساء أو أي شيء آخر) قد لا يزال قيد التشغيل ولم يتم حذفه بالكامل .. ، ملف
وهم "إزالتها" مضلل قليلاً في بعض الأحيان

يوم الخميس 4 يونيو 2020 الساعة 9:16 صباحًا ، كونر ستيفن مكابي <
[email protected]> كتب:

لمعلوماتك لقد حللت هذا الأمر بقوة حذف باستخدام:

kubectl حذف القرون- فترة السماح = 0 - القوة

وأعتقد أن هذا نجح في إنهاء الكبسولة. منذ ذلك الحين أنا
لم تواجه المشكلة مرة أخرى. ربما قمت بالتحديث منذ ذلك الحين ،
لذلك قد تكون مشكلة في الإصدار ، ولكن ليس بنسبة 100٪ منذ ذلك الحين منذ وقت طويل
لقد رأيت المشكلة.

أيضًا ، لا تعني علامة --force بالضرورة إزالة الكبسولة ، بل
فقط لا تنتظر التأكيد (ويسقط المرجع ، إلى
فهم). كما جاء في التحذير ، قد يستمر المورد في العمل
على الكتلة بشكل غير محدد.

صحيح ، لكن النقطة هي أن - فترة السماح = 0 تفرض الحذف
حدث :) لست متأكدًا من سبب أهمية تعليقك: /

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/51835#issuecomment-638840136 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAH34CDZF7EJRLAQD7OSH2DRU6NCRANCNFSM4DZKZ5VQ
.

هذا هو حقا وجهة نظري. يؤدي استخدام هذه الطريقة --force ترك الحمل الأساسي يثقل كاهل العقد ، ولا يؤدي بالضرورة إلى حل المشكلة الأصلية. في أسوأ الحالات ، يكون إصلاح "إذا لم أتمكن من رؤيته غير موجود" - والذي يمكن أن ينتهي به الأمر إلى صعوبة اكتشافه.

أم أنك تقول إن --grace-period=0 مضمون لفرض إزالة الحاوية الأساسية ، @ elrok123؟
إذا كانت هذه هي الحالة ، فإن تعليقي يستند إلى معرفة خاطئة وغير ذي صلة ، ولكن إذا ظل خطر ترك الحاويات قيد التشغيل عند استخدام --grace-period=0 فإن وجهة نظري كذلك.

oscarlofwenhamn على حد https://kubernetes.io/docs/concepts / workloads / pods / pod / # : ~: text = عندما تنتهي٪ 20the٪ 20grace٪ 20period٪ 20 ، الفترة٪ 200٪ 20 (الحذف الفوري٪ 20).) ، وإزالة البود بنجاح (قد لا يحدث فورًا ، ولكنه سيفعل يحدث.)

يذكر الدليل أنه يزيل المرجع ، لكنه لا يحذف البود نفسه (المصدر: "فرض الحذف" - https://kubernetes.io/docs/tasks/run-application/force-delete-stateful-set-pod/ ) ، ومع ذلك ، فإن فترة السماح = 0 يجب أن تؤثر بشكل فعال على حاسبك ، وإن لم يكن على الفور.

أنا أقرأ المستندات والطرق الموصى بها للتعامل مع السيناريو الذي واجهته. المشكلة التي واجهتها على وجه التحديد لم تكن مشكلة متكررة ، وشيء حدث مرة واحدة ؛ أعتقد أن الإصلاح الحقيقي لهذا هو إصلاح النشر الخاص بك ، ولكن حتى تصل إلى هناك ، يجب أن تساعدك هذه الطريقة.

@ elrok123 لامع - كنت حقا غير مطلعة. لقد قمت بتحديث ردي أعلاه ، مع الإشارة إلى هذا الشرح. نشكرك على الرد المفصل ، والطريقة الأخرى المحفزة للتعامل مع القرون المزعجة. في صحتك!

حاليًا بها حواجز عالقة لمدة يومين أو أكثر في حالة الإنهاء.

بالنسبة لي ، مساحة الاسم عالقة في Terminating . لم يتم سرد القرون. لا توجد خدمات ... لا شيء. مساحة الاسم فارغة. لا يزال ... عالق في الإنهاء.

JoseFMP استخدم kubectl لطلب yaml من مساحة الاسم ، فقد تحتوي على

تضمين التغريدة

لا يوجد نهائيات. لا يزال عالقًا Terminating

JoseFMP هنا نص برمجي بإزالته تمامًا) ، ما عليك سوى حفظه وتشغيله. / script_name:
""

! / بن / باش

مجموعة -Eo pipefail

يموت () {echo "$ *" 1> & 2 ؛ خروج 1 ؛ }

بحاجة إلى() {
الذي "$ 1" &> / dev / null || يموت "الثنائي '$ 1' مفقود ولكنه مطلوب"
}

التحقق من المتطلبات المسبقة

أحتاج "jq"
تحتاج "حليقة"
تحتاج "kubectl"

المشروع = "1 دولار"
تحول

اختبار -n "$ PROJECT" || الحجج المفقودة: kill-ns"

وكيل kubectl &> / dev / null &
PROXY_PID = دولار!
killproxy () {
اقتل PROXY_PID دولار
}
خروج فخ killproxy

sleep 1 # امنح الوكيل ثانية

kubectl احصل على مساحة الاسم "$ PROJECT" -o json | jq 'del (.spec.finalizers [] | حدد ("kubernetes"))' | curl -s -k -H "نوع المحتوى: تطبيق / json" -X PUT -o / dev / null --data-binary @ - http: // localhost : 8001 / api / v1 / namespaces / $ PROJECT / finalize && صدى "Killed namespace: $ PROJECT" ``

يبدو أنني واجهت هذا أيضًا ، مع توقف العديد من البودات في الإنهاء ، بما في ذلك جراب واحد لم يعد مرئيًا في أي مكان في البنية التحتية الخاصة بي ولكنه لا يزال يعمل كشبح (إنه يخدم الطلبات ويمكنني رؤية الطلبات يتم تقديمها حتى مع مقياس النشر من الصفر).

ليس لدي أي رؤية أو تحكم في هذا الكبسولة وأسأل كيف يفترض بي استكشاف موقف مثل هذا دون إغلاق جميع العقد بقوة؟

يبدو أنني واجهت هذا أيضًا ، مع توقف العديد من البودات في الإنهاء ، بما في ذلك جراب واحد لم يعد مرئيًا في أي مكان في البنية التحتية الخاصة بي ولكنه لا يزال يعمل كشبح (إنه يخدم الطلبات ويمكنني رؤية الطلبات يتم تقديمها حتى مع مقياس النشر من الصفر).

ليس لدي أي رؤية أو تحكم في هذا الكبسولة وأسأل كيف يفترض بي استكشاف موقف مثل هذا دون إغلاق جميع العقد بقوة؟

سيتعين عليك الوصول إلى عامل الإرساء على العقدة.
يمكنك استخدام dink (https://github.com/Agilicus/dink) والذي سيُحضر pod w / a shell w / docker access ، أو ssh إلى الحجرة.
docker ps -a
docker stop ####

حظا طيبا وفقك الله.

شكرا على الاتجاه.

تمكنت في النهاية من حل هذا الأمر ، لكنني ما زلت في حيرة من أمر كيف يمكن أن يحدث ذلك (بالنسبة لي ، كان الكبسولة غير مرئية تمامًا). كما كان الأمر في الإنتاج ، كانت الأمور محمومة بعض الشيء ولم أتمكن من إجراء التشخيص ، ولكن إذا حدث ذلك مرة أخرى ، آمل أن أتمكن من إعداد تقرير أفضل عن الأخطاء.

عند رؤية أعراض مماثلة ، فإن القرون عالقة في النهاية (من المثير للاهتمام أن لديهم جميعًا مسبارًا من نوع exec للاستعداد / الحيوية). بالنظر إلى السجلات التي يمكنني رؤيتها: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] مسبار الاستعداد لـ "test-service-74c4664d8d-58c96_default (822c3c3d-082a-4dc9-943c-19f04544713e): اختبار -خدمة "فشل (فشل): فشل تشغيل OCI exec: فشل exec: لا يمكن تنفيذ حاوية توقفت: غير معروف. تتكرر هذه الرسالة إلى الأبد ويبدو أن تغيير مسبار exec إلى tcpSocket يسمح بإنهاء الكبسولة (بناءً على اختبار ، سيتابعه). يبدو أن الحاوية تحتوي على إحدى الحاويات "قيد التشغيل" ولكنها ليست "جاهزة" ، وتظهر سجلات الحاوية "قيد التشغيل" كما لو تم إيقاف الخدمة.

يحدث هذا في الحاوية 1.4.0 عندما يكون حمل العقدة مرتفعًا ويتم تعيين vm.max_map_count على قيمة أعلى من القيمة الافتراضية ، ولا تستنزف الحاوية stdout fifo وتنتظر الكتل حتى يتم تصريفها ، بينما يفشل dockerd في تحديد قيمة حدث / إقرار من containerd بأن العمليات قد ولت.

discanto شكرا لتقاسم هذه المعلومات. هل يتم إصلاح المشكلة أو تعقبها؟

@ عشوائي ليو

تم فتح الخطأ لأكثر من 3 سنوات. قد يكون سبب توقف البودات عند الإنهاء مجموعة متنوعة من الأسباب. عند الإبلاغ عن حالتك ، سيكون من المفيد جدًا نشر بعض سجلات kubelet لمعرفة ما إذا كانت البودات عالقة.