cc @ironcladlou @bgrant0607

स्पेक में बिना किसी बदलाव के पॉड्स को फिर से शुरू करने के लिए क्या उपयोग है?

ध्यान दें कि यदि पॉड्स पुनरारंभ होने पर विफल होने लगे तो परिवर्तन को रोलबैक करने का कोई तरीका नहीं होगा।

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

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

साथ ही, बिना किसी विशेष परिवर्तन के रोलिंग पुनरारंभ पॉड्स को पुन: आवंटित करता है
समूह।

हालांकि, मैं इसे पुनर्निर्धारित किए बिना ऐसा करने की क्षमता भी चाहूंगा
फली यह एक रोलिंग लेबल परिवर्तन हो सकता है, लेकिन यह नया डायनामिक ले सकता है
स्थानीय फ़ाइल स्थिति को कॉन्फ़िगर या साफ़ करें।

बुधवार, 2 सितंबर, 2015 को दोपहर 12:01 बजे, सैम घोड्स नोटिफिकेशन @github.com ने लिखा:

जब भी सेवाएं कुछ खराब या अवांछनीय स्थिति में आती हैं (अधिकतम आउट .)
कनेक्शन और अब ठप हैं, खराब आंतरिक स्थिति, आदि)। यह आमतौर पर है
यदि सेवा गंभीर है तो पहले समस्या निवारण चरणों में से एक
दुर्व्यवहार।

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

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

क्लेटन कोलमैन | लीड इंजीनियर, ओपनशिफ्ट

@smarterclayton क्या यह ऊपर सूचीबद्ध मेरे विकल्प 2 की तरह है? हालांकि लेबल क्यों बदले जाएंगे?

पुनः। वेज्ड: यही लिवनेस प्रोब के लिए है।

पुनः। पुनर्संतुलन: देखें #12140

अगर हमने इसका समर्थन किया, तो मैं इसे #9043 के साथ जोड़ दूंगा - उसी तंत्र की आवश्यकता है।

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

मुझे ऐसा लगता है कि किसी एप्लिकेशन को फिर से शुरू करने के लिए कहना काफी सामान्य उपयोग का मामला है, लेकिन शायद मैं गलत हूं।

भ्रष्टाचार सिर्फ एक पॉड होगा, जिसे बस मार दिया जा सकता है और आरसी द्वारा प्रतिस्थापित किया जा सकता है।

ऑफ़लाइन उल्लेख किया गया दूसरा मामला कॉन्फ़िगरेशन को फिर से पढ़ना था। यह स्पष्ट रूप से करना खतरनाक है, क्योंकि किसी भी कारण से पुनरारंभ करने से कंटेनर नए कॉन्फ़िगरेशन को लोड कर सकते हैं। पॉड्स के लिए एक नए संस्करण वाले कॉन्फिग संदर्भ (जैसे एक env var में) को पुश करने के लिए रोलिंग अपडेट करना बेहतर होगा। यह उसी के समान है जिसने #1353 को प्रेरित किया।

@bgrant0607 क्या हमने तय किया है कि हम ऐसा नहीं करना चाहते हैं?

@gmarek कुछ भी नहीं, अभी के लिए। बहुत सी चीजें पहले से ही चल रही हैं।

क्या हमारे पास उस सामान के लिए post v1.1 मील का पत्थर (या कुछ और) हो सकता है जिसे हम महत्वपूर्ण मानते हैं, लेकिन हमारे पास उन्हें तुरंत ठीक करने के लिए लोगों की कमी है?

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

मैं इस विशेषता का प्रशंसक हूं। केस का उपयोग करें: सभी पॉड्स को नई पुश की गई डॉक इमेज ( imagePullPolicy: Always ) का उपयोग करने के लिए आसानी से अपग्रेड करें। मैं वर्तमान में एक हैकी समाधान का उपयोग करता हूं: छवि नाम पर :latest टैग के साथ या उसके बिना रोलिंग-अपडेट।

एक और उपयोग का मामला: रहस्यों को अद्यतन करना।

मैं वास्तव में यह सुविधा देखना चाहूंगा। हम कुबेरनेट्स पर नोड ऐप्स चलाते हैं और वर्तमान में कुछ उपयोग के मामले हैं जहां हम ऐप छद्म कैशिंग में साफ़ करने के लिए पॉड्स को पुनरारंभ करते हैं।

यहाँ मैं अभी के लिए क्या कर रहा हूँ:

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

यह एक बार में पॉड्स 10 को हटाता है और एक प्रतिकृति नियंत्रक में अच्छी तरह से काम करता है। यह पॉड आवंटन या नए पॉड्स शुरू करने में विफल होने जैसी किसी भी चिंता का समाधान नहीं करता है। जरूरत पड़ने पर यह एक त्वरित समाधान है।

मैं वास्तव में रोलिंग पुनरारंभ करने में सक्षम होना चाहता हूं।
मुख्य कारण यह है कि हम ConfigMap का उपयोग करके ENV चर को पॉड्स में फीड करेंगे और फिर यदि हम कॉन्फिगरेशन बदलते हैं तो हमें उस ConfigMap के उपभोक्ताओं को पुनरारंभ करने की आवश्यकता होती है।

हां, ऐसे कई मामले हैं जब आप वास्तव में पॉड/कंटेनर को बिना किसी बदलाव के पुनरारंभ करना चाहते हैं ...
कॉन्फिग, कैशे, बाहरी सेवाओं से फिर से कनेक्ट करें, आदि। मुझे वास्तव में उम्मीद है कि यह सुविधा विकसित की जाएगी।

चारों ओर छोटा काम (मैं तैनाती का उपयोग करता हूं और मैं छवि/पॉड में वास्तविक परिवर्तन किए बिना कॉन्फ़िगरेशन बदलना चाहता हूं):

• कॉन्फिग मैप बनाएं
• किसी भी कंटेनर में ENV वैरिएबल के साथ परिनियोजन बनाएं (आप इसे अपने परिनियोजन के लिए संकेतक के रूप में उपयोग करेंगे)
• अद्यतन configMap
• अद्यतन परिनियोजन (इस ENV चर को बदलें)

k8s देखेंगे कि परिनियोजन की परिभाषा बदल दी गई है और पॉड्स को बदलने की प्रक्रिया शुरू हो जाएगी
पुनश्च:
अगर किसी के पास बेहतर समाधान है तो कृपया साझा करें

धन्यवाद @paunin

@paunin ठीक वही स्थिति है जहाँ हमें वर्तमान में इसकी आवश्यकता है - हमें ConfigMap मानों को बदलना होगा जो सेवाओं के लिए बहुत महत्वपूर्ण हैं और कुछ घंटों के भीतर कंटेनरों में रोल-आउट करने की आवश्यकता है। यदि इस दौरान कोई परिनियोजन नहीं होता है तो सभी कंटेनर एक ही समय में विफल हो जाएंगे और हमारे पास कम से कम कुछ सेकंड का आंशिक डाउनटाइम होगा

from (थोड़े से संबंधित # 9043): @paunin के दृष्टिकोण का एक-लाइनर, जहां RESTART_ पर्यावरण चर है, और यह एक आईएसओ टाइमस्टैम्प पर सेट है:

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(ध्यान दें कि किसी कारण से _ शुरू होने वाले पर्यावरण चर गायब हो जाते हैं, और संख्यात्मक env value त्रुटियों का कारण बनते हैं, उन्हें तार होने की आवश्यकता होती है)

@paunin @rcoup आजकल हम कुछ ऐसा ही करते हैं, हमारे पास एक env var है जिसे शाब्दिक रूप से "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT" कहा जाता है।

ऐसा लगता है कि यहां सही समाधान आपको एक परिनियोजन को पुनरारंभ करने में सक्षम करेगा, और MinReadyCount जैसे रोलआउट के लिए अधिकांश परिनियोजन मापदंडों का पुन: उपयोग करेगा, जबकि कमांड-लाइन ओवरराइड की अनुमति देता है जैसे कि आपातकालीन स्थितियों के लिए समानता को बढ़ाना जहां आपको तुरंत बाउंस करने के लिए सब कुछ चाहिए।

इस पर कोई प्रगति?

मुझे ऐसा लगता है कि यह जोड़ सीएलआई एपीआई की अनावश्यक सूजन है। इसे @paunin द्वारा सुझाए गए परिनियोजन परिवेश चर मानों

हम इसे kubectl restart deployment some-api जैसे परिनियोजन के लिए भी देखना चाहेंगे

कुबेरनेट्स को सभी प्रकार के कारणों से पॉड्स को पुनरारंभ करने की अनुमति है, लेकिन क्लस्टर व्यवस्थापक को इसकी अनुमति नहीं है।
मैं नैतिक रुख को समझता हूं कि 'इसे बंद करें और फिर से चालू करें' संचालित करने का एक वांछित तरीका नहीं हो सकता है ... कम स्वादिष्ट ट्रिक्स जैसे:

• फली हटाना
• डमी लेबल
• डमी पर्यावरण चर
• डमी कॉन्फिग मैप्स को पर्यावरण चर में मैप किया गया
• कार्यकर्ता नोड्स को रिबूट करना
• डेटा सेंटर की शक्ति में कटौती

'नहीं, नहीं, मैं कुछ भी पुनरारंभ नहीं कर रहा हूँ, बस यहाँ इस लेबल में एक टाइपो को ठीक कर रहा हूँ'

यह सुविधा kubectl apply साथ जोड़ी में उपयोगी होगी: apply प्रतिकृति नियंत्रकों सहित कॉन्फ़िगरेशन को अपडेट करेगा, लेकिन पॉड्स को पुनरारंभ नहीं किया जाएगा।

इसलिए हमें इन पॉड्स को ब्लू-ग्रीन तरीके से फिर से शुरू करने के लिए एक विधि की आवश्यकता है।

@DmitryRomanenko प्रतिकृति

@kargakis यह संभव नहीं है: परिनियोजन केवल प्रतिकृति सेट और पॉड्स अपडेट करते हैं।
kubectl apply हम ConfigMaps, Services आदि को भी अपडेट करते हैं।

@DmitryRomanenko यदि समस्या "मैं कॉन्फिग मैप/सीक्रेट अपडेट होने पर पॉड्स को पुनरारंभ करना चाहता हूं" तो संभावित समाधान आपके कॉन्फिग मैप और सीक्रेट्स के संस्करण हैं, और उस संस्करण को आपके परिनियोजन युक्ति का हिस्सा बनाते हैं। तो kubectl apply के साथ परिनियोजन की युक्ति बदल जाती है और पॉड्स को फिर से बनाया जाता है।
अन्य स्थितियों में मैं यह नहीं देखता कि पॉड्स को फिर से शुरू क्यों किया जाना चाहिए (मेरा मतलब है सेवा/प्रवेश/आदि अद्यतन)।

@tyranron , धन्यवाद! संस्करण ConfigMap s का सबसे अच्छा तरीका क्या है? क्या मुझे नए परिनियोजन के लिए किसी भिन्न नाम से नया कॉन्फ़िग मैप बनाना चाहिए?

@DmitryRomanenko आप वास्तव में कर सकते हैं, क्यों नहीं? लेकिन ऐसे में आपको पुराने को हटाने का ध्यान रखना चाहिए। दूसरी ओर यह रोलबैक के लिए उपयोगी हो सकता है। लेकिन ज्यादातर मामलों में लेबल के माध्यम से संस्करण निर्दिष्ट करना पर्याप्त है।

मुझे विश्वास है कि यहां सबसे अच्छा समाधान configmap ऑब्जेक्ट पर किसी प्रकार का द्रष्टा या हैश-सम चेकर हो सकता है। जो संबंधित वस्तुओं/पॉड्स को पुनरारंभ करना चाहिए (कुछ भी configmap , secret )। सुनिश्चित नहीं है कि यह k8s आर्किटेक्चर में कुछ सुलभ है हालांकि ...

मुझे यह भी लगता है कि परिवर्तनों पर पुनरारंभ ट्रिगर करने के लिए configmap|secret ऑब्जेक्ट से नियंत्रण रखना बेहतर है या नहीं।

@tyranron ,

तो Kubectl के साथ परिनियोजन की युक्ति को बदल दिया जाता है और पॉड्स को फिर से बनाया जाता है।

क्या आप समझाएँगे? क्या मुझे केवल अद्यतन परिनियोजन के साथ kubectl apply -f new_config.yml उपयोग करना चाहिए, और ये परिनियोजन रोलिंग-पुनरारंभ होंगे?

@DmitryRomanenko हाँ, बिल्कुल।

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

डिफ़ॉल्ट रूप से पुनरारंभ रणनीति है RollingUpdate , लेकिन आप स्पष्ट रूप से एक और भी निर्दिष्ट कर सकते हैं।

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

/lifecycle frozen टिप्पणी के साथ समस्याओं को स्वतः बंद होने से रोकें।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया /close साथ ऐसा करें।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या @fejta को फीडबैक भेजें।
/जीवनचक्र बासी

@rcoup के समाधान में एक छोटा सा परिवर्तन : सुनिश्चित करें कि date का मूल्यांकन शेल के भीतर किया गया है:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/निकालें-जीवनचक्र बासी
/जीवनचक्र जमे हुए

कुछ समय के लिए झुंड मोड का उपयोग कर रहा है जिसे कुबेरनेट्स की तुलना में कम लचीला माना जाता है, मैं सेवा कार्यों को फिर से शुरू करने में सक्षम हूं (पढ़ें: परिनियोजन पॉड्स), केवल एक बल अद्यतन (चश्मा में कोई बदलाव नहीं) के रूप में docker service update --force <service-name> । मुझे उम्मीद है कि कुबेरनेट्स भी ऐसा ही करेगा।
कॉन्फिगमैप्स और रहस्यों के लिए, झुंड आपको उन्हें संपादित करने की अनुमति नहीं देता है, आपको इसके बजाय उन्हें घुमाने की आवश्यकता है। आप इसे नए कॉन्फिगमैप्स/सीक्रेट्स बनाकर, नए का उपयोग करने के लिए सर्विस स्पेक को अपडेट करके करते हैं, फिर पुराने को हटाते हैं। मैं देखता हूं कि यह आमतौर पर आपके कॉन्फिगमैप्स/सेकर्ट्स को वर्जन करके और उनका उपयोग करने वाले तैनाती को अपडेट करके ऊपर अनुशंसित किया जाता है। ईमानदार होने के लिए, रोटेशन का यह व्यवहार एक प्रमुख कारण है जिसके लिए मैंने झुंड छोड़ा है! स्थानीय प्रतिलिपि रखना, अद्यतन करना, फिर नए संसाधन बनाना और अंत में आश्रित संसाधनों को अद्यतन करना बहुत असुविधाजनक है। उसमें जोड़ें, झुंड में रहस्यों को एपीआई से नहीं पढ़ा जा सकता है, आपको उन्हें किसी भी कंटेनर के अंदर माउंट करना होगा (या एक कंटेनर के अंदर निष्पादन जो उनका उपयोग करता है), फिर cat उनकी फाइलें।
संबंधित नोट पर, मैंने कुछ समय के लिए ओपनशिफ्ट का उपयोग किया और मेरा मानना ​​​​है कि यह एनवी/कॉन्फिगमैप/गुप्त परिवर्तन पर पॉड्स को ऑटो-रीस्टार्ट करता है? मैं हालांकि सही खड़ा हूँ।

परिवर्तनों के लिए फाइल सिस्टम को देखने के लिए ऐप जिम्मेदारी होनी चाहिए, जैसा कि उल्लेख किया गया है कि आप कॉन्फिगमैप/सीक्रेट पर चेकसम का उपयोग कर सकते हैं और उस तरह से फिर से शुरू कर सकते हैं

लेकिन अगर आप कॉन्फ़िगरेशन को बिल्कुल भी नहीं बदलना चाहते हैं और मनमाने ढंग से विराम के साथ रोलिंग पुनरारंभ करना चाहते हैं, तो एक साधारण पाइपलाइन काम करती है (यह टर्मिनेटेड पॉड के बीच 30 सेकंड सोती है)

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

ध्यान दें कि यदि आप ctrl+c दबाते हैं, तो जहां आपने छोड़ा था, वहां से फिर से शुरू करना आसान नहीं है

@ so0k , वैकल्पिक आदेश:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

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

२७०८१ #३३६६४ https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

एक और चाल शुरू में चलाने के लिए है:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

और फिर:

kubectl set image deployment/my-deployment mycontainer=myimage

यह वास्तव में रोलिंग-अपडेट को ट्रिगर करेगा लेकिन सुनिश्चित करें कि आपके पास imagePullPolicy: "Always" सेट भी है।

एक और तरकीब जो मुझे मिली, जहाँ आपको छवि का नाम बदलने की ज़रूरत नहीं है, वह है उस फ़ील्ड के मान को बदलना जो एक रोलिंग अपडेट को ट्रिगर करेगा, जैसे टर्मिनेशनग्रेसपीरियोडसेकंड। आप इसे kubectl एडिट परिनियोजन your_deployment या kubectl apply -f your_deployment.yaml या इस तरह के पैच का उपयोग करके कर सकते हैं:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/hi/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@ so0k @KIVAgant पॉड्स को हटाने का मतलब डाउनटाइम है, भले ही कई इंस्टेंसेस चल रहे हों। जब कोई strategy.rollingUpdate.maxUnavailable = 0 साथ एकल पॉड चलाता है तो एक नियमित परिनियोजन पहले मौजूदा पॉड को समाप्त करने से पहले एक नया पॉड बनाता है। kubectl patch deployment ट्रिक इस व्यवहार को ट्रिगर करती है, पॉड्स को हटाना नहीं है। मांग पर इस व्यवहार को ट्रिगर करने के लिए मैं वास्तव में एक गैर-हैकी तरीका चाहता हूं।

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

ConfigMap/गुप्त अद्यतनों का रोलआउट #22368 . है
नई छवियों का आसान रोलआउट #1697 . है
इन-प्लेस रोलिंग अपडेट #9043 . है

छवि निर्माण पर पुनरारंभ करें :
परिनियोजन रोलआउट को ट्रिगर करने के लिए टेम्प्लेट एनोटेशन का उपयोग करके एक ट्रिक की हेल्म शिखर प्रस्तुति: https://www.youtube.com/watch?v=dSw0w1x96ak

@ bgrant0607 मुझे लगता है कि महत्वपूर्ण उपयोग-मामला जो अन्य टिकटों द्वारा कवर नहीं किया गया है, वह यह है: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

@ghodss ने लिखा:
मुझे लगता है कि यह उस स्थिति के लिए अधिक होगा जहां पॉड जीवित है और चेक का जवाब दे रहा है लेकिन फिर भी इसे पुनरारंभ करने की आवश्यकता है। एक उदाहरण इन-मेमोरी कैश या आंतरिक स्थिति वाली सेवा है जो दूषित हो जाती है और इसे साफ़ करने की आवश्यकता होती है।

मुझे ऐसा लगता है कि किसी एप्लिकेशन को फिर से शुरू करने के लिए कहना काफी सामान्य उपयोग का मामला है, लेकिन शायद मैं गलत हूं।

मैं मैन्युअल चाल के बिना सभी एप्लिकेशन स्थिति को साफ़ करने के लिए रोलिंग पुनरारंभ को मजबूर करना चाहता हूं।

मेरे पास @rcoup और @paunin द्वारा वर्णित दृष्टिकोण के आधार पर एक समान एक-लाइनर है, लेकिन इसे अधिक सामान्य मामले के लिए काम करना चाहिए। यह JSON आउटपुट पर निर्भर करता है और पार्सिंग के लिए jq का उपयोग करता है। मैंने इसे अपने bashrc में एक फ़ंक्शन के रूप में लोड किया है ताकि मैं इसे कहीं भी कॉल कर सकूं

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

यह मुझे केवल यह कहने की अनुमति देता है: kubectl-restart my-deployment-name और यह पहले कंटेनर में RESTART_ env var को वर्तमान टाइमस्टैम्प पर "अपडेट" करेगा। मैं एक jq विशेषज्ञ से बहुत दूर हूं इसलिए इसे करने का एक बेहतर तरीका हो सकता है, लेकिन मूल रूप से यह पुराने RESTART_ env var को आउटपुट से हटा देता है (यदि यह मौजूद है) और फिर इसे वहां वापस जोड़ता है वर्तमान समय।

यह मेरे लिए बहुत अजीब लगता है कि ऐसा करने का कोई मूल तरीका नहीं है ... निश्चित रूप से इंजीनियरों से भरा कमरा इस बात से सहमत होगा कि "इसे बंद करने और फिर से चालू करने" की क्षमता कुछ ऐसी है जो हम चाहते हैं।

यह एक अच्छा हैक और सब कुछ है, लेकिन इसमें बड़ा नकारात्मक पहलू है। अगली बार जब आप kubectl apply -f का उपयोग करते हुए परिनियोजित करते हैं, तो वह घटक फिर से चालू हो जाएगा यदि इसमें RESTART_xxx env var है, भले ही कुछ और न बदले। दूसरे शब्दों में, यह अगली परिनियोजन पर नकली पुनरारंभ का कारण बनता है यदि इसे पिछले परिनियोजन और इस परिनियोजन के बीच कभी भी पुनरारंभ किया गया हो। आदर्श नहीं...

यही कारण है कि रोलिंग-रीस्टार्ट कार्यक्षमता को परिनियोजन नियंत्रक में बेक किया जाना चाहिए, शीर्ष पर नहीं बनाया जाना चाहिए।

मैंने " terminationGracePeriodSeconds की पैच परिनियोजन" रणनीति को पूरा करने के लिए एक बैश फ़ंक्शन लिखा था @whereisaaron ऊपर उनकी टिप्पणी में उद्धृत (स्रोत: https://stackoverflow.com/a/40368520/90442)।

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

यहाँ सार के माध्यम से टिप्पणी/अपडेट

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

@ कुबेरनेट्स / सिग-ऐप्स-फीचर-अनुरोध @ kow3ns @janetkuo

@gjcarneiro क्या आपके द्वारा लागू किए गए कॉन्फ़िगरेशन में आपके पास RESTART_xxx env var है या नहीं? यदि नहीं, तो मैं लाइव स्थिति में अतिरिक्त env var को अनदेखा करने के लिए लागू होने की अपेक्षा करता हूं।

cc @apelisse

@gjcarneiro हाँ, @mattdodge स्क्रिप्ट के साथ समस्या यह है कि यह लागू का उपयोग कर रहा है, इसलिए परिवर्तन अंतिम लागू एनोटेशन में सहेजा जाएगा। परिनियोजन को अद्यतन करने के लिए पैच या किसी अन्य विधि का उपयोग करके स्क्रिप्ट को ठीक किया जा सकता है।

इस सुविधा को प्राप्त करना पसंद करेंगे। यह बहुत ही बुनियादी और आवश्यक लगता है।

यहां कोई प्रगति नहीं है और न ही # 22368 पर, ले आह :-(

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

@alcohol , इसे जांचें https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

पारितोषिक के लिए धन्यवाद :-)

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

इसके अलावा डॉकर रिपॉजिटरी का इतिहास है इसलिए कोई कारण नहीं है कि रोलबैक काम नहीं कर सका - .spec.template से उत्पन्न पॉड कंटेनरों के लिए छवियों को खींचते समय image-tag:@digest प्रारूप का उपयोग कर सकते हैं। रोलबैक पिछले रोलआउट की डाइजेस्ट आईडी का उपयोग करेगा।

सुनिश्चित नहीं है कि मैं सही ढंग से समझ रहा हूँ। बस अगर यह किसी की मदद करता है।

ऐसा लगता है कि यदि आप पॉड> टेम्प्लेट> मेटाडेटा के तहत किसी लेबल के मान को अपडेट करते हैं, तो आपके बाद kubectl apply -f file.yaml बाद एक रोलिंग अपडेट होता है

तो आपके पास हमेशा अपने संस्करण के लिए एक लेबल हो सकता है और जब भी आप अद्यतन को रोल करना चाहते हैं, तो संस्करण बदलें और फ़ाइल लागू करें।

निश्चित रूप से, नकारात्मक पक्ष यह है कि अगली बार जब आप एक परिनियोजन करना चाहते हैं, तो आप kubectl apply -f some.yaml , है ना? आम तौर पर, अगर some.yaml में कुछ भी नहीं बदलता है तो कुछ भी पुनरारंभ नहीं होता है, यह कुबेरनेट्स के बारे में सबसे अच्छी चीजों में से एक है।

लेकिन कल्पना करें कि किसी परिनियोजन को पुनरारंभ करने के लिए लेबल बदलने के बाद क्या होता है। अगले सामान्य सॉफ़्टवेयर परिनियोजन पर आप हमेशा की तरह kubectl apply -f some.yaml करते हैं, लेकिन क्योंकि yaml फ़ाइल में समान लेबल नहीं है, परिनियोजन अनावश्यक रूप से पुनरारंभ हो जाएगा।

@gjcarneiro यदि आप apply करते हैं, तो kubectl.kubernetes.io/last-applied-configuration एनोटेशन अपडेट नहीं होगा, इसलिए अगला apply एक और पुनरारंभ का कारण नहीं होगा।

मैं kubectl में रोलिंग रीस्टार्ट कमांड जोड़ने के पक्ष में हूं, लेकिन इस बीच मैं निम्नलिखित का उपयोग कर रहा हूं (उपरोक्त समाधानों के आधार पर):

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

इसे पैरामीटर करें और इसे अपने .bashrc में एक फ़ंक्शन के रूप में जोड़ें और यह एक अच्छा अंतरिम समाधान है।

आह, अच्छा, मुझे यह नहीं पता था, धन्यवाद!

मुझे बैश उपनाम की आवश्यकता नहीं है, मेरी कंपनी में हमने Python+aiohttp का उपयोग करके Kubernetes के प्रबंधन के लिए अपना स्वयं का वेब इंटरफ़ेस बनाया है और यह पहले से ही पैच का उपयोग करता है। मैंने इसे ओपन सोर्सिंग के बारे में सोचा, बस आलसी हो गया ...

ऐसा लगता है कि लोग इस थ्रेड में वही समाधान समाधान दोहरा रहे हैं - कृपया यहां पोस्ट करने से पहले पूरा थ्रेड पढ़ें

@joelittlejohn मैंने आपका मैक्रो चलाया और इसने मेरे पॉड्स के रिबूट को ट्रिगर किया, लेकिन वे सभी एक ही समय में फिर से शुरू हो गए। मैंने सोचा कि यह एक रोलिंग रीबूट ट्रिगर करेगा, नहीं?

@Macmee यह आपके परिनियोजन के विन्यास पर निर्भर करता है। उपरोक्त आदेश सिर्फ परिनियोजन को बदलता है। पॉड्स को आपके परिनियोजन द्वारा परिभाषित रोल आउट strategy अनुसार अपडेट किया जाता है। यह परिनियोजन में किसी भी अन्य परिवर्तन की तरह ही है।

यह एक ही समय में सभी पॉड्स को बदलने का एकमात्र तरीका है यदि आपका .spec.strategy.rollingUpdate.maxUnavailable अनुमति देता है।

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

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

क्या इस पर कोई अपडेट आया है? हम भी इस सुविधा की तलाश कर रहे हैं। @bgrant0607 @nikhiljindal

@ भोलागब्बर-एमटी आपका उपयोग मामला क्या है?

cc @kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo हमारे सिस्टम के लिए उपयोग का मामला कई गुना है।

1. रहस्य अद्यतन करना - मुझे यकीन है कि आप महसूस करेंगे कि मेरी जैसी कई कंपनियां हैं, जिन्होंने कुबेरनेट्स पर अपने स्वयं के सार का निर्माण किया है। हमारे पास अपनी कंटेनर प्रबंधन प्रणाली है जिसे कुबेरनेट्स पर व्यवस्थित किया गया है। तो गुप्त सुझाव टिप्पणी और अन्य लागू नहीं होते हैं। देव क्लस्टर में ConfigMaps से रहस्यों को फिर से लोड करने के लिए, हमें पॉड्स को मारने के लिए मजबूर करना होगा, जिसके परिणामस्वरूप कुछ सेकंड का डाउनटाइम होगा। यह मामला नहीं हो सकता। रोलिंग अपडेट के लिए यह एक वास्तविक उपयोगकेस है।

2. यह थोड़ा जटिल है, लेकिन समग्र दायरा, जैसा कि किसी ने सुझाव दिया है, असामान्य व्यवहार को ठीक करना है। हमारे पास Play ढांचे पर चल रहे 4-5 भारी जावा ऐप्स हैं। हम एक ऐसी स्थिति का सामना कर रहे हैं जहां हमारे जावा पॉड्स की मेमोरी खपत रैखिक रूप से बढ़ जाती है और मेमोरी की सीमा तक पहुंचने पर पॉड्स को पुनरारंभ करता है। यह एक के साथ एक दस्तावेज जावा मुद्दा है stackoverflow मुद्दा और Kubernetes मुद्दा यह करने के लिए जुड़ा हुआ है। 3-4 घंटे की अवधि में सभी पॉड्स का रोलिंग-रीस्टार्ट मेमोरी खपत को रीसेट कर देगा और हमारे ऐप्स को बिना स्पाइक्स के सुचारू रूप से कार्य करने की अनुमति देगा।

उम्मीद है कि यह काफी आश्वस्त था और इस सुविधा को विकास के लिए किसी के द्वारा लिया जा सकता है?

@ भोलागब्बर-एमटी बस एक पर्यावरण चर बदलें और यह एक रोलिंग तैनाती को ट्रिगर करेगा:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn यह एकदम सही है। हमने इस बदलाव को आज ही अपने सिस्टम में एकीकृत किया है और यह ठीक चलता है। अनेक अनेक धन्यवाद!

सीसी @huzhengchuan

इसके लिए एक और उपयोग-मामला: कंटेनरड में सुरक्षा समस्या के कारण मैं सभी पॉड्स को पुनरारंभ करना चाहता हूं। https://seclists.org/oss-sec/2019/q1/119 या तो क्लस्टर पूरी तरह से नीचे चला जाता है, या यह एक रोलिंग पुनरारंभ करता है। पुनरारंभ आदेश होने से बहुत फर्क पड़ेगा!

अद्यतन , समाधान:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh आप सर्वोत्तम अभ्यास हैं। रैंचर में annotation:{creatTime: 12312312} जोड़ें!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

ऐसा लगता है कि न्यूनतम आदेश है जो एक परिनियोजन के लिए काम करता है। यह अनिवार्य विन्यास के उपयोग का उदाहरण है।

cc @monopole @apelisse

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

रोलिंग अपडेट अभी भी किसी ऐसी चीज़ के लिए एक बहुत लोकप्रिय गतिविधि है जिसका स्पष्ट रूप से कोई उपयोग नहीं है

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

1. मुझे अनिवार्य तर्क को एक घोषणात्मक एपीआई में बहने दिए बिना ऐसा करने का कोई तरीका नहीं दिखता है, जिससे एपीआई को घोषणात्मक रखने और नियंत्रकों में अनिवार्य व्यवहार को लागू करने और अधिकांश सीआई/सीडी प्रथाओं के साथ असंगतताओं को पेश करने के हमारे सम्मेलन को तोड़ दिया जाता है।
2. मैं एक रोलिंग रीस्टार्ट एपीआई और नियंत्रक की कल्पना कर सकता हूं जहां रोलिंग रीस्टार्ट संसाधन के निर्माण ने नियंत्रक को निष्कासन के माध्यम से 1 से 1 पॉड्स को पुनरारंभ करने का कारण बना दिया (इस प्रकार व्यवधान बजट का सम्मान), लेकिन ऐसे नियंत्रक को सीआरडी के रूप में कार्यान्वित किया जा सकता है (यानी मुझे कारण पता है कि क्यों हमें इसे पेड़ में करना है)।
3. घोषणात्मक दृष्टिकोण, उदाहरण के लिए lastRestartedAt=TIMESTAMP एनोटेशन जोड़ना मेरे लिए एक हैक जैसा प्रतीत नहीं होता है।
4. अगर कोई इस सुविधा को लागू करने के लिए एक घोषणात्मक डिजाइन और योगदान की पेशकश करना चाहता है (पेड़ में या अन्यथा) तो कृपया एन्हांसमेंट रेपो के खिलाफ केईपी पीआर लिखने पर विचार करें। यदि एक घोषणात्मक, अंतर्निहित, कार्यान्वयन को डिज़ाइन किया जा सकता है तो मुझे वर्कलोड एपीआई में समीक्षा/शेपर्ड करने में खुशी होगी। यदि [2] जैसे सीआरडी नियंत्रक की पेशकश की जाती है तो हम इसे समुदाय प्रायोजित विस्तार के रूप में एसआईजी ऐप्स में प्रायोजित कर सकते हैं।

घोषणात्मक दृष्टिकोण, उदाहरण के लिए lastRestartedAt=TIMESTAMP एनोटेशन जोड़ना मेरे लिए एक हैक जैसा प्रतीत नहीं होता है।

यह हैक नहीं है, इसके लिए बस एक शॉर्टहैंड कमांड लाइन होनी चाहिए।

कोई क्रू प्लगइन बना सकता है जो पैच भेजता है। kubectl restart-deployment <deployment_name> ?

kubectl rollout restart जो एक नए 'रोलआउट' को ट्रिगर करने के लिए परिनियोजन/डेमॉनसेट/स्टेटफुलसेट को पैच करता है?

यह @kow3ns के दृष्टिकोण (3) के kubectl rollout कमांड के साथ शुरू किया था।

@whereisaaron मैं सजा का इरादा नहीं है)

नए रहस्यों और कॉन्फिगमैप्स को रोल आउट करने के लिए, मेरी सिफारिश अभी भी #22368 है: नए बनाएं। यह रोलआउट को नियंत्रित करने और वापस रोल करने दोनों के लिए एक साधन प्रदान करता है। हमें पुरानी वस्तुओं के जीसी को खत्म करने की जरूरत है:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

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

सीसी @ मोनोपोल

नई छवियों के लिए, CI/CD या एक नियंत्रक जो टैग को पचाने के लिए हल करता है: #1697।

नाखुश पॉड्स को स्थानांतरित करने का इरादा descheduler (https://github.com/kubernetes-incubator/descheduler) या ऐसा कुछ है, जो कंटेनर स्थिति, कोर मेट्रिक्स और यहां तक ​​​​कि कस्टम मेट्रिक्स का उपभोग कर सकता है:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

साथ ही, सीक्रेट और कॉन्फिगमैप को कैसे हैंडल करें, इस पर आधिकारिक दस्तावेज: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

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

ठीक है, kubectl rollout restart का विलय हो गया है!

लगभग 4 वर्षों के बाद यह सुनकर बहुत अच्छा लगा, धन्यवाद!

मेरा मानना ​​है कि मर्ज किए गए पीआर केवल तैनाती का समर्थन करते हैं, क्या यह सही है?

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

@apelisse एसडीके या सिर्फ कुबेक्टल के माध्यम से ऐसा करने का कोई तरीका है?

@ ई-निकोलोव एसडीके क्या है?

मेरा मतलब गो क्लाइंट से था जिसका इस्तेमाल गो प्रोग्राम से कुबेरनेट्स से बात करने के लिए किया जा सकता है।

नहीं, आपको Kubectl में लागू किए गए (बहुत ही सरल) तर्क को फिर से लागू करना होगा।

ठीक है, kubectl रोलआउट पुनरारंभ विलय हो गया है!

इसका कौन सा kubectl संस्करण होगा?

इसका कुबेक्टल संस्करण क्या होगा?

कुबेरनेट्स 1.15

"रैपिड" रिलीज़ चैनल पर हमारे GKE क्लस्टर ने खुद को Kubernetes 1.16 में अपग्रेड कर लिया है और अब kubectl rollout restart ने काम करना बंद कर दिया है:

Kubectl रोलआउट पुनरारंभ परिनियोजन myapp
त्रुटि: अज्ञात आदेश "परिनियोजन myapp को पुनरारंभ करें"

@nikhiljindal ने कुछ समय पहले स्पेक्स में बिना किसी बदलाव के डिप्लॉयमेंट को अपडेट करने के लिए

मैं सराहना करता हूं कि हम पिछली मॉडल फ़ाइलों के साथ आसानी से परिनियोजन को वापस रोल करने में सक्षम नहीं हैं, लेकिन यह वह ट्रेड-ऑफ है जिसे हमने मॉडल को ऐप के जितना संभव हो सके लाने और नेटवर्क कॉल से बचने के लिए अपनाया है (जैसा कि कुछ सुझाव दे सकते हैं)।

अरे @dimileeh

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

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

हाय @apelisse , आपकी प्रतिक्रिया के लिए धन्यवाद!

जब मैं Google क्लाउड टर्मिनल से kubectl version चलाता हूं, तो मुझे निम्न मिलता है:

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

जब मैंने kubectl को gcloud components update माध्यम से अपग्रेड करने का प्रयास किया, तो उसने कहा कि मैं पहले से ही सभी उत्पादों के नवीनतम संस्करणों का उपयोग कर रहा हूं। इसलिए, मुझे लगता है कि मेरा kubectl संस्करण वही रहा, जबकि K8S क्लस्टर 1.15 से 1.16 तक अपग्रेड हुआ।

Kubenetes दस्तावेज़ 1.17, 1.16 और 1.15 में kubectl rollout restart सुविधा के बारे में कुछ भी नहीं है। तो मुझे आश्चर्य है कि क्या आपका बहुमूल्य योगदान 1.16 से गायब हो सकता था?

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

मैं यहां डॉक्स देख सकता हूं:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

आह, धन्यवाद, मैं यहाँ देख रहा था:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

उस लिंक के लिए बहुत-बहुत धन्यवाद, मैं यह सुनिश्चित करूँगा कि यह अपडेट हो जाए!

गुरु, 19 दिसंबर, 2019 को दोपहर 12:40 बजे दिमित्री लिहहत्सोव सूचनाएं @github.com
लिखा था:

आह, धन्यवाद, मैं यहाँ देख रहा था:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVVBJ65ZLOORNMVX
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (विलय होने के बाद मैं संबंधित शाखाओं में चेरी-पिक करूंगा)।

@dimileeh मुझे लगता है कि मुझे पता चला कि आपके kubectl संस्करण में क्या गलत है, हम इस पर काम करेंगे।

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

@anuragtr नवीनतम संस्करणों के साथ आप चला सकते हैं

kubectl rollout restart deploy NAME

मैं उस [1] के लिए एक कस्टम कमांड का उपयोग कर रहा था, खुशी है कि यह अब मानक कुबेक्टल में है! धन्यवाद

[१] https://github.com/mauri870/kubectl-renew

@anuragtr नवीनतम संस्करणों के साथ आप चला सकते हैं

kubectl rollout restart deploy NAME

@ देशद्रोही