Kubernetes: ناقش كيف يجب أن يعالج kubeadm init الملف الذي تم الخروج منه بالفعل

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

خلال كل جولة تالية (الهدف هو جعلها غير فعالة):

• بيانات البود الثابتة : ما فعلته هو إلقاء نظرة على الأصول التي تم إنشاؤها حديثًا إذا تغيرت بعض / جميع البيانات بسبب قيام المستخدم بتوفير تكوينات جديدة ، فإننا نطالب المستخدم إذا كان يرغب في الكتابة فوقها.
• أصول PKI : صعبة. إذا لم يتغير شيء ، فلن نحتاج إلى فعل أي شيء ويمكننا فقط تحليل القيم ومحاولة الاتصال بخادم api والسماح لـ kubeadm بإنهاء تشغيله. إذا قام المستخدم بإنشاء أصول pki جديدة وأراد استخدامها ، فسيلزم إيقاف نظام kubelet الجديد من Confs وما إلى ذلك ... وبدء kubelet مرة أخرى.

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

حسنًا ، لذلك قررنا طلب kubeadm reset بين عمليتي تشغيل kubeadm init/join مع اختبارات الاختبار المبدئي. قد لا تكون الملفات التي ينشئها kubeadm موجودة مسبقًا

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