Cluster Anthos di VMware kini menjadi Google Distributed Cloud (khusus software) untuk VMware. Untuk mengetahui informasi selengkapnya, lihat ringkasan produk.

Halaman ini diterjemahkan oleh Cloud Translation API.

Merotasi certificate authority cluster pengguna

Google Distributed Cloud menggunakan sertifikat dan kunci pribadi untuk mengotentikasi dan mengenkripsi koneksi antar komponen sistem dalam cluster pengguna. Cluster admin membuat kumpulan certificate authority (CA) baru untuk setiap cluster pengguna, dan menggunakan sertifikat CA untuk menerbitkan leaf tambahan sertifikat untuk komponen sistem. Cluster admin mengelola distribusi sertifikat CA publik dan pasangan kunci {i>leaf certificate<i} ke komponen sistem untuk membangun komunikasi yang aman dengan mereka.

Fitur rotasi CA cluster pengguna memungkinkan Anda memicu rotasi sertifikat sistem inti di cluster pengguna. Selama rotasi, cluster admin menggantikan CA sistem inti untuk cluster pengguna dengan CA yang baru dibuat, dan mendistribusikan sertifikat CA publik yang baru dan pasangan kunci sertifikat entitas akhir ke komponen sistem cluster pengguna. Rotasi terjadi secara bertahap, sehingga komponen sistem dapat terus berkomunikasi selama rotasi. Namun, perlu diketahui bahwa workload dan node dimulai ulang selama rotasi.

Ada tiga CA sistem yang dikelola oleh cluster admin untuk setiap cluster pengguna:

CA {i>etcd<i} mengamankan komunikasi dari server API ke replika {i>etcd<i} dan juga traffic antara replika etcd. CA ini ditandatangani sendiri.
CA cluster mengamankan komunikasi antara server API dan semua Klien Kubernetes API (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
CA {i>front-proxy<i} mengamankan komunikasi dengan API gabungan. CA ini ditandatangani sendiri.

Selain itu, Anda mungkin menggunakan CA org untuk menandatangani sertifikat yang dikonfigurasi oleh opsi authentication.sni. CA dan sertifikat SNI ini digunakan untuk menyalurkan Kubernetes API ke klien di luar cluster. Anda mengelola CA ini dan membuat SNI secara manual CA {i>root<i}. Baik CA ini maupun sertifikat SNI tidak terpengaruh oleh pengguna fitur rotasi CA cluster.

Batasan

Rotasi sertifikat CA terbatas untuk {i>etcd<i}, {i>cluster<i}, dan CA {i>front-proxy<i} yang disebutkan sebelumnya.
Rotasi sertifikat CA dibatasi pada sertifikat yang diterbitkan secara otomatis oleh Google Distributed Cloud. Alat ini tidak memperbarui sertifikat yang diterbitkan secara manual oleh administrator, meskipun sertifikat tersebut ditandatangani oleh CA sistem.
Rotasi CA memulai ulang server API, proses bidang kontrol lainnya, dan setiap node dalam cluster beberapa kali. Setiap tahap rotasi CA prosesnya mirip dengan upgrade cluster. Meskipun cluster pengguna operasional selama rotasi CA, Anda harus memperkirakan bahwa beban kerja dimulai ulang dan dijadwalkan ulang. Anda juga harus memperkirakan periode singkat periode nonaktif bidang kontrol jika cluster pengguna tidak memiliki bidang kontrol ketersediaan tinggi.
Anda harus memperbarui file kubeconfig cluster pengguna dan autentikasi file konfigurasi setelah rotasi CA. Hal ini karena gugus lama dicabut, dan kredensial dalam file kubeconfig tidak pekerjaan yang lebih lama.
Setelah dimulai, rotasi CA tidak dapat dijeda atau di-roll back.
Rotasi CA mungkin membutuhkan waktu yang cukup lama untuk diselesaikan, tergantung pada ukuran cluster pengguna.

Melakukan rotasi CA

Mulai rotasi:

gkectl update credentials certificate-authorities rotate \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Ganti kode berikut:

USER_CLUSTER_CONFIGE: jalur cluster pengguna file konfigurasi
ADMIN_CLUSTER_KUBECONFIG: jalur cluster admin file kubeconfig

Jika rotasi CA berhasil dimulai, Anda akan melihat pesan yang mirip dengan ini:

successfully started the CA rotation with CAVersion 2, use gkectl update credentials certificate-authorities status command to view the current state of CA rotation

Jika rotasi CA sedang berlangsung, Anda akan melihat error yang mirip dengan pesan ini:

Exit with error:
admission webhook "vonpremusercluster.onprem.cluster.gke.io" denied the request: requests must not modify CAVersion when cluster is not ready: ready condition is not true: ClusterCreateOrUpdate: Creating or updating user cluster control plane workloads

Lihat status rotasi:

gkectl update credentials certificate-authorities status \
    --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Perintah sebelumnya melaporkan CAVersion, yang merupakan bilangan bulat secara otomatis bertambah untuk membedakan CA yang digunakan sebelum dan setelah satu rotasi. Perintah tersebut juga melaporkan status (True atau False) yang menunjukkan apakah rotasi CA selesai, dan pesan yang menjelaskan CAVersion mana yang saat ini digunakan oleh setiap komponen sistem.

Jika rotasi CA sudah selesai, Anda akan melihat pesan yang mirip dengan ini:

State of CARotation with CAVersion 2 is -
status: True,
reason: CARotationCompleted,
message: Control plane has CA bundle [2], certs from CA 2, CA 2 is CSR signer. Data plane has CA bundle [2], CA 2 was CSR signer at last restart.

Jika rotasi CA masih berlangsung, Anda akan melihat pesan yang serupa dengan ini:

State of CARotation with CAVersion 2 is -
status: False,
reason: CARotationProgressed,
message: Control plane has CA bundle [1 2], certs from CA 2, CA 1 is CSR signer. Data plane has CA bundle [1 2], CA 1 was CSR signer at last restart.

Memperbarui kredensial cluster pengguna

Setelah rotasi CA selesai, Anda harus mendapatkan kubeconfig cluster pengguna baru dari cluster admin. Hal ini karena rotasi CA mencabut CA yang menjadi dasar file {i>kubeconfig<i}.

Dapatkan file kubeconfig yang baru:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret admin \
    -n USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}' \
    | base64 --decode > USER_CLUSTER_NAME-kubeconfig

Distribusikan file {i>kubeconfig<i} baru ke semua orang yang menggunakan file {i>kubeconfig<i} untuk berinteraksi dengan cluster.

Memperbarui file konfigurasi autentikasi

Setelah rotasi CA selesai, file konfigurasi autentikasi harus diperbarui dan didistribusikan ulang. Ikuti petunjuk tertaut untuk memperbarui dan mendistribusikan ulang file ini setelah rotasi CA:

Rotasi sertifikat bidang kontrol

Tanpa rotasi, CA cluster pengguna dan sertifikat bidang kontrol berakhir lima tahun sejak tanggal cluster dibuat. Cluster pengguna sertifikat bidang kontrol akan otomatis dirotasi dalam waktu sepuluh jam setelah upgrade cluster pengguna, tetapi CA tidak dirotasi secara otomatis. Ini berarti Rotasi CA harus dilakukan setidaknya sekali setiap lima tahun selain peningkatan versi reguler.

Untuk mencegah cluster pengguna menjadi tidak tersedia, sertifikat bidang kontrol akan dirotasi dalam waktu sepuluh jam setelah upgrade cluster pengguna. Jika akan muncul pesan dalam status rotasi CA cluster pengguna.

Untuk melihat versi terakhir, cluster pengguna telah diupgrade saat bidang kontrol sertifikat telah dirotasi:

gkectl update credentials certificate-authorities status \
--config USER_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG

Informasi akan muncul di akhir kolom message dalam waktu sepuluh jam setelah {i>upgrade.<i} Contoh:

Last Leaf Certificates Rotation Version: 1.16.0-gke.0.

Memecahkan masalah rotasi CA

Perintah gkectl diagnose mendukung pemeriksaan status yang diharapkan dari rotasi CA yang telah selesai pada cluster pengguna. Untuk petunjuk tentang cara menjalankan gkectl diagnose di cluster pengguna, lihat Mendiagnosis masalah cluster. Jika Anda mengalami masalah dengan rotasi CA, hubungi tim dukungan Google dan memberikan output gkectl diagnose.