سم مكعبironcladlou @ bgrant0607

ما هي حالة الاستخدام لإعادة تشغيل البودات دون أي تغييرات في المواصفات؟

لاحظ أنه لن يكون هناك أي طريقة للتراجع عن التغيير إذا بدأت القرون بالفشل عند إعادة تشغيلها.

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

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

أيضًا ، تؤدي إعادة التشغيل المتداول بدون تغيير في المواصفات إلى إعادة تخصيص القرون عبر
العنقودية.

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

في يوم الأربعاء 2 سبتمبر 2015 الساعة 12:01 صباحًا ، كتب Sam Ghods [email protected] :

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

إذا فشل الكبسولة الأولى أثناء إعادة تشغيلها ، أتوقع أن تتوقف
متابعة أو متابعة إعادة المحاولة لبدء البود.

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

كلايتون كولمان | مهندس رئيسي ، OpenShift

smarterclayton هل هذا مثل خياري 2 المذكور أعلاه؟ رغم ذلك لماذا تتغير التسميات؟

إعادة. مثبت: هذا هو الغرض من تحقيقات الحياة.

إعادة. إعادة التوازن: راجع # 12140

إذا دعمنا هذا ، فسأجمعه بالرقم 9043 # - نفس الآلية مطلوبة.

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

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

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

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

@ bgrant0607 هل قررنا أننا لا نريد القيام بذلك؟

gmarek لا شيء ، في الوقت الحالي. أشياء كثيرة جدا جارية بالفعل.

هل يمكننا الحصول على علامة بارزة post v1.1 (أو شيء من هذا القبيل) للأشياء التي نعتبرها مهمة ، لكننا نفتقر إلى الأشخاص لإصلاحها على الفور؟

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

أنا معجب بهذه الميزة. حالة الاستخدام: قم بترقية جميع الكبسولات بسهولة لاستخدام صورة عامل إرساء تم دفعها حديثًا (مع imagePullPolicy: Always ). أستخدم حاليًا بعض الحلول المبتذلة: التحديث المتداول مع أو بدون علامة :latest على اسم الصورة.

حالة استخدام أخرى: تحديث الأسرار.

أود حقًا أن أرى هذه الميزة. نقوم بتشغيل تطبيقات العقدة على kubernetes ولدينا حاليًا حالات استخدام معينة حيث نقوم بإعادة تشغيل البودات لمسح التخزين المؤقت الزائف للتطبيق.

هذا ما أفعله الآن:

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

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

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

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

حل بسيط (أستخدم عمليات النشر وأريد تغيير التكوينات دون إجراء تغييرات حقيقية في الصورة / البود):

• إنشاء configMap
• إنشاء النشر باستخدام متغير ENV (ستستخدمه كمؤشر للنشر الخاص بك) في أي حاوية
• تحديث configMap
• نشر التحديث (تغيير متغير ENV هذا)

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

شكرا لكم punin

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

من (kinda-related # 9043): سطر واحد من نهج RESTART_ هو متغير البيئة ، ويتم تعيينه على طابع زمني ISO:

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(لاحظ ، لسبب ما ، أن متغيرات البيئة التي تبدأ بـ _ تبدو وكأنها تختفي ، و env الرقمية value s تسبب أخطاء ، يجب أن تكون سلاسل)

pauninrcoup أن نفعل شيئا مشابهة جدا في الوقت الحاضر، لدينا الحياة الفطرية فار دعا حرفيا "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT".

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

أي تقدم في هذا؟

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

نود أيضًا أن نرى هذا لعمليات النشر ربما مثل kubectl restart deployment some-api

يُسمح لـ Kubernetes بإعادة تشغيل Pods لجميع أنواع الأسباب ، ولكن لا يُسمح لمسؤول المجموعة بذلك.
أفهم الموقف الأخلاقي القائل بأن `` إيقاف تشغيله وتشغيله مرة أخرى '' قد لا يكون طريقة مرغوبة للعمل ... لكنني أعتقد أيضًا أنه ينبغي السماح لهؤلاء الأشخاص الذين يرغبون في ذلك ، بإعادة بدء عملية النشر دون اللجوء إلى النطاق من الحيل الأقل شهية مثل:

• حذف القرون
• تسميات وهمية
• متغيرات البيئة الوهمية
• تعيين خرائط التكوين الوهمية لمتغير البيئة
• إعادة تشغيل العقد العاملة
• قطع الطاقة إلى مركز البيانات 😄

'لا ، لا ، أنا لا أقوم بإعادة تشغيل أي شيء ، فقط أقوم بتصحيح خطأ مطبعي في هذا الملصق هنا' 😛

ستكون هذه الميزة مفيدة في الاقتران مع kubectl apply : apply لتحديث التكوينات ، بما في ذلك وحدات التحكم في النسخ المتماثل ، ولكن لن يتم إعادة تشغيل البودات.

لذلك نحن بحاجة إلى طريقة لإعادة تشغيل هذه القرون بطريقة Blue-Green.

DmitryRomanenko ماذا عن التبديل من ReplicationControllers إلى Deployments؟ سيمكنك ذلك من تشغيل تحديثات ReplicaSets (اللاحقة لـ ReplicationController).

Kargakis @ غير ممكن: تحديث
باستخدام kubectl apply نقوم أيضًا بتحديث ConfigMaps والخدمات وما إلى ذلك.

DmitryRomanenko إذا كانت المشكلة هي "أريد إعادة تشغيل Pods عند تحديث ConfigMap / Secret" ، فإن الحل المحتمل هو الحصول على إصدارات لـ ConfigMap والأسرار ، وجعل هذا الإصدار جزءًا من مواصفات النشر الخاصة بك. لذلك مع kubectl apply ing تتغير مواصفات النشر ويتم إعادة إنشاء الكبسولات.
في حالات أخرى ، لا أرى سبب وجوب إعادة تشغيل Pods (أعني تحديث الخدمة / الدخول / إلخ).

tyranron ، شكرا! ما هي أفضل طريقة لنسخة ConfigMap s؟ هل يجب إنشاء خريطة تكوين جديدة باسم مختلف للنشر الجديد؟

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

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

أعتقد أيضًا أنه من الأفضل التحكم في عنصر configmap|secret لبدء إعادة التشغيل عند التغييرات أم لا.

tyranron ،

لذلك مع تطبيق kubectl ، يتم تغيير مواصفات النشر ويتم إعادة إنشاء السنفات.

هل يمكن ان توضح؟ هل يجب علي فقط استخدام kubectl apply -f new_config.yml مع عمليات النشر المحدثة ، وسيتم إعادة تشغيل عمليات النشر هذه؟

DmitryRomanenko نعم ، بالضبط.

DmitryRomanenko مع تطبيق المواصفات الجديدة التي تقوم بتحديثها ، وعند إعادة تشغيل تحديث النشر يتم تشغيله إذا تم تغيير المواصفات الخاصة به.

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

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

منع المشكلات من الإغلاق التلقائي بتعليق /lifecycle frozen .

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

أرسل ملاحظاتك إلى اختبار sig و kubernetes / test-infra و / أو @fejta .
/ دورة الحياة التي لا معنى لها

تغيير بسيط في حل : تأكد من تقييم date داخل الصدفة:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/ إزالة دورة الحياة التي لا معنى لها
/ دورة الحياة مجمدة

كنت أستخدم وضع Swarm لبعض الوقت والذي يعتبر أقل مرونة من Kubernetes ، فأنا قادر على إعادة تشغيل مهام الخدمة (اقرأ: وحدات النشر) ، ببساطة عن طريق إجراء تحديث للقوة (بدون تغيير في المواصفات) كما في docker service update --force <service-name> . أتوقع أن يقوم Kubernetes بهذا أيضًا.
بالنسبة لخرائط التكوين والأسرار ، لا يسمح لك السرب بتعديلها ، فأنت بحاجة إلى تدويرها بدلاً من ذلك. يمكنك القيام بذلك عن طريق إنشاء خرائط / أسرار تكوين جديدة ، وتحديث مواصفات الخدمة لاستخدام المواصفات الجديدة ، ثم حذف القديمة. أرى أن هذا هو عادةً ما يوصى به أعلاه عن طريق تعيين إصدار لخرائط التهيئة / التأمينات وتحديث عمليات النشر التي تستخدمها. لأكون صادقًا ، فإن سلوك الدوران هذا هو أحد الأسباب الرئيسية التي دفعتني إلى ترك السرب من أجله! من غير الملائم أن يكون لديك نسخة محلية ، قم بالتحديث ثم إنشاء موارد جديدة وتحديث الموارد التابعة في النهاية. أضف إلى ذلك ، الأسرار الموجودة في السرب لا يمكن قراءتها من واجهة برمجة التطبيقات ، يجب عليك تركيبها داخل أي حاوية (أو داخل حاوية تستخدمها) ، ثم cat ملفاتها.
في ملاحظة ذات صلة ، استخدمت openhift لبعض الوقت وأعتقد أنه يعيد تشغيل البودات تلقائيًا عند تغيير env / configmap / secret؟ أقف على الرغم من تصحيح.

يجب أن يكون التطبيق مسؤولاً عن مراقبة نظام الملفات للتغييرات ، كما ذكرنا ، يمكنك استخدام المجموع الاختباري على configmap / secret وإجبار إعادة التشغيل بهذه الطريقة

ولكن إذا كنت لا ترغب في تغيير التكوين على الإطلاق والقيام فقط بإعادة التشغيل المتداول مع الإيقاف المؤقت التعسفي ، فإن خط الأنابيب البسيط يقوم بالمهمة (هذا ينام 30 ثانية بين البود المنتهي)

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

لاحظ أنه إذا ضغطت على ctrl + c ، فليس من السهل إعادة التشغيل من حيث توقفت

@ so0k ، أمر بديل:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

بعد مرور عامين ونصف وما زال الناس يصنعون حلولًا بديلة جديدة ، مع متغيرات بيئة وهمية ، وملصقات وهمية ، و ConfigMap و Secret Watcher sidecars ، والتوسع إلى الصفر ، ونصوص شل التحديث المتداول مباشرة لمحاكاة القدرة على إطلاق التحديث المتداول. هل لا يزال هذا شيئًا لا ينبغي السماح لمشرفي الكتلة بفعله بأمانة ، دون الحيل؟

27081 # 33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

حيلة أخرى هي التشغيل الأولي:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

وثم:

kubectl set image deployment/my-deployment mycontainer=myimage

سيؤدي ذلك بالفعل إلى تشغيل التحديث المتداول ولكن تأكد من أن لديك أيضًا imagePullPolicy: تعيين "دائمًا".

خدعة أخرى وجدتها ، حيث لا يتعين عليك تغيير اسم الصورة ، هي تغيير قيمة الحقل الذي سيؤدي إلى تحديث مستمر ، مثل terminationGracePeriodSeconds. يمكنك القيام بذلك باستخدام kubectl edit النشر your_deployment أو kubectl application -f your_deployment.yaml أو باستخدام تصحيح مثل هذا:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@ so0kKIVagant حذف البودات يعني التوقف ، حتى عند تشغيل مثيلات متعددة. عندما يقوم شخص ما بتشغيل حجرة واحدة مع strategy.rollingUpdate.maxUnavailable = 0 فإن النشر المنتظم أولاً ينشئ حجرة جديدة قبل أن تنهي الحافظة الحالية. تؤدي خدعة kubectl patch deployment هذا السلوك ، بينما لا يؤدي حذف البودات. أرغب حقًا في طريقة غير مخترقة لإثارة هذا السلوك عند الطلب.

على سبيل المثال ، عند تشغيل الصور من hub.docker.com ، يمكن تصحيح نفس العلامة لتحديثات الأمان. أرغب حقًا في "سحب أحدث الصور" وإجراء تحديث متجدد لأي صورة قديمة.

طرح تحديثات ConfigMap / Secret هو # 22368
نشر أسهل للصور الجديدة هو # 1697
التحديثات المستمرة في المكان هي # 9043

أعد التشغيل على إصدارات الصور: https://github.com/GoogleCloudPlatform/freshpod
عرض قمة Helm لخدعة باستخدام تعليق توضيحي نموذجي لبدء نشر النشر: https://www.youtube.com/watch؟

@ bgrant0607 أعتقد أن حالة الاستخدام المهمة التي لا تغطيها التذاكر الأخرى هي هذه: https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

ghodss كتب:
أفترض أن هذا سيكون أكثر للموقف الذي يكون فيه البود على قيد الحياة ويستجيب لعمليات الفحص ولكن لا يزال يتعين إعادة تشغيله. أحد الأمثلة على ذلك هو خدمة ذات ذاكرة تخزين مؤقت في الذاكرة أو حالة داخلية تالفة وتحتاج إلى مسح.

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

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

لقد حصلت على خط واحد مشابه بناءً على النهج الذي وصفهrcoup و paunin ، لكن يجب أن يعمل مع الحالة الأكثر عمومية. يعتمد على إخراج JSON ويستخدم jq للتحليل. لقد تم تحميل هذا في bashrc الخاص بي كوظيفة حتى يمكنني تسميته في أي مكان

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

هذا يسمح لي أن أقول فقط: kubectl-restart my-deployment-name وسيقوم "بتحديث" RESTART_ env var في الحاوية الأولى إلى الطابع الزمني الحالي. أنا بعيد كل البعد عن خبير jq ، لذا قد تكون هناك طريقة أفضل للقيام بذلك ، لكنها تحذف بشكل أساسي var RESTART_ env القديم من الإخراج (إذا كان موجودًا) ثم يضيفه مرة أخرى هناك مع الوقت الحالي.

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

هذا اختراق جيد وكل شيء ، لكن له جانبًا سلبيًا كبيرًا. في المرة التالية التي تقوم فيها بالنشر ، باستخدام kubectl apply -f ، ستتم إعادة تشغيل هذا المكون إذا كان يحتوي على RESTART_xxx env var حتى لو لم يتغير شيء آخر. وبعبارة أخرى ، فإنه يتسبب في إعادة تشغيل زائفة في النشر التالي إذا تم إعادة تشغيله بين آخر نشر وهذا النشر. ليست مثالية...

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

لقد كتبت دالة bash لإنجاز استراتيجية "نشر التصحيح terminationGracePeriodSeconds " whereisaaron المقتبس في تعليقه أعلاه (المصدر: https://stackoverflow.com/a/40368520/90442).

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

التعليق / التحديث عبر جوهر هنا . سأكرر تعليقات الآخرين بأنه سيكون من الأفضل لو لم يكن ذلك ضروريًا.

فقط من خلال تبرير متعلق بـ kube بشكل أكثر تحديدًا ، تسمح إعادة التشغيل أيضًا بإعادة تشغيل حاوية init ، والتي يمكن استخدامها لتدوير المفاتيح أو تحديث التكوين أو أيًا كان ما تستخدمه حاويات init.

@ kubernetes / sig-apps- features- طلبات kow3nsjanetkuo

gjcarneiro هل كان لديك RESTART_xxx env var في التكوين الذي طبقته ، أم لا؟ إذا لم يكن الأمر كذلك ، فأنا أتوقع أن يتقدم بطلب لتجاهل env var الإضافي في الحالة الحية.

ccapelisse

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

أحب أن يكون لديك هذه الميزة. يبدو أساسيًا جدًا ومطلوبًا.

لا تقدم هنا ولا على # 22368 ، تنهد :-(

هل يمكن لأي شخص أن يوصي بحل سريع وقذر لإعادة تشغيل DaemonSet بعد تحديث ConfigMap المركب (لا يزال الاسم متطابقًا)؟

@ الكحول ، تحقق من هذا https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

شكرا على الاكرامية :-)

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

علاوة على ذلك ، يحتوي مستودع Docker على محفوظات ، لذلك لا يوجد سبب لعدم عمل التراجع - يمكن أن يستخدم البود الذي تم إنتاجه من .spec.template image-tag:@digest تنسيق

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

يبدو أنك إذا قمت بتحديث قيمة الملصق ضمن pod> template> metadata ، فسيتم إجراء تحديث متجدد بعد kubectl apply -f file.yaml

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

بالتأكيد ، الجانب السلبي هو أنه في المرة القادمة التي تريد فيها إجراء نشر ، ستفعل kubectl apply -f some.yaml ، أليس كذلك؟ عادةً ، إذا لم يتغير شيء في some.yaml فلن تتم إعادة تشغيل أي شيء ، فهذا أحد أجمل الأشياء في Kubernetes.

لكن تخيل ما يحدث بعد تغيير التسمية لإعادة تشغيل النشر. في عملية نشر البرنامج العادية التالية ، تقوم بإجراء kubectl apply -f some.yaml كالمعتاد ، ولكن نظرًا لأن ملف yaml لا يحتوي على نفس التصنيف ، فسيتم إعادة تشغيل النشر دون داع.

gjcarneiro إذا لم تقم apply عند إجراء تغيير ، فلن يتم تحديث التعليق التوضيحي kubectl.kubernetes.io/last-applied-configuration ، لذا لن يتسبب apply إعادة التشغيل مرة أخرى.

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

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

عدل هذا وأضفه كدالة في .bashrc الخاص بك وهو حل مؤقت جيد.

آه ، رائع ، لم أكن أعرف ذلك ، شكرًا!

لا أحتاج إلى الاسم المستعار bash ، ففي شركتي صممنا واجهة الويب الخاصة بي لإدارة Kubernetes باستخدام Python + aiohttp وهو يستخدم بالفعل التصحيح. فكرت في البحث عن مصادر مفتوحة ، كنت كسولًا ...

يبدو أن الأشخاص يكررون نفس الحلول البديلة في سلسلة الرسائل هذه - يرجى قراءة الموضوع بالكامل قبل النشر هنا

joelittlejohn قمت بتشغيل الماكرو الخاص بك وأدى ذلك إلى إعادة تشغيل

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

الطريقة الوحيدة التي سيحل بها هذا استبدال جميع الكبسولات في نفس الوقت هي إذا كان .spec.strategy.rollingUpdate.maxUnavailable يسمح بذلك.

نحن أيضًا بحاجة إلى هذه الميزة. إحدى حالات الاستخدام أيضًا من جانبنا هي أننا نستخدم خادم spring-cloud-config-config المدعوم من قبل و scm ، لتطبيقنا الربيعي. عندما نقوم بتغيير خاصية التكوين ، يحتاج تطبيق spring-boot إلى إعادة التشغيل ليتمكن من جلب تغيير التكوين الجديد ، لذلك نحتاج أيضًا إلى هذا النوع من مشغل إعادة التشغيل الرشيق دون الحاجة إلى إعادة النشر.

japzio كما اقترح هيلم ، يعد المجموع الاختباري لخريطة التكوين في التعليقات التوضيحية طريقة جيدة للتعامل مع هذه الحالة.

هل كان هناك أي تحديث على هذا؟ نحن نتطلع إلى الحصول على هذه الميزة أيضًا. تضمين التغريدة

@ bholagabbar-mt ما هي حالة استخدامك؟

cc @ kow3nsjanetkuo

@ bgrant0607 @ kow3nsjanetkuo النموذج التطبيقي لأنظمتنا هو متعدد الجوانب.

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

2. هذا معقد بعض الشيء ، لكن النطاق العام ، كما اقترح أحدهم ، هو إصلاح السلوك غير الطبيعي. لدينا 4-5 تطبيقات Java ثقيلة تعمل على إطار عمل Play. نحن نواجه موقفًا يرتفع فيه استهلاك الذاكرة في جراب جافا الخاص بنا خطيًا ثم يعيد تشغيل البودات عند الوصول إلى الحد الأقصى للذاكرة. هذه مشكلة Java موثقة تتعلق بمشكلة تدفق التراص ومشكلة Kubernetes المرتبطة بها. إعادة تشغيل جميع الكبسولات في فترة 3-4 ساعات سيعيد ضبط استهلاك الذاكرة ويسمح لتطبيقاتنا بالعمل بسلاسة دون ارتفاعات.

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

@ bholagabbar-mt فقط غيّر متغير بيئة وسيؤدي إلى نشر متجدد:

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

تضمين التغريدة لقد قمنا بدمج هذا التغيير في أنظمتنا اليوم نفسه وهو يعمل بشكل جيد. شكرا جزيلا!

سي سي huzhengchuan

حالة استخدام أخرى لهذا: نظرًا لوجود مشكلة أمنية في الحاوية ، أود إعادة تشغيل جميع البودات. https://seclists.org/oss-sec/2019/q1/119 إما أن المجموعة تتعطل تمامًا أو تقوم بإعادة التشغيل. إن وجود أمر إعادة التشغيل سيحدث فرقًا كبيرًا!

التحديث ، الحل:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

realfresh أنت أفضل الممارسات. أضف annotation:{creatTime: 12312312} في مزرعة!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

يبدو أنه أمر ضئيل يؤدي المهمة لنشر واحد. إنه مثال على استخدام التكوين الحتمي.

سم مكعبmonopoleapelisse

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

لا تزال التحديثات المتدرجة نشاطًا شائعًا جدًا لشيء ليس له حالة استخدام على ما يبدو

قضية طويلة الأجل (ملاحظة للنفس)

1. لا أرى طريقة للقيام بذلك دون السماح للمنطق الإلزامي بالتسرب إلى واجهة برمجة تطبيقات تصريحية ، وبالتالي كسر تقاليدنا في الحفاظ على واجهات برمجة التطبيقات التصريحية وتنفيذ السلوك الإلزامي في وحدات التحكم ، وإدخال حالات عدم التوافق مع معظم ممارسات CI / CD.
2. يمكنني أن أتخيل واجهة برمجة تطبيقات RollingRestart ووحدة تحكم حيث تسبب إنشاء مورد RollingRestart في قيام وحدة التحكم بإعادة تشغيل Pods 1 × 1 عبر الإخلاء (وبالتالي احترام ميزانيات التعطيل) ، ولكن يمكن تنفيذ وحدة التحكم هذه باعتبارها CRD (على سبيل المثال ، أعرف سبب ذلك) علينا أن نفعل هذا في الشجرة).
3. النهج التصريحي ، على سبيل المثال إضافة lastRestartedAt = TIMESTAMP التعليق التوضيحي لا يبدو وكأنه اختراق بالنسبة لي.
4. إذا رغب أي شخص في تقديم تصميم إعلاني ومساهمة في تنفيذ هذه الميزة (في الشجرة أو غير ذلك) ، فيرجى التفكير في تأليف KEP PR مقابل إعادة شراء التحسينات . إذا كان من الممكن تصميم تطبيق تصريحي ، مدمج ، فسيسعدني مراجعة / دعم واجهات برمجة تطبيقات أعباء العمل. إذا تم عرض وحدة تحكم CRD مثل [2] ، فيمكننا رعايتها في تطبيقات SIG باعتبارها امتدادًا برعاية المجتمع.

النهج التصريحي ، على سبيل المثال إضافة lastRestartedAt = TIMESTAMP التعليق التوضيحي لا يبدو وكأنه اختراق بالنسبة لي.

إنه ليس اختراقًا ، يجب أن يكون هناك سطر أوامر مختزل له.

يمكن لأي شخص بناء البرنامج المساعد krew الذي يرسل التصحيح. kubectl restart-deployment <deployment_name> ؟

kubectl rollout restart الذي يصحح نشر / daemonset / statefulset لبدء عملية "نشر" جديدة؟

يتماشى هذا مع نهج @ kow3ns (3) ، ومن المنطقي أنه يمكنك بعد ذلك مشاهدة / إيقاف مؤقت / استئناف الطرح الذي بدأته للتو بأوامر kubectl rollout .

whereisaaron سأرى ما إذا كان بإمكاني إرسال تصحيح لذلك (التورية غير مقصودة)

لطرح الأسرار وخرائط التكوين الجديدة ، لا تزال توصيتي # 22368: إنشاء أسرار جديدة. يوفر ذلك وسيلة للتحكم في كل من الطرح والتراجع أيضًا. نحتاج فقط إلى إنهاء GC للكائنات القديمة:
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

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

cc monopole

بالنسبة للصور الجديدة ، CI / CD أو وحدة تحكم تقوم بحل العلامات لتضمينها: # 1697.

كان من المفترض أن يتم نقل البودات غير السعيدة بواسطة عامل إلغاء الجدولة (https://github.com/kubernetes-incubator/descheduler) أو شيء من هذا القبيل ، يمكن أن يستهلك حالة الحاوية والمقاييس الأساسية وحتى المقاييس المخصصة:

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

أيضًا ، الوثائق الرسمية حول كيفية التعامل مع الأسرار وخريطة التكوين: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

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

حسنًا ، تم دمج kubectl rollout restart !

إنه لأمر رائع أن تسمع بعد ما يقرب من 4 سنوات ، شكرًا!

أعتقد أن العلاقات العامة المدمجة تدعم عمليات النشر فقط ، فهل هذا صحيح؟

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

apelisse هل هناك أيضًا طريقة للقيام بذلك عبر sdk أو kubectl فقط؟

@ e-nikolov ما هي SDK؟

قصدت عميل Go الذي يمكن استخدامه للتحدث إلى kubernetes من برامج Go.

لا ، سيكون عليك إعادة تنفيذ المنطق (البسيط جدًا) الذي تم تنفيذه في kubectl.

حسنًا ، تم دمج إعادة تشغيل kubectl الطرح!

ما هو الإصدار kubectl سيحتوي عليه؟

ما هو إصدار kubectl سيكون عليه؟

Kubernetes 1.15.0 تحديث

قامت مجموعة GKE الخاصة بنا على قناة الإصدار "السريع" بترقية نفسها إلى Kubernetes 1.16 والآن توقف kubectl rollout restart عن العمل:

kubectl الطرح إعادة نشر تطبيق myapp
خطأ: أمر غير معروف "إعادة نشر تطبيق myapp"

سأل nikhiljindal منذ فترة عن حالة الاستخدام لتحديث عمليات النشر دون أي تغييرات على المواصفات. ربما نقوم بذلك بطريقة غير مثالية ، ولكن ها هو: يتم تحميل نماذج ML المدربة مسبقًا في الذاكرة من Google Cloud Storage. عندما يتم تحديث ملفات النموذج على GCS ، نريد إعادة تشغيل نشر K8S ، والذي يسحب النماذج من GCS.

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

يا dimileeh

هل تعرف ما هو إصدار kubectl الذي تستخدمه الآن؟ وما هو الإصدار الذي استخدمته من قبل؟ أود أن أعرف ما إذا كان هناك تراجع ، ولكن في نفس الوقت سأفاجأ إذا اختفت الميزة تمامًا.

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

مرحبًا apelisse ، شكرًا لك على ردك!

عندما أقوم بتشغيل kubectl version من Google Cloud Terminal ، أحصل على ما يلي:

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

عندما حاولت ترقية kubectl عبر gcloud components update ، قيل إنني أستخدم بالفعل أحدث الإصدارات من جميع المنتجات. لذلك ، أعتقد أن إصدار kubectl الخاص بي ظل كما هو بينما تمت ترقية مجموعة K8S من 1.15 إلى 1.16.

وثائق Kubenetes 1.17 و 1.16 و 1.15 لا تحتوي على أي شيء حول ميزة kubectl rollout restart . لذا أتساءل عما إذا كان من الممكن أن تختفي مساهمتك القيمة من 1.16؟

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

يمكنني رؤية المستندات هنا:
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-reset-em-

آه ، شكرًا لك ، كنت أبحث هنا:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

شكرًا جزيلاً لك على هذا الرابط ، وسأحرص على تحديثه!

يوم الخميس 19 ديسمبر 2019 الساعة 12:40 مساءً Dmitri Lihhatsov [email protected]
كتب:

آه ، شكرًا لك ، كنت أبحث هنا:
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubernetes/issues/13488؟email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVREXG43VMissment
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (سأختار من الفروع ذات الصلة بمجرد دمج هذا).

dimileeh أعتقد أنني اكتشفت الخطأ في إصدار kubectl الخاص بك ، وسنعمل على حله.

نعم ، لدينا أيضًا حالة إعادة تشغيل pod دون تغيير الكود ، بعد تحديث configmap. هذا لتحديث نموذج ML دون إعادة نشر الخدمة.

anuragtr بأحدث الإصدارات التي يمكنك تشغيلها

kubectl rollout restart deploy NAME

كنت أستخدم أمرًا مخصصًا لذلك [1] ، سعيد لأنه الآن في kubectl القياسي! شكرا

[1] https://github.com/mauri870/kubectl-renew

anuragtr بأحدث الإصدارات التي يمكنك تشغيلها

kubectl rollout restart deploy NAME

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