Memperpanjang sertifikat cluster yang sudah tidak berlaku secara manual

Dokumen ini menjelaskan cara memperpanjang sertifikat yang telah habis masa berlakunya secara manual untuk Google Distributed Cloud Anda. Sertifikat Transport Layer Security (TLS) digunakan oleh komponen bidang kontrol Google Distributed Cloud. Jika sertifikat ini berakhir masa berlakunya, kemampuan Anda untuk mengelola siklus proses cluster dan workload akan diblokir hingga sertifikat dapat diperpanjang. Untuk mengetahui informasi selengkapnya tentang dampak sertifikat yang telah habis masa berlakunya, lihat Masa berlaku sertifikat.

Halaman ini ditujukan untuk Admin, arsitek, dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta menanggapi pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna umum GKE Enterprise. Google Cloud

Secara default, sertifikat TLS, termasuk sertifikat etcd, memiliki periode habis masa berlaku 1 tahun. Google Distributed Cloud memperpanjang sertifikat ini selama upgrade cluster dan saat Anda Merotasi otoritas sertifikat. Sertifikat ini tidak diperbarui secara berkala dengan sendirinya. Sebaiknya upgrade cluster Anda secara rutin agar tetap aman, didukung, dan untuk mencegah masa berlaku sertifikat TLS berakhir.

Error yang disebabkan oleh masa berlaku sertifikat yang telah habis

Jika sertifikat TLS di cluster Anda sudah tidak berlaku, 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 sertifikat Anda telah habis masa berlakunya, 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 habis masa berlakunya akan memblokir akses ke cluster etcd, karena peer tidak dapat berkomunikasi satu sama lain. 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:

  1. 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 control plane 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

  2. 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 akan 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 berdekatan dalam hitungan 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.

  3. 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

  4. Jalankan perintah berikut untuk mencari masa berlaku sertifikat untuk kubeconfig cluster di cluster admin:

    kubectl get secret/CLUSTER_NAME-kubeconfig \
  -n CLUSTER_NAMESPACE \
  --kubeconfig=ADMIN_KUBECONFIG \
  -o jsonpath='{.data.value}' | base64 --decode | grep client-certificate-data | awk '{print $2}' | base64 -d | openssl x509 -text | grep Validity -A2

    Ganti kode berikut:

    * ADMIN_KUBECONFIG: the
  path to the admin cluster kubeconfig file.

* CLUSTER_NAME:
  the name of the cluster that you're renewing certificates for.

* CLUSTER_NAMESPACE:
  the namespace of the cluster that you're renewing certificates for.

    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:

  1. Cadangkan folder /etc/kubernetes.

  2. Jalankan perintah kubeadm berikut untuk memperpanjang semua sertifikat. Perintah 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

  3. Pastikan bahwa sertifikat memiliki waktu habis masa berlaku baru dengan menjalankan perintah berikut:

    sudo kubeadm certs check-expiration

  4. 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, dan etcd.

    Ulangi langkah-langkah berikut untuk setiap dari empat penampung:

    1. 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, atau etcd (bukan etcd-defrag).

      Responsnya mirip dengan output berikut:

      c331ade490cb6       28df10594cd92      26 hours ago       Running          kube-apiserver ...

      ID penampung adalah nilai di kolom pertama.

      .

    2. Hentikan setiap container:

      sudo crictl stop CONTAINER_ID

      Ganti CONTAINER_ID dengan ID penampung dari langkah sebelumnya.

      Saat container yang dihentikan keluar, kubelet akan membuat container baru di tempatnya dan menghapus container yang dihentikan. Jika Anda mengalami error, seperti context deadline exceeded (kode error DeadlineExceeded), jalankan kembali perintah.

Memastikan konektivitas dipulihkan

Sertifikat kubeadm kini harus diperpanjang di semua node bidang kontrol. Jika Anda memperpanjang sertifikat yang sudah habis masa berlakunya, lakukan langkah berikut:

  • Untuk memverifikasi koneksi dengan server Kubernetes API, jalankan perintah kubectl berikut pada node bidang kontrol mana pun:

    kubectl get nodes --kubeconfig=/etc/kubernetes/admin.conf

Respons harus menampilkan daftar node untuk cluster. Jika sertifikat Anda diperpanjang dengan benar, tidak ada error TLS atau sertifikat yang ditampilkan.

Memperbarui secret kubeconfig di cluster

Perbarui secret kubeconfig dari konten file admin.conf.

Untuk mengupdate kubeconfig baru ke secret, jalankan perintah berikut di node panel kontrol:

CLUSTER_KUBECONFIG_BASE64=$(base64 /etc/kubernetes/admin.conf -w 0)

kubectl get secret/CLUSTER_NAME-kubeconfig \
  -n CLUSTER_NAMESPACE \
  –kubeconfig /etc/kubernetes/admin.conf -o json | jq \
  --arg conf "${CLUSTER_KUBECONFIG_BASE64}" '.data."value" |= $conf' | kubectl apply -f -

Mengganti file kubeconfig cluster

Untuk mengganti file kubeconfig cluster Anda dengan file yang memiliki sertifikat yang diperpanjang, gunakan langkah-langkah berikut:

  1. 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 Anda perpanjang.

    • CLUSTER_NAMESPACE: namespace cluster tempat Anda memperpanjang sertifikat.

    File new_kubeconfig.conf berisi data sertifikat yang diperbarui.

  2. Verifikasi bahwa kubeconfig baru berfungsi dengan menjalankan perintah kubectl apa pun, menggunakan kredensial baru:

    kubectl get nodes --kubeconfig new_kubeconfig.conf

  3. 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.

Verifikasi sertifikat kubelet dan mulai ulang etcd-defrag

Untuk menyelesaikan proses memperpanjang sertifikat cluster secara manual, lakukan langkah-langkah berikut untuk setiap node bidang kontrol:

  1. Login ke node bidang kontrol dan verifikasi waktu habis masa berlaku sertifikat klien dan penayangan kubelet 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 akan terlihat seperti contoh berikut:

    Validity
    Not Before: Nov 28 18:04:57 2022 GMT
    Not After : Nov 28 19:04:57 2023 GMT

  2. Gunakan perintah berikut untuk memulai ulang container etcd-defrag:

    Kontainer etcd-defrag menggunakan sertifikat klien apiserver-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, verifikasi bahwa semua Pod berjalan dengan benar dan tidak ada error TLS yang dilaporkan untuk penampung bidang kontrol.

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care. Anda juga dapat melihat bagian Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:

  • Persyaratan untuk membuka kasus dukungan.
  • Alat untuk membantu Anda memecahkan masalah, seperti konfigurasi lingkungan, log, dan metrik.
  • Komponen yang didukung.