Halaman ini menjelaskan cara Anda dan Google Kubernetes Engine (GKE) mengelola perubahan selama siklus proses cluster untuk memaksimalkan performa dan ketersediaan sekaligus meminimalkan gangguan workload.
Halaman ini ditujukan untuk administrator platform yang ingin merencanakan dan mengoptimalkan lingkungan cluster mereka untuk meminimalkan gangguan pada workload mereka. Anda dapat membaca halaman ini sebelum atau setelah mempelajari cara melakukan tugas pengelolaan cluster dasar yang dijelaskan dalam Mengelola cluster dan Ringkasan administrasi cluster.
Platform terkelola dan tanggung jawab bersama
GKE adalah implementasi platform orkestrasi container open source Kubernetes yang dikelola Google. Seperti yang disebutkan dalam Cara kerja GKE, cluster GKE terdiri dari bidang kontrol, yang mencakup node pengelolaan yang menjalankan komponen sistem, dan worker node, tempat Anda men-deploy workload.
Membuat lingkungan cluster yang optimal agar workload Anda dapat berjalan, dengan performa dan ketersediaan maksimum, serta gangguan minimal, adalah tanggung jawab bersama:
- Tanggung jawab GKE adalah menjaga lingkungan cluster yang andal, tersedia, aman, dan berperforma tinggi. Untuk melakukannya, GKE mengelola bidang kontrol, komponen sistem, dan, untuk mode Autopilot, worker node.
- Tanggung jawab Anda sebagai administrator platform adalah mengonfigurasi cluster dan mengelola workload, termasuk mempersiapkannya untuk menangani gangguan. Dengan mode Standard, Anda juga membuat dan mengelola node pekerja, yang dikelompokkan dalam node pool.
Untuk mempelajari lebih lanjut, lihat Tanggung jawab bersama GKE.
Cara GKE mengelola perubahan selama siklus proses cluster
Sebagai penerapan Kubernetes, cluster GKE adalah jaringan proses dan sistem yang bekerja sama untuk mempertahankan lingkungan yang optimal untuk menjalankan workload Anda. Untuk mengelola cluster, GKE melakukan tugas pemeliharaan, membuat perubahan, memulai operasi, mengupdate komponen, dan mengupgrade versi bidang kontrol dan node.
Sebagian besar pengoperasian aplikasi Anda sehari-hari terjadi secara diam-diam di latar belakang, sehingga beban kerja Anda tetap berjalan tanpa gangguan. Namun, beberapa perubahan penting harus diselesaikan dengan cara yang dapat mengganggu sementara workload Anda, seperti yang dijelaskan di bagian berikutnya.
Beberapa perubahan cluster dapat mengganggu workload
Meskipun GKE berupaya agar workload Anda berjalan dengan lancar, beberapa jenis perubahan penting dapat menyebabkan gangguan sementara pada workload Anda—terutama perubahan yang memulai ulang node yang menjalankan workload Anda. Dengan menggunakan fitur GKE dan Kubernetes, Anda dapat menentukan kapan dan bagaimana Anda ingin gangguan terjadi, sehingga saat terjadi, beban kerja Anda dapat menangani perubahan dengan baik.
Bagian berikut menjelaskan jenis perubahan yang dilakukan GKE pada cluster, jenis gangguan yang ditimbulkannya, dan cara Anda dapat bersiap.
Upgrade dan update dengan pengelolaan siklus proses cluster GKE
Di GKE, upgrade cluster dan update cluster memiliki makna yang terkait.
Di GKE, istilah upgrade cluster—atau hanya upgrade—mengacu pada update versi Kubernetes dari bidang kontrol (upgrade bidang kontrol) atau node (upgrade node), atau keduanya. Saat menggunakan cluster Standard, upgrade node juga dapat disebut sebagai upgrade node pool karena GKE menggunakan satu operasi untuk mengupgrade node pool.
Istilah update cluster—atau hanya update—adalah istilah yang lebih umum yang merujuk pada semua jenis perubahan bidang kontrol atau node, termasuk mengupdate versinya. GKE secara aktif mengelola lingkungan cluster Anda dengan melakukan upgrade, jenis update lainnya, dan operasi pemeliharaan yang diperlukan. Tindakan ini memastikan cluster Anda tetap berperforma tinggi, aman, dan diupdate dengan fitur dan perbaikan bug terbaru. GKE menggunakan alat seperti strategi upgrade node dan kebijakan pemeliharaan untuk meminimalkan gangguan selama proses ini.
Merencanakan gangguan update node
Jenis perubahan cluster tertentu—sebagian besar perubahan pada node—dapat menyebabkan gangguan.
GKE menggunakan strategi upgrade node untuk mengupdate node—baik node Autopilot maupun kumpulan node cluster Standar—dengan cara yang dioptimalkan untuk kebutuhan workload Anda. Strategi ini berlaku untuk upgrade versi dan juga untuk beberapa jenis perubahan node lainnya. Strategi ini memungkinkan GKE meminimalkan gangguan saat melakukan update node, yang penting untuk menjaga fungsi dan performa cluster.
Gunakan periode dan pengecualian pemeliharaan untuk memilih kapan beberapa pemeliharaan cluster terjadi dan tidak terjadi, dan, untuk cluster Standar, pilih strategi upgrade node yang paling sesuai dengan profil beban kerja dan batasan resource Anda.
Untuk perubahan pada node yang dilakukan secara manual dan otomatis, GKE melakukan perubahan dengan karakteristik umum berikut:
- Perubahan biasanya mematuhi kebijakan pemeliharaan: Saat GKE
melakukan perubahan pada node, perubahan ini umumnya mematuhi
kebijakan pemeliharaan
GKE.
Pertimbangkan hal berikut jika Anda memulai perubahan manual yang mengharuskan semua node dalam node pool dibuat ulang:
- Untuk beberapa perubahan, GKE mematuhi kebijakan pemeliharaan dan tidak menerapkan perubahan yang Anda kirimkan hingga ada ketersediaan pemeliharaan. Jika GKE menunggu ketersediaan pemeliharaan, dan perubahan bersifat mendesak, Anda dapat menerapkan perubahan secara manual untuk menerapkan konfigurasi baru dengan segera.
- Untuk perubahan manual lainnya, termasuk upgrade manual, GKE tidak mematuhi kebijakan pemeliharaan. Untuk perubahan manual ini, pastikan beban kerja Anda siap untuk gangguan langsung.
- Perubahan umumnya menggunakan strategi upgrade node: Saat GKE menerapkan sebagian besar perubahan yang dimulai secara otomatis atau manual pada node—termasuk update node selain upgrade versi—GKE memilih strategi upgrade node: upgrade lonjakan atau upgrade blue-green. Autopilot selalu menggunakan upgrade lonjakan. Perubahan pada node pool cluster Standar biasanya menggunakan upgrade lonjakan, kecuali jika Anda telah mengonfigurasi upgrade blue-green dan melakukan jenis perubahan tertentu.
- Perubahan memerlukan resource yang memadai: Saat GKE menerapkan perubahan menggunakan strategi upgrade node, perubahan ini memerlukan sejumlah resource tertentu, bergantung pada strategi dan konfigurasinya. Project cluster Anda harus memiliki kuota resource, ketersediaan resource, dan kapasitas reservasi yang memadai (untuk kumpulan node dengan afinitas reservasi tertentu). Untuk mempelajari lebih lanjut, lihat Memastikan resource untuk upgrade node.
Untuk mengetahui daftar mendetail perubahan tertentu dan karakteristiknya, lihat Jenis perubahan pada cluster GKE di halaman ini.
Memaksimalkan ketersediaan workload dengan bersiap menghadapi perubahan yang mengganggu
Untuk memaksimalkan ketersediaan workload yang berjalan di cluster GKE, sebaiknya lakukan tindakan yang dijelaskan di bagian berikut:
Memilih ketersediaan cluster
Jika ketersediaan bidang kontrol adalah prioritas, pilih cluster Autopilot atau cluster Standard regional, bukan cluster Standard zona. Untuk mempelajari lebih lanjut, lihat Tentang pilihan konfigurasi cluster.
Mengontrol upgrade menggunakan alat GKE
Anda dapat menggunakan alat berikut untuk mengontrol kapan dan bagaimana GKE mengupgrade cluster Anda, sehingga memungkinkan Anda menerapkan praktik terbaik:
- Saluran rilis: Pilih saluran rilis untuk mendapatkan versi cluster dengan keseimbangan ketersediaan dan stabilitas fitur yang Anda pilih.
- Masa pemeliharaan: Tentukan jangka waktu berulang saat jenis pemeliharaan cluster GKE tertentu, seperti upgrade, dapat terjadi.
- Pengecualian pemeliharaan: Mencegah pemeliharaan cluster terjadi selama jangka waktu tertentu.
- Strategi upgrade node: Jika menggunakan cluster Standar, pilih cara node Anda diupdate–upgrade lonjakan atau upgrade blue-green–untuk meminimalkan gangguan pada beban kerja Anda.
- Urutan peluncuran: Tentukan upgrade di lingkungan praproduksi sebelum GKE mengupgrade cluster produksi Anda.
- Upgrade manual: Upgrade cluster secara manual, dan lakukan tindakan seperti membatalkan, melanjutkan, melakukan roll back, dan menyelesaikan upgrade yang sedang berlangsung secara otomatis atau manual.
Mengelola dan memantau cluster Anda
Untuk mengelola potensi gangguan pada cluster Anda, lakukan tugas berikut secara terus-menerus:
- Pantau cluster Anda dengan kumpulan alat observasi GKE.
- Ikuti catatan rilis GKE untuk melihat pengumuman.
- Lihat notifikasi cluster, seperti saat upgrade dimulai atau selesai, saat versi baru tersedia, buletin keamanan, dan tanggal akhir dukungan.
- Dapatkan visibilitas ke upgrade cluster untuk memahami status upgrade cluster Anda.
- Periksa jadwal rilis GKE untuk mengetahui perkiraan terbaik tentang kapan versi minor tersedia untuk upgrade, dan kapan akhir masa dukungan.
- Gunakan panduan preskriptif yang mengidentifikasi potensi peluang pengoptimalan dan menjelaskan cara mengoptimalkan penggunaan cluster Anda, termasuk panduan untuk penghentian penggunaan fitur dan API.
Menyiapkan workload Anda
Kelola gangguan dengan membuat workload Anda setahan mungkin terhadap gangguan:
- Jalankan replika workload Anda untuk memastikan redundansi dan menghindari titik tunggal kegagalan.
- Tentukan anggaran gangguan untuk aplikasi Anda menggunakan Anggaran Gangguan Pod.
- Tetapkan periode tenggang penghentian dengan durasi yang tepat agar workload Anda dapat dimatikan dengan benar.
- Jika workload Anda menggunakan GPU atau TPU, ikuti petunjuk untuk mengelola gangguan node GKE untuk GPU dan TPU.
- Untuk aplikasi stateful, yang sering kali memerlukan waktu untuk menghentikan I/O dengan sempurna dan melepasnya dari penyimpanan, ikuti langkah-langkah di Memastikan beban kerja stateful siap menghadapi gangguan.
Untuk pembahasan umum tentang topik ini, lihat bagian Mengelola gangguan di postingan blog Praktik terbaik GKE: Operasi hari ke-2 untuk kelangsungan bisnis.
Jenis perubahan pada cluster GKE
Tabel berikut menunjukkan jenis perubahan besar yang paling umum pada cluster, termasuk karakteristik perubahan ini seperti frekuensi dan tingkat gangguan.
Jenis upgrade
Tinjau tabel berikut untuk memahami cara upgrade dapat mengganggu lingkungan cluster.
| Ubah | Otomatis atau dimulai secara manual | Mematuhi kebijakan pemeliharaan | Frekuensi | Jenis gangguan | Tingkat gangguan |
|---|---|---|---|---|---|
| Upgrade bidang kontrol | Otomatis atau manual |
Upgrade otomatis mematuhi kebijakan pemeliharaan hingga akhir dukungan, kecuali untuk perbaikan darurat yang sangat jarang terjadi, jika diperlukan. Upgrade manual tidak diblokir oleh kebijakan pemeliharaan. |
Upgrade patch, sesering setiap minggu, bergantung pada saluran rilis. Upgrade minor kira-kira setiap empat bulan. Untuk cluster Saluran yang diperpanjang, upgrade minor hanya dilakukan saat versi minor mendekati akhir dukungan. |
Bidang kontrol |
Untuk cluster Autopilot dan Standard regional, bidang kontrol tetap tersedia. Untuk cluster Standar zonal, Anda tidak dapat berkomunikasi dengan bidang kontrol selama beberapa menit, yang berarti Anda tidak dapat mengonfigurasi cluster, node, dan workload selama waktu tersebut. |
| Upgrade node | Otomatis atau manual |
Upgrade otomatis mematuhi kebijakan pemeliharaan hingga akhir dukungan, kecuali untuk perbaikan darurat yang sangat jarang terjadi, jika diperlukan. Upgrade manual tidak diblokir oleh kebijakan pemeliharaan. |
Biasanya sama dengan upgrade bidang kontrol. Jika cluster Anda tidak terdaftar di saluran rilis dan Anda menonaktifkan upgrade otomatis node, Anda bertanggung jawab untuk mengupgrade node pool cluster secara manual. |
Semua node untuk cluster Autopilot, atau satu atau beberapa node pool cluster Standard. |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan upgrade lonjakan untuk Autopilot, atau strategi upgrade node yang dikonfigurasi (lonjakan atau blue-green) untuk cluster Standard. |
Perubahan manual yang membuat ulang node menggunakan strategi upgrade node dan mematuhi kebijakan pemeliharaan
Tinjau tabel berikut untuk memahami bagaimana perubahan manual ini dapat mengganggu lingkungan cluster. Daftar ini mencakup, di antara perubahan lainnya, perubahan manual yang mematuhi kebijakan pemeliharaan GKE.
| Ubah | Otomatis atau dimulai secara manual | Mematuhi kebijakan pemeliharaan | Frekuensi | Jenis gangguan | Tingkat gangguan |
|---|---|---|---|---|---|
| Menonaktifkan port hanya baca kubelet | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini. | Semua node di cluster Autopilot Semua node di node pool cluster Standard. |
Node harus dimatikan untuk dibuat ulang. Pod harus diganti. GKE segera menggunakan upgrade lonjakan untuk membuat ulang node, terlepas dari kebijakan pemeliharaan aktif. |
| Merotasi kredensial cluster | Otomatis jika kredensial cluster akan habis masa berlakunya dalam 30 hari, juga dapat dimulai secara manual. | Mematuhi kebijakan pemeliharaan. Namun, GKE dapat menggantikan kebijakan pemeliharaan dalam waktu 30 hari setelah masa berlaku kredensial habis. Dalam waktu 30 hari, GKE mengabaikan ketersediaan pemeliharaan untuk langkah pertama, yaitu memulai rotasi. Selain itu, jika Anda memicu operasi tertentu secara manual setelah langkah pertama, operasi tersebut tidak mematuhi kebijakan pemeliharaan. | Sekali per perubahan manual jenis ini, atau bergantung pada masa aktif kredensial cluster untuk inisiasi otomatis. Anda dapat memanggil operasi secara manual untuk langkah tertentu dalam proses rotasi. | Untuk beberapa langkah, bidang kontrol. Untuk langkah-langkah lainnya, semua node untuk cluster Autopilot, semua node di setiap node pool cluster Standard. |
Saat Anda memulai rotasi dan menyelesaikan rotasi, tingkat gangguan adalah sebagai berikut:
Saat node dibuat ulang, tingkat gangguan adalah sebagai berikut:
|
| Merotasi alamat IP panel kontrol | Dimulai secara manual | Mematuhi kebijakan pemeliharaan, tetapi jika Anda memicu operasi tertentu secara manual setelah langkah pertama, operasi tersebut tidak mematuhi kebijakan pemeliharaan. | Sekali per perubahan manual jenis ini. Anda dapat memanggil operasi secara manual untuk langkah tertentu dalam proses rotasi. | Untuk beberapa langkah, bidang kontrol. Untuk langkah-langkah lainnya, semua node untuk cluster Autopilot, semua node di setiap node pool cluster Standard. |
Saat Anda memulai rotasi dan menyelesaikan rotasi, tingkat gangguan adalah sebagai berikut:
Saat node dibuat ulang, tingkat gangguan adalah sebagai berikut:
|
| Mengonfigurasi node terlindungi | Dimulai secara manual |
Membuat ulang bidang kontrol tidak mematuhi kebijakan pemeliharaan, dan langsung melakukan perubahan. Pembuatan ulang node akan mematuhi kebijakan pemeliharaan. |
Sekali per perubahan jenis ini |
Bidang kontrol diperbarui. Setelah bidang kontrol diupdate, semua node di setiap node pool cluster Standard harus dibuat ulang. |
Saat bidang kontrol dibuat ulang, tingkat gangguan adalah sebagai berikut:
Saat node dibuat ulang, tingkat gangguan adalah sebagai berikut:
|
| Mengonfigurasi kebijakan jaringan | Dimulai secara manual | Mematuhi kebijakan pemeliharaan | Sekali per perubahan jenis ini | Semua node untuk cluster Autopilot, semua node di setiap node pool cluster Standard. |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan upgrade lonjakan untuk membuat ulang node. |
| Mengonfigurasi visibilitas intranode | Dimulai secara manual | Mematuhi kebijakan pemeliharaan | Sekali per perubahan jenis ini | Semua node untuk cluster Autopilot, semua node di setiap node pool cluster Standard. |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan upgrade lonjakan untuk membuat ulang node. |
| Mengonfigurasi NodeLocal DNSCache | Dimulai secara manual | Mematuhi kebijakan pemeliharaan | Sekali per perubahan jenis ini | Semua node di kumpulan node cluster Standard yang sedang diupdate harus diupdate. |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan upgrade lonjakan untuk membuat ulang node. |
| Mengaktifkan streaming gambar | Dimulai secara manual |
Saat memperbarui di tingkat cluster, kebijakan pemeliharaan akan diterapkan. Saat memperbarui masing-masing node pool, tidak mematuhi kebijakan pemeliharaan. |
Sekali per perubahan jenis ini |
Jika dialihkan di tingkat node pool, semua node di node pool cluster Standard. Jika diaktifkan di tingkat cluster, node dari node pool cluster Standard mana pun yang belum Anda aktifkan atau nonaktifkan setelannya secara individual untuk node pool. |
GKE menggunakan upgrade lonjakan untuk membuat ulang node dari node pool. |
Pemeliharaan otomatis yang tidak mematuhi kebijakan pemeliharaan
Tinjau tabel berikut untuk memahami cara pemeliharaan otomatis yang tidak mematuhi kebijakan pemeliharaan dapat mengganggu lingkungan cluster.
| Ubah | Otomatis atau dimulai secara manual | Mematuhi kebijakan pemeliharaan | Frekuensi | Jenis gangguan | Tingkat gangguan |
|---|---|---|---|---|---|
| Perbaikan atau perubahan ukuran bidang kontrol | Otomatis | Tidak mematuhi kebijakan pemeliharaan |
Frekuensi perbaikan bidang kontrol bersifat acak, tetapi tidak berdampak pada cluster Autopilot dan Standar regional. Pengubahan ukuran bidang kontrol jarang terjadi, tetapi frekuensinya meningkat seiring dengan peristiwa penskalaan cluster, dan juga tidak berdampak pada cluster Autopilot dan Standard regional. |
Bidang kontrol |
Untuk cluster Autopilot dan Standard regional, bidang kontrol tetap tersedia. Untuk cluster Standar zonal, Anda tidak dapat berkomunikasi dengan bidang kontrol selama beberapa menit, yang berarti Anda tidak dapat mengonfigurasi cluster, node, dan workload selama waktu tersebut. |
| Peristiwa pemeliharaan host | Otomatis | Tidak mematuhi kebijakan pemeliharaan | Lihat Peristiwa pemeliharaan untuk mengetahui perkiraan frekuensi. | Satu node |
Untuk sebagian besar jenis node, efeknya minimal. Beberapa node, termasuk yang memiliki GPU atau TPU, mungkin mengalami gangguan yang lebih besar. Untuk mempelajari lebih lanjut, lihat Pemeliharaan Google Cloud lainnya. |
| Perbaikan otomatis node | Otomatis | Tidak mematuhi kebijakan pemeliharaan | Frekuensi perbaikan otomatis node bersifat acak. |
Satu node | Node dimulai ulang, sehingga Pod apa pun yang berjalan di node akan terganggu. |
| Mengklaim kembali Spot VM dan Preemptible VM | Otomatis | Tidak mematuhi kebijakan pemeliharaan |
Untuk preemptible VM, setidaknya sekali setiap 24 jam. Untuk Spot VM, saat Compute Engine memerlukan resource di tempat lain. |
Satu node | Lihat detail tentang penghentian dan pemadaman tuntas VM Spot, serta penghentian dan pemadaman tuntas preemptible VM. |
| Pemeliharaan database status cluster berbasis Spanner | Otomatis | Tidak mematuhi kebijakan pemeliharaan | Peristiwa bersifat acak dan tidak berdampak pada cluster atau beban kerja. | Tidak ada. Database berbasis Spanner berjalan secara terpisah dari bidang kontrol dan node cluster di infrastruktur Google. | Tidak ada. Database berbasis Spanner direplikasi untuk semua jenis cluster dan tetap tersedia selama pemeliharaan. |
Perubahan manual yang membuat ulang node menggunakan strategi upgrade node tanpa mematuhi kebijakan pemeliharaan
Tinjau tabel berikut untuk memahami bagaimana perubahan manual ini dapat mengganggu lingkungan cluster. Daftar ini mencakup perubahan dari saat GKE menggunakan upgrade lonjakan dan saat GKE menggunakan upgrade blue-green yang tidak disertakan dalam bagian lain karena tidak mematuhi kebijakan pemeliharaan.
| Ubah | Otomatis atau dimulai secara manual | Mematuhi kebijakan pemeliharaan | Frekuensi | Jenis gangguan | Tingkat gangguan |
|---|---|---|---|---|---|
| Pembaruan label node pool | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard | GKE akan segera menggunakan upgrade lonjakan untuk membuat ulang node pool saat Anda mengupdate label node pada node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
| Menskalakan node secara vertikal dengan mengubah atribut mesin node | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard | GKE segera menggunakan upgrade lonjakan untuk membuat ulang node di node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
| Perubahan jenis gambar | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan strategi upgrade node yang dikonfigurasi (lonjakan atau blue-green) untuk cluster Standard. |
| Menambahkan atau mengganti pool penyimpanan di node pool cluster Standard | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE menggunakan strategi upgrade node yang dikonfigurasi (lonjakan atau blue-green) untuk cluster Standard. |
| Mengaktifkan streaming gambar | Dimulai secara manual |
Saat memperbarui di tingkat cluster, kebijakan pemeliharaan akan diterapkan. Saat memperbarui masing-masing node pool, tidak mematuhi kebijakan pemeliharaan. |
Sekali per perubahan jenis ini |
Jika dialihkan di tingkat node pool, semua node di node pool cluster Standard. Jika diaktifkan di tingkat cluster, node dari node pool cluster Standard mana pun yang belum Anda aktifkan atau nonaktifkan setelannya secara individual untuk node pool. |
GKE menggunakan upgrade lonjakan untuk membuat ulang node dari node pool. |
| Pembaruan konfigurasi performa jaringan | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE segera menggunakan upgrade lonjakan untuk membuat ulang node di node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
| Mengaktifkan gVNIC | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE segera menggunakan upgrade lonjakan untuk membuat ulang node di node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
| Perubahan konfigurasi sistem node | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE segera menggunakan upgrade lonjakan untuk membuat ulang node di node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
| Node rahasia | Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node di node pool cluster Standard |
Node harus dimatikan untuk dibuat ulang, Pod harus diganti. GKE segera menggunakan upgrade lonjakan untuk membuat ulang node di node pool yang ada, terlepas dari kebijakan pemeliharaan aktif. |
Perubahan yang tidak memerlukan pembuatan ulang node
Tinjau tabel berikut untuk memahami perubahan pada konfigurasi node yang tidak memerlukan pembuatan ulang node. Perubahan ini tidak mengganggu, tetapi gangguan masih dapat terjadi jika konfigurasi node yang diperbarui memengaruhi beban kerja Anda.
| Ubah | Otomatis atau dimulai secara manual | Mematuhi kebijakan pemeliharaan | Frekuensi | Jenis gangguan | Tingkat gangguan |
|---|---|---|---|---|---|
|
Perbarui setelan berikut:
|
Dimulai secara manual | Tidak mematuhi kebijakan pemeliharaan, langsung melakukan perubahan. | Sekali per perubahan jenis ini | Semua node yang relevan diperbarui. | Pod tidak perlu diganti karena konfigurasi node diperbarui tanpa membuat ulang node. |
Langkah berikutnya
- Ringkasan GKE
- Arsitektur cluster GKE
- Tanggung jawab bersama GKE
- Pembuatan versi dan dukungan GKE
- Perjanjian Tingkat Layanan GKE
- Upgrade cluster GKE