Dokumen ini menjelaskan cara memperpanjang sertifikat yang sudah tidak berlaku secara manual untuk Google Distributed Cloud Anda. Sertifikat Transport Layer Security (TLS) digunakan oleh komponen bidang kontrol Google Distributed Cloud. Saat masa berlaku sertifikat ini berakhir, kemampuan Anda untuk mengelola workload dan siklus proses cluster akan diblokir hingga sertifikat dapat diperpanjang. Untuk mengetahui informasi selengkapnya tentang dampak sertifikat yang sudah tidak berlaku, lihat Masa berlaku sertifikat.
Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta merespons pemberitahuan dan halaman saat sasaran tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
Secara default, sertifikat TLS memiliki periode habis masa berlaku 1 tahun. Google Distributed Cloud memperpanjang sertifikat ini secara otomatis selama upgrade cluster dan saat Anda Memutar certificate authority. Sebaiknya upgrade cluster Anda secara rutin agar tetap aman, didukung, dan mencegah masa berlaku sertifikat TLS berakhir.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.
Error yang disebabkan oleh habis masa berlaku sertifikat
Jika sertifikat TLS di cluster Anda berakhir masa berlakunya, pengontrol inti tidak dapat membuat koneksi TLS dengan server Kubernetes API. Kurangnya konektivitas ini menyebabkan error berikut:
Tidak dapat terhubung ke server: x509
Saat Anda menggunakan
kubectl
untuk mendapatkan node cluster, respons akan menyertakan error bahwa masa berlaku sertifikat Anda telah habis, mirip dengan contoh output berikut:Unable to connect to the server: x509: certificate has expired or is not yet valid
tidak dapat terhubung: x509 atau koneksi ditolak
Sertifikat yang sudah tidak berlaku akan memblokir akses ke cluster etcd, karena peer tidak dapat saling berkomunikasi. Log etcd mungkin berisi entri error seperti berikut:
W | rafthttp: health check for peer 6221a1d241bb2d0a could not connect: x509: certificate has expired or is not yet valid I | embed: rejected connection from "10.200.0.4:46108" (error "remote error: tls: bad certificate", ServerName "")
Memeriksa waktu habis masa berlaku sertifikat
Untuk memeriksa waktu habis masa berlaku sertifikat, lakukan langkah-langkah berikut di setiap node panel kontrol:
Login ke salah satu mesin node bidang kontrol dan jalankan perintah berikut:
sudo kubeadm certs check-expiration
Output perintah mencantumkan sertifikat yang dibuat oleh
kubeadm
untuk komponen bidang kontrol dan masa berlakunya, seperti yang ditunjukkan dalam contoh output berikut:CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Nov 28, 2021 19:09 UTC 53m no apiserver Nov 28, 2021 19:09 UTC 53m ca no apiserver-etcd-client Nov 28, 2021 19:09 UTC 53m etcd-ca no apiserver-kubelet-client Nov 28, 2021 19:09 UTC 53m ca no controller-manager.conf Nov 28, 2021 19:09 UTC 53m no etcd-healthcheck-client Nov 28, 2021 19:09 UTC 53m etcd-ca no etcd-peer Nov 28, 2021 19:09 UTC 53m etcd-ca no etcd-server Nov 28, 2021 19:09 UTC 53m etcd-ca no front-proxy-client Nov 28, 2021 19:09 UTC 53m front-proxy-ca no scheduler.conf Nov 28, 2021 19:09 UTC 53m no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Nov 26, 2031 18:06 UTC 9y no etcd-ca Nov 26, 2031 18:06 UTC 9y no front-proxy-ca Nov 26, 2031 18:06 UTC 9y no
Jalankan perintah berikut untuk memeriksa waktu habis masa berlaku sertifikat
kubelet
:sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
Respons untuk setiap perintah terlihat seperti contoh output berikut:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Jika semua node bidang kontrol telah di-bootstrap secara bersamaan, maka waktu habis masa berlaku sertifikat akan berbeda beberapa menit. Hubungan waktu ini berlaku di semua node bidang kontrol. Anda dapat memverifikasi waktu habis masa berlaku dengan menjalankan perintah sebelumnya di setiap node bidang kontrol.
Jalankan perintah berikut di workstation admin untuk memeriksa waktu habis masa berlaku sertifikat klien dalam file kubeconfig cluster:
grep 'client-certificate-data' KUBECONFIG_PATH | \ awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
Responsnya akan terlihat seperti contoh output ini:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Jalankan perintah berikut untuk mencari masa berlaku sertifikat untuk kubeconfig cluster di cluster admin:
kubectl get secret/CLUSTER_NAME-kubeconfig -n CLUSTER_NAMESPACE -o --kubeconfig=ADMIN_KUBECONFIG jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2
Responsnya akan terlihat seperti contoh output ini:
Validity Not Before: Sep 17 22:27:53 2021 GMT Not After : Sep 17 22:33:16 2022 GMT
Sertifikat kubeconfig di cluster admin dan sertifikat dalam file kubeconfig di workstation admin sama. Oleh karena itu, output untuk perintah ini dan perintah dari langkah sebelumnya harus cocok.
Memperpanjang sertifikat secara manual
Untuk memperpanjang sertifikat TLS secara manual untuk cluster, gunakan petunjuk di bagian berikut.
Memperpanjang sertifikat di setiap node bidang kontrol
Lakukan langkah-langkah berikut di setiap node panel kontrol cluster yang terpengaruh:
Cadangkan folder
/etc/kubernetes
.Jalankan perintah
kubeadm
berikut untuk memperpanjang semua sertifikat. Perintah ini akan memperpanjang sertifikat menggunakan Certificate Authority (CA) yang ada di mesin:sudo kubeadm certs renew all
Output perintah mirip dengan contoh berikut:
certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself renewed certificate for serving the Kubernetes API renewed certificate the apiserver uses to access etcd renewed certificate for the API server to connect to kubelet renewed certificate embedded in the kubeconfig file for the controller manager to use renewed certificate for liveness probes to healthcheck etcd renewed certificate for etcd nodes to communicate with each other renewed certificate for serving etcd renewed certificate for the front proxy client renewed certificate embedded in the kubeconfig file for the scheduler manager to use renewed
Pastikan bahwa sertifikat memiliki waktu habis masa berlaku baru dengan menjalankan perintah berikut:
sudo kubeadm certs check-expiration
Tidak semua komponen bidang kontrol mendukung pemuatan ulang sertifikat dinamis. Untuk mengambil sertifikat yang diperpanjang, langkah-langkah berikut akan memulai ulang penampung berikut:
kube-apiserver
,kube-scheduler
,kube-controller-manager
, danetcd
.Ulangi langkah-langkah berikut untuk setiap dari empat penampung:
Temukan ID penampung untuk setiap penampung:
sudo crictl ps | grep CONTAINER_NAME
Ganti
CONTAINER_NAME
dengan nama penampung berikut:kube-apiserver
,kube-scheduler
,kube-controller-manager
, atauetcd
(bukanetcd-defrag
).Responsnya mirip dengan output berikut:
c331ade490cb6 28df10594cd92 26 hours ago Running kube-apiserver ...
ID penampung adalah nilai di kolom pertama.
Hentikan setiap penampung:
sudo crictl stop CONTAINER_ID
Ganti CONTAINER_ID dengan ID penampung dari langkah sebelumnya.
Saat penampung yang dihentikan keluar, kubelet akan membuat penampung baru sebagai penggantinya dan menghapus penampung yang dihentikan. Jika Anda mengalami error, seperti
context deadline exceeded
(kode errorDeadlineExceeded
), jalankan kembali perintah tersebut.
Memverifikasi bahwa konektivitas telah dipulihkan
Sekarang, sertifikat kubeadm harus diperpanjang di semua node bidang kontrol. Jika Anda memperpanjang sertifikat yang sudah tidak berlaku, lakukan langkah berikut:
Untuk memverifikasi koneksi dengan server Kubernetes API, jalankan perintah
kubectl
berikut di node bidang kontrol mana pun:kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf
Respons akan menampilkan daftar node untuk cluster. Jika sertifikat Anda diperpanjang dengan benar, tidak akan ada error TLS atau sertifikat yang ditampilkan.
Mengganti file kubeconfig cluster
Untuk mengganti file kubeconfig untuk cluster Anda dengan file yang memiliki sertifikat yang diperpanjang, gunakan langkah-langkah berikut:
Untuk membuat file kubeconfig baru, jalankan perintah
kubectl
berikut di workstation admin:kubectl --kubeconfig="ADMIN_KUBECONFIG" get secret/CLUSTER_NAME-kubeconfig \ -n "CLUSTER_NAMESPACE" -o jsonpath='{.data.value}' | base64 --decode > new_kubeconfig.conf
Ganti kode berikut:
ADMIN_KUBECONFIG: jalur ke file kubeconfig cluster admin.
CLUSTER_NAME: nama cluster yang sertifikatnya akan Anda perbarui.
CLUSTER_NAMESPACE: namespace cluster yang sertifikatnya Anda perbarui.
File
new_kubeconfig.conf
berisi data sertifikat yang diperbarui.Verifikasi bahwa kubeconfig baru berfungsi dengan menjalankan perintah
kubectl
apa pun, menggunakan kredensial baru:kubectl get nodes --kubeconfig new_kubeconfig.conf
Ganti konten file kubeconfig lama yang disimpan di direktori cluster di workstation admin dengan konten file kubeconfig baru
new-kubeconfig.conf
.Secara default, jalur ke file konfigurasi cluster adalah
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig
.
Memverifikasi sertifikat kubelet dan memulai ulang etcd-defrag
Untuk menyelesaikan proses perpanjangan sertifikat cluster secara manual, lakukan langkah-langkah berikut untuk setiap node bidang kontrol:
Login ke node bidang kontrol dan verifikasi klien kubelet dan waktu habis masa berlaku sertifikat layanan dengan menjalankan perintah berikut:
Sertifikat kubelet dirotasi secara otomatis selama bidang kontrol dapat dijangkau. Periode perpanjangan otomatis sertifikat kubelet lebih singkat daripada periode habis masa berlaku sertifikat komponen bidang kontrol. Oleh karena itu, kemungkinan sertifikat kubelet telah diperpanjang sebelumnya:
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -text | grep Validity -A2 sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -text | grep Validity -A2
Output dari kedua perintah tersebut akan terlihat seperti contoh berikut:
Validity Not Before: Nov 28 18:04:57 2022 GMT Not After : Nov 28 19:04:57 2023 GMT
Gunakan perintah berikut untuk memulai ulang penampung
etcd-defrag
:Penampung
etcd-defrag
menggunakan sertifikat klienapiserver-etcd
untuk berkomunikasi dengan etcd dan harus dimulai ulang untuk mengambil sertifikat yang diperbarui.kubectl rollout restart daemonset etcd-defrag -n kube-system --kubeconfig KUBECONFIG_PATH
Setelah Anda menyelesaikan langkah-langkah manual ini untuk memperpanjang sertifikat cluster, pastikan semua Pod berjalan dengan benar dan tidak ada error TLS yang dilaporkan untuk penampung platform kontrol.
Langkah selanjutnya
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.