Kubeadm: مشكلة التتبع: مخطط موجز لاستخدام موفري السحابة

تم إنشاؤها على ٧ نوفمبر ٢٠١٧  ·  45تعليقات  ·  مصدر: kubernetes/kubeadm

لقد تم إبلاغي بنشر مشكلة هنا تحدد العديد من المشكلات المتعلقة بإعداد kubeadm. المشكلة الأساسية التي وجدتها هي عدم وجود مستند واضح وموجز ، وبالنسبة لأولئك الذين يبحثون عن جولة حول تمكين ميزات مزود السحابة في أي سحابة ، فإن المهمة شاقة للغاية وغير موثقة بشكل كافٍ باستثناء واحد أو اثنين منشورات المدونة الخاصة بـ openstack أو مقدمي الخدمات الآخرين (وليس AWS).

هل يمكننا الحصول على وثائق تتضمن الخطوات التالية والتوضيح مع تفسيرات واضحة / موجزة تتعلق بمقدمي خدمات معينين:

  1. تعديل / إنشاء ملف التكوين السحابي جنبًا إلى جنب مع إضافة --cloud-Provider / --cloud-config flags في apiServer وملفات kube-controller لـ kube-master ليس كافيًا.
  2. بالإضافة إلى ذلك ، يتعين على المرء تحديث kubelets لاحتواء علامة --cloud-Provider / --cloud-config في "متغير env args الإضافي". هل يتطلب هذا إعادة التشغيل ، أو أي أمر ذي حالة؟ ابدأ سيدًا ، ثم ابدأ kubelets ، إلخ.
  3. هذا لا يكفي لتمكين مزود السحابة ؛ تتطلب AWS أذونات IAM محددة للتفاعل مع Amazon بالإضافة إلى علامات محددة 'KubernetesCluster ='(من ملف التكوين السحابي في جميع العقد). ومع ذلك ، لا توجد وثائق تشرح الموارد بدقة - من المفترض أنه يتعين عليك وضع علامة على كل شيء. حتى ذلك الحين ، بعد وضع العلامات وبعد إتاحة الوصول الكامل إلى S3 و EC2 و VPC (للاختبار فقط) وما إلى ذلك ، ما زلت لا أستطيع تحديث أخطاء
  4. حتى بعد 1-3 خطوات ، لا يزال هذا غير كافٍ لتشغيل kubeadm مع مزود السحابة على AWS. لقد كسرت أيضًا تركيب كاليكو الخاص بي ، مما يقودني إلى التساؤل عن مدى إمكانية ذلك.

أعتقد أنه إذا قام شخص ما بإنشاء مستند تدريجي ومقاوم للفشل يعرض إعداد برنامج رئيسي باستخدام kubeadm باستخدام الأمر kubeadm init ، ثم الوصلات المقابلة مع تكوين kubelet الأساسي لمجموعة فسيكون ذلك مفيدًا للغاية. هذه حالة استخدام خاصة جدًا لأنها تسمح بربط العقد ديناميكيًا دون الحاجة إلى إعادة تطبيق عالمي ، كما أنها تتيح / تسمح بالميزات التي تركز على موفر AWS في kube. حالة الاستخدام الخاصة هذه غير متوفرة في KOPS / kubespray والأدوات الأخرى التي رأيتها.

الوثائق الحالية التي مررت بها تبدو ناقصة / غير كافية:

kubeadm على مكدس مفتوح
k8s-cloud-Provider-Notes

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

areUX kindocumentation prioritimportant-longterm sicloud-provider

التعليق الأكثر فائدة

أعتقد أنه يمكن حلها قريبًا.
يعد الأسلوب باستخدام ملف التكوين أمرًا مثيرًا للاهتمام لأنه يمكنك تمرير kube-api-server و kube-controller-manager إضافيين في تعريف yaml ، على سبيل المثال:

apiServerExtraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"
controllerManagerExtraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"

المرجع: https://kubernetes.io/docs/admin/kubeadm/#config -file

لا يمكن تكوين وحدات التخزين للملف /etc/kubernertes/cloud.conf حتى الآن ، ومع ذلك ، تم تنفيذه بالفعل هنا: https://github.com/kubernetes/kubernetes/pull/49840/

في الآونة الأخيرة ، تمت إضافة وثائق ملف cloud-config لـ OpenStack وأعتقد أن موفري السحابة الآخرين يمكنهم فعل الشيء نفسه: https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack

هناك نقطة أخرى حول تكامل موفري السحابة وهي إعادة البناء قيد التنفيذ لدعم موفري السحابة خارج الشجرة وغير المعالجين (المعروفين أيضًا باسم موفري السحابة القابلة للتوصيل) ، راجع الاقتراح: https://github.com/kubernetes/community/ blob / ماجستير / مساهمون / design-articles / cloud-Provider / cloud-provider-refactoring.md

لذا، فإن مقدمي سحابة التكامل لا يزال في مرحلة تجريبية، ولكن أعتقد أن kubeadm تسير على الطريق الصحيح: https://kubernetes.io/docs/admin/kubeadm/#cloud -provider-التكامل-التجريبية

أعتقد أن الأمر الأكثر إلحاحًا هو إنشاء / تكييف وثائق حول:

  • cloud-config للموفرين الآخرين
  • تكامل مزود السحابة نفسه
  • دروس باستخدام ملف التكوين kubeadm

سي سي @ لوكساس

ال 45 كومينتر

أعتقد أنه يمكن حلها قريبًا.
يعد الأسلوب باستخدام ملف التكوين أمرًا مثيرًا للاهتمام لأنه يمكنك تمرير kube-api-server و kube-controller-manager إضافيين في تعريف yaml ، على سبيل المثال:

apiServerExtraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"
controllerManagerExtraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"

المرجع: https://kubernetes.io/docs/admin/kubeadm/#config -file

لا يمكن تكوين وحدات التخزين للملف /etc/kubernertes/cloud.conf حتى الآن ، ومع ذلك ، تم تنفيذه بالفعل هنا: https://github.com/kubernetes/kubernetes/pull/49840/

في الآونة الأخيرة ، تمت إضافة وثائق ملف cloud-config لـ OpenStack وأعتقد أن موفري السحابة الآخرين يمكنهم فعل الشيء نفسه: https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#openstack

هناك نقطة أخرى حول تكامل موفري السحابة وهي إعادة البناء قيد التنفيذ لدعم موفري السحابة خارج الشجرة وغير المعالجين (المعروفين أيضًا باسم موفري السحابة القابلة للتوصيل) ، راجع الاقتراح: https://github.com/kubernetes/community/ blob / ماجستير / مساهمون / design-articles / cloud-Provider / cloud-provider-refactoring.md

لذا، فإن مقدمي سحابة التكامل لا يزال في مرحلة تجريبية، ولكن أعتقد أن kubeadm تسير على الطريق الصحيح: https://kubernetes.io/docs/admin/kubeadm/#cloud -provider-التكامل-التجريبية

أعتقد أن الأمر الأكثر إلحاحًا هو إنشاء / تكييف وثائق حول:

  • cloud-config للموفرين الآخرين
  • تكامل مزود السحابة نفسه
  • دروس باستخدام ملف التكوين kubeadm

سي سي @ لوكساس

@ srflaxu40 ، هل نظرت إلى https://github.com/appscode/pharmer . تتم معالجة هذا النوع من المشكلات خارج منطقة الجزاء في Pharmer.

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

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

نعم فعلا.

يمكنك التحقق من العلامات التي نمررها للحصول على التهيئة السحابية / المزود في الصيادلة لـ aws.

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

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

هذا هو الشيء بالرغم من ذلك - المكون الرئيسي لحالة الاستخدام الخاصة بي هل يجب تشغيله في SpotInst؟

نعم. الحالات الموضعية غير مدعومة حاليًا.

@ srflaxu40 شكرًا على هذه المشكلة. نحن نعلم أن هذه نقطة ألم ونحن في حالة ما بين حاليًا ، والمجتمع في منتصف نقل مزودي الخدمات السحابية هؤلاء من الشجرة. بقدر ما قد يبدو قاسياً ، فإنه في النهاية تقع على عاتق موفر السحابة المعني مسؤولية توفير الوثائق حول ما هو مطلوب لكل حالة. لا تستطيع kubeadm فعل أي شيء من أجلك هنا (على سبيل المثال ، إعداد أدوار IAM لمزود السحابة-name-it-cloud-Provider).

إذا كنت مهتمًا بإعادة بناء موفر السحابة وكيف ستتحسن العملية ، فابحث عن مستندات الشجرة على kubernetes.io وانضم إلى # wg-cloud-Provider على Slack. تجتمع المجموعة الساعة 10 صباحًا بتوقيت المحيط الهادئ اليوم وكل أربعاء.

tamalsaha هههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههه

شكرا على التعليق @ arthur0!

TL ؛ DR ؛ ما هي عناصر العمل _ الواقعية التي نراها هنا الآن والتي قد تؤثر على kubeadm؟

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

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

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

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

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

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

/ تعيين liztio

محاولة جعل مجموعة kubeadm المثبتة للعمل مع EBS في نظام AWS لكنها فشلت. آمل أن يكون هناك بعض التعليمات الجيدة لذلك.

/ ccluxas - هذا مطلوب بالتأكيد لإصدار 1.11.

timothysc ما الذي تغير منذ نوفمبر الماضي؟ لا تزال sig-docs تعمل على إخراج مستندات مزود السحابة من الشجرة ؛ لم يتغير شيء هناك. يمكنني رؤية قيمة التوثيق بشكل أكثر وضوحًا مهما كانت الميزات الجديدة في تثبيتات موفر السحابة لدعم kubeadm ، ولكن يجب أن تكون مشتركة مع kubeadm ، وليس خاصة بموفري الخدمات السحابية. التوضيح سوف يساعد ، شكرا!

في اجتماع ساعات عمل kubeadm اليوم (06.06.2018) تقرر ما يلي:

ليس لدينا إرشادات موفر السحابة الخاصة بـ kubeadm - المستندات هنا ، ولكن ربما يجب علينا الارتباط بها فقط + بعض التفاصيل الموجزة ، لأننا لا نريد التوسع في تفاصيل مزود السحابة: https://kubernetes.io/ المستندات / أدلة البدء / cloudstack /

https://docs.google.com/document/d/130_kiXjG7graFNSnIAgtMS1G8zPDwpkshgfRYS0nggo/edit#

^ ما ورد أعلاه مفتوح للنقاش.
timothysc @ Bradamant3 @ srflaxu40

سآخذ هذا واحد.

لذلك ناقشنا هذا اليوم في المكالمة sig. سيكون من المثالي أن يكون لديك مجموعة محدودة من التجاوزات الموضحة ثم ربطها بمستند منفصل يحتفظ به موفر sig-cloud.

/ ccandrewsykim

لمعلوماتك hogepodge re: https://github.com/kubernetes/website/issues/8304

نحن نعمل مع @ kubernetes / sig-cloud-Provider-misc للمساعدة في الحصول على مراجع أفضل في مكانها الصحيح ، ولكن قد يتأخر إصدار v1.11 لذا فنحن نعمل على تحقيق ذلك ، ولكننا نعمل بنشاط على التفاصيل.

andrewsykim ، هل يمكنك ربط الاقتراح الذي كنت تتحدث عنه ، من فضلك.

timothyschogepodge تعمل حاليا على وضع شيء معا، وعبر الارتباط في أقرب وقت كما انها بها.

لا أريد ترك هذا بدون رد.

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

https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/

يحتوي Cloud-Provider-openstack على بعض الوثائق ، لكنه لا يعالج المشكلة التي تصفها تمامًا.

https://github.com/kubernetes/cloud-provider-openstack/pull/67
https://github.com/kubernetes/cloud-provider-openstack/pull/224
https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-controller-manager-with-kubeadm.md

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

قدمنا ​​تقريرين في اليومين الماضيين ، حول المستخدمين الذين لا يفهمون كيفية تمرير مزود السحابة إلى مستوى التحكم و kubelet من kubeadm.

لقد كنت أكتب مدير وحدة التحكم السحابية في Brightbox على مدار الأسابيع القليلة الماضية وقمت بإعداد قائمة من الأسئلة والأشياء التي كان عليّ العمل عليها لدمجها في kubernetes وعلى وجه الخصوص في مجموعة مبنية من kubeadm.

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

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

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

يمكنني ربط تجربتي في هذا التذكرة أو غيرها من التذكرة ذات الصلة إذا كان ذلك يساعد. دعني اعرف.

NeilW إذا كان بإمكانك إنشاء مشكلة في kubernetes/kubernetes وعلامة sig-cloud-Provider ، فسيسعدنا مناقشتها في اجتماعنا القادم.

andrewsykim @ d-nishi - هل

/ سم مكعب @ Bradamant3

أهلا،
تضمين التغريدة

ما هي حالة https://github.com/kubernetes/community/blob/master/keps/sig-cloud-provider/0019-cloud-provider-documentation.md من حيث المتابعات k/website docs ؟

هل سنتمكن من إغلاق هذه المشكلة لـ 1.12؟
/ سم مكعب @ تيموثيسك

@ neolit123 نحن ببساطة بحاجة للإشارة إلى إحدى الصفحات.
من الناحية المثالية ، ستكون خطوة ما بعد النشر مشابهة لـ CNI ولكن لموفري السحابة خارج الشجرة. https://docs.google.com/spreadsheets/d/1zqqh_S8qZBJx6DPTXrjElN1RJXiQGnIymPuVL4PUczo/edit#gid = 0

تضمين التغريدة
مفهومة ، بمجرد إنشاء صفحة k/website (؟) سنقوم بالربط بها.

نعم فعلا.

لا يبدو أنه يمكننا الارتباط حتى 1.13 في هذه المرحلة.

نعتذر عن عدم استكمال هذا في الوقت المناسب لـ v1.12.

أثناء عملنا من خلال المستندات في الإصدار التالي ، إذا كان لديك أي شيء _ محدد _ تريد تضمينه كجزء من مستندات الموفر (مثل خطوات تثبيت kubeadm) ، فيرجى اقتراح تلك الموجودة في https://github.com/kubernetes/community/blob/master/ keps / sig-cloud-provider / 0019-cloud-provider-documentation.md

andrewsykim ما حالة هذا لـ 1.13؟

timothysc آسف للرد المتأخر ، كان خارج الأسبوع الماضي في شركة خارج الموقع.

ما زلنا ننفذ KEP-0019 ونتتبع تقدم المستندات من كل مزود في صحيفة تتبع مزود السحابة (يلزم أن تكون في قائمة بريدية لموفر السحابة kubernetes-sig-cloud للوصول). بالنسبة إلى دمج المستندات معًا ، يقودchenopis هذا الجهد وسيحصل على المزيد من التحديثات قريبًا.

/ تعيين dims

يسحبك للداخل ؛-)

andrewsykimchenopis - أين مستندات الترشح لل1،13؟

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

timstclair تقريب حالة التوثيق لجميع مقدمي الخدمة. نتطلع إلى جعل هذا متسقًا عبر جميع مقدمي الخدمة.

https://docs.google.com/document/d/1yj8z2ctFZKqUGF40U_MB_7VZD8VuEz0eLFVg_CQYvzI/edit؟usp=sharing

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

وثائق مقدم وحدة التحكم السحابي Brightbox هنا.

التصميم والتطوير: https://github.com/brightbox/brightbox-cloud-controller-manager/blob/master/README.md

التثبيت والتكوين: https://github.com/brightbox/brightbox-cloud-controller-manager/blob/master/config/README.md

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

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

ما زلنا في مرحلة ألفا المبكرة من خلال Cloudstack CCM المُصمم على أساس عوامل ، لذا فإن الوثائق تتكون فقط مما هو مكتوب في README: https://github.com/swisstxt/cloudstack-cloud-controller-manager/blob/master /README.md#use

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

/ إلغاء تعيين

سأغلق هنا الآن لأن https://github.com/kubernetes/cloud-provider/issues؟q=is٪3Aissue+is٪3Aopen+label٪3AP0 يتتبع تحديثاتهم.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات