Kubernetes: बैच नौकरियों में साइडकार कंटेनरों के लिए बेहतर समर्थन

/विषय

यहां सुझाए गए अनुसार एक जीवंतता समस्या का उपयोग करना http://stackoverflow.com/questions/36208211/sidecar-containers-in-kubernetes-jobs काम नहीं करता है क्योंकि पॉड को विफल माना जाएगा और समग्र कार्य को सफल नहीं माना जाएगा।

कैसे के बारे में हमने नौकरी की सफलता जांच की घोषणा की ताकि नौकरी फली के लौटने की प्रतीक्षा करने के बजाय सफलता का पता लगाने के लिए इसकी जांच कर सके।
एक बार जब जांच सफल हो जाती है, तो पॉड को समाप्त किया जा सकता है।

एक कंटेनर के खिलाफ जांच कर सकते हैं जो पहले ही बाहर निकल चुका है, या वहां होगा
एक ऐसी दौड़ बनो जहाँ इसे तोड़ा जा रहा है?

एक अन्य विकल्प कुछ निकास कोडों को विशेष अर्थ के रूप में निर्दिष्ट करना है।

दोनों "पूरे पॉड के लिए सफलता" या "पूरे पॉड के लिए विफलता" दोनों हैं
उपयोगी।

इसे पॉड ऑब्जेक्ट पर होना चाहिए, ताकि यह एक बड़ा एपीआई परिवर्तन हो।

गुरु, 22 सितंबर, 2016 को दोपहर 1:41 बजे, मिंग फेंग नोटिफिकेशन @github.com ने लिखा:

कैसे के बारे में हमने नौकरी की सफलता की जांच की घोषणा की ताकि नौकरी इसकी जांच कर सके
पॉड के 0 पर लौटने की प्रतीक्षा करने के बजाय सफलता का पता लगाएं।

एक बार जब जांच सफल हो जाती है, तो पॉड को समाप्त किया जा सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -249021627,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AHuudjrpVtef6U35RWRlZr3mDKcCRo7oks5qsugRgaJpZM4IiqQH
.

@erictune अच्छा बिंदु; हम एक बाहर निकले कंटेनर की जांच नहीं कर सकते।

क्या हम पॉड में किसी विशेष कंटेनर को "पूर्ण" कंटेनर के रूप में नामित कर सकते हैं ताकि जब वह कंटेनर बाहर निकले तो हम कह सकें कि काम पूरा हो गया है?

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

क्या हम पॉड में किसी विशेष कंटेनर को "पूर्ण" कंटेनर के रूप में नामित कर सकते हैं ताकि जब वह कंटेनर बाहर निकले तो हम कह सकें कि काम पूरा हो गया है?

क्या आपने इस दस्तावेज़ बिंदु 3 को देखा है, जिसका विवरण यहां दिया गया है, जहां आप मूल रूप से .spec.completions सेट नहीं करते हैं और जैसे ही पहला कंटेनर 0 निकास कोड के साथ समाप्त होता है, काम पूरा हो जाता है।

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

व्यक्तिगत रूप से, ये मुझे नौकरी के बजाय RS की तरह अधिक लगते हैं, लेकिन यह मेरी व्यक्तिगत राय है और सबसे महत्वपूर्ण बात यह है कि मुझे आपके सेटअप का पूरा विवरण नहीं पता है।

आम तौर पर, https://github.com/kubernetes/kubernetes/issues/17244 और https://github.com/kubernetes/kubernetes/issues/30243 पर निम्नलिखित चर्चाएं होती हैं जो इस विषय को भी छू रही हैं।

@soltysh आपके द्वारा ऊपर भेजा गया लिंक, बिंदु 3 संदर्भ पॉड पूर्णता और कंटेनर पूर्णता नहीं।

दो कंटेनर एक खाली डीआईआर, और पहला कंटेनर साझा कर सकते हैं और एक फ़ाइल में "मैं अभी बाहर निकल रहा हूं" संदेश लिख सकता हूं और दूसरा उस संदेश को देखने पर बाहर निकल सकता है।

@erictune मेरे पास एक उपयोग का मामला है जो मुझे लगता है कि इस बाल्टी में आता है और मुझे उम्मीद है कि आप मुझे सही दिशा में मार्गदर्शन कर सकते हैं क्योंकि इस समस्या को हल करने के लिए कोई आधिकारिक अनुशंसित तरीका नहीं लगता है।

मैं नीचे सब कुछ कोड करने के लिए क्लाइंट-गो लाइब्रेरी का उपयोग कर रहा हूं:

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

मैं इस परिणाम फ़ाइल को कैप्चर करने में सक्षम था यदि मैंने वॉल्यूम स्रोत के रूप में HostPath किया और चूंकि मैं स्थानीय रूप से मिनीक्यूब चला रहा हूं, परिणाम फ़ाइल मेरे वर्कस्टेशन पर सहेजी जाती है।

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

तो, क्या मुझे साइडकार कंटेनर पैटर्न का उपयोग करके भी अपनी समस्या का समाधान करना चाहिए?

मूल रूप से, वही करें जो आपने ऊपर सुझाया था। काम शुरू होने पर पॉड में 2 कंटेनर शुरू करें। 1 कंटेनर काम चलाता है और जैसे ही काम पूरा हो जाता है, एक संदेश छोड़ देता है जो दूसरे कंटेनर द्वारा उठाया जाता है जो फिर परिणाम फ़ाइल को पकड़ लेता है और इसे कहीं संग्रहीत करता है?

मैं यह समझने में असफल रहा कि हमें पहली जगह में 2 कंटेनरों की आवश्यकता क्यों होगी। जॉब कंटेनर यह सब अपने आप क्यों नहीं कर सकता? यानी काम खत्म करें, रिजल्ट फाइल को कहीं सेव करें, उसे एक्सेस करें/पढ़ें और कहीं स्टोर करें।

@anshumanbh मैं आपको सुझाव

1. एक सतत भंडारण का उपयोग करें, आप परिणाम फ़ाइल को सहेजते हैं
2. hostPath माउंट का उपयोग करें, जो लगभग 1 जैसा ही है, और आप इसे पहले ही आज़मा चुके हैं
3. परिणाम फ़ाइल को किसी ज्ञात दूरस्थ स्थान (s3, google ड्राइव, ड्रॉपबॉक्स) पर अपलोड करें, आमतौर पर किसी भी प्रकार की साझा ड्राइव

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

@anshumbh पूरी तरह से स्पष्ट है, और फिर भी यह साइड-कार कंटेनर की श्रेणी में नहीं आता है। आप जो कुछ हासिल करना चाहते हैं वह वर्तमान में नौकरियों के साथ उपलब्ध कराने योग्य है।

@soltysh इसलिए विचार करते हुए कि मैं ऊपर दी गई सूची से विकल्प 3 के लिए जाना चाहता हूं, मैं इसे लागू करने के बारे में कैसे

मुझे जिस समस्या का सामना करना पड़ रहा है वह यह है कि जैसे ही काम खत्म हो जाता है, कंटेनर बाहर निकल जाता है और मैं फाइल खो देता हूं। अगर मेरे पास फ़ाइल नहीं है, तो मैं इसे S3/Google ड्राइव/ड्रॉपबॉक्स जैसी साझा ड्राइव पर कैसे अपलोड करूं? मैं नौकरी के कोड को संशोधित करने से पहले इसे कहीं और स्वचालित रूप से अपलोड करने के लिए संशोधित नहीं कर सकता, इसलिए दुर्भाग्य से मुझे पहले नौकरी चलानी होगी और फिर फ़ाइल को कहीं सहेजना होगा ..

यदि आप नौकरी के कोड को संशोधित नहीं कर सकते हैं, तो आपको फ़ाइल को अपलोड करने में सक्षम होने के लिए इसे इस तरह से लपेटना होगा। यदि आप जिसके साथ काम कर रहे हैं वह एक छवि है जिसे पहले से ही कॉपी कोड के साथ विस्तारित किया गया है।

@soltysh हाँ, यह समझ में आता है। मैं वह कर सकता था। हालांकि, मेरे पास अगला प्रश्न है - मान लीजिए कि मुझे कई नौकरियां चलाने की ज़रूरत है (इसके बारे में विभिन्न टूल्स चलाने के बारे में सोचें) और इनमें से किसी भी टूल में अपलोडिंग पार्ट नहीं है। तो, अब, मुझे उस रैपर का निर्माण करना होगा और उनमें से प्रत्येक टूल को अपलोडिंग भाग के साथ विस्तारित करना होगा। क्या कोई तरीका है कि मैं सिर्फ एक बार रैपर/एक्सटेंशन लिख सकता हूं और सभी टूल्स के लिए इसका इस्तेमाल कर सकता हूं?

क्या उस मामले में साइड कार पैटर्न फिट नहीं होगा?

हाँ, सकता है। हालाँकि मैं एक ही पॉड के अंदर कई कंटेनरों के साथ कोशिश करूँगा, pattern. आयो। आपका पॉड जॉब कंटेनर चला रहा है और अतिरिक्त एक के साथ आउटपुट की प्रतीक्षा कर रहा है और उसे अपलोड कर रहा है। सुनिश्चित नहीं है कि यह कितना व्यवहार्य है लेकिन आप इसे पहले से ही आजमा सकते हैं।

कोमल पिंग - साइडकार जागरूकता Envoy जैसे माइक्रोसर्विस प्रॉक्सी के प्रबंधन को और अधिक सुखद बना देगी। क्या साझा करने के लिए कोई प्रगति है?

चीजों की वर्तमान स्थिति यह है कि प्रत्येक कंटेनर को जीवन काल के समन्वय के लिए बंडल टूलिंग की आवश्यकता होती है, जिसका अर्थ है कि हम सीधे अपस्ट्रीम कंटेनर छवियों का उपयोग नहीं कर सकते हैं। यह टेम्प्लेट को भी महत्वपूर्ण रूप से जटिल बनाता है, क्योंकि हमें अतिरिक्त argv और माउंट पॉइंट इंजेक्ट करने होते हैं।

पहले का सुझाव था कि कुछ कंटेनरों को "पूर्ण" कंटेनर के रूप में नामित किया जाए। मैं इसके विपरीत प्रस्ताव देना चाहूंगा - कुछ कंटेनरों को "साइडकार्स" के रूप में नामित करने की क्षमता। जब पॉड में अंतिम गैर-साइडकार कंटेनर समाप्त हो जाता है, तो पॉड को साइडकार को TERM भेजना चाहिए। यह कई थ्रेडिंग लाइब्रेरी में पाई जाने वाली "बैकग्राउंड थ्रेड" अवधारणा के अनुरूप होगा, उदाहरण के लिए पायथन का Thread.daemon ।

उदाहरण कॉन्फ़िगरेशन, जब कंटेनर main समाप्त होता है तो क्यूबलेट envoy को मार देगा:

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/my-batch-job/bin/main", "--config=/config/my-job-config.yaml"]
  - name: envoy
    image: lyft/envoy:latest
    sidecar: true
    command: ["/usr/local/bin/envoy", "--config-path=/my-batch-job/etc/envoy.json"]

संदर्भ के लिए, यहाँ बैश पागलपन है जिसका उपयोग मैं वांछित साइडकार व्यवहार का अनुकरण करने के लिए कर रहा हूँ:

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        trap "touch /tmp/pod/main-terminated" EXIT
        /my-batch-job/bin/main --config=/config/my-job-config.yaml
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
  - name: envoy
    image: gcr.io/our-envoy-plus-bash-image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        /usr/local/bin/envoy --config-path=/my-batch-job/etc/envoy.json &
        CHILD_PID=$!
        (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
        wait $CHILD_PID
        if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; fi
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
        readOnly: true
volumes:
  - name: tmp-pod
    emptyDir: {}

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

@ jmillikin-stripe मुझे यह विचार पसंद है, हालांकि मुझे यकीन नहीं है कि यह कुछ कंटेनरों को पॉड में अलग-अलग व्यवहार करने या उनके बीच निर्भरता शुरू करने के प्रिंसिपल का पालन करता है। मैं अंतिम कॉल के लिए @erictune को टाल

हालाँकि, क्या आपने #17244 की जाँच की है, क्या इस प्रकार का समाधान आपके उपयोग के मामले में फिट होगा? यह वही है जो @erictune ने पहले कुछ टिप्पणियों का उल्लेख किया था:

एक अन्य विकल्प कुछ निकास कोडों को विशेष अर्थ के रूप में निर्दिष्ट करना है।

@ jmillikin-stripe मुझे यह विचार पसंद है, हालांकि मुझे यकीन नहीं है कि यह कुछ कंटेनरों को पॉड में अलग-अलग व्यवहार करने या उनके बीच निर्भरता शुरू करने के प्रिंसिपल का पालन करता है। मैं अंतिम कॉल के लिए @erictune को टाल

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

हालाँकि, क्या आपने #17244 की जाँच की है, क्या इस प्रकार का समाधान आपके उपयोग के मामले में फिट होगा? यह वही है जो @erictune ने पहले कुछ टिप्पणियों का उल्लेख किया था:

एक अन्य विकल्प कुछ निकास कोडों को विशेष अर्थ के रूप में निर्दिष्ट करना है।

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

शायद इसे हल करने के लिए अतिरिक्त जीवनचक्र हुक पर्याप्त होंगे?

हो सकता है:

• पोस्टस्टॉप: पॉड में अन्य कंटेनरों पर जीवनचक्र की घटनाओं को ट्रिगर करने के साधन के साथ (यानी ट्रिगर स्टॉप)
• पीयरस्टॉप्ड: संकेत है कि पॉड में एक "पीयर" कंटेनर मर गया है - संभवतः एक तर्क के रूप में निकास कोड के साथ

यह एक कंटेनर को पुनरारंभ करने के लिए कस्टम नीतियों को परिभाषित करने के लिए एक साधन भी परिभाषित कर सकता है - या यहां तक ​​​​कि कंटेनर शुरू करने के लिए डिफ़ॉल्ट रूप से प्रारंभ नहीं किए गए कंटेनर भी शुरू कर सकते हैं (जब कंटेनर खत्म हो जाता है तो कंटेनर शुरू करें बी)

यह भी याद आ रही है। हम हर 30 मिनट में एक नौकरी चलाते हैं जिसके लिए कनेक्टिविटी के लिए वीपीएन क्लाइंट की आवश्यकता होती है, लेकिन ऐसे बहुत से उपयोग के मामले प्रतीत होते हैं जहां यह बहुत उपयोगी हो सकता है (उदाहरण के लिए सामान जिसे कुबेक्टल प्रॉक्सी की आवश्यकता होती है)। वर्तमान में, मैं वर्कअराउंड के रूप में jobSpec.concurrencyPolicy: Replace का उपयोग कर रहा हूं, लेकिन निश्चित रूप से यह केवल तभी काम करता है जब a.) आप समानांतर जॉब रन के बिना रह सकते हैं और b.) जॉब निष्पादन समय शेड्यूलिंग अंतराल से कम है।

संपादित करें: मेरे उपयोग के मामले में, एक कंटेनर को समाप्ति के रूप में चिह्नित करने के लिए नौकरी की कल्पना में कुछ संपत्ति रखने के लिए पूरी तरह से पर्याप्त होगा और नौकरी की निगरानी होगी कि एक बाहर निकलने की स्थिति के लिए और शेष को मार दें।

मुझे भी इसकी जरूरत है। हमारे मामले में यह एक ऐसा काम है जो एक साइडकार सेवा के रूप में क्लाउडस्क्ल-प्रॉक्सी कंटेनर का उपयोग करता है।

संभावित रूप से एक एनोटेशन जोड़ने के बारे में जो पॉड में 'प्राथमिक' कंटेनर के नाम पर मैप करता है? इस तरह पॉड स्पेक को किसी भी तरह से संशोधित करने की आवश्यकता नहीं है।

पॉड्स को कैसे डिज़ाइन किया जाता है, इसकी प्रकृति से यह एक बहुत ही सामान्य उपयोग-मामला जैसा लगता है। @soltysh @erictune इस पर जल्द काम करने की कोई योजना है? जहां संभव हो मदद करने में खुशी हुई :)

इस सुविधा की भी जरूरत है। हमारे उपयोग के मामले के लिए :
पॉड ए को कंटेनर करना पड़ता है

• कंटेनर A1 : एक रन-टू-कंप्लीट कंटेनर जो फाइलों में लॉग प्रिंट करता है
• कंटेनर A2 : साइडकार कंटेनर, जो फ़ाइल से stdout में लॉग को केवल टेल करता है

मुझे क्या चाहिए : जब कंटेनर A1 सफलता के साथ पूरा होता है, तो पॉड A सफलता के साथ पूरा होता है। क्या हम कंटेनर A1 को मुख्य कंटेनर के रूप में लेबल कर सकते हैं, जब मुख्य कंटेनर बाहर निकलता है, पॉड बाहर निकलता है? @erictune (यह विचार @mingfang द्वारा भी वर्णित है)

हे दोस्तों, मैं देख रहा हूँ कि यह मुद्दा एक महीने से खुला है। इस पर नवीनतम क्या है? हमारे पास एक उपयोग-मामला है, जहां हम नौकरी चलाना चाहते हैं। नौकरी कुछ साइड-कार containers साथ main कंटेनर चलाती है। हम चाहते हैं कि main कंटेनर के बाहर निकलने पर जॉब निकल जाए। क्या कंटेनरों के बीच signal भेजने के लिए file साझा करने के लिए कला की स्थिति है?

मुझे इस पर कुछ काम शुरू करने में कोई आपत्ति नहीं होगी, मैं जानना चाहूंगा कि क्या कोई आगामी पीआर की समीक्षा कर सकता है यदि मैं करता हूं (शायद क्यूबकॉन के बाद)।

cc @erictune @a-robinson @soltysh

@andrewsykim आप क्या दृष्टिकोण अपनाएंगे। साथ ही, मुझे पता है कि मैं इसे यहां जोड़ रहा हूं, निर्भरताओं के लिए समर्थन जोड़ने में क्या लगेगा। जैसे main कंटेनर तब तक शुरू नहीं होना चाहिए जब तक कि साइडकार्स इनिशियलाइज़ नहीं हो जाते

मुख्य कंटेनर की तरह तब तक शुरू नहीं होना चाहिए जब तक कि साइडकार शुरू नहीं हो जाते

मुझे लगता है कि यह मामला कोई समस्या नहीं है क्योंकि main यह जांचने में सक्षम होना चाहिए कि साइडकार कब प्रारंभ किया गया है (या एक तत्परता जांच का उपयोग करें)। इस मुद्दे के लिए यह मामला नहीं है क्योंकि main निकल गया होगा :)

मैंने एक साधारण स्क्रिप्ट लिखना समाप्त कर दिया जो कुबेरनेट्स एपीआई देखता है और एक मिलान एनोटेशन के साथ नौकरियों को समाप्त करता है और जिसका मुख्य कंटेनर निकल गया है। यह सही नहीं है लेकिन यह मूल आवश्यकता को संबोधित करता है। अगर लोग रुचि रखते हैं तो मैं इसे साझा कर सकता हूं।

@ajbouh यदि आप इसे एक सार के रूप में साझा करते हैं तो मैं व्यक्तिगत रूप से सराहना

@nrmitchi यहाँ मैंने जो यमल लिखा है उसका सार है। यह बहुत ही शेल स्क्रिप्ट है, लेकिन शायद यह आपके लिए एक अच्छा प्रारंभिक बिंदु है, जिसके संदर्भ में एपीआई का उपयोग करना है और कुछ ऐसा कैसे प्राप्त करना है जो काम करता है। यदि आपके कोई प्रश्न हैं, तो मैं इस बारे में प्रश्नों का उत्तर दे सकता हूं कि यह क्या कर रहा है।

https://gist.github.com/ajbouh/79b3eb4833aa7b068de640c19060d126

मेरे पास @mrbobbytables के समान क्लाउड SQL प्रॉक्सी उपयोग केस है। क्लाउड SQL से सुरक्षित रूप से कनेक्ट होने के लिए प्रॉक्सी का उपयोग करने की अनुशंसा की जाती है, लेकिन काम पूरा होने पर वह प्रॉक्सी समाप्त नहीं हो रहा है, जिसके परिणामस्वरूप पागल हैक या निगरानी निम्न की तरह दिखती है। क्या इस पर आगे बढ़ने का कोई रास्ता है?

@ amaxwell01 इसमें क्लाउड एसक्यूएल प्रॉक्सी की भागीदारी के संबंध में, मैंने Google के साथ एक मुद्दा खोला था जिसे आप अपडेट के लिए तारांकित या देख सकते हैं: https://issuetracker.google.com/issues/70746902 (संपादित करें: और मुझे मेरे द्वारा उपयोग किए जाने वाले कुछ वाक्यांशों पर खेद है इस समय की गर्मी में; दुर्भाग्य से मैं इसे संपादित नहीं कर सकता)

धन्यवाद @abevoelker मैं वहां आपकी पोस्ट का अनुसरण कर रहा हूं। साथ ही आपकी टिप्पणियों ने मुझे हंसाया

हम भी इस मुद्दे से प्रभावित हैं।
हमारे पास हमारी सूक्ष्म सेवाओं पर कई django प्रबंधन आदेश हैं जो k8s cronjobs पर चल सकते हैं लेकिन क्लाउडस्क्लप्रॉक्सी साइडकार की वजह से सफल होने में असफल होते हैं जो नौकरी पूरा होने पर नहीं रुकते हैं।
हमारे पास कोई समाधान कब हो सकता है इस पर कोई अपडेट?
साइडकार कंटेनर पैटर्न का अधिक से अधिक उपयोग किया जाता है और हम में से बहुत से लोग k8s cronjobs और जॉब का उपयोग तब तक नहीं कर पाएंगे जब तक कि इसका समाधान नहीं हो जाता।

बस इसके लिए मेरे +1 में फेंकना चाहता था। मेरे पास एक ही जीसीई क्लाउड एसक्यूएल प्रॉक्सी मुद्दा है जो हर किसी के रूप में है। यह मुझे मार रहा है ... हेल्म परिनियोजन विफल रहता है जो बदले में मेरा टेराफॉर्म लागू होता है।

वास्तव में इस पर किसी प्रकार का संकल्प देखना चाहेंगे ... जिस्ट @ajbouh से हैकी है।

किसी और के लिए cloudsql-proxy , क्या यह आपके उपयोग के मामले में cloudsql-proxy को डेमनसेट के रूप में चलाने के लिए उपयुक्त होगा? मेरे मामले में मेरे पास लगातार परिनियोजन और क्रोनजॉब दोनों को प्रॉक्सी की आवश्यकता थी, इसलिए इसे अलग-अलग पॉड से अलग करना और इसके बजाय प्रति नोड एक उदाहरण संलग्न करना समझ में आया।

हां,

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

बुधवार, 7 फरवरी, 2018 को सुबह 9:37 बजे, रोब जैक्सन सूचनाएं @github.com
लिखा था:

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment-363710890 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ACAWMwetx6gA_SrHL_RRbTMJVOhW1FKLks5tSW7JgaJpZM4IiqQH
.

दिलचस्प है, एक डीमोंसेट का उपयोग करना एक अच्छा विकल्प लगता है। @RJacksonm1 और @devlounge - डेमोंसेट का उपयोग करते समय क्लाउड sql प्रॉक्सी की खोज कैसे काम करती है?

यह मिला जो ऐसा लगता है कि यह चाल चलेगा ...
https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

मूल रूप से होस्ट आईपी प्राप्त करने के लिए कुछ इस तरह का उपयोग करना शामिल है:

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

@ RJacksonm1 - क्या hostPort काम करने के लिए आपने कुछ खास किया था? fieldPath: spec.nodeName दृष्टिकोण के संयोजन के साथ इसका उपयोग करते समय मुझे लगातार connection refused मिल रहा है

संपादित करें: मैंने सुनिश्चित किया है कि spec.nodeName सही ढंग से हो रहा है और मैं GKE v1.9.2-gke.1 पर हूं

@cvallance मेरे पास cloudsql-proxy इंस्टेंस से बात करेगा, लेकिन यह गारंटी देता है कि cloudsql-proxy पूरे क्लस्टर के साथ स्केल करेगा (मूल रूप से मेरे पास था एक परिनियोजन और एक क्षैतिज पॉडऑटोस्केलर के रूप में प्रॉक्सी, लेकिन पाया कि यह बहुत अधिक बढ़ रहा है - जिससे ऐप में MySQL has gone away त्रुटियां हो रही हैं)। मुझे लगता है कि यह डेमनसेट की सच्ची भावना में नहीं है...

@RJacksonm1 - इसे hostPort और spec.nodeName साथ काम कर रहा है ... अब वे सीधे अपने नोड पर डेमनसेट से जुड़ेंगे

CloudSql प्रॉक्सी कमांड काम नहीं कर रहा है:
-instances={{ .Values.sqlConnectionName }}=tcp:{{ .Values.internalPort }}
काम कर रहे:
-instances={{ .Values.sqlConnectionName }}=tcp:0.0.0.0:{{ .Values.internalPort }}

‍♂️

क्या इस मुद्दे पर कुछ ध्यान आकर्षित करने के लिए हम कुछ कर सकते हैं?
यह लगभग 2 वर्षों से खुला है और अभी भी हमारे पास केवल समाधान हैं

मुझे संदेह है कि भले ही मैं इसे लागू करने के लिए स्वयंसेवा करता हूं, मैं नहीं कर पाऊंगा क्योंकि इसे आंतरिक लोगों से कुछ अनुमोदन की आवश्यकता है कि किस समाधान को लागू करना है, एपीआई परिवर्तन, आदि।

इसे पूरा करने में मदद के लिए मैं कुछ भी कर सकता हूं?

संदर्भ के लिए मैंने @ jmillikin-stripe के वर्कअराउंड का क्लाउड-एसक्यूएल-प्रॉक्सी साइडकार संस्करण बनाया, जहां एक साझा वॉल्यूम में एक फ़ाइल राज्य को साइडकार से संचार करती है।

यह ठीक काम करता है, लेकिन मेरे K8s कॉन्फ़िगरेशन में अब तक का सबसे गंदा हैक है :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

क्या इस परियोजना में कोई आंतरिक व्यक्ति कृपया इस मुद्दे की प्रगति पर टिप्पणी कर सकता है?

यहाँ एक ही मुद्दा

cc @kubernetes/sig-apps-feature-requests @kubernetes/sig-node-feature-requests

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

apiVersion: batch/v2beta1
kind: Job
metadata:
  name: my-job
  namespace: app
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-job-image
          ...
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.11
          ...
  backoffLimit: 2
  jobCompletedWith:
    - my-container

यानी पॉड चलेगा, तब तक प्रतीक्षा करें जब तक my-container सफलतापूर्वक बाहर न निकल जाए, और फिर बस cloudsql-proxy समाप्त कर दें।

संपादित करें: इस धागे को स्क्रॉल करना, अब मैं देखता हूं कि यह पहले प्रस्तावित किया गया है। क्या @erictune या कोई और शायद इस बात पर फिर से विस्तार कर सकता है कि यह काम क्यों नहीं करेगा?

हाँ मुझे लगता है कि यह एकदम सही होगा। बस कुछ ऐसा जो आपको कार्य की स्थिति देखने और उसके पूरा होने के बाद पाइपलाइन जारी रखने की अनुमति देता है

हाँ, यह एकदम सही होगा।

मुझे यह विचार पसंद है @jpalomaki

जॉब कंट्रोलर के भीतर इसे पूरी तरह से हल करने के दृष्टिकोण के साथ मेरी एक चिंता यह है कि जॉब खत्म होने के बाद भी पॉड चलता रहेगा। वर्तमान में, पॉड टर्मिनेटेड चरण में प्रवेश करता है और नोड उन संसाधनों को मुक्त कर सकता है।

जब नियंत्रक निर्णय लेता है तो आप जॉब कंट्रोलर पॉड को हटा सकते हैं, लेकिन यह वर्तमान व्यवहार से भी अलग होगा, जहां टर्मिनेटेड पॉड रिकॉर्ड एपीआई सर्वर (नोड संसाधनों को उठाए बिना) में रहता है।

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

मैं एक कंटेनर द्वारा उत्पादित फ़ाइलों को अपलोड करने के लिए एक समाधान की तलाश में हूं यदि प्रोसेसर कंटेनर सफलतापूर्वक बाहर निकल गया।

मैं नहीं यकीन है कि मैं साइड कार कंटेनर k8s एपीआई के माध्यम से कंटेनर स्थिति देखने को पता है अगर और जब अपलोड करने या बाहर निकलने शुरू करने के लिए होने के खिलाफ बनाया @mingfang द्वारा तर्क समझ में कर रहा हूँ। जब साइडकार कंटेनर पॉड से बाहर निकलता है और जॉब सफलतापूर्वक बाहर निकल जाना चाहिए।

एक और विचार, जो एक हैक की तरह प्रतीत होता है, लेकिन मैं जानना चाहता हूं कि डेटा उत्पादक कंटेनर को एक इनिट कंटेनर में बनाना कितना बुरा होगा, और डेटा अपलोड करने वाला कंटेनर होगा (जिसे अब साइडकार कंटेनर होने की आवश्यकता नहीं होगी ) प्रोसेसर कंटेनर के सफलतापूर्वक बाहर निकलने के बाद ही स्वचालित रूप से शुरू होता है। मेरे मामले में प्रसंस्करण कंटेनर को डेटा प्रदान करने के लिए मुझे पहले init कंटेनर के रूप में डेटा डाउनलोडर कंटेनर की भी आवश्यकता होगी .. यदि यह एक विशेष रूप से बुरा विचार है, तो मुझे यह जानना अच्छा लगेगा कि क्यों।

प्रथम श्रेणी k8s अवधारणा के लिए साइडकार को बढ़ावा देने से इस समस्या का समाधान नहीं होगा? क्यूबलेट पॉड को समाप्त करने में सक्षम होगा यदि इसमें चल रहे सभी कंटेनरों को साइडकार के रूप में चिह्नित किया गया है।

एफडब्ल्यूआईडब्ल्यू, मैंने क्लाउड एसक्यूएल प्रॉक्सी को नियमित परिनियोजन ( replicas: 1 ) के रूप में तैनात करके इस पर काम किया और अपने Job और CronJob को type: ClusterIP माध्यम से इसका उपयोग किया। सेवा। नौकरियां अब ठीक हैं।

मुझे इस पर एक आधिकारिक स्थिति पसंद आएगी।

अगर हमें एपीआई से कुछ समर्थन नहीं मिलने वाला है, तो हमारे पास कम से कम वैकल्पिक समाधान आधिकारिक रूप से प्रलेखित होने चाहिए ताकि लोग जान सकें कि इस समस्या का सामना करने पर उन्हें क्या करना चाहिए।

मुझे नहीं पता कि किसे पिंग करना है या इस पर कैसे ध्यान दिया जाए...

इस पर ध्यान देना वास्तव में अच्छा होगा। नौकरी के अलावा कभी दूर नहीं जा रहा है, समग्र पॉड स्थिति स्पष्ट रूप से गलत है:

Init Containers:
  initializer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:52:57 -0500
      Finished:     Wed, 21 Mar 2018 17:52:57 -0500
    Ready:          True
Containers:
  sideCar:
    State:          Running
      Started:      Wed, 21 Mar 2018 17:53:40 -0500
    Ready:          True
  mainContainer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:53:41 -0500
      Finished:     Wed, 21 Mar 2018 17:55:12 -0500
    Ready:          False
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 

दिलचस्प बात यह है कि राज्य और तैयार initContainer (समाप्त, पूर्ण, तैयार = सत्य) और मुख्य ऐप कंटेनर (समाप्त, पूर्ण, तैयार = गलत) के लिए तैयार है। ऐसा लगता है कि ओवर पॉड रेडी स्टेट ऑफ फाल्स - मेरे विचार में, गलत तरीके से चला रहा है। यह इस पॉड को हमारे डैशबोर्ड पर एक समस्या के रूप में चिह्नित करने का कारण बन रहा है।

मेरे पास एक अन्य ग्राहक है जो विशेष रूप से क्लाउड SQL प्रॉक्सी के साथ इस समस्या का सामना कर रहा है। वे क्रॉन जॉब्स को क्लाउड एसक्यूएल तक पहुंचने की अनुमति देने के लिए इसे लगातार सेवा के रूप में नहीं चलाना चाहते हैं।

@yuriatgoogle सबसे आसान समाधान अभी भी बैश और खाली हैDir "जादू" जैसे: https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -365924958

यह एक हैक है, लेकिन इसे करना होगा। @फिदाह के लिए कोई अपराध करने का इरादा नहीं है।

यह निश्चित रूप से ऐसा लगता है कि बहुत से लोग इसे कई कारणों से चाहते हैं। कुछ आधिकारिक समर्थन प्राप्त करना अच्छा होगा। मुझे अपने स्वयं के साइडकार और नौकरियों के साथ एक ही समस्या थी, इसलिए मैंने साइडकार को पॉड में अन्य कंटेनर की स्थिति देखने के लिए क्यूब एपीआई का उपयोग किया था, अगर इसे completed के साथ समाप्त किया गया तो साइडकार 0 से बाहर निकल जाएगा, अगर इसने गलती की कि साइडकार 1 से बाहर निकल जाएगा। शायद सबसे सुंदर समाधान नहीं है, लेकिन इसने हमारे डेवलपर्स को बहुत कुछ बदलने की आवश्यकता के बिना चाल चली। अगर किसी की दिलचस्पी है तो कोड यहां है: https://github.com/uswitch/vault-creds/blob/master/cmd/main.go#L132।

यह मुझे एक गोरिल्लाज़ गीत M1 A1 की याद दिलाता है...

नमस्ते? नमस्ते? क्या वहां कोई है?

हाँ, कृपया कुछ कर्षण प्राप्त करें +1

तो प्रस्तावित समाधान जिनके लिए अपस्ट्रीम परिवर्तन की आवश्यकता है वे हैं:

1. sidecar: true द्वारा @jmillikin-stripe
2. @msperl . द्वारा अतिरिक्त जीवनचक्र हुक
3. jobCompletedWith @jpalomaki . द्वारा

साइडकार के लिए अस्थायी समाधान, एक हैकी (लेकिन काम करता है):

1. cloudsql-proxy साइडकार के लिए @phidah . द्वारा

मुझे प्रस्तावित समाधानों के बारे में कुबेरनेट्स अनुरक्षक से प्रतिक्रिया देखना अच्छा लगेगा और कृपया हमें मौजूदा कुबेरनेट्स संस्करण का उपयोग करके इस उपयोग के मामले को हल करने के बारे में सिफारिश दें। धन्यवाद!

एक लॉग एजेंट लिखने की कोशिश में एक दिन बिताने के बाद बस इस धागे की खोज की, जो मेरे प्रतिपादन कार्य के stdout/stderr को डेटाबेस में अपलोड करेगा, केवल यह पता लगाने के लिए कि पॉड में एजेंट की उपस्थिति का अर्थ यह होगा कि नौकरी कभी समाप्त नहीं होगी।

ऊपर दिए गए सुझावों में से, मुझे 'साइडकार: ट्रू' सबसे अच्छा लगता है, क्योंकि यह सरल और सीधी बात है - मेरे जैसे डेवलपर के लिए बहुत समझ में आता है। मैं शायद इसे कुछ अलग कहूंगा, क्योंकि 'साइडकार' वास्तव में एक पॉड डिज़ाइन पैटर्न है जो केवल नौकरियों से अधिक पर लागू होता है और पूरा होने की आवश्यकताओं के अलावा अन्य चीजों का तात्पर्य है। यदि आप मेरी बाइकशेडिंग का बहाना करेंगे, तो मैं शायद इसे 'परिवेश: सत्य' जैसा कुछ कहूंगा, यह इंगित करने के लिए कि कार्य को पूरा माना जा सकता है, भले ही यह कार्य अभी भी चल रहा हो। अन्य शब्द 'सहायक' या 'समर्थन' हो सकते हैं।

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

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

यह मेरा आदर्श समाधान भी है। मैं SIGTERM के बजाय SIGHUP का सुझाव दे सकता हूं - यह सटीक उपयोग का मामला प्रतीत होता है जिसके लिए SIGHUP के शब्दार्थ प्रासंगिक हैं! - लेकिन मैं दोनों में से किसी एक के साथ खुश रहूंगा।

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

मैं इसके लिए एक पैच बनाने को तैयार हूं लेकिन किसी भी कोड में खुदाई करने से पहले @ Kubernetes/sig-apps-feature-requests से कुछ मार्गदर्शन चाहता हूं। क्या हम इस काम को करने के लिए पॉड स्पेक में sidecar फ़ील्ड जोड़ने के साथ ठीक हैं? मैं यह सुनिश्चित किए बिना पॉड स्पेक में कोई भी बदलाव करने में संकोच करता हूं कि हम इसे चाहते हैं। शायद अभी के लिए एनोटेशन का उपयोग करें?

@andrewsykim मैं थोड़ी देर के लिए इस मुद्दे का पालन कर रहा हूं (बस इसे स्वयं संबोधित करने की कोशिश करने के लिए नहीं मिला है), लेकिन मैं अभी के लिए एनोटेशन का उपयोग करने का सुझाव दूंगा।

मेरा तर्क यह है कि:

• यह समस्या लगभग 2 वर्षों से है, और वास्तव में कुबेरनेट्स कोर से बहुत अधिक ध्यान नहीं खींचा है। इसलिए, यदि हम पॉड स्पेक में परिवर्तन करने की प्रतीक्षा करते हैं, या सीधे इनपुट की प्रतीक्षा करते हैं, तो हम शायद लंबे समय तक प्रतीक्षा करेंगे।
• एक पुराने मुद्दे की तुलना में एक व्यावहारिक पीआर कुछ ध्यान आकर्षित करना बहुत आसान है।
• भविष्य में पॉड विशेषता का उपयोग करने के लिए एनोटेशन दृष्टिकोण को स्विच करना प्रत्येक के लिए सुंदर होना चाहिए

विचार?

नमस्ते, मैंने इस मुद्दे के बारे में क्यूबकॉन में कुछ सिग-ऐप्स लोगों से बात की, मूल रूप से यह ऐसा कुछ नहीं है जो उनके तत्काल रोडमैप पर है, लेकिन यह ऐसा कुछ है जो उन्हें लगता है कि एक वैध उपयोग-मामला है। वे इससे निपटने वाले समुदाय के किसी व्यक्ति के लिए बहुत खुले हैं।

मैंने इसे हल करने के लिए एक एन्हांसमेंट प्रस्ताव के लिए एक पीआर बनाया है, इसलिए मुझे आशा है कि यह कुछ चर्चा https://github.com/kubernetes/community/pull/2148 उत्पन्न करता है

इसे एक साथ रखने के लिए धन्यवाद @ जोसेफ-इरविंग! ऐसा लगता है कि इसके लिए और अधिक विवरण हैं जिन्हें संबोधित करने की आवश्यकता है, इसलिए मैं तब तक कोई भी काम करने पर रोक लगाऊंगा :)

लगातार-दीर्घकालिक-समस्या :(

cc @ kow3ns @janetkuo

मामले को और अधिक जटिल बनाने के अर्थ के बिना, initContainers साथ "साइडकार" स्टाइल कंटेनर चलाने में सक्षम होना भी उपयोगी होगा।

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

@mcfedr एक उचित रूप से सक्रिय वृद्धि प्रस्ताव है जो init कंटेनर व्यवहार के संबंध में उस अवलोकन की सराहना कर सकता है। यह मेरे लिए स्पष्ट नहीं है कि यह इस प्रस्ताव के दायरे में है, या संबंधित सुधार है, लेकिन मुझे लगता है कि यह पर्याप्त रूप से संबंधित है कि विचार के लिए उठाना समझ में आता है।

संभावित कार्यान्वयन/संगतता समस्याओं के बावजूद, आपका आदर्श मॉडल संभवतः साइडकार इनिट कंटेनरों के लिए गैर-साइडकार इनिट कंटेनरों के साथ समवर्ती रूप से चलने के लिए होगा, जो अब तक क्रमिक रूप से चलते रहते हैं, और साइडकार्स के लिए मुख्य अनुक्रम कंटेनर शुरू होने से पहले समाप्त हो जाते हैं?

इसके लायक क्या है, मैं अभी भी CloudSQL Proxy et.al जैसे चल रहे साइडकार्स को अनदेखा करने की आवश्यकता व्यक्त करना चाहूंगा।

मैं 30 सेकंड के बाद क्लाउडस्क्ल कंटेनर को मारने में कामयाब रहा क्योंकि मुझे पता है कि मेरी स्क्रिप्ट में इतना समय नहीं लगेगा। यहाँ मेरा दृष्टिकोण है:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: schedule
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  startingDeadlineSeconds: 40
  jobTemplate:
    spec:
      completions: 1
      template:
        spec:
          containers:
          - image: someimage
            name: imagename
            args:
            - php
            - /var/www/html/artisan
            - schedule:run
          - command: ["sh", "-c"]
            args:
            - /cloud_sql_proxy -instances=cloudsql_instance=tcp:3306 -credential_file=some_secret_file.json & pid=$! && (sleep 30 && kill -9 $pid 2>/dev/null)
            image: gcr.io/cloudsql-docker/gce-proxy:1.11
            imagePullPolicy: IfNotPresent
            name: cloudsql
            resources: {}
            volumeMounts:
            - mountPath: /secrets/cloudsql
              name: secretname
              readOnly: true
          restartPolicy: OnFailure
          volumes:
          - name: secretname
            secret:
              defaultMode: 420
              secretName: secretname

और यह मेरे लिए काम कर रहा है।
क्या आप लोगों को इस दृष्टिकोण में कोई कमी नजर आती है?

चूंकि मुझे लगता है कि वे संबंधित हैं और क्रोनजॉब्स के लिए भी आसानी से अनुकूलनीय हैं, यह मेरा समाधान है: https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/128#issuecomment -413444029

यह यहां पोस्ट किए गए वर्कअराउंड में से एक पर आधारित है लेकिन preStop का उपयोग करता है क्योंकि यह तैनाती के लिए है। साइडकार को फँसाना आश्चर्यजनक रूप से काम करेगा।

इस मुद्दे के बाद। साथ ही cronjob में साइड कार के रूप में cloud_sql_proxy कंटेनर का उपयोग करना
मैंने @stiko . द्वारा टाइमआउट कार्यान्वयन का उपयोग किया

बस बातचीत में जोड़ने के लिए @oxygen0211 द्वारा प्रतिस्थापन का उपयोग करने पर प्रस्तावित समाधान अभी के लिए एक अच्छा समाधान है, अगर आप इस मुद्दे में भाग लेते हैं तो इसे जांचना सुनिश्चित करें जैसे मैंने किया था।

https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -327396198

हमें यह केईपी अस्थायी रूप से स्वीकृत https://github.com/kubernetes/community/pull/2148 मिल गया है, हमारे पास अभी भी कुछ चीजें हैं जिन पर हमें सहमत होने की आवश्यकता है, लेकिन उम्मीद है कि यह एक ऐसी जगह पर पहुंच जाएगा जहां अपेक्षाकृत जल्द ही काम शुरू हो सकता है . ध्यान दें कि केईपी 30 तारीख को https://github.com/kubernetes/enhancements पर चले जाएंगे, इसलिए यदि आप इसके साथ चलना चाहते हैं तो यह वहां पर होगा।

जब तक साइडकार सपोर्ट नहीं आता तब तक आप डॉक-लेवल सॉल्यूशन का उपयोग कर सकते हैं जिसे बाद में आसानी से हटाया जा सकता है: https://gist.github.com/janosroden/78725e3f846763aa3a660a6b2116c7da

यह काम में कंटेनरों का प्रबंधन करने के लिए एक माउंटेड डॉकटर सॉकेट और मानक कुबेरनेट्स लेबल के साथ एक विशेषाधिकार प्राप्त कंटेनर का उपयोग करता है।

हम इस्तियो और उसकी साइड कार के साथ एक ही समस्या कर रहे थे, और हमने जो करने का फैसला किया है वह कर्ल + प्रीस्टॉप हुक के माध्यम से पॉड को हटा देता है।

अपने काम को इस तरह न्यूनतम RBAC नियम दें

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myservice-job
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-job-rolebinding
subjects:
  - kind: ServiceAccount
    name: myservice-job
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myservice-role

और POD_NAME और POD_NAMESPACE जैसे आपके ENV को

   env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

और अंत में, एक प्रीस्टॉप हुक जोड़ें जैसे

 lifecycle:
      preStop:
        exec:
          command: 
            - "/bin/bash" 
            - "-c"
            - "curl -X DELETE -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$POD_NAMESPACE/pods/$POD_NAME?gracePeriodSeconds=1"

सही डॉकटर कंटेनर को मारने की कोशिश की तुलना में गन्दा लेकिन थोड़ा सुरक्षित और कम बारीक।

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

https://github.com/nrmitchi/k8s-controller-sidecars

cloud_sql_proxy को ClusterIP सेवा के साथ परिनियोजन के रूप में चलाने के सुझाव के लिए https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -371469801 पर @jpalomaki के लिए धन्यवाद, और @ पर https://github.com/kubernetes/kubernetes/issues/25908#issuecomment स्थापित करने पर टिप के लिए -+३६,४२,५५,३६३ tcp:0.0.0.0 में cloud_sql_proxy instances पैरामीटर अनुमति देने के लिए गैर प्रक्रिया के लिए स्थानीय कनेक्शन। साथ में उन लोगों ने क्रॉन जॉब्स को प्रॉक्सी का उपयोग करने देना दर्द रहित बना दिया।

दीर्घकालिक मुद्दा (स्वयं को नोट)

वही मुद्दा। Cloud SQL साथ GKE क्रॉन जॉब का उपयोग करने के तरीके के बारे में एक रास्ता या आधिकारिक दस्तावेज़ खोज रहे हैं

पक्षीय लेख:
Google ने अपने क्लाउड SQL को अपडेट किया -> Google Kubernetes Engine दस्तावेज़ Connecting using the Cloud SQL Proxy Docker image आप Connecting using a private IP address
इसलिए यदि आप यहां उसी कारण से हैं, तो मैं यहां हूं (क्लाउड_एसक्यूएल_प्रॉक्सी के कारण), अब आप निजी आईपी की नई सुविधा का उपयोग कर सकते हैं

पक्षीय लेख:
Google ने अपने क्लाउड SQL को अपडेट किया -> Google Kubernetes Engine दस्तावेज़ Connecting using the Cloud SQL Proxy Docker image आप Connecting using a private IP address
इसलिए यदि आप यहां उसी कारण से हैं, तो मैं यहां हूं (क्लाउड_एसक्यूएल_प्रॉक्सी के कारण), अब आप निजी आईपी की नई सुविधा का उपयोग कर सकते हैं

ऐसा लगता है कि निजी आईपी सुविधा को पूरे क्लस्टर को हटाने और एक को फिर से बनाने की जरूरत है ......?

@cropse इसकी आवश्यकता केवल तभी है जब आपका क्लस्टर

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

बस मेरे दो सेंट जोड़ने के लिए: अगर पॉड कभी पूरा नहीं होता है तो इस्तियो साइडकार का इंजेक्शन लगने पर हेल्म टेस्ट भी टूट जाता है।

@dansivter आप मेरे वर्कअराउंड की जांच कर सकते हैं, मैंने पहले ही अपने प्रोजेक्ट में

इसे लागू होते देखने के लिए उत्सुक हैं! :)

हमारे पास सामान्य नौकरियों के साथ एक ही समस्या है जब एक इस्तियो प्रॉक्सी को इंजेक्ट किया जाता है, इसके ऊपर हम यह भी चाहते हैं क्योंकि हम प्रो के साथ सीआई जॉब चलाना चाहते हैं।
उदाहरण के लिए परीक्षण उद्देश्यों के लिए रेल ऐप कंटेनर + साइडकार डेटाबेस कंटेनर।

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

FYI करें, इस सुविधा के लिए ट्रैकिंग समस्या यहाँ खत्म हो गई है https://github.com/kubernetes/enhancements/issues/753 अगर लोग साथ चलना चाहते हैं, तो हमारे पास एक केईपी है, कुछ प्रोटोटाइप किया है (एक पीओसी शाखा/वीडियो है ), अभी भी कार्यान्वयन योग्य स्थिति में होने से पहले कुछ कार्यान्वयन विवरणों को आयरन करने की आवश्यकता है।

पक्षीय लेख:
Google ने अपने क्लाउड SQL को अपडेट किया -> Google Kubernetes Engine दस्तावेज़ Connecting using the Cloud SQL Proxy Docker image आप Connecting using a private IP address
इसलिए यदि आप यहां उसी कारण से हैं, तो मैं यहां हूं (क्लाउड_एसक्यूएल_प्रॉक्सी के कारण), अब आप निजी आईपी की नई सुविधा का उपयोग कर सकते हैं

मैं यहाँ उसी कारण से था, हालाँकि, इस सुविधा के तैयार होने से पहले हमारे क्लाउड SQL का प्रावधान किया गया था। मैंने पिछले सुझावों को जोड़ दिया और मेरे डीबीमेट माइग्रेटर हेल्म चार्ट के लिए इसे (शायद आदर्श नहीं, लेकिन यह काम करता है) निकला।

      containers:
      - name: migrator
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/bin/bash", "-c"]
        args:
          - |
            /cloud_sql_proxy -instances={{ .Values.gcp.project }}:{{ .Values.gcp.region }}:{{ .Values.gcp.cloudsql_database }}=tcp:5432 -credential_file=/secrets/cloudsql/credentials.json &
            ensure_proxy_is_up.sh dbmate up
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: DATABASE_URL
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials

ensure_proxy_is_up.sh

#!/bin/bash

until pg_isready -d $(echo $DATABASE_URL); do
    sleep 1
done

# run the command that was passed in
exec "$@"

क्या यह कुबेरनेट्स में साइडकार कंटेनरों की धारणा के लिए एक अच्छा समय होगा और गैर-साइडकार कंटेनरों के समाप्त होने के आधार पर पॉड को साफ करने की अनुमति होगी?

@ विलक्स मैं अपने फोन एटीएम पर हूं, इसलिए संदर्भ के लिए लिंक

@krancour अपडेट के लिए धन्यवाद। मुझे वह विवरण याद आ गया होगा। हाल ही में यहां बहुत अधिक गतिविधि नहीं हो रही थी, इसलिए मैं यह सुनिश्चित करना चाहता था कि कुछ चल रहा है :)

संदर्भ के लिए मैंने @ jmillikin-stripe के वर्कअराउंड का क्लाउड-एसक्यूएल-प्रॉक्सी साइडकार संस्करण बनाया, जहां एक साझा वॉल्यूम में एक फ़ाइल राज्य को साइडकार से संचार करती है।

यह ठीक काम करता है, लेकिन मेरे K8s कॉन्फ़िगरेशन में अब तक का सबसे गंदा हैक है :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

क्या इस परियोजना में कोई आंतरिक व्यक्ति कृपया इस मुद्दे की प्रगति पर टिप्पणी कर सकता है?

क्या यह मान लेना उचित है कि जीकेई के स्थिर रिलीज चैनल पर काम करने वालों के लिए यह सबसे अच्छा विकल्प है, जो शायद कम से कम कुछ महीनों के लिए कुबेरनेट्स 1.18 तक नहीं पहुंच पाएगा?

@Datamance इस बिंदु पर KEP इस मुद्दे को हल करने के लिए ऐसा लगता है कि यह अनिश्चित काल के लिए होल्ड पर है ।

मैंने कुछ समय पहले यह टिप्पणी पोस्ट की थी, जो मेरा पुराना समाधान था। मैं यहां अपनी खुद की सामग्री को आगे बढ़ाने की कोशिश नहीं कर रहा हूं, बस वह टिप्पणी जीथब की "100 और टिप्पणियों ..." में खो गई है और यह फिर से उपयोगी हो सकता है।

@nrmitchi इसे दोबारा पोस्ट करने के लिए धन्यवाद। मैं वह हूं जिसने टिप्पणियों के समुद्र में इसे अनदेखा कर दिया था और यह एक शानदार निकट अवधि के समाधान की तरह दिखता है।

यदि आप अपने पॉड कंटेनर में निम्नलिखित जोड़ते हैं, तो हम एक अलग दृष्टिकोण का पता लगाते हैं:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

तब आप अन्य कंटेनरों में पिड को पकड़ने में सक्षम होंगे, हम अपने मुख्य कंटेनर के अंत में निम्नलिखित चलाएंगे:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@krancour खुशी है कि इससे मदद मिली। यदि आप उस भंडार में नेटवर्क को देखते हैं तो कुछ कांटे हैं जो लगभग निश्चित रूप से मेरे मूल स्थान से बेहतर जगह पर हैं, और इसका निर्माण/उपयोग करना बेहतर हो सकता है।

आईआईआरसी नींबू पानी-एचक्यू कांटा में कुछ उपयोगी जोड़ थे।

@nrmitchi , मैं कोड पर

क्या आप संक्षेप में टिप्पणी कर सकते हैं कि ऐसी कौन सी पूर्व-आवश्यकताएं मौजूद हो सकती हैं जिनका रीडमे में उल्लेख नहीं किया गया है?

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

@krancour मैं अपनी प्रतिक्रिया को एक नोट के साथ प्रस्तुत करूंगा कि यह समाधान कुछ साल पहले लिखा गया था और मेरी याददाश्त थोड़ी

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

साइडकार्स की एकमात्र आवश्यकता यह है कि वे SIGTERM सिग्नल को ठीक से सुनते हैं, और फिर बंद हो जाते हैं। मुझे याद है कि साइडकार्स में चल रहे थर्ड-पार्टी कोड के साथ कुछ समस्याएं थीं जो एक अलग सिग्नल की उम्मीद कर रहे थे और उन्हें चारों ओर काम करना था, लेकिन वास्तव में नियंत्रक को सिग्नल को निर्दिष्ट करने की अनुमति देनी चाहिए थी (यानी, सिगिनट के बजाय सिगिनट)।

उन्हें सिग्नल के लिए किसी पोर्ट को सुनने की आवश्यकता नहीं है, क्योंकि नियंत्रक साइडकार की मुख्य प्रक्रिया को सीधे सिग्नल करने के लिए exec का उपयोग करता है। आईआईआरसी उस समय कुबेरनेट्स कोड से कार्यक्षमता की प्रतिलिपि बनाई गई थी क्योंकि यह क्लाइंट में मौजूद नहीं था। मेरा मानना ​​है कि यह अब आधिकारिक क्लाइंट में मौजूद है और शायद इसे अपडेट किया जाना चाहिए।

यदि आप अपने पॉड कंटेनर में निम्नलिखित जोड़ते हैं, तो हम एक अलग दृष्टिकोण का पता लगाते हैं:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

तब आप अन्य कंटेनरों में पिड को पकड़ने में सक्षम होंगे, हम अपने मुख्य कंटेनर के अंत में निम्नलिखित चलाएंगे:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ ruiyang2015 इस हैक के लिए धन्यवाद।
यदि कोई इसे लागू कर रहा है, तो कंटेनरों के बीच एक प्रक्रिया एनएस साझा करने के निहितार्थ को

@nrmitchi

साइडकार की मुख्य प्रक्रिया को सीधे सिग्नल करने के लिए एक निष्पादन का उपयोग करता है

यही कारण है कि मैंने पूछा... मुझे लगता है, विशेष रूप से, मैं सोच रहा हूं कि यह FROM scratch निर्मित छवियों के आधार पर कंटेनरों के लिए काम नहीं करता है।

@krancour फेयर पॉइंट, मैं कभी नहीं गया और उन कंटेनरों के साथ परीक्षण किया जो बंद थे scratch । कोड को देखते हुए (या मेरा मूल संस्करण; यह फोर्क में बदल सकता था) ऐसा लगता है कि यह bash पर निर्भर होने जा रहा है, लेकिन इसे संशोधित करने में सक्षम होना चाहिए।

यह बैश पर निर्भर होने वाला है, लेकिन इसे संशोधित करने में सक्षम होना चाहिए

निश्चित रूप से, लेकिन जब तक यह निष्पादित हो रहा है, यह हमेशा कंटेनर में मौजूद कुछ बाइनरी पर निर्भर होने वाला है और स्क्रैच कंटेनर के लिए, वहां _कुछ भी नहीं है, जो कुछ भी आप स्पष्ट रूप से डालते हैं। ‍♂

उस सीमा को देखते हुए, मैं इसका उपयोग ऐसे उपयोग के मामले के लिए नहीं कर सकता जहां चल रहे कंटेनर पूरी तरह से मनमाने ढंग से और किसी तीसरे पक्ष द्वारा निर्दिष्ट किए जा सकते हैं। ओह-- और फिर मेरे पास विंडोज़ कंटेनर भी चल रहे हैं।

मैं इसका उल्लेख करूंगा कि इसके बजाय मैं किस पर समझौता करने जा रहा हूं। यह शायद अधिकांश उपयोग के मामलों के लिए बहुत भारी-भरकम है, लेकिन मैं इसका उल्लेख कर रहा हूं यदि किसी और के उपयोग का मामला इससे दूर होने के लिए मेरे जैसा ही है ...

मैं केवल _deleting_ एक पॉड जिसका "प्राथमिक" कंटेनर निकल चुका है, की विलासिता को वहन कर सकता हूं, जब तक कि मैं पहले बाहर निकलने की स्थिति रिकॉर्ड करता हूं। तो मैं एक नियंत्रक लिखना समाप्त करने जा रहा हूं जो पूरा होने के लिए कुछ नामित (एनोटेशन के माध्यम से) कंटेनर की निगरानी करेगा, डेटास्टोर में अपनी सफलता या विफलता रिकॉर्ड करेगा जो पहले से ही "नौकरी" स्थिति को ट्रैक करता है, और फिर पूरी तरह से पॉड को हटा देता है।

अच्छे उपाय के लिए, मैं शायद अपने केंद्रीय लॉग एकत्रीकरण के टारपीडो से पहले प्राथमिक कंटेनर के आउटपुट की अंतिम कुछ पंक्तियों को प्राप्त करने की संभावनाओं को अधिकतम करने के लिए पॉड डिलीट पर थोड़ा विलंब कर दूंगा।

भारी-भरकम, लेकिन कुछ के लिए काम कर सकता है।

@krancour पूरी तरह से सच है। जैसा है, नियंत्रक मनमाने ढंग से उपयोग-आधारों के लिए काम नहीं करेगा। ईमानदारी से, मैं कभी वापस नहीं गया और अन्य मामलों का समर्थन करने के लिए कुछ कार्यान्वयन को अमूर्त करने का प्रयास किया क्योंकि मैंने वास्तव में सोचा था कि पहले उल्लिखित केईपी को विलय कर दिया गया होगा और इस कार्यक्षमता की आवश्यकता को कम कर दिया जाएगा।

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

https://github.com/karlkfi/kubexit

इसका उपयोग करने के कुछ तरीके हैं:

1. इसे अपनी छवियों में बेक करें
2. एक इनिट कंटेनर और एक क्षणिक मात्रा का उपयोग करके इसे साइड लोड करें।
3. प्रत्येक नोड पर इसे प्रोविजन करें और होस्ट बाइंड माउंट का उपयोग करके इसे कंटेनरों में लोड करें

संपादित करें: v0.2.0 अब "जन्म निर्भरता" (देरी से शुरू) और "मृत्यु निर्भरता" (स्व-समाप्ति) का समर्थन करता है।

ड्राइव-बाय कमेंट: यह बिल्कुल https://github.com/kubernetes/enhancements/issues/753 जैसा दिखता है

@vanzin जैसा कि पहले उल्लेख किया गया है , कि केईपी अनिश्चितकालीन होल्ड पर है।

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