في حالة الرد على الأمر
kubectl get pod ستحصل على:
Unable to connect to the server: x509: certificate has expired or is not yet valid
بعد ذلك ، على الأرجح ، انقضى عام ، وانتهت صلاحية شهادات kubernetes الخاصة بك ، وتوقفت مكونات الكتلة عن استخدامها ، وتوقف التفاعل بينهما وتحولت الكتلة الخاصة بك إلى قرع.
ما يجب القيام به وكيفية استعادة كتلة؟
أولاً ، نحتاج إلى فهم مكان وجود الشهادات التي تحتاج إلى تحديث.
اعتمادًا على الطريقة التي تم بها تثبيت الكتلة ، قد يختلف موقع واسم ملفات الشهادة. لذلك ، على سبيل المثال ، عند إنشاء نظام مجموعة ، يقوم Kubeadm بتحليل ملفات الشهادات وفقًا
لأفضل الممارسات . وبالتالي ، توجد جميع الشهادات في الدليل
/etc/kuberenetes/pki ، في الملفات ذات الملحق
.crt ، والمفاتيح الخاصة ، على التوالي ، في ملفات
.key . بالإضافة إلى
/etc/kubernetes/ ملفات
.conf مع تكوين الوصول لمسؤول حسابات المستخدمين ، وحدة تحكم المدير ، sheduler و kubelet من العقدة الرئيسية. تكمن الشهادات في ملفات
.conf في حقل user.client-certificate-data في نموذج base64-encoded.
يمكنك الاطلاع على تاريخ انتهاء الصلاحية لمن تم إصدارها ولمن تم توقيع الشهادة باستخدام هذا البرنامج النصي الصغير
لا تزال هناك شهادات تستخدم kubelet على عقد العمل للمصادقة في API. إذا كنت تستخدم الصلة kubeadm لإضافة العقد إلى الكتلة ، فغالبًا ما كانت العقدة متصلة باستخدام إجراء
التمهيد TLS ، وفي هذه الحالة يمكن أن تقوم kubelet بتجديد شهادتها تلقائيًا إذا تم إعطاؤها خيار
--rotate-certificates . في الإصدارات الأخيرة من kubernetes ، يتم تمكين هذا الخيار بالفعل بشكل افتراضي.
التحقق من أن العقدة متصلة باستخدام إجراء التمهيد TLS بسيط للغاية - في هذه الحالة ، يتم تحديد الملف
/var/lib/kubelet/pki/kubelet-client-current.pem في ملف شهادة العميل في ملف
/var/lib/kubelet/pki/kubelet-client-current.pem وهو رابط إلى الشهادة الحالية.
يمكنك أيضًا مشاهدة تواريخ انتهاء صلاحية هذه الشهادة باستخدام البرنامج النصي
shcertنعود إلى مشكلة تجديد الشهادات.إذا قمت بتثبيت نظام المجموعة باستخدام kubeadm ، فعندئذٍ لدي أخبار جيدة لك. بدءًا من الإصدار 1.15 ، يمكن لـ kubeadm تحديث جميع شهادات طائرة التحكم تقريبًا باستخدام أمر واحد
kubeadm alpha certs renew all
سيقوم هذا الأمر بتجديد جميع الشهادات في الدليل / etc / kubernetes ، حتى إذا كانت قد انتهت صلاحيتها بالفعل وكسر كل شيء.
لن يتم تحديث شهادة kubelet فقط - فهذه هي الشهادة الموجودة في ملف
/etc/kubernetes/kubelet.conf !
تحديث: kubeadm ، بدءًا من الإصدار 1.17 ، يشمل على جميع العقد (حتى على المعالج الأول حيث تم إجراء kubeadm init) التجديد التلقائي لشهادة culet. التحقق بسيط للغاية - في /etc/kubernetes/kubelet.conf المسار إلى الملف /var/lib/kubelet/pki/kubelet-client-current.pem في حقل شهادة العميل
لتجديد هذه الشهادة ، استخدم أمر إنشاء حساب مستخدم
kubeadm alpha kubeconfig user --client-name system:node:kube.slurm.io --org system:nodes > /etc/kubernetes/kubelet.conf
إذا كان النظام لديه حساب مستخدم ، فإن هذا الأمر يقوم بتحديث الشهادة لهذا الحساب. لا تنس تحديد اسم المضيف الصحيح في
--client-name ، يمكنك
--client-name اسم المضيف في حقل الموضوع في شهادة موجودة:
shcert /etc/kubernetes/kubelet.conf
وبالطبع ، بعد تحديث الشهادات ، ستحتاج إلى إعادة تشغيل جميع مكونات طائرة التحكم ، أو إعادة تشغيل العقدة بأكملها أو إيقاف الحاويات مع etcd ، api ، مدير وحدة التحكم والجدولة باستخدام الأمر docker
docker stop ، ثم إعادة تشغيل kubelet
systemctl restart kubelet .
إذا كان لدى نظامك إصدار قديم: 1.13 أو أقل ، فلن يعمل ببساطة لترقية kubeadm إلى 1.15 ، لأنه يمتد على طول تبعيات kubelet و kubernetes-cni ، مما قد يسبب مشاكل ، لأن أداء مكونات نظام المجموعة يختلف في الإصدارات بأكثر من واحد المرحلة ، غير مضمونة. أسهل طريقة للخروج من هذا الموقف هي تثبيت kubeadm على جهاز آخر ، وأخذ الملف الثنائي
/usr/bin/kubeadm ، ونسخه إلى العقد الرئيسية للمجموعة المتوفاة واستخدامه فقط لتجديد الشهادات. وبعد تنشيط الكتلة ، قم بتحديثها خطوة بخطوة باستخدام الطرق المعتادة ، وتثبيت إصدار kubeadm بأحدث إصدار في كل مرة.
وأخيرًا ، من الإصدار 1.15 تعلمت kubeadm كيفية تجديد شهادات الكل عند تحديث نظام مجموعة باستخدام أمر
kubeadm upgrade . لذلك إذا قمت بتحديث نظامك بانتظام مرة واحدة على الأقل في السنة ، فستظل شهاداتك صالحة دائمًا.
ولكن إذا لم يتم تثبيت الكتلة باستخدام kubeadm ، فسوف تضطر إلى التقاط openssl وتجديد جميع الشهادات بشكل فردي.
المشكلة هي أن الشهادات تحتوي على حقول موسعة ، ويمكن لأدوات تثبيت الكتلة المختلفة إضافة مجموعة الحقول الخاصة بها. علاوة على ذلك ، ترتبط أسماء هذه الحقول في تكوين opensl وفي إخراج محتويات الشهادة ، ولكن ضعيفة. فمن الضروري أن جوجل وحدد.
سأقدم مثالاً للتكوين لـ opensl ، في أقسام منفصلة وصفت السمات الموسعة ، خاصة بكل نوع من أنواع الشهادات. سوف نشير إلى القسم المقابل عند إنشاء وتوقيع csr. تم استخدام هذا التكوين لتنشيط نظام المجموعة الذي أنشأته المزرعة قبل عام.
openssl.cnf [req] distinguished_name = req_distinguished_name req_extensions = v3_req [v3_req] keyUsage = nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [client] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth [apiproxyclient] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth [etcd] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [api] keyUsage = critical,digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, serverAuth subjectAltName = @alt_names [alt_names] DNS.1 = ec2-us-east-1-1a-c1-master-2 DNS.2 = ec2-us-east-1-1a-c1-master-3 DNS.3 = ec2-us-east-1-1a-c1-master-1 DNS.4 = localhost DNS.5 = kubernetes DNS.6 = kubernetes.default DNS.7 = kubernetes.default.svc DNS.8 = kubernetes.default.svc.cluster.local IP.1 = 10.0.0.109 IP.2 = 10.0.0.159 IP.3 = 10.0.0.236 IP.4 = 127.0.0.1 IP.5 = 10.43.0.1
يمكن عرض السمات الفعلية والأسماء الإضافية في الشهادة باستخدام الأمر
openssl x509 -in cert.crt -text
عند تجديد شهادة واجهة برمجة تطبيقات الخادم ، واجهت مشكلة: لم تنجح الشهادة المحدثة. كان الحل هو إصدار شهادة صالحة لمدة عام في الماضي.
في openssl ، لا يمكنك إصدار شهادة صالحة في الماضي باستخدام أمر بسيط ، وينص الرمز بدقة على أن الشهادة صالحة فقط من اللحظة الحالية. ولكن يمكنك العودة محليًا في الوقت المناسب باستخدام مكتبة libfaketime
yum install libfaketime LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req ...
نصدر الشهادات الموسعة وفقًا للخوارزمية التالية:
نقوم بإنشاء CSR باستخدام شهادة موجودة ، وحدد القسم المطلوب مع قائمة بالسمات المتقدمة في ملف التكوين:
openssl x509 -x509toreq -in "node.cert" -out "node.csr" -signkey "node.key" -extfile "openssl.cnf" -extensions client
نقوم بتوقيعه باستخدام شهادة الجذر المناظرة ، ونغير الوقت قبل سنة واحدة ونحدد القسم المطلوب مع قائمة بالسمات المتقدمة في ملف التكوين
LD_PRELOAD=/usr/lib64/faketime/libfaketime.so.1 FAKETIME="-365d" openssl x509 -req -days 36500 -in "node.csr" -CA "kube-ca.pem" -CAkey "kube-ca-key.pem" -CAcreateserial -out "node.new.cert" -extfile "openssl.cnf" -extensions client
نتحقق من السمات ونعيد تشغيل مكونات طائرة التحكم.
سيرجي بونداريف ،
سذاجة المعلم
slurm.io