لقد تم إبلاغي بنشر مشكلة هنا تحدد العديد من المشكلات المتعلقة بإعداد kubeadm. المشكلة الأساسية التي وجدتها هي عدم وجود مستند واضح وموجز ، وبالنسبة لأولئك الذين يبحثون عن جولة حول تمكين ميزات مزود السحابة في أي سحابة ، فإن المهمة شاقة للغاية وغير موثقة بشكل كافٍ باستثناء واحد أو اثنين منشورات المدونة الخاصة بـ openstack أو مقدمي الخدمات الآخرين (وليس AWS).
هل يمكننا الحصول على وثائق تتضمن الخطوات التالية والتوضيح مع تفسيرات واضحة / موجزة تتعلق بمقدمي خدمات معينين:
أعتقد أنه إذا قام شخص ما بإنشاء مستند تدريجي ومقاوم للفشل يعرض إعداد برنامج رئيسي باستخدام kubeadm باستخدام الأمر kubeadm init ، ثم الوصلات المقابلة مع تكوين kubelet الأساسي لمجموعة فسيكون ذلك مفيدًا للغاية. هذه حالة استخدام خاصة جدًا لأنها تسمح بربط العقد ديناميكيًا دون الحاجة إلى إعادة تطبيق عالمي ، كما أنها تتيح / تسمح بالميزات التي تركز على موفر AWS في kube. حالة الاستخدام الخاصة هذه غير متوفرة في KOPS / kubespray والأدوات الأخرى التي رأيتها.
الوثائق الحالية التي مررت بها تبدو ناقصة / غير كافية:
kubeadm على مكدس مفتوح
k8s-cloud-Provider-Notes
أشعر أن kubeadm مثير ، وعلى الرغم من أنني أستخدمه بدون تمكين المزود ، سيكون من الجيد أن يكون لديك بعض الميزات التي تعمل لأشياء مثل القرص الثابت. قد يستخدم هذا بعضًا من TLC وأعتقد أن الاضطرار إلى المرور عبر الكود هو حقًا مضيعة للوقت لأولئك الذين ليسوا على دراية بقاعدة الشفرة.
أعتقد أنه يمكن حلها قريبًا.
يعد الأسلوب باستخدام ملف التكوين أمرًا مثيرًا للاهتمام لأنه يمكنك تمرير 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
للموفرين الآخرينسي سي @ لوكساس
@ 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 يتتبع تحديثاتهم.
التعليق الأكثر فائدة
أعتقد أنه يمكن حلها قريبًا.
يعد الأسلوب باستخدام ملف التكوين أمرًا مثيرًا للاهتمام لأنه يمكنك تمرير
kube-api-server
وkube-controller-manager
إضافيين في تعريف yaml ، على سبيل المثال:المرجع: 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
للموفرين الآخرينسي سي @ لوكساس