Kubeadm: bagaimana cara memperbarui sertifikat ketika sertifikat apiserver kedaluwarsa?

Duplikat https://github.com/kubernetes/kubeadm/issues/206.

@zalmanzhao apakah Anda berhasil menyelesaikan masalah ini?

Saya membuat cluster kubeadm v1.9.3 lebih dari setahun yang lalu dan itu berfungsi dengan baik selama ini. Saya pergi untuk memperbarui satu penerapan hari ini dan menyadari bahwa saya terkunci dari API karena sertifikatnya kedaluwarsa. Saya bahkan tidak bisa kubeadm alpha phase certs apiserver , karena saya mendapatkan failure loading apiserver certificate: the certificate has expired (versi kubeadm saat ini 1.10.6 karena saya ingin memutakhirkan).

Menambahkan insecure-skip-tls-verify: true ke ~/.kube/config → clusters[0].cluser juga tidak membantu – saya melihat You must be logged in to the server (Unauthorized) ketika mencoba kubectl get pods (https://github. com/kubernetes/kubernetes/issues/39767).

Cluster ini berfungsi, tetapi ia menjalani hidupnya sendiri sampai hancur sendiri atau sampai semuanya diperbaiki Sayangnya, saya tidak dapat menemukan solusi untuk situasi saya di #206 dan saya bertanya-tanya bagaimana cara keluar darinya. Satu-satunya materi relevan yang dapat saya gali adalah posting blog berjudul _'Cara mengubah sertifikat kedaluwarsa di kubernetes cluster'_ , yang sekilas tampak menjanjikan. Namun, pada akhirnya tidak muat karena mesin master saya tidak memiliki folder /etc/kubernetes/ssl/ (hanya /etc/kubernetes/pki/ ) – entah saya memiliki versi k8s yang berbeda atau saya hanya menghapus folder itu tanpa menyadarinya.

@errordeveloper bisakah Anda merekomendasikan sesuatu? Saya ingin memperbaiki hal-hal tanpa kubeadm reset dan rekreasi muatan.

@kachkaev Apakah Anda beruntung memperbarui sertifikat tanpa mengatur ulang kubeadm?
Jika demikian, tolong bagikan, saya mengalami masalah yang sama di sini dengan k8s 1.7.4. Dan sepertinya saya tidak dapat memutakhirkan ($ kubeadm upgrade plan) karena kesalahan muncul lagi memberi tahu saya bahwa sertifikat telah kedaluwarsa dan tidak dapat mencantumkan master di cluster saya:

[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

Sayangnya, saya menyerah pada akhirnya. Solusinya adalah membuat cluster baru, memulihkan semua muatan di dalamnya, mengganti catatan DNS dan akhirnya menghapus cluster asli Setidaknya tidak ada downtime karena saya cukup beruntung memiliki pod yang sehat di k8s lama selama masa transisi.

Terima kasih @kachkaev untuk menanggapi. Saya tetap akan mencobanya lagi.
Jika saya menemukan sesuatu, saya pasti akan mempostingnya di sini ...

Jika Anda menggunakan versi kubeadm sebelum 1.8, di mana saya mengerti bahwa rotasi sertifikat #206 diberlakukan (sebagai fitur beta ) atau sertifikat Anda sudah kedaluwarsa, maka Anda perlu memperbarui sertifikat Anda secara manual (atau membuat ulang cluster Anda yang tampaknya beberapa (bukan hanya @kachkaev) akhirnya beralih ke).

Anda perlu SSH ke node master Anda. Jika Anda menggunakan kubeadm >= 1.8 lewati ke 2.

1. Perbarui Kubeadm, jika perlu. Saya berada di 1.7 sebelumnya.

$ 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. Cadangkan sertifikat dan kunci apiserver-kubelet-client, apiserver-kubelet-client, dan front-proxy-client yang lama.

$ 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. Buat sertifikat dan kunci apiserver, apiserver-kubelet-client, dan front-proxy-client baru.

$ 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. Cadangkan file konfigurasi lama

$ 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. Hasilkan file konfigurasi baru.

Ada catatan penting di sini. Jika Anda menggunakan AWS, Anda harus secara eksplisit meneruskan parameter --node-name dalam permintaan ini. Jika tidak, Anda akan mendapatkan kesalahan seperti: 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 di log Anda sudo journalctl -u kubelet --all | tail dan Master Node akan melaporkan bahwa itu adalah Not Ready ketika Anda menjalankan kubectl get nodes .

Pastikan untuk mengganti nilai yang diteruskan dalam --apiserver-advertise-address dan --node-name dengan nilai yang benar untuk lingkungan Anda.

$ 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. Pastikan kubectl mencari di tempat yang tepat untuk file konfigurasi Anda.

$ 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. Nyalakan ulang master node Anda

$ sudo /sbin/shutdown -r now

1. Hubungkan kembali ke master node Anda dan ambil token Anda, dan verifikasi bahwa Master Node Anda "Siap". Salin token ke papan klip Anda. Anda akan membutuhkannya di langkah berikutnya.

$ kubectl get nodes
$ kubeadm token list

Jika Anda tidak memiliki token yang valid. Anda dapat membuatnya dengan:

$ kubeadm token create

Token akan terlihat seperti 6dihyb.d09sbgae8ph2atjw

1. SSH ke masing-masing node slave dan sambungkan kembali ke 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. Ulangi Langkah 9 untuk setiap node penghubung. Dari node master, Anda dapat memverifikasi bahwa semua node slave telah terhubung dan siap dengan:

$ kubectl get nodes

Semoga ini membawa Anda ke tempat yang Anda inginkan @davidcomeyne.

Terima kasih banyak @danroliver !
Saya pasti akan mencobanya dan memposting temuan saya di sini.

@danroliver Terima kasih! Baru saja mencobanya di cluster single-node lama, begitu juga langkah hingga 7. Itu berhasil.

@danroliver Bekerja untuk saya. Terima kasih.

Tidak berhasil untuk saya, harus menyiapkan cluster baru. Tapi senang itu membantu orang lain!

terima kasih @danroliver . itu bekerja untuk saya
dan versi kubeadm saya adalah 1.8.5

Terima kasih @danroliver menyusun langkah-langkahnya. Saya harus membuat tambahan kecil pada langkah Anda. Cluster saya menjalankan v1.9.3 dan berada di pusat data pribadi di luar Internet.

Pada Guru

1. Siapkan kubeadm config.yml .

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

1. Sertifikat cadangan dan file conf

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. Perintah kubeadm pada master memiliki --config config.yml seperti ini:

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. Buat token

Pada antek-anteknya

aku harus pindah

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

Terima kasih @danroliver! Hanya kluster simpul tunggal saya yang cukup untuk mengikuti langkah 1-6 (tanpa reboot) lalu mengirim SIGHUP ke kube-apiserver . Baru saja menemukan id wadah dengan docker ps dan mengatur sinyal dengan docker kill -s HUP <container id> .

Terima kasih banyak @danroliver! Pada cluster single-master/multi-workers kami, melakukan langkah dari 1 hingga 7 sudah cukup, kami tidak perlu menghubungkan kembali setiap node pekerja ke master (yang merupakan bagian yang paling menyakitkan).

Terima kasih untuk langkah demi langkah yang luar biasa ini, @danroliver! Saya bertanya-tanya bagaimana proses ini dapat diterapkan pada cluster multi-master (bare metal, saat ini menjalankan 1.11.1), dan lebih disukai tanpa downtime. Sertifikat saya belum kedaluwarsa, tetapi saya mencoba mempelajari cara membuat ulang/memperbaruinya sebelum itu terjadi.

@kcronin
silakan lihat dokumen baru ini:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/
semoga membantu.

@danroliver : Terima kasih banyak, ini berhasil.

Tidak perlu me-reboot server.
Cukup dengan membuat ulang pod kube-system (apiserver, schduler, ...) dengan dua perintah ini:

systemctl restart kubelet
untuk saya di $(docker ps | egrep 'admin|controller|scheduler|api|fron|proxy' | rev | awk '{print $1}' | rev);
lakukan docker stop $i; selesai

Saya harus menangani ini juga pada cluster 1,13, dalam kasus saya sertifikat akan kedaluwarsa sehingga sedikit berbeda
Juga berurusan dengan instance master\control tunggal di tempat sehingga tidak perlu khawatir tentang pengaturan HA atau spesifikasi AWS
Belum termasuk langkah mundur seperti yang telah dimasukkan orang lain di atas

Karena sertifikat belum kedaluwarsa, cluster sudah memiliki beban kerja yang saya ingin terus bekerja
Tidak harus berurusan dengan sertifikat etcd saat ini jadi dihilangkan

Jadi pada level tinggi saya harus

• Pada tuannya
  
  
  
  • Hasilkan sertifikat baru pada master
  
  
  • Hasilkan kubeconfig baru dengan sertifikat tersemat
  
  
  • Hasilkan sertifikat kubelet baru - klien dan server
  
  
  • Hasilkan token baru untuk kubelet node pekerja
  
  
• Untuk setiap pekerja
  
  
  
  • Tiriskan pekerja terlebih dahulu pada master
  
  
  • ssh ke pekerja, hentikan kubelet, hapus file dan mulai ulang kubelet
  
  
  • Lepaskan pekerja pada master
  
  
• Pada master di akhir
  
  
  
  • Hapus 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

Mari buat token baru untuk node yang bergabung kembali dengan cluster (Setelah kubelet restart)

# On master
sudo kubeadm token create

Sekarang untuk setiap pekerja - satu per satu

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

ssh ke simpul pekerja

# 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

Kembali ke master dan lepaskan pekerja

kubectl uncordon WORKER-NODE-NAME

Setelah semua pekerja diperbarui - Hapus token - akan kedaluwarsa dalam 24 jam tetapi mari singkirkan itu

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

@pmcgrath Terima kasih telah memposting langkah-langkah itu. Saya berhasil mengikuti mereka dan memperbarui sertifikat saya, dan mendapatkan cluster yang berfungsi.

Jika Anda menggunakan versi kubeadm sebelum 1.8, di mana saya mengerti bahwa rotasi sertifikat #206 diberlakukan (sebagai fitur beta ) atau sertifikat Anda sudah kedaluwarsa, maka Anda perlu memperbarui sertifikat Anda secara manual (atau membuat ulang cluster Anda yang tampaknya beberapa (bukan hanya @kachkaev) akhirnya beralih ke).

Anda perlu SSH ke node master Anda. Jika Anda menggunakan kubeadm >= 1.8 lewati ke 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.

Ada catatan penting di sini. Jika Anda menggunakan AWS, Anda harus secara eksplisit meneruskan parameter --node-name dalam permintaan ini. Jika tidak, Anda akan mendapatkan kesalahan seperti: 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 di log Anda sudo journalctl -u kubelet --all | tail dan Master Node akan melaporkan bahwa itu adalah Not Ready ketika Anda menjalankan kubectl get nodes .

Pastikan untuk mengganti nilai yang diteruskan dalam --apiserver-advertise-address dan --node-name dengan nilai yang benar untuk lingkungan Anda.

$ 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

Jika Anda tidak memiliki token yang valid. Anda dapat membuatnya dengan:

$ kubeadm token create

Token akan terlihat seperti 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

Semoga ini membawa Anda ke tempat yang Anda inginkan @davidcomeyne.

Inilah yang saya butuhkan hanya untuk 1.14.2 .. ada petunjuk tentang cara

Saya harus menangani ini juga pada cluster 1,13, dalam kasus saya sertifikat akan kedaluwarsa sehingga sedikit berbeda
Juga berurusan dengan instance master\control tunggal di tempat sehingga tidak perlu khawatir tentang pengaturan HA atau spesifikasi AWS
Belum termasuk langkah mundur seperti yang telah dimasukkan orang lain di atas

Karena sertifikat belum kedaluwarsa, cluster sudah memiliki beban kerja yang saya ingin terus bekerja
Tidak harus berurusan dengan sertifikat etcd saat ini jadi dihilangkan

Jadi pada level tinggi saya harus

* 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

Mari buat token baru untuk node yang bergabung kembali dengan cluster (Setelah kubelet restart)

# On master
sudo kubeadm token create

Sekarang untuk setiap pekerja - satu per satu

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

ssh ke simpul pekerja

# 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

Kembali ke master dan lepaskan pekerja

kubectl uncordon WORKER-NODE-NAME

Setelah semua pekerja diperbarui - Hapus token - akan kedaluwarsa dalam 24 jam tetapi mari singkirkan itu

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

Saya tahu masalah ini sudah selesai tetapi saya memiliki masalah yang sama pada 1.14.2 dan panduan ini tidak memberikan kesalahan tetapi saya tidak dapat terhubung ke cluster dan menerbitkan ulang token (saya gagal auth)

Cluster k8s yang dibuat menggunakan kubeadm v1.9.x mengalami masalah yang sama ( apiserver-kubelet-client.crt kedaluwarsa pada 2 Juli) pada usia v1.14.1 lol

Saya harus merujuk ke 4 sumber berbeda untuk memperbarui sertifikat, membuat ulang file konfigurasi, dan mengembalikan kluster 3 simpul sederhana.

@danroliver memberikan
[Memperbarui sertifikat cluster Kubernetes] dari IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

CATATAN: IBM Financial Crimes Insight dengan Watson private didukung oleh k8s, tidak pernah tahu itu.

Masalah dengan langkah 3 dan langkah 5

Langkah 3 TIDAK seharusnya memiliki fase dalam perintah

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

Langkah 5 harus menggunakan di bawah ini, kubeadm alpha tidak memiliki kubeconfig semua, itu adalah fase init kubeadm sebagai gantinya

# 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

di 1.15 kami telah menambahkan dokumentasi yang lebih baik untuk pembaruan sertifikat:
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

juga, setelah 1,15 kubeadm upgrade secara otomatis akan memperbarui sertifikat untuk Anda!

Cluster k8s yang dibuat menggunakan kubeadm v1.9.x mengalami masalah yang sama (apiserver-kubelet-client.crt kedaluwarsa pada 2 Juli) pada usia v1.14.1 lol

versi yang lebih lama dari 1.13 sudah tidak didukung.
kami sangat mendorong pengguna untuk mengikuti proyek yang bergerak cepat ini.

saat ini ada diskusi yang sedang berlangsung oleh Kelompok Kerja LongTermSupport , agar versi kubernetes didukung untuk jangka waktu yang lebih lama, tetapi menetapkan prosesnya mungkin memakan waktu cukup lama.

Terima kasih @pmorie .
Bekerja untuk kube versi 1.13.6

Sekedar komentar dan permintaan fitur: Kedaluwarsa sertifikat ini telah kami produksi di klaster Kubernetes 1.11.x pagi ini. Kami mencoba semuanya di atas (dan ke tautan), tetapi menemukan banyak kesalahan, menyerah setelah beberapa jam benar-benar terjebak dengan kluster selang besar. Untungnya, kami tinggal sekitar 2 minggu lagi untuk mengupgrade ke Kubernetes 1.15 (dan membangun cluster baru) sehingga kami akhirnya hanya membuat cluster 1,15 baru dari awal dan menyalin semua data pengguna kami.

Saya sangat berharap ada peringatan sebelum ini terjadi. Kami baru saja beralih dari "cluster yang sangat stabil" menjadi "mimpi buruk yang benar-benar hancur" tanpa peringatan apa pun, dan mungkin mengalami downtime terburuk yang pernah kami alami. Untungnya, itu adalah pantai barat pada Jumat sore, jadi dampak yang relatif minimal.

Dari semua yang dibahas di atas dan di semua tiket yang ditautkan, satu hal yang akan membuat banyak orang
perbedaan bagi kami tidak disebutkan: mulailah menampilkan peringatan ketika sertifikat akan segera kedaluwarsa . (Misalnya, jika Anda menggunakan kubectl, dan sertifikat akan kedaluwarsa dalam beberapa minggu, beri tahu saya!).

Maaf untuk masalah Anda. Biasanya itu adalah tanggung jawab operator
untuk memantau sertifikat pada disk untuk kedaluwarsa. Tapi saya setuju bahwa kekurangannya
pemantauan yang mudah dapat menyebabkan masalah. Itulah salah satu alasan kami menambahkan
perintah untuk memeriksa masa berlaku sertifikat di kubeadm. Lihat
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/

Harap perhatikan juga bahwa setelah 1,15 kubeadm akan memperbarui sertifikat secara otomatis pada
meningkatkan. Yang mendorong pengguna untuk meningkatkan lebih sering juga.
Pada 20 Juli 2019 03:49, "William Stein" [email protected] menulis:

Hanya komentar dan permintaan fitur: Kedaluwarsa sertifikat ini menimpa kami
produksi di cluster Kubernetes 1.11.x kami pagi ini. Kami sudah mencoba
semua yang ada di atas (dan ke tautan), tetapi mengalami banyak kesalahan, menyerah setelah a
beberapa jam benar-benar terjebak dengan cluster disemprot besar. Untung,
kami sekitar 2 minggu lagi untuk meningkatkan ke Kubernetes 1.15 (dan membangun
cluster baru) jadi kami akhirnya hanya membuat cluster 1,15 baru dari awal
dan menyalin semua data pengguna kami.

Saya sangat berharap ada peringatan sebelum ini terjadi. Kami hanya
berubah dari "kluster yang sangat stabil" menjadi "benar-benar rusak parah
mimpi buruk" tanpa peringatan apa pun, dan mungkin mengalami waktu henti terburuk yang pernah kami alami.
Untungnya, itu adalah pantai barat Jumat sore, jadi relatif minim
berdampak.

Dari semua yang dibahas di atas dan di semua tiket terkait, satu hal
yang akan membuat besar
perbedaan bagi kami tidak disebutkan: mulai tampilkan peringatan saat sertifikatakan segera berakhir . (Misalnya, jika Anda menggunakan kubectl, dan sertifikatnya adalah
akan kedaluwarsa dalam beberapa minggu, tolong beri tahu saya!).

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
Https://github.com/kubernetes/kubeadm/issues/581?email_source=notifications&email_token=AACRATDWBQHYVVRG4LYVTXLQAJOJHA5CNFSM4EGBFHKKYY3PNVWWK3TUL52HS4DFVREXG43VMWSW2ZD4ORPWWZGOZD2NC5134XHJKTissue
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AACRATC437G4OZ3ZOEQM5LLQAJOJHANCNFSM4EGBFHKA
.

@neolit123 Terima kasih; kami akan menambahkan sesuatu ke infrastruktur pemantauan kami sendiri untuk secara berkala memeriksa masalah sertifikat yang akan datang, seperti yang dijelaskan dalam komentar Anda.

@danroliver Terima kasih banyak atas balasan Anda. Itu menghemat banyak waktu bagi saya.
Satu poin yang layak disebutkan adalah sertifikat terkait "etcd", yang harus diperbarui dengan cara yang sama. Tidak perlu memuat ulang konfigurasi karena digunakan dalam file metadata YAML sebagai referensi.

Untuk Kubernetes v1.14 saya menemukan prosedur yang diusulkan oleh @desdic ini yang paling membantu:

• https://stackoverflow.com/a/56334732/1147487
  
  
  
  • buat cadangan dan buat ulang semua sertifikat:
  
  

$ 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>

• backup dan buat ulang semua file kubeconfig:

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

• salin admin.conf :

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

Untuk Kubernetes v1.14 saya menemukan prosedur ini yang paling membantu:

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

Saya membuat perbaikan setelah cluster saya sendiri diperbaiki .. berharap orang lain dapat menggunakannya

@danroliver memberikan
[Memperbarui sertifikat cluster Kubernetes] dari IBM WoW! (https://www.ibm.com/support/knowledgecenter/en/SSCKRH_1.1.0/platform/t_certificate_renewal.html)

Bagus! Saya bertanya-tanya kapan ini diterbitkan. Saya pasti akan menemukan ini membantu ketika saya sedang melalui ini.

Catatan tentang token di K8 1.13.x (mungkin versi K8 lainnya)
Jika Anda akhirnya membuat ulang sertifikat CA Anda ( /etc/kubernetes/pki/ca.crt ), token Anda (lihat kubectl -n kube-system get secret | grep token ) mungkin memiliki CA lama, dan harus dibuat ulang. Token bermasalah termasuk kube-proxy-token , coredns-token dalam kasus saya (dan lainnya), yang menyebabkan layanan cluster-critical tidak dapat mengautentikasi dengan K8s API.
Untuk membuat ulang token, hapus token lama, dan token tersebut akan dibuat ulang.
Hal yang sama berlaku untuk layanan apa pun yang berbicara dengan K8s API, seperti PV Provisioner, Ingress Controllers, cert-manager , dll.

Terima kasih untuk langkah demi langkah yang luar biasa ini, @danroliver! Saya bertanya-tanya bagaimana proses ini dapat diterapkan pada cluster multi-master (bare metal, saat ini menjalankan 1.11.1), dan lebih disukai tanpa downtime. Sertifikat saya belum kedaluwarsa, tetapi saya mencoba mempelajari cara membuat ulang/memperbaruinya sebelum itu terjadi.

Hai @kcronin , bagaimana Anda menyelesaikannya dengan konfigurasi multi-master? Saya tidak tahu bagaimana melanjutkan dengan --apiserver-advertise-addresskarena saya memiliki 3 IP dan tidak hanya satu.

Terima kasih

@pmcgrath Jika saya memiliki 3 master, haruskah saya mengulangi langkah-langkah pada setiap master? atau apa itu. kasus

@SuleimanWA , Anda dapat menyalin admin.conf atas, serta file CA, jika CA dibuat ulang.
Untuk yang lainnya, Anda harus mengulangi langkah-langkah untuk membuat ulang sertifikat (untuk etcd, kubelet, scheduler, dll.) pada setiap master

@anapsix
Saya menjalankan cluster 1.13.x, dan apiserver melaporkan 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] setelah saya memperbarui sertifikat dengan menjalankan kubeadm alpha certs renew all .

Untuk membuat ulang token, hapus token lama, dan token tersebut akan dibuat ulang.

Token mana yang Anda maksud dalam kasus ini? Apakah yang dihasilkan oleh kubeadm atau bagaimana cara menghapus token?

-----MEMPERBARUI-----
Saya tahu itu rahasianya sendiri. Dalam kasus saya, kube-controller tidak aktif sehingga rahasianya tidak dibuat secara otomatis.

penggunaan versi tinggi：

kubeadm alpha certs memperbarui semua

Ketika kubelet master node pertama down (systemctl stop kubelet), master node lain tidak dapat menghubungi CA pada master node pertama. Ini menghasilkan pesan berikut hingga kubelet pada master node asli kembali online:

kubectl dapatkan node
Kesalahan dari server (InternalError): kesalahan pada server ("") telah mencegah permintaan berhasil (mendapatkan node)

Apakah ada cara agar peran CA ditransfer ke node master lain saat kublet pada node CA asli turun?

@anapsix
Saya menjalankan cluster 1.13.x, dan apiserver melaporkan 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] setelah saya memperbarui sertifikat dengan menjalankan kubeadm alpha certs renew all .

Untuk membuat ulang token, hapus token lama, dan token tersebut akan dibuat ulang.

Token mana yang Anda maksud dalam kasus ini? Apakah yang dihasilkan oleh kubeadm atau bagaimana cara menghapus token?

-----MEMPERBARUI-----
Saya tahu itu rahasianya sendiri. Dalam kasus saya, kube-controller tidak aktif sehingga rahasianya tidak dibuat secara otomatis.

Hai, saya telah melakukan tugas ini tetapi tidak pada versi 1.13. Bolehkah saya menanyakan beberapa hal jika Anda sudah melakukan ini?
Jadi pada dasarnya saya akan melakukan:
kubeadm alpha certs memperbaharui semua (yang memperbarui folder control plane cert uber pki/ pada Masters).
kubeadm init fase kubeconfig untuk memperbarui file konfigurasi kube. (Pada Guru dan pekerja).
Mulai ulang kubelet di semua node.

Apakah saya masih perlu membuat token dan menjalankan join pada node pekerja? Jika memungkinkan, dapatkah Anda membagikan langkah-langkah yang Anda lakukan?