<p>تجديد شهادات مرحلة ألفا kubeadm يجب أيضًا تحديث جميع الشهادات في ملفات KubeConfig</p>

تضمين التغريدة
بالطبع ، لكن يرجى ملاحظة أن مراحل الانضمام لها أولوية عالية.

يبدو جيدا! شكر كثيرا.

أهلا،

هناك شيء آخر بخصوص هذا الموضوع.

kubeadm alpha phase kubeconfig all هذه الرسالة إذا كانت ملفات conf في مكانها عند إصدار الأمر:

[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/admin.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Using existing up-to-date KubeConfig file: "/etc/kubernetes/scheduler.conf"

إنه لا يتحقق مما إذا كانت الشهادات منتهية الصلاحية ، لذا في رأيي ، فإن up-to-date يعد أمرًا خاطئًا.

للحصول على الشهادات المحدثة في الملفات ، يجب على المرء أن يزيل الملفات مقدمًا ، بحيث يبدو السجل كما يلي:

[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"   

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

مع أطيب التحيات
أندرياس

مخصص لـ

MalloZup : لم يسمح لي GitHub بتعيين المستخدمين التاليين: MalloZup.

لاحظ أنه لا يمكن تعيين سوى أعضاء kubernetes والمتعاونين مع الريبو وأن المشكلات / العلاقات العامة لا يمكن أن يكون لها سوى 10 معينين في نفس الوقت.
لمزيد من المعلومات يرجى الاطلاع على دليل المساهم

مرحبا adoerler تشك لهذه القضية. فيما يتعلق بالمعلومات المضللة ، فقد قمت بإرسال رسالة علاقات عامة https://github.com/kubernetes/kubernetes/pull/73798.

سألقي نظرة على بقية المشكلة بمجرد توفر الوقت. تشك للوقت ودقة القضية

adoerler لقد أرسلت DOC pr
(https://github.com/kubernetes/website/pull/12579)

مرحبًا MalloZup ،

شكرا للعلاقات العامة!

فقدت جملة حول ملفات kubeconfig ، لأن certs renew هو جزء واحد فقط من اللعبة.
شيء مثل:

بعد تجديد الشهادات ، لا تنس إعادة إنشاء ملفات KubeConfig باستخدام kubeadm alpha phase kubeconfig ...

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

MalloZup ليس لدي معرفة عميقة بكيفية عمل تجديد الشهادات.

أنا شخصياً أود أن أوضح قليلاً التاريخ العام قبل اتخاذ الإجراءات - بما في ذلك ما تم اقتراحه أعلاه -:

• ما يجب إدارته بواسطة kubeadm alpha phase certs renew
• ما يجب إدارته تلقائيًا خلال kubeadm upgrade
• ما يجب توثيقه (وتدبيره من قبل المستخدمين)
• كيف ينطبق هذا على مجموعات HA
• كيف يتأثر ذلك بمتغيرات المجموعة (مثل الخارجية وما إلى ذلك ، المرجع المصدق الخارجي)
• إلخ.

لكني أترك الكلمة الأخيرة لأشخاص أكثر مهارة مني في هذا المجال

أعتقد أنه يجب علينا تخصيص وقت للاجتماع لمناقشة سياسة تجديد الشهادات التي نوصي بها. قد تحتاج الصفحة الخاصة بإدارة الشهادات إلى بعض التفاصيل الإضافية:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs

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

ما يفعله المستخدمون هو اكتشاف الأشياء بأنفسهم:
https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139
^ يحتوي هذا التعليق والتعليق أعلاه على أدلة من صنع المستخدم.

هذه علامة على أننا بحاجة إلى إضافة دليل رسمي.
تضمين التغريدة

/ إسناد ereslibre

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

@ dimm0

ما يفعله المستخدمون هو اكتشاف الأشياء بأنفسهم:
# 581 (تعليق)
^ يحتوي هذا التعليق والتعليق أعلاه على أدلة من صنع المستخدم.

هذه هي الأدلة الوحيدة التي لدينا أجهزة الصراف الآلي.

[root<strong i="5">@controller0</strong> ~]# kubeadm alpha phase certs apiserver --apiserver-advertise-address 1.2.3.4
Error: unknown flag: --apiserver-advertise-address
Usage:

Flags:
  -h, --help   help for phase

Global Flags:
      --log-file string   If non-empty, use this log file
      --rootfs string     [EXPERIMENTAL] The path to the 'real' host root filesystem.
      --skip-headers      If true, avoid header prefixes in the log messages
  -v, --v Level           log level for V logs

error: unknown flag: --apiserver-advertise-address
[root<strong i="6">@controller0</strong> ~]# kubeadm alpha phase certs apiserver
This command is not meant to be run on its own. See list of available subcommands.

في 1.13 ، انتقلت مراحل init إلى أمر init الأصل:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd -phase-certs

في 1.12 يجب أن يكون العلم موجودًا:
https://v1-12.docs.kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd -phase-certs

1.11 يخرج قريبًا من الدعم.

إزالة دورة الحياة / التسمية النشطة.
الانتقال إلى 1.15.

أفكار محتملة لتحديث المستندات هنا:
https://github.com/kubernetes/kubeadm/issues/1361#issuecomment -463192631

ههههههههههه
السؤال: في 1.14 مع Master HA ، هل يكفي اتباع https://github.com/kubernetes/kubeadm/issues/581#issuecomment -421477139 على سيد واحد ، أم يتعين علينا إعادة الانضمام إلى الماجستير الثانوي مرة أخرى من أجل إعادة إحضار الشهادات؟

إعادة الانضمام إلى عقد مستوى التحكم الثانوية ، يبدو كخيار سريع وقابل للتطبيق في 1،14.
ليس لدينا أي مستندات حتى الآن فيما يتعلق بتناوب شهادات HA.
(ناهيك عن أننا لم نضيف بعد خطوات مناسبة مثل https://github.com/kubernetes/kubeadm/issues/581#issuecomment-421477139 فعل).

ألا توفر شهادات التحميل التجريبية أساسًا لحل أسهل لتناوب الشهادة في HA؟

طريقة واحدة للقيام بتناوب شهادة HA هي:

• على عقدة مستوى تحكم واحدة ، اتبع الخطوات المذكورة أعلاه لتحديث شهاداتها
• على نفس استدعاء عقدة CP:

kubeadm init phase upload-certs --experimental-upload-certs

تخزين مفتاح الشهادات.

kubeadm token create --print-join-command

تخزين أمر الانضمام مع الرمز المميز.

أعد الانضمام إلى بقية عقد مستوى التحكم باستخدام الرمز المميز ومفتاح الشهادات ، واحدًا تلو الآخر باستخدام --certs-key .... --experimental-control-plane-join

للعمال: استنزف ، انضم مرة أخرى باستخدام الرمز الجديد ، unordon ، واحدًا تلو الآخر.

اختياريا حذف الرموز الناتجة.

ههههههههههه
في 3 مجموعات رئيسية ، في اللحظة التي نغير فيها الشهادات على المعلم الرئيسي "الأساسي" ، سيتوقف إلخ عن العمل ، حيث يتم تغيير الشهادات (ويجب ألا يقل النصاب عن 51٪)؟ إذا كان الأمر كذلك ، فربما يتعين علينا بطريقة ما تطويق السادة الثانوية 2 وبعد ذلك فقط تغيير الشهادات؟ هل "كوردون ماستر" ممكن؟

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

تتعامل شهادات النسخ التلقائية مع CA و front-proxy-CA و etcd-CA (مع 10 سنوات من TTL) ومفتاح SA (بدون TTL)

يلامس أمر تجديد الشهادة جميع الشهادات الأخرى (مع مدة البقاء لمدة عام واحد) ، والتي تختلف عبر الشهادات الرئيسية.
AFAIK ، حاليًا لا يوجد شيء يعالج تجديد الشهادات لملفات kubeconfig

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

/تعيين
/ دورة الحياة نشطة

لقد بدأت العمل على هذه المسألة.
هناك نقاط مختلفة يجب معالجتها (_محدّث 14 مايو 2019_)

• حتى مع تمكين تدوير الشهادة ، يشير kubelet.conf إلى شهادات قديمة (تم تتبعها بالفعل من خلال https://github.com/kubernetes/kubeadm/issues/1317)
• لا يقوم تدوير الشهادة بتحديث شهادات apiserver / etcd / front-proxy-client (تم إصلاحها بواسطة https://github.com/kubernetes/kubernetes/pull/76862)
• لا تقوم شهادات مرحلة ألفا Command kubeadm بتجديد الكل بتحديث ملفات KubeConfig (تم إصلاحها بواسطة https://github.com/kubernetes/kubernetes/pull/77180)
• وثائق حول تجديد الشهادات (مع مزيد من التفاصيل حول مكان تشغيل الأمر ، متى ، kubeconfig ، HA)

وسأعالجهم جميعًا في علاقات عامة منفصلة

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

@ tushar00jain يتم تتبع دوران CA cert في مشكلة أخرى https://github.com/kubernetes/kubeadm/issues/1350
تركز هذه المشكلة على الشهادات الموقعة فقط

fabriziopandini كنت أبحث عن إغلاق هذه التذكرة اليوم حيث كنت قادرًا على إرسال

حتى مع تمكين تدوير الشهادة ، يشير kubelet.conf إلى شهادات قديمة (تم تتبعها بالفعل بواسطة # 1317)

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

لا يُحدِّث "تدوير الشهادة" شهادات العميل apiserver / etcd / front-proxy-client (تم إصلاحها بواسطة kubernetes / kubernetes # 76862)

لا تقوم شهادات مرحلة ألفا Command kubeadm بتجديد الكل بتحديث ملفات KubeConfig (تم إصلاحها بواسطة kubernetes / kubernetes # 77180)

وثائق حول تجديد الشهادات (مع مزيد من التفاصيل حول مكان تشغيل الأمر ، متى ، kubeconfig ، HA)

3 أعلاه ينبغي أن يتم.

/قريب
حسب التعليق أعلاه ، تم الانتهاء بالفعل من معظم العمل ؛ يتم تعقب البت المفقود في قضية منفصلة / مخصصة

fabriziopandini : إغلاق هذه القضية.

هل يمكن لأي شخص أن يشرح لي كيف تم معالجة الجزء "حتى مع تمكين تدوير الشهادة ، يشير kubelet.conf إلى شهادات قديمة"؟ المشكلة الوحيدة المرتبطة التي تشير إلى إغلاقها صراحةً لصالح مشكلات أخرى تم إغلاقها بعبارة "لست متأكدًا مما إذا كانت هذه مشكلة ، فافتح بطاقة جديدة إذا كانت كذلك".
أنا في 1.16 لا أرى أي تجديد يحدث عند kubelet.conf مع sudo kubeadm alpha certs renew all . ما المفقود؟ ههههههههههه

خلاصة سريعة لمناقشة طويلة جدًا.

1. يتم الآن إدارة تدوير الشهادة لجميع الشهادات ولكن kubelet.conf بواسطة تجديد kubeadm alpha cert.
2. ستتم إدارة تدوير الشهادة لـ kubelet.conf بواسطة kubelet نفسها (ما لم يخرج المستخدم من التدوير التلقائي للشهادة)

هذه النقطة الثانية تعمل بالفعل اعتبارًا من اليوم لجميع العقد باستثناء تلك التي تقوم فيها بتشغيل kubeadm init؛ https://github.com/kubernetes/kubernetes/pull/84118 سيصلح ذلك

fabriziopandini شكرا لك على هذا ، فمن المنطقي.

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

https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#check -certificate-expiration

في العقد التي تم إنشاؤها باستخدام kubeadm init ، قبل إصدار kubeadm 1.17 ، يوجد خطأ حيث يتعين عليك تعديل محتويات kubelet.conf يدويًا. بعد انتهاء kubeadm init ، يجب عليك تحديث kubelet.conf للإشارة إلى شهادات عميل kubelet التي تم تدويرها ، عن طريق استبدال بيانات شهادة العميل وبيانات مفتاح العميل بـ:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

AndrewSav شكرا لك على هذا. لقد استخدمت عامل بروميثيس لمراقبة الكتلة. لقد تلقيت مؤخرًا تنبيهًا مفاده "تنتهي صلاحية شهادة Kubernetes API في أقل من 7 أيام" ، وأعتقد أنه مرتبط بهذه المشكلة. لقد قمت بتحديث محتوى kubelet.conf على العقد الرئيسية. لكن ما زلت أتلقى التنبيه. هل لديك اي اقتراحات؟ تكس.

tannh إذا قمت بتثبيت الكتلة باستخدام kubeadm ، فاستخدم kubeadm للتحقق من تجربة الشهادات. وإلا فإن مشكلتك ربما لا تكون ذات صلة.

في العقد التي تم إنشاؤها باستخدام kubeadm init ، قبل إصدار kubeadm 1.17 ، يوجد خطأ حيث يتعين عليك تعديل محتويات kubelet.conf يدويًا. بعد انتهاء kubeadm init ، يجب عليك تحديث kubelet.conf للإشارة إلى شهادات عميل kubelet التي تم تدويرها ، عن طريق استبدال بيانات شهادة العميل وبيانات مفتاح العميل بـ:

سيكون هذا أيضًا في ملاحظات إصدار 1.17.

adoerler ما زلت أستخدم إصدارًا قديمًا من kubeadm ، كيف يمكنني تحديث kubelet.conf ، admin.con ، ... إلخ ، بعد تجديد الشهادة؟

قمت بتشغيل "kubeadm alpha certs Renew all" ، والذي أدى إلى إنشاء شهادات جديدة ، ثم أحتاج إلى تعديل جميع ملفات .conf ضمن / etc / kubernetes ، كيف؟ أين يجب أن يشيروا بالضبط؟
وفي حالة العقد الرئيسية المتعددة ، هل يجب تشغيل الأمر في جميع البرامج الرئيسية؟

مرحبا SuleimanWA ،

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

هذا ما فعلته:

بادئ ذي بدء ، تأكد من نقل ملفات conf الموجودة بعيدًا عن الطريق ، لأنه لن يتم الكتابة فوق الملفات الموجودة!

mv /etc/kubernetes/admin.conf /backup
mv /etc/kubernetes/kubelet.conf /backup
mv /etc/kubernetes/controller-manager.conf /backup
mv /etc/kubernetes/scheduler.conf /backup

ثم قم بتحديث هذه الملفات:

user<strong i="13">@master</strong>:~$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address=<INSERT-YOUR-APISERVER-IP-HERE>
I0124 21:56:14.253641   15040 version.go:236] remote version is much newer: v1.13.2; falling back to: stable-1.12
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"    

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

لا تنس نسخ client-certificate-data و client-key-data من /etc/kubernetes/admin.conf إلى .kube/config المحلي.

أتمنى أن يساعدك هذا

أندرياس

أي فكرة عن كيفية تشغيل هذا الأمر على 1.14.10؟ كل ما أحصل عليه هو:

kubeadm alpha phase kubeconfig all --apiserver-advertise-address=192.168.102.170 Error: unknown flag: --apiserver-advertise-address

ثم يقول المستندات:
kubeadm alpha phase kubeconfig all
وأحصل على:
This command is not meant to be run on its own. See list of available subcommands.

شكرا

مرحبا provgregoryabdo ،

ما هو انتاجك kubeadm version ؟

بي آر أندرياس

provgregoryabdo ، تم نقل أوامر phase خارج ألفا ولإصدارها في الإصدارات الأحدث حتى تتمكن من استخدام شيء مثل

kubeadm init phase kubeconfig all --apiserver-advertise-address=<your_address>

adoerler شكرا للمساعدة!