Kubeadm: एपिसर्वर सर्टिफिकेट की समय सीमा समाप्त होने पर सर्टिफिकेट का नवीनीकरण कैसे करें?

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 (कुबेदम संस्करण वर्तमान में 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. com/kubernetes/kubernetes/issues/39767)।

क्लस्टर काम कर रहा है, लेकिन यह अपना जीवन तब तक जीता है जब तक कि यह स्वयं नष्ट नहीं हो जाता या जब तक चीजें ठीक नहीं हो जाती 😅 दुर्भाग्य से, मुझे # 206 में अपनी स्थिति का समाधान नहीं मिला और मैं सोच रहा हूं कि इससे कैसे बाहर निकला जाए। एकमात्र प्रासंगिक सामग्री जिसे मैं खोद सकता था, वह एक /etc/kubernetes/ssl/ फ़ोल्डर नहीं था (केवल /etc/kubernetes/pki/ ) - या तो मेरे पास एक अलग k8s संस्करण है या मैंने बिना ध्यान दिए उस फ़ोल्डर को हटा दिया है।

@errordeveloper क्या आप कृपया कुछ सुझा सकते हैं? मुझे kubeadm reset और पेलोड मनोरंजन के बिना चीजों को ठीक करना अच्छा लगेगा।

@kachkaev क्या आपको
यदि ऐसा है, तो कृपया साझा करें, मुझे यहाँ 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

दुर्भाग्य से, मैंने अंत में हार मान ली। समाधान यह था कि एक नया क्लस्टर बनाया जाए, उस पर सभी पेलोड को पुनर्स्थापित किया जाए, डीएनएस रिकॉर्ड को स्विच किया जाए और अंत में मूल क्लस्टर को हटा दिया जाए कम से कम कोई डाउनटाइम नहीं था क्योंकि मैं भाग्यशाली था कि संक्रमण के दौरान पुराने k8s पर स्वस्थ पॉड्स थे।

प्रतिक्रिया देने के लिए धन्यवाद
अगर मुझे कुछ मिलता है तो मैं इसे यहां पोस्ट करना सुनिश्चित करूंगा ...

यदि आप 1.8 से पहले कुबेदम के एक संस्करण का उपयोग कर रहे हैं, जहां मैं समझता हूं कि सर्टिफिकेट रोटेशन # 206 को जगह में रखा गया था ( बीटा फीचर के रूप

आपको अपने मास्टर नोड में SSH की आवश्यकता होगी। यदि आप कुबेदम>= 1.8 का उपयोग कर रहे हैं तो 2 पर जाएं।

1. जरूरत पड़ने पर कुबेदम को अपडेट करें। मैं पहले 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. बैकअप पुराने एपिसर्वर, एपिसर्वर-क्यूबलेट-क्लाइंट, और फ्रंट-प्रॉक्सी-क्लाइंट सेर्ट्स और कीज़।

$ 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. नया एपिसर्वर, एपिसर्वर-क्यूबलेट-क्लाइंट, और फ्रंट-प्रॉक्सी-क्लाइंट सेर्ट्स और कुंजियाँ उत्पन्न करें।

$ 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 । इससे मेरा काम बनता है
और मेरा कुबेदम संस्करण 1.8.5 . है

धन्यवाद @danroliver एक साथ कदम रख रहा है। मुझे आपके कदमों में छोटे-छोटे जोड़ करने थे। मेरा क्लस्टर v1.9.3 चल रहा है और यह इंटरनेट से दूर एक निजी डेटासेंटर में है।

मास्टर पर

1. एक कुबेदम 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. मास्टर पर कुबेदम कमांड में --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 पर चल रहे) पर कैसे लागू किया जा सकता है, और अधिमानतः बिना डाउनटाइम के। मेरे कर्ट अभी तक समाप्त नहीं हुए हैं, लेकिन मैं यह सीखने की कोशिश कर रहा हूं कि ऐसा होने से पहले उन्हें कैसे पुन: उत्पन्न/नवीनीकृत किया जाए।

@kcronin
कृपया इस नए दस्तावेज़ पर एक नज़र डालें:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
उम्मीद है की वो मदद करदे।

@danroliver : बहुत बहुत धन्यवाद, यह काम कर रहा है।

सर्वर को रिबूट करना आवश्यक नहीं है।
यह इन दो आदेशों द्वारा क्यूब-सिस्टम पॉड्स (एपिसर्वर, स्कड्यूलर, ...) को फिर से बनाने के लिए पर्याप्त है:

systemctl पुनः आरंभ क्यूबलेट
मैं के लिए $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | Rev | awk '{print $1}' | Rev);
docker stop $i; किया हुआ

मुझे इससे 1.13 क्लस्टर पर भी निपटना था, मेरे मामले में प्रमाण पत्र समाप्त होने वाले थे, इसलिए थोड़ा अलग
इसके अलावा एक एकल मास्टर \ नियंत्रण उदाहरण के साथ काम करना, इसलिए एचए सेटअप या एडब्ल्यूएस बारीकियों के बारे में चिंता करने की ज़रूरत नहीं थी
पीछे के चरणों को शामिल नहीं किया है जैसा कि अन्य लोगों ने ऊपर शामिल किया है

चूंकि सर्टिफिकेट की समय सीमा समाप्त नहीं हुई थी, क्लस्टर में पहले से ही वर्कलोड था जिसे मैं काम करना जारी रखना चाहता था
आदि प्रमाणपत्रों से निपटने की ज़रूरत नहीं थी या तो इस समय छोड़े गए हैं

तो उच्च स्तर पर मुझे करना पड़ा

• गुरु पर
  
  
  
  • मास्टर पर नए प्रमाणपत्र उत्पन्न करें
  
  
  • एम्बेडेड प्रमाणपत्रों के साथ नए kubeconfigs उत्पन्न करें
  
  
  • नया क्यूबलेट सर्टिफिकेट जेनरेट करें - क्लाइंट और सर्वर
  
  
  • कार्यकर्ता नोड क्यूबलेट के लिए एक नया टोकन उत्पन्न करें
  
  
• प्रत्येक कार्यकर्ता के लिए
  
  
  
  • मजदूर को पहले मालिक पर उतारो
  
  
  • कार्यकर्ता को ssh, क्यूबलेट को रोकें, फ़ाइलों को हटाएं और क्यूबलेट को पुनरारंभ करें
  
  
  • मास्टर पर कार्यकर्ता को खोलना
  
  
• अंत में मास्टर पर
  
  
  
  • टोकन हटाएं
  
  

# 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

क्लस्टर में फिर से शामिल होने वाले नोड्स के लिए एक नया टोकन बनाएं (क्यूबलेट पुनरारंभ होने के बाद)

# 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 उन चरणों को पोस्ट करने के लिए धन्यवाद। मैं उनका अनुसरण करने और अपने प्रमाणपत्रों को नवीनीकृत करने, और एक कार्यशील क्लस्टर प्राप्त करने में कामयाब रहा।

यदि आप 1.8 से पहले कुबेदम के एक संस्करण का उपयोग कर रहे हैं, जहां मैं समझता हूं कि सर्टिफिकेट रोटेशन # 206 को जगह में रखा गया था ( बीटा फीचर के रूप

आपको अपने मास्टर नोड में SSH की आवश्यकता होगी। यदि आप कुबेदम>= 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 क्लस्टर पर भी निपटना था, मेरे मामले में प्रमाण पत्र समाप्त होने वाले थे, इसलिए थोड़ा अलग
इसके अलावा एक एकल मास्टर \ नियंत्रण उदाहरण के साथ काम करना, इसलिए एचए सेटअप या एडब्ल्यूएस बारीकियों के बारे में चिंता करने की ज़रूरत नहीं थी
पीछे के चरणों को शामिल नहीं किया है जैसा कि अन्य लोगों ने ऊपर शामिल किया है

चूंकि सर्टिफिकेट की समय सीमा समाप्त नहीं हुई थी, क्लस्टर में पहले से ही वर्कलोड था जिसे मैं काम करना जारी रखना चाहता था
आदि प्रमाणपत्रों से निपटने की ज़रूरत नहीं थी या तो इस समय छोड़े गए हैं

तो उच्च स्तर पर मुझे करना पड़ा

* 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

क्लस्टर में फिर से शामिल होने वाले नोड्स के लिए एक नया टोकन बनाएं (क्यूबलेट पुनरारंभ होने के बाद)

# 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 पर भी यही समस्या है और गाइड कोई त्रुटि नहीं देता है, लेकिन मैं क्लस्टर से कनेक्ट नहीं हो सकता और टोकन को फिर से जारी नहीं कर सकता (मैं असफल हो जाता हूं)

kubeadm v1.9.x का उपयोग करके बनाए गए एक k8s क्लस्टर ने v1.14.1 lol की उम्र में एक ही समस्या ( apiserver-kubelet-client.crt 2 जुलाई को समाप्त) का अनुभव किया।

मुझे प्रमाणपत्रों को नवीनीकृत करने, कॉन्फ़िगरेशन फ़ाइलों को पुन: उत्पन्न करने और साधारण 3 नोड क्लस्टर को वापस लाने के लिए 4 अलग-अलग स्रोतों का उल्लेख करना पड़ा।

@danroliver ने आईबीएम से नीचे दिए गए गाइड के बहुत करीब, बहुत अच्छे और संरचित निर्देश दिए।
[कुबेरनेट्स क्लस्टर प्रमाणपत्रों का नवीनीकरण] IBM से वाह! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

नोट: आईबीएम फाइनेंशियल क्राइम्स इनसाइट विद वाटसन प्राइवेट 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 सभी नहीं है, यह इसके बजाय एक kubeadm init चरण है

# 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 स्वचालित रूप से आपके लिए प्रमाणपत्रों का नवीनीकरण करेगा!

Kubeadm v1.9.x का उपयोग करके बनाए गए k8s क्लस्टर ने v1.14.1 lol की उम्र में एक ही समस्या (apiserver-kubelet-client.crt 2 जुलाई को समाप्त हो गई) का अनुभव किया।

1.13 से पुराने संस्करण पहले से ही असमर्थित हैं।
हम उपयोगकर्ताओं को इस तेजी से आगे बढ़ने वाले प्रोजेक्ट के साथ बने रहने के लिए दृढ़ता से प्रोत्साहित करते हैं।

वर्तमान में लॉन्गटर्म सपोर्ट वर्किंग ग्रुप द्वारा चर्चा चल रही है कि कुबेरनेट्स के संस्करणों को लंबे समय तक समर्थित किया जा सकता है, लेकिन इस प्रक्रिया को स्थापित करने में कुछ समय लग सकता है।

धन्यवाद @pmorie ।
क्यूब संस्करण 1.13.6 . के लिए काम करता है

बस एक टिप्पणी और सुविधा का अनुरोध: इस प्रमाणपत्र की समाप्ति ने आज सुबह हमारे Kubernetes 1.11.x क्लस्टर पर उत्पादन शुरू कर दिया। हमने ऊपर (और लिंक करने के लिए) सब कुछ करने की कोशिश की, लेकिन कई त्रुटियों को मारा, कुछ घंटों के बाद पूरी तरह से एक बड़े होसेस क्लस्टर के साथ फंसने के बाद छोड़ दिया। सौभाग्य से, हम कुबेरनेट्स 1.15 (और एक नया क्लस्टर बनाने) में अपग्रेड करने से लगभग 2 सप्ताह दूर थे, इसलिए हमने स्क्रैच से एक नया 1.15 क्लस्टर बनाना और अपने सभी उपयोगकर्ता डेटा की प्रतिलिपि बनाना समाप्त कर दिया।

काश ऐसा होने से पहले कुछ चेतावनी होती। हम बिना किसी चेतावनी के "अविश्वसनीय रूप से स्थिर क्लस्टर" से "पूरी तरह से टूटे हुए नारकीय दुःस्वप्न" में चले गए, और शायद हमारा अब तक का सबसे खराब समय था। सौभाग्य से, यह शुक्रवार की दोपहर एक पश्चिमी तट था, इसलिए अपेक्षाकृत कम प्रभावकारी था।

ऊपर चर्चा की गई और सभी लिंक्ड टिकटों में से, एक चीज जिसने बड़े पैमाने पर कमाई की होगी
हमारे लिए अंतर का उल्लेख नहीं किया गया है: जब प्रमाणपत्र जल्द ही समाप्त होने जा रहे हों तो एक चेतावनी प्रदर्शित करना शुरू करें । (उदाहरण के लिए, यदि आप kubectl का उपयोग करते हैं, और प्रमाणपत्र कुछ ही हफ्तों में समाप्त होने वाला है, तो कृपया मुझे बताएं!)।

आपकी परेशानी के लिए खेद है। आम तौर पर यह ऑपरेटर की जिम्मेदारी है
समाप्ति के लिए डिस्क पर प्रमाणपत्रों की निगरानी करने के लिए। लेकिन मैं सहमत हूं कि कमी
आसान निगरानी के कारण परेशानी हो सकती है। यही एक कारण है कि हमने जोड़ा
कुबेदम में प्रमाणपत्र की समय सीमा समाप्त होने की जांच करने का आदेश। देखो
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

कृपया ध्यान दें कि 1.15 के बाद kubeadm प्रमाणपत्रों को स्वतः नवीनीकृत करेगा
उन्नयन। जो यूजर्स को अधिक बार अपग्रेड करने के लिए भी प्रोत्साहित करता है।
जुलाई 20, 2019 03:49 पर, "विलियम स्टीन" नोटिफिकेशन @github.com ने लिखा:

बस एक टिप्पणी और सुविधा अनुरोध: इस प्रमाणपत्र की समाप्ति ने हमें प्रभावित किया
आज सुबह हमारे Kubernetes 1.11.x क्लस्टर पर उत्पादन। कोशिश की
ऊपर सब कुछ (और लिंक के लिए), लेकिन कई त्रुटियों को मारा, एक के बाद छोड़ दिया
कुछ घंटे पूरी तरह से एक बड़े होसेस क्लस्टर के साथ फंस गए। सौभाग्य से,
हम Kubernetes 1.15 (और बिल्डिंग .) में अपग्रेड करने से लगभग 2 सप्ताह दूर थे
एक नया क्लस्टर) इसलिए हमने स्क्रैच से एक नया 1.15 क्लस्टर बनाया
और हमारे सभी उपयोगकर्ता डेटा की प्रतिलिपि बनाना।

काश ऐसा होने से पहले कुछ चेतावनी होती। हमने अभी
"अविश्वसनीय रूप से स्थिर क्लस्टर" से "पूरी तरह से टूटे हुए नारकीय" में चला गया
दुःस्वप्न" बिना किसी चेतावनी के, और शायद हमारा अब तक का सबसे खराब समय था।
सौभाग्य से, यह शुक्रवार की दोपहर एक पश्चिमी तट था, इसलिए अपेक्षाकृत कम
प्रभावशाली।

ऊपर चर्चा की गई और सभी लिंक्ड टिकटों में से, एक बात
कि एक बड़े पैमाने पर बना होता
हमारे लिए अंतर का उल्लेख नहीं किया गया है: प्रमाणपत्र प्रदर्शित होने पर चेतावनी प्रदर्शित करना शुरू करेंजल्द ही समाप्त होने जा रहे हैं । (उदाहरण के लिए, यदि आप Kubectl का उपयोग करते हैं, और प्रमाणपत्र है
कुछ हफ्तों के भीतर समाप्त होने जा रहा है, कृपया मुझे बताएं!)

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWK3LOPWZ2-5134
या थ्रेड को म्यूट करें
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 से वाह! (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 ) में पुराना CA हो सकता है, और उसे फिर से बनाना होगा। परेशान टोकन में kube-proxy-token , coredns-token मेरे मामले (और अन्य) में शामिल थे, जिसके कारण क्लस्टर-महत्वपूर्ण सेवाएं K8s API के साथ प्रमाणित करने में असमर्थ थीं।
टोकन को फिर से बनाने के लिए, पुराने को हटा दें, और उन्हें फिर से बनाया जाएगा।
वही K8s API से बात करने वाली किसी भी सेवा के लिए जाता है, जैसे PV प्रोविजनर, इनग्रेड कंट्रोलर, cert-manager , आदि।

इस बेहतरीन चरण-दर-चरण के लिए धन्यवाद, @danroliver! मैं सोच रहा हूं कि इस प्रक्रिया को मल्टी-मास्टर क्लस्टर (नंगे धातु, वर्तमान में 1.11.1 पर चल रहे) पर कैसे लागू किया जा सकता है, और अधिमानतः बिना डाउनटाइम के। मेरे कर्ट अभी तक समाप्त नहीं हुए हैं, लेकिन मैं यह सीखने की कोशिश कर रहा हूं कि ऐसा होने से पहले उन्हें कैसे पुन: उत्पन्न/नवीनीकृत किया जाए।

हाय @kcronin , आपने मल्टी-मास्टर जैसा कि मेरे पास 3 आईपी हैं और केवल एक ही नहीं।

धन्यवाद

@pmcgrath यदि मेरे पास 3 मास्टर हैं, तो क्या मुझे प्रत्येक मास्टर के चरणों को दोहराना चाहिए? या क्या है. मामला

@SuleimanWA , यदि CA को पुन: उत्पन्न किया गया था, तो आप admin.conf साथ-साथ CA फ़ाइल की प्रतिलिपि बना सकते हैं।
अन्य सभी चीज़ों के लिए, आपको प्रत्येक मास्टर पर प्रमाणपत्र (आदि, क्यूबलेट, अनुसूचक, आदि के लिए) पुन: उत्पन्न करने के लिए चरणों को दोहराना चाहिए

@anapsix
मैं एक 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 ।

टोकन को फिर से बनाने के लिए, पुराने को हटा दें, और उन्हें फिर से बनाया जाएगा।

इस मामले में आप किस टोकन का जिक्र कर रहे हैं? क्या कुबेदम द्वारा उत्पन्न किया गया है या मैं टोकन को कैसे हटा सकता हूं?

-----अपडेट करें-----
मुझे लगा कि यह रहस्य ही है। मेरे मामले में क्यूब-नियंत्रक नहीं था इसलिए रहस्य स्वतः उत्पन्न नहीं हुआ था।

उच्च संस्करण उपयोग：

कुबेदम अल्फा सेर्ट्स सभी को नवीनीकृत करते हैं

जब पहले मास्टर नोड का क्यूबलेट डाउन (systemctl स्टॉप क्यूबलेट) होता है, तो अन्य मास्टर नोड पहले मास्टर नोड पर CA से संपर्क नहीं कर सकते हैं। इसके परिणामस्वरूप निम्न संदेश तब तक आया जब तक मूल मास्टर नोड पर क्यूबलेट ऑनलाइन वापस नहीं आया:

Kubectl नोड्स प्राप्त करें
सर्वर से त्रुटि (आंतरिक त्रुटि): सर्वर पर एक त्रुटि ("") ने अनुरोध को सफल होने से रोक दिया है (नोड्स प्राप्त करें)

क्या मूल सीए नोड पर कुब्लेट डाउन होने पर सीए भूमिका को अन्य मास्टर नोड्स में स्थानांतरित करने का कोई तरीका है?

@anapsix
मैं एक 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 ।

टोकन को फिर से बनाने के लिए, पुराने को हटा दें, और उन्हें फिर से बनाया जाएगा।

इस मामले में आप किस टोकन का जिक्र कर रहे हैं? क्या कुबेदम द्वारा उत्पन्न किया गया है या मैं टोकन को कैसे हटा सकता हूं?

-----अपडेट करें-----
मुझे लगा कि यह रहस्य ही है। मेरे मामले में क्यूब-नियंत्रक नहीं था इसलिए रहस्य स्वतः उत्पन्न नहीं हुआ था।

नमस्ते, मैंने यह कार्य किया है लेकिन 1.13 संस्करण पर नहीं। क्या मैं कुछ चीजें पूछ सकता हूं यदि आपने पहले ही ऐसा कर लिया है?
तो मूल रूप से मैं करूँगा:
kubeadm alpha certs सभी को नवीनीकृत करता है (जो मास्टर्स पर कंट्रोल प्लेन सर्टिफिकेट uber pki/फोल्डर को अपडेट करता है)।
kubeadm init phase kubeconfig क्यूब कॉन्फिग फाइल को अपडेट करने के लिए। (मास्टर और कार्यकर्ता पर)।
सभी नोड्स पर क्यूबलेट को पुनरारंभ करें।

क्या मुझे अभी भी एक टोकन बनाने और कार्यकर्ता नोड्स पर शामिल होने की आवश्यकता है? यदि संभव हो, तो क्या आप अपने द्वारा किए गए चरणों को साझा कर सकते हैं?