Halaman ini diterjemahkan oleh Cloud Translation API.

Merotasi certificate authority cluster pengguna
Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Google Distributed Cloud menggunakan sertifikat dan kunci pribadi untuk mengautentikasi dan mengenkripsi koneksi antar-komponen sistem di cluster pengguna. Cluster admin membuat kumpulan baru certificate authority (CA) untuk setiap cluster pengguna, dan menggunakan sertifikat CA untuk menerbitkan sertifikat daun tambahan untuk komponen sistem. Cluster admin mengelola distribusi sertifikat CA publik dan pasangan kunci sertifikat leaf ke komponen sistem untuk membuat komunikasi yang aman.

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

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

CA etcd mengamankan komunikasi dari server API ke replika etcd dan juga traffic antar-replika etcd. CA ini ditandatangani sendiri.
CA cluster mengamankan komunikasi antara server API dan semua klien Kubernetes API internal (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
CA front-proxy mengamankan komunikasi dengan API gabungan. CA ini ditandatangani sendiri.

Selain itu, Anda mungkin menggunakan org CA untuk menandatangani sertifikat yang dikonfigurasi oleh opsi authentication.sni. CA ini dan sertifikat SNI digunakan untuk menayangkan Kubernetes API kepada klien di luar cluster. Anda mengelola CA ini dan membuat sertifikat SNI secara manual. CA ini maupun sertifikat SNI tidak terpengaruh oleh fitur rotasi CA cluster pengguna.

Batasan

Perhatikan batasan berikut dengan cluster lanjutan:
- Versi 1.31: Rotasi CA tidak didukung di cluster lanjutan.
- Versi 1.32 dan yang lebih baru: Rotasi CA didukung di cluster lanjutan, tetapi ada beberapa perbedaan kecil yang dicatat jika berlaku dalam dokumen ini.
Rotasi sertifikat CA dibatasi untuk CA etcd, cluster, dan front-proxy yang disebutkan sebelumnya.
Rotasi sertifikat CA terbatas pada sertifikat yang dikeluarkan secara otomatis oleh Google Distributed Cloud. Tindakan 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 di cluster beberapa kali. Setiap tahap rotasi CA berlangsung serupa dengan upgrade cluster. Meskipun cluster pengguna tetap beroperasi selama rotasi CA, Anda harus mengharapkan workload tersebut dimulai ulang dan dijadwalkan ulang. Anda juga akan mengalami periode nonaktif bidang kontrol singkat jika cluster pengguna tidak memiliki bidang kontrol ketersediaan tinggi.
Anda harus memperbarui file kubeconfig cluster pengguna dan file konfigurasi autentikasi setelah rotasi CA. Hal ini karena sertifikat cluster lama dicabut, dan kredensial dalam file kubeconfig tidak lagi berfungsi.
Setelah dimulai, rotasi CA tidak dapat dijeda atau di-roll back.
Rotasi CA mungkin memerlukan waktu yang cukup lama untuk diselesaikan, bergantung 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_CONFIG: jalur file konfigurasi cluster pengguna
- ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin

Perilaku perintah berbeda-beda bergantung pada apakah cluster lanjutan diaktifkan:

Tidak diaktifkan

Jika cluster lanjutan tidak diaktifkan di cluster, perintah akan asinkron dan memulai rotasi CA, lalu keluar. Anda tidak perlu melihat output perintah selama seluruh durasi rotasi CA. Sebagai gantinya, Anda dapat memeriksa progres secara berkala dengan menjalankan perintah gkectl update credentials certificate-authorities status.

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

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 sudah berlangsung, Anda akan melihat pesan error yang mirip dengan berikut 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

Untuk melihat status rotasi:

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

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

Jika rotasi CA telah 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 mirip 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

Di cluster yang tidak mengaktifkan cluster lanjutan, Anda harus mendapatkan file kubeconfig cluster pengguna baru dari cluster admin. Hal ini karena rotasi CA membatalkan CA yang menjadi dasar file kubeconfig lama.

Dapatkan file kubeconfig baru:

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

Aktif

Jika cluster lanjutan diaktifkan, perintah gkectl update credentials certificate-authorities rotate bersifat sinkron. Perintah ini menghasilkan pesan status ke workstation admin saat rotasi CA berlangsung.

Setelah CA berhasil dirotasi, perintah akan keluar dan file kubeconfig baru akan otomatis dibuat. Output perintah memberikan nama file kubeconfig baru, dan mirip dengan berikut ini:

Beginning CA rotation with generated CA
...
Successfully rotated CA for user cluster "USER_CLUSTER_NAME". The
kubeconfig file "/home/ubuntu"/USER_CLUSTER_NAME-kubeconfig" has
been updated.

Kubeconfig baru berada di direktori yang sama dengan kubeconfig cluster admin yang Anda tentukan dalam perintah. Nama kubeconfig baru adalah USER_CLUSTER_NAME-kubeconfig.

Mendistribusikan file kubeconfig baru

Distribusikan file kubeconfig baru kepada semua orang yang menggunakan file kubeconfig untuk berinteraksi dengan cluster.

Memperbarui file konfigurasi autentikasi

Setelah rotasi CA selesai, file konfigurasi autentikasi harus diperbarui dan didistribusikan ulang. Untuk mengetahui informasi selengkapnya, lihat Mengelola identitas pengguna.

Rotasi sertifikat bidang kontrol

Tanpa rotasi, CA cluster pengguna dan sertifikat platform kontrol akan berakhir masa berlakunya lima tahun sejak tanggal cluster dibuat. Sertifikat panel kontrol cluster pengguna dirotasi secara otomatis dalam waktu sepuluh jam setelah setiap upgrade cluster pengguna, tetapi CA tidak dirotasi secara otomatis. Artinya, rotasi CA harus dilakukan setidaknya sekali setiap lima tahun selain upgrade versi reguler.

Untuk mencegah cluster pengguna tidak tersedia, sertifikat control plane dirotasi dalam waktu sepuluh jam setelah upgrade cluster pengguna. Jika hal ini terjadi, pesan akan muncul di status rotasi CA cluster pengguna.

Untuk melihat versi terakhir yang diupgrade oleh cluster pengguna saat sertifikat control plane dirotasi:

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

Informasi ini muncul di akhir kolom message dalam waktu sepuluh jam setelah upgrade. 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 terhadap cluster pengguna. Untuk petunjuk tentang cara menjalankan gkectl diagnose di cluster pengguna, lihat Mendiagnosis masalah cluster. Jika Anda mengalami masalah dengan rotasi CA, hubungi dukungan Google dan berikan output gkectl diagnose.