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 dalam cluster. Certificate authority (CA)
cluster mengelola sertifikat dan kunci ini. Saat Anda menjalankan perintah bmctl
update credentials certificate-authorities rotate,
Google Distributed Cloud akan melakukan tindakan berikut:
Perintah ini membuat dan mengupload cluster certificate authority (CA) baru
untuk CA cluster, CA etcd, dan CA front-proxy ke namespace cluster
pengguna di cluster admin.
Pengontrol cluster admin mengganti otoritas sertifikat cluster pengguna dengan yang baru dibuat.
Pengontrol cluster admin mendistribusikan sertifikat CA publik baru dan
pasangan kunci sertifikat leaf ke komponen sistem cluster pengguna.
Perintah ini juga memperbarui Secret stackdriver-prometheus-etcd-scrape,
yang dibuat oleh Google Distributed Cloud selama pembuatan cluster.
Prometheus memerlukan secret ini untuk mengumpulkan metrik etcd.
Untuk mempertahankan komunikasi cluster yang aman, putar CA cluster pengguna secara berkala dan setiap kali ada kemungkinan pelanggaran keamanan.
Sebelum memulai
Sebelum memutar otoritas sertifikasi cluster, buat rencana sesuai dengan
kondisi dan dampak berikut:
Pastikan cluster admin dan pengguna menggunakan versi 1.9.0 atau yang lebih tinggi sebelum
memulai rotasi CA.
Rotasi CA bersifat inkremental, sehingga komponen sistem dapat berkomunikasi selama
rotasi.
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 bahwa beban kerja
akan dimulai ulang dan dijadwalkan ulang.
Operasi pengelolaan cluster tidak diizinkan selama rotasi CA.
Durasi rotasi CA bergantung pada ukuran cluster Anda. Misalnya, rotasi CA
mungkin memerlukan waktu hampir dua jam untuk diselesaikan untuk cluster dengan satu
bidang kontrol dan 50 node pekerja.
Batasan
Kemampuan rotasi certificate authority memiliki
batasan berikut:
Rotasi CA tidak memperbarui sertifikat yang diterbitkan secara manual oleh administrator,
meskipun CA cluster menandatangani sertifikat. Perbarui dan distribusikan ulang
sertifikat yang diterbitkan secara manual setelah rotasi CA cluster pengguna selesai.
Setelah dimulai, rotasi CA tidak dapat dijeda atau di-roll back.
Memulai rotasi CA cluster
Secara default, sertifikat TLS memiliki periode habis masa berlaku 1 tahun.
Google Distributed Cloud memperpanjang sertifikat ini saat Anda merotasi otoritas
sertifikat. Google Distributed Cloud juga memperpanjang sertifikat TLS selama upgrade cluster. Sebaiknya upgrade cluster secara berkala agar tetap
aman, didukung, dan mencegah sertifikat TLS berakhir masa berlakunya.
Gunakan perintah berikut untuk memulai proses rotasi CA:
CLUSTER_NAME: nama cluster yang CA-nya ingin Anda putar.
KUBECONFIG: jalur ke file kubeconfig
cluster admin. Untuk cluster yang mengelola sendiri, file ini adalah file
kubeconfig cluster.
Perintah bmctl akan keluar setelah CA berhasil dirotasi dan file
kubeconfig baru dibuat. Jalur standar untuk file kubeconfig adalah
bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig.
Memecahkan masalah rotasi CA cluster
Perintah bmctl update credentials menampilkan progres rotasi CA.
File update-credentials.log terkait disimpan ke direktori berstempel waktu
berikut:
[[["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-08-04 UTC."],[],[],null,["Google Distributed Cloud uses certificates and private keys to authenticate and encrypt\nconnections between system components in clusters. The cluster certificate\nauthority (CA) manages these certificates and keys. When you run the `bmctl\nupdate credentials certificate-authorities rotate` command,\nGoogle Distributed Cloud performs the following actions:\n\n- The command creates and uploads new cluster certificate authorities (CAs)\n for the cluster CA, the etcd CA, and the front-proxy CA to the user cluster\n namespace in the admin cluster.\n\n- The admin cluster controllers replace the user cluster certificate\n authorities with the newly generated ones.\n\n- The admin cluster controllers distribute the new public CA certificates and\n leaf certificate key pairs to user cluster system components.\n\n- The command also updates the `stackdriver-prometheus-etcd-scrape` Secret,\n which was created by Google Distributed Cloud during cluster creation.\n Prometheus requires this secret to collect etcd metrics.\n\nTo maintain secure cluster communication, rotate your user cluster CA\nperiodically and whenever there is a possible security breach.\n| **Important:** If your cluster certificates have expired, you must renew them manually to regain cluster operation. For more information and instructions, see [Renew expired cluster certificates manually](/kubernetes-engine/distributed-cloud/bare-metal/docs/troubleshooting/expired-certs).\n\nBefore you begin\n\nBefore you rotate your cluster's certificate authority, plan according to the\nfollowing conditions and impacts:\n\n- Ensure admin and user clusters are at version 1.9.0 or higher before\n starting the CA rotation.\n\n- CA rotation is incremental, allowing system components to communicate during\n the rotation.\n\n- A CA rotation restarts the API server, other control-plane processes, and\n each node in the cluster multiple times. Each stage of a CA rotation\n progresses similarly to a cluster upgrade. While the user cluster does\n remain operational during a CA rotation, you should expect that workloads\n will be restarted and rescheduled.\n\n- If your user cluster doesn't have a [high-availability control plane](/kubernetes-engine/distributed-cloud/bare-metal/docs/reference/cluster-config-ref#controlplane-nodepoolspec-nodes),\n expect brief periods of control-plane downtime during CA rotation.\n\n- Cluster management operations aren't allowed during CA rotation.\n\n- CA rotation duration depends on the size of your cluster. For example, CA\n rotation may take close to two hours to complete for a cluster with one\n control plane and 50 worker nodes.\n\nLimitations\n\nThe certificate authority rotation capability has the\nfollowing limitations:\n\n- CA rotation doesn't update certificates issued manually by an administrator,\n even if the cluster CA signs the certificates. Update and redistribute any\n manually issued certificates after user cluster CA rotation is complete.\n\n- Once started, CA rotation can't be paused or rolled back.\n\nStart a cluster CA rotation\n\nBy default, TLS certificates have a 1-year expiration period.\nGoogle Distributed Cloud renews these certificates when you rotate certificate\nauthorities. Google Distributed Cloud also renews the TLS certificates during\ncluster upgrades. We recommend that you upgrade your clusters regularly to keep\nthem secure, supported, and to prevent TLS certificates from expiring.\n\nUse the following command to start the CA rotation process: \n\n bmctl update credentials certificate-authorities rotate --cluster \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --kubeconfig \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the cluster for which you want to rotate CAs.\n- \u003cvar translate=\"no\"\u003eKUBECONFIG\u003c/var\u003e: the path to the admin cluster kubeconfig file. For self-managing clusters, this file is the cluster's kubeconfig file.\n\nThe `bmctl` command exits after the CA is rotated successfully and a new\nkubeconfig file is generated. The standard path for the kubeconfig file is\n`bmctl-workspace/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e`-kubeconfig`.\n\nTroubleshoot a cluster CA rotation\n\nThe `bmctl update credentials` command displays the progress of the CA rotation.\nThe associated `update-credentials.log` file is saved to the following\ntimestamped directory: \n\n bmctl-workspace/\u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e/log/update-credentials-\u003cvar translate=\"no\"\u003eTIMESTAMP\u003c/var\u003e"]]