Kubernetes: आरसी और पॉड में पॉड निर्दिष्ट करते समय लॉग-ड्राइवर और लॉग-ऑप्ट को परिभाषित करना

/ सीसी @ कुबेरनेट्स / आरएच-क्लस्टर-इन्फ्रा

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

cc @sosiouxme @smarterclayton @liggitt @jwhonce @jcantrill @bparees @jwforres

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

ध्यान दें कि डॉकर लॉग अभी भी केवल जेसन-फाइल और जर्नल ड्राइवरों का समर्थन करते हैं, हालांकि मुझे लगता है कि सूची का विस्तार हो सकता है।

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

@ncdc @smarterclayton मैं आप दोनों से सहमत हूं, आंतरिक रूप से हमारे उपयोग के मामले पर पुनर्विचार करने के बाद, यह पता चला है कि

1. हमारी प्राथमिक जरूरत अपने नोड्स की रक्षा करना है। हम लॉग को लॉग सर्वर पर भेजते हैं लेकिन अगर यह विफल हो जाता है, तो डॉकर आंतरिक लॉग पर लॉग फॉलबैक हो जाता है। ऐसे मामले में, नोड संतृप्ति को रोकने के लिए हमें डॉक लॉग के लिए क्लस्टर वाइड व्यवहार की आवश्यकता होती है
2. पॉड/आरसी परिभाषाओं में विशिष्ट डॉकटर विकल्पों को उजागर करना एक अच्छा विचार नहीं है जैसा कि @smarterclayton ने सुझाव दिया था। यदि संभव हो तो हम उच्च स्तरीय लॉग व्यवहार की परिभाषा की अनुमति देने वाले एक अमूर्त से भी सहमत हैं
3. एक अन्य विकल्प ऐसे लॉग व्यवहार को संभालने के लिए क्यूबलेट कॉन्फ़िगरेशन फ़ाइलों और कोड में परिवर्तन कर रहा है

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

मंगलवार, 13 अक्टूबर, 2015 को सुबह 10:55 बजे, एपो जेम्बा नोटिफिकेशन @github.com
लिखा था:

@ncdc https://github.com/ncdc @smarterclayton
https://github.com/smarterclayton मैं आप दोनों से सहमत हूं, इसके बाद
आंतरिक रूप से हमारे उपयोग के मामले पर पुनर्विचार करते हुए, यह पता चला है कि

1. हमारी प्राथमिक जरूरत अपने नोड्स की रक्षा करना है। हम लॉग को लॉग में भेजते हैं
   सर्वर लेकिन अगर यह विफल रहता है, तो डॉकर आंतरिक लॉग पर फ़ॉलबैक लॉग करता है। ऐसे में
   मामले में, नोड संतृप्ति को रोकने के लिए हमें क्लस्टर व्यापक व्यवहार की आवश्यकता है
   डॉकर लॉग
2. पॉड/आरसी परिभाषाओं में विशिष्ट डॉकटर विकल्पों को उजागर करना एक नहीं है
   @smarterclayton के रूप में अच्छा विचार https://github.com/smarterclayton
   इसका सुझाव दिया। हम उच्च की परिभाषा की अनुमति देने वाले एक अमूर्त से भी सहमत हैं
   स्तर लॉग व्यवहार यदि संभव हो तो
3. एक अन्य विकल्प क्यूबलेट कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन कर रहा है और
   ऐसे लॉग व्यवहार को संभालने के लिए कोड

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

:थम्स अप:

ध्यान दें कि अब 9 लॉगिंग ड्राइवर हैं । इसे प्राप्त करने पर आम सहमति क्या है?

+1

यदि किसी को पता नहीं है, तो आप डोकर डेमॉन ( --log-driver ) के ध्वज के साथ प्रति-नोड आधार पर डिफ़ॉल्ट लॉग ड्राइवर को परिभाषित कर सकते हैं। अपने परिवेश में, मैंने ड्राइवर को इस तरह से journald सेट किया है। मैं ईमानदार होने के लिए प्रति-कंटेनर के आधार पर इसे ओवरराइड करने के लिए उपयोग-मामले के बारे में सोचने के लिए संघर्ष करता हूं।

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

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

इस पर +1।
डॉकर लॉगिंग को कैसे नियंत्रित किया जाता है, इसे नियंत्रित करने में सक्षम नहीं होने का अर्थ है कि एकमात्र समझदार लॉगिंग विकल्प k8s के साथ भेजे गए टूल का उपयोग कर रहा है, जो एक अविश्वसनीय सीमा है।

@timothysc यहाँ हमारा उपयोग-मामला है। हमारे पास एक जटिल गतिशील बुनियादी ढांचा (~100 मशीनें) हैं, जिन पर बहुत सारी मौजूदा सेवाएं चल रही हैं, लॉग इकट्ठा करने के लिए हमारे अपने logstash । खैर, अब हम अपनी सेवाओं को एक-एक करके k8s में स्थानांतरित करने का प्रयास कर रहे हैं और मेरे लिए k8s पर क्लस्टर किए गए हमारे मौजूदा बुनियादी ढांचे और कंटेनरों के बीच लॉगिंग को एकीकृत करने का कोई साफ तरीका नहीं है।

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

उम्मीद है, यह समझ में आता है।

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

सोम, 23 मई 2016 को पूर्वाह्न 10:50 बजे, जैकोपो नारडिएलो < नोटिफिकेशन @github.com

लिखा था:

इस पर +1।
डॉकर लॉगिंग को कैसे नियंत्रित किया जाता है, इसे नियंत्रित करने में सक्षम नहीं होने का अर्थ है कि
केवल समझदार लॉगिंग विकल्प k8s के साथ भेजे गए टूल का उपयोग कर रहा है, जो कि एक है
अविश्वसनीय सीमा।

@timothysc https://github.com/timothysc यहाँ हमारा उपयोग-मामला है। हमारे पास एक
बहुत सारे मौजूदा के साथ जटिल गतिशील बुनियादी ढाँचा (~ 100 मशीनें)
उन पर चल रही सेवाएं, लॉग इकट्ठा करने के लिए हमारे अपने लॉगस्टैश के साथ। खैर हम
अब हमारी सेवाओं को एक-एक करके k8s और मेरे पास ले जाने का प्रयास कर रहे हैं
ऐसा लगता है कि हमारे मौजूदा के बीच लॉगिंग को एकीकृत करने का कोई साफ तरीका नहीं है
इन्फ्रास्ट्रक्चर और कंटेनर k8s पर क्लस्टर किए गए हैं।

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

उम्मीद है, यह समझ में आता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

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

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

क्या आप प्रति एप्लिकेशन कस्टम लॉग विकल्प निर्दिष्ट कर रहे हैं? कितने अलग
आपके पास प्रति क्लस्टर लॉग विकल्प के सेट होंगे? यदि के छोटे समूह हैं
config में, एक विकल्प पॉड्स पर एक एनोटेशन का समर्थन करना होगा जो है
नोड स्तर के विन्यास से संबंधित है जो कई "मानक लॉग" प्रदान करता है
विकल्प"। यानी क्यूबलेट लॉन्च समय पर "लॉग मोड एक्स" परिभाषित करें (जो परिभाषित करता है
कस्टम लॉग विकल्प और ड्राइवर), और पॉड निर्दिष्ट करेगा "
pod.alpha.kubernetes.io/log.mode=X"।

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

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

गुरु, 26 मई, 2016 को सुबह 5:34 बजे, जैकोपो नारडिएलो नोटिफिकेशन @github.com
लिखा था:

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

ये सिर्फ मेरे दो सेंट हैं, लेकिन हम उस वास्तविक दुनिया के परिसर का ढोंग नहीं कर सकते हैं
परिदृश्य बस अपने मौजूदा लॉगिंग इन्फ्रास्ट्रक्चर को छोड़ देते हैं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

@smarterclayton क्या आपने https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829 देखा है

जी नहीं, धन्यवाद। वहां चल रही चर्चा।

गुरु, 26 मई 2016 को पूर्वाह्न 11:23 बजे, एंडी गोल्डस्टीन नोटिफिकेशन @github.com
लिखा था:

@smarterclayton https://github.com/smarterclayton क्या आपने # 24677 . देखा है
(टिप्पणी)
https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221903781

नमस्ते,
मुझे लगता है कि यह एक महत्वपूर्ण विशेषता है जिसे कुबेरनेट्स के लिए माना जाना चाहिए।
डॉकर के लॉग ड्राइवर के उपयोग को सक्षम करने से कुछ गैर-तुच्छ समस्याओं का समाधान हो सकता है।

मैं कहूंगा कि डिस्क पर लॉगिंग एक विरोधी पैटर्न है। लॉग स्वाभाविक रूप से "राज्य" हैं, और अधिमानतः डिस्क पर सहेजा नहीं जाना चाहिए। लॉग को सीधे कंटेनर से रिपॉजिटरी में भेजने से कई समस्याएं हल हो जाती हैं।

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

डॉकर के पास पहले से ही Google क्लाउड (gcplogs) और Amazon (awslogs) के लिए लॉग ड्राइवर हैं। हालांकि उन्हें डॉकर डेमॉन पर ही सेट करना संभव है, लेकिन इसमें कई कमियां हैं। दो डॉकटर विकल्पों को सेट करने में सक्षम होने के कारण:

--लॉग-ड्राइवर = कंटेनर के लिए लॉगिंग ड्राइवर
--लॉग-ऑप्ट=[] लॉग ड्राइवर विकल्प

लेबल के साथ भेजना संभव होगा (gcplogs के लिए) या awslogs-group (awslogs के लिए)
एक फली के लिए विशिष्ट। इससे दूसरे छोर पर लॉग ढूंढना आसान हो जाएगा।

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

मैं यह भी जोड़ सकता हूं कि मेरे सहित कुछ लोग, होस्ट पर लॉगरोटेट स्थापित करने के बजाय JSON लॉगिंग ड्राइवर (जो डॉकटर के मूल निवासी हैं) पर '--log-opt max-size' विकल्प के माध्यम से docker logs रोटेशन करना चाहते हैं। तो, यहां तक ​​कि केवल '--log-opt' विकल्प को उजागर करने की भी बहुत सराहना की जाएगी

कंटेनर कॉन्फ़िगरेशन LogConfig बनाते समय मैंने k8s को संशोधित किया है।

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

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

तुम वहाँ जाओ। कृपया ऐसा कराएं।

एक और विचार है, जहां सभी कंटेनर अभी भी एक ही एंडपॉइंट में लॉग अग्रेषित करते हैं, लेकिन आप अपने लॉग सर्वर पर

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

कुबेरनेट्स के बिना उदाहरण, केवल डॉकर डेमॉन और गेल्फ ड्राइवर के साथ। docker daemon के साथ कॉन्फ़िगर किया गया है: --log-driver=gelf --log-opt labels=env,label2 और एक docker कंटेनर बनाएं:

docker run -dti --label env=testing --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

और एक अन्य डॉकटर कंटेनर:

docker run -dti --label env=production --label label2=some_value alpine:3.4 /bin/sh -c "while true; do date; sleep 2; done"

इस तरह, ग्रेलॉग पर, आप env=production और env=testing कंटेनरों के बीच अंतर कर सकते हैं।

वर्तमान में मैं ऐसे डॉकर डिमन विकल्पों का उपयोग करता हूं:

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

@xmik , बस इसकी पुष्टि करने के लिए एक मौजूदा सुविधा या आपके प्रस्ताव के बारे में क्या है

वर्तमान में मैं ऐसे डॉकर डिमन विकल्पों का उपयोग करता हूं:

--log-driver=gelf --log-opt gelf-address=udp://graylog.example.com:12201 --log-opt tag=k8s-testing --log-opt labels=io.kubernetes.pod.namespace,io.kubernetes.container.name,io.kubernetes.pod.name

वे डॉकटर डिमन विकल्प जो मैं वर्तमान में उपयोग करता हूं, पहले से ही काम करते हैं। कुबेरनेट्स पहले से ही प्रत्येक डॉकटर कंटेनर के लिए कुछ लेबल सेट करता है। उदाहरण के लिए, क्यूब-एपिसर्वर कंटेनर पर docker inspect चलाते समय:

 "Labels": {
   "io.kubernetes.container.hash": "4959a3f5",
   "io.kubernetes.container.name": "kube-apiserver",
   "io.kubernetes.container.ports": "[{\"name\":\"https\",\"hostPort\":6443,\"containerPort\":6443,\"protocol\":\"TCP\"},{\"name\":\"local\",\"hostPort\":8080,\"containerPort\":8080,\"protocol\":\"TCP\"}]",
   "io.kubernetes.container.restartCount": "1",
   "io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
   "io.kubernetes.pod.name": "kube-apiserver-k8s-production-master-1",
   "io.kubernetes.pod.namespace": "kube-system",
   "io.kubernetes.pod.terminationGracePeriod": "30",
   "io.kubernetes.pod.uid": "a47396d9dae12c81350569f56aea562e"
}

इसलिए, वे docker daemon विकल्प काम करते हैं।

हालाँकि, मुझे लगता है कि कुबेरनेट्स को पॉड स्पेक पर आधारित डॉकटर कंटेनर पर कस्टम लेबल सेट करना अब संभव नहीं है। तो उदाहरण के लिए --log-driver=gelf --log-opt labels=env,label2 काम नहीं करता है।

क्या इस मोर्चे पर कोई खबर है? लेबल निर्दिष्ट करने और फिर --log-opt labels<> का लाभ लेने की क्षमता होना बहुत अच्छा होगा!

@portante @jcantrill बस इसे यहाँ कैप्चर करने के लिए क्योंकि हमने इस पर चर्चा की, यहाँ उपयोग का मामला है कि हम सोच रहे थे कि यह इसके लिए उपयोगी हो सकता है:

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

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

मेरे 2 सेंट।

K8s के अंदर लॉगिंग के वर्तमान समाधान हैं (AFAIK):

• साइडकार कंटेनर कहीं लॉग भेज रहा है
• प्रतिकृति नियंत्रक कहीं न कहीं सभी लॉग भेज रहा है
• कंटेनर स्वयं कहीं लॉग भेज रहा है

साइडकार कंटेनर मेरे लिए एक तरह से ओवरकिल लगता है। प्रतिकृति नियंत्रक रणनीति अच्छी लगती है, लेकिन यह सभी परिनियोजन से कंटेनरों के लॉग को मिलाती है, और कुछ उपयोगकर्ता अब इसे चाहते हैं, और इसके बजाय प्रत्येक ऐप को एक अलग चीज़ पर लॉग करना चाहते हैं। इस मामले के लिए, अंतिम विकल्प सबसे अच्छा IMHO काम करता है, लेकिन सभी कंटेनरों में दोहराए गए बहुत सारे कोड बनाता है (उदाहरण: लॉगेंट्री डेमॉन स्थापित और सेटअप करें)।

यदि हमारे पास log-driver झंडे तक पहुंच होती तो यह सब आसान हो जाता, इसलिए प्रत्येक परिनियोजन यह परिभाषित करेगा कि इसे कैसे लॉग किया जाना चाहिए, डॉकर मूल सुविधाओं का उपयोग करके।

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

एक बार जब बहु किरायेदारी एक चीज बन जाती है, तो इसे ठीक से हल करना कठिन हो जाएगा।

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

मैं ऐसा करने के कुछ तरीकों के बारे में सोच सकता हूं:

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

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

@crassirostris मुझे यकीन नहीं है कि मैं समझता हूं: अगर हम सिर्फ log-driver एट अल की अनुमति देते हैं, तो हमें भंडारण या उसमें से किसी से निपटने की ज़रूरत नहीं है, है ना?

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

मुद्दा यह है कि डॉकर में लॉग-ड्राइवर किसी भी k8s मेटाडेटा को नहीं जोड़ता है जो बाद में लॉग को वास्तव में उपयोगी बनाता है। :/

@ kfox1111 हम्म, समझ में आता है ...

लेकिन, क्या होगा यदि उपयोगकर्ता केवल "एप्लिकेशन" लॉग चाहता है, कुबेरनेट्स लॉग नहीं, डॉकर लॉग नहीं, केवल कंटेनर लॉग के अंदर चलने वाला ऐप?

उस स्थिति में, मुझे लगता है, log-driver काम करेगा...

@ caarlos0 इसके कुछ निहितार्थ हो सकते हैं, उदाहरण के लिए क्यूबलेट सर्वर kubectl लॉग में लॉगिंग प्रारूप के बारे में कुछ धारणाएँ बनाता है।

लेकिन सभी चीजें एक तरफ, log-driver प्रति से डॉकर-विशिष्ट है और अन्य रनटाइम के लिए काम नहीं कर सकती है, यही मुख्य कारण है कि इसे एपीआई में शामिल न किया जाए।

@crassirostris जो समझ में आता है ...

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

@ caarlos0 हालांकि, हम निश्चित रूप से लॉगिंग सेट अप को अधिक लचीला और पारदर्शी बनाना चाहते हैं। प्रस्ताव पर आपकी प्रतिक्रिया की सराहना की जाएगी!

कंटेनरों से स्टडआउट लॉगिंग को वर्तमान में कुबेरनेट्स के भीतर आउट-ऑफ-बैंड नियंत्रित किया जाता है। हम वर्तमान में लॉगिंग को संभालने के लिए गैर-कुबेरनेट्स समाधानों पर भरोसा कर रहे हैं, या विशेषाधिकार प्राप्त कंटेनर जो आउट-ऑफ-बैंड लॉगिंग तक पहुंच प्राप्त करने के लिए कुबेरनेट्स को जेल तोड़ते हैं। कंटेनर रन-टाइम लॉगिंग प्रति रन-टाइम (docker, rkt, Windows) अलग है, इसलिए किसी एक को चुनना, जैसे Docker --log-driver भविष्य का सामान बना रहा है।

मेरा सुझाव है कि लॉग स्ट्रीम को बैंड में वापस लाने के लिए हमें क्यूबलेट की आवश्यकता है। न्यूनतम JSON या XML लॉग प्रारूप को परिभाषित करें या चुनें, जो प्रत्येक कंटेनर से स्टडआउट लाइनें एकत्र करता है, एक न्यूनतम क्लस्टर + नेमस्पेस + पॉड + कंटेनर मेटाडेटा जोड़ें, ताकि लॉग स्रोत को कुबेरनेट्स स्पेस के भीतर पहचाना जा सके, और स्ट्रीम को कुबेरनेट्स सर्विस + पर निर्देशित किया जा सके। बंदरगाह। उपयोगकर्ता अपनी पसंद की कोई भी लॉग खपत सेवा प्रदान करने के लिए स्वतंत्र हैं। शायद Kubernetes एक संदर्भ/डिफ़ॉल्ट सेवा प्रदान करेगा जो 'kubectl logs' समर्थन को लागू करता है।

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

क्यूबलेट कंटेनर रनटाइम रैपर प्रत्येक कंटेनर रनटाइम से स्टडआउट निकालने के लिए न्यूनतम करता है, और इसे k8s सेल्फ-होस्टेड सेवा (सेवाओं) के उपभोग और प्रक्रिया के लिए इन-बैंड में वापस लाता है।

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

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

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

लोग क्या सोचते हैं?

@whereisaaron मैं वास्तव में अब यह चर्चा नहीं करना चाहूंगा, जब हमारे पास एक ही स्थान पर लॉगिंग पारिस्थितिकी तंत्र के बारे में सभी विवरण नहीं हैं।

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

निश्चित रूप से @crassirostris। कृपया हमें यहां बताएं कि प्रस्ताव कब जांच के लिए तैयार है।

/ हस्ताक्षर मापनीयता

हालांकि दोनों --log-driver और --log-opt डॉकर डेमॉन के विकल्प हैं और k8s सुविधाओं के लिए नहीं , उन्हें k8s पॉड स्पेक में निर्दिष्ट करना अच्छा होगा:

1. प्रति-पॉड लॉग ड्राइवर और एकल नोड-स्तरीय लॉग ड्राइवर नहीं
2. एक ही नोड पर विभिन्न प्रकार के ऐप-विशिष्ट लॉग ड्राइवर (फ्लुएंट, सिसलॉग, जर्नलड, स्प्लंक)
3. पॉड के लिए लॉग रोटेशन को कॉन्फ़िगर करने के लिए --log-opt सेट करें
4. प्रति-पॉड --log-opt सेटिंग्स और एक नोड-स्तर नहीं --log-opt

AFAIK, उपरोक्त में से कोई भी आज k8s पॉड स्पेक में पॉड-स्तर पर सेट नहीं किया जा सकता है।

@vhosakot उपरोक्त में से कोई भी कुबेरनेट्स में किसी भी स्तर पर सेट नहीं किया जा सकता है, क्योंकि वे कुबेरनेट्स अवधारणाएं नहीं हैं

@crassirostris बिल्कुल! :)

यदि k8s वह सब कुछ करता है जो Docker पॉड-लेवल/कंटेनर-लेवल पर करता है, तो क्या यह उपयोगकर्ताओं के लिए आसान नहीं होगा? कुछ पॉड-लेवल/कंटेनर-लेवल सामान के लिए उपयोगकर्ता डॉकर का उपयोग क्यों करते हैं?

और, एक k8s प्रेमी जो डॉकर प्रशंसक नहीं है, वही प्रश्न पूछ सकता है।

@vhosakot Point है, कई अन्य कंटेनर रनटाइम हैं जिनका उपयोग K8s के साथ किया जा सकता है, लेकिन --log-opt केवल डॉकर में मौजूद है। K8s स्तर पर ऐसा विकल्प बनाना जानबूझकर अमूर्तता को लीक करना होगा। मुझे नहीं लगता कि हम इस तरह से जाना चाहते हैं। यदि कोई विकल्प मौजूद है, तो उसे सभी कंटेनर रनटाइम द्वारा समर्थित होना चाहिए, आदर्श रूप से CRI का एक हिस्सा होना चाहिए

मैं यह नहीं कह रहा हूं कि ऐसा कोई विकल्प नहीं होगा, मैं कह रहा हूं कि यह डॉकर के लिए सीधा मार्ग नहीं होगा

@crassirostris सच है, ऐसा लगता है कि यह नीचे आता है अगर k8s को वह करना चाहिए जो CRI करता है/पॉड-लेवल/कंटेनर-लेवल पर करता है, डॉकर-विशिष्ट नहीं।

जी बिल्कुल सही

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

@ gabriel-tincu मैं वर्तमान में आश्वस्त नहीं हूं कि मूल FR परेशानी के लायक है

docker लॉग ड्राइवरों की एक बहुत व्यापक सूची के साथ आता है

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

@crassirostris मैं मानता हूं कि आप पर्यावरण को स्थापित करने से पहले __ पहले __ सेट कर सकते हैं, लेकिन अगर पर्यावरण के पहले से ही सेटअप होने के बाद डॉकर लॉग ड्राइवर को सक्रिय रूप से अपडेट करने का कोई तरीका है तो यह इस समय मुझे हटा देता है

@ gabriel-tincu @vhosakot प्रत्यक्ष इंटरफ़ेस जो k8s और डॉकर के बीच मौजूद था> = 1.5 के 'पुराने दिन' में वापस आ गया है और मेरा मानना ​​​​है कि कोड अब पूरी तरह से हटा दिया गया है। क्यूबलेट और रन-टाइम जैसे डॉकर (या आरकेटी, क्रि-ओ, रनक, एलएक्सडी जैसे अन्य) के बीच सब कुछ सीआरआई के माध्यम से जाता है। अब बहुत सारे कंटेनर रनटाइम हैं और cri-containerd + containerd पक्ष में डॉकर को जल्द ही पदावनत और हटा दिए जाने की संभावना है।

http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html

@crassirostris किसी प्रस्ताव पर कोई आंदोलन, जिसमें इन-बैंड कंटेनर लॉगिंग की संभावना हो सकती है?

सीआरआई कंटेनर लॉग फ़ाइल आधारित है (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md), और लॉग पथ स्पष्ट रूप से परिभाषित है:

/var/log/pods/PodUID/ContainerName/RestartCount.log

अधिकांश डॉक लॉगिंग ड्राइवरों में https://docs.docker.com/config/containers/logging/configure/#supported -logging-drivers, मुझे लगता है कि क्लस्टर वातावरण के लिए, सबसे महत्वपूर्ण ड्राइवर कंटेनर लॉग इन क्लस्टर में हैं लॉगिंग प्रबंधन प्रणाली, जैसे splunk , awslogs , gcplogs आदि।

सीआरआई के मामले में, "डॉकर लॉग ड्राइवर" का उपयोग नहीं किया जाना चाहिए। लोग सीआरआई कंटेनर लॉग निर्देशिका से कंटेनर लॉग को जहां चाहें वहां ले जाने के लिए डेमोंसेट चला सकते हैं। वे धाराप्रवाह का उपयोग कर सकते हैं या स्वयं एक डेमोंसेट भी लिख सकते हैं।

यदि अधिक मेटाडेटा की आवश्यकता है, तो हम मेटाडेटा फ़ाइल को छोड़ने के बारे में सोच सकते हैं, फ़ाइल पथ का विस्तार कर सकते हैं या डेमॉनसेट को एपिसर्वर से मेटाडेटा प्राप्त करने दे सकते हैं। इस https://github.com/kubernetes/kubernetes/issues/58638 . के बारे में चर्चा चल रही है

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

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

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

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र सड़ा हुआ
/निकालें-जीवनचक्र बासी

/निकालें-जीवनचक्र सड़ा हुआ

इस पर कोई अपडेट? तो डॉकर कंटेनरों के साथ k8s चलाने वाला कोई कैसे AWS CloudWatch जैसे कुछ बैकएंड पर लॉगिंग कर रहा है?

@ bryan831 धाराप्रवाह या समान का उपयोग करके k8s कंटेनर लॉग फ़ाइलों को एकत्र करना और उन्हें बैक-एंड, क्लाउडवॉच, स्टैकड्राइवर, इलास्टिसर्च आदि की अपनी पसंद में एकत्र करना लोकप्रिय है।

उदाहरण के लिए फ्लुएंटड+क्लाउडवॉच , फ्लुएंटड+इलास्टिसर्च , -बिट->फ्लुएंटड-> योर चॉइस ,

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

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

Docker --log-opt विकल्पों को अनुकूलित करने में सक्षम होना अच्छा होगा। मेरे मामले में, मैं एक टैग का उपयोग करना चाहूंगा जैसे '--log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"' ImageName को लॉग में भेजने के लिए ताकि मुझे पता चले कि किस कंटेनर संस्करण से लॉग आ रहे हैं। (संदर्भ: https://docs.docker.com/config/containers/logging/log_tags/)

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

@ pmahalwar-intertrust आप docker daemon को --log-opt पास कर सकते हैं, जो आपके सभी कंटेनरों को प्रभावित करेगा ...

@ pmahalwar-intertrust कुबेरनेट्स द्वारा containerd से एकत्र किए गए लॉग में पहले से ही व्यापक मेटाडेटा शामिल है, कंटेनर पर आपके द्वारा लागू किए गए किसी भी लेबल को शामिल करें। यदि आप इसे fluentd साथ एकत्र करते हैं तो आपको सभी मेटाडेटा प्राप्त होंगे जैसे नीचे लॉग प्रविष्टि में।

{
    "log": " - [] - - [25/Oct/2018:06:29:48 +0000] \"GET /nginx_status/format/json HTTP/1.1\" 200 9250 \"-\" \"Go-http-client/1.1\" 118 0.000 [internal] - - - - 5eb73997a372badcb4e3d993ceb44cd9\n",
    "stream": "stdout",
    "docker": {
        "container_id": "3657e1d9a86e629d0dccefec0c3c7624eaf0c4a11f60f53c5045ec0839c37f06"
    },
    "kubernetes": {
        "container_name": "nginx-ingress-controller",
        "namespace_name": "ingress",
        "pod_name": "nginx-ingress-dev-controller-69c644f7f5-vs8vw",
        "pod_id": "53514ad6-d0f4-11e8-a04c-02c433fc5820",
        "labels": {
            "app": "nginx-ingress",
            "component": "controller",
            "pod-template-hash": "2572009391",
            "release": "nginx-ingress-dev"
        },
        "host": "ip-172-29-21-204.us-east-2.compute.internal",
        "master_url": "https://10.3.0.1:443/api",
        "namespace_id": "e262510b-180a-11e8-b763-0a0386e3402c"
    },
    "kubehost": "ip-172-29-21-204.us-east-2.compute.internal"
}

क्या अभी भी इन सुविधाओं का समर्थन करने की कोई योजना नहीं है?
--लॉग-ड्राइवर = कंटेनर के लिए लॉगिंग ड्राइवर
--लॉग-ऑप्ट=[] लॉग ड्राइवर विकल्प

नमस्ते @lifubang मैं किसी की योजनाओं के बारे में बात नहीं कर सकता, लेकिन उन सुविधाओं का समर्थन करने वाला डेमॉन, dockerd अब कुबेरनेट्स का हिस्सा नहीं है (ऊपर चर्चा देखें)।

यदि आप चाहें तो आप अभी भी इसे वैकल्पिक रूप से स्थापित कर सकते हैं, ताकि आप पुराने dockerd लॉग ड्राइवरों का उपयोग करने के लिए ऐसा करने में सक्षम हो सकें। उस विकल्प पर यहां चर्चा की गई है:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

लेकिन fluentd जैसी समर्पित लॉगिंग सेवा का उपयोग करना सुझाया गया तरीका है। आप इसे अपने क्लस्टर या प्रति-पॉड के लिए साइडकार के रूप में विश्व स्तर पर तैनात कर सकते हैं। कुबेरनेट्स में लॉगिंग की चर्चा यहाँ की गई है:
https://kubernetes.io/docs/concepts/cluster-administration/logging/

मैं धाराप्रवाह की अत्यधिक अनुशंसा करता हूं जैसा कि @whereisaaron . द्वारा वर्णित किया

जहां तक ​​​​इस सुविधा अनुरोध पर काम किया जा रहा है ... कुबेरनेट्स आर्किटेक्चरल रोडमैप उन चीजों के "पारिस्थितिकी तंत्र" खंड के तहत लॉगिंग कर रहा है जो वास्तव में "कुबेरनेट्स" का हिस्सा नहीं हैं, इसलिए मुझे संदेह है कि ऐसी सुविधा कभी भी मूल रूप से समर्थित होगी।
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

मैं धाराप्रवाह का उपयोग करने के खिलाफ दृढ़ता से अनुशंसा करता हूं क्योंकि इसमें कई बग हैं जो k8s चलाते समय आपके जीवन को h*ll बना सकते हैं

in_tail डॉकटर को कंटेनर https://github.com/fluent/fluentd/issues/1680 को हटाने से रोकता है

in_tail स्टार्टअप चरण के दौरान ट्रैक न की गई फ़ाइल स्थिति को हटा देता है। इसका मतलब है कि pos_file की सामग्री पुनरारंभ होने तक बढ़ रही है और जब आप गतिशील पथ सेटिंग के साथ बहुत सारी फाइलों को पूंछते हैं तो इसके माध्यम से एक टन सीपीयू स्कैनिंग खा सकते हैं।
https://github.com/fluent/fluentd/issues/1126।

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

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र बासी

आपके अनुभव @roffe के लिए धन्यवाद। धाराप्रवाह/धाराप्रवाह#1680 k8s 1.5 के बारे में एक मुद्दा था और हमने उस कारण से 'in_tail' का उपयोग नहीं किया था। चूंकि k8s containerd लॉगिंग में चले गए हैं, यह अभी भी एक चीज प्रतीत नहीं होता है? हमने धाराप्रवाह/धाराप्रवाह#1126 से कोई पता लगाने योग्य प्रभाव नहीं देखा है।

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

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

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/जीवनचक्र सड़ा हुआ

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/बंद करे

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

यह बंद नहीं होना चाहिए था, है ना?
सुविधा अनुरोध अभी भी मुझे समझ में आता है क्योंकि मैं प्रति पॉड लॉग-ऑप्ट सेट करना चाहता हूं (इसे डिमन पर सेट किए बिना या लॉगरोटेट का उपयोग किए बिना) ...

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

@whereisaaron क्या आपको K8s@containerd के लिए लॉगिंग समाधान मिला

हैं --log-driver , --log-opt अभी भी समर्थित नहीं है?
मैं सिंगल पॉड से स्प्लंक तक लॉग अग्रेषित करने का एक तरीका खोजने का प्रयास कर रहा हूं। कोई विचार?

@ sariel1212 सिंगल पॉड के लिए मैं आपके पॉड में एक साइड कार कंटेनर शामिल करने की सलाह देता हूं जो केवल स्प्लंक फ़ॉरवर्डिंग एजेंट है। आप पॉड में सभी कंटेनरों के बीच एक खाली डायर वॉल्यूम साझा कर सकते हैं और एप्लिकेशन कंटेनर को अपने लॉग को साझा खालीदिर में लिख सकते हैं। फिर स्प्लंक फारवर्डर कंटेनर को उस वॉल्यूम से पढ़ें और उन्हें फॉरवर्ड करें।

यदि आप अपने पूरे क्लस्टर @ sariel1212 के लिए स्प्लंक को एकत्र करना चाहते हैं, तो स्प्लंक एचईसी fluentd प्लग-इन एकत्र करने के लिए fluentd तैनात करने के लिए एक @coffeepac के लिए एक साझा खालीदिर के साथ एक साइडकार का सुझाव एक अच्छा तरीका है।

यह बहुत भयानक है कि इस समय के बाद भी क्लस्टर मालिक के लिए डॉकर लॉग ड्राइवरों का उपयोग करने का कोई तरीका नहीं है।

मैं अपनी लॉग एग्रीगेटेड सेवा में सभी स्टडआउट/गलती को पाइप करने के लिए डॉकर-कंपोज़ (मेरे K8s क्लस्टर का अनुकरण) के साथ बहुत जल्दी सेटअप प्राप्त करने में सक्षम था।

Kubenetes में ऐसा करने की कोशिश कर रहे हैं? इस धागे से ऐसा लगता है कि मुझे प्रत्येक माइक्रोसर्विस के लिए कोड बढ़ाना होगा! अच्छा नहीं है।

हाय @ashleydavis , dockerd को बहिष्कृत कर दिया गया था, इसलिए किसी ऐसी चीज़ के लिए समर्थन शुरू करने का कोई मतलब नहीं है जो अब कुबेरनेट्स का हिस्सा नहीं है। हालाँकि आप अभी भी इसे कुबेरनेट्स के अतिरिक्त स्थापित कर सकते हैं। यहाँ पृष्ठभूमि है:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

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

https://docs.fluentd.org/container-deployment/kubernetes

बैक-एग्रीगेशन बैक-एंड के लिए बहुत सारे तैयार fluentd +बैकएंड कंटेनर चित्र और नमूना कॉन्फ़िगरेशन हैं:

https://github.com/fluent/fluentd-kubernetes-daemonset

यदि आप डेटाडॉग का उपयोग कर रहे हैं तो उनके पास इसके बजाय या साथ ही fluentd स्थापित करने के लिए अपना स्वयं का एजेंट है:

https://docs.datadoghq.com/integrations/kubernetes/

आम तौर पर docker लॉगिंग और लॉग प्लग-इन, और झुंड, और रनटाइम टूल्स, बिल्ड टूल्स, नेटवर्किंग, और फाइल सिस्टम माउंटिंग इत्यादि के साथ kitchen sink जाता है। सभी एक डेमॉन प्रक्रिया में। कुबेरनेट्स आमतौर पर ढीले युग्मित कंटेनरों/प्रक्रियाओं को पसंद करते हैं जो प्रत्येक एक कार्य करते हैं और एपीआई के माध्यम से संचार करते हैं। इसलिए आदत डालने के लिए यह एक अलग शैली है।

विस्तृत प्रतिक्रिया के लिए धन्यवाद। मैं निश्चित रूप से इस पर गौर करने जा रहा हूं।

डॉकर्ड के पदावनत होने का मतलब यह है कि मैं भविष्य में डॉकर छवियों को कुबेरनेट्स पर तैनात नहीं कर सकता?

@ashleydavis आप निश्चित रूप से 'डॉकर' छवियों का उपयोग करना जारी रख सकते हैं ( dockerd बिना भी), और आप अपने स्वयं के उद्देश्यों के लिए अपने Kubernetes नोड्स पर dockerd तैनात कर सकते हैं (जैसे docker-in-docker में) बनाता है) यदि आप चाहते हैं। डॉकर के मुख्य भागों को 'ओसीआई कंटेनर' और containerd रन-टाइम के रूप में निकाला और मानकीकृत किया गया है।

https://www.opencontainers.org/
https://containerd.io/

डॉकर और कुबेरनेट्स दोनों अब इन साझा मानकों पर आधारित हैं।

https://blog.docker.com/2017/08/what-is-containerd-runtime/
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

धन्यवाद, मैं बहुत कुछ सीख रहा हूँ।

मैंने अभी एक माइक्रोसर्विस बनाया है जिसे मैंने Loggy कहा है। इरादा यह था कि डॉकर लॉग ड्राइवर द्वारा लॉग भेजे जाएं और फिर उन्हें (वेबहुक के माध्यम से) स्लैक को अग्रेषित करें।

आप यहां कोड देख सकते हैं: https://github.com/artlife-solutions/loggy/blob/master/src/index.ts

यह बहुत आसान है, एक लॉग प्राप्त करें और इसे HTTP POST के माध्यम से Slack पर अग्रेषित करें।

इसे अनुकूलित करने का सबसे तेज़ तरीका क्या है ताकि मैं अपने पॉड्स से लॉग एकत्र और एकत्र कर सकूं?

@ashleydavis आप उस माइक्रो-सर्विस के साथ एक कंटेनर छवि बना सकते हैं, फिर या तो

1. इसे आप क्लस्टर को एक सेवा के साथ परिनियोजन के रूप में सेवा के क्लस्टर DNS नाम का उपयोग करके)।

2. इसे अपने परिनियोजन में एक अतिरिक्त 'साइडकार' कंटेनर के रूप में एक ही पॉड में कंटेनर समान localhost तक निजी पहुंच साझा करते हैं ताकि एप्लिकेशन कंटेनर आपके माइक्रो-सर्विस कंटेनर साइडकार को localhost:12201 पर भेज सके। वैकल्पिक रूप से, एक ही पॉड में कंटेनर साझा लॉग फ़ाइलों या नामित पाइपों के लिए

यह यहां विषय से हटकर हो रहा है और हर कोई यह नहीं चाहेगा, इसलिए शायद जीथब पर कुछ स्लैक चैनलों को हिट करें।

https://github.com/ramitsurana/awesome-kubernetes
https://slack.k8s.io/
https://kubernetes.io/

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

डॉकर लॉग ड्राइवरों का वादा सादगी था। क्या ऐसा करने का कोई आसान तरीका है?

ज़रूर @ashleydavis , अपना क्लस्टर परिनियोजित करें, fluentd परिनियोजित करें, और धमाका करें, आपका काम हो गया । आपके द्वारा परिनियोजित प्रत्येक एप्लिकेशन का stdout/stderr आपके पसंदीदा एग्रीगेटर को भेज दिया जाएगा। मैं

K8s में कुछ समय निवेश करने और लॉगिंग करने के बाद मैंने स्पष्ट GELF कॉन्फ़िगरेशन के बिना एक अच्छा किया है । कृपया https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html पर एक नज़र डालें

मेरा सेटअप फाइलबीट है जो लॉगस्टैश को लॉग को पाइप करता है जो फ़िल्टर और अर्क करता है और अपनी सामग्री को इलास्टिक्स खोज में पाइप करता है। किबाना के साथ मैं लॉग और कुल डेटा देख सकता हूं।

मुझे ऑपरेटिंग सिस्टम की मूल syslog फ़ाइल में लॉगिंग का समर्थन करना भी अच्छा लगेगा, उदाहरण के लिए: उबंटू पर मैं /var/log/syslog लॉग लिख सकता हूं, जिसे बॉक्स के बाहर लॉगरोटेट द्वारा प्रबंधित किया जाता है।

झुंड / रचना के साथ, मैं यह कर सकता हूँ:

version: '3.3'
services:
  mysql:
    image: mysql:5.7
    logging:
      driver: syslog
      options:
        tag: mysql

एक emtpyDir वॉल्यूम का उपयोग करना ठीक है, हालांकि, लंबे समय तक चलने वाले पॉड्स में वॉल्यूम भरने का जोखिम होता है जब तक कि आप एक अतिरिक्त प्रक्रिया नहीं जोड़ते जो लॉग फ़ाइलों को घुमाते / काटते हैं। मैं इस अतिरिक्त जटिलता से सहमत नहीं हूं जब ओएस पहले से ही /var/log/syslog के रोटेशन को संभाल रहा है।

मैं सहमत हूं कि कुछ परिनियोजन के लिए साइडकार का उपयोग करना एक अच्छा विचार है (मैं पहले से ही अपने कुछ परिनियोजन के लिए ऐसा करता हूं), हालांकि, हर किसी का वातावरण अलग होता है।

एक emtpyDir वॉल्यूम का उपयोग करना ठीक है

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

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

@coffeepac सिर्फ इसलिए कि नोड्स में syslog नहीं हो सकता है इसका मतलब यह नहीं है कि ऑपरेटर के पास विकल्प नहीं होना चाहिए। अगर मैं syslog का उपयोग करने का इरादा रखता हूं, तो मैं यह सुनिश्चित करूंगा कि मेरे कार्यकर्ता नोड्स में syslog हो।

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

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

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

मुझे कई बार बताया गया है कि कुबेरनेट्स पर लॉगिंग सेट करना आसान है, लेकिन अब अपनी लॉगिंग एग्रीगेशन सिस्टम स्थापित करने की प्रक्रिया के माध्यम से मैं कह सकता हूं कि यह वास्तव में आसान नहीं है।

मैंने कुबेरनेट्स के लिए अपने स्वयं के लॉग एग्रीगेशन सिस्टम को हैंड-रोल करने के सबसे सरल तरीके पर एक ब्लॉग पोस्ट लिखा है: http://www.the-data-wrangler.com/kubernetes-log-aggregation/

उम्मीद है कि मेरी ब्लॉग पोस्ट दूसरों को अपनी रणनीति बनाने में मदद करेगी।

यह इतना कठिन नहीं होना चाहिए, लेकिन हम यहीं पर हैं।

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

क्या हम डॉकर लॉग-ड्राइवर को लागू कर सकते हैं? मैं

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

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

यह सुनिश्चित करने में मददगार होगा कि हम https://github.com/cri-o/cri-o/pull/1605 जैसा कुछ करते हैं, जहां हम लॉग ड्राइवरों से लॉग स्ट्रीम व्याख्या को डिस्कनेक्ट करते हैं ताकि कंटेनर व्यवहार कैसे प्रभावित न हो ड्राइवर काम करते हैं।

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/बंद करे

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

फ़ंक्शन को अभी भी लागू करने की आवश्यकता है
/फिर से खोलना

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

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

ठीक है, मैं समझ गया

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

"लॉगकॉन्फ़िगरेशन": {
"लॉगड्राइवर": "स्प्लंक",
"विकल्प": {
"स्प्लंक-प्रारूप": "कच्चा",
"splunk-insecureskipverify": "true",
"स्प्लंक-टोकन": "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx",
"स्प्लंक-यूआरएल": " https://xxxxx.splunk-heavyforwarderxxx.com ",
"टैग": "{{.Name}}/{{.ID}}",
"स्प्लंक-सत्यापन-कनेक्शन": "झूठा",
"मोड": "गैर-अवरुद्ध"
}
}

लेकिन k8s में ऐसा कुछ नहीं मिला। यह पॉड परिभाषा में ही होना चाहिए।

विकल्पों को अभी भी लागू करने की आवश्यकता है
/फिर से खोलना

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

/ हस्ताक्षर नोड
/ रिमूव-सिग इंस्ट्रूमेंटेशन

/निकालें-हस्ताक्षर मापनीयता

@logichan : वे लेबल इस मुद्दे पर सेट नहीं हैं: sig/

इसके साथ कोई प्रगति?
मैं विशेष रूप से बाहरी लॉगस्टैश में लॉग इन करने के लिए पॉड्स के कंटेनरों को सेटअप करने की क्षमता की तलाश कर रहा था, जो डॉकटर के गेल्फ लॉग-ड्राइवर को निर्दिष्ट करता है। /etc/docker/daemon.json में सभी कंटेनरों के लिए इसे डिफ़ॉल्ट रूप से सेट करना एक ओवरहेड लगता है।

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/बंद करे

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

/फिर से खोलना

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

/फिर से खोलना

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

@ejemba : इस मुद्दे को वर्तमान में ट्राइएज की प्रतीक्षा है।

यदि कोई SIG या सबप्रोजेक्ट यह निर्धारित करता है कि यह एक प्रासंगिक मुद्दा है, तो वे triage/accepted लेबल लागू करके इसे स्वीकार करेंगे और आगे मार्गदर्शन प्रदान करेंगे।

triage/accepted लेबल को संगठन के सदस्यों द्वारा एक टिप्पणी में /triage accepted लिखकर जोड़ा जा सकता है।

मैं वास्तव में इस सुविधा को लागू करना चाहूंगा। मैं वर्तमान में Rancher 1.x क्लस्टर से Rancher 2.x क्लस्टर पर कार्यभार माइग्रेट कर रहा हूं जो k8s चलाते हैं। हमारे पास एक परिनियोजन है जो डॉकर-कंपोज़ कॉन्फ़िगरेशन में लॉग-ड्राइवर और लॉग-ऑप्ट पैरामीटर सेट करता है।

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

ऐसा लगता है कि हमें यह निर्दिष्ट करने के लिए CRI-O को बदलना चाहिए कि दोनों कंटेनर लॉग स्ट्रीम (stdout / stderr) को कच्चे रूप में एकत्र किया जाता है, और बाद के लिए रॉ को पढ़ते समय हम लॉग बाइट स्ट्रीम की विभिन्न व्याख्याओं को लागू कर सकते हैं।

देखें https://github.com/cri-o/cri-o/pull/1605।

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

sig-testing, Kubernetes/test-infra और/या fejta को फ़ीडबैक भेजें।
/बंद करे

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