Kubernetes: क्रोनजॉब्स को टाइमज़ोन का समर्थन करना चाहिए

@iterion इस मुद्दे पर कोई हस्ताक्षर लेबल नहीं हैं। कृपया इसके द्वारा एक हस्ताक्षर लेबल जोड़ें :
(1) एक संकेत का उल्लेख करना: @kubernetes/sig-<team-name>-misc
(2) लेबल को मैन्युअल रूप से निर्दिष्ट करना: /sig <label>

_नोट: विधि (1) टीम को एक सूचना ट्रिगर करेगी। आप यहां टीम सूची और लेबल सूची यहां देख सकते हैं _

/ हस्ताक्षर क्षुधा

दूसरे विकल्प को प्राथमिकता दें क्योंकि यह मुझे अधिक स्वाभाविक लगता है

@soltysh @kubernetes/sig-apps-feature-requests

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

ऐसा लगता है कि इसे लागू करने के लिए सीधा होना चाहिए:
वर्तमान में, हम सिर्फ time.Now() को syncOne लूप में पास करते हैं। k8s जिस क्रोन लिब का उपयोग कर रहा है, वह उस क्षेत्र में समय का उपयोग करके काम करता प्रतीत होता है, जिसकी आप परवाह करते हैं। इसलिए, हम क्रोनजॉब से टाइमज़ोन खींच सकते हैं और उस समय को ज़ोन के साथ सिंकऑन फंक में पास कर सकते हैं।

//init the loc, needs error handling
//perhaps default to local if Timezone was invalid
loc, _ := time.LoadLocation(cronjob.Spec.Timezone)

//set timezone,  
now := time.Now().In(loc)

साथ ही, मुझे इसे लागू करने का प्रयास करने में खुशी हो रही है।

मैं आपके पीआर की समीक्षा करने के लिए सही व्यक्ति नहीं हूं, लेकिन मेरे पास शब्दार्थ के बारे में कुछ प्रश्न हैं।

• जब कोई समय क्षेत्र निर्दिष्ट नहीं है तो शब्दार्थ क्या हैं?
• क्या कार्यान्वयन उस समयक्षेत्र पर निर्भर करता है जो नियंत्रक होस्ट पर सही ढंग से कॉन्फ़िगर किया जा रहा है?
• हम समय क्षेत्र की वैधता की पुष्टि कब करते हैं? ऑब्जेक्ट बनाने/अपडेट करने का समय, या बाद में?
• क्या होता है यदि एपीआई ऑब्जेक्ट बनाए जाने पर टाइमज़ोन नाम कानूनी था, लेकिन भविष्य में अब मौजूद नहीं है? ऐसा इसलिए हो सकता है क्योंकि एक नाम हटा दिया गया है (हो सकता है कि कोई शहर या राष्ट्र अस्तित्व में न हो), या क्योंकि अंतर्निहित tzdata पैकेज पुराने संस्करण में बदल गया है।

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

यदि उपयोगकर्ता ने कुछ अमान्य निर्दिष्ट किया है तो मैं वर्तमान में केवल जमानत देता हूं और होस्ट के टाइमज़ोन का उपयोग करता हूं। यहाँ, मैं गोलांग के समय पर झुक रहा हूँ।

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

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

इसके लिए मेरा सुझाव होगा कि एक उपयुक्त घटना के साथ रोजगार सृजन को विफल किया जाए। लेकिन सच कहूं तो मुझे शक है कि ऐसा अक्सर होता है। मैं यह सुनिश्चित करूंगा कि इसे आपके कार्यान्वयन @iterion में जोड़ा जाए।

और क्रॉन प्रारूप समर्थन वर्ष दायर नहीं है, एक निर्दिष्ट समय पर केवल एक बार नौकरी कैसे चलाएं?

:+1:

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

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

इसे कुबेरनेट्स में डालने के बजाय यह पूछना है:

1. इसे पारिस्थितिकी तंत्र में विकसित करें (उदाहरण के लिए, एक नियंत्रक) जिसका उपयोग अन्य कर सकते हैं। इसे वितरित करें, वहां की समस्याओं को हल करें, और देखें कि अपडेट कैसा दिखता है
2. यदि समाधान व्यापक रूप से अपनाया जाता है और सभी द्वारा उपयोग किया जा सकता है (छोटे पैमाने, बहु-क्लस्टर, आदि सहित) तो इसे कोर कुबेरनेट्स के लिए माना जा सकता है

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

यदि आप ऐसा कुछ बनाते हैं तो हम इसे लोगों के लिए दिखाने के लिए इसे SIG ऐप्स पर प्रदर्शित करना चाहेंगे। इसे सामुदायिक बैठक में भी प्रदर्शित किया जा सकता है।

यदि इस पर आपके कोई प्रश्न हैं, तो कृपया बेझिझक मुझसे संपर्क करें।

पिछली टिप्पणी को देखते हुए मुझे लगता है कि हम इस मुद्दे को बंद कर सकते हैं। यदि आप सहमत नहीं हैं तो बेझिझक फिर से खोलें।

एफडब्ल्यूआईडब्ल्यू, "टाइमज़ोन कैसे सेट करें" मेरे प्रत्येक उपयोगकर्ता द्वारा पूछा जाता है जो क्रोनजोब (डेवलपर्स और व्यवस्थापक समान) बनाता है।

@iterion आपने इसके बारे में क्या किया? हम अपने उपयोग के मामले के लिए विभिन्न विकल्पों पर विचार कर रहे हैं, जिनमें शामिल हैं

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

यदि आपके पास पहले से कुछ ऐसा है जो आपके लिए काम कर रहा है जिसे हम एक शुरुआती बिंदु के रूप में उपयोग कर सकते हैं, या यदि हम किसी ऐसी चीज़ पर सहयोग कर सकते हैं जो @mattfarina को उसके निर्णय को उलटने के लिए प्रोत्साहित कर सकती है, जिसमें इसे शामिल नहीं करने की अनुमति है (जो नाटकीय रूप से इस क्यूब को अपनाने को नुकसान पहुँचाता है) फीचर), यह बहुत अच्छा होगा।

मैंने वास्तव में एक नई नौकरी पर स्विच कर लिया है, इसलिए मूल समस्या मेरे लिए व्यक्तिगत रूप से अब मौजूद नहीं है। जहां तक ​​मुझे पता है, मेरे पूर्व सहयोगी इससे होने वाले दर्द से निपट रहे हैं।

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

@mattfarina को इसे शामिल न करने के अपने निर्णय को उलटने के लिए प्रोत्साहित करें

इसे स्पष्ट करने के लिए, यह निर्णय सामूहिक रूप से एक हस्ताक्षर-वास्तुकला बैठक के दौरान किया गया था। मैट ही इस मुद्दे में उस निर्णय को व्यक्त करने वाले व्यक्ति थे।

सभी घंटियों और सीटी के साथ टाइमज़ोन की समस्या लंबे समय से लिनक्स की दुनिया में हल हो गई है। Kubernetes परिनियोजन के लिए यह इतनी अधिक आवश्यकता क्यों है?

मेरे द्वारा स्वीकार किए जाने वाले उपयोग के मामलों के महत्व के बारे में चर्चा करना मुश्किल है। हालाँकि (और मेरी विनम्र राय में), सेवाओं के उपयोगकर्ताओं के साथ तालमेल बिठाने में सक्षम होना मेरे लिए कुबेरनेट्स कोर के योग्य होने के लिए पर्याप्त महत्वपूर्ण लगता है।

क्या कोई TimezoneAwareCronjobController के साथ एक ऑपरेटर लिखने को तैयार होगा? @iterion द्वारा लिखे गए अधिकांश कोड को संभवतः पुनर्नवीनीकरण किया जा सकता है।
पैकेज्ड एप्लिकेशन में TZ हैंडलिंग को स्थानांतरित करने से वितरण तर्क हल हो जाएगा जिसने कुबेरनेट्स में प्रथम श्रेणी के क्रोनजॉब समर्थन को मार दिया।

FWIW, https://gopkg.in/robfig/cron.v2 (जो मौजूदा नियंत्रक पुराने उपसमुच्चय का उपयोग करता है), TZ में पासिंग का समर्थन करता है, और समय परिभाषाओं का थोड़ा समृद्ध सेट।
हमारे पास आंतरिक रूप से एक नियंत्रक है जो हमारे कुछ आंतरिक वर्कलोड के लिए क्रॉन जॉब बनाता है, और यह उन लोगों के लिए टाइमज़ोन निर्दिष्ट करने में सक्षम होने के लिए एक उत्कृष्ट सुविधा अनुरोध है। मुझे गलती से छोड़ने या नौकरियों को फिर से चलाने के बिना मौजूदा क्रोनजॉब परिभाषा को सुरक्षित रूप से अपडेट करने का तरीका जानने की जरूरत है। इस बिंदु पर ऐसा लगता है कि बाहर निकलने वाले कंटोलर से जॉब शेड्यूलिंग चोरी करना और सीधे जॉब डेफिनिशन बनाना आसान हो सकता है (बजाय cronjobs)।

जब से मैंने K8s का उपयोग करना शुरू किया है, मैं साल में दो बार इस मुद्दे पर वापस आता हूं, जब मुझे सभी CronJobs पर शेड्यूल बदलने के लिए मजबूर किया जाता है, इस उम्मीद में कि इसे आखिरकार फिर से खोल दिया गया है। यदि chronos और crontab सुविधा है, कैसे K8s अभी भी इस का समर्थन नहीं कर रहा है?

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

उम्मीद है कि यह समस्या फिर से खुल जाएगी और हर दिन UTC समय को देखना थोड़ा अजीब है।

मेरे पास एक क्रोनजॉब है जिसे स्थानीय समय पर प्रत्येक महीने के पहले दिन चलाने की जरूरत है, लेकिन पिछले महीने के आखिरी दिन यूटीसी का समय 16:00 है। मैं पिछले महीने के अंतिम दिन को कैसे परिभाषित करूं? क्रोनजॉब एल का समर्थन नहीं करता है।

ऐसा प्रतीत होता है कि कोई वैकल्पिक समाधान मौजूद नहीं है। मेरे प्रश्न यहाँ और यहाँ देखें

किसी के लिए अभी भी इसका इंतजार कर रहे हैं; मैंने मूल कुबेरनेट्स क्रोनजॉब नियंत्रक और बंद किए गए मूल पीआर से प्राप्त एक नियंत्रक बनाया।

https://github.com/hiddeco/cronjobber

संपादित करें (2019/05/12): @mterron करने के लिए धन्यवाद, Cronjobber अब एक साइडकार का उपयोग कर एक मेजबान स्वतंत्र समय क्षेत्र डेटाबेस का समर्थन करता है।

@hiddeco मौजूदा एक को संशोधित करने के बजाय नियंत्रक नियंत्रण मानक सीजे नियंत्रक रखना बेहतर होगा? बाद के दृष्टिकोण के साथ किसी को वास्तविक सीजे नियंत्रक परिवर्तनों को बनाए रखने की आवश्यकता होती है, जो हमेशा संभव नहीं हो सकता है। तुम्हारे काम के लिए धन्यवाद।

@andrewsav जो बेहतर होगा लेकिन करने योग्य नहीं है। मौजूदा सीजे नियंत्रक को 'नियंत्रित' करने का एकमात्र तरीका एक समय क्षेत्र के ऑफसेट के लिए CronJob के शेड्यूल को संशोधित करना है। ऐसा कोई तरीका नहीं है जिससे आप सभी संभावित शेड्यूल संयोजनों के लिए ऐसा कर सकें।

मुझे उम्मीद नहीं है कि CJ नियंत्रक में वैसे भी कई बदलाव होंगे, साथ ही हम इसे चालू रखने के लिए इसके साथ तालमेल बिठाने के लिए बाध्य नहीं हैं क्योंकि यह स्व-निहित है (क्लाइंट पर निर्भरता और Job विनिर्देशों को छोड़कर) .

@ हिडेको

ऐसा कोई तरीका नहीं है जिससे आप सभी संभावित शेड्यूल संयोजनों के लिए ऐसा कर सकें।

क्या आप कृपया इसे समझा सकते हैं?

@AndrewSav सरल उदाहरण: 0 0 1 * * NZDT (UTC+13) में चल रहा है, इसका मतलब यह होगा कि आपको इसे हर महीने पुनर्गणना करने की आवश्यकता होगी क्योंकि आपको पिछले महीने के अंतिम दिन पर चलने की आवश्यकता होगी यूटीसी में सुबह 11 बजे।

यदि आपके शेड्यूल की जटिलता बढ़ जाती है, तो इसे सिंक में रखने के लिए आपको जितने बदलाव करने की आवश्यकता होती है, वह भी बढ़ जाता है। साथ ही जब भी समय क्षेत्र क्षेत्र डीएसटी से एसटी में बदलता है, तो आपको इसे हर बार बदलना होगा।

यह इसे बेहद जटिल बनाता है और इसे गलत समय पर चलाने के लिए बहुत जगह खोलता है या शायद इससे भी बदतर; बिल्कुल नहीं।

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

डीएसटी के लिए इसका मतलब है कि यह एक बार के बजाय दिन में दो बार चलेगा और डीएसटी के आधार पर पहले या दूसरे को छोड़ देगा।

उदाहरण के लिए, प्रत्येक अनुपालन कुबेरनेट्स वितरण के लिए एक टाइमज़ोन डेटाबेस होना चाहिए और इसे अद्यतित रखना चाहिए। टाइमज़ोन, डेलाइट सेविंग टाइम, और इस काम को करने का विवरण जबकि वास्तविक दुनिया का विवरण शिफ्ट कर सकता है और कर सकता है। आज मौजूद 20 से अधिक वितरणों के लिए यह अतिरिक्त कार्य होगा।

टाइमज़ोन डेटाबेस, डीएसटी, ओएस वितरण द्वारा बहुत अच्छी तरह से बनाए रखा जाता है, जिस पर कुबेरनेट्स वितरण को भरोसा करना चाहिए। "यह वितरण के लिए कड़ी मेहनत है" बहाना वैध IMO नहीं है।

अगर अवधारणा को PeriodicJob या RepeatingJob कहा जाता तो मैं बहस नहीं करता। लेकिन इसके बजाय, इसे CronJob कहा जाता है। यह कैलेंडर और घड़ी से बंधा हुआ है। इस बात से इनकार नहीं किया जा सकता है कि इसके लिए टाइमज़ोन जागरूकता एक महत्वपूर्ण आवश्यकता है।

एक और समाधान; हो सकता है कि क्रोनजॉब को कुबेरनेट्स से पूरी तरह से हटाकर समस्या का समाधान किया जा सकता है। ऐसा नहीं है कि यह किसी की मदद करेगा।

एक और समाधान; हो सकता है कि क्रोनजॉब को कुबेरनेट्स से पूरी तरह से हटाकर समस्या का समाधान किया जा सकता है। ऐसा नहीं है कि यह किसी की मदद करेगा।

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

तर्क सुसंगत प्रतीत नहीं होता है, अगर हम इस तर्क से जाने वाले हैं तो K8s में बहुत सारी विशेषताएं होनी चाहिए जो मौजूद नहीं होनी चाहिए।

यह वास्तव में एक बग है। Cronjob अपने आप में भ्रामक है क्योंकि यह क्रॉन विनिर्देश का पालन नहीं करता है। अधिकांश Kubernetes उपयोगकर्ता मान लेंगे कि Time Zone समर्थन बॉक्स से बाहर आता है। यह निराशाजनक है कि कोर डेवलपर्स ने इसे शामिल नहीं करने का फैसला किया। यह समस्या उन 90% उपयोगकर्ताओं को प्रभावित करेगी जो UTC समय पर काम नहीं करते हैं।

मैं इस पर फिर से विचार करने का आग्रह करता हूं। मेरी एक समस्या यह है कि मैं चाहता हूं कि जापान में महीने की पहली तारीख को कुछ नौकरियां 1 बजे चले - निश्चित रूप से एक उचित/मानक उपयोग का मामला। यह देखते हुए कि यूटीसी में क्रॉन परिभाषित किया गया है, मेरे लिए इसे निर्दिष्ट करने का कोई तरीका नहीं है; 0 0 1 * * जापान के समयानुसार सुबह 9 बजे चलेगी। (महीने के आखिरी दिन के लिए 0 0 L * * जोड़ना भी अच्छा होगा जो कुछ क्रॉन कार्यान्वयन में उपयोग किया जाता है)

@johnnyshields आपको शायद @soltysh को फिर से खोलने के लिए कहना चाहिए।

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

CronJobber https://github.com/hiddeco/cronjobber पर एक नज़र डालें (और योगदान दें!) यह वही करता है जो हर कोई चाहता है।

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

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

फिर उन्हें कम से कम सुसंगत होना चाहिए और क्रोनजॉब के वर्तमान कार्यान्वयन को हटा देना चाहिए क्योंकि यह बहुत भ्रामक है (कम से कम कहने के लिए)।

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

@AndrewSav और इसलिए मैं इसके लिए मदद मांग रहा था। मैंने वह सब कुछ किया है जो मैं कर सकता हूं। मुझे यकीन नहीं है कि इसके साथ कोई सुरक्षा जोखिम है, हालांकि कुबेरनेट्स हर समय बदलता है लेकिन इसका मतलब यह नहीं है कि सुरक्षा अर्थ में परिवर्तन सार्थक है।

ऐसा कहने के बाद, एक रिबेस अच्छा होगा, इसमें योगदान करने और इसमें मदद करने के लिए स्वतंत्र महसूस करें।

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

अगर यह बंद हो जाता है और कोई इसे लगातार रिबेज करता रहता है और इसे बनाए रखता है तो यह बहुत अच्छा होगा।

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

@mterron मुझे लगता है कि मैं अपनी उम्मीदों के स्तर पर हूं। कुछ भी हो, वे कम हैं। यही मुख्य कारण है कि मैंने अपने समूहों में लिंक किए गए कार्य का उपयोग करने से परहेज किया।

@AndrewSav आपको क्रोनजॉबर और अपस्ट्रीम क्रोनजॉब कंट्रोलर के बीच एक अंतर करना चाहिए। पिछली बार मैंने (1.17) किया था, कोई अंतर नहीं था। अपस्ट्रीम क्रोनजॉब कंट्रोलर आपकी परिभाषा के अनुसार प्रभावी रूप से अनियंत्रित है।

अपस्ट्रीम कंट्रोलर में भी भयानक प्रदर्शन विशेषताएँ होती हैं, जो निश्चित रूप से क्रोनजॉबर को विरासत में मिलती हैं।

@बेनलैंगफेल्ड

आपको क्रोनजॉबर और अपस्ट्रीम क्रोनजॉब कंट्रोलर के बीच अंतर करना चाहिए

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

अपस्ट्रीम क्रोनजॉब कंट्रोलर आपकी परिभाषा के अनुसार प्रभावी रूप से अनियंत्रित है।

मैंने जो कहा, उसकी यह उचित व्याख्या नहीं है।

अंतर के विषय पर: आप किससे भिन्न हैं? उस रेपो में 50 से अधिक फाइलें हैं, और सभी नाम कुबेरनेट्स स्रोतों से मेल नहीं खाते हैं। क्या आप समझा सकते हैं कि हम अपने आप को कैसे आश्वस्त कर सकते हैं कि कोई परिवर्तन नहीं हुआ था? अधिमानतः थोड़ा और विस्तृत है कि आपकी पिछली टिप्पणी में, क्योंकि यह स्पष्ट नहीं है। यह विशेष रूप से, किन फाइलों पर आपने प्रत्येक पक्ष पर शाखाओं/कमिट की तुलना की है, और कोई छेड़छाड़ नहीं मिली है?

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

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

@AndrewSav 'कांटा' के लेखक के रूप में मुझे आपके द्वारा अब तक कही गई किसी भी बात से सम्मानपूर्वक असहमत होना है, और कई OSS परियोजनाओं के अनुरक्षक के रूप में मैं आपके रवैये से हैरान हूं।

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

दूसरा, स्पॉनिंग जॉब X समय पर Y समय क्षेत्र को ध्यान में रखते हुए Z रॉकेट साइंस नहीं है, अवधारणा समय के लिए विनिर्देश वर्षों में नहीं बदला है, और चाहिए' यह सुनिश्चित करने के अलावा किसी भी रखरखाव की आवश्यकता है कि यह अभी भी सही समय पर कुबेरनेट्स देशी नौकरियों को जन्म दे सकता है (और समय क्षेत्र डेटाबेस अप-टू-डेट हैं, जिसके लिए @mterron के लिए एक सहायक उपलब्ध है)।

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

@ हिडेको

आपने अब तक जो कुछ भी कहा है, उससे मुझे सम्मानपूर्वक असहमत होना पड़ेगा

कुछ भी? यह एक मजबूत बयान है।

नीचे बताए गए कारणों को देखते हुए, मुझे उम्मीद नहीं थी कि अपस्ट्रीम में बहुत बदलाव आएगा (न ही ऐसा हुआ है)

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

दूसरा, समय क्षेत्र को ध्यान में रखते हुए Y समय पर नौकरी एक्स पैदा करना रॉकेट विज्ञान नहीं है, अवधारणा समय के लिए विनिर्देश वर्षों में नहीं बदला है, और यह सुनिश्चित करने के अलावा किसी भी रखरखाव की आवश्यकता नहीं होनी चाहिए कि यह अभी भी कुबेरनेट्स की मूल नौकरियों को जन्म दे सकता है सही समय (और समय क्षेत्र डेटाबेस अप-टू-डेट हैं, जिसके लिए @mterron के लिए एक सहायक उपलब्ध है)।

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

जब तक यह इन नौकरियों को पैदा करने में सक्षम है, जो पिछली बार मैंने जांच की थी, मेरा समय कहीं और बेहतर है।

और यह ठीक है। आप पहले ही और अधिक कर चुके हैं जो आपको करना था। आपने पीआर को मर्ज कर दिया, और आपने अपना काम किसी के भी उपयोग के लिए प्रकाशित किया। शुक्रिया।

यदि यह आपके मानकों को पूरा नहीं करता है, तो मैं सुझाव दूंगा कि किसी को आपके लिए एक समान समाधान लिखने और बनाए रखने के लिए काम पर रखा जाए।

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

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

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

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

और जैसा कि कहा गया है, वर्तमान कार्यान्वयन बेकार के करीब है क्योंकि यह पूरी तरह से समय क्षेत्र की उपेक्षा करता है, जहां कार्यान्वयन जो कि समय क्षेत्र के बारे में जागरूक है, लोगों के व्यापक समूह के लिए अधिक उपयोगी है, यहां आपका क्या कहना है?

इस तर्क का इस्तेमाल किसी भी चीज़ के खिलाफ बहस करने के लिए किया जा सकता है

मुझे नहीं लगता कि यह कर सकता है। यदि आप चाहें तो इसे प्रदर्शित करने के लिए आपका स्वागत है, लेकिन कृपया जो कहा गया है उस पर टिके रहें, न कि जो निहित हो सकता था।

इसलिए मुझे नहीं पता कि आप यहां क्या हासिल करने की कोशिश कर रहे हैं।

ओह, मैं सिर्फ मुझ पर निर्देशित हिडेको की टिप्पणी का उत्तर दे रहा हूं, आप इसे ऊपर पा सकते हैं।

और जैसा कि कहा गया है, वर्तमान कार्यान्वयन बेकार के करीब है क्योंकि यह पूरी तरह से समय क्षेत्र की उपेक्षा करता है, जहां कार्यान्वयन जो कि समय क्षेत्र के बारे में जागरूक है, लोगों के व्यापक समूह के लिए अधिक उपयोगी है

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

तुम्हारा यहाँ क्या मतलब है?

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

बग लगातार पाए जाते हैं, यहां तक ​​कि "परिपक्व और समय सिद्ध" परियोजनाओं में भी और ठीक हो जाते हैं।

सबसे पहले, "परिपक्व" और "समय सिद्ध" शब्दों का कुबेरनेट्स, या इसके पारिस्थितिकी तंत्र के बारे में एक वाक्य में कोई स्थान नहीं है।

दूसरा, कुबेरनेट्स में बग्स की समस्या कब से है? @ fejta-bot उन्हें स्वचालित रूप से "ठीक" (बंद) कर देगा। बग के बारे में सोचने की जरूरत नहीं है। सब ठीक हैं।

मुझे आश्चर्य है कि कोई रखरखाव कब/टिप्पणी करेगा?

मुझे लगता है कि इसे https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limitations के तहत प्रलेखित किया जाना चाहिए

मैं मानता हूँ क्योंकि Kubernetes समूहों लिनक्स जो इस प्रदान करता है पर चलने Kubernetes पर है कि "cronjobs" समय-क्षेत्र की समर्थन होना चाहिए। क्या हम इस धारणा को खारिज कर रहे हैं क्योंकि कुछ पार्टी के पास दूर के भविष्य में विंडोज़ पर कुबेरनेट्स (या संस्करण) चलाने के लिए डिज़ाइन हैं? यदि मामला हो तो इस मुद्दे को अस्वीकार करने का बहुत कमजोर कारण। क्या हम इसे हल किए गए मुद्दों से अलग करने के लिए कम से कम "ट्राएज/अनसुलझे" टैग जोड़ सकते हैं?

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

चूंकि गो 1.15 को अब इसके मूल पुस्तकालय में time/tzdata पैकेज मिल गया है, संभवतः…?

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

क्रोनजॉब के साथ टाइमज़ोन का प्रबंधन नहीं करना आपके द्वारा लिया गया एक बहुत ही अजीब निर्णय था।

हमें इस समस्या के लिए एक अच्छा समाधान मिला: K8s CronJobs का उपयोग करना बंद करें और इसके बजाय Apache Airflow का उपयोग करें।

जब से हमने किया है तब से जीवन बहुत बेहतर हो गया है। हमसे जुड़ें!

यह समस्या वहाँ बाहरी रूप से हल की गई है: https://github.com/hiddeco/cronjobber

@mattfarina

1. यदि समाधान व्यापक रूप से अपनाया जाता है और सभी द्वारा उपयोग किया जा सकता है (छोटे पैमाने, बहु-क्लस्टर, आदि सहित) तो इसे कोर कुबेरनेट्स के लिए माना जा सकता है

सामुदायिक समाधान के अंगीकरण को कैसे और कब मापा जाता है?

https://github.com/kubernetes/enhancements/pull/1996

@mattfarina @soltysh अब KEP-19 के साथ: ग्रेजुएट क्रोनजॉब टू स्टेबल , जो विचार के लिए सुधारों में से एक के रूप में क्रोनजॉब कंट्रोलर v2 पर काम प्रक्रिया में है, क्या इस मुद्दे पर फिर से विचार किया जा सकता है?

यह एक विचार/संभावित सुधार के रूप में इसका उल्लेख करता है। यह गारंटी नहीं देता है कि यह कब और कब संपर्क किया जाएगा। मैं 100% गारंटी के साथ कह सकता हूं कि यह क्रोनजोब जीए से पहले नहीं होने वाला है, जो इसे और 2 अन्य रिलीज लेगा।

@soltysh इस पर अभी भी ठीक से चर्चा की जा सकती है। यह व्यापक रूप से प्रदर्शित किया गया है कि यह एक आवश्यक विशेषता है। इस पर गेंद को सड़क पर लात मारने की जिद अनुरक्षकों और उपयोगकर्ताओं के बीच एक बहुत बड़ा संबंध दर्शाती है।

@benlangfeld मैं इसके लिए बहुत खुला हूं, लेकिन समय यहां मुख्य सीमित कारक है: निराश:

@benlangfeld मैं इसके लिए बहुत खुला हूं, लेकिन समय यहां मुख्य सीमित कारक है

पहले से ही एक प्रस्तावित फिक्स है। इसे स्वीकार करने के लिए आपको किस इनपुट की आवश्यकता है?

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