नियंत्रक:
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go#L105
:
I did not use watch or expectations. Those add a lot of corner cases, and we aren't expecting a large volume of jobs or scheduledJobs. (We are favoring correctness over scalability.)
If we find a single controller thread is too slow because there are a lot of Jobs or CronJobs, we we can parallelize by Namespace. If we find the load on the API server is too high, we can use a watch and UndeltaStore.)
Just periodically list jobs and SJs, and then reconcile them.
समय-समय पर हर 10 सेकंड का अर्थ है:
https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go
एक टिप्पणी है कि एक विवरण के लिए नींव देता है के साथ शुरू होता है,
If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrentPolicy is set to AllowConcurrent, the jobs will always run at least once.
Jobs may fail to run if the CronJob controller is not running or broken for a span of time from before the start time of the CronJob to start time plus startingDeadlineSeconds, or if the span covers multiple start times and concurrencyPolicy does not allow concurrency. For example, suppose a cron job is set to start at exactly 08:30:00 and its startingDeadlineSeconds is set to 10, if the CronJob controller happens to be down from 08:29:00 to 08:42:00, the job will not start. Set a longer startingDeadlineSeconds if starting later is better than not starting at all.
उच्चतर स्तर केवल एक बार एक में के लिए सुलझाने:
प्रलेखन उद्धृत सीमाओं निम्नलिखित भी परिस्थितियों के तहत 2 नौकरियों या कोई कार्य एक विशेष समय पर शुरू किया जा सकता है में से कुछ पर कुछ उपयोगी रंग है वितरित प्रणाली मुश्किल है:
https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/
घड़ियां और एक वितरित प्रणाली में समय तुल्यकालन भी मुश्किल है:
https://8thlight.com/blog/rylan-dirksen/2013/10/04/synchronization-in-a-distributed-system.html
सवाल करने के लिए:
वजह से ऐसा हो सकता है?
उदाहरण के लिए- क्रॉन जोबकंट्रोलर होस्ट करने वाला नोड उस समय विफल रहता है जब नौकरी चलाना चाहिए।
यह संभावनाएं/आंकड़े क्या हो सकती हैं?
किसी दिए गए रन के लिए बहुत ही असंभव है।बड़ी संख्या में रनों के लिए, इस मुद्दे का सामना करने से बचने की संभावना बहुत कम है।
इसे के8 के कुछ उचित भविष्य में तय किया जाएगा?
के 8 एस रेपो में क्षेत्र/बैच लेबल के तहत कोई idemopotency- संबंधित मुद्दों नहीं हैं, तो कोई अनुमान नहीं लगाएगा।
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fbatch
वहाँ इस तरह के एक व्यवहार को रोकने के लिए (यदि चल रहा काम idempotent के रूप में लागू नहीं किया जा सकता है) किसी भी कामकाज से जुड़े हैं?
बेवकूफ की विशिष्ट परिभाषा के बारे में और नौकरी में विशेष बिंदु जहां काम करता है, के बारे में और सोचें। मिसाल के तौर पर, यदि वे राज्य को स्टेजिंग क्षेत्रों में सहेजते हैं, तो एक से अधिक निष्पादन का समर्थन करने के लिए नौकरियां बनाई जा सकती हैं, और फिर यह निर्धारित करने के लिए एक चुनावी प्रक्रिया है कि किसके काम जीतते हैं।
अन्य क्रॉन से संबंधित सेवाएं एक ही समस्या से पीड़ित हैं? शायद यह एक कोर क्रॉन समस्या है?
हां, यह मूल वितरित सिस्टम समस्या है।
अधिकांश उपयोगकर्ताओं के लिए, के 8 एस दस्तावेज शायद आवश्यक से अधिक सटीक और उत्तर दिया गया उत्तर देता है। यदि आपका निर्धारित कार्य कुछ महत्वपूर्ण चिकित्सा प्रक्रिया को नियंत्रित कर रहा है, तो विफलता के मामलों की योजना बनाना वास्तव में महत्वपूर्ण है। अगर यह सिर्फ कुछ सिस्टम क्लीनअप कर रहा है, तो अनुसूचित रन लापता होने से कोई फर्क नहीं पड़ता। परिभाषा के अनुसार, के 8 के क्रोनजब्स के लगभग सभी उपयोगकर्ता बाद की श्रेणी में आते हैं।
स्रोत
2018-02-17 03:26:22
स्पष्ट दिखता है, बहुत कुछ। "नौकरी नियंत्रक विफल होने पर नौकरी शुरू नहीं हो सकती है" - यह काफी स्पष्ट था, हालांकि यह क्यों गुणा करना शुरू कर सकता था समझने में मुश्किल थी। – radistao