@ kubernetes / sig-aws @ कुबेरनेट्स / सिग-शेड्यूलिंग

आमतौर पर वॉल्यूम और नेटवर्क क्लीनअप समाप्ति में अधिक समय लेते हैं। क्या आप पा सकते हैं कि आपकी फली किस चरण में है? उदाहरण के लिए वॉल्यूम सफाई?

आमतौर पर वॉल्यूम और नेटवर्क क्लीनअप समाप्ति में अधिक समय लेते हैं।

सही बात। वे हमेशा संदिग्ध होते हैं।

@igorleao आप kubectl delete pod xxx --now भी कोशिश कर सकते हैं।

Hi @resouer और @dixudx
मुझे यकीन नहीं है। एक ही समस्या के साथ एक अलग फली के लिए क्यूबलेट लॉग को देखते हुए, मैंने पाया:

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 एक वॉल्यूम के रूप में कॉन्फ़िगर करने में विफल रहा है।

@igorleao क्या यह प्रजनन योग्य है? या यह सिर्फ स्थिर नहीं है, कभी-कभार हो रहा है। मैं इस तरह की त्रुटियों से पहले मिला हूं, बस यह सुनिश्चित करने के लिए।

@dixudx यह दिन में कई बार एक निश्चित क्लस्टर के लिए होता है। कोप्स और कुबेरनेट्स के एक ही वर्स्टियन के साथ बनाए गए अन्य क्लस्टर, एक ही सप्ताह में, ठीक काम करते हैं।

@igorleao जैसा कि लॉग से पता चलता है कि वॉल्यूम प्रबंधक स्रावित निर्देशिका को हटाने में विफल रहा क्योंकि डिवाइस व्यस्त है।
क्या आप कृपया जाँच सकते हैं कि निर्देशिका /var/lib/kubelet/pods/GUID/volumes/kubernetes.io~secret/token-key अभी भी आरोहित है या नहीं? धन्यवाद!

@igorleao आप

हम समान व्यवहार देखते हैं। हम क्यूबलेट को कंटेनर के रूप में चलाते हैं और समस्या को आंशिक रूप से /var/lib/kubelet रूप में साझा करके (डिफ़ॉल्ट docker आरोह के रूप में आरएसएलवी द्वारा) बढ़ाकर आंशिक रूप से कम किया गया था। लेकिन फिर भी हम समान मुद्दों को देखते हैं, लेकिन कम लगातार। वर्तमान में मुझे संदेह है कि कुछ अन्य आरोह अलग तरीके से किए जाने चाहिए (जैसे /var/lib/docker या /rootfs )

@stormltf क्या आप कृपया अपना क्यूबलेट कंटेनर कॉन्फ़िगरेशन पोस्ट कर सकते हैं?

@stormltf आप कंटेनर में क्यूबलेट चला रहे हैं और --containerized फ्लैग का उपयोग नहीं करते हैं (जो माउंट के साथ कुछ ट्रिक्स करते हैं)। जिसका मूल रूप से मतलब है कि सभी माउंट क्यूबलेट कंटेनर माउंट नेमस्पेस में किए जाएंगे। अच्छी बात यह है कि उन्हें मशीन के नेमस्पेस होस्ट करने का प्रस्ताव दिया जाएगा (जैसा कि आपके पास / var / lib / kubelet साझा है), लेकिन मुझे यकीन नहीं है कि क्या होता है नेमस्पेस हटा दिया जाता है (जब क्यूबलेट कंटेनर हटा दिया जाता है)।

आप फली फली निम्नलिखित के लिए कृपया कर सकते हैं:

नोड पर जहां फली चल रही है

• docker exec -ti /kubelet /bin/bash -c "mount | grep STUCK_POD_UUID"
• और नोड पर ही mount | grep STUCK_POD_UUID ।

कृपया हौसले से बनाई गई फली के लिए भी ऐसा ही करें। मैं कुछ /var/lib/kubelet mounts (जैसे डिफ़ॉल्ट-गुप्त) देखने के लिए उत्साहित करता हूं

@stormltf पहले दो पॉड बनने के बाद आपने शुरू किया था?

@stormltf आप साझा के रूप में /var/lib/docker और /rootfs बनाने की कोशिश कर सकते हैं (जो कि मैं आपके docker निरीक्षण में नहीं देखता, लेकिन कंटेनर के अंदर देखता हूं) माउंटपॉइंट।

/ सिग भंडारण

कुछ के लिए यह मदद कर सकता है। हम --containerized ध्वज के साथ docker कंटेनर में क्यूबलेट चला रहे हैं और इस मुद्दे को साझा /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/ \

कुछ और जानकारी के लिए। यह समस्या को ठीक से हल नहीं करता है क्योंकि प्रत्येक बाँध माउंट के लिए आपको क्यूबलेट कंटेनर (2 परजीवी) के अंदर 3 माउंट मिलेंगे। लेकिन कम से कम साझा माउंट आसानी से एक शॉट के साथ उन्हें अनमाउंट करने की अनुमति देता है।

कोरोस में यह समस्या नहीं है। क्यूबेक कंटेनर के लिए रक और डॉकटर का उपयोग न करें। यदि हमारा केस डॉकटर में क्यूबलेट चलता है और क्यूबलेट महाद्वीप के अंदर प्रत्येक माउंट /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

मेरे पास एज़्योर पर कुबेरनेट्स 1.8.1 के साथ एक ही मुद्दा है - तैनाती में बदलाव के बाद और नई पॉड्स शुरू की गई हैं, पुरानी पॉड्स समाप्त होने पर अटक गई हैं।

आईबीएम क्लाउड पर कुबेरनेट्स 1.8.2 पर मेरा एक ही मुद्दा है। नई पॉड्स शुरू होने के बाद पुराने पॉड को समाप्त करने में फंस जाते हैं।

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

मैंने बिना किसी लाभ के kubectl delete pod xxx --now और kubectl delete pod foo --grace-period=0 --force उपयोग किया है।

यदि मूल कारण अभी भी समान (अनुचित रूप से प्रस्तावित माउंट) है तो यह विशिष्ट बग इमो वितरण है।

कृपया वर्णन करें कि आप आईबीएम क्लाउड में क्यूबलेट कैसे चलाते हैं? सिस्टमड यूनिट? क्या इसके पास --containerized झंडा है?

इसे झूठा सेट करने वाले ध्वज के साथ चलाया जाता है।

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

-संचालित ध्वज: नहीं

ठीक है, मुझे और जानकारी चाहिए, कृपया मेरी टिप्पणी https://github.com/kubernetes/kubernetes/issues/51835#issuecomment -333090349 के ऊपर

और कृपया /lib/systemd/system/kubelet.service की सामग्री दिखाएं और यदि /etc/systemd/system कृपया में क्यूबलेट के बारे में कुछ भी साझा करें।

पार्टिकल में, यदि क्यूबलेट docker में चलता है, तो मैं सभी बाइंड mounts -v देखना चाहता हूं।

आज मुझे एक समस्या का सामना करना पड़ा, जो एक वर्णित के समान हो सकती है, जहां हमारे पास हमारे ग्राहक प्रणालियों में से एक पर पॉड्स थे जो कई दिनों के लिए समाप्ति की स्थिति में फंस गए थे। हम "त्रुटि: UnmountVolume.TearDown वॉल्यूम के लिए विफल" के साथ "डिवाइस या संसाधन व्यस्त" प्रत्येक फंसे हुए फली के लिए दोहराया गया।

हमारे मामले में, यह RHEL / Centos 7.4 पर आधारित डकैती के साथ एक मुद्दा प्रतीत होता है, जो इस मोबिलिटी में शामिल हैं: https://github.com/moby/moby/issues/22260 और यह mob PR: https: github .com / मोबी / मोबी / पुल / 34,886 / फ़ाइलें

हमारे लिए, एक बार जब हम sysctl विकल्प सेट करते हैं fs.may_detach_mounts = 1 एक दो मिनट के भीतर हमारे सभी समाप्ति पॉड्स साफ हो जाते हैं।

मैं भी इस समस्या का सामना कर रहा हूं: पॉड्स 1.8.3 पर समाप्त होने की स्थिति में फंस गया।

प्रासंगिक क्यूबलेट नोड से लॉग करता है:

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"

क्यूबलेट उबंटू 16.04 पर सिस्टमड यूनिट (कंटेनर में नहीं) के रूप में चल रहा है।
जैसा कि आप देख सकते हैं, एनएफएस सर्वर के लिए एक माउंट था और किसी तरह क्यूबलेट ने माउंट निर्देशिका को हटाने की कोशिश की क्योंकि यह इस निर्देशिका को गैर-माउंटेड मानता है।

फली से वॉल्यूम कल्पना:

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

UPD : मैंने 1.6.6 पर भी इस समस्या का सामना किया

अजुरे पर ही प्रयोग ।।

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

फली नगीनेक्स -56ccc998dd-nnsvj का वर्णन करें

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

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

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

cat /etc/systemd/system/kubelet.service

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

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

[Install]
WantedBy=multi-user.target

लगता है कि मुद्दे से संबंधित विभिन्न बग हैं। हम दोनों हमारे 1.8.3 क्लस्टर पर हैं।

1. https://github.com/moby/moby/issues/31768 । यह docker बग है। Docker-Ce = 17.09.0 ~ Ce-0 ~ ubuntu पर प्रतिकारक।
2. दूसरा अधिक दिलचस्प है और शायद क्यूबलेट के अंदर कुछ दौड़ की स्थिति से संबंधित है।
   हमारे पास बहुत सारे पॉड हैं जो कंटेनर mounts में निर्दिष्ट सबपाथ के साथ NFS दृढ़ता मात्रा का उपयोग करते थे, उनमें से कुछ तैनाती को हटाने के बाद समाप्त होने वाली स्थिति में फंस रहे हैं। और syslog में बहुत सारे संदेश हैं:

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

और यह सच है कि निर्देशिका खाली नहीं है, यह बेशुमार है और इसमें हमारी "उपपथ" निर्देशिका है!
इस तरह के व्यवहार की व्याख्या में से एक:

1. P1: पॉड या सिंक पॉड बनाना शुरू करें
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 * वांछितStateOfWorldPopulator) findAndRemoveDeletedPods ()) आरंभिक मात्राएँ शुरू करें जबकि फली आरंभीकरण अवस्था में है:

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

एक ही समय में फली को हटाने और हटाने का कार्य चल रहा है।
बग के साथ दोहराने के लिए आपको शुरू करना चाहिए और तुरंत 10 तैनाती (एकल मिनियन के लिए परीक्षण) के बारे में हटाना / अपडेट करना चाहिए और शायद आपका माउंट ऑपरेशन बहुत तेज नहीं होना चाहिए।

GKE पर उसी बग से प्रभावित। क्या इस मुद्दे के लिए कोई ज्ञात समाधान हैं? --now काम नहीं चलता।

मेरे पास इस बग के लिए ठीक है, लेकिन मुझे यकीन नहीं है कि यह कुबेरनेट्स टीम द्वारा विलय कर दिया जाएगा।

@ ड्रेक क्या आप कृपया इस बग के बारे में और अधिक जानकारी प्रदान कर सकते हैं और आपकी फिक्स क्या है इसलिए स्टोरेज टीम देख सकती है? धन्यवाद!

@ gm42 मैं GKE द्वारा इस मुद्दे पर मैन्युअल रूप से काम करने में सक्षम था:

1. नोड में SSH अटक फली पर निर्धारित किया गया था
2. डॉकर कंटेनर आईडी प्राप्त करने के लिए docker ps | grep {pod name} चल रहा है
3. docker rm -f {container id} चल रहा है

जीकेई पर, उन्नयन नोड्स ने तुरंत मदद की।

मेरे स्थानीय क्लस्टर पर समान बग को 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
इसलिए जब क्‍यूबलेट पॉड को हटाता है, लेकिन यह आयतन को जारी नहीं कर सकता है, तो संदेश है:
उपकरण या संसाधन व्यस्त

कदम:
1) सुडो जर्नलक्टल -यू कुब्लेट
इस खोल ने मुझे त्रुटि का पता लगाने में मदद की,
2) सुडो डोकर निरीक्षण
io.kubernetes.pod.uid खोजें: "ddc66e10-0711-11e8-b905-6c92bf70b164"
तथा
HostConfig -> बंधन -> "/var/lib/kubelet/pods/ddc66e10-0711-11e8-b905-6c92bf70b164/volumes/kernernetes.io~secret/default-token-bnttf:/var/run/sun/sun .io / सेरी सीकाउंट: आरओ "

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

/ Proc / 90,225 / mountinfo
5) ps aux | grep 90225
रूट 90225 1.3 0.0 2837164 42580? Ssl Feb01 72:40 ./monitor_program

मेरे 1.7.2 पर एक ही बग है

OperationExecutor.UnmountVolume ने वॉल्यूम "डिफ़ॉल्ट-टोकन-bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11-118-b905/6c92bf70b164-default-token-bnttf") "ddc" "d66" के लिए शुरू किया। 6c92bf70b164 "क्यूबलेट [94382]: E0205 11: 35: 50.509169 94382 nestedpendingoperations.go: 262]" \ "kubernetes.io/secret/ddc66e10-0711-11e8-b905-6c92bff70706166166 के लिए ऑपरेशन "ddc66e10-0711-11-11e8-b905-6c92bf70b164 \") "विफल रहा। 2018-02-05 11: 37: 52.509148953 +0800 सीएसटी (अवधि सीमा 2 मी 2 एस) तक कोई भी अनुमति नहीं। त्रुटि: UnmountVolume.TearDown वॉल्यूम के लिए विफल "डिफ़ॉल्ट-टोकन- bnttf" (UniqueName: "kubernetes.io/secret/ddc66e10-0711-11-118-bb5-6c92bf70b164-default-token-bnttf") "dd" फली "dd" b905-6c92bf70b164 "(UID:" ddc66e10-0711-11-118-b905-6c92bf70b164 "): /var/lib/kubelet-pods/ddc66e10-0711-11-118-b905-69092f4704164x4704164" टोकन- bnttf: डिवाइस या संसाधन व्यस्त

डॉकटर सेवा को पुनः आरंभ करने से ताला बंद हो जाता है और कुछ ही मिनटों में फली निकल जाती है। यह एक बग है। डॉक 17.03 का उपयोग करना

यहाँ Azure, Kube 1.8.7 पर एक ही मुद्दा

कुछ मिनट पहले 1.8.9 पर भी हमारे पास आया था - कोई भी इसे हल करने के लिए देख रहा है? डॉकटर को फिर से शुरू करने में मदद मिलती है, लेकिन यह थोड़ा हास्यास्पद है।

यह GKE पर नवीनतम 1.9.4 रिलीज पर मेरे लिए बहुत कुछ हो रहा है। अभी के लिए यह कर रहा है:

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

यहाँ GKE 1.9.4-gke.1 पर समान समस्या
लगता है मात्रा mounts से संबंधित है।
यह हर बार फ़ाइलबीट के साथ होता है जैसा कि यहाँ वर्णित है:
https://github.com/elastic/beats/tree/master/deploy/kubernetes/filebeat

क्यूबलेट लॉग यह दिखाता है:

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
काम करने लगता है।
क्यूबलेट कार्यों को पुनः आरंभ करना भी।

यहाँ GKE 1.9.4-gke.1 पर समान समस्या
केवल एक विशिष्ट फ़ाइलबीट डेमोनसेट के साथ होता है, लेकिन सभी नोड्स को फिर से बनाना या तो मदद नहीं करता है, यह बस होता रहता है।

इसके अलावा GKE 1.9.4-gke.1 पर इस समस्या को टाल देना जैसे @Tapppi - मेजबान नोड पर डॉक डेमॉन से पॉड्स को हटा दिया गया था लेकिन kubernetes ने इसे TERMINATING में चिपका दिया था

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

हमारे लिए कुछ नया बस एक पल पहले हुआ था, जब मैंने kubectl delete pod NAME --grace-period=0 --force का उपयोग करके एक फली हुई फली को जबरन हटा दिया, जिस नोड पर यह पॉड बस अस्वस्थ था। हम डॉक 17-12CE चला रहे हैं, और उस बॉक्स पर docker deamon को फिर से शुरू करने और नोड को अनारक्षित करने में मदद कर रहे हैं।

1.9.4-gke.1 पर इस मुद्दे को देखने वाले लोगों के लिए, यह https://github.com/kubernetes/kubernetes/issues/61178 के कारण सबसे अधिक संभावना है, जो 1.9.5 में तय किया गया है और इसे GKE में रोल आउट किया जा रहा है इस सप्ताह। यह समस्या किसी फ़ाइल (किसी निर्देशिका नहीं) की सबपैथ माउंट्स की सफाई से संबंधित है। @zackify @ नोडफैक्ट्री-बीके @ टप्प्पी @Stono

IIUC, इस बग में मूल समस्या कंटेनरीकृत क्यूबलेट के विन्यास से संबंधित है, जो अलग है।

BTW, v1.9.3-gke.0 संस्करण के साथ एक नया नोड पूल बना रहा था, इसके लिए हमारा वर्कअराउंड था, क्योंकि v1.9.5 अभी भी gke पर रोल आउट नहीं हुआ है और यह पहले से ही ईस्टर है।

क्या कोई पुष्टि कर सकता है कि यह संस्करण 1.9.3+ में तय किया गया है? इस व्यवहार के कारण हमें कुछ गंभीर परेशानी हो रही है, और प्रत्येक बार ऐसा होने पर docker को पुनः आरंभ करना soo st00pid है।

मेरे लिए 1.9.6 पर फिक्स्ड

बुध पर, ४ अप्रैल २०१ 201, ११:४३ सुबह का समय है, सूचनाएं @github.com ने लिखा है:

क्या कोई पुष्टि कर सकता है कि यह संस्करण 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

@ सोंटो जो

मुझे आज भी 1.9.6 पर Azure AKS प्रबंधित क्लस्टर में यह समस्या आ रही है।

इस समय इस वर्कअराउंड का उपयोग करके सभी अटकी हुई फली का चयन करें और उन्हें हटा दें (जैसा कि मैं अंत में अपने देव / खरोंच क्लस्टर में फली को खत्म करने की कसम खा रहा हूं):

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

Azure और AWS दोनों समूहों में इस पर भाग गया - माइक इलियट द्वारा समाधान प्रदान किया गया

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

ubuntu @ ip-10-0-0-22 : ~ $ kubectl पॉड्स-all-namespaces मिलता है
NAMESPACE का नाम याद रखें स्टेटेस्ट रेस्टार्ट्स एज
क्यूब-सिस्टम हैपस्टर -76b8cd7b5-4r88h 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम क्यूब-डीएनएस -५ डी c बी ४४99 सी-एस ४ एसआरजी ३/३ रनिंग ० २५ डी
क्यूब-सिस्टम कुबेरनेट्स-डैशबोर्ड-f9577fffd-298r6 1/1 रनिंग 0 25d
क्यूब-सिस्टम मॉनिटरिंग-ग्राफाना -997796fcf-wtz7n 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम मॉनिटरिंग-इनफ्लक्सडब -56 एफडीसीडी 96 बी -2 एफडी 2 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम टिलर-तैनाती-cc96d4f6b-jzqmz 1/1 रनिंग 0 25 डी
ओनप देव-एस.एम.एस.-f५f एफ ६ डीबीडी p-पीडी ५s ० / १ टर्मिनेटिंग ० ३ एच
ओणप देव-वीएफसी-ज़ेट-एसडीएनसी-ड्राइवर -५ बी ६ सी-सी 6 बीडी ६ बी -५ डीवीडीपी ० / १ टर्मिनेटिंग ० ३ एच
ubuntu @ ip-10-0-0-22 : ~ $ kubectl पॉड देव-vfc-zte-sdnc-ड्राइवर -5b6c7cbd6b-5vdvp -n ओनैप - मूल्य-अवधि = 0 --force हटाएं
चेतावनी: तत्काल विलोपन पुष्टि के लिए प्रतीक्षा नहीं करता है कि चल रहे संसाधन को समाप्त कर दिया गया है। संसाधन अनिश्चित काल तक क्लस्टर पर चलता रह सकता है।
फली "dev-vfc-zte-sdnc-driver-5b6c7cbd6b-5vdvp" हटाया गया
ubuntu @ ip-10-0-0-22 : ~ $ kubectl पॉड्स-all-namespaces मिलता है
NAMESPACE का नाम याद रखें STATUS रेस्टार्ट एज
क्यूब-सिस्टम हैपस्टर -76b8cd7b5-4r88h 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम क्यूब-डीएनएस -५ डी c बी ४४99 सी-एस ४ एसआरजी ३/३ रनिंग ० २५ डी
क्यूब-सिस्टम कुबेरनेट्स-डैशबोर्ड-f9577fffd-298r6 1/1 रनिंग 0 25d
क्यूब-सिस्टम मॉनिटरिंग-ग्राफाना -997796fcf-wtz7n 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम मॉनिटरिंग-इनफ्लक्सडब -56 एफडीसीडी 96 बी -2 एफडी 2 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम टिलर-तैनाती-cc96d4f6b-jzqmz 1/1 रनिंग 0 25 डी
ओनप देव-एस.एम.एस.-f५f एफ ६ डीबीडी p-पीडी ५/ ० / १ समाप्त ० ३ एच
ubuntu @ ip-10-0-0-22 : ~ $ kubectl पॉड देव-sms-857f6dbd87-pds58 -n onap --grace-period = 0 --force हटाएं
चेतावनी: तत्काल विलोपन पुष्टि के लिए प्रतीक्षा नहीं करता है कि चल रहे संसाधन को समाप्त कर दिया गया है। संसाधन अनिश्चित काल तक क्लस्टर पर चलता रह सकता है।
पॉड "dev-sms-857f6dbd87-pds58" हटाया गया
ubuntu @ ip-10-0-0-22 : ~ $ kubectl पॉड्स-all-namespaces मिलता है
NAMESPACE का नाम याद रखें STATUS रेस्टार्ट एज
क्यूब-सिस्टम हैपस्टर -76b8cd7b5-4r88h 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम क्यूब-डीएनएस -५ डी c बी ४४99 सी-एस ४ एसआरजी ३/३ रनिंग ० २५ डी
क्यूब-सिस्टम कुबेरनेट्स-डैशबोर्ड-f9577fffd-298r6 1/1 रनिंग 0 25d
क्यूब-सिस्टम मॉनिटरिंग-ग्राफाना -997796fcf-wtz7n 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम मॉनिटरिंग-इनफ्लक्सडब -56 एफडीसीडी 96 बी -2 एफडी 2 1/1 रनिंग 0 25 डी
क्यूब-सिस्टम टिलर-तैनाती-cc96d4f6b-jzqmz 1/1 रनिंग 0 25 डी

मुझे यकीन नहीं है कि यह एक ही मुद्दा है, लेकिन हमने इस व्यवहार को नोट करना शुरू कर दिया है _since_ 1.9.3 से 10.10.1 तक अपग्रेड करना। उससे पहले ऐसा कभी नहीं हुआ। हम सबपाथ के साथ चमकता हुआ वॉल्यूम उपयोग कर रहे हैं। क्यूबलेट लगातार चीजों को लॉग करता है

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

और lsof वास्तव में दिखाता है कि glusterfs वॉल्यूम के तहत निर्देशिका अभी भी उपयोग में है:

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

यह 1.9.3 पर सब ठीक था, इसलिए यह ऐसा है जैसे इस मुद्दे के लिए हमारे उपयोग के मामले को ठीक कर दिया गया है :(

@ ross-w यह हस्ताक्षर दूसरों से अलग दिखता है। क्या आप एक नया मुद्दा खोल सकते हैं और अपनी पॉड युक्ति भी शामिल कर सकते हैं?

इन मुद्दों पर कोई अपडेट?
हमारे मामले में (कुबेरनेट्स 1.9.7, डॉक 17.03), फली की स्थिति समाप्त हो रही है, नोड के बाद स्मृति से बाहर चला जाता है और फली पुनर्निर्धारित की जाती है। आखिरकार कुबेरनेट्स डैशबोर्ड में भूत की एक बहुत कुछ है और तैनाती टैब में, हम 4/1 पॉड्स के साथ तैनाती देख सकते हैं।
क्यूबलेट को फिर से शुरू करने या नेमस्पेस में सभी पॉड्स को मारने से मदद मिलती है, लेकिन यह बहुत खराब समाधान है।

@ Aqqq इसके लिए यह समस्या थी कि

अपने नोड में से किसी एक पर journalctl -u kubelet -f लुक रखें। मुझे एक संदेश मिला था, 'कंटेनर नहीं मार सकताgRpc त्रुटि "(मैंने यह तय करने के बाद से वास्तविक संदेश नहीं दिया है)।

यह तय करने के लिए कि मैंने प्रत्येक नोट पर do पुनः आरंभ किया है। एक टूटी हुई अवस्था में डॉकटर को साफ करने के लिए बूट करने के दौरान और इस सभी बासी फली को हटा दें।

मेरे पास कल 1.9.7 में यह था, एक फली को समाप्त करने की स्थिति में फँस गया और लॉग में बस "फली को मारने की जरूरत थी", मुझे छुटकारा पाने के लिए --force --grace-period=0 होना पड़ा।

बस 1.9.7-gke.0 के साथ यह अस्वस्थ हो गया।
1.9.6-gke.1 के साथ कोई समस्या नहीं थी।
लेकिन 1.9.4 और 1.9.5 के साथ किया था

फली हो रही एक पीवी संलग्न है।

फली को हटाने या हटाने का समान प्रभाव पड़ता है।
आक्रामक नोड पर क्यूबलेट को फिर से शुरू करने से काम नहीं चला। क्यूबलेट फिर से शुरू नहीं हुआ और मुझे पूरे नोड को पुनः आरंभ करना पड़ा।

इस दौरान पॉड को किसी अन्य नोड पर शेड्यूल नहीं किया जा सकता था क्योंकि यह कहा गया था कि पीवी पहले से ही कहीं और घुड़सवार था।

@Stono @ नोडफैक्ट्री-बीके क्या आप लोग अपने क्यूबलेट लॉग्स को आपत्तिजनक नोड्स पर देख सकते हैं, यह देखने के लिए कि क्या कोई विस्तृत लॉग हैं जो समस्या को इंगित कर सकते हैं?

cc @dashpole

बस एक ऐप ख़त्म होने में अटक गया था।
यह 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

निश्चित नहीं है कि गोगल्स इमेजेस पर gke में kubelet.log कहां मिलेगी। कुछ ऐसा मिला जिसे मैं अटैच कर रहा हूं।
kube.log

kubectl -n shsp-cloud-dev delete pod sharespine-cloud-6b78cbfb8d-xcbh5 --force --grace-period 0
इसे मार दिया और इसे हटा दिया।
इसके बाद ठीक होने लगा लेकिन सामान्य से थोड़ा अधिक समय लगा।

ध्यान रहे, यह उस ऐप के लिए हर बार नहीं होता है।
मैं शायद लगभग 1/4 बार कहूंगा।

K8s 1.9.6 के साथ इसे मारना, जब क्यूबलेट सेफहॉफ माउंट करने में असमर्थ है, नोड पर सभी पॉड्स हमेशा के लिए समाप्त हो जाते हैं। पुनर्प्राप्त करने के लिए नोड को पुनरारंभ करना पड़ा, क्यूबलेट या डोकर पुनरारंभ ने मदद नहीं की।

@tuminoid ceph समस्या अलग लगती है। क्या आप एक नया मुद्दा खोल सकते हैं और उस पॉड के लिए पॉड इवेंट और क्यूबलेट लॉग भी प्रदान कर सकते हैं?

FYI करें, मेरे समूहों को अपडेट करना (k8s v1.10.2 को) लगता है कि यह समस्या हमारे लिए समाप्त हो गई है।

संलग्न ने मेरे लिए gke पर इसे पुन: पेश किया

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

k8s-NFS-test.yaml.txt

इसे चलाएं, फिर इसे हटाएं। आपको 'nfs-client' हटाने में अटक जाएगा। इसका कारण नोड पर हार्ड माउंट है, और 'सर्वर' को पहले हटा दिया जाता है।

जब आप पहले nfs सर्वर को हटाते हैं तो nfs अनमाउंट समस्या के लिए @donbowman , आप StorageClass या PV में "सॉफ्ट" माउंट विकल्प सेट कर सकते हैं।

मैं नहीं देखता कि कैसे? मैं इसे एक PersistentVolumeClaim पर सेट कर सकता हूं, लेकिन यह यहां लागू नहीं होता है।
मुझे नहीं लगता कि StorageClass यहां लागू होता है (जो कि अंडर-डिस्क होगा, nfs सर्वर के नीचे)।

यह मुद्दा nfs- क्लाइंट पर है।
क्या मैं कुछ भूल रहा हूँ?

अपने nfs PV के लिए, आप एक सॉफ्ट माउंट निर्दिष्ट करने के लिए 1.8 में शुरू होने वाले माउंटऑन फील्ड्स सेट कर सकते हैं। यदि आप गतिशील रूप से एनएफ़एस संस्करणों का प्रावधान करते हैं, तो आप इसे अपने StorageClass.mountOptions में भी सेट कर सकते हैं

हाँ, लेकिन इसका पीवी नहीं है जिसे डब्ल्यू / एनएफएस लगाया जा रहा है।
मेरे एनएफएस-सर्वर कंटेनर से इसकी।
कोई गतिशील प्रावधान नहीं है।

यह Google GCP + GKE का उपयोग कर रहा है। पीवीसी एक पीवी का चयन करता है जो कि ब्लॉक IO है, जिसे ext4 के रूप में एक कंटेनर में रखा गया है जो इसे NFS के साथ फिर से निर्यात करता है।

कंटेनरों का दूसरा सेट, जो एनएफएस-सर्वर (जो स्वयं एक पॉड है) से माउंट होता है, वे इसे पीवी के रूप में नहीं देखते हैं। वे इसे नीचे की तरह एक मात्रा के रूप में देखते हैं।

मुझे इस nfs-client को माउंट के लिए '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: /

कंटेनर के अपने 2 सेट के लिए

कुछ इस तरह:

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

धन्यवाद! इस तरह काम किया (इस अर्थ में अब यह एक नरम-माउंट है) लेकिन समस्या को ठीक नहीं करता है:

माउंट (नोड पर देखा गया) अब नरम है:

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

लेकिन जब मैं पूरी चीज को हटा देता हूं, तब भी मैं nfs-client को हमेशा के लिए समाप्त करने की स्थिति में फंस जाता हूं।

k8s-NFS-test.yaml.txt

संलग्न yaml मैं इस्तेमाल किया है। मैंने एक 'क्रिएट' किया, इसके आने का इंतजार किया, देखा कि क्लाइंट के पास माउंट था, उसमें फाइलें पढ़ / लिख सकता था, फिर उस पर 'डिलीट' किया।

Nfs-server पॉड को हटा दिया जाता है, लेकिन nfs-client नहीं है।

फली को देखते हुए, माउंट बना हुआ है:

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

@donbowman आह बहुत खेद है, मैं नरम विकल्प के बारे में गलत था। नरम विकल्प केवल सर्वर के अप्राप्य होने पर फाइलसिस्टम कॉल को लटकने से रोकता है, लेकिन वास्तव में nfs मात्रा को अनमाउंट करने में मदद नहीं करता है। इसके लिए एक बल की आवश्यकता होगी, जिसे वर्तमान में हमारे पास से गुजरने का कोई रास्ता नहीं है। अभी के लिए, आपको उन माउंट्स को मैन्युअल रूप से साफ़ करना होगा और यह सुनिश्चित करना होगा कि आप अपने पॉड्स को सही क्रम में हटा दें (nfs क्लाइंट पहले, फिर nfs सर्वर)।

मैं timeo = 30 और intr जोड़ने की कोशिश की, लेकिन एक ही मुद्दा।
यह लॉक करता है, नोड में लॉग इन करना चाहिए और अंतर्निहित माउंट पर एक umount -f -l करना चाहिए और फिर पॉड पर एक kubectl delete --force --grace-period 0 कर सकते हैं।

ऐसा लगता है जैसे यह फली की ओर से लगाया गया था कि यह स्वचालित रूप से हटाने पर कुछ समय के बाद 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 के नए फ़ाइलस्टोर के साथ हमारे पास एक ही मुद्दा होगा, कोई umount नहीं।

@donbowman iirc, आपका मुद्दा है क्योंकि आप nfs क्लाइंट पॉड से पहले nfs सर्वर पॉड को समाप्त कर रहे थे। यदि आप फाइलस्टोर का उपयोग करते हैं, तो आपको अपने nfs सर्वर को होस्ट करने के लिए किसी पॉड की आवश्यकता नहीं है, इसलिए आपको यह समस्या तब तक नहीं होनी चाहिए जब तक कि आप पूरे फायरस्टार के आइंटेंस को हटा नहीं देते।

मैं एक ही मुद्दा नहीं है अगर मैं filestore थियो orchestrating हूँ? उदाहरण के लिए, अगर मैं इसे एक विशिष्ट कुबेरनेट तैनाती के लिए ला रहा हूं, और फिर अंत में, आदेश की गारंटी नहीं है।

लेकिन यह भी मुझे लगता है कि मुद्दा सिर्फ आदेश नहीं है, nfs क्लाइंट पॉड डिलीट umount बिल्कुल नहीं है, यह सिर्फ नोड पर माउंट झूलने छोड़ देता है। तो इस बात की परवाह किए बिना कि फाइलस्टार / सर्वर मौजूद है या नहीं, एक झूलने वाला माउंट है।

जब एक फली समाप्त हो जाती है, तो हम वॉल्यूम को अनमाउंट करते हैं (यह मानते हुए कि सर्वर अभी भी है)। यदि आप सर्वर के मौजूद होने पर भी लटकते हुए माउंट को देख रहे हैं, तो यह एक बग है।

यदि आप PVCs और PVs के साथ डायनेमिक प्रोविज़निंग का उपयोग करते हैं, तो हम PVC (और अंतर्निहित स्टोरेज) को तब तक हटाने की अनुमति नहीं देते हैं जब तक कि सभी पॉड्स संदर्भित नहीं करते हैं कि इसका उपयोग किया जाता है। यदि आप प्रावधान को स्वयं को ऑर्केस्ट्रेट करना चाहते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि आप सर्वर को तब तक न हटाएं जब तक कि सभी पॉड्स इसका उपयोग न करें।

शायद यह एक संभावित समाधान है: # 65936

हटाए जाने को मजबूर करने के लिए kubectl delete po $pod --grace-period=0 --force । --now ध्वज काम नहीं कर रहा था। मुझे # 65936 के बारे में निश्चित नहीं है, लेकिन मैं Unknown राज्यों होने पर नोड को नहीं मारना चाहूंगा।

एक ही समस्या होने के कारण (पॉड समाप्त होने में रहता है क्योंकि फली के भीतर कोई फ़ाइल अनमाउंट नहीं की जा सकती क्योंकि डिवाइस 1.10.5 पर 'व्यस्त' है)। मेरे लिए --grace-period=0 --force का उपयोग करने से माउंटपोन का अस्तित्व बना रहेगा। आखिरकार मैं 90000 से अधिक माउंटपॉइंट के साथ समाप्त हो गया, जो क्लस्टर को गंभीर रूप से धीमा कर देता है। यहां वर्कअराउंड पॉड के फोल्डर में एक खोज करना है और उन फाइलों को पुन: असंबद्ध करना है, फिर पॉड फोल्डर को पुन: हटा देना है।
मेरे मामले में, मैं मौजूदा फ़ाइलों के साथ एक मौजूदा फ़ोल्डर में उपपथ का उपयोग करके एक कॉन्फ़िगरमैप को बढ़ा रहा हूं, मौजूदा फ़ाइलों में से एक को अधिलेखित कर रहा हूं। यह मेरे लिए 1.8.6 पर ठीक काम करता था।
मूल पोस्टर में पॉड्स के कुछ घंटों के लिए 'समाप्त' होने का उल्लेख है, मेरे मामले में यह दिन है। मैंने देखा नहीं है कि आखिरकार उन्हें सफाई मिलती है, जब मैं मैनुअल वर्कअराउंड करता हूं।

लॉग एग्रीगेटर (फ्लुएंट के समान) के कारण होने वाली एक ही समस्या होने पर, यह /var/lib/docker/containers फोल्डर और पॉड में बहुत सारे mounts करता है:

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

मेरे मामले में कुबेरनेट्स द्वारा कुछ फली को अच्छी तरह से हटाया जा सकता है, लेकिन कुछ "समाप्त" स्थिति में फंस गए हैं।

यह https://github.com/kubernetes/kubernetes/issues/45688 से संबंधित हो सकता है (मैं docker 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

अभी भी फली लटकी हुई है और इसके कारण संबंधित तैनाती भी अटक जाती है।

मैं भी इन "फली को मारने की जरूरत है" पॉड घटनाओं में संदेश द्वारा प्रेतवाधित हूँ। इस तरह से क्या मतलब है? कि _Kubernetes_ को फली को मारने की आवश्यकता महसूस होती है, या कि _I_ को फली को मारना चाहिए?

यह मेरे साथ कुछ दिन पहले हुआ था और मैंने इसे हटा दिया और इसे छोड़ दिया। फिर आज, यह गायब हो गया था और अंततः नष्ट हो गया लगता है।

अभी मेरे पास आया। Theforce --now समाधान मेरे लिए काम नहीं किया। मुझे क्यूबलेट लॉग में निम्नलिखित पंक्ति संदिग्ध लगी

अगस्त 6 15:25:37 क्यूब-मिनियन -1 क्यूबलेट [2778]: W0806 15: 25: 37.986549 2778 docker_sandbox.go: 263] NetworkPlugin cni फली के लिए स्थिति हुक पर विफल "बैकेंड-फोस-227474871-gzhw0_default यूनिका। कमांड आउटपुट nsenter: नहीं खुल सकता: ऐसी कोई फ़ाइल या निर्देशिका नहीं

जिसके कारण मुझे निम्नलिखित समस्या का पता चला:
https://github.com/openshift/origin/issues/15802

मैं ओपनशफ्ट पर नहीं हूं लेकिन ओपनस्टैक पर हूं, इसलिए मुझे लगा कि यह संबंधित हो सकता है। मैंने एक शॉट को पुनः आरंभ करने की सलाह दी।
पुनः आरंभ करने वाले डॉक ने "समाप्ति" में फंसे फली को हटा दिया।

मुझे पता है कि यह केवल एक काम-काज है, लेकिन मैं इसे ठीक करने के लिए कभी-कभी 3 बजे भी नहीं उठता।
यह कहते हुए कि आपको इसका उपयोग नहीं करना चाहिए, लेकिन यह कुछ लोगों की मदद कर सकता है।

नींद है जो मैं अपने फली समाप्ति हैग्रेसपेरियोडसेकंड (30 सेकंड) के लिए सेट है। यदि इससे अधिक समय तक जीवित रहता है, तो यह क्रोनजॉब --फोर्स -ग्रेस-पीरियड = 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"

मैं मैन्युअल रूप से शिकायत के बिना उपपथ मात्रा को अनमाउंट कर सकता हूं (लिनक्स मुझे नहीं बताता कि यह व्यस्त है)। यह त्रुटि संदेश को लॉग करने से क्यूबलेट को रोकता है। हालांकि, यह कुबेरनेट्स को सफाई जारी रखने के लिए प्रेरित नहीं करता है, क्योंकि फली को अभी भी समाप्त करने की स्थिति में दिखाया गया है। नियमित रूप से इसे साफ करने के लिए डॉकर को पुनः आरंभ करना वास्तव में एक स्वीकार्य समाधान नहीं है क्योंकि विघटन के कारण यह चलने वाले कंटेनरों का कारण बनता है।

नोट का भी: कंटेनर खुद बिना किसी सबूत के docker ps -a से चला गया है कि यह कभी अस्तित्व में था, इसलिए मुझे यकीन नहीं है कि यह वास्तव में डॉकटर मुद्दा है। हम डॉकर संस्करण 17.03.2-CE का उपयोग कर रहे हैं।

एक अपडेट: हमने अपने नोड्स को क्यूबलेट रूट डायरेक्टरी को एक गैर-ओएस वॉल्यूम के लिए एक सिम्लिंक ( /var/lib/kubelet एक सिम्लिंक एक अलग वॉल्यूम पर दूसरी निर्देशिका की ओर इशारा करते हुए) के साथ पुनर्निर्देशित किया था। जब मैंने क्यूबलेट में --root-dir पास करने के लिए चीजों को फिर से जोड़ दिया ताकि यह एक सिम्लिंक के बजाय सीधे वांछित निर्देशिका में जाए, और क्यूबलेट को फिर से शुरू किया, इसने वॉल्यूम माउंट को साफ किया और फली को साफ कर दिया जो फंसे थे डॉकर रिस्टार्ट की आवश्यकता के बिना समाप्त करना।

मैंने आज पहली बार इस मुद्दे का अनुभव किया, जबकि मिनीक्यूब पर स्थानीय स्तर पर कुछ पॉड्स चला रहा था।

मेरे पास एक पॉम्पमैप / गुप्त माउंट के कारण Terminating में फली का एक गुच्छा था जो गायब था। इस पोस्ट को छोड़कर ऊपर दिए गए किसी भी सुझाव / समाधान / समाधान पर काम नहीं किया गया।

एक चीज जो मुझे लगता है कि नोटिस के लायक है, हालांकि निम्नलिखित है:

• जब मैंने kubectl get pods भाग लिया, तो मुझे Terminating स्थिति के साथ पॉड्स की सूची मिली।
• जब मैंने docker ps | grep -i {{pod_name}} भाग लिया, तब भी Terminating स्थिति में कोई भी पोड kubectl get pods minikube VM में चल रहा था।

मैं Terminating अटक docker ps उम्मीद कर रहा था, लेकिन वास्तव में उनमें से कोई भी नहीं चल रहा था, फिर भी kubectl get pods उनके बारे में डेटा वापस कर रहा था? क्या कोई समझा पाएगा कि ऐसा क्यों है?

मैंने 4 तैनाती के साथ इस मुद्दे का अनुभव किया। फिर मैंने सभी आरोहियों के लिए "स्थानीय मात्रा" से "मेजबान पथ" पर स्विच किया, और यह मेरे लिए चला गया।

मुझे सिर्फ यह समस्या थी कि फली ख़त्म नहीं हो रही थी क्योंकि एक रहस्य गायब था। मैंने उस नामस्थान में उस रहस्य को बनाने के बाद सब कुछ वापस सामान्य हो गया था।

यदि नामस्थान "समाप्ति" स्थिति में है, तो आप नामस्थान में एक रहस्य कैसे बनाते हैं?

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

मेरे लिये कार्य करता है।

"- ग्रेस-अवधि = 0" के बारे में मत भूलना। यह मायने रखता है

kubectl ने मुझे चेतावनी दी "चेतावनी: तत्काल विलोपन पुष्टि की प्रतीक्षा नहीं करता है कि चल रहे संसाधन को समाप्त कर दिया गया है। संसाधन अनिश्चित काल तक क्लस्टर पर चलता रह सकता है।" जब मैं --force --grace-period=0 उपयोग करता हूं।
क्या कोई मुझे बता सकता है कि क्या यह वास्तव में होगा?

वास्तव में, जब हम कुछ फली को हटाते हैं, तो कुछ कारणों से हटाने में देरी हो सकती है,
और अगर हम "झंडे के साथ" कुबेटेल डिलीट "निष्पादित करते हैं - प्रवर्तन - अनुग्रह-अवधि = 0",
संसाधन ऑब्जेक्ट को एक ही बार में हटा दिया जाएगा।

क्या आप यह पुष्टि करने में मदद कर सकते हैं कि क्या फली को तुरंत हटा दिया जाएगा?
क्या इसका मतलब यह था कि चेतावनी संदेश वास्तव में गलत है?

@ रिडोज़ , यदि आप --force --grace-period = 0 विकल्प है, तो इसका मतलब है कि फली एपीआई ऑब्जेक्ट एपीआई सर्वर से तुरंत हटा दिया जाएगा। नोड क्यूबलेट वॉल्यूम माउंट्स को साफ करने और कंटेनरों को मारने के लिए जिम्मेदार है। यदि फली की सफाई के दौरान क्यूबलेट नहीं चल रहा है या समस्या है, तो कंटेनर अभी भी चल सकता है। लेकिन क्यूबलेट को जब भी संभव हो फली को साफ करने की कोशिश करते रहना चाहिए।

ताकि अभी भी इसका मतलब है कि विलोपन हमेशा के लिए हो सकता है क्योंकि क्यूबलेट की खराबी हो सकती है?
क्या यह सुनिश्चित करने का कोई तरीका है कि फली को हटा दिया जाए?
मैं सवाल पूछ रहा हूं क्योंकि मैं क्लस्टर में कुछ विशाल पॉड्स चला रहा हूं और उनमें से 2 उदाहरणों को चलाने के लिए प्रत्येक नोड पर पर्याप्त मेमोरी नहीं है।
यदि विलोपन विफल हो गया, तो नोड अनुपयोगी हो जाता है, और यदि यह समस्या कई बार हो रही है, तो सेवा पूरी तरह से डाउन हो जाएगी क्योंकि अंततः कोई नोड नहीं होगा इस पॉड को चला सकते हैं।

सादे-एन-पुराने डॉकटर वातावरण में मैं kill -9 या कुछ के साथ एक फली को मारने के लिए मजबूर कर सकता हूं, लेकिन ऐसा लगता है कि k8s में ऐसा फ़ंक्शन नहीं है।

@ इसके

ऐसी स्थिति मेरे क्लस्टर पर कई महीने पहले हुई थी, क्यूबलेट चल रहा था लेकिन डॉकटर डेमन को कुछ परेशानी हुई और बिना किसी त्रुटि लॉग के अटक गया।
मेरा समाधान नोड में लॉग इन करना था और कंटेनर प्रक्रिया को मारना और डोकर डेमॉन को फिर से शुरू करना था।
कुछ अपग्रेड के बाद यह समस्या दूर हो गई थी और मैंने इसे फिर कभी नहीं किया।

kubectl delete pods <podname> --force --grace-period=0 मेरे लिए काम किया!

@ चमकबयार-जी, --force साथ समस्या यह है कि इसका मतलब यह हो सकता है कि आपका कंटेनर चालू रहेगा। यह सिर्फ कुबेरनेट्स को इस फली के कंटेनर के बारे में भूल जाने के लिए कहता है। एक बेहतर समाधान एसएसएच में फली चलाने वाले वीएम में है और जांच करें कि डॉकर के साथ क्या हो रहा है। कंटेनर को docker kill साथ मैन्युअल रूप से मारने का प्रयास करें और यदि सफल हो, तो फली को सामान्य रूप से फिर से हटाने का प्रयास करें।

@agolomoodysaada आह, यह समझ में आता है। स्पष्टीकरण के लिए धन्यवाद। इसलिए मुझे वास्तव में नहीं पता होगा कि वास्तविक कंटेनर वास्तव में हटा दिया गया है या सही नहीं है?

इसलिए, यह 2018 का अंत है, क्यूब 1.12 बाहर है और ... आप सभी को अभी भी फली हुई फली के साथ समस्या है?

मेरे पास एक ही मुद्दा है, या तो --फोर्स -ग्रेस-पीरियड = 0 या --फोर्स --नहीं काम करता है, निम्नलिखित लॉग हैं:

रूट @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat पॉड नोड-निर्यातक-zbfpx प्राप्त करें
NAD READY STATUS RESTARTS AGE
नोड-निर्यातक-zbfpx 0/1 समाप्ति 0 4d

रूट @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat डिलीट पॉड नोड-निर्यातक-zbfpx --grace-period = 0 --force
चेतावनी: तत्काल विलोपन पुष्टि के लिए प्रतीक्षा नहीं करता है कि चल रहे संसाधन को समाप्त कर दिया गया है। संसाधन अनिश्चित काल तक क्लस्टर पर चलता रह सकता है।
पॉड "नोड-निर्यातक-zbfpx" हटा दिया गया

रूट @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat पॉड नोड-निर्यातक-zbfpx प्राप्त करें
NAD READY STATUS RESTARTS AGE
नोड-निर्यातक-zbfpx 0/1 समाप्ति 0 4d

रूट @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat पॉड नोड-निर्यातक-zbfpx --now --force हटाएं
पॉड "नोड-निर्यातक-zbfpx" हटा दिया गया

रूट @ r15-c70-b03-master01 : ~ # kubectl -n infra-lmat पॉड नोड-निर्यातक-zbfpx प्राप्त करें
NAD READY STATUS RESTARTS AGE
नोड-निर्यातक-zbfpx 0/1 समाप्ति 0 4d

रूट @ r15-c70-b03-master01 : ~ #

मैंने फली को संपादित करने और मेटाडेटा में फाइनल अनुभाग को हटाने की कोशिश की, लेकिन यह भी विफल रहा।

मैं अभी भी 100% प्रतिलिपि प्रस्तुत करने योग्य फैशन (एक ही संसाधन दोष) में kubectl 1.13 अल्फा और डेस्कटॉप पर डेस्कटॉप के लिए डॉकर के साथ देख रहा हूं। प्रतिलिपि प्रस्तुत करने योग्य से मेरा मतलब है कि इसे ठीक करने का एकमात्र तरीका मैक के लिए डॉकर को रीसेट करना प्रतीत होता है, और जब मैं अपने क्लस्टर को फिर से उसी संसाधनों (तैनाती स्क्रिप्ट) का उपयोग करके सेटअप करता हूं, तो वही क्लीन-अप स्क्रिप्ट विफल हो जाती है।

मुझे यकीन नहीं है कि यह प्रासंगिक क्यों होगा लेकिन मेरी साफ-सुथरी पटकथा ऐसी है:

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

क्योंकि क्लस्टर स्थानीय रूप से चलाया जाता है इसलिए मैं यह सत्यापित कर सकता हूं कि डॉकटर में कोई कंटेनर describe फली की स्थिति को Status: Terminating (lasts <invalid>) रूप में सूचीबद्ध किया है

बस एक बार फिर मेरे साथ हुआ। मैं NFS शेयर के साथ पेरकोना pmm- सर्वर को स्थापित करने की कोशिश कर रहा था और सॉफ्टवेयर भी नहीं आया था, इसलिए मैंने हटा दिया और यह हुआ। (इस सॉफ़्टवेयर के लिए लगातार दावा काम नहीं कर रहा था)। लगता है मैं एक बार फिर से अच्छे पुराने kubectl delete pods <podname> --force --grace-period=0 बुला रहा हूं। लेकिन सवाल यह है कि मुझे कैसे पता चलेगा कि यह फली कहाँ पर रह रही है?

@ चमकबयार-जी, एसएसएच वीएम में यह चालू था और docker ps चलता था।

खैर यह नहीं था .. मेरे पास कुछ वीएम हैं, इसलिए मैंने पूछा कि यह कैसे पता करें कि कौन सा सही है। :)

@ चमकबयार-जी यह काम कर सकता है:
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 में दिखाई नहीं देते हैं; उनमें से कुछ केवल कुबलेट को जानते हैं जो फली चल रही है, इसलिए आपको स्थानीय रूप से इसकी लॉग स्ट्रीम का पालन करना होगा
  
  
  
  • विशेष रूप से, umount निर्देशिकाएं जो Kubelet device or resource busy संदेशों के साथ शिकायत करती हैं
  
  
• जब बाकी सब विफल हो जाता है, kubectl edit फली फली और finalizers: → - foregroundDeletion निकाल दें

दो और सुझाव:

• स्थिर-स्थिति में एक गैर-भ्रमित क्यूबलेट को कोई आवधिक संदेश लॉग नहीं करना चाहिए। किसी चीज को जारी करने में किसी भी तरह की बार-बार असफलता, फंसे हुए फली का लक्षण है।
• आप अपनी प्रगति पर नज़र रखने के लिए एक kubectl delete कमांड को किसी अन्य विंडो में बंद रख सकते हैं (यहां तक ​​कि एक फली पर जो आपने पहले ही "कई बार" हटा दिया है)। kubectl delete अंतिम अटक संसाधन जारी होते ही समाप्त हो जाएगा।

आज इसके साथ सामना किया।
क्या किया गया था:

1. ssh नोड और कंटेनर मैन्युअल रूप से निकालने के लिए
2. उसके बाद kubectl get pods मुझे दिखाते हैं कि मेरे फंसे हुए कंटेनर 0/1 terminating ( 1/1 terminating )
3. फली से finalizers अनुभाग निकालें, मेरा foregroundDeletion ($ kubectl पॉड / नाम संपादित करें) था -> पॉड सूची से हटाए गए कंटेनर
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 विकल्प के साथ पोड को जबरदस्ती नहीं हटाता।

स्थायी समाधान की तलाश है।

खैर, हाल ही में मैंने अपने मंचन क्लस्टर पर रनवे शोषण सीवीई-2019-5736 का परीक्षण किया, जैसा कि आप पहले से ही जानते हैं कि मेजबान मशीन पर रन बाइनरी को फिर से लिखते हैं। इसका विनाशकारी शोषण। उसके बाद मैंने क्लस्टर पर अजीब व्यवहार देखा। सभी पॉड्स समाप्त होने वाली स्थिति पर अटक गए। वर्कअराउंड प्रभावित नोड पर्ज docker को सूखा रहा था और इसे फिर से स्थापित करें। इसके बाद सभी पॉड्स और k8s क्लस्टर पहले की तरह ही काम करते हैं। हो सकता है कि इसका डॉक्यूमेंट जारी हो और इसे फिर से स्थापित करने से आपकी समस्या हल हो जाए! धन्यवाद

ताजा v1.13.3 यहाँ स्थापित करें। यह मेरे साथ भी होता है। तब से मैं कुछ फली भर में एक ही NFS संस्करणों घुड़सवार जो इसके साथ कुछ करने के लिए लगता है।

मुझे यह समस्या तब दिखाई देती है जब कोई ऐसा परिनियोजन बनाते हैं जो एक ऐसे रहस्य का उपयोग करके वॉल्यूम बनाने की कोशिश करता है जो मौजूद नहीं है, उस परिनियोजन / सेवा को हटाकर Terminating पोड के आसपास छोड़ देता है।

v.1.12.3 के साथ एक ही समस्या का सामना करना पड़ रहा है, और - अनुग्रह-अवधि = 0 - प्रवर्तन या - दोनों को अमान्य, राज्य-स्थिति को हटा दें, जो भी अमान्य हैं

SMB (मुझे लगता है?) माउंट के साथ एक ही मुद्दा (Azure फ़ाइलें https://docs.microsoft.com/en-us/azure/aks/azure-files-volume) के अनुसार साझा करें।

13.3 के साथ एक ही मुद्दा

मेरे पास एक ही मुद्दा है कि फली लगभग 2 दिनों के लिए "समाप्त" स्थिति में है।
मैं लिनक्स मशीन (डेबियन) पर मिनिक्यूब का उपयोग कर रहा हूं।

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

@ardalanrazavi दो दिनों के लिए क्यों समाप्त हो रहा है? यदि यह 5 मिनट के बाद नहीं हटाता है तो बस बल हटाएं

@nmors

यह दो दिनों के लिए क्यों समाप्त हो रहा है?

यह एक अच्छा सवाल है। हम सभी यह जानना चाहेंगे।

यदि यह 5 मिनट के बाद नहीं हटाता है तो बस बल हटाएं

इसे हटाने से क्लस्टर को असंगत स्थिति में छोड़ दिया जाता है। (मिनिक्यूब के साथ, यह आपका वास्तविक क्लस्टर नहीं है, यह वास्तव में चिंता का बहुत कम हिस्सा है)

@AndrewSav

मुझे यहाँ कोई अन्य समाधान नहीं दिख रहा है।

ज़रूर, क्लस्टर "असंगत स्थिति" में छोड़ दिया जाएगा। मैं यह समझना चाहता हूं कि आप वास्तव में इससे क्या मतलब है। फोर्स क्लोजिंग खराब है। मुझे भी यह पसंद नहीं है, लेकिन मेरे मामले में, मैं आवश्यकतानुसार किसी भी संसाधन को नष्ट करने और फिर से तैयार करने में सहज हूं।

मेरे मामले में, यह केवल उन पॉड्स पर समाप्त हो रहा है जो एनएफएस माउंट है। और केवल तब होता है जब क्लाइंट के नीचे जाने की कोशिश करने से पहले एनएफएस सर्वर नीचे चला जाता है।

मैंने इस मुद्दे को तय किया, मैं अलग करने में सक्षम था कि सभी फली समाप्त होने वाले सभी एक नोड पर थे, नोड को फिर से शुरू किया गया था और समस्या दूर हो गई है।

@nmors @AndrewSav मैं किया शक्ति के रूप में अच्छी तरह से हटाने के लिए है।

अपने पॉड्स को हटाने से पहले अपने nfs सर्वर को हटाने से अनमाउंट को हमेशा के लिए लटकाने के लिए जाना जाता है। उस स्थिति में अपने विलोपन का आदेश देना सबसे अच्छा है ताकि आपका nfs सर्वर हमेशा अंतिम हटा दिया जाए।

@ msau42 मेरा NFS सर्वर k8s क्लस्टर का हिस्सा नहीं है - यह एक अलग उपकरण और मशीन है

इससे कोई फर्क नहीं पड़ता कि यह k8s क्लस्टर का हिस्सा है या नहीं। यदि nfs सर्वर अप्राप्य है, तो अनमाउंट तब तक लटका रहेगा जब तक कि वह फिर से सुलभ न हो जाए।

@ msau42 यह अजीब है, क्योंकि मुझे पूरा यकीन है कि जब यह ऑनलाइन वापस आया था, तब भी फली समाप्त हो गई थी। नए पॉड्स शुरू होते हैं और ठीक माउंट होते हैं।

मैं इस उदाहरण द्वारा पीछा किए गए kubernetes पर NFS सर्वर का उपयोग करता हूं और यह दुर्भाग्य से अक्सर होता है।

@ शाइबयार-जी मैंने भी उस गाइड का अनुसरण किया, लेकिन अब मैंने पीवी और पीवीसी से छुटकारा पा लिया है और अपनी मात्रा को सीधे तैनाती में परिभाषित किया है, जैसे:

        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 / पॉड्स" जैसी त्रुटियों को खोजती है ... निर्देशिका खाली नहीं है या "nfs"। ..देवी व्यस्त है ... अनमाउंट। एनएफएस "या" बासी एनएफएस फ़ाइल हैंडल "।
फिर यह या तो पॉड_ड या पॉड पूर्ण निर्देशिका को निकालता है और देखता है कि इसमें क्या है (जैसे mount | grep $pod_id ), फिर सभी को अनमाउंट करता है और संबंधित निर्देशिका को हटाता है। आखिरकार क्यूबलेट बाकी और इनायत को बंद कर देता है और फली को हटा देता है। समाप्त करने की स्थिति में कोई और अधिक फली नहीं।

मैंने हर मिनट चलाने के लिए उस स्क्रिप्ट को क्रोन में डाल दिया। नतीजतन - अभी के लिए कोई मुद्दा नहीं, यहां तक ​​कि 3-4 महीने बाद भी।
नोट : मुझे पता है, यह दृष्टिकोण अविश्वसनीय है और इसके लिए हर क्लस्टर अपग्रेड पर जांच की आवश्यकता है लेकिन यह काम करता है!

मैं संस्करण १.१० का उपयोग कर रहा हूं और मैंने आज इस मुद्दे का अनुभव किया है और मुझे लगता है कि मेरी समस्या बढ़ती गुप्त मात्रा के मुद्दे से संबंधित है जिसने कुछ कार्य लंबित छोड़ दिए और पॉड को हमेशा के लिए समाप्त कर दिया।

मुझे फली समाप्त करने के लिए --grace-period = 0 --force विकल्प का उपयोग करना पड़ा।

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

मैंने पाया है कि यदि आप --force --grace-period=0 उपयोग करते हैं, तो यह सभी संदर्भ को हटा देता है ... यदि आप नोड में ssh करते हैं, तो आप अभी भी डॉक कंटेनर को चलाते हुए देखेंगे।

मेरे मामले में, नोड पर स्मृति से बाहर था।
और कर्नेल ने सिलियम-एजेंट को मार दिया, जो कि गड़बड़ी को समाप्त करता है।
मैंने केवल नोड को फिर से शुरू किया और इसे मंजूरी दे दी।

मेरे अनुभव में, नोड पर sudo systemctl restart docker मदद करता है (लेकिन स्पष्ट रूप से डाउनटाइम है)।

और यह अभी भी समय-समय पर यादृच्छिक नोड्स पर हो रहा है जो या तो ए) मेमोरी सीमा या बी के करीब है) सीपीयू भूखा है (या तो कुछ केएसवीडी 0 मुद्दे का बीसी जो अभी भी मेम संबंधित, या वास्तविक लोड हो सकता है)

90 डी निष्क्रियता के बाद मुद्दे बासी हो जाते हैं।
/remove-lifecycle stale साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र बासी

बासी मुद्दे 30d निष्क्रियता के बाद सड़ जाते हैं।
/remove-lifecycle rotten साथ ताज़ा अंक को चिह्नित करें।
अतिरिक्त 30 डी निष्क्रियता के बाद सड़े हुए मुद्दे बंद हो जाते हैं।

यदि यह समस्या अब बंद करने के लिए सुरक्षित है, तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/ जीवनचक्र सड़ा हुआ

निष्क्रियता के 30d के बाद सड़े हुए मुद्दे।
/reopen साथ समस्या को फिर से खोलें।
/remove-lifecycle rotten साथ ताज़ा अंक को चिह्नित करें।

सिग-टेस्टिंग, कुबेरनेट्स / टेस्ट-इन्फ्रा और / या फ़ेज्टा पर प्रतिक्रिया भेजें।
/बंद करे

@ fejta- बॉट: इस मुद्दे को बंद करना।

यह अभी भी बहुत सक्रिय मुद्दा है, k8s 1.15.4 और RHEL Docker 1.13.1। सभी समय फली Terminating लेकिन कंटेनर पहले से ही चला गया है, और k8s स्वयं का पता नहीं लगा सकते हैं, लेकिन मानव संपर्क की आवश्यकता है। वास्तविक PITA स्क्रिप्टिंग परीक्षण करता है।

/ फिर से खोलना
/ remove-lifecycle सड़ा हुआ

@tuminoid : जब तक आप इसे लिखे या आप सहयोगी नहीं हैं, तब तक आप किसी समस्या / PR को फिर से खोल नहीं सकते।

/ फिर से खोलना
/ remove-lifecycle सड़ा हुआ

@mikesplain : इस मुद्दे को फिर से खोल दिया।

यहाँ भी: फली अधिक 19 मिनट के लिए समाप्त चरण में फंस गया। कंटेनर सफलतापूर्वक समाप्त हो गया है, लेकिन कुबेरनेट्स अभी भी मानते हैं कि इसे कुछ के लिए इंतजार करने की आवश्यकता है ..

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

क्या आप अपने क्यूबलेट लॉग को चेक कर सकते हैं और देख सकते हैं कि क्या वॉल्यूम अनमाउंट फेलिंग, या अनाथ फली के बारे में कोई संदेश है?

मैंने इसे भी देखा है
E1206 03: 05: 40.247161 25653 kubelet_volumes.go: 154] अनाथ फली "0406c4bf-17e3-4613-a526-34e8a2cee208" मिला, लेकिन वॉल्यूम पाथ अभी भी डिस्क पर मौजूद हैं: इसमें कुल 8 त्रुटियां थीं। उन्हें देखने के लिए क्रियाशीलता को चालू करें।

मैंने भी देखा है। लॉग की जाँच नहीं कर सकते क्योंकि क्यूबेकल शिकायत करता है कि यह डॉकटर कंटेनर से नहीं जुड़ सकता है और पॉड को समाप्त करने के वर्तमान अस्तित्व के कारण नया पॉड नहीं बना सकता है। बल्कि गुस्सा है।

यह अनुभव करते हुए भी कि कुबेरनेट्स ने पुराने पॉड्स को अच्छी तरह से साफ किया है या नहीं, इसकी पुष्टि करना कष्टप्रद है।
उम्मीद है, यह जल्द ही तय हो जाएगा।

और इस मुद्दे के बारे में क्या? क्या इसका समाधान हुआ? मेरे पास एक ही है, लेकिन यह तुरंत शुरू नहीं होता है, लेकिन नोड की शुरुआत के कुछ समय बाद, यदि आप नोड को रीसेट करते हैं, तो कुछ समय के लिए सब कुछ अच्छा है

क्या आप जांच कर सकते हैं कि क्या फली पर अंतिम रूप से इसे हटाने से रखा जा रहा है?

जारी किए गए फली में कोई फाइनल नहीं है

FYI करें मैंने इसका उपयोग बल हटाने के साथ किया:

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

और मेरा मानना ​​है कि यह सफलतापूर्वक फली को समाप्त करने में कामयाब रहा। तब से मैंने इस मुद्दे पर फिर से अनुभव नहीं किया है। मैंने तब से संभवतः अपडेट किया है, इसलिए यह एक संस्करण मुद्दा हो सकता है, लेकिन 100% नहीं जब से मैंने इस मुद्दे को देखा है तब से यह बहुत लंबा है।

यह मुझे तब होता है जब एक फली स्मृति से बाहर चल रही है। यह तब तक समाप्त नहीं होता जब तक कि मेमोरी का उपयोग फिर से कम न हो जाए।

FYI करें मैंने इसका उपयोग बल हटाने के साथ किया:

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

और मेरा मानना ​​है कि यह सफलतापूर्वक फली को समाप्त करने में कामयाब रहा। तब से मैंने इस मुद्दे पर फिर से अनुभव नहीं किया है। मैंने तब से संभवतः अपडेट किया है, इसलिए यह एक संस्करण मुद्दा हो सकता है, लेकिन 100% नहीं जब से मैंने इस मुद्दे को देखा है तब से यह बहुत लंबा है।

मेरे लिए वह काम कर गया

kubectl delete pods <pod> --grace-period=0 --force एक अस्थायी फिक्स है, मैं प्रभावित फली में से किसी एक के लिए फेलओवर होने पर हर बार मैनुअल फिक्स नहीं चलाना चाहता। मेरे zookeeper पॉड minikube और Azure AKS पर समाप्त नहीं हो रहे हैं।

अपडेट 9 मार्च 2020
मैंने अपने पॉड को मैन्युअल रूप से समाप्त करने के लिए प्रीस्टॉप जीवनचक्र हुक का उपयोग किया। मेरे ज़ुकीपर पॉड्स एक समाप्ति की स्थिति में फंस गए थे और कंटेनर के भीतर से टर्म सिग्नल का जवाब नहीं देंगे। मेरे पास मूल रूप से समान रूप से चलने वाला एक अन्य स्थान है और सब कुछ सही ढंग से समाप्त हो गया है, इसका कोई कारण नहीं है कि मूल कारण क्या है।

एक ही मुद्दा, सुपर कष्टप्रद

एक ही मुद्दा :( फली 3 दिनों से समाप्त करने में फंस गया

FYI करें मैंने इसका उपयोग बल हटाने के साथ किया:

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

और मेरा मानना ​​है कि यह सफलतापूर्वक फली को समाप्त करने में कामयाब रहा। तब से मैंने इस मुद्दे पर फिर से अनुभव नहीं किया है। मैंने तब से संभवतः अपडेट किया है, इसलिए यह एक संस्करण मुद्दा हो सकता है, लेकिन 100% नहीं जब से मैंने इस मुद्दे को देखा है तब से यह बहुत लंबा है।

इसके अलावा, --force ध्वज का मतलब यह नहीं है कि फली को हटा दिया गया है, यह सिर्फ पुष्टि के लिए इंतजार नहीं करता है (और मेरी समझ के लिए संदर्भ छोड़ देता है)। जैसा कि चेतावनी The resource may continue to run on the cluster indefinetely ने कहा है।

संपादित करें: मैं बीमार था। आगे की प्रेरणा के लिए नीचे elrok123s टिप्पणी देखें।

FYI करें मैंने इसका उपयोग बल हटाने के साथ किया:

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

और मेरा मानना ​​है कि यह सफलतापूर्वक फली को समाप्त करने में कामयाब रहा। तब से मैंने इस मुद्दे पर फिर से अनुभव नहीं किया है। मैंने तब से संभवतः अपडेट किया है, इसलिए यह एक संस्करण मुद्दा हो सकता है, लेकिन 100% नहीं जब से मैंने इस मुद्दे को देखा है तब से यह बहुत लंबा है।

इसके अलावा, --force ध्वज का मतलब यह नहीं है कि फली को हटा दिया गया है, यह सिर्फ पुष्टि के लिए इंतजार नहीं करता है (और मेरी समझ के लिए संदर्भ छोड़ देता है)। जैसा कि चेतावनी The resource may continue to run on the cluster indefinetely ने कहा है।

सही है, लेकिन बात यह है कि --grace-period=0 हटने को मजबूर करती है :) यह सुनिश्चित नहीं है कि आपकी टिप्पणी प्रासंगिक क्यों है: /

मुझे लगता है कि उनकी टिप्पणी प्रासंगिक है क्योंकि अंतर्निहित कंटेनर
(docker या जो भी) अभी भी चल रहा है और पूरी तरह से हटाया नहीं जा सकता है ..,
इसका भ्रम "हटा दिया गया" कई बार थोड़ा भ्रामक होता है

थू पर, जून 4, 2020 को 9:16 बजे, कोनर स्टीफन मैककेबे <
सूचनाएं@github.com> ने लिखा:

FYI करें मैंने इसका उपयोग बल हटाने के साथ किया:

kubectl फली हटाएं- अनुग्रह-काल = ० - प्रवर्तन

और मेरा मानना ​​है कि यह सफलतापूर्वक फली को समाप्त करने में कामयाब रहा। तब से मैं
इस मुद्दे को फिर से अनुभव नहीं किया है। मैंने तब से संभवतः अपडेट किया है,
इसलिए यह एक संस्करण मुद्दा हो सकता है, लेकिन 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 जहां तक ​​मुझे जानकारी है, यह प्रभावी रूप से उस फली में सभी प्रक्रियाओं पर सिगकिल चला रहा है, जो ज़ोंबी प्रक्रियाओं को हटाना सुनिश्चित करता है (स्रोत: प्वाइंट 6 'पॉड्स की समाप्ति' के तहत - https ://kubernetesesio/docs/concepts

मार्गदर्शक का उल्लेख है कि यह संदर्भ को हटा देता है, लेकिन स्वयं फली को नहीं हटाता है (स्रोत: 'फोर्स डिलीटेशन' - https://kubernetes.io/docs/tasks/run-application/force-delete-startful-set-pod/ ), हालांकि ग्रेस-पीरियड = 0 को प्रभावी ढंग से आपके पॉड एल्बिट को सिगिल करना चाहिए, तुरंत नहीं।

मैं सिर्फ डॉक्स और मेरे द्वारा देखे गए परिदृश्य को संभालने के लिए अनुशंसित तरीके पढ़ रहा हूं। जो मुद्दा मैंने विशेष रूप से सामना किया था, वह एक पुनरावृत्ति मुद्दा नहीं था, और कुछ ऐसा जो एक बार हुआ; मेरा मानना ​​है कि इसके लिए वास्तविक निर्धारण आपकी तैनाती को ठीक कर रहा है, लेकिन जब तक आप वहां नहीं पहुंचते हैं, तब तक इस विधि की मदद करनी चाहिए।

@ elrok123 शानदार - मैं वास्तव में बीमार था। मैंने इस स्पष्टीकरण का संदर्भ देते हुए अपनी प्रतिक्रिया अपडेट की है। विस्तृत प्रतिक्रिया के लिए धन्यवाद, और परेशान फली से निपटने के लिए एक और प्रेरित विधि। चीयर्स!

वर्तमान में राज्य को समाप्त करने में 2 + दिनों के लिए फली अटक गई है।

मेरे लिए नामस्थान Terminating में अटका हुआ है। कोई फली सूचीबद्ध नहीं है। कोई सेवाएं नहीं ... कुछ भी नहीं। नाम स्थान खाली है। फिर भी ... समाप्त करने में अटक गया।

@JoseFMP नामस्थान से yaml का अनुरोध करने के लिए

@JordyBottelier धन्यवाद।

कोई फाइनल नहीं। अभी भी Terminating अटका हुआ है

@JoseFMP यहाँ एक स्क्रिप्ट है इसे पूरी तरह से बंद करने के लिए (प्रभावी रूप से इसे nuke), बस इसे बचाने और चलाने के लिए ।/script.name:
`` `

! / Bin / bash

सेट-पाइफेल

die () {echo "$ *" 1> & 2; बाहर निकलें 1; }

जरुरत() {
जो "$ 1" और> / देव / अशक्त || मर "बाइनरी '$ 1' गायब है लेकिन आवश्यक है"
}

पूर्व-रीकों की जाँच करना

जरूरत "jq"
"कर्ल" की जरूरत है
"kubectl" की आवश्यकता

परियोजना = "$ 1"
खिसक जाना

परीक्षण -n "$ परियोजना" || डाई "मिसिंग दलीलें: किल-एनएस"

kubectl प्रॉक्सी और> / देव / अशक्त और
PROXY_PID = $!
किलप्रोक्सी () {
$ PROXY_PID को मारें
}
ट्रैप किलप्रोक्सी परीक्षा

नींद 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 / $ PRO PROECT / अंतिम रूप && गूंज "मारे गए नाम स्थान: $ परियोजना" `` `

मैं भी इसमें आसानी से दौड़ता हूँ, जिसमें कई पॉड्स समाप्त हो जाते हैं, जिसमें एक पॉड भी शामिल है जो अब मेरे बुनियादी ढांचे में कहीं भी दिखाई नहीं देता है, लेकिन फिर भी यह एक भूत के रूप में चल रहा है (यह अनुरोधों पर काम करता है और मैं देख सकता हूं कि तैनाती के पैमाने के साथ भी अनुरोध किए जा रहे हैं शून्य का)।

मेरे पास शून्य दृश्यता है और न ही इस पॉड पर नियंत्रण है और पूछते हैं कि कैसे मैं सभी नोड्स को जबरदस्ती बंद किए बिना इस तरह की स्थिति का निवारण करने वाला हूं?

मैं भी इसमें आसानी से दौड़ता हूँ, जिसमें कई पॉड्स समाप्त हो जाते हैं, जिसमें एक पॉड भी शामिल है जो अब मेरे बुनियादी ढांचे में कहीं भी दिखाई नहीं देता है, लेकिन फिर भी यह एक भूत के रूप में चल रहा है (यह अनुरोधों पर काम करता है और मैं देख सकता हूं कि तैनाती के पैमाने के साथ भी अनुरोध किए जा रहे हैं शून्य का)।

मेरे पास शून्य दृश्यता है और न ही इस पॉड पर नियंत्रण है और पूछते हैं कि कैसे मैं सभी नोड्स को जबरदस्ती बंद किए बिना इस तरह की स्थिति का निवारण करने वाला हूं?

आपको नोड पर डॉक एक्सेस करना होगा।
आप मेरे dink (https://github.com/Agilicus/dink) का उपयोग कर सकते हैं, जो पॉड w / शेल w / docker एक्सेस या पॉड के लिए ssh लाएगा।
docker ps -a
docker stop ####

सौभाग्य।

दिशा के लिए धन्यवाद।

मैं अंततः इसे हल करने में सक्षम था, लेकिन फिर भी थोड़ा हैरान था कि यह कैसे हो सकता है (मेरे लिए फली पूरी तरह से अदृश्य थी)। जैसा कि यह उत्पादन में था चीजें थोड़ी व्यस्त थीं और मैं निदान करने में सक्षम नहीं था, लेकिन अगर यह फिर से होता है तो उम्मीद है कि मैं एक बेहतर बग रिपोर्ट बना सकता हूं।

एक समान लक्षण देखकर, फली समाप्त होने में फंस गई (दिलचस्प है कि वे सभी तत्परता / आजीविका के लिए प्रकार की जांच करते हैं)। लॉग को देखकर मैं देख सकता हूं: kubelet [1445]: I1022 10: 26: 32.203865 1445 prober.go: 124] "परीक्षण-सेवा -74c4664d8d-58c96 -default (822c3c3d-082a-4dc9-943c-194344-19f44-19f44-1944) के लिए तत्परता जांच। -service "विफल (विफलता): ओसीआई रनटाइम निष्पादन विफल रहा: निष्पादन विफल: बंद किए गए कंटेनर को निष्पादित नहीं कर सकता: अज्ञात। यह संदेश अपने आप को हमेशा के लिए दोहराता है और निष्पादन जांच को tcpSocket में बदलकर लगता है कि पॉड को समाप्त करने की अनुमति है (एक परीक्षण के आधार पर, इसका पालन करेंगे)। पॉड में कंटेनर "रनिंग" में से एक है, लेकिन "रेडी" नहीं है, "रनिंग" कंटेनर के लिए लॉग दिखाता है जैसे कि सेवा बंद हो गई है।

यह कंटेनड 1.4.0 पर होता है जब नोड लोड अधिक होता है और vm.max_map_count डिफ़ॉल्ट से अधिक मूल्य पर सेट होता है, तो कंटेनर-शिम डेंट को स्टडआउट ड्रेन ड्रेन करता है और ब्लॉक्स के बंद होने का इंतजार करता है, जबकि डॉकडर जीई को विफल नहीं करता है। घटना / कंटेनर से स्वीकार करते हैं कि प्रक्रियाएं समाप्त हो गई हैं।

@discanto इस जानकारी को साझा करने के लिए धन्यवाद। क्या समस्या ठीक हो रही है या ट्रैक की जा रही है?

@ रैंडम-लियू

बग को 3 साल से अधिक समय हो गया है। समाप्त होने पर फली कई कारणों से हो सकती है। अपने मामले की रिपोर्टिंग करते समय, यह देखने के लिए कुछ क्यूबलेट लॉग पोस्ट करने में बहुत मदद मिलेगी कि क्या फली अटक गई है।