Kubeadm: كيف يتم تجديد الشهادة عند انتهاء صلاحية شهادة apiserver؟

نسخة مكررة من https://github.com/kubernetes/kubeadm/issues/206.

zalmanzhao هل تمكنت من حل هذه المشكلة؟

لقد أنشأت مجموعة kubeadm v1.9.3 منذ أكثر من عام بقليل وكانت تعمل بشكل جيد طوال هذا الوقت. ذهبت لتحديث عملية نشر واحدة اليوم وأدركت أنني مُنعت من واجهة برمجة التطبيقات لأن الشهادة انتهت صلاحيتها. لا يمكنني حتى kubeadm alpha phase certs apiserver ، لأنني أحصل على failure loading apiserver certificate: the certificate has expired (إصدار kubeadm حاليًا 1.10.6 لأنني أريد الترقية).

إضافة insecure-skip-tls-verify: true إلى ~/.kube/config → clusters[0].cluser لا تساعد أيضًا - أرى You must be logged in to the server (Unauthorized) عند محاولة kubectl get pods (https: // github. كوم / kubernetes / kubernetes / قضايا / 39767).

الكتلة تعمل ، لكنها تعيش حياتها الخاصة حتى تدمر نفسها أو حتى يتم إصلاح الأشياء 😅 لسوء الحظ ، لم أجد حلًا لموقفي في # 206 وأتساءل عن كيفية الخروج منه. كانت المادة الوحيدة ذات الصلة التي استطعت اكتشافها هي منشور مدونة يسمى _'كيفية تغيير الشهادات منتهية الصلاحية في مجموعة kubernetes'_ ، والتي بدت واعدة للوهلة الأولى. ومع ذلك ، لم يكن مناسبًا في النهاية لأن جهازي الرئيسي لم يكن يحتوي على مجلد /etc/kubernetes/ssl/ (فقط /etc/kubernetes/pki/ ) - إما لدي إصدار k8s مختلف أو قمت ببساطة بحذف هذا المجلد دون أن ألاحظ.

errordeveloper هل يمكنك أن توصي بشيء ما؟ أرغب في إصلاح الأشياء بدون kubeadm reset واستجمام الحمولة.

kachkaev هل كان لديك أي حظ في تجديد الشهادات دون إعادة ضبط kubeadm؟
إذا كان الأمر كذلك ، يرجى المشاركة ، فأنا أواجه نفس المشكلة هنا مع k8s 1.7.4. ولا يبدو أنني أقوم بالترقية (خطة ترقية $ kubeadm) لأن الخطأ ينبثق مرة أخرى ليخبرني أن الشهادة قد انتهت صلاحيتها وأنه لا يمكن إدراج الشرائح الرئيسية في المجموعة الخاصة بي:

[ERROR APIServerHealth]: the API Server is unhealthy; /healthz didn't return "ok"
[ERROR MasterNodesReady]: couldn't list masters in cluster: Get https://172.31.18.88:6443/api/v1/nodes?labelSelector=node-role.kubernetes.io%2Fmaster%3D: x509: certificate has expired or is not yet valid

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

شكرا @ kachkaev على الرد. ومع ذلك سأجربها مرة أخرى.
إذا وجدت شيئًا فسأحرص على نشره هنا ...

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

سوف تحتاج إلى SSH في العقدة الرئيسية الخاصة بك. إذا كنت تستخدم kubeadm> = 1.8 فانتقل إلى 2.

1. قم بتحديث Kubeadm ، إذا لزم الأمر. كنت في 1.7 سابقًا.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. النسخ الاحتياطي لشهادات apiserver القديمة و apiserver-kubelet-client وشهادات ومفاتيح الوكيل الأمامي.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. قم بإنشاء شهادات ومفاتيح apiserver-kubelet-client و front-proxy-client جديدة.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. النسخ الاحتياطي لملفات التكوين القديمة

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. إنشاء ملفات تكوين جديدة.

هناك ملاحظة مهمة هنا. إذا كنت تستخدم AWS ، فستحتاج إلى تمرير المعلمة --node-name بشكل صريح في هذا الطلب. وإلا ستحصل على خطأ مثل: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal في سجلاتك sudo journalctl -u kubelet --all | tail وستبلغ العقدة الرئيسية أنها Not Ready عند تشغيل kubectl get nodes .

يرجى التأكد من استبدال القيم التي تم تمريرها في --apiserver-advertise-address و --node-name بالقيم الصحيحة لبيئتك.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. تأكد من أن kubectl الخاص بك يبحث في المكان المناسب لملفات التكوين الخاصة بك.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. أعد تشغيل العقدة الرئيسية الخاصة بك

$ sudo /sbin/shutdown -r now

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

$ kubectl get nodes
$ kubeadm token list

إذا لم يكن لديك رمز مميز صالح. يمكنك إنشاء واحدة باستخدام:

$ kubeadm token create

يجب أن يبدو الرمز المميز مثل 6dihyb.d09sbgae8ph2atjw

1. SSH في كل من العقد التابعة وأعد توصيلها بالسيد

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. كرر الخطوة 9 لكل عقدة متصلة. من العقدة الرئيسية ، يمكنك التحقق من أن جميع العقد التابعة متصلة وجاهزة مع:

$ kubectl get nodes

نأمل أن يأخذك هذا إلى المكان الذي تريد أن تكون فيه @ davidcomeyne.

شكرا حفنة danroliver !
سأحاول بالتأكيد ذلك وأنشر نتائجي هنا.

@ danroliver شكرا! لقد جربته للتو على مجموعة قديمة أحادية العقدة ، وكذلك فعلت الخطوات حتى 7. لقد نجحت.

@ danroliver عملت لي. شكرا لك.

لم يعمل بالنسبة لي ، كان لا بد من إنشاء كتلة جديدة. لكن سعيد لأنه ساعد الآخرين!

شكرا لك danroliver . يعمل بالنسبة لي
وإصدار kubeadm الخاص بي هو 1.8.5

شكرا danroliver وضع الخطوات معا. كان علي أن أقوم بإضافات صغيرة لخطواتك. يعمل نظام المجموعة الخاص بي على الإصدار 1.9.3 وهو موجود في مركز بيانات خاص بعيدًا عن الإنترنت.

على السيد

1. قم بإعداد kubeadm config.yml .

apiVersion: kubeadm.k8s.io/v1alpha1
kind: MasterConfiguration
api:
  advertiseAddress: <master-ip>
kubernetesVersion: 1.9.3

1. شهادات النسخ الاحتياطي وملفات أسيوط

mkdir ~/conf-archive/
for f in `ls *.conf`;do mv $f ~/conf-archive/$f.old;done

mkdir ~/pki-archive
for f in `ls apiserver* front-*client*`;do mv $f ~/pki-archive/$f.old;done

1. أوامر kubeadm على master بها --config config.yml مثل هذا:

kubeadm alpha phase certs apiserver --config ./config.yml 
kubeadm alpha phase certs apiserver-kubelet-client --config ./config.yml 
kubeadm alpha phase certs front-proxy-client --config ./config.yml
kubeadm alpha phase kubeconfig all --config ./config.yml --node-name <master-node>
reboot

1. إنشاء رمز مميز

على التوابع

كان علي أن أتحرك

mv /etc/kubernetes/pki/ca.crt ~/archive/
mv /etc/kubernetes/kubelet.conf ~/archive/
systemctl stop kubelet
kubeadm join --token=eeefff.55550009999b3333 --discovery-token-unsafe-skip-ca-verification <master-ip>:6443

شكرا danroliver! فقط الكتلة أحادية العقدة الخاصة بي كانت كافية لاتباع الخطوات 1-6 (بدون إعادة تشغيل) ثم أرسل SIGHUP إلى kube-apiserver . لقد عثرت للتو على معرف الحاوية بـ docker ps وقم بتعيين الإشارة على docker kill -s HUP <container id> .

شكرا جزيلا danroliver! في مجموعتنا الفردية / متعددة العمال ، كان تنفيذ الخطوات من 1 إلى 7 كافياً ، ولم يكن علينا إعادة توصيل كل عقدة عاملة بالسيد (والذي كان الجزء الأكثر إيلامًا).

شكرًا على هذه الخطوة الرائعة خطوة بخطوة ، danroliver! أتساءل كيف يمكن تطبيق هذه العملية على مجموعة متعددة الشرائح الرئيسية (المعدن العاري ، يعمل حاليًا 1.11.1) ، ويفضل أن يكون ذلك بدون توقف. شهاداتي لم تنتهِ صلاحيتها بعد ، لكني أحاول معرفة كيفية تجديدها / تجديدها قبل حدوث ذلك.

تضمين التغريدة
يرجى إلقاء نظرة على هذا المستند الجديد:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
امل ان يساعد.

@ danroliver : شكرا جزيلا لك ، إنه يعمل.

ليس من الضروري إعادة تشغيل الخوادم.
يكفي إعادة إنشاء قرون نظام kube (apiserver ، schduler ، ...) من خلال هذين الأمرين:

إعادة تشغيل systemctl kubelet
لـ i in $ (docker ps | egrep 'admin | controller | Scheduler | api | fron | proxy' | rev | awk '{print $ 1}' | rev) ؛
هل توقف عامل المرفأ $ i ؛ انتهى

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

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

لذلك على مستوى عال كان علي أن أفعل ذلك

• على السيد
  
  
  
  • توليد شهادات جديدة على الماستر
  
  
  • قم بإنشاء kubeconfigs جديدة باستخدام الشهادات المضمنة
  
  
  • إنشاء شهادات kubelet جديدة - العميل والخادم
  
  
  • قم بإنشاء رمز مميز جديد للعقدة العاملة kubelets
  
  
• لكل عامل
  
  
  
  • استنزاف العامل أولاً على الربان
  
  
  • ssh للعامل ، أوقف kubelet ، أزل الملفات وأعد تشغيل kubelet
  
  
  • Uncordon العامل على السيد
  
  
• على الماجستير في النهاية
  
  
  
  • حذف الرمز المميز
  
  

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

لنقم بإنشاء رمز مميز جديد للعقد التي تعيد الانضمام إلى الكتلة (بعد إعادة تشغيل kubelet)

# On master
sudo kubeadm token create

الآن لكل عامل - واحدًا تلو الآخر

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh إلى عقدة العامل

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

العودة إلى إتقان وفتح العامل

kubectl uncordon WORKER-NODE-NAME

بعد تحديث جميع العمال - إزالة الرمز المميز - ستنتهي صلاحيته في غضون 24 ساعة ولكن دعنا نتخلص منه

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

pmcgrath شكرًا لنشر هذه الخطوات. تمكنت من متابعتهم وتجديد شهاداتي ، والحصول على مجموعة عمل.

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

سوف تحتاج إلى SSH في العقدة الرئيسية الخاصة بك. إذا كنت تستخدم kubeadm> = 1.8 فانتقل إلى 2.

1. Update Kubeadm, if needed. I was on 1.7 previously.

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm

1. Backup old apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo mv /etc/kubernetes/pki/apiserver.key /etc/kubernetes/pki/apiserver.key.old
$ sudo mv /etc/kubernetes/pki/apiserver.crt /etc/kubernetes/pki/apiserver.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.crt /etc/kubernetes/pki/apiserver-kubelet-client.crt.old
$ sudo mv /etc/kubernetes/pki/apiserver-kubelet-client.key /etc/kubernetes/pki/apiserver-kubelet-client.key.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.crt /etc/kubernetes/pki/front-proxy-client.crt.old
$ sudo mv /etc/kubernetes/pki/front-proxy-client.key /etc/kubernetes/pki/front-proxy-client.key.old

1. Generate new apiserver, apiserver-kubelet-client, and front-proxy-client certs and keys.

$ sudo kubeadm alpha phase certs apiserver --apiserver-advertise-address <IP address of your master server>
$ sudo kubeadm alpha phase certs apiserver-kubelet-client
$ sudo kubeadm alpha phase certs front-proxy-client

1. Backup old configuration files

$ sudo mv /etc/kubernetes/admin.conf /etc/kubernetes/admin.conf.old
$ sudo mv /etc/kubernetes/kubelet.conf /etc/kubernetes/kubelet.conf.old
$ sudo mv /etc/kubernetes/controller-manager.conf /etc/kubernetes/controller-manager.conf.old
$ sudo mv /etc/kubernetes/scheduler.conf /etc/kubernetes/scheduler.conf.old

1. Generate new configuration files.

هناك ملاحظة مهمة هنا. إذا كنت تستخدم AWS ، فستحتاج إلى تمرير المعلمة --node-name بشكل صريح في هذا الطلب. وإلا ستحصل على خطأ مثل: Unable to register node "ip-10-0-8-141.ec2.internal" with API server: nodes "ip-10-0-8-141.ec2.internal" is forbidden: node ip-10-0-8-141 cannot modify node ip-10-0-8-141.ec2.internal في سجلاتك sudo journalctl -u kubelet --all | tail وستبلغ العقدة الرئيسية أنها Not Ready عند تشغيل kubectl get nodes .

يرجى التأكد من استبدال القيم التي تم تمريرها في --apiserver-advertise-address و --node-name بالقيم الصحيحة لبيئتك.

$ sudo kubeadm alpha phase kubeconfig all --apiserver-advertise-address 10.0.8.141 --node-name ip-10-0-8-141.ec2.internal
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"

1. Ensure that your `kubectl` is looking in the right place for your config files.

$ mv .kube/config .kube/config.old
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config
$ sudo chmod 777 $HOME/.kube/config
$ export KUBECONFIG=.kube/config

1. Reboot your master node

$ sudo /sbin/shutdown -r now

1. Reconnect to your master node and grab your token, and verify that your Master Node is "Ready". Copy the token to your clipboard. You will need it in the next step.

$ kubectl get nodes
$ kubeadm token list

إذا لم يكن لديك رمز مميز صالح. يمكنك إنشاء واحدة باستخدام:

$ kubeadm token create

يجب أن يبدو الرمز المميز مثل 6dihyb.d09sbgae8ph2atjw

1. SSH into each of the slave nodes and reconnect them to the master

$ sudo curl -sSL https://dl.k8s.io/release/v1.8.15/bin/linux/amd64/kubeadm > ./kubeadm.1.8.15
$ chmod a+rx kubeadm.1.8.15
$ sudo mv /usr/bin/kubeadm /usr/bin/kubeadm.1.7
$ sudo mv kubeadm.1.8.15 /usr/bin/kubeadm
$ sudo kubeadm join --token=<token from step 8>  <ip of master node>:<port used 6443 is the default> --node-name <should be the same one as from step 5>

1. Repeat Step 9 for each connecting node. From the master node, you can verify that all slave nodes have connected and are ready with:

$ kubectl get nodes

نأمل أن يأخذك هذا إلى المكان الذي تريد أن تكون فيه @ davidcomeyne.

هذا ما أحتاجه فقط لـ 1.14.2 .. أي تلميحات حول كيفية القيام بذلك

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

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

لذلك على مستوى عال كان علي أن أفعل ذلك

* On the master

  * Generate new certificates on the master
  * Generate new kubeconfigs with embedded certificates
  * Generate new kubelet certicates - client and server
  * Generate a new token for the worker node kubelets

* For each worker

  * Drain the worker first on the master
  * ssh to the worker, stop the kubelet, remove files and restart the kubelet
  * Uncordon the worker on the master

* On master at the end

  * Delete token

# On master - See https://kubernetes.io/docs/setup/certificates/#all-certificates

# Generate the new certificates - you may have to deal with AWS - see above re extra certificate SANs
sudo kubeadm alpha certs renew apiserver
sudo kubeadm alpha certs renew apiserver-etcd-client
sudo kubeadm alpha certs renew apiserver-kubelet-client
sudo kubeadm alpha certs renew front-proxy-client

# Generate new kube-configs with embedded certificates - Again you may need extra AWS specific content - see above
sudo kubeadm alpha kubeconfig user --org system:masters --client-name kubernetes-admin  > admin.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-controller-manager > controller-manager.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo kubeadm alpha kubeconfig user --client-name system:kube-scheduler > scheduler.conf

# chown and chmod so they match existing files
sudo chown root:root {admin,controller-manager,kubelet,scheduler}.conf
sudo chmod 600 {admin,controller-manager,kubelet,scheduler}.conf

# Move to replace existing kubeconfigs
sudo mv admin.conf /etc/kubernetes/
sudo mv controller-manager.conf /etc/kubernetes/
sudo mv kubelet.conf /etc/kubernetes/
sudo mv scheduler.conf /etc/kubernetes/

# Restart the master components
sudo kill -s SIGHUP $(pidof kube-apiserver)
sudo kill -s SIGHUP $(pidof kube-controller-manager)
sudo kill -s SIGHUP $(pidof kube-scheduler)

# Verify master component certificates - should all be 1 year in the future
# Cert from api-server
echo -n | openssl s_client -connect localhost:6443 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from controller manager
echo -n | openssl s_client -connect localhost:10257 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
# Cert from scheduler
echo -n | openssl s_client -connect localhost:10259 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

# Generate kubelet.conf
sudo kubeadm alpha kubeconfig user --org system:nodes --client-name system:node:$(hostname) > kubelet.conf
sudo chown root:root kubelet.conf
sudo chmod 600 kubelet.conf

# Drain
kubectl drain --ignore-daemonsets $(hostname)
# Stop kubelet
sudo systemctl stop kubelet
# Delete files
sudo rm /var/lib/kubelet/pki/*
# Copy file
sudo mv kubelet.conf /etc/kubernetes/
# Restart
sudo systemctl start kubelet
# Uncordon
kubectl uncordon $(hostname)

# Check kubelet
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not

لنقم بإنشاء رمز مميز جديد للعقد التي تعيد الانضمام إلى الكتلة (بعد إعادة تشغيل kubelet)

# On master
sudo kubeadm token create

الآن لكل عامل - واحدًا تلو الآخر

kubectl drain --ignore-daemonsets --delete-local-data WORKER-NODE-NAME

ssh إلى عقدة العامل

# Stop kubelet
sudo systemctl stop kubelet

# Delete files
sudo rm /etc/kubernetes/kubelet.conf
sudo rm /var/lib/kubelet/pki/*

# Alter the bootstrap token
new_token=TOKEN-FROM-CREATION-ON-MASTER
sudo sed -i "s/token: .*/token: $new_token/" /etc/kubernetes/bootstrap-kubelet.conf

# Start kubelet
sudo systemctl start kubelet

# Check kubelet certificate
echo -n | openssl s_client -connect localhost:10250 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text -noout | grep Not
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -text -noout | grep Not

العودة إلى إتقان وفتح العامل

kubectl uncordon WORKER-NODE-NAME

بعد تحديث جميع العمال - إزالة الرمز المميز - ستنتهي صلاحيته في غضون 24 ساعة ولكن دعنا نتخلص منه

On master
sudo kubeadm token delete TOKEN-FROM-CREATION-ON-MASTER

أعلم أن هذه المشكلة مغلقة ولكن لدي نفس المشكلة في 1.14.2 ولا يقدم الدليل أي أخطاء ولكن لا يمكنني الاتصال بالمجموعة وإعادة إصدار الرمز المميز (فشلت المصادقة)

واجهت مجموعة k8s التي تم إنشاؤها باستخدام kubeadm v1.9.x نفس المشكلة (انتهت صلاحية apiserver-kubelet-client.crt في 2 يوليو) في عمر v1.14.1 lol

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

أعطى danroliver تعليمات جيدة جدًا ومنظمة ، قريبة جدًا من الدليل أدناه من IBM.
[تجديد شهادات مجموعة Kubernetes] من IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

ملاحظة: يتم تشغيل IBM Financial Crimes Insight with Watson private بواسطة k8s ، ولم أكن أعرف ذلك مطلقًا.

مشكلة في الخطوة 3 والخطوة 5

الخطوة 3 يجب ألا تحتوي على المرحلة في الأمر

$ sudo kubeadm alpha certs renew apiserver
$ sudo kubeadm alpha certs renew apiserver-kubelet-client
$ sudo kubeadm alpha certs renew front-proxy-client

الخطوة 5 يجب أن تستخدم أدناه ، kubeadm alpha لا تحتوي على kubeconfig all ، هذه هي kubeadm init phase بدلاً من ذلك

# kubeadm init phase kubeconfig all
I0705 12:42:24.056152   32618 version.go:240] remote version is much newer: v1.15.0; falling back to: stable-1.14
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file

في 1.15 أضفنا وثائق أفضل لتجديد الشهادة:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

أيضًا ، بعد 1.15 kubeadm upgrade سيتم تجديد الشهادات تلقائيًا لك!

واجهت مجموعة k8s التي تم إنشاؤها باستخدام kubeadm v1.9.x نفس المشكلة (انتهت صلاحية apiserver-kubelet-client.crt في 2 يوليو) في عمر الإصدار 1.14.1 lol

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

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

شكرا pmorie .
يعمل مع نسخة kube 1.13.6

مجرد تعليق وطلب ميزة: لقد أصابنا انتهاء صلاحية الشهادة هذا في الإنتاج على مجموعة Kubernetes 1.11.x الخاصة بنا هذا الصباح. لقد جربنا كل شيء أعلاه (والروابط) ، لكننا واجهنا العديد من الأخطاء ، واستسلمنا بعد بضع ساعات من التعلق تمامًا بمجموعة كبيرة من المياه. لحسن الحظ ، كنا على بعد أسبوعين تقريبًا من الترقية إلى Kubernetes 1.15 (وبناء مجموعة جديدة) لذلك انتهى بنا الأمر بإنشاء مجموعة 1.15 جديدة من البداية ونسخ جميع بيانات المستخدم الخاصة بنا.

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

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

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

يرجى أيضًا ملاحظة أنه بعد 1.15 kubeadm سيتم تجديد الشهادات تلقائيًا في
تطوير. مما يشجع المستخدمين على الترقية في كثير من الأحيان أيضًا.
في 20 يوليو 2019 03:49 ، كتب "ويليام شتاين" [email protected] :

مجرد تعليق وطلب ميزة: لقد أصابنا انتهاء صلاحية الشهادة هذا
الإنتاج على مجموعة Kubernetes 1.11.x الخاصة بنا هذا الصباح. حاولنا
كل شيء أعلاه (والروابط) ، ولكن تعرض لأخطاء عديدة ، استسلم بعد ملف
بضع ساعات تتعثر تمامًا مع كتلة مسرطنة كبيرة. لحسن الحظ،
كنا على بعد حوالي أسبوعين من الترقية إلى Kubernetes 1.15 (وبناء
كتلة جديدة) لذلك انتهى بنا الأمر للتو بإنشاء كتلة 1.15 جديدة من البداية
ونسخ جميع بيانات المستخدم الخاصة بنا.

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

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/kubernetes/kubeadm/issues/581؟email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VM13TUL52HS4DFVREXG43VM20
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@ neolit123 شكرا ؛ سنضيف شيئًا إلى البنية التحتية للمراقبة الخاصة بنا للتحقق بشكل دوري من مشكلات الشهادة القادمة ، كما هو موضح في تعليقك.

danroliver Thx الكثير
نقطة واحدة جديرة بالذكر هي الشهادات ذات الصلة "إلخ" ، والتي يجب تجديدها بنفس الطريقة. ليست هناك حاجة لإعادة تحميل التكوين حيث يتم استخدامه في ملفات YAML للبيانات الوصفية كمراجع.

بالنسبة إلى Kubernetes v1.14 ، أجد أن هذا الإجراء الذي اقترحه desdic هو الأكثر فائدة:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • النسخ الاحتياطي وإعادة إنشاء جميع الشهادات:
  
  

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --apiserver-advertise-address <IP>

• النسخ الاحتياطي وإعادة إنشاء جميع ملفات kubeconfig:

$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,mv kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all
$ reboot

• نسخ جديد admin.conf :

$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

بالنسبة إلى Kubernetes v1.14 ، أجد أن هذا الإجراء مفيد للغاية:

* https://stackoverflow.com/a/56334732/1147487

لقد قمت بإنشاء الإصلاح بمجرد إصلاح الكتلة الخاصة بي .. آمل أن يتمكن شخص آخر من استخدامه

أعطى danroliver تعليمات جيدة جدًا ومنظمة ، قريبة جدًا من الدليل أدناه من IBM.
[تجديد شهادات مجموعة Kubernetes] من IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

لطيف - جيد! أتساءل متى تم نشر هذا. بالتأكيد كنت سأجد هذا مفيدًا عندما كنت أعاني من هذا.

ملاحظة حول الرموز المميزة في K8s 1.13.x (ربما إصدارات K8s الأخرى)
إذا كنت قد انتهيت من إعادة إنشاء شهادة CA الخاصة بك ( /etc/kubernetes/pki/ca.crt ) ، فقد تحتوي الرموز المميزة الخاصة بك (انظر kubectl -n kube-system get secret | grep token ) على مرجع مصدق قديم ، وسيتعين عليك إعادة إنشائها. تضمنت الرموز المميزة المضطربة kube-proxy-token و coredns-token في حالتي (وغيرها) ، مما تسبب في عدم قدرة خدمات المجموعة الحرجة على المصادقة باستخدام K8s API.
لإعادة إنشاء الرموز ، احذف الرموز القديمة ، وستتم إعادة إنشائها.
ينطبق الشيء نفسه على أي خدمات تتحدث إلى K8s API ، مثل PV Provisioner و Ingress Controllers و cert-manager ، إلخ.

شكرًا على هذه الخطوة الرائعة خطوة بخطوة ، danroliver! أتساءل كيف يمكن تطبيق هذه العملية على مجموعة متعددة الشرائح الرئيسية (المعدن العاري ، يعمل حاليًا 1.11.1) ، ويفضل أن يكون ذلك بدون توقف. شهاداتي لم تنتهِ صلاحيتها بعد ، لكني أحاول معرفة كيفية تجديدها / تجديدها قبل حدوث ذلك.

مرحبًا kcronin ، كيف تم حل مشكلة التكوين متعدد لأن لدي 3 IPs وليس واحدًا فقط.

شكرا

pmcgrath في حال كان لدي 3 سادة ، هل يجب أن أكرر الخطوات على كل معلم؟ أو ما هو. قضية

SuleimanWA ، يمكنك نسخ admin.conf أكثر ، وكذلك ملف CA ، إذا تم إعادة إنشاء CA.
لكل شيء آخر ، يجب عليك تكرار الخطوات لإعادة إنشاء الشهادات (لـ etcd ، kubelet ، المجدول ، إلخ ..) على كل معلم

تضمين التغريدة
أنا أقوم بتشغيل مجموعة 1.13.x ، ويقوم apiserver بالإبلاغ عن Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] بعد أن قمت بتجديد الشهادات عن طريق تشغيل kubeadm alpha certs renew all .

لإعادة إنشاء الرموز ، احذف الرموز القديمة ، وستتم إعادة إنشائها.

ما هو الرمز المميز الذي تشير إليه في هذه الحالة؟ هل هو الذي تم إنشاؤه بواسطة kubeadm أو كيف يمكنني حذف الرمز المميز؟

-----تحديث-----
اكتشفت أنه السر نفسه. في حالتي ، لم يكن جهاز التحكم في kube جاهزًا ، لذا لم يتم إنشاء السر تلقائيًا.

استخدام نسخة عالية ：

جميع شهادات kubeadm alpha

عندما تنخفض kubelet للعقدة الرئيسية (توقف systemctl kubelet) ، لا يمكن للعقد الرئيسية الأخرى الاتصال بـ CA على العقدة الرئيسية الأولى. أدى ذلك إلى ظهور الرسالة التالية حتى تمت إعادة الاتصال kubelet على العقدة الرئيسية الأصلية:

kubectl الحصول على العقد
خطأ من الخادم (خطأ داخلي): خطأ في الخادم ("") حال دون نجاح الطلب (الحصول على العقد)

هل هناك طريقة لنقل دور CA إلى العقد الرئيسية الأخرى أثناء تعطل kublet الموجود في عقدة CA الأصلية؟

تضمين التغريدة
أنا أقوم بتشغيل مجموعة 1.13.x ، ويقوم apiserver بالإبلاغ عن Unable to authenticate the request due to an error: [x509: certificate has expired or is not yet valid, x509: certificate has expired or is not yet valid] بعد أن قمت بتجديد الشهادات عن طريق تشغيل kubeadm alpha certs renew all .

لإعادة إنشاء الرموز ، احذف الرموز القديمة ، وستتم إعادة إنشائها.

ما هو الرمز المميز الذي تشير إليه في هذه الحالة؟ هل هو الذي تم إنشاؤه بواسطة kubeadm أو كيف يمكنني حذف الرمز المميز؟

-----تحديث-----
اكتشفت أنه السر نفسه. في حالتي ، لم يكن جهاز التحكم في kube جاهزًا ، لذا لم يتم إنشاء السر تلقائيًا.

مرحبًا ، لقد قمت بهذه المهمة ولكن ليس على الإصدار 1.13. هل لي أن أسأل بعض الأشياء إذا كنت قد فعلت هذا بالفعل؟
لذلك سأفعل في الأساس:
تقوم kubeadm alpha certs بتجديد الكل (الذي يقوم بتحديث مستوى التحكم cert uber pki / folder على الماجستير).
kubeadm init phase kubeconfig لتحديث ملفات تهيئة kube. (في الماجستير والعامل).
أعد تشغيل kubelet على جميع العقد.

هل ما زلت بحاجة إلى إنشاء رمز مميز وتشغيل الانضمام على عقد العامل؟ إذا أمكن ، هل يمكنك مشاركة الخطوات التي قمت بها؟