Kubernetes: تحديد برنامج تشغيل السجل واختيار السجل عند تحديد البود في RC و Pod

/ cc @ kubernetes / rh-cluster-infra

حسنًا ، أعتقد أننا ربما نرغب في أن نكون قادرين على تعيين هذه الكتلة على مستوى المجموعة افتراضيًا ، ومن ثم ربما نسمح بتعريفات حجرة معينة لتجاوزها.

سممكعبsosiouxmesmarterclaytonliggittjwhoncejcantrillbpareesjwforres

هل يمكنك وصف كيف يمكنك الاستفادة من هذا على أساس كل حاوية (حالة الاستخدام)؟ نحن تقليديًا لا نعرض خيارات Docker المحددة مباشرة في الحاويات ما لم يكن من الممكن استخراجها بشكل نظيف عبر أوقات التشغيل. إن معرفة كيف تريد استخدام هذا سيساعد في تبريره.

لاحظ أن سجلات عامل الإرساء لا تزال تدعم فقط ملفات json وبرامج التشغيل اليومية ، على الرغم من أنني أتخيل أن هذه القائمة يمكن أن تتوسع.

ربما ما يريده المستخدمون بالفعل هو تحديد نقاط نهاية كتابة السجل المحددة ، وليس التعرض لتفاصيل برنامج تشغيل التسجيل.

ncdcsmarterclayton وأنا أتفق مع كل واحد منكما، بعد إعادة النظر في حالة استخدامنا في داخلي، اتضح أن

1. حاجتنا الأساسية هي حماية عقدنا. نرسل السجلات إلى خادم السجل ولكن في حالة فشلها ، يتم الاحتفاظ بالسجلات احتياطيًا في السجلات الداخلية لعمال الإرساء. في مثل هذه الحالة ، لمنع تشبع العقدة ، نحتاج إلى سلوك واسع للكتلة لسجل عامل الإرساء
2. إن عرض خيارات عامل إرساء محددة في تعريفات pod / Rc ليست فكرة جيدة كما اقترحها smarterclayton . نتفق أيضًا مع تجريد يسمح بتعريف سلوك السجل عالي المستوى إن أمكن
3. خيار آخر هو إجراء تغيير على ملفات تكوين kubelet والتعليمات البرمجية للتعامل مع سلوك السجل هذا

لا ينبغي أن تكون التغييرات التي تم إجراؤها على قوالب الملح لجعل هذا الخيار افتراضيًا
صعب للغاية. إنه حقًا مجرد تكوين خفي مناسب (و
التعامل مع أي تغييرات على سجل التجميع عبر بطلاقة بحكم
اختيار مصدر مختلف)

يوم الثلاثاء ، 13 أكتوبر 2015 ، الساعة 10:55 صباحًا ، Epo Jemba [email protected]
كتب:

ncdc https://github.com/ncdcsmarterclayton
https://github.com/smarterclayton أتفق معكما بعد
إعادة النظر في حالة استخدامنا داخليًا ، اتضح أن

1. حاجتنا الأساسية هي حماية عقدنا. نرسل السجلات إلى السجل
   الخادم ولكن إذا فشل ، فسيسجل احتياطيًا في سجلات عامل الإرساء الداخلية. في مثل
   الحالة ، لمنع تشبع العقدة ، نحتاج إلى سلوك جماعي واسع لـ
   سجل عامل ميناء
2. إن عرض خيارات عامل إرساء محددة في تعريفات pod / Rc ليس ملفًا
   فكرة جيدة مثل smarterclayton https://github.com/smarterclayton
   اقترح ذلك. نتفق أيضًا مع تجريد يسمح بتعريف مرتفع
   مستوى سلوك سجل إن أمكن
3. هناك خيار آخر وهو إجراء تغيير على ملفات تكوين kubelet و
   رمز للتعامل مع سلوك السجل هذا

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -147740136
.

:ممتاز:

لاحظ أن هناك الآن 9 برامج تشغيل للتسجيل . ما هو الإجماع على الحصول على هذا؟

+1

في حالة عدم علم أي شخص ، يمكنك تحديد برنامج تشغيل السجل الافتراضي على أساس كل عقدة مع إشارة إلى Docker daemon ( --log-driver ). في بيئتي ، قمت بتعيين برنامج التشغيل على journald بهذه الطريقة. أجد صعوبة في التفكير في حالة استخدام لتجاوز هذا على أساس كل حاوية لأكون صادقًا.

لن ترغب معظم المجموعات في إخراج سجلاتهم "خارج النطاق" ، لذا ما هو تمكين الميزة الذي سيوفره هذا.

أيضًا ، من منظور العمليات ، يبدو الأمر وكأنه فقد السيطرة. نقوم حاليًا بتعيين الإعدادات الافتراضية وتكوين مكدس تسجيل للتجميع.

+1 على هذا.
عدم القدرة على التحكم في كيفية التعامل مع تسجيل عامل الإرساء يعني أن خيار التسجيل العقلاني الوحيد هو استخدام الأدوات التي يتم شحنها مع k8s ، وهو قيد لا يصدق.

timothysc هنا لدينا حالة الاستخدام. لدينا بنية تحتية ديناميكية معقدة (حوالي 100 جهاز) مع الكثير من الخدمات الحالية التي تعمل عليها ، مع logstash الخاص بنا لجمع السجلات. حسنًا ، نحاول الآن نقل خدماتنا ، واحدة تلو الأخرى ، إلى k8s ويبدو لي أنه لا توجد طريقة نظيفة لدمج التسجيل بين بنيتنا التحتية الحالية والحاويات المجمعة على k8s.

K8S لديها رأي شديد بشأن كيفية جمع السجلات. قد يكون هذا رائعًا لمن يبدأ من نقطة الصفر في بنية أساسية بسيطة. بالنسبة لأي شخص آخر يعمل على بنى تحتية معقدة والتي لا تمانع في الغوص بعمق وتنفيذ آلية تسجيل مخصصة ، لا توجد طريقة للقيام بذلك في الوقت الحالي ، وهو أمر محبط للغاية.

نأمل أن يكون ذلك منطقيًا.

لذا فإن السجلات في السيناريو الخاص بك هي حقًا "لكل تطبيق" ، ولكن عليك ذلك
التأكد من أن المضيف الأساسي يدعم هذه السجلات؟ هذا هو مصدر القلق نحن
نناقش هنا - إما أن نفعل مستوى الكتلة ، أو مستوى العقدة ، ولكن إذا فعلنا ذلك
مستوى البود ، ثم يجب أن يكون المجدول على دراية بسجلات السائقين
موجودة حيث. بقدر الإمكان نحاول تجنب ذلك.

يوم الإثنين 23 مايو 2016 الساعة 10:50 صباحًا ، Jacopo Nardiello < [email protected]

كتب:

+1 على هذا.
عدم القدرة على التحكم في كيفية معالجة تسجيل عامل الإرساء يعني ضمناً أن ملف
فقط خيار التسجيل العقلاني هو استخدام الأدوات التي يتم شحنها مع k8s ، وهو ملف
حدود لا تصدق.

timothysc https://github.com/timothysc هنا حالة الاستخدام الخاصة بنا. لدينا
البنية التحتية الديناميكية المعقدة (حوالي 100 آلة) مع الكثير من العناصر الموجودة
الخدمات التي تعمل عليها ، مع logstash الخاص بنا لجمع السجلات. حسنًا ، نحن
تحاول الآن نقل خدماتنا ، واحدة تلو الأخرى ، إلى k8s ولي هناك
يبدو أنه لا توجد طريقة نظيفة لدمج التسجيل بين الموجود لدينا
البنية التحتية والحاويات المجمعة على k8s.

K8S لديها رأي شديد بشأن كيفية جمع السجلات. قد يكون هذا رائعًا
لمن يبدأ من الصفر على بنية تحتية بسيطة. ل
أي شخص آخر يعمل على بنى تحتية معقدة لا يمانع في ذلك
الغوص بعمق وتنفيذ آلية تسجيل مخصصة ، ببساطة لا يوجد
طريقة القيام بذلك في الوقت الحالي ، وهو أمر محبط للغاية.

نأمل أن يكون ذلك منطقيًا.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221002545

smarterclayton أنا أفهم مخاوفك وهم في وضع جيد. لست متأكدًا مما إذا كان يجب أن تكون المجموعة بأكملها على دراية بوجود تسجيل على مستوى البود ، ما أعتقد أنه يجب علينا القيام به هو إعطاء خيار تسجيل pod stdout / stderr في مكان ما (ملف يعتمد على اسم pod الحالي؟) بحيث يكون لأي شخص يرغب في تنفيذ حله المخصص مكانًا ثابتًا للحصول على المحتوى. هذا يفتح بابًا ضخمًا على الرغم من أن التسجيل ليس بالأمر التافه.

هذان فقط سنتان ، لكن لا يمكننا التظاهر بأن السيناريوهات المعقدة في العالم الحقيقي تتخلى فقط عن البنية التحتية الحالية للتسجيل.

هل تحدد خيارات السجل المخصصة لكل تطبيق؟ كم مختلفة
مجموعات من خيارات السجل لديك لكل مجموعة؟ إذا كانت هناك مجموعات صغيرة من
config ، سيكون أحد الخيارات هو دعم التعليق التوضيحي على البودات
مرتبط بتكوين مستوى العقدة الذي يقدم عددًا من "السجل القياسي
الخيارات ". أي في وقت إطلاق kubelet ، حدد" وضع السجل X "(الذي يحدد
خيارات السجل المخصص وبرنامج التشغيل) ، وسيحدد الكبسولة "
pod.alpha.kubernetes.io/log.mode=X ".

خيار آخر هو أن نكشف عن طريقة للسماح للجهات الناشرة بالحصول على
فرصة لتغيير تعريف الحاوية مباشرة قبل أن نبدأ
الحاوية. هذا أصعب اليوم لأننا سنضطر إلى إجراء تسلسل لملف
تعريف عامل ميناء إلى تنسيق وسيط ، وتنفيذه ، ثم تشغيله
مرة أخرى ، ولكن من المحتمل أن يكون أسهل في المستقبل.

أخيرًا ، يمكننا الكشف عن أزواج القيمة الرئيسية على واجهة الحاوية التي
يتم تمريرها إلى محرك الحاوية مباشرة ، ولا تقدم أي ضمانات لـ API
لهم ، والتأكد من أن PodSecurityPolicy يمكنه تنظيم هذه الخيارات. التي من شأنها أن
تكون فتحة الهروب للمتصلين ، لكننا لن نتمكن من توفير أي منها
تضمن أن هؤلاء سيستمرون في العمل عبر الإصدارات.

يوم الخميس ، 26 مايو 2016 ، الساعة 5:34 صباحًا ، Jacopo Nardiello [email protected]
كتب:

smarterclayton https://github.com/smarterclayton أنا أفهم
مخاوفك وهي في وضع جيد. لست متأكدًا مما إذا كانت المجموعة بأكملها
يجب أن نكون على دراية بوجود تسجيل على مستوى البود ، ما أعتقده نحن
يجب القيام به هو إعطاء خيار تسجيل pod stdout / stderr في مكان ما (ملف
بناءً على اسم الكبسولة الحالي؟) بحيث يمكن لأي شخص يرغب في تنفيذ ملفات
حل مخصص ، سيكون له مكان دائم للحصول على المحتوى.
هذا يفتح بابًا ضخمًا على الرغم من أن التسجيل ليس بالأمر التافه.

هذان فقط سنتان ، لكن لا يمكننا التظاهر بهذا المركب الواقعي
سيناريوهات مجرد التخلي عن البنية التحتية لتسجيل الأشجار الموجودة لديهم.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/15478#issuecomment -221823732

smarterclayton هل رأيت https://github.com/kubernetes/kubernetes/issues/24677#issuecomment -220735829

لا شكرا. تتحرك المناقشة هناك.

الخميس، 26 مايو 2016 الساعة 11:23 صباحا، أندي غولدشتاين [email protected]
كتب:

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

أهلا،
أعتقد أن هذه ميزة مهمة يجب مراعاتها في kubernetes.
يمكن أن يؤدي تمكين استخدام برنامج تشغيل سجل Docker إلى حل بعض المشكلات غير التافهة.

أود أن أقول أن التسجيل على القرص هو نمط مضاد. السجلات هي بطبيعتها "حالة" ، ويفضل عدم حفظها على القرص. يؤدي شحن السجلات مباشرة من الحاوية إلى المستودع إلى حل العديد من المشكلات.

يعني تعيين برنامج تشغيل السجل أن الأمر kubectl logs لا يمكنه إظهار أي شيء بعد الآن.
على الرغم من أن هذه الميزة "لطيفة التوفر" - لن تكون هناك حاجة إلى الميزة عندما تكون السجلات متاحة من مصدر مختلف.

يحتوي Docker بالفعل على برامج تشغيل سجلات لـ google cloud (gcplogs) و Amazon (awslogs). في حين أنه من الممكن تعيينها على Docker daemon نفسه ، فإن هذا له العديد من العيوب. من خلال القدرة على ضبط خياري عامل الإرساء:

--log-driver = برنامج تشغيل التسجيل للحاوية
--log-opt = [] خيارات برنامج تشغيل السجل

سيكون من الممكن الإرسال مع التصنيفات (لـ gcplogs) أو awslogs-group (لـ awslogs)
خاص بجراب. سيسهل ذلك العثور على السجلات في الطرف الآخر.

لقد كنت أقرأ عن كيفية تعامل الأشخاص مع السجلات في kubernetes. يبدو أن الكثيرين أنشأوا بعض أدوات الكشط المعقدة التي تعيد توجيه السجلات إلى الأنظمة المركزية. إن القدرة على ضبط برنامج تشغيل السجل سيجعل ذلك غير ضروري - توفير الوقت للعمل على أشياء أكثر إثارة :)

يمكنني أيضًا أن أضيف أن بعض الأشخاص ، بمن فيهم أنا ، يرغبون في إجراء تناوب لسجلات عامل الإرساء عبر خيار "--log-opt max-size" على برنامج تشغيل تسجيل JSON (وهو أصلي بالنسبة إلى عامل الإرساء) بدلاً من إعداد logrotate على المضيف. لذا ، فإن مجرد الكشف عن خيار "--log-opt" سيكون موضع تقدير كبير

لقد قمت بتعديل k8s ، عند إنشاء تكوين حاوية LogConfig.

+1
يبدو استخدام برنامج تشغيل سجل عامل الإرساء لتجميع السجلات المركزية أكثر بساطة ثم إنشاء روابط رمزية لملفات السجل ، وتثبيتها في حاوية خاصة بطلاقة ، وتقسيمها وإدارة تدوير السجل.

حالة الاستخدام لتهيئة كل حاوية: أريد تسجيل الدخول في مكان آخر أو بشكل مختلف للحاويات التي أقوم بنشرها ولا أهتم (أو أريد تغيير) برنامج تشغيل السجل للحاويات القياسية اللازمة لتشغيل Kubernetes.

ها أنت ذا. من فضلك اجعل هذا يحدث.

فكرة أخرى ، حيث لا تزال جميع الحاويات تعيد توجيه السجلات إلى نفس نقطة النهاية ، ولكن يمكنك على الأقل تعيين قيم حقول مختلفة لحاويات عامل إرساء مختلفة على خادم السجل الخاص بك.

سيعمل هذا مع برنامج تشغيل gelf docker ، إذا تمكنا من التأكد من أن حاويات عامل الإرساء التي أنشأتها Kubernetes مصنفة حسب الطلب. المعنى: يمكن إعادة توجيه بعض حقول Pod كتسميات حاوية عامل إرساء. (ربما هذا ممكن بالفعل لكني لا أعرف كيف أحقق ذلك).

مثال بدون Kubernetes ، فقط مع Docker daemon و gelf driver. قم بتكوين برنامج Docker daemon مع: --log-driver=gelf --log-opt labels=env,label2 وأنشئ حاوية عامل إرساء:

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"

بهذه الطريقة ، في Graylog ، يمكنك التمييز بين الحاويات env=production و env=testing الحاويات.

أستخدم حاليًا خيارات Docker daemon هذه:

--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 ، فقط ما يجب تأكيده هو ميزة موجودة أو

أستخدم حاليًا خيارات Docker daemon هذه:

--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 daemon التي أستخدمها حاليًا تعمل بالفعل. يعيّن Kubernetes بالفعل بعض التصنيفات لكل حاوية عامل إرساء. على سبيل المثال ، عند تشغيل docker inspect على حاوية kube-apiserver:

 "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 هذه.

ومع ذلك ، أعتقد أنه ليس من الممكن الآن جعل Kubernetes يضع ملصقات مخصصة على حاوية عامل إرساء تستند إلى مواصفات Pod. على سبيل المثال ، --log-driver=gelf --log-opt labels=env,label2 لا يعمل.

هل هناك أخبار على هذا الصعيد؟ إن امتلاك القدرة على تحديد الملصقات ثم الاستفادة من --log-opt labels<> سيكون جيدًا جدًا!

portantejcantrill فقط للاستيلاء عليها هنا لأننا مناقشته، وهنا هو حالة الاستخدام التي كنا نفكر أن هذا قد يكون مفيدا ل:

عندما تبدأ كبسولات تسجيل السجلات في مواجهة الأخطاء وتسجيلها ، فإن البنية التحتية التي تجمع هذه الأخطاء ستلتقطها وتعيدها إلى آلية التسجيل التي بدورها تلقي وتسجيل المزيد من الأخطاء.

يمكن تجنب حلقة التغذية الراجعة هذه باستخدام آليات التصفية ، لكن هذا هش قليلاً. يبدو أن استخدام برنامج تشغيل تسجيل مختلف للتسجيل في ملف ولديك خيارات تدوير سيكون حلاً جيدًا.

2 سنتي.

الحلول الحالية لتسجيل الدخول داخل k8s هي (AFAIK):

• إرسال الحاوية الجانبية سجلات في مكان ما
• وحدة تحكم النسخ المتماثل ترسل جميع السجلات في مكان ما
• الحاوية نفسها ترسل السجلات في مكان ما

حاوية Sidecar تبدو نوعًا من المبالغة بالنسبة لي. تبدو إستراتيجية وحدة التحكم في النسخ جيدة ، ولكنها تجمع بين سجلات الحاويات من جميع عمليات النشر ، وقد يرغب بعض المستخدمين في ذلك الآن ، وقد يرغبون بدلاً من ذلك في تسجيل كل تطبيق في شيء مختلف. في هذه الحالات ، يعمل الخيار الأخير بشكل أفضل IMHO ، ولكنه ينشئ الكثير من التعليمات البرمجية المنسوخة في جميع الحاويات (على سبيل المثال: البرنامج الخفي للتثبيت والإعداد logentries).

سيكون كل هذا أسهل بكثير إذا كان لدينا وصول إلى علامات log-driver ، لذلك ستحدد كل عملية نشر كيفية تسجيلها ، باستخدام ميزات عامل الإرساء الأصلية.

يمكنني محاولة تنفيذ ذلك ، ولكن ربما سأحتاج إلى بعض المساعدة - لأنني لست على دراية بقاعدة كود kubernetes.

بمجرد أن يصبح الإيجار المتعدد شيئًا ، سيكون من الصعب حله بشكل صحيح.

قد تكون كل مساحة اسم مستأجرًا مختلفًا ، لذا لا يجب بالضرورة تجميع السجلات من كل مساحة ، ولكن يُسمح بإرسالها إلى مواقع المستأجر المحددة.

يمكنني التفكير في عدة طرق للقيام بذلك:

1. إنشاء نوع وحدة تخزين جديد ، سجلات الحاوية. يسمح هذا لمجموعة daemonset التي يتم إطلاقها بواسطة مساحة اسم معينة بالوصول فقط إلى السجلات من حاوياتها الخاصة. يمكنهم بعد ذلك إرسال السجلات مع أي شركة شحن يختارونها لأي خدمة تخزين يختارونها.
2. قم بتعديل واحد من (أو أكثر) من شركات شحن السجل ، مثل بت بطلاقة لقراءة مساحة الاسم الموجودة في الكبسولة ، وإعادة توجيه السجلات من كل جراب إلى مشغل سجل آخر يعمل في مساحة الاسم هذه كخدمة. مثل بطلاقة. يسمح هذا مرة أخرى لمساحة الاسم بتكوين شاحن السجل الخاص بها للدفع إلى أي خلفية سجل تريد دعمها.

@ caarlos0 @ kfox1111 أتفق مع نقاطك. هذا موضوع معقد ، لأنه يتطلب تنسيق الأجهزة والتخزين والعقدة وربما المزيد من الفرق. أقترح وضع اقتراح لهيكل التسجيل الشامل الذي تم وضعه أولاً ثم مناقشة التغيير إلى وجهة النظر المتسقة هذه. أتوقع أن يظهر هذا الاقتراح في غضون شهر أو نحو ذلك ، لإحداث النظام ومعرفة جميع المشاكل المذكورة.

crassirostris لست متأكدًا من فهمي: إذا سمحنا فقط بـ log-driver وآخرون ، فلن نضطر للتعامل مع التخزين أو أي من ذلك ، أليس كذلك؟

هل يرسل عامل الميناء فقط STDOUT إلى أي برنامج تشغيل سجل تم إعداده في قاعدة الحاوية ، أليس كذلك؟ لقد نقلنا المسؤولية إلى الحاوية ... يبدو أنه حل بسيط جدًا بالنسبة لي - لكن ، كما قلت ، لا أعرف قاعدة الشفرة ، لذلك ربما أكون مخطئًا تمامًا ...

تكمن المشكلة في أن برنامج تشغيل السجل في عامل الإرساء لا يضيف أيًا من البيانات الوصفية لـ k8s التي تجعل استهلاك السجلات لاحقًا مفيدًا بالفعل. : /

@ kfox1111 هممم ، منطقي ...

ولكن ، ماذا لو كان المستخدم يريد فقط سجلات "التطبيق" ، وليس سجلات kubernetes ، وليس سجلات عامل التحميل ، فقط التطبيق الذي يتم تشغيله داخل سجلات الحاوية؟

في هذه الحالة ، يبدو لي أن log-driver سيعمل ...

@ caarlos0 قد يكون لها بعض الآثار ، على سبيل المثال ، يضع kubelet بعض الافتراضات حول تنسيق التسجيل في سجلات الخادم kubectl.

ولكن بغض النظر عن كل الأشياء ، فإن log-driver في حد ذاته خاص بـ Docker وقد لا يعمل في أوقات التشغيل الأخرى ، وهذا هو السبب الرئيسي لعدم تضمينه في API.

MustafaHosny اللهم امين ...

نظرًا لأن هذه الميزة لن تتم إضافتها (كما هو موضح في المشكلة) ، فربما يجب إغلاق هذه المشكلة (أو تعديلها أو أي شيء آخر)؟

@ caarlos0 ومع ذلك ، نريد بالتأكيد جعل إعداد التسجيل أكثر مرونة وشفافية. سيتم تقدير ملاحظاتك على الاقتراح!

يتم حاليًا التعامل مع تسجيل stdout من الحاويات خارج النطاق داخل Kubernetes. نحن نعتمد حاليًا على حلول غير تابعة لـ Kubernetes للتعامل مع التسجيل ، أو الحاويات المميزة التي تكسر Kubernetes للوصول إلى التسجيل خارج النطاق. يختلف تسجيل وقت تشغيل الحاوية باختلاف وقت التشغيل (عامل ميناء ، rkt ، Windows) ، لذا فإن اختيار أي واحد ، مثل Docker --log-driver يؤدي إلى إنشاء أمتعة مستقبلية.

أقترح أننا بحاجة إلى kubelet لإعادة تدفقات السجل إلى النطاق. حدد أو اختر تنسيق سجل JSON أو XML ، والذي يجمع سطور stdout من كل حاوية ، أضف الحد الأدنى من البيانات الوصفية للكتلة + مساحة الاسم + pod + الحاوية ، بحيث يتم تحديد مصدر السجل داخل مساحة Kubernetes ، وتوجيه الدفق إلى خدمة Kubernetes + ميناء. المستخدمون أحرار في تقديم أي خدمة استهلاك سجل يحلو لهم. ربما ستوفر Kubernetes خدمة مرجعية / افتراضية واحدة تنفذ دعم "سجلات kubectl".

بدون تحديد خدمة استهلاك التسجيل ، سيتم تجاهل السجلات ولن تصل إلى القرص على الإطلاق . دفق السجلات في مكان آخر ، أو الكتابة إلى التخزين الدائم والتناوب ، كل هذا هو مسؤولية / قرار الخدمة.

يقوم غلاف وقت تشغيل حاوية kubelet بالحد الأدنى لاستخراج stdout من كل وقت تشغيل حاوية ، وإعادته إلى النطاق الترددي للخدمة (الخدمات) المستضافة ذاتيًا لـ k8s للاستهلاك والمعالجة.

تحدد مواصفات الحاوية في Deployment أو Pod بشكل اختياري الخدمة والمنفذ الهدف لتسجيل stdout. ستكون إضافة بيانات تعريف k8s للمجموعة + مساحة الاسم + الحاوية + حاوية اختيارية (لذا فإن اختيار خام / لم يمس أو مع بيانات وصفية). سيكون المستخدمون أحرارًا في تجميع جميع السجلات في مكان واحد ، أو التجميع حسب المستأجر ، أو مساحة الاسم ، أو التطبيق.

الأقرب إلى ذلك الآن هو تشغيل خدمة تستخدم 'kubectl logs -f' لدفق سجلات الحاوية لكل حاوية عبر خادم API. هذا لا يبدو فعالاً أو قابلاً للتطوير. سيسمح هذا الاقتراح بتبخير مباشر أكثر كفاءة من غلاف وقت تشغيل الحاوية مباشرة إلى الخدمة أو Pod ، مع تحسينات مثل تفضيل نشر التسجيل أو Daemonset Pods على نفس العقدة والحاوية التي تنشئ السجلات.

أقترح أن تقوم Kubernetes بالحد الأدنى لإحضار سجلات وقت تشغيل الحاوية بكفاءة في النطاق ، لأي حلول تسجيل مستضافة ذاتيًا أو متجانسة أو غير متجانسة نقوم بإنشائها داخل مساحة Kubernetes.

ماذا يعتقد الناس؟

whereisaaron ، أود حقًا عدم إجراء هذه المناقشة الآن ، عندما لا تتوفر لدينا جميع التفاصيل حول نظام التسجيل البيئي في مكان واحد.

على سبيل المثال ، أرى مشكلات في الشبكة والآلة تعطل تدفق السجل ، ولكن مرة أخرى ، لا أريد مناقشتها الآن. ماذا لو نناقش هذا لاحقًا ، عندما يكون الاقتراح جاهزًا؟ هل يبدو معقولا بالنسبة لك؟

بالتأكيدcrassirostris. يرجى إخبارنا هنا عندما يكون الاقتراح جاهزًا للمراجعة.

/ سيج قابلية التوسع

على الرغم من أن كلاً من --log-driver و --log-opt هما خياران لخفي Docker وليس لميزات k8s ، سيكون من الجيد تحديدهما في مواصفات حجرة k8s لـ:

1. لكل برنامج تشغيل السجل وليس برنامج تشغيل سجل على مستوى عقدة واحدة
2. أنواع مختلفة من برامج تشغيل السجل الخاصة بالتطبيق (بطلاقة ، سجل النظام ، مجلة ، سبونك) على نفس العقدة
3. قم بتعيين --log-opt لتهيئة تدوير السجل لحجرة
4. لكل إعدادات --log-opt وليس مستوى عقدة واحدة --log-opt

AFAIK ، لا يمكن تعيين أي مما سبق على مستوى pod في مواصفات pod k8s اليوم.

vhosakot لا يمكن تعيين أي مما سبق على أي مستوى في Kubernetes ، لأن هذه ليست مفاهيم Kubernetes

تضمين التغريدة :)

إذا كان k8s يفعل كل ما يفعله Docker على مستوى البود / مستوى الحاوية ، ألن يكون ذلك سهلاً على المستخدمين؟ لماذا تجعل المستخدمين يستخدمون Docker على الإطلاق لبعض الأشياء على مستوى البود / على مستوى الحاوية؟

ويمكن لمحبي k8s وليس من محبي Docker طرح نفس السؤال.

vhosakot Point هو أن هناك عددًا من أوقات تشغيل الحاوية الأخرى التي يمكن استخدامها مع K8s ، ولكن --log-opt موجود فقط في Docker. سيؤدي إنشاء مثل هذا الخيار على مستوى K8s إلى تسريب التجريد عن قصد. لا أعتقد أن هذه هي الطريقة التي نريد أن نسير بها. إذا كان الخيار موجودًا ، فيجب أن يكون مدعومًا بجميع أوقات تشغيل الحاوية ، ويكون مثاليًا جزءًا من CRI

أنا لا أقول أنه لن يكون هناك مثل هذا الخيار ، أنا أقول أنه لن يكون طريقًا مباشرًا إلى Docker

crassirostris صحيح ، يبدو أن الأمر يتعلق بما إذا كان يجب على k8s القيام بما يفعله / يسمح به CRI على مستوى الحاوية / مستوى الحاوية ، وليس خاصًا بـ Docker.

نعم ، صحيح تمامًا

على الرغم من تأخري في هذه المناقشة ولدي اهتمام برؤية هذه الميزة مطبقة ، إلا أنني أزعم أن هناك مفاضلة بين امتلاك تصميم جميل وطريقة مباشرة لإعداد حل تسجيل عاقل وموحد للمجموعة. نعم ، سيؤدي تنفيذ هذه الميزة إلى الكشف عن عامل الإرساء الداخلي ، وهو رقم كبير لا ، ولكن في نفس الوقت يمكنني المراهنة بأموال جيدة على أن غالبية مستخدمي K8S يستخدمون عامل الإرساء لأن تقنية الحاوية الأساسية وعمال الإرساء تأتي مع قائمة شاملة للغاية من سجل السائقين.

@ gabriel-tincu لست مقتنعًا حاليًا بأن FR الأصلي يستحق العناء

يأتي عامل الإرساء مع قائمة شاملة جدًا من برامج تشغيل السجل

يمكنك إعداد تسجيل الدخول على مستوى Docker أثناء خطوة نشر K8s واستخدام أي من برامج تشغيل السجل هذه ، دون تسريب هذه المعلومات إلى K8s. الشيء الوحيد الذي لا يمكنك فعله اليوم هو إعداد تلك الخيارات لكل حاوية / لكل جراب (في الواقع ، يمكنك إعداد عقد مع عقد مخصص واستخدام محدد العقدة) ، لكنني لست متأكدًا من أنه قيد كبير.

crassirostris أوافق على أنه يمكنك إعداد ذلك __قبل__ إعداد البيئة ، ولكن إذا كانت هناك طريقة لتحديث برنامج تشغيل سجل عامل الإرساء بشكل نشط بعد إعداد البيئة بالفعل ، فهذا أمر بعيد المنال في الوقت الحالي

تم إهمال @ غابرييل-tincuvhosakot واجهة المباشرة التي كانت قائمة بين k8s وعامل الميناء مرة أخرى في "يوم الخوالي" من> = 1.5 وأعتقد رمز إزالة تماما الآن. كل شيء بين kubelet وأوقات التشغيل مثل Docker (أو الآخرين مثل rkt ، cri-o ، runc ، lxd) يمر عبر CRI. هناك الكثير من أوقات تشغيل الحاوية الآن ومن المحتمل أن يتم إهمال Docker نفسه وإزالته قريبًا لصالح cri-containerd + containerd .

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

crassirostris أي حركة بشأن اقتراح ، قد يكون لديها إمكانية تسجيل الحاوية في النطاق؟

سجل حاوية CRI مستند إلى ملف (https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/kubelet-cri-logging.md) ، ومسار السجل محدد بوضوح:

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

في معظم برامج تشغيل تسجيل Docker https://docs.docker.com/config/containers/logging/configure/#supported -logging-drivers ، أعتقد أنه بالنسبة لبيئة المجموعة ، فإن أهمها هي برامج تشغيل الحاوية التي تسجل الدخول إلى المجموعة نظام إدارة التسجيل ، مثل splunk ، awslogs ، gcplogs إلخ.

في حالة CRI ، يجب عدم استخدام "مشغل سجل عامل الإرساء". يمكن للأشخاص تشغيل مجموعة خوادم لاستيعاب سجلات الحاوية من دليل سجل حاوية CRI إلى أي مكان يريدون. يمكنهم استخدام اللغة بطلاقة أو حتى كتابة شيطان بأنفسهم.

إذا كانت هناك حاجة إلى مزيد من البيانات الوصفية ، فيمكننا التفكير في إسقاط ملف البيانات الوصفية ، أو تمديد مسار الملف أو السماح لمجموعة الشياطين بالحصول على البيانات الوصفية من الخادم. هناك مناقشة جارية حول هذا https://github.com/kubernetes/kubernetes/issues/58638

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

تتعفن المشكلات التي لا معنى لها بعد 30 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .
يتم إغلاق المشكلات الفاسدة بعد 30 يومًا إضافيًا من عدم النشاط.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة حياة فاسدة
/ إزالة دورة الحياة التي لا معنى لها

/ إزالة دورة الحياة فاسدة

أي تحديثات على هذا؟ فكيف قام أي شخص يقوم بتشغيل k8s مع حاويات Docker بتسوية التسجيل في بعض الخلفية مثل AWS CloudWatch؟

@ bryan831 من الشائع جمع ملفات سجل حاوية k8s باستخدام fluentd أو ما شابه وتجميعها في اختيارك للنهاية الخلفية و CloudWatch و StackDriver و Elastisearch وما إلى ذلك.

هناك مخططات Helm جاهزة للاستخدام على سبيل المثال fluentd + CloudWatch و fluentd + Elastisearch و fluent-bit-> fluentd-> اختيارك و Datadog وربما مجموعات أخرى إذا كنت تتجول.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، 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 يمكنك تمرير نفس --log-opt إلى docker daemon ، والذي سيؤثر على جميع حاوياتك ...

@ pmahalwar-intertrust السجلات التي تم جمعها من containerd بواسطة kubernetes تتضمن بالفعل بيانات وصفية شاملة ، قم بتضمين أي تسميات قمت بتطبيقها على الحاوية. إذا قمت بتجميعها باستخدام 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"
}

ألا يوجد حتى الآن أي خطة لدعم هذه الميزات؟
--log-driver = برنامج تشغيل التسجيل للحاوية
--log-opt = [] خيارات برنامج تشغيل السجل

مرحبًا lifubang ، لا يمكنني التحدث إلى خطط أي شخص ، ولكن البرنامج الخفي الذي يدعم هذه الميزات ، dockerd لم يعد جزءًا من Kubernetes (انظر المناقشة أعلاه التي تغطي ذلك).

لا يزال بإمكانك تثبيته اختياريًا إذا كنت ترغب في ذلك ، لذلك قد تتمكن من القيام بذلك من أجل استخدام برامج التشغيل القديمة dockerd log. تمت مناقشة هذا الخيار هنا:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

لكن استخدام خدمة تسجيل مخصصة مثل fluentd هو الأسلوب المقترح. يمكنك نشره عالميًا لمجموعتك أو لكل قرنة كأداة جانبية. تتم مناقشة تسجيل الدخول إلى Kubernetes هنا:
https://kubernetes.io/docs/concepts/cluster-administration/logging/

أوصي بشدة بطلاقة كما وصفها whereisaaron

بقدر ما يتم العمل على طلب الميزة هذا ... تحتوي خارطة الطريق المعمارية لـ kubernetes على تسجيل ضمن قسم "النظام البيئي" للأشياء التي ليست "جزءًا من" kubernetes ، لذا أشك في أن هذه الميزة سيتم دعمها أصلاً.
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md#summarytldr

أوصي بشدة بعدم استخدام fluentd لأنه يحتوي على العديد من الأخطاء التي يمكن أن تجعل حياتك مليئة بالمرح عند تشغيل k8s

in_tail يمنع عامل الإرساء من إزالة الحاوية https://github.com/fluent/fluentd/issues/1680.

يزيل in_tail موضع الملف الذي لم يتم تعقبه أثناء مرحلة بدء التشغيل. هذا يعني أن محتوى pos_file يتزايد حتى إعادة التشغيل ويمكن أن يلتهم الكثير من مسح وحدة المعالجة المركزية من خلاله عندما تقوم بإخراج الكثير من الملفات باستخدام إعداد المسار الديناميكي.
https://github.com/fluent/fluentd/issues/1126.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

شكرا لتجربتكroffe. بطلاقة / بطلاقة # 1680 كانت مشكلة تعود إلى k8s 1.5 ولم نستخدم "in_tail" في ذلك الوقت لهذا السبب. منذ انتقال k8s إلى containerd logging ، لا يبدو أنه لا يزال شيئًا؟ لم نلاحظ أي تأثير يمكن اكتشافه من التحدث بطلاقة / بطلاقة # 1126.

لقد أوصيت مقابل fluentd . ماذا تنصح بدلا من ذلك؟ ما الذي تستخدمه شخصيًا بدلاً من fluentd لتجميع السجل باستخدام البيانات الوصفية لـ k8s؟

تتعفن المشكلات التي لا معنى لها بعد 30 يومًا من الخمول.
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .
يتم إغلاق المشكلات الفاسدة بعد 30 يومًا إضافيًا من عدم النشاط.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة حياة فاسدة

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

@ fejta-bot: إغلاق هذه القضية.

هذا لا ينبغي أن يغلق ، أليس كذلك؟
لا يزال طلب الميزة منطقيًا بالنسبة لي لأنني أتطلع إلى تعيين خيارات السجل لكل جراب (بدون تعيينه على البرنامج الخفي أو استخدام logrotate) ...

أنا متأكد إلى حد ما من أن دعم خيارات التكوين الخاصة بعمال الشحن من داخل k8s ليست فكرة جيدة. كما ذكرنا سابقًا ، تعتبر السيارة الجانبية بطلاقة أو السيارة الجانبية فلوينت من الخيارات الحالية. أنا أفضل السيارة الجانبية لأنها أكثر أمانًا.

Whereisaaron هل وجدت حلاً لتسجيل الدخول لـ K8s @ containerd؟

هل لا يزال --log-driver، --log-opt غير مدعوم؟
أحاول إيجاد طريقة لإعادة توجيه السجلات من حجرة واحدة إلى Splunk. أيه أفكار؟

@ sariel1212 لحجرة واحدة أوصي بتضمين حاوية سيارة جانبية في جرابك الذي يمثل فقط وكيل الشحن الرائع. يمكنك مشاركة حجم emptydir بين جميع الحاويات في الحاوية وجعل حاوية (حاويات) التطبيق تكتب سجلاتها في emptydir المشترك. ثم اطلب من حاوية معيد التوجيه splunk قراءة من هذا المجلد وإعادة توجيهها.

إذا كنت تريد التجميع إلى Splunk من أجل مجموعتك بالكامل مخطط Splunk helm رسمي لنشر fluentd مع Splunk HEC fluentd plug-in لجمعها سجلات العقدة ، وسجل الحاوية ، وسجلات مستوى التحكم ، بالإضافة إلى كائنات Kubernetes ومقاييس مجموعة Kubernetes. بالنسبة إلى اقتراح Podcoffeepac لسيارة جانبية مع emptydir مشترك ، يعد اقتراح Podcoffeepac طريقة جيدة.

إنه لأمر فظيع أنه لا توجد طريقة حتى الآن لمالك المجموعة لاستخدام برامج تشغيل Docker log بعد كل هذا الوقت.

لقد تمكنت من الحصول على الإعداد بسرعة كبيرة باستخدام Docker-Compose (محاكاة مجموعة K8s الخاصة بي) لتوصيل جميع الأشياء / الأخطاء إلى خدمة السجل المجمعة الخاصة بي.

هل تحاول القيام بذلك في كوبينيتس؟ من هذا الموضوع ، يبدو أنني سأضطر إلى زيادة الشفرة لكل خدمة مصغرة! ليست جيدة.

مرحبًا ashleydavis ، تم إهمال dockerd في Kubernetes ، لذا لا فائدة من تقديم دعم لشيء لم يعد جزءًا من Kubernetes. على الرغم من أنه لا يزال بإمكانك تثبيته بالإضافة إلى Kubernetes. هنا الخلفية:
https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

لا تحتاج إلى زيادة الحاويات إلا إذا كنت ترغب في ذلك ، يقوم Kubernetes أصلاً بدفق سجلات stdout / stderr لكل حاوية تلقائيًا. تحتاج فقط إلى نشر حاوية واحدة على كل عقدة ( DaemonSet ) لتجميع وإرسال تدفقات السجل هذه إلى اختيارك (اختيارات) لخدمة التجميع. فمن السهل جدا.

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

يوجد الكثير من صور حاوية الواجهة الخلفية الجاهزة fluentd + وعينات التكوينات للنهايات الخلفية للتجميع الخلفي هنا:

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

إذا كنت تستخدم DataDog ، فلديهم وكيلهم الخاص للتثبيت بدلاً من ذلك أو بالإضافة إلى fluentd :

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

بشكل عام ، كان docker يميل إلى kitchen sink ، مع مكونات إضافية للتسجيل والتسجيل ، وأدوات سرب ووقت التشغيل ، وأدوات البناء ، والشبكات ، وتثبيت نظام الملفات ، وما إلى ذلك ، كل ذلك في عملية خفية واحدة. يفضل Kubernetes عمومًا الحاويات / العمليات غير المحكم التي تقوم بمهمة واحدة وتتواصل عبر واجهات برمجة التطبيقات. لذا فهو أسلوب مختلف بعض الشيء لتعتاد عليه.

شكرا على الاجابة المفصلة. أنا بالتأكيد سأبحث في هذا.

مع إيقاف dockerd ، هل هذا يعني أنه لا يمكنني نشر صور Docker على Kubernetes في المستقبل؟

ashleydavis ، يمكنك بالتأكيد الاستمرار في استخدام صور "Docker" (حتى بدون dockerd الحالي) ، ويمكنك الاستمرار في نشر dockerd على عقد Kubernetes لأغراضك الخاصة (كما هو الحال في docker-in-docker يبني) إذا كنت تريد. تم استخراج الأجزاء الأساسية من عامل الإرساء وتوحيدها كـ "حاويات OCI" ووقت التشغيل containerd .

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

يعتمد كل من Docker و Kubernetes الآن على هذه المعايير المشتركة.

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

شكرًا ، أنا أتعلم كثيرًا.

لقد أنشأت للتو خدمة مصغرة أطلق عليها اسم Loggy. كان القصد من ذلك أن يتم إرسال السجلات بواسطة برنامج تشغيل Docker log ثم إعادة توجيهها (عبر webhook) إلى Slack.

يمكنك رؤية الكود هنا: https://github.com/artlife-solutions/loggy/blob/master/src/index.ts

الأمر بسيط جدًا ، احصل على سجل وأعد توجيهه عبر HTTP POST إلى Slack.

ما هي أسرع طريقة لتكييف ذلك حتى أتمكن من جمع السجلات وتجميعها من البودات الخاصة بي؟

ashleydavis ، يمكنك إنشاء صورة حاوية مع تلك الخدمة الدقيقة فيها ، ثم إما

1. قم بنشره على أنه نشر مع خدمة يمكن أن ترسلها جميع الحاويات الموجودة على نظام المجموعة الخاص بك إلى (باستخدام اسم DNS للكتلة الخاص بالخدمة ).

2. انشرها كحاوية "جانبية" إضافية في عملية النشر الخاصة بك. تشترك الحاويات الموجودة في نفس الحاوية في الوصول الخاص إلى نفس localhost حتى تتمكن حاوية التطبيق من الإرسال إلى حاوية الخدمة الصغيرة الجانبية الخاصة بك على localhost:12201 . بدلاً من ذلك ، يمكن للحاويات الموجودة في نفس القرص مشاركة وحدة تخزين لملفات السجل المشتركة أو أنابيب الاتصال المسماة.

هذا خارج عن الموضوع هنا ولن يرغب الجميع في ذلك ، لذا ربما ابحث عن بعض قنوات Slack للحصول على المشورة.

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

يبدو جيدا. شكر. كنت أتمنى ألا أضطر إلى تغيير الخدمات الحالية. أود فقط أن ألتقط ستدوت / خطأ. أي طريقة لفعل ذلك؟

كان الوعد بسائقي Docker log هو البساطة. هل هناك طريقة بسيطة للقيام بذلك؟

بالتأكيد ashleydavis ، انشر fluentd ، وانطلق ، لقد انتهيت 😺. سيتم شحن stdout / stderr لكل تطبيق تقوم بنشره إلى المجمع المفضل لديك. 👍

بعد استثمار بعض الوقت في K8s وتسجيل الدخول ، قمت بإعداد مكدس ELK لطيف https://www.elastic.co/guide/en/beats/filebeat/current/running-on-kubernetes.html

الإعداد الخاص بي هو Filebeat الذي يقوم بتوجيه السجلات إلى Logstash الذي يقوم بتصفية واستخلاص العناصر الخاصة بهم ونقلها إلى Elasticsearch. باستخدام Kibana يمكنني عرض السجلات والبيانات المجمعة.

أود أيضًا دعم التسجيل في ملف syslog الأصلي لنظام التشغيل ، على سبيل المثال: على Ubuntu يمكنني كتابة سجلات إلى /var/log/syslog ، والتي تتم إدارتها بواسطة logrotate خارج الصندوق.

باستخدام السرب / التأليف ، يمكنني القيام بذلك:

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

يعد استخدام وحدة تخزين emtpyDir أمرًا جيدًا ، ومع ذلك ، فإن البودات التي تعمل لفترة طويلة معرضة لخطر ملء وحدة التخزين ما لم تقم بإضافة عملية إضافية تقوم بتدوير / اقتطاع ملفات السجل. لا أتفق مع هذا التعقيد الإضافي عندما يتعامل نظام التشغيل بالفعل مع تناوب / var / log / syslog.

أوافق على أن استخدام اللوحات الجانبية لبعض عمليات النشر فكرة رائعة (أفعل ذلك بالفعل لبعض عمليات النشر الخاصة بي) ، ومع ذلك ، فإن بيئة كل شخص مختلفة.

استخدام حجم emtpyDir جيد

كن حذرًا معهم - تتم إدارتهم بواسطة Kubernetes ولا تتحكم أنت في حياتهم. إذا تم طرد الكبسولة وإعادة جدولتها إلى عقدة أخرى - فستفقد السجلات. إذا قمت بتحديث pod وتغييرات uid الخاصة به ، فلن يستخدم وحدة التخزين القديمة ولكن بدلاً من ذلك يقوم بإنشاء وحدة تخزين جديدة وإزالة القديم.

jsirianni ليست كل الأنظمة تقوم بتشغيل syslog مما يعني أنه يجب أن يكون هناك بعض التعليقات التوضيحية لكل عقدة حول التسهيلات المتاحة لضمان تلبية احتياجات حجرة معينة. يحصل عامل البناء على هذا الافتراض لأنه يعمل محليًا فقط.

coffeepac فقط لأن العقد قد لا تحتوي على سجل نظام لا يعني أن المشغل يجب ألا يكون لديه الخيار. إذا كنت أنوي استخدام سجل النظام ، فسأتأكد من أن عُقد العمالي لديها سجل نظام.

أشعر أنه يجب إعادة فتح هذه المشكلة حيث لا تزال هناك حالات استخدام كافية لهذه الميزة.
/ إعادة الفتح

@ saiyam1814 : أعيد فتح هذه القضية.

أنا شخصياً ، ما زلت أعتقد أن Kubernetes يجب أن تدعم برامج تشغيل سجل Docker أو بعض الطرق المضمنة البسيطة الأخرى لتهيئة التسجيل.

لقد قيل لي عدة مرات أن إعداد التسجيل أمر سهل على Kubernetes ، ولكن بعد أن مررت الآن بعملية إعداد نظام تجميع التسجيل الخاص بي ، يمكنني القول إنه ليس بالأمر السهل حقًا.

لقد كتبت منشور مدونة حول أبسط طريقة لعرض نظام تجميع السجلات الخاص بك يدويًا لـ Kubernetes: http://www.the-data-wrangler.com/kubernetes-log-aggregation/

آمل أن يساعد منشور مدونتي الآخرين في اكتشاف إستراتيجيتهم الخاصة.

لا ينبغي أن يكون الأمر صعبًا للغاية ، لكن هذا هو ما نحن فيه الآن.

بالتأكيد نحتاج إلى طريقة لاستهلاك سجلات Docker مباشرة من stdout و stderr ، بدلاً من استخدام ملفات السجل. هناك بعض المشكلات الأمنية لاستخدام مسار Docker لملفات السجل ، لأنه يمكنك الوصول إلى سجلات أخرى في النظام المضيف.

هل يمكننا تنفيذ برنامج تشغيل سجل Docker؟ 👍

سيتيح تكوين برامج تشغيل سجل عامل الإرساء على مستوى الحاوية في البود (حيث يكون البود تحت سيطرة العميل) إعادة توجيه السجلات باستخدام برنامج التشغيل gelf مباشرة إلى خدمة / جراب Graylog (والذي يخضع أيضًا لتحكم العميل ) بدلاً من الاضطرار إلى جمعها من الملفات الموجودة على المضيف باستخدام خدمة فورية أخرى (والتي تمثل مزيدًا من النفقات الإدارية وفاصلًا أسوأ لمستوى التجريد من استخدام برنامج تشغيل السجل gelf ) أو عن طريق وصول وحدات العميل إلى دليل سجلات الحاوية على المضيف.

لذلك أود أن أرى هذه الميزة مطبقة في kubernetes.

قد يكون من المفيد التأكد من قيامنا بشيء مثل https://github.com/cri-o/cri-o/pull/1605 ، حيث نقوم بفصل تفسير دفق السجل من برامج تشغيل السجل بحيث لا يؤثر سلوك الحاوية على كيفية السائقين يعملون.

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

@ fejta-bot: إغلاق هذه القضية.

لا تزال الوظيفة بحاجة إلى التنفيذ
/ إعادة الفتح

@ M0rdecay : لا يمكنك إعادة فتح مشكلة / العلاقات العامة إلا إذا قمت بتأليفها أو كنت متعاونًا.

@ M0rdecay : لا يمكنك إعادة فتح مشكلة / العلاقات العامة إلا إذا قمت بتأليفها أو كنت متعاونًا.

حسنًا ، فهمت

حتى aws ecs لديه هذه الوظيفة حيث يمكن للمرء تعيين سائق تسجيل عامل ميناء.
في بيئتنا ، قمنا بإنشاء فهرس منفصل برمز مميز فريد لكل خدمة حاوية.

"logConfiguration": {
"logDriver": "splunk"،
"والخيارات": {
"تنسيق splunk": "خام"،
"splunk-insecureskipverify": "true"،
"Splunk-token": "xxxxx-xxxxxxx-xxxxx-xxxxxxx-xxxxxx"،
"splunk-url": " https://xxxxx.splunk-heavyforwarderxxx.com "،
"العلامة": "{{.Name}} / {{. ID}}" ،
"splunk-check-connection": "false"،
"الوضع": "غير محظور"
}
}

لكن لم أجد شيئًا كهذا في k8s. يجب أن يكون هناك في تعريف الكبسولة نفسها.

لا تزال الخيارات بحاجة إلى التنفيذ
/ إعادة الفتح

ejemba : أعيد فتح هذه القضية.

/ عقدة سيج
/ أجهزة إزالة سيج

/ إزالة سيج قابلية التوسع

logicalhan : لم يتم تعيين هذه التصنيفات على المشكلة: sig/

أي تقدم معها؟
كنت أبحث تحديدًا عن القدرة على إعداد حاويات البودات لتسجيل الدخول إلى السجل الخارجي ، مع تحديد برنامج تشغيل سجل الرصيف. يبدو أن إعداده افتراضيًا لجميع الحاويات في /etc/docker/daemon.json يمثل عبئًا.

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

@ fejta-bot: إغلاق هذه القضية.

/ إعادة الفتح

andreswebs : لا يمكنك إعادة فتح مشكلة / العلاقات العامة إلا إذا قمت بتأليفها أو كنت متعاونًا.

/ إعادة الفتح

ejemba : أعيد فتح هذه القضية.

ejemba : هذه المشكلة في انتظار الفرز حاليًا.

إذا حددت SIG أو مشروع فرعي أن هذه مشكلة ذات صلة ، فسيقبلونها من خلال تطبيق التسمية triage/accepted وتقديم المزيد من الإرشادات.

يمكن إضافة التصنيف triage/accepted بواسطة أعضاء المؤسسة بكتابة /triage accepted في تعليق.

أود حقًا أن يتم تنفيذ هذه الميزة. أقوم حاليًا بترحيل أعباء العمل من مجموعات Rancher 1.x إلى مجموعات Rancher 2.x التي تقوم بتشغيل k8s. لدينا عملية نشر تحدد معلمات تشغيل السجل ومعلمات اختيار السجل في تكوين تكوين عامل الإرساء.

لا أريد أن أضطر إلى تكوين مضيف واحد محدد لاستخدام برنامج gelf عالميًا ووضع علامة على البود بتسمية ومضيف بعلامة.

يبدو أنه يجب علينا تغيير CRI-O لتحديد أن كلا من تدفقات سجل الحاوية (stdout / stderr) يتم جمعها في شكل خام ، وعند قراءة الخام في وقت لاحق يمكننا تطبيق تفسيرات مختلفة لتدفق بايت السجل بعد ذلك.

راجع https://github.com/cri-o/cri-o/pull/1605.

يتم إغلاق المشكلات الفاسدة بعد 30 يومًا من عدم النشاط.
أعد فتح المشكلة مع /reopen .
ضع علامة على المشكلة على أنها حديثة مع /remove-lifecycle rotten .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/أغلق

@ fejta-bot: إغلاق هذه القضية.