راجع أيضًا https://github.com/cookeem/kubeadm-ha - يبدو أن هذا يغطي ما أريد تحقيقه هنا.

mbert بدأنا في تنفيذ ميزات HA والخشب المقطوع على مجموعة التبعية الأساسية الآن في الإصدار 1.9 ، لكنها دورة قصيرة لمهمة كبيرة ، لذلك سيستمر العمل في الإصدار 1.10 كما أشرت.

بالنسبة للإصدار 1.9 ، سنقوم بتوثيق ما تصفه هنا في المستندات الرسمية بالرغم من ذلك ؛ كيفية تحقيق HA مع الأقسام الخارجية مثل إعداد LB

ممتاز. أنا أبحث في كل هذا الآن. أنا عالق حاليًا في bootstrapping master 2 و 3 ، ولا سيما كيفية تكوين kubelet و apiserver (ما مقدار ما يمكنني إعادة استخدامه من Master 1؟) وما إلى ذلك (أفكر في استخدام bootstrap وما إلى ذلك على جهاز منفصل للاكتشاف). الدليل من المستندات مقتضب قليلاً عندما يتعلق الأمر بهذا.

mbert لقد كنت أخبرك أنني اتبعت الدليل في المستندات وتمكنت من الوقوف على مجموعة HA k8s عاملة باستخدام kubeadm (v1.8.x).

إذا كنت تتابع هذا الإعداد وتحتاج إلى bootstrap master 2 و 3 ، فيمكنك إعادة استخدام كل شيء تقريبًا من المعلم الأول. ستحتاج بعد ذلك إلى إصلاح ملفات التكوين التالية على الماستر 2 و 3 لتعكس المضيف الحالي: /etc/kubernetes/manifests/kube-apiserver.yaml ، /etc/kubernetes/kubelet.conf ، / etc / kubernetes / admin. conf و /etc/kubernetes/controller-manager.conf

فيما يتعلق وما إلى ذلك ، إذا اتبعت مستندات الدليل هذه ، فيجب عليك إنشاء مجموعة خارجية ثلاثية العقد وما إلى ذلك تمتد عبر العقد الرئيسية 3 k8s.

هناك أيضًا عنصر واحد "مسكتك" لم تتم تغطيته بعد في مستندات الدليل.
يمكنك الاطلاع على هذه المشكلة لمزيد من التفاصيل: https://github.com/cookeem/kubeadm-ha/issues/6

لقد طرحت أيضًا بعض الأسئلة المتعلقة بـ kubeadm HA من هذا المنشور: https://github.com/cookeem/kubeadm-ha/issues/7

آمل حقًا أن يعطيني بعض الأفكار حول هذه.

شكرا لك مقدما على وقتك.

هذا شيء رائع - بالتأكيد بحاجة إلى هذا لأنني متأكد من أن 99 ٪ من مستخدمي kubeadm يعانون من جنون العظمة المزعج في مؤخرة رؤوسهم حول هكتار سيدهم (أسيادهم).

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

إذا كانت الإجابة بنعم ، أفترض أنه بعد ذلك سأحاول عرض kubelet و apiserver على الماستر 2 و 3 باستخدام التكوين من الرئيسي 1 (مع عناوين IP المعدلة وأسماء المضيف هناك بالطبع) ثم قم بتشغيل مجموعة etcd عن طريق وضع تم تعديل etcd.yaml إلى / etc / kubernetes / manifests.

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

بمجرد تشغيل هذا ، سأقوم بتوثيق العملية برمتها ونشرها.

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

تحويل المثيل المفرد _etcd_ إلى نظام مجموعة

لقد تمكنت من استبدال مثيل _etcd_ الفردي بمجموعة في مجموعة K8s جديدة. الخطوات تقريبًا هي:

1. قم بإعداد خادم _etcd_ منفصل. هذا المثال _etcd_ مطلوب فقط من أجل تمهيد الكتلة. قم بإنشاء عنوان URL للاكتشاف لثلاث عقد عليه (راجع https://coreos.com/etcd/docs/latest/op-guide/clustering.html#etcd-discovery).
2. انسخ _ / etc / kubernetes_ من المستوى الرئيسي 1 إلى الماجستير 2 و 3. استبدل اسم المضيف وعنوان IP في _ / etc / kubernetes /*.*_ و _ / etc / kubernetes / manifests /*.*_
3. قم بإنشاء بدائل لـ _ / etc / kubernetes / manifests / etcd.yaml_ لجميع الأساتذة الثلاثة: اضبط جميع عناوين URL للإعلان على عناوين IP الأساسية للمضيفين المعنيين ، وجميع عناوين URL للاستماع إلى 0.0.0.0 ، وأضف عنوان URL للاكتشاف من الخطوة 1. لقد استخدمت تعلق ملف قالب JINJA2 etcd.yaml.j2.txt جنبا إلى جنب مع _ansible._
4. انسخ الاستبدالات _etcd.yaml_ إلى _ / etc / kubernetes / manifests_ على العقد الثلاثة الرئيسية.
5. الآن الأمور تصبح حرجة الوقت. انتظر حتى تنتهي عملية _etcd_ المحلية ، ثم انقل _ / var / lib / etcd / member / wal_ في مكان آخر قبل ظهور العملية الجديدة (وإلا فسوف تتجاهل عنوان URL للاكتشاف).
6. عندما يظهر _etcd_ الجديد ، سينتظر الآن انضمام المثيلين المتبقيين. ومن ثم ، قم بتشغيل _kubelet_ بسرعة على العقدتين الرئيسيتين الأخريين.
7. اتبع سجلات الحاوية _etcd_ على اللوحة الرئيسية الأولى لمعرفة ما إذا كان هناك خطأ ما تمامًا. إذا كانت الأمور على ما يرام ، فعندئذ بعد بضع دقائق ، سيعمل التجمع مرة أخرى.

الخطوة 5 محرجة إلى حد ما ، ووجدت أنه إذا فاتني الوقت المناسب هنا أو احتجت إلى الكثير من الوقت للحصول على السيدين الآخرين للانضمام (الخطوة 6) ، فإن مجموعتي تدخل في حالة يصعب عليها ذلك
استعادة. عندما حدث هذا ، كان أبسط حل وجدته هو إيقاف تشغيل _kubelet_ على الماستر 2 و 3 ، وتشغيل _kubeadm reset_ على جميع الأساتذة والتوابع ، ومسح مجلدات _ / var / lib / etcd_ على جميع الأساتذة وإعداد مجموعة جديدة باستخدام _kubeadm فيه_.

بينما يعمل هذا ، سأكون مهتمًا بالتحسينات الممكنة: هل هناك أي نهج بديل أكثر أناقة وقوة لهذا (بشرط أن ما زلت أرغب في اتباع نهج تشغيل _etcd_ في الحاويات على الماجستير)؟

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

mbert لماذا لا تستخدم مجموعة ETCD مستقلة بدلاً من الإنشاء في k8s؟

KeithTt شكرا لك على ملاحظاتك. كنت أفكر في هذه هنا:

1. عدم استخدام أي بيانات.
2. ابق على مقربة من إعداد kubeadm قدر الإمكان.
3. اجعلها تحت إشراف K8s ودمجها في أي مراقبة أعددتها لنظامي
4. حافظ على عدد الخدمات التي تعمل على نظام التشغيل منخفضًا.
5. لن يجعل الأمور أسهل حيث لا يزال يتعين علي التعامل مع (4) أعلاه.

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

mbert يرجى التأكد من المزامنة مع jamiehannaford في هذا الجهد ، فهو يعمل أيضًا على هذا / ملتزم بجعل هذه المستندات شيئًا في الإصدار 1.9

mbert هل أنت متاح للانضمام إلى اجتماع SIG اليوم 9PT أو تنفيذ kubeadm للعلاقات العامة غدًا 9PT؟ أود مناقشة هذا الأمر معك في مكالمة: +1:

luxas في الواقع كان jamiehannaford هو الذي طلب مني فتح هذه المشكلة. بمجرد تشغيل الأمور وتوثيقها ، آمل أن أحصل على الكثير من التعليقات منه.
9PT ، هذا في غضون ساعة ، أليس كذلك؟ سيكون هذا جيدا. فقط دعني أعرف كيف أتواصل معك.

اتباع الأدلة هنا وهناك تمكنت من القيام بذلك هنا هو خطوتي الأخيرة

/ cccraigtracey

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

تم إنشاؤه - لم يتم تحويله - 3 مجموعة عقدة رئيسية باستخدام kubeadm مع مجموعة 3 عقدة وما إلى ذلك تم نشرها على kubernetes

هذا ما يجب أن أفعله:

1. قم بإنشاء 3 مجموعة عقدة رئيسية باستخدام kubeadm على خوادم مجردة
2. نشر مجموعة etcd على 3 عقد رئيسية باستخدام kubeadm
3. استخدم pod-network غير الافتراضي cidr / 27

مشاكل:

1. استخدام cidr غير الافتراضي لشبكة pod مستحيل الإعداد باستخدام _kubeadm init_
2. لا توجد وثائق حول إنشاء كتلة متعددة الرئيسية على شكل مجردة. المستندات الأخرى ليست مفصلة كما يمكن أن تكون

الطريقة التي قمت بها هي استخدام خطوات مرحلة ألفا kubeadm ، القائمة القصيرة التالية:

على جميع العقد الرئيسية:

1. بدء عامل ميناء - وليس kubelet

على masternode1:

1. إنشاء شهادات CA
2. أنشئ شهادات apiserver باستخدام معلمات _-- apiserver-advertise-address_ ، _-- service-cidr_ ، _-- apiserver-cert-extra-sans_ المعلمات المستخدمة. هنا ، فقط _ --apiserver-cert-extra-sans _ هو إلزامي.
3. أنشئ باقي الشهادات المطلوبة
4. قم بإنشاء تكوينات kubeconfig وطائرة التحكم
5. قم بتحرير ملفات yaml المنشأة حديثًا في دليل / etc / kubernetes / manifest لإضافة أي خيارات إضافية تحتاجها.
   بالنسبة لي ، هنا حيث قمت بتعيين CIDR لشبكة البود غير الافتراضية لـ / 27 في kube-control-manager.yaml. أيضًا ، قم بإزالة NodeRestriction من التحكم في القبول
6. انسخ ملف yaml المُعد مسبقًا لمجموعة etd في دليل / etc / kubernetes / manifest
7. انسخ الدليل / etc / kubernetes لبقية العقد الرئيسية وعدّل جميع الملفات اللازمة لتكوينها لـ masternode2 و masternode3.
8. بمجرد إعادة تكوين جميع الملفات ، ابدأ kubelet على جميع العقد الرئيسية الثلاثة.
9. بمجرد الانتهاء من جميع العقد ، قم بتشويه جميع العقد الرئيسية
10. تمهيد جميع الرموز
11. إنشاء رمز مميز للانضمام إلى عقد العامل
12. قم بتحرير masterConfig.yaml الذي تم إنشاؤه مسبقًا وتحديث معلمة الرمز المميز
13. تحميل masterConfig إلى kubernetes
14. تثبيت الإضافات
15. قم بإنشاء تجزئة --Discovery-token-ca-cert-hash وأضف العقد العاملة

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

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

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

أخطط لإعداد مستند مستندات google والبدء في توثيق ما فعلته (وهو أمر بسيط جدًا). أود بعد ذلك دعوة الآخرين للانضمام وكتابة الامتدادات والتصحيحات والتعليقات؟

لقد قمت الآن "بتوثيق" إعداد بسيط للغاية في شكل مشروع صغير غير مقبول: https://github.com/mbert/kubeadm2ha

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

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

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

• متانة بيانات إلخ (متعددة إلخ. تتطلب 2+ عقدتين وما إلى ذلك)
• توفر بيانات إلخ (متعدد إلخ + التكرار. يتطلب 3+ عقد وما إلى ذلك)
• توفر apiserver (خادم متعدد. يتطلب تحميل رصيد / VIP أو (على الأقل) DNS مع سجلات A متعددة)
• سم / توفر المجدول (متعدد سم / جدولة. يتطلب 2+ عقدتين رئيسيتين ، والنسخ المتماثلة = 2 + في هذه المهام)
• استعادة إعادة التشغيل - all-the-masters (تحدي للاستضافة الذاتية - يتطلب شكلاً من أشكال القرون الثابتة لطائرة التحكم)
• kubeadm upgrade دعم متعدد apiserver / سم جدولة (يختلف اعتمادًا على الاستضافة الذاتية مقابل غير المستضافة ذاتيًا)

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

أعتقد أن تفاصيل الباقي تعتمد بشكل كبير على

جانبا: أحد التحديات هنا هو أن كل شيء يتعلق بالتثبيت + تغييرات الترقية إذا كنت تفترض إعدادًا مستضافًا ذاتيًا + HA (غالبًا _ يبسط_ كل شيء لأنه يمكنك استخدام الترقيات المستمرة وآلات k8s المدمجة). أشعر أنه من خلال التأجيل المستمر لهذا الإعداد ، فقد جعلنا حقًا أن نصل إلى هذا الهدف النهائي ، وأشعر بالقلق من أننا سنستمر في دفع الإعداد "الحقيقي" مرة أخرى بينما نعمل على إتقان العزف المنفرد غير ذي الصلة- الترقيات الرئيسية: (أفضل أن نتناول إعداد HA _first_ ، ثم عملنا _ backward_ لمحاولة إنتاج تقريب لمضيف واحد إذا لزم الأمر (ربما عن طريق حزم وظائف مكررة مؤقتًا على مضيف واحد) ، بدلاً من محاولة حل مضيف واحد ثم اعتقد بطريقة أو بأخرى أن هذه التجربة ستساعدنا مع مضيف متعدد.

mbert لقد حققت عرض HA من خلال إنشاء الشهادات يدويًا لكل عقدة ، وبدون حذف NodeRestriction ، أستخدم haproxy+keepalived كمتعامل تحميل الآن ، ربما lvs+keepalived سيكون أفضل ، سوف أقوم بتوثيق التفاصيل في نهاية هذا الأسبوع ، وآمل أن أشاركها معك.

لمعلوماتك ، بدأ mbert العمل على دليل ويب رائع لـ kubeadm HA يدويًا سنضيفه إلى مستندات v1.9 kubeadm في النهاية: https://docs.google.com/document/d/1rEMFuHo3rBJfFapKBInjCqm2d7xGkXzh0FpFO0cRuqg/

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

شكرًا لك mbert وجميع الأشخاص الآخرين النشطين في الموضوع ، سيكون هذا تعاونًا رائعًا!

mbert / luxas : هذا المستند لا يسمح بالتعليقات (بالنسبة لي على الأقل: البكاء :)

تم ، لقد كان لدي الإعداد الخاطئ في المستند.

mbert لدي سؤال لك. باتباع نهجك ، على افتراض أن لدي مجموعة HA k8s عاملة. هل تعرف كيفية إضافة برامج رئيسية جديدة لـ k8s إلى عنقودتي الحالية؟ المشكلة التي أواجهها الآن هي الشهادات التي تم إنشاؤها بناءً على العدد الثابت لمضيفات k8s الرئيسية في الوقت الذي تم فيه تمهيد الكتلة. هذا الآن يمنع أي سيد جديد من الانضمام إلى الكتلة. من سجل kubelet للسيد الجديد ، سترى شيئًا مثل هذا: "... x509: الشهادة صالحة لـ 192.168.1.x ، 192.168.1.y ، 192.168.1.z وليس 192.168.1.n. " (حيث .x و. y و. z هي عنوان IP للعناصر الرئيسية الحالية و. n هو عنوان الشريحة الرئيسية الجديدة). هل تعرف كيف تحل هذه المشكلة؟ هل يجب أن تستخدم العقد الرئيسية الشهادات نفسها في هذه الحالة؟

@ kcao3 لست على دراية بهذا الجانب بالذات. ربما يستطيع jamiehannaford إخبارك المزيد عن هذا؟

@ kcao3 ستنشئ كل عملية انضمام رئيسية أصول TLS باستخدام IPv4 المحدد لذلك الخادم. يقبل التكوين أيضًا شبكات SAN إضافية ، والتي يجب أن تتضمن LB IPv4 الذي يجلس أمام الأساسيين. لدي دليل HA قيد المراجعة ، لذا تحقق من ذلك إذا كان لديك وقت.

لقد دفعت للتو إلى التزام جديد بـ https://github.com/mbert/kubeadm2ha

• شبكة الفانيلا مدعومة الآن (وافتراضي)
• هناك تثبيت أساسي للوحة القيادة (شبكة NodePort ، غير آمنة ، أي لا يوجد SSL) ككتيب تشغيل منفصل
• تنظيف الكود

mbert لقد قرأت للتو دليل HA من jamiehannaford : https://github.com/jamiehannaford/kubernetes.github.io/blob/3663090ea9b9a29a00c79dd2916e11737ccf1802/docs/setup/independent/high-availability.md. هل من الممكن في كل عقدة رئيسية أن يكون لدينا kubeadm لإنشاء شهادات منفصلة وتوقيعها باستخدام نفس CA.crt و CA.key؟

لذا فإن الأشياء الوحيدة التي يجب نسخها من الرئيسي الأساسي إلى الماجستير الثانوي هي مفتاح CA.crt و CA. باستخدام هذا الأسلوب ، سنقوم بتشغيل "kubeadm init" باستخدام ملف تكوين kubeadm بناءً على قالب مثل التالي:

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
kubernetesVersion: v{{ KUBERNETES_VERSION }}
networking:
  podSubnet: {{ POD_NETWORK_CIDR }}
api:
  advertiseAddress: {{ MASTER_VIP }}
apiServerCertSANs:
- {{ MASTER_VIP }}
etcd:
  endpoints:
{% for host in groups['masters'] %}
  - http://{{ hostvars[host]['ansible_default_ipv4']['address'] }}:2379
{% endfor %}

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

أي أفكار؟

@ kcao3 هذا ما أحاول القيام به. اكتشفت أنني بحاجة أيضًا إلى إنشاء مفاتيح CA cert + الوكيل مسبقًا والتي تختلف.
ولكن الآن عندما أقوم بتشغيل kubeadm init على أساتذتي ، تظهر جميع المكونات بشكل صحيح ولكن لا يزال وكيل kube يفشل بسبب مشكلات المصادقة ، على الرغم من توقيع front-proxy-client.crt بواسطة نفس المرجع المصدق (CA) في كل العقد.

discordianfish لقد واجهت أيضًا مشكلات المصادقة ولكن عند نشر Flannel. أتساءل عما إذا كان مرتبطًا بما تراه.

في غضون ذلك ، اكتشفت أن "المرجع المصدق الوكيل" (الواجهة الأمامية-الوكيل- *) لا يرتبط بـ kube-proxy. ما زلت أحاول معرفة ما يجري ، يبدو أنه لا يوجد دور system:node-proxier لكنني لا أعرف ما الذي يفترض إنشائه.

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

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

يبدو حساب الخدمة صحيحًا وله سر:

$ kubectl -n kube-system get ds kube-proxy -o yaml|grep serviceAccount
      serviceAccount: kube-proxy
      serviceAccountName: kube-proxy

$ kubectl -n kube-system get sa kube-proxy -o yaml|grep -A1 secrets
secrets:
- name: kube-proxy-token-5ll9k

$ kubectl -n kube-system get secret kube-proxy-token-5ll9k
NAME                     TYPE                                  DATA      AGE
kube-proxy-token-5ll9k   kubernetes.io/service-account-token   3         16m

يرتبط حساب الخدمة هذا بدور أيضًا:

$ kubectl get clusterrolebindings kubeadm:node-proxier -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: 2017-12-07T12:52:54Z
  name: kubeadm:node-proxier
  resourceVersion: "181"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/kubeadm%3Anode-proxier
  uid: 8a9638df-db4d-11e7-8d7e-0e580b140468
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:node-proxier
subjects:
- kind: ServiceAccount
  name: kube-proxy
  namespace: kube-system

والدور موجود ويظهر بشكل جيد:

$ kubectl get clusterrole system:node-proxier -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2017-12-07T12:52:51Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:node-proxier
  resourceVersion: "63"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Anode-proxier
  uid: 88dfc662-db4d-11e7-8d7e-0e580b140468
rules:
- apiGroups:
  - ""
  resources:
  - endpoints
  - services
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update

لذلك لست متأكدا ما الذي يجري. من كيفية فهمي لكل شيء ، يجب أن يعمل هذا على هذا النحو ولكن apiserver يواصل التسجيل: E1207 13:18:20.697707 1 authentication.go:64] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, crypto/rsa: verification error]]

حسنًا ، يبدو أنه لا يتم قبول الرمز المميز إلا من خلال مثيل واحد من أجهزة apiservers الخاصة بي ، ربما على الخادم الرئيسي حيث تم تشغيل kubeadm init آخر مرة. اعتقدت أنه يتم تخزين الرموز المميزة لحساب الخدمة في etcd؟

تم حل اللغز بفضل gintas و foxie في # kubernetes-users: نحتاج أيضًا إلى إنشاء مفاتيح sa مسبقًا وتوزيعها مع CA.

لقد اتبعت دليل HA الخاص بـ jamiehannaford عن كثب ووصلت في النهاية إلى مجموعة HA عاملة (تم إعدادها في إعداد Vagrant مع موازن تحميل HAProxy أمام ثلاث عقد رئيسية) ، لكنني واجهت بعض العوائق على طول الطريق واعتقدت شاركها هنا لأنها ربما تكون ذات صلة بصرف النظر عن النهج:

• من المهم أن يكون الإصدار etcd متوافقًا مع إصدار Kubernetes الذي تقوم بتشغيله. من ما يمكنني جمعه ، يستهدف الدليل k8s 1.9 وبالتالي يستخدم etcd v3.1.10 . بالنسبة إلى تثبيت k8s 1.8 (الذي كنت أستهدفه) ، يجب عليك استخدام v3.0.17 (باستخدام v3.1.17 تسبب في اختناق kubeadm ، وفشل استخراج الإصدار الخ. ).

• اضطررت إلى تشغيل etcd باستخدام systemd ، نظرًا لأن تشغيله كقرون ثابتة تحت /etc/kubernetes/manifests سيؤدي إلى فشل اختبارات الاختبار المبدئي kubeadm (يتوقع أن يكون هذا الدليل فارغًا).

• قبل تشغيل kubeadm init على master1 و master2 ، يجب أن تنتظر master0 لإنشاء الشهادات ، بالإضافة إلى /etc/kubernetes/pki/ca.{crt,key} ، انسخ ملفات /etc/kubernetes/pki/sa.key و /etc/kubernetes/pki/sa.pub إلى master1 و master2 (كما تم التلميح بواسطةdiscordianfish). وإلا ، فإن master1 و master2 سينشئان شهادات توقيع رمز حساب الخدمة الخاصة بهما ، الأمر الذي تسبب في حالتي في فشل kube-proxy على هؤلاء المضيفين في المصادقة ضد apiserver.

  هناك أيضًا الملفات front-proxy-ca.{crt,key} و front-proxy-client.{crt,key} التي لم أنسخها. لست متأكدًا مما إذا كان يجب نسخها من master0 أيضًا ، ولكن يبدو أن الأشياء تعمل على أي حال.

• يشجعك دليل تثبيت kubeadm "العادي" على تكوين Docker لاستخدام برنامج التشغيل systemd cgroup. بالنسبة لي ، تطلب مني ذلك أيضًا تمرير --cgroup-driver=systemd إلى kubelet عبر KUBELET_EXTRA_ARGS .

petergardfjall Ha من المضحك أن ترى كيف تواجه نفس المشكلات بالضبط. لذا ، اعتبارًا من يوم أمس ، تعمل مجموعة HA المتعددة أيضًا. واجهت https://github.com/kubernetes/kubeadm/issues/590 رغم ذلك ، هل وجدت حلاً جيدًا لذلك؟
لم يكن من الضروري استخدام إصدار خاص وما إلى ذلك. أعتقد أنني فقط أستخدم الإعدادات الافتراضية في غلاف العناصر الأساسية المستقر.
فيما يتعلق بأمور الوكيل الأمامي .. بصراحة ليس لدي أدنى فكرة عن ماهيتها.

discordianfish : لم

api:
  advertiseAddress: <apiserver-loadbalancer-ip>

ويبدو أنه تم التقاطه بواسطة خريطة التكوين kube-proxy .

> kubectl get cm -n kube-system kube-proxy -o yaml
apiVersion: v1
data:
  kubeconfig.conf: |
    apiVersion: v1
    kind: Config
    clusters:
    - cluster:
        certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        server: https://<apiserver-loadbalancer-ip>:6443
      name: default

آه حسنا. حسنًا ، إنه يعمل مع IP موازن التحميل ولكنك لا تحصل على IP ثابت عند التشغيل على AWS واستخدام ELB ، لذلك تحتاج إلى استخدام اسم.

discordianfish التي أرى أنها قد تصبح مشكلة بالفعل لأنني

jamiehannaford في دليل HA تقوم بالإشارة إلى استخدام أدوات التحميل السحابية الأصلية. هل جربت ذلك؟ هل تمكنت من الالتفاف حول # 590؟

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

ولقد أطلقت لي للتو هذا: kubeadm init سيحل محل configmap و https://github.com/kubernetes/kubernetes/issues/57109 يجعل من الصعب إدراك ذلك.

لذا مما يمكنني قوله أنه لا توجد طريقة لاستخدام kubeadm الآن في إعداد متعدد الأساتذة ، دون الرجوع إلى تنفيذ alpha phases يدويًا.

دليل HA الخاص بـ jamiehannaford يخطئ هذا بشكل عام. سيكون للعنقود الذي تم إنشاؤه مثل هذا عنوان IP الخاص بشخصية رئيسية واحدة مشفرة بشكل ثابت ويفكك تلك التي تختفي.

أهلا

لقد جربت هذا قليلاً وأعتقد أن لدي إعدادًا عمليًا الآن.
إذن هذا ما فعلته:

تم إجراء التجربة على DigtialOcean بقطرات 4x 20 دولارًا (3 ماستر + عامل واحد)

أولاً ، قمت بإنشاء 3 قطرات (CoreOS مستقر):

master1: 188.166.76.108
master2: 188.166.29.53
master3: 188.166.76.133

ثم أمطر النص التالي على كل عقدة لتكوين القطع المطلوبة لاستخدام kubeadm مع CoreOS:

#!/bin/bash
set -o nounset -o errexit

RELEASE="$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)"
CNI_VERSION="v0.6.0"

mkdir -p /opt/bin
cd /opt/bin
curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
chmod +x {kubeadm,kubelet,kubectl}

mkdir -p /opt/cni/bin
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz

BRANCH="release-$(cut -f1-2 -d .<<< "${RELEASE##v}")"
cd "/etc/systemd/system/"
curl -L "https://raw.githubusercontent.com/kubernetes/kubernetes/${BRANCH}/build/debs/kubelet.service" | sed 's:/usr/bin:/opt/bin:g' > kubelet.service
mkdir -p "/etc/systemd/system/kubelet.service.d"
cd "/etc/systemd/system/kubelet.service.d"
curl -L "https://raw.githubusercontent.com/kubernetes/kubernetes/${BRANCH}/build/debs/10-kubeadm.conf" | sed 's:/usr/bin:/opt/bin:g' > 10-kubeadm.conf

إنشاء المعلم الأولي:

core@master-01 ~ $ sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-cert-extra-sans="127.0.0.1,188.166.76.108,188.166.29.53,188.166.76.133"
[...]
  kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
[...]
core@master-01 ~ $ sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf apply -f https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml
core@master-01 ~ $ sudo systemctl enable kubelet docker

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

core@master-01 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# add --listen-peer-urls=http://0.0.0.0:2380 as a command arg
core@master-01 ~ $ sudo systemctl restart kubelet # for some reason, kubelet does not pick up the change

قم بتغيير عنوان url الافتراضي لعضو etcd إلى IPv4 ip العام:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member list
8e9e05c52164694d, started, default, http://localhost:2380, http://127.0.0.1:2379

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member update 8e9e05c52164694d --peer-urls="http://188.166.76.108:2380"

الآن انسخ جميع ملفات kubernetes (manifests / pki) إلى العقد الرئيسية الأخرى:

$ eval $(ssh-agent)
$ ssh-add <path to ssh key>
$ ssh -A [email protected] # master-02
core@master-02 ~ $ sudo -E rsync -aP --rsync-path="sudo rsync" [email protected]:/etc/kubernetes/ /etc/kubernetes
$ ssh -A [email protected] # master-03
core@master-03 ~ $ sudo -E rsync -aP --rsync-path="sudo rsync" [email protected]:/etc/kubernetes/ /etc/kubernetes

أضف master-02 إلى المجموعة etcd:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member add member-02 --peer-urls="http://188.166.29.53:2380"
Member  b52af82cbbc8f30 added to cluster cdf818194e3a8c32

ETCD_NAME="member-02"
ETCD_INITIAL_CLUSTER="member-02=http://188.166.29.53:2380,default=http://188.166.76.108:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

$ ssh [email protected] # master-02
core@master-02 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# Add the following as args:
--name=member-02
--initial-cluster=member-02=http://188.166.29.53:2380,default=http://188.166.76.108:2380
--initial-cluster-state=existing
core@master-02 ~ $ sudo systemctl restart kubelet

أضف master-03 إلى مجموعة etcd:

core@master-01 ~ $ ETCDCTL_API=3 etcdctl member add master-03 --peer-urls="http://188.166.76.133:2380"
Member 874cba873a1f1e81 added to cluster cdf818194e3a8c32

ETCD_NAME="master-03"
ETCD_INITIAL_CLUSTER="member-02=http://188.166.29.53:2380,master-03=http://188.166.76.133:2380,default=http://188.166.76.108:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

$ ssh [email protected] # master-03
core@master-03 ~ $ sudo vi /etc/kubernetes/manifests/etcd.yaml
# Add the following as args:
--name=master-03
--initial-cluster=member-02=http://188.166.29.53:2380,master-03=http://188.166.76.133:2380,default=http://188.166.76.108:2380
--initial-cluster-state=existing
core@master-03 ~ $ sudo systemctl start kubelet

لذلك يجب أن يكون لدينا الآن مجموعة ثلاثية العقد وما إلى ذلك.

الآن يسمح لـ master-02 و master-03 بالانضمام إلى مجموعة k8s:

$ ssh [email protected] # master-02
core@master-02 ~ $ sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf
core@master-02 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
$ ssh [email protected] # master-03
core@master-03 ~ $ sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf
core@master-03 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 188.166.76.108:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a

قم بتمييزهم على أنهم سادة:

core@master-01 ~ $ sudo kubeadm alpha phase mark-master --node-name master-02
core@master-01 ~ $ sudo kubeadm alpha phase mark-master --node-name master-03

قم بتغيير kubelet و kube-Scheduler و kube-controller-manager لاستخدام apiserver المحلي بدلاً من master-01 apiserver:

core@master-01 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}
core@master-02 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}
core@master-03 ~ $ sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{scheduler.conf,kubelet.conf,controller-manager.conf}

قم بتغيير ملف yaml kube-apiserver للإعلان عن IP الصحيح والتحقق من صحة IP:

core@master-02 ~ $ sudo sed 's/188.166.76.108/188.166.29.53/g' -i /etc/kubernetes/manifests/kube-apiserver.yaml
core@master-03 ~ $ sudo sed 's/188.166.76.108/188.166.76.133/g' -i /etc/kubernetes/manifests/kube-apiserver.yaml

تفعيل kubelet و docker وإعادة التشغيل:

core@master-01 ~ $ sudo systemctl enable kubelet docker; sudo reboot
core@master-02 ~ $ sudo systemctl enable kubelet docker; sudo reboot
core@master-03 ~ $ sudo systemctl enable kubelet docker; sudo reboot

قم بتغيير kube-proxy لاستخدام apiserver على المضيف المحلي:

core@master-01 ~ $ sudo kubectl --kubeconfig=/etc/kubernetes/admin.conf -n kube-system edit configmap kube-proxy
# Change server: https://<ip>:6443 to https://127.0.0.1:6443

لنحاول الآن إضافة عقدة عاملة (قم بتشغيل البرنامج النصي في الأعلى):
عامل - 01: 178.62.216.244.001

$ ssh [email protected]
core@worker-01 ~ $ sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 6443 -j DNAT --to 188.166.76.108
core@worker-01 ~ $ sudo iptables -t nat -I POSTROUTING -o eth0 -j SNAT --to-source $(curl -s ipinfo.io | jq -r .ip)
core@worker-01 ~ $ sudo sysctl net.ipv4.conf.eth0.route_localnet=1
core@worker-01 ~ $ sudo kubeadm join --token b11224.fada30ef8a7cbd38 127.0.0.1:6443 --discovery-token-ca-cert-hash sha256:19d34ff6e69203a799ab5984a212684b3dcd446ca5e9d6f6c1a8ae422583b62a
core@worker-01 ~ $ sudo systemctl enable kubelet docker

الآن نحتاج فقط إلى إضافة موازن التحميل المحلي إلى العقدة العاملة ، ويتم كل شيء.
احفظ ما يلي باسم /etc/nginx/nginx.conf على عقدة worker-01:

error_log stderr notice;

worker_processes auto;
events {
    use epoll;
    worker_connections 1024;
}

stream {
    upstream kube_apiserver {
        least_conn;
        server 188.166.76.108:6443 max_fails=3 fail_timeout=30s;
        server 188.166.29.53:6443 max_fails=3 fail_timeout=30s;
        server 188.166.76.133:6443 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 127.0.0.1:6443 reuseport;
        proxy_pass kube_apiserver;
        proxy_timeout 10m;
        proxy_connect_timeout 1s;

    }
}

أنشئ /etc/kubernetes/manifests

core@worker-01 ~ $ sudo mkdir /etc/kubernetes/manifests

أضف بيانًا ثابتًا nginx-proxy مثل /etc/kubernetes/manifests/nginx-proxy.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: nginx-proxy
  namespace: kube-system
  labels:
    k8s-app: kube-nginx
spec:
  hostNetwork: true
  containers:
  - name: nginx-proxy
    image: nginx:1.13-alpine
    imagePullPolicy: Always
    resources:
      limits:
        cpu: 200m
        memory: 128M
      requests:
        cpu: 50m
        memory: 32M
    volumeMounts:
    - mountPath: /etc/nginx
      name: etc-nginx
      readOnly: true
  volumes:
  - name: etc-nginx
    hostPath:
      path: /etc/nginx

يجب أن تختفي إعادة تشغيل العقدة وقواعد iptables المؤقتة ، ويجب أن يعمل كل شيء كما هو متوقع.

منشور طويل ، لكنه يُظهر أنه قابل للتنفيذ :)

تحرير: نسيت تغيير خادم API للعقدة العاملة: sudo sed 's/188.166.76.108/127.0.0.1/g' -i /etc/kubernetes/{bootstrap-kubelet.conf,kubelet.conf}
Edit2: يجب أيضًا تغيير kubectl --kubeconfig=admin.conf -n kube-public get configmap cluster-info

klausenbusk عظيم: تادا :! إذا كنت ترغب في حمل / تحسين https://github.com/kubernetes/website/pull/6458 ، فلا تتردد في إرسال jamiehannaford الذي هو في إجازة في الوقت الحالي.

@ klausenbusk ، في برنامج Master-02 و master-03 ، لا أفهم كيف تمكنت من الانضمام؟ نظرًا لأن دليل / etc / kubernetes ليس فارغًا. هل يمكنك توضيح ما إذا كانت هناك خطوة مفقودة؟
شكرا.

@ klausenbusk ، في برنامج Master-02 و master-03 ، لا أفهم كيف تمكنت من الانضمام؟ نظرًا لأن دليل / etc / kubernetes ليس فارغًا. هل يمكنك توضيح ما إذا كانت هناك خطوة مفقودة؟

لقد قمت بإزالة sudo rm /etc/kubernetes/pki/ca.crt /etc/kubernetes/kubelet.conf كما هو موثق ، ولم تكن هناك حاجة لإزالة الدليل بالكامل.

إلى discordianfish والآخرين الذين يرغبون في تشغيل إعداد HA على AWS.

لقد تمكنت من الحصول على إعداد HA للعمل مع ELB من Amazon (على الرغم من عدم وجود عنوان IP ثابت واحد).

لتشغيله ، يجب اتباع الخطوات التالية (بالإضافة إلى

• نظرًا لأن ELB لا يحتوي على عنوان IP ثابت ، فلا يمكننا استخدام ذلك كعنوان إعلان apiserver. بدلاً من ذلك ، نسمح لكل معلم بالإعلان عن عنوان IP الخاص به.

  يبدو أن الجانب السلبي لهذا النهج هو أن النوادل سوف "تتقاتل" على سجل نقطة النهاية ، وتعيد كتابتها بين الحين والآخر (كما يمكن رؤيته من خلال kubectl get endpoints ) والذي بدوره له عواقب على kube- الوكيل ، والذي سيعيد كتابة iptables الخاص به كلما تم اكتشاف تغيير.

  لا يبدو أن هذا يضر بصحة Kubernetes ، لكن أعتقد أنه يمكن أن يؤدي إلى بعض تدهور الأداء في مجموعات كبيرة. أي أفكار؟

  تتم مناقشة القضية بمزيد من التفصيل هنا .

• تحتاج جميع الكوبيليتات العاملة ووكلاء kube إلى الوصول إلى خوادم API عبر موازين التحميل FQDN. نظرًا لأن kubeadm لا يسمح لنا بتحديد خوادم مختلفة لـ kube-proxy و kubelets العامل (سيستخدمون ببساطة عنوان IP الخاص بخادم Apiserver الذي حدث للاتصال به على kubeadm join )
  نحن بحاجة إلى الاهتمام بهذا بأنفسنا.

  • يتم تخزين التكوين kube-proxy كخريطة تكوين ، والتي يتم استبدالها في كل مرة يتم فيها تشغيل kubeadm init (مرة واحدة لكل عقدة رئيسية). لذلك ، لكل kubeadm init نحتاج إلى تصحيح ملف configmap على النحو التالي:

    kubectl الحصول على configmap -n kube-system kube-proxy -o yaml> kube-proxy.cm
    sudo sed -i 's # server :. * # الخادم: https: //: 6443 # g 'kube-proxy.cm
    kubectl تطبيق -f kube-proxy.cm --force

    أعد تشغيل جميع حاضنات kube-proxy للتأكد من أنها تقوم بتحميل خريطة التكوين الجديدة

    kubectl delete pod -n kube-system -l k8s-app = kube-proxy

  • في كل عامل نحتاج إلى تصحيح التكوين kubelet بعد الانضمام ، بحيث يتصل kubelet عبر موازن التحميل.

    sudo kubeadm انضم --config = kubeadm-config.yaml

    قد لا يكون /etc/kubernetes/kubelet.conf موجودًا على الفور

    wait_for 60 [-f /etc/kubernetes/kubelet.conf]
    sudo sed -i 's # server :. * # الخادم: https: //: 6443 # g '/etc/kubernetes/kubelet.conf
    sudo systemctl إعادة تشغيل kubelet

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

لا يبدو أن هذا يضر بصحة Kubernetes ، لكن أعتقد أنه يمكن أن يؤدي إلى بعض تدهور الأداء في مجموعات كبيرة. أي أفكار؟

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

نصيحة ممتازة @ klausenbusk. هذا يعمل كالسحر.

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

سيستخدمون ببساطة عنوان IP الخاص بخادم Apiserver الذي حدث للاتصال به عند kubeadm Join

ماذا يحدث إذا قمت بعمل kubeadm join باستخدام IP الخاص بـ LB؟

من حيث kubelet ، أعتقد أن هذا تعديل يدوي ضروري. تحتاج إلى إضافة إلى دليل HA.

jamiehannaford تكمن المشكلة عند استخدام ELB من Amazon في أنه لا يوفر عنوان IP ثابتًا واحدًا ، لذلك لا يوجد عنوان IP LB يمكنني الاستفادة منه (راجع https://stackoverflow.com/a/35317682/7131191 ).

حتى الآن ، ينضم العمال عبر FQDN الخاص بـ ELB ، والذي سيعيد توجيهه إلى أحد الخوادم ، والتي ، منذ أن تعلن عن عنوان IP الخاص بها ، تجعل العامل يقوم بتكوين kubelet الخاص به لاستخدام عنوان IP هذا (وليس ELB FQDN). لذلك ، للتأكد من أن kubelet يمر عبر موازن تحميل apiserver ، يجب تصحيح kubelet.conf بعد ذلك باستخدام ELB FQDN وإعادة تشغيل kubelet.

لقد فتحت للتو طعنة مصدرها على HA kubeadm. يأتي مع بعض التحذيرات والحل البديل القبيح (خاصة أن اختراق وكيل kube قبيح). لكنها تعمل: https://github.com/itskoko/kubecfn

لقد قمت ببعض العمل في دليل إعداد HA على مستندات Google :

• تولى بعض التغييرات المقترحة في التعليقات
• دعم المكون الإضافي لشبكة "كاليكو"
• تولى إعداد SSL _etcd_ من مستند الدليل الرسمي الذي كتبه jamiehannaford

تم تنفيذ هذه التغييرات في أتمتة العملية الموصوفة الخاصة بي ، بالإضافة إلى المزيد:

• الإعداد التلقائي لمشغل etcd للتطبيقات التي تعمل في الكتلة (وليس الكتلة نفسها)
• الجلب المسبق للصور اللازمة لتشغيل Kubernetes ونسخها إلى مضيفات المجموعة
• إعداد لوحة المعلومات (غير آمن ، بدون SSL) مع المنفذ 30990 على NodePort (إذا لم يتم تكوين LB)

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

إنه نص برمجي من نوع Python يتم تنفيذه على مرحلتين: render الذي ينشئ "أصول مجمعة" في شكل مفاتيح SSH ، وشهادات ، وسكربتات جزئية ، وطور install الذي ينفذ تلك البرامج النصية عبر SSH.

تمت تجربة البرامج النصية على مجموعة Vagrant المحلية وضد AWS. يتم تضمين "نصين برمجيين لمزودي البنية التحتية" في الريبو (المتشرد و AWS عبر Terraform) لتوفير موازن أحمال الكتلة والأجهزة الافتراضية الضرورية.

لا تتردد في تجربته. https://github.com/elastisys/hakube-installer

لم أجد بعد طريقة لترقية مجموعة HA مثبتة باستخدام kubeadm والخطوات اليدوية الموضحة في دليل إعداد HA الخاص بي

ما جربته حتى الآن هو ما يلي:

1. قم بإيقاف تشغيل Keepalived على الماجستير الثانوي ، وقم بتشغيل kubeadm Upgrade على الرئيسي الأساسي ، وقم بتطبيق نفس التغييرات في / etc / kubernetes / manifests على الأسياد الثانوية كما كانت موجودة في الماجستير الأساسي وابدأ في البقاء على قيد الحياة على الماجستير الثانوي.
2. تمامًا مثل (1) ، ولكن بالإضافة إلى الحفاظ على الحياة ، أغلق أيضًا (وبدء لاحقًا) kubelet و docker على الماجستير الثانوي.
3. تمامًا مثل (2) ، ولكن قبل تطبيق الترقية على البرنامج الرئيسي الأساسي ، قم بتطويق جميع الماجستير الثانوي (وبعد ذلك unordon).

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

Unable to register node "master-2.mylan.local" with API server: nodes "master-2.mylan.local" is forbidden: node "master-1.mylan.local" cannot modify node "master-2.mylan.local"

Failed to update status for pod "kube-apiserver-master-2.mylan.local_kube-system(6d84ab47-0008-11e8-a558-0050568a9775)": pods "kube-apiserver-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-controller-manager-master-2.mylan.local_kube-system(665da2db-0008-11e8-a558-0050568a9775)": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-scheduler-master-2.mylan.local_kube-system(65c6a0b3-0008-11e8-a558-0050568a9775)": pods "kube-scheduler-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-flannel-ds-ch8gq_kube-system(47cccaea-0008-11e8-b5b5-0050568a9e45)": pods "kube-flannel-ds-ch8gq" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Failed to update status for pod "kube-proxy-htzg7_kube-system(47cc9d00-0008-11e8-b5b5-0050568a9e45)": pods "kube-proxy-htzg7" is forbidden: node "master-1.mylan.local" can only update pod status for pods with spec.nodeName set to itself

Deleting mirror pod "kube-controller-manager-master-2.mylan.local_kube-system(665da2db-0008-11e8-a558-0050568a9775)" because it is outdated

Failed deleting a mirror pod "kube-controller-manager-master-2.mylan.local_kube-system": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only delete pods with spec.nodeName set to itself

Failed creating a mirror pod for "kube-controller-manager-master-2.mylan.local_kube-system(78432ebfe5d8dfbb93f8173decf3447e)": pods "kube-controller-manager-master-2.mylan.local" is forbidden: node "master-1.mylan.local" can only create pods with spec.nodeName set to itself

[... and so forth, repeats itself ...]

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

mbert يبدو هذا وكأنه مشكلة RBAC. هل تأكدت من تطابق اسم العقدة مع تجاوز اسم المضيف ؟

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

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

سأعطي تعيين تجاوز اسم المضيف لـ kubelet لقطة ومعرفة ما إذا كان هذا يؤدي إلى أي نتيجة أخرى.

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

مرحبًا mbert وآخرون - من العام الماضي أو نحو ذلك ، لدي عدة مجموعات k8s (kubeadm وغير ذلك) مدفوعة من Cobbler / Puppet على CoreOS و CentOS. ومع ذلك ، لم يكن أي من هؤلاء HA.

مهمتي التالية هي دمج K8s HA وأريد استخدام kubeadm. أنا غير متأكد ما إذا كان الذهاب معmbert الصورة دليل الإعداد HA أوjamiehannaford الصورة دليل HA .

أيضا - وهذا الصباح وأنا أقرأtimothysc الصورة مقترح لتكوين طائرة مراقبة متاح للغاية ل"نشر kubeadm. وأنا أحب نهج "البذور الأولية إلخ" الذي يحدده. ومع ذلك ، لا أرى نفس النهج في عمل mbert أو jamiehannaford . mbert يبدو أن استخدام واحد، etcd استضافت k8s بينماjamiehannaford الصورة الوثائق وثيقة النهج الكلاسيكي etcd الخارجي (والذي هو بالضبط ما كنت قد استخدمت لجهودي غير HA POC أخرى).

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

TIA!

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

andybrucenet ليس تمامًا - أنا أستخدم مجموعة خارجية وما إلى ذلك تمامًا مثلما يقترح jamiehannaford في دليله. في الواقع ، يجب أن تكون الأساليب الموضحة في وثائقنا متشابهة إلى حد ما. يعتمد على إعداد مجموعة etcd التي تشعر أنك بحاجة إليها ثم استخدمها kubeadm عند تمهيد مجموعة Kubernetes.

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

لست متأكدًا تمامًا مما إذا كانت هناك حاجة إلى مزيد من نقل دليلي إلى دليلك ،

في الواقع ، لم يكن تجاوز اسم المضيف ضروريًا. عند تشغيل kubeadm upgrade apply ، تقوم بعض الإعدادات الافتراضية بالكتابة فوق تعديلاتي ، على سبيل المثال NodeRestriction يتم إعادة تنشيطها (يتم أيضًا إعادة تعيين مقياس _Kube DNS_ ، ولكن هذا بالطبع لم يكن إيقاف عرض هنا). أدى تصحيح قاعدة القبول NodeRestriction من _ / etc / kubernetes / manifests / kube-apiserver.yaml_ إلى تنفيذ الحيلة.

لقد قمت الآن بكتابة فصل حول ترقية مجموعات HA إلى دليل إعداد HA الخاص بي.

لقد أضفت أيضًا رمزًا لأتمتة هذه العملية إلى مشروعي الثابت على جيثب . ألق نظرة على ملف README.md هناك لمزيد من المعلومات.

mbert لعملية الترقية التي حددتها ، ما هي الأسباب الدقيقة لنسخ التكوينات والبيان يدويًا من /etc/kubernetes على المعلم الأساسي إلى الماجستير الثانوي بدلاً من مجرد تشغيل kubeadm upgrade apply <version> على الماجستير الثانوية كذلك؟

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

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

FWIW ، تشغيل kubeadm على الماجستير الثانوي يبدو أنه عمل جيدًا بالنسبة لي (بما في ذلك الترقية) - لكني بحاجة إلى فهم المخاطر الدقيقة بشكل أفضل في كل مرحلة. لقد كنت أتبع دليل تشغيله تلقائيًا بواسطة hakube-installerpetergardfjall (لا يوجد دعم ترقية حتى الآن ، لذلك اختبرت ذلك يدويًا).

تحرير: من المهم أيضًا ملاحظة أنني أختبر فقط على الإصدار 1.9 +. كانت الترقية من v1.9.0 إلى v1.9.2.

لقد اتبعت الآن الدليل الموجود على kubernetes.io الذي أنشأه jamiehannaford ، أي تشغيل kubeadm init على جميع الأجهزة الرئيسية (بعد نسخ /etc/kubernetes/pki/ca.* إلى الماجستير الثانوي). هذا يعمل بشكل جيد لإنشاء الكتلة. لكي أتمكن من الترقية إلى الإصدار 1.9.2 ، أقوم بإعداد v1.8.3 هنا.

الآن أواجه مشكلة عند محاولة ترقية الكتلة: فشل تشغيل kubeadm upgrade apply v1.9.2 على أول سيد:

[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests872757515/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/tmp/kubeadm-upgraded-manifests872757515/kube-scheduler.yaml"
[upgrade/staticpods] Moved new manifest to "/etc/kubernetes/manifests/kube-apiserver.yaml" and backed up old manifest to "/etc/kubernetes/tmp/kubeadm-backup-manifests647361774/kube-apiserver.yaml"
[upgrade/staticpods] Waiting for the kubelet to restart the component
[upgrade/apply] FATAL: couldn't upgrade control plane. kubeadm has tried to recover everything into the earlier state. Errors faced: [timed out waiting for the condition]

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

لقد جربت العديد من الأشكال ، لكن لم تنجح:

• اجعل kubelet يستخدم مثيل خادم API المحلي أو المثال المشار إليه بواسطة IP الظاهري
• لديك kube-proxy يستخدم مثيل خادم API المحلي أو المثيل المشار إليه بواسطة IP الظاهري

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

فشل ترقية الوكيل على vip.log
ترقية فشل الوكيل و kubelet على vip.log
فشل الترقية الوكيل و kubelet على local-ip.log

بعد تجربة بعض الأشياء الأخرى ، يتلخص الأمر في ما يلي:

• يعمل التحديث الرئيسي الذي تم إعداده مؤخرًا (أي الذي تم تشغيل kubeadm init عليه مؤخرًا عند إعداد الكتلة).
• يمكنني تشغيل العقد الأخرى أيضًا ، إذا قمت بتحرير configmap/kubeadm-config وقمت بتغيير قيمة MasterConfiguration.nodeName هناك إلى اسم المضيف الرئيسي المعني أو قمت ببساطة بحذف هذا السطر.

تمكن آخرون مثل mattkelly من إجراء الترقية دون تعديل configmap/kubeadm-config ، ومن ثم يجب أن تكون طريقة إعداد الأشياء مختلفة إلى حد ما.

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

لقد حاولت الترقية من 1.8.3 و 1.9.0 إلى 1.9.2 ، مع نفس النتيجة.

mbert أنا الآن أعيد إنتاج مشكلتك من مجموعة v1.9.0 حديثة تم إنشاؤها باستخدام hakube-installer . محاولة الترقية إلى v1.9.3. لا يمكنني التفكير في أي شيء تغير مع سير العمل الخاص بي. سأحاول معرفة ذلك اليوم.

لقد تحققت من أن حذف السطر nodeName من configmap/kubeadm-config لكل إصلاح لاحق لهذه المشكلة.

شكرا لك ، هذا مفيد جدا. لقد قمت الآن بإضافة التصحيح configmap/kubeadm-config إلى تعليماتي.

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

أهلا،
هل سيقوم kubeadm 1.10 بإزالة أي من الخطوات المسبقة / الحلول المطلوبة حاليًا لـ HA في 1.9؟
على سبيل المثال ، الإنشاء اليدوي لـ bootstrap وما إلى ذلك ، وإنشاء مفاتيح etcd ، إلخ

إغلاق هذا العنصر عند 1.10 مستند وسننتقل إلى مزيد من قصة HA في 1.11

/ cc fabriziopandini