Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Google Distributed Cloud menggunakan sertifikat dan kunci pribadi untuk mengautentikasi
komunikasi antara komponen sistem Kubernetes di cluster admin. Saat Anda
membuat cluster admin, sertifikat certificate authority (CA) baru akan dibuat,
dan root certificate ini digunakan untuk menerbitkan sertifikat leaf tambahan untuk
komponen sistem Kubernetes.
Ada tiga sertifikat CA yang digunakan oleh sistem Kubernetes di cluster admin:
Sertifikat CA etcd mengamankan komunikasi dari server Kubernetes API
ke replika etcd dan juga komunikasi antar-replika etcd. Sertifikat
ini ditandatangani sendiri.
Sertifikat CA cluster mengamankan komunikasi antara server Kubernetes API
dan semua klien Kubernetes API internal, misalnya, kubelet, pengelola pengontrol, dan penjadwal. Sertifikat ini ditandatangani sendiri.
Sertifikat CA proxy depan mengamankan komunikasi dengan
API gabungan.
Sertifikat ini ditandatangani sendiri.
Anda dapat menggunakan gkectl untuk memicu rotasi sertifikat. Selama rotasi,
gkectl akan mengganti sertifikat CA sistem inti untuk
cluster admin dengan sertifikat yang baru dibuat. Kemudian, CA mendistribusikan sertifikat
CA, sertifikat leaf, dan kunci pribadi baru ke komponen sistem
cluster admin. Rotasi terjadi secara bertahap, sehingga komponen sistem dapat
terus berkomunikasi selama rotasi. Namun, perlu diperhatikan bahwa workload dan node dimulai ulang selama rotasi.
Tanpa rotasi, sertifikat CA dan sertifikat platform kontrol akan berakhir masa berlakunya
lima tahun sejak tanggal cluster dibuat. Sertifikat bidang kontrol
otomatis dirotasi selama upgrade cluster, tetapi CA
tidak otomatis dirotasi. Artinya, rotasi CA harus dilakukan setidaknya
sekali setiap lima tahun, selain upgrade versi reguler.
Batasan
Perhatikan batasan berikut dengan 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 sertifikat 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 sertifikat CA memulai ulang server Kubernetes API, proses
bidang kontrol lainnya, dan setiap node di cluster admin beberapa kali.
Setiap tahap rotasi berlangsung dengan cara yang sama seperti upgrade cluster. Meskipun
cluster admin dan cluster pengguna yang dikelola oleh cluster admin tetap
beroperasi selama rotasi sertifikat, Anda harus bersiap bahwa beban kerja
di cluster admin akan dimulai ulang dan dijadwalkan ulang. Anda juga akan mengalami
periode nonaktif singkat untuk bidang kontrol cluster admin dan bidang kontrol
cluster pengguna.
Anda harus memperbarui file kubeconfig cluster admin di tengah-tengah
rotasi sertifikat dan lagi setelah rotasi selesai. Hal ini karena
sertifikat cluster lama dicabut, dan kredensial dalam file
kubeconfig tidak akan berfungsi lagi.
Setelah dimulai, rotasi sertifikat CA tidak dapat di-roll back.
Rotasi sertifikat CA mungkin memerlukan waktu yang cukup lama untuk diselesaikan, bergantung
pada ukuran cluster.
Proses rotasi sertifikat dapat dilanjutkan dengan menjalankan kembali perintah yang sama jika terganggu. Namun, Anda harus memastikan bahwa hanya ada satu perintah rotasi yang berjalan dalam satu waktu.
Memulai rotasi
Untuk memulai rotasi sertifikat, jalankan perintah berikut:
ADMIN_CLUSTER_CONFIG: jalur file konfigurasi cluster admin
ADMIN_CLUSTER_KUBECONFIG: jalur file kubeconfig cluster admin
Perilaku perintah berbeda-beda bergantung pada apakah cluster lanjutan diaktifkan:
Tidak diaktifkan
Perintah gkectl update credentials certificate-authorities rotate memulai
dan melakukan paruh pertama rotasi. Perintah tersebut kemudian dijeda untuk memungkinkan
Anda menjalankan perintah berikutnya guna mengupdate file kubeconfig.
Mengupdate file kubeconfig
Saat perintah gkectl update credentials certificate-authorities rotate
dijeda, perbarui file kubeconfig untuk cluster admin. Tindakan ini akan menempatkan sertifikat klien
baru dan sertifikat CA baru dalam file kubeconfig. Sertifikat klien lama
akan dihapus dari file kubeconfig, dan sertifikat CA lama
tetap ada dalam file kubeconfig.
Jalankan perintah berikut untuk melakukan paruh kedua prosedur. Perintah
tidak akan dilanjutkan hingga gkectl memverifikasi bahwa file kubeconfig
yang diperbarui ada di direktori saat ini.
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. File kubeconfig yang Anda tentukan dalam
perintah akan diganti dengan file baru. Output perintah mirip dengan
berikut:
Beginning CA rotation with generated CA
...
Successfully rotated CA for admin cluster. The kubeconfig file
"/home/ubuntu/kubeconfig" has been updated.
Done rotating certificate-authorities
Mendistribusikan file kubeconfig baru
Distribusikan file kubeconfig cluster admin baru ke semua pengguna cluster.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-07-31 UTC."],[],[],null,["Google Distributed Cloud use certificates and private keys to authenticate\ncommunication between Kubernetes system components in an admin cluster. When you\ncreate an admin cluster, new certificate authority (CA) certificates are created,\nand these root certificates are used to issue additional leaf certificates for\nKubernetes system components.\n\nThis guide applies only to rotation of admin cluster CA certificates. For\nuser clusters, see\n[Rotating user cluster CA certificates](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/ca-rotation).\n\nThere are three CA certificates used by the Kubernetes system in an admin\ncluster:\n\n- The etcd CA certificate secures communication from the Kubernetes API server\n to the etcd replicas and also communication between etcd replicas. This\n certificate is self-signed.\n\n- The cluster CA certificate secures communication between the Kubernetes API\n server and all internal Kubernetes API clients, for example, the kubelet, the\n controller manager, and the scheduler. This certificate is self-signed.\n\n- The front-proxy CA certificate secures communication with\n [aggregated APIs](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/).\n This certificate is self-signed.\n\nYou can use `gkectl` to trigger a certificate rotation. During a rotation,\n`gkectl` replaces the core system CA certificates for the\nadmin cluster with newly generated certificates. Then it distributes the new\nCA certificates, leaf certificates, and private keys to admin cluster system\ncomponents. The rotation happens incrementally, so that system components can\ncontinue to communicate during the rotation. Note, however, that workloads and\nnodes are restarted during the rotation.\n\nWithout rotation, CA certificates and control-plane certificates will expire\nfive years from the date the cluster was created. The control plane certificates\nare automatically rotated during a cluster upgrade, but the CAs are\nnot automatically rotated. This means a CA rotation must be performed at least\nonce every five years, in addition to regular version upgrades.\n| **Warning:** A CA certificate rotation revokes the old CA certificates at the end of the operation. This invalidates kubeconfig files that were based on an old certificate. Consequently, the credentials in the kubeconfig file stop working after a CA certificate rotation. This guide includes instructions on how to update your kubeconfig file. The same issue applies to authentication configuration files.\n\nLimitations\n\n- Note the following limitation with advanced clusters:\n\n - Version 1.31: CA rotation isn't supported on [advanced clusters](/kubernetes-engine/distributed-cloud/vmware/docs/how-to/admin-cluster-configuration-file-latest#enable-advanced-cluster-field).\n - Version 1.32 and higher: CA rotation is supported on advanced clusters but there are some minor differences noted where applicable in this document.\n- CA certificate rotation limited to the etcd, cluster, and front-proxy\n certificates mentioned previously.\n\n- CA certificate rotation is limited to certificates issued automatically by\n Google Distributed Cloud. It does not update certificates issued manually by an\n administrator, even if those certificates are signed by the system CAs.\n\n- CA certificate rotation restarts the Kubernetes API server, other\n control-plane processes, and each node in the admin cluster multiple times.\n Each stage of a rotation progresses similarly to a cluster upgrade. While the\n admin cluster and the user clusters managed by the admin cluster do remain\n operational during a certificate rotation, you should expect that workloads\n in the admin cluster will be restarted and rescheduled. You should also expect\n brief periods of downtime for the admin cluster control plane and user cluster\n control plane.\n\n- You must update the admin cluster kubeconfig file in the middle of a\n certificate rotation and again after the rotation completes. This is because\n the old cluster certificate is revoked, and the credentials in the kubeconfig\n file will no longer work.\n\n- Once initiated, a CA certificate rotation cannot be rolled back.\n\n- A CA certificate rotation might take considerable time to complete, depending\n on the size of the cluster.\n\n- The certificate rotation process can be resumed by re-running the same\n command if it is interrupted. However, you must ensure that there is only one\n rotation command running at a time.\n\nStart the rotation\n\nTo start the certificate rotation, run the following command:\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_CONFIG\u003c/var\u003e: the path of the admin cluster configuration\n file\n\n- \u003cvar translate=\"no\"\u003eADMIN_CLUSTER_KUBECONFIG\u003c/var\u003e: the path of the admin cluster kubeconfig\n file\n\nThe behavior of the command differs depending on whether advanced cluster\nis enabled: \n\nNot enabled\n\nThe `gkectl update credentials certificate-authorities rotate` command starts\nand performs the first half of the rotation. The command then pauses to let\nyou run the next command to update the kubeconfig file.\n\nUpdate the kubeconfig file\n\nWhen the `gkectl update credentials certificate-authorities rotate` command\npauses, update the kubeconfig file for the admin cluster. This places a new\nclient certificate and a new CA certificate in the kubeconfig file. The old\nclient certificate is removed from the kubeconfig file, and the old CA\ncertificate remains in the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nContinue the rotation\n\nRun the following command to perform the second half of the procedure. The\ncommand doesn't proceed until `gkectl` verifies that the updated kubeconfig\nfile is in the current directory.\n\n```\ngkectl update credentials certificate-authorities rotate \\\n --admin-cluster \\\n --complete \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nWhen the rotation is complete, it reports the current CA version.\n\nUpdate the kubeconfig file again\n\nAfter the second half of the rotation completes, update the kubeconfig file\nagain. This removes the old CA certificate from the kubeconfig file.\n\n```\ngkectl update credentials certificate-authorities update-kubeconfig \\\n --admin-cluster \\\n --config ADMIN_CLUSTER_CONFIG \\\n --kubeconfig ADMIN_CLUSTER_KUBECONFIG\n```\n\nEnabled\n\nIf advanced cluster is enabled, the `gkectl update credentials\ncertificate-authorities rotate` command is synchronous. The command outputs\nstatus messages to the admin workstation as the CA rotation progresses.\n\nAfter the CA is rotated successfully, the command exits and a new kubeconfig\nfile is automatically generated. The kubeconfig file that you specified in the\ncommand is replaced with a new one. The command output is similar to the\nfollowing:\n\n```\nBeginning CA rotation with generated CA\n...\nSuccessfully rotated CA for admin cluster. The kubeconfig file\n\"/home/ubuntu/kubeconfig\" has been updated.\nDone rotating certificate-authorities\n```\n\nDistribute the new kubeconfig file\n\nDistribute the new admin cluster kubeconfig file to all cluster users."]]
