Kubernetes: دعم أفضل للحاويات الجانبية في الوظائف المجمعة

/الفرعية

أيضًا استخدام مشكلة الحياة كما هو مقترح هنا http://stackoverflow.com/questions/36208211/sidecar-containers-in-kubernetes-jobs لا يعمل لأن الكبسولة ستعتبر فاشلة ولن تعتبر الوظيفة الإجمالية ناجحة.

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

يمكن أن يعمل المسبار ضد حاوية خرجت بالفعل ، أو قد تكون هناك
يكون سباقا حيث يتم هدمه؟

خيار آخر هو تعيين رموز خروج معينة لها معنى خاص.

كلاهما "Success for the whole pod" أو "failure for the whole pod" كلاهما
مفيد.

يجب أن يكون هذا على كائن Pod ، لذلك يعد تغييرًا كبيرًا في واجهة برمجة التطبيقات.

في الخميس ، 22 سبتمبر 2016 الساعة 1:41 مساءً ، كتب Ming Fang [email protected] :

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

بمجرد أن يعود المسبار بنجاح ، يمكن إنهاء الكبسولة.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -249021627 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AHuudjrpVtef6U35RWRlZr3mDKcCRo7oks5qsugRgaJpZM4IiqQH
.

erictune نقطة جيدة ؛ لا يمكننا فحص حاوية خرجت.

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

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

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

هل نظرت في هذه النقطة 3 من هنا حيث لم تقم بشكل أساسي بتعيين .spec.completions وبمجرد انتهاء الحاوية الأولى مع رمز الخروج 0 ، تتم المهام.

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

شخصيًا ، تبدو هذه لي أكثر مثل RS ، وليس وظيفة ، ولكن هذا رأيي الشخصي والأهم من ذلك أنني لا أعرف التفاصيل الكاملة لإعدادك.

بشكل عام ، هناك المناقشات التالية https://github.com/kubernetes/kubernetes/issues/17244 و https://github.com/kubernetes/kubernetes/issues/30243 التي تمس هذا الموضوع أيضًا.

soltysh الرابط الذي أرسلته أعلاه ، تشير النقطة 3 إلى إكمال الحاوية وليس إكمال الحاوية.

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

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

أنا أستخدم مكتبة client-go لترميز كل شيء أدناه:

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

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

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

لذا ، هل يجب أن أحل مشكلتي باستخدام نموذج الحاوية الجانبية أيضًا؟

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

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

anshumanbh أود أن أقترح عليك:

1. استخدام تخزين دائم ، تقوم بحفظ ملف النتيجة
2. استخدم hostPath mount ، وهو ما يماثل 1 تقريبًا ، وقد جربته بالفعل
3. تحميل ملف النتيجة إلى موقع بعيد معروف (s3 ، google drive ، dropbox) ، عمومًا أي نوع من محركات الأقراص المشتركة

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

anshumanbh واضح تمامًا ، وما زال هذا لا يندرج ضمن فئة حاوية السيارة الجانبية. كل ما تريد تحقيقه قابل للتنفيذ حاليًا مع الوظائف التي توفرها.

soltysh ، لذا مع الأخذ في الاعتبار أنني أريد الانتقال إلى الخيار 3 من القائمة التي اقترحتها أعلاه ، كيف سأبدأ في تنفيذه؟

المشكلة التي أواجهها هي أنه بمجرد انتهاء المهمة ، تخرج الحاوية وأفقد الملف. إذا لم يكن لدي الملف ، كيف يمكنني تحميله على محرك أقراص مشترك مثل S3 / Google Drive / Dropbox؟ لا يمكنني تعديل رمز الوظيفة لتحميله تلقائيًا في مكان ما قبل أن يتم إنهاء العمل به ، لذا لسوء الحظ سأضطر أولاً إلى تشغيل الوظيفة ثم حفظ الملف في مكان ما ..

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

soltysh نعم ، هذا منطقي. يمكنني فعل ذلك. ومع ذلك ، فإن السؤال التالي الذي أطرحه هو - لنفترض أنني بحاجة إلى تشغيل وظائف متعددة (فكر في الأمر على أنه تشغيل أدوات مختلفة) ولم يتم تضمين جزء التحميل في أي من هذه الأدوات. لذا ، الآن ، سأضطر إلى إنشاء هذا الغلاف وتوسيع كل واحدة من تلك الأدوات مع جزء التحميل. هل هناك طريقة يمكنني من خلالها كتابة الغلاف / الامتداد مرة واحدة واستخدامه لجميع الأدوات؟

ألن يتناسب نمط السيارة الجانبي في هذه الحالة؟

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

ping اللطيف - من شأن الوعي الجانبي أن يجعل إدارة بروكسيات الخدمات المصغرة مثل Envoy أكثر إمتاعًا. هل هناك أي تقدم للمشاركة؟

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

كان اقتراح سابق هو تعيين بعض الحاويات كحاوية "مكتملة". أود أن أقترح العكس - القدرة على تعيين بعض الحاويات على أنها "عربات جانبية". عند إنهاء آخر حاوية غير جانبية في Pod ، يجب أن يرسل Pod TERM إلى العربات الجانبية. سيكون هذا مشابهاً لمفهوم "مؤشر ترابط الخلفية" الموجود في العديد من مكتبات الترابط ، مثل Python Thread.daemon .

مثال للتكوين ، عندما تنتهي الحاوية main فإن kubelet سيقتل envoy :

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/my-batch-job/bin/main", "--config=/config/my-job-config.yaml"]
  - name: envoy
    image: lyft/envoy:latest
    sidecar: true
    command: ["/usr/local/bin/envoy", "--config-path=/my-batch-job/etc/envoy.json"]

كمرجع ، إليك جنون bash الذي أستخدمه لمحاكاة السلوك الجانبي المطلوب:

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        trap "touch /tmp/pod/main-terminated" EXIT
        /my-batch-job/bin/main --config=/config/my-job-config.yaml
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
  - name: envoy
    image: gcr.io/our-envoy-plus-bash-image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        /usr/local/bin/envoy --config-path=/my-batch-job/etc/envoy.json &
        CHILD_PID=$!
        (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
        wait $CHILD_PID
        if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; fi
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
        readOnly: true
volumes:
  - name: tmp-pod
    emptyDir: {}

أود أن أقترح العكس - القدرة على تعيين بعض الحاويات على أنها "عربات جانبية". عندما تنتهي آخر حاوية غير جانبية في Pod ، يجب أن يرسل Pod TERM إلى السيارات الجانبية.

@ jmillikin-stripe تعجبني هذه الفكرة ، على الرغم من أنني لست متأكدًا مما إذا كان هذا يتبع مبدأ معاملة بعض الحاويات بشكل مختلف في Pod أو إدخال التبعيات بينها. سأذعن إلى

على الرغم من أنك حددت الرقم 17244 ، فهل يناسب هذا النوع من الحلول حالة الاستخدام الخاصة بك؟ هذا ما ذكره erictune ببعض التعليقات من قبل:

خيار آخر هو تعيين رموز خروج معينة لها معنى خاص.

@ jmillikin-stripe تعجبني هذه الفكرة ، على الرغم من أنني لست متأكدًا مما إذا كان هذا يتبع مبدأ معاملة بعض الحاويات بشكل مختلف في Pod أو إدخال التبعيات بينها. سأذعن إلى

أعتقد أن Kubernetes قد تحتاج إلى التحلي بالمرونة بشأن مبدأ عدم التعامل مع الحاويات بشكل مختلف. نحن (Stripe) لا نريد تعديل كود طرف ثالث مثل Envoy للحصول على خطافات دورة حياة على غرار لامبري ، ومحاولة اعتماد انعكاس exec على غرار Envelope سيكون أكثر تعقيدًا من ترك Kubelet ينهي سيارات جانبية محددة.

على الرغم من أنك حددت الرقم 17244 ، فهل يناسب هذا النوع من الحلول حالة الاستخدام الخاصة بك؟ هذا ما ذكره erictune ببعض التعليقات من قبل:

خيار آخر هو تعيين رموز خروج معينة لها معنى خاص.

أنا أعارض بشدة تفسير Kubernetes أو Kubelet لرموز الخطأ بدقة أكثر دقة من "صفر أو غير صفري". كان استخدام Borglet للأرقام السحرية في كود الخروج ميزة خاطئة غير سارة ، وسيكون أسوأ بكثير في Kubernetes حيث يمكن أن تكون صورة حاوية معينة إما "رئيسية" أو "جانبية" في Pods مختلفة.

ربما تكون خطافات دورة الحياة الإضافية كافية لحل هذه المشكلة؟

ممكن ان يكون:

• PostStop: مع وسيلة لتشغيل أحداث دورة الحياة على الحاويات الأخرى في الكبسولة (أي توقف الزناد)
• PeerStopped: الإشارة إلى وفاة حاوية "نظير" في الحاوية - ربما باستخدام رمز الخروج كوسيطة

يمكن أن يحدد هذا أيضًا وسيلة لتحديد السياسات المخصصة لإعادة تشغيل الحاوية - أو حتى بدء الحاويات التي لم يتم تشغيلها افتراضيًا للسماح ببعض التسلسل المتسلسل للحاويات (عندما تنتهي الحاوية ، تبدأ الحاوية ب)

أيضا في عداد المفقودين هذا. نقوم بتشغيل وظيفة كل 30 دقيقة تحتاج إلى عميل VPN للاتصال ولكن يبدو أن هناك الكثير من حالات الاستخدام حيث يمكن أن يكون هذا مفيدًا للغاية (على سبيل المثال ، الأشياء التي تحتاج إلى وكيل kubectl). حاليًا ، أنا أستخدم jobSpec.concurrencyPolicy: Replace كحل بديل ولكن بالطبع هذا لا يعمل إلا إذا أ.) يمكنك العيش بدون تشغيل وظائف متوازية و ب) وقت تنفيذ المهمة أقصر من فترة الجدولة.

تحرير: في حالة الاستخدام الخاصة بي ، سيكون كافيًا تمامًا أن يكون لديك بعض الخصائص في مواصفات الوظيفة لتمييز الحاوية على أنها الحاوية المنتهية وجعل الوظيفة تراقب تلك الحالة لحالة الخروج وقتل ما تبقى منها.

أنا أيضا ، لدي حاجة لهذا. في حالتنا ، إنها مهمة تستفيد من حاوية cloudql-proxy كخدمة جانبية.

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

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

تحتاج أيضًا إلى هذه الميزة. لحالة الاستخدام لدينا:
جراب A لديه حاويات

• الحاوية A1 :
• الحاوية A2 : حاوية جانبية ، والتي تقوم فقط بذيل السجلات من ملف إلى آخر

ما أريده : عندما تكتمل الحاوية A1 بنجاح ، يكتمل A بالنجاح. هل يمكننا فقط تسمية الحاوية A1 على أنها حاوية رئيسية ، عند خروج الحاوية الرئيسية ، ومخارج الكبسولة؟ erictune (تم وصف هذه الفكرة أيضًا بواسطة mingfang )

مرحبًا يا رفاق ، أرى أن هذه القضية مفتوحة منذ شهر. ما هو آخر ما في هذا؟ لدينا حالة استخدام ، حيث نريد تشغيل وظيفة. تعمل الوظيفة على حاوية main مع سيارة جانبية قليلة containers . نريد إنهاء الوظيفة عند خروج الحاوية main . هل من أحدث التقنيات مشاركة file لإرسال signal بين الحاويات؟

لا أمانع في بدء بعض الأعمال في هذا الشأن ، وأود أن أعرف ما إذا كان بإمكان أي شخص مراجعة العلاقات العامة القادمة إذا فعلت ذلك (ربما بعد kubecon).

سم مكعبerictune @ و-روبنسونsoltysh

andrewsykim ما هو النهج الذي main يجب ألا تبدأ حتى يتم تهيئة اللوحات الجانبية

مثل الحاوية الرئيسية لا ينبغي أن تبدأ حتى يتم تهيئة العربات الجانبية

أعتقد أن هذه الحالة ليست مشكلة نظرًا لأن main يجب أن يكون قادرًا على التحقق عند تهيئة السيارة الجانبية (أو استخدام مسبار الجاهزية). هذا ليس هو الحال بالنسبة لهذه المشكلة لأن main كان سيخرج :)

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

ajbouh سأكون ممتنًا شخصيًا إذا شاركت ذلك كجوهر. كنت على وشك كتابة شيء مشابه

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

https://gist.github.com/ajbouh/79b3eb4833aa7b068de640c19060d126

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

@ amaxwell01 فيما يتعلق تمييز التحديثات أو مراقبتها: https://issuetracker.google.com/issues/70746902 (تحرير: وأنا آسف لبعض الصياغة التي استخدمتها هناك في خضم اللحظة ؛ للأسف لا يمكنني تعديلها)

شكرا abevoelker أنا

نحن أيضا متأثرون بهذه المشكلة.
لدينا العديد من أوامر إدارة django على خدماتنا المصغرة والتي يمكن تشغيلها على k8s cronjobs لكنها تفشل في النجاح بسبب cloudqlproxy sidecar التي لا تتوقف عند إكمال الوظيفة.
أي تحديث حول متى يمكن أن يكون لدينا حل؟
يتم استخدام نمط الحاوية الجانبية أكثر فأكثر ولن يتمكن الكثير منا من استخدام k8s cronjobs والوظائف حتى يتم حل هذا الأمر.

أردت فقط إضافة +1 لهذا. لدي نفس مشكلة وكيل GCE Cloud SQL مثل أي شخص آخر. إنه يقتلني ... فشل نشر الدفة والذي بدوره يفشل في تطبيق التضاريس الخاصة بي.

أود حقًا أن أرى نوعًا من القرار حول هذا ... يبدو أن jist من

لأي شخص آخر يحتاج إلى cloudsql-proxy ، هل يناسب حالة الاستخدام الخاصة بك لتشغيل cloudsql-proxy كمجموعة DaemonSet؟ في حالتي ، كان لدي نشر مستمر و CronJob يتطلب الوكيل ، لذلك من المنطقي فصله عن البودات الفردية وإرفاق مثيل واحد بدلاً من ذلك بكل عقدة.

نعم،

لقد قررنا إزالة ملفات وكيل cloudql الجانبية وقمنا ببناء مجموعة من ملفات
الوكلاء cloudql في مساحة الاسم المركزية الخاصة بهم ، فهي تعمل بشكل مثالي وتسمح
نقل قابلية التوسع وعمليات النشر الأسهل.
الآن يمكننا تشغيل الوظائف و cronjobs دون أي مشكلة.

يوم الأربعاء ، 7 فبراير ، 2018 الساعة 9:37 صباحًا ، Rob Jackson [email protected]
كتب:

لأي شخص آخر يحتاج إلى cloudql-proxy ، هل يناسب حالة الاستخدام الخاصة بك
تشغيل الوكيل cloudql باعتباره DaemonSet؟ في حالتي كان لدي كل من المثابرة
يتطلب النشر و CronJob الوكيل ، لذلك كان من المنطقي الفصل
من القرون الفردية وبدلاً من ذلك إرفاق مثيل واحد لكل عقدة.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment-363710890 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ACAWMwetx6gA_SrHL_RRbTMJVOhW1FKLks5tSW7JgaJpZM4IiqQH
.

من المثير للاهتمام أن استخدام مجموعة الشعاع يبدو خيارًا جيدًا. @ RJacksonm1 & devlounge - كيف يعمل اكتشاف بروكسي sql السحابي عند استخدام مجموعات daemonsets؟

وجدت هذا الذي يبدو أنه سيفي بالغرض ...
https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

يتضمن أساسًا استخدام شيء مثل هذا للحصول على عنوان IP للمضيف:

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

@ RJacksonm1 - هل كان هناك أي شيء خاص فعلته للحصول على عمل hostPort ؟ أحصل باستمرار على connection refused عند استخدامه بالتزامن مع نهج fieldPath: spec.nodeName 🤔

تحرير: لقد تأكدت من أن spec.nodeName يمر بشكل صحيح وأنا على GKE v1.9.2-gke.1

cvallance لدي خدمة تم إعدادها لفضح DaemonSet ، والتي يمكن لتطبيقي الوصول إليها بعد ذلك عبر DNS. هذا لا يضمن أن التطبيق سيتحدث إلى المثيل cloudsql-proxy يعمل على نفس المضيف نفسه ، لكنه يضمن أن cloudsql-proxy سيتوسع مع الكتلة ككل (في الأصل كان لدي الوكيل باعتباره Deployment و HorizontalPodAutoscaler ، لكنه وجد أنه يتوسع / ينخفض ​​كثيرًا - مما تسبب في أخطاء MySQL has gone away في التطبيق). أعتقد أن هذا ليس بالروح الحقيقية لمجموعة DaemonSet ... 🤔

@ RJacksonm1 - بدأ العمل مع hostPort و spec.nodeName ... الآن سيتصلون مباشرة بـ DaemonSet على عقدتهم 😄

أمر وكيل CloudSql لا يعمل:
-instances={{ .Values.sqlConnectionName }}=tcp:{{ .Values.internalPort }}
عمل:
-instances={{ .Values.sqlConnectionName }}=tcp:0.0.0.0:{{ .Values.internalPort }}

🤦‍♂️

هل هناك أي شيء يمكننا القيام به للحصول على بعض الجاذبية في هذه القضية؟
لقد كان مفتوحًا منذ ما يقرب من عامين وما زال لدينا حلول بديلة فقط

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

أي شيء يمكنني القيام به للمساعدة في إنجاز هذا؟

كمرجع ، قمت بعمل نسخة جانبية للوكيل السحابي من حل @ jmillikin-stripe حيث يقوم ملف في وحدة تخزين مشتركة بنقل الحالة إلى السيارة الجانبية.

إنه يعمل بشكل جيد ، ولكنه إلى حد بعيد أكثر الاختراقات شرا في تكوين K8s: :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

هل يمكن لأي شخص داخل المشروع التعليق على التقدم المحرز في هذه القضية؟

نفس المشكلة هنا

cc @ kubernetes / sig-apps-features-features @ kubernetes / sig-node-feature-applications

هل من المنطقي السماح للمستخدمين بتحديد (بالاسم) الحاويات في الوظيفة التي يرغبون في رؤيتها مكتملة بنجاح من أجل وضع علامة على مجموعة المهام على أنها "تم" (مع إيقاف الحاويات الأخرى) ، مثل:

apiVersion: batch/v2beta1
kind: Job
metadata:
  name: my-job
  namespace: app
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-job-image
          ...
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.11
          ...
  backoffLimit: 2
  jobCompletedWith:
    - my-container

أي سيتم تشغيل الكبسولة ، وانتظر حتى يخرج my-container بنجاح ، ثم قم بإنهاء cloudsql-proxy .

تحرير: التمرير لأعلى هذا الموضوع ، الآن أرى أن هذا قد تم اقتراحه مسبقًا. هل يستطيع erictune أو أي شخص آخر إعادة توضيح سبب عدم

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

نعم ، سيكون ذلك مثاليًا.

أحب هذه الفكرةjpalomaki

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

يمكن أن تجعل وحدة التحكم في الوظيفة تحذف Pod عندما تقرر وحدة التحكم أن ذلك قد تم ، ولكن هذا سيكون مختلفًا أيضًا عن السلوك الحالي ، حيث يظل سجل Terminated Pod موجودًا في خادم API (دون تناول موارد Node).

لهذه الأسباب ، يبدو لي أنه من الأنظف معالجة هذا على مستوى Pod API ، إن وجد. العقدة هي الشيء الوحيد الذي يجب الوصول إليه وقتل الحاويات الفردية لأن حاويات "الإكمال" التي تهتم بها قد تم إنهاؤها بالفعل. قد يتخذ هذا شكل واجهة برمجة تطبيقات على مستوى Pod والتي تتيح لك تحديد فكرة الحاويات التي يجب أن تنتظرها ، أو واجهة برمجة تطبيقات على مستوى Pod للسماح للوكلاء الخارجيين (مثل وحدة التحكم في المهمة) بإجبار Pod على الإنهاء دون حذف فعلي الجراب.

أنا أبحث أيضًا عن حل لتحميل الملفات التي تنتجها حاوية إذا خرجت حاوية المعالج بنجاح.

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

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

ألن يؤدي الترويج للسيارة الجانبية إلى مفهوم k8 من الدرجة الأولى إلى حل هذه المشكلة؟ سيتمكن Kubelet من إنهاء الكبسولة إذا تم وضع علامة على جميع الحاويات الموجودة فيه على أنها حاويات جانبية.

FWIW ، لقد عملت على حل هذا الأمر فقط من خلال نشر خادم Cloud SQL كنشر منتظم ( replicas: 1 ) وجعلت Job و CronJob أستخدمه عبر type: ClusterIP الخدمات. الوظائف كاملة الآن.

أود الحصول على موقف رسمي من هذا.

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

لست متأكدًا من الشخص الذي يتعين عليه الاتصال أو كيفية لفت الانتباه إلى هذا ...

سيكون من الرائع حقًا معالجة هذا الأمر. بالإضافة إلى أن الوظيفة لا تختفي أبدًا ، يبدو أن حالة Pod بشكل عام غير صحيحة:

Init Containers:
  initializer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:52:57 -0500
      Finished:     Wed, 21 Mar 2018 17:52:57 -0500
    Ready:          True
Containers:
  sideCar:
    State:          Running
      Started:      Wed, 21 Mar 2018 17:53:40 -0500
    Ready:          True
  mainContainer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:53:41 -0500
      Finished:     Wed, 21 Mar 2018 17:55:12 -0500
    Ready:          False
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 

الأمر المثير للاهتمام هو ملاحظة الحالة وجاهز لـ initContainer (تم إنهاؤه ، مكتمل ، جاهز = صحيح) وحاوية التطبيق الرئيسية (منتهية ، مكتملة ، جاهزة = خطأ). يبدو أن هذا يقود حالة False أكثر من Pod Ready - من وجهة نظري ، بشكل غير صحيح. هذا يتسبب في وضع علامة على Pod هذا على أنه يواجه مشكلة في لوحات المعلومات الخاصة بنا.

لدي عميل آخر يواجه هذه المشكلة مع خادم Cloud SQL على وجه التحديد. لا يرغبون في تشغيلها كخدمة مستمرة للسماح لوظائف cron بالوصول إلى Cloud SQL.

yuriatgoogle الحل الأسهل لا يزال باش وفارغ دير "السحر" مثل: https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -365924958

إنه اختراق ، لكن سيتعين عليه القيام به. لا يقصد الإساءة إلىphidah.

يبدو بالتأكيد أن الكثير من الناس يريدون هذا لأسباب متنوعة. سيكون من الجيد الحصول على بعض الدعم الرسمي. لقد واجهت نفس المشكلة مع السيارة الجانبية والوظائف الخاصة بنا ، لذلك كان لديّ الجانب الجانبي يستخدم kube api لمشاهدة حالة الحاوية الأخرى في الحاوية ، إذا تم إنهاؤها بـ completed فإن السيارة الجانبية ستخرج 0 ، إذا لقد أخطأ في أن السيارة الجانبية ستخرج 1. ربما لم يكن الحل الأكثر أناقة ولكنه قام بالخدعة دون الحاجة إلى تغيير الكثير من مطورينا. الكود موجود هنا إذا كان أي شخص مهتمًا: https://github.com/uswitch/vault-creds/blob/master/cmd/main.go#L132.

هذا يذكرني بأغنية Gorillaz M1 A1 ...

مرحبا؟ مرحبا؟ هل من أحد هناك؟

نعم ، دعنا نحصل من فضلك على بعض الجر +1

لذا فإن الحلول المقترحة التي تتطلب تغييرات أولية هي:

1. sidecar: true بواسطة @ jmillikin-stripe
2. خطافات دورة حياة إضافية بواسطة msperl
3. jobCompletedWith بواسطة jpalomaki

حل مؤقت للسيارة الجانبية ، مبتكر (لكنه يعمل):

1. مقابل cloudsql-proxy sidecar بواسطةphidah

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

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

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

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

كان اقتراح سابق هو تعيين بعض الحاويات كحاوية "مكتملة". أود أن أقترح العكس - القدرة على تعيين بعض الحاويات على أنها "عربات جانبية". عندما تنتهي آخر حاوية غير جانبية في Pod ، يجب أن يرسل Pod TERM إلى السيارات الجانبية.

هذا هو الحل المثالي بالنسبة لي أيضًا. قد أقترح SIGHUP بدلاً من SIGTERM - يبدو أن هذه هي حالة الاستخدام الدقيقة التي تتعلق بها دلالات SIGHUP! - لكن سأكون سعيدًا بأي منهما.

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

سأكون على استعداد لإجراء تصحيح لهذا ولكني أرغب في الحصول على بعض الإرشادات من طلبات @ kubernetes / sig-apps-feature-features قبل الحفر في أي كود. هل نحن بخير بإضافة حقل sidecar إلى مواصفات البود لإنجاح هذا العمل؟ أتردد في إجراء أي تغييرات على مواصفات pod دون التأكد من أننا نريد ذلك. ربما تستخدم التعليقات التوضيحية في الوقت الحالي؟

andrewsykim لقد كنت

تفكيري هو أن:

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

أفكار؟

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

لقد قمت بإنشاء علاقات عامة لاقتراح تحسين لحل هذه المشكلة ، لذا آمل أن يؤدي هذا إلى بعض المناقشة https://github.com/kubernetes/community/pull/2148.

شكرا لتجميع ذلك معا @ جوزيف ايرفينغ! يبدو أن هناك المزيد من التفاصيل التي يجب معالجتها لهذا الأمر ، لذا سأمتنع عن القيام بأي عمل حتى ذلك الحين :)

مشكلة مستمرة على المدى الطويل :(

cc @ kow3nsjanetkuo

بدون أي معنى لزيادة تعقيد الأمر ، سيكون من المفيد أيضًا أن تكون قادرًا على تشغيل حاوية نمط "sidecar" جنبًا إلى جنب مع initContainers .

حالة الاستخدام الخاصة بي تشبه الأشخاص هنا ، فأنا بحاجة إلى تشغيل وكيل سحابة sql في نفس الوقت مثل initContainer الذي يقوم بتشغيل عمليات ترحيل قاعدة البيانات. نظرًا لأنه يتم تشغيل initContainers واحدًا تلو الآخر ، لا يمكنني رؤية طريقة للقيام بذلك ، باستثناء تشغيل الوكيل كخدمة نشر + ، لكنني أتوقع وجود حالات استخدام أخرى (إدارة السجل وما إلى ذلك) حيث لن يكون هذا العمل مناسبًا حول.

mcfedr هناك اقتراح تحسين نشط بشكل معقول والذي قد يقدر هذه الملاحظة فيما يتعلق بسلوك حاوية البادئة. ليس من الواضح بالنسبة لي ما إذا كان هذا في نطاق هذا الاقتراح ، أو تحسين ذي صلة ، لكنني أعتقد أنه مرتبط بما يكفي بحيث يكون من المنطقي رفعه للنظر فيه.

على الرغم من مشاكل التنفيذ / التوافق المحتملة ، من المفترض أن يكون نموذجك المثالي هو تشغيل حاويات الفتحات الجانبية بشكل متزامن مع حاويات init غير جانبية ، والتي تستمر في العمل بالتتابع كما هو الحال الآن ، ولكي تنتهي العربات الجانبية قبل بدء تشغيل حاويات التسلسل الرئيسي؟

لما تستحقه ، أود أيضًا أن أعبر عن الحاجة إلى تجاهل السيارات الجانبية التي لا تزال تعمل مثل CloudSQL Proxy et.al.

تمكنت من قتل حاوية cloudql بعد 30 ثانية لأنني أعرف أن البرنامج النصي الخاص بي لن يستغرق هذا الوقت الطويل. هذا هو أسلوبي:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: schedule
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  startingDeadlineSeconds: 40
  jobTemplate:
    spec:
      completions: 1
      template:
        spec:
          containers:
          - image: someimage
            name: imagename
            args:
            - php
            - /var/www/html/artisan
            - schedule:run
          - command: ["sh", "-c"]
            args:
            - /cloud_sql_proxy -instances=cloudsql_instance=tcp:3306 -credential_file=some_secret_file.json & pid=$! && (sleep 30 && kill -9 $pid 2>/dev/null)
            image: gcr.io/cloudsql-docker/gce-proxy:1.11
            imagePullPolicy: IfNotPresent
            name: cloudsql
            resources: {}
            volumeMounts:
            - mountPath: /secrets/cloudsql
              name: secretname
              readOnly: true
          restartPolicy: OnFailure
          volumes:
          - name: secretname
            secret:
              defaultMode: 420
              secretName: secretname

وهي تعمل لأجلي.
هل ترى يا رفاق أي عيب في هذا النهج؟

نظرًا لأنني أعتقد أنها مرتبطة وقابلة للتكيف بسهولة مع CronJobs أيضًا ، فهذا هو الحل: https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/128#issuecomment -413444029

يعتمد على أحد الحلول المنشورة هنا ولكنه يستخدم preStop لأنه من المفترض أن يكون لعمليات النشر. محاصرة السيارة الجانبية ستعمل بشكل رائع.

بعد هذه القضية. أيضًا استخدام حاوية cloud_sql_proxy كسيارة جانبية في cronjob
لقد استخدمت تنفيذ المهلة بواسطة stiko

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

https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -327396198

لقد حصلنا على KEP هذا تمت الموافقة عليه مؤقتًا https://github.com/kubernetes/community/pull/2148 ، ولا يزال لدينا بعض الأشياء التي نحتاج إلى الاتفاق عليها ولكن نأمل أن نصل إلى مكان يمكن أن يبدأ فيه العمل فيه قريبًا نسبيًا . ملاحظة سينتقل KEPs إلى https://github.com/kubernetes/enhancements في اليوم الثلاثين ، لذلك إذا كنت تريد المتابعة فسيكون هناك.

حتى وصول الدعم الجانبي ، يمكنك استخدام حل على مستوى عامل الإرساء والذي يمكن إزالته بسهولة لاحقًا: https://gist.github.com/janosroden/78725e3f846763aa3a660a6b2116c7da

يستخدم حاوية مميزة مع مقبس عامل إرساء مُثبت وتسميات kubernetes قياسية لإدارة الحاويات في المهمة.

كنا نواجه نفس المشكلة مع Istio وسيارته الجانبية ، وما قررنا فعله هو حذف الكبسولة عبر خطاف curl + preStop مثل هذا

أعط وظيفتك حدًا أدنى من قاعدة RBAC مثل هذه

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myservice-job
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-job-rolebinding
subjects:
  - kind: ServiceAccount
    name: myservice-job
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myservice-role

و POD_NAME و POD_NAMESPACE إلى ENV الخاص بك على هذا النحو

   env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

وأخيرًا ، أضف خطافًا أوليًا مثل

 lifecycle:
      preStop:
        exec:
          command: 
            - "/bin/bash" 
            - "-c"
            - "curl -X DELETE -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$POD_NAMESPACE/pods/$POD_NAME?gracePeriodSeconds=1"

نوع من الفوضى ولكنه أكثر أمانًا وأقل صعوبة من محاولة قتل حاوية عامل الإرساء الصحيحة.

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

https://github.com/nrmitchi/k8s-controller-sidecars

بفضل jpalomaki على https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -371469801 لاقتراح تشغيل cloud_sql_proxy كنشر مع خدمة ClusterIP و @ cvallance على https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -364255363 للحصول على معلومات حول إعداد tcp:0.0.0.0 في المعلمة cloud_sql_proxy instances للسماح بعدم -الاتصالات المحلية للعملية. جعل هؤلاء معًا من السهل السماح لوظائف cron باستخدام الوكيل.

قضية طويلة الأجل (ملاحظة للذات)

المشكلة نفسها. البحث عن طريقة أو مستند رسمي حول كيفية استخدام وظيفة كرون GKE مع Cloud SQL

ملاحظة جانبية:
قامت Google بتحديث Cloud SQL -> الاتصال من وثائق Connecting using the Cloud SQL Proxy Docker image يمكنك Connecting using a private IP address
لذلك إذا كنت هنا لنفس السبب ، فأنا هنا (بسبب cloud_sql_proxy) ، يمكنك الآن استخدام الميزة الجديدة لـ Private IP

ملاحظة جانبية:
قامت Google بتحديث Cloud SQL -> الاتصال من وثائق Connecting using the Cloud SQL Proxy Docker image يمكنك Connecting using a private IP address
لذلك إذا كنت هنا لنفس السبب ، فأنا هنا (بسبب cloud_sql_proxy) ، يمكنك الآن استخدام الميزة الجديدة لـ Private IP

يبدو أن ميزة IP الخاصة بحاجة إلى حذف المجموعة بأكملها وإعادة إنشاء واحدة ........؟

cropse هذا مطلوب فقط إذا كان نظام المجموعة الخاص بك ليس أصليًا لـ VPC.

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

فقط لإضافة سنتي: تنكسر اختبارات الدفة أيضًا إذا حدث حقن الجنزير الجانبي لأن الكبسولة لا تكتمل أبدًا.

dansiviter ، يمكنك التحقق من الحل الخاص بي ، لقد اختبرت بالفعل في مشروعي مع دفة.

نتطلع لرؤية هذا التنفيذ! :)

لدينا نفس المشكلة مع الوظائف العادية عندما يتم حقن وكيل Istio بها ، وفوق ذلك نريد هذا أيضًا لأننا نريد تشغيل وظائف CI مع Prow.
على سبيل المثال ، حاوية تطبيق ريلز + حاوية قاعدة بيانات جانبية لأغراض الاختبار.

@ المحاصيل شكرا. لم أجربه لأننا سنحتاج إلى تكوينه لجميع الاختبارات. نحن فقط نسمح لـ Pod (لا تسمح اختبارات Helm لـ Job للأسف) بالفشل والاعتماد على فحص السجل يدويًا حتى يتم إصلاح هذه المشكلة على المدى الطويل. ومع ذلك ، فقد أصبحت أيضًا مشكلة لوظائف أخرى أيضًا ، لذا فقد نعيد النظر في هذا الموقف.

لمعلوماتك ، فإن مشكلة التتبع لهذه الميزة موجودة هنا https://github.com/kubernetes/enhancements/issues/753 إذا أراد الناس المتابعة ، فلدينا KEP ، وقمنا ببعض النماذج الأولية (هناك فرع / فيديو POC ) ، لا تزال بحاجة إلى تسوية بعض تفاصيل التنفيذ قبل أن تكون في حالة قابلة للتنفيذ.

ملاحظة جانبية:
قامت Google بتحديث Cloud SQL -> الاتصال من وثائق Connecting using the Cloud SQL Proxy Docker image يمكنك Connecting using a private IP address
لذلك إذا كنت هنا لنفس السبب ، فأنا هنا (بسبب cloud_sql_proxy) ، يمكنك الآن استخدام الميزة الجديدة لـ Private IP

كنت هنا للسبب نفسه ، ومع ذلك ، فقد تم توفير Cloud SQL قبل أن تصبح هذه الميزة جاهزة. لقد جمعت الاقتراحات السابقة وخرجت بهذا (ربما ليس مثاليًا ، لكنه يعمل) لمخطط دفة مهاجر dbmate الخاص بي.

      containers:
      - name: migrator
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/bin/bash", "-c"]
        args:
          - |
            /cloud_sql_proxy -instances={{ .Values.gcp.project }}:{{ .Values.gcp.region }}:{{ .Values.gcp.cloudsql_database }}=tcp:5432 -credential_file=/secrets/cloudsql/credentials.json &
            ensure_proxy_is_up.sh dbmate up
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: DATABASE_URL
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials

ensure_proxy_is_up.sh

#!/bin/bash

until pg_isready -d $(echo $DATABASE_URL); do
    sleep 1
done

# run the command that was passed in
exec "$@"

هل سيكون هذا هو الوقت المناسب لفكرة الحاويات الجانبية في Kubernetes والسماح بتنظيف الكبسولات بناءً على ما إذا كانت الحاويات غير الجانبية قد انتهت؟

Willux أنا على جهاز الصراف الآلي الخاص

krancour شكرا على التحديث. لابد أنني فاتني تلك التفاصيل. لم يكن هناك الكثير من الأنشطة التي تحدث هنا مؤخرًا ، لذلك أردت فقط التأكد من وجود شيء مستمر :)

كمرجع ، قمت بعمل نسخة جانبية للوكيل السحابي من حل @ jmillikin-stripe حيث يقوم ملف في وحدة تخزين مشتركة بنقل الحالة إلى السيارة الجانبية.

إنه يعمل بشكل جيد ، ولكنه إلى حد بعيد أكثر الاختراقات شرا في تكوين K8s: :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

هل يمكن لأي شخص داخل المشروع التعليق على التقدم المحرز في هذه القضية؟

هل من العدل أن نفترض أن هذا هو الخيار الأفضل لأولئك منا الذين يعملون على قناة إصدار GKE المستقرة ، والتي ربما لن تلحق بـ Kubernetes 1.18 لبضعة أشهر على الأقل؟

Datamance في هذه المرحلة ، يبدو أن KEP لمعالجة هذه المشكلة معلقة إلى أجل غير مسمى .

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

nrmitchi شكرا لإعادة نشر ذلك. أنا من الأشخاص الذين أغفلتهم في بحر التعليقات وهذا يبدو وكأنه حل رائع على المدى القريب.

نكتشف طريقة مختلفة ، إذا أضفت ما يلي إلى حاويات Pod الخاصة بك:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

بعد ذلك ستتمكن من تحضير Pid في حاويات أخرى ، وسنعمل على اتباعها في نهاية الحاوية الرئيسية الخاصة بنا:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ krancour سعيد لأنه ساعد. إذا نظرت إلى الشبكة في هذا المستودع ، فهناك زوجان من الشوكات يكاد يكونان في مكان أفضل من مكاني الأصلي ، وقد يكون من الأفضل البناء / الاستخدام.

كان لدى IIRC شوكة lemonade-hq بعض الإضافات المفيدة.

nrmitchi ، لقد كنت ألقي نظرة

هل يمكنك التعليق بإيجاز على أي من الشروط المسبقة التي قد تكون موجودة والتي لم يتم ذكرها في README؟

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

krancour سأقدم

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

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

لا يحتاجون إلى الاستماع إلى أي منافذ للإشارة ، نظرًا لأن وحدة التحكم تستخدم exec للإشارة إلى العملية الرئيسية للجهاز الجانبي مباشرة. IIRC في الوقت الذي تم فيه نسخ هذه الوظيفة من كود kubernetes لأنها لم تكن موجودة في العميل. أعتقد أن هذا موجود في العميل الرسمي الآن وربما يجب تحديثه.

نكتشف طريقة مختلفة ، إذا أضفت ما يلي إلى حاويات Pod الخاصة بك:

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

بعد ذلك ستتمكن من تحضير Pid في حاويات أخرى ، وسنعمل على اتباعها في نهاية الحاوية الرئيسية الخاصة بنا:
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ ruiyang2015 شكرا لهذا الاختراق.
إذا قام أي شخص بتنفيذها ، فتأكد من فهم الآثار المترتبة على مشاركة العملية بين الحاويات

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

يستخدم exec للإشارة إلى العملية الرئيسية للجناح الجانبي مباشرة

هذا جزء من سبب سؤالي ... أعتقد ، على وجه التحديد ، أنني أتساءل عما إذا كان هذا لا يعمل للحاويات القائمة على الصور التي تم إنشاؤها FROM scratch .

krancour Fair Point ، لم أذهب واختبرها مطلقًا باستخدام حاويات كانت من scratch . بالنظر إلى الكود (أو إصداري الأصلي ؛ كان من الممكن أن يتغير هذا في forked) ، يبدو أنه سيعتمد على bash ، لكن يجب أن يكون قابلاً للتعديل.

ستعتمد على bash ، لكن يجب أن تكون قابلة للتعديل

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

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

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

يمكنني تحمل رفاهية _deleting_ الكبسولة التي خرجت حاويتها "الأساسية" ، طالما أنني أسجل حالة الخروج أولاً. لذلك سأنتهي بكتابة وحدة تحكم ستراقب بعض الحاويات المعينة (عبر التعليق التوضيحي) لإكمالها ، وتسجيل نجاحها أو فشلها في مخزن بيانات يتتبع بالفعل حالة "الوظيفة" ، ثم احذف الحاوية تمامًا.

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

ثقيلة اليد ، ولكن قد تعمل مع البعض.

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

نظرًا لأن هذه المشكلة تبلغ من العمر 4 سنوات ، فإن KEP لم يذهب إلى أي مكان حتى الآن ، وأحدث ما توصلت إليه التقنية هو نص برمجي مضمن متسلل يحل محل كل نقطة إدخال ، فقد قررت تقنين الاختراق "القياسي" (شواهد القبور في وحدة تخزين مشتركة ) في ملف ثنائي Go يمكن تحميصه بسهولة في صور حاوية باستخدام بنية متعددة المراحل.

https://github.com/karlkfi/kubexit

هناك عدة طرق لاستخدامه:

1. اخبزها في صورك
2. قم بتحميله من الجانب باستخدام حاوية init وحجم سريع الزوال.
3. قم بتوفيره على كل عقدة وتحميله الجانبي في حاويات باستخدام حامل ربط مضيف

تعديل: الإصدار 0.2.0 يدعم الآن "تبعيات الولادة" (البدء المتأخر) و "التبعيات على الموت" (الإنهاء الذاتي).

تعليق من Drive: يبدو هذا تمامًا مثل https://github.com/kubernetes/enhancements/issues/753

vanzin كما لوحظ من قبل ، أن KEP معلقة إلى أجل غير مسمى.

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