Dokumen ini menjelaskan cara mendesain, merencanakan, dan mengimplementasikan upgrade di lingkungan multi-cluster Google Kubernetes Engine (GKE). Meskipun dokumen ini menggunakan Multi Cluster Ingress untuk upgrade, konsepnya dapat diterapkan ke solusi lain. Dokumen ini ditujukan bagi administrator yang bertanggung jawab mengelola fleet untuk cluster GKE. Google Cloud
Pengelolaan siklus proses cluster GKE
Pengelolaan siklus proses cluster dapat didefinisikan sebagai strategi dan perencanaan yang diperlukan untuk mempertahankan fleet cluster Kubernetes yang berfungsi baik dan terupdate tanpa melanggar SLO layanan. Dengan strategi dan perencanaan yang tepat, pengelolaan siklus proses cluster harus rutin, dapat diprediksi, dan lancar.
Untuk mengetahui informasi selengkapnya tentang cara mengelola versi GKE cluster, lihat Tentang upgrade cluster GKE. Untuk mengetahui informasi selengkapnya tentang cara mengelola semua jenis perubahan selama siklus proses cluster, lihat Mengelola perubahan siklus proses cluster untuk meminimalkan gangguan.
Pengelolaan siklus proses multi-cluster GKE
Bagian ini menjelaskan berbagai strategi pengelolaan siklus proses multi-cluster GKE dan cara merencanakannya.
Pertimbangan perencanaan dan desain
Arsitektur multi-cluster GKE berperan dalam memilih strategi pengelolaan siklus proses cluster. Sebelum membahas strategi ini, penting untuk membahas keputusan desain tertentu yang mungkin akan memengaruhi atau dipengaruhi oleh strategi pengelolaan siklus proses cluster.
Jenis cluster
Jika Anda menggunakan upgrade otomatis GKE sebagai strategi pengelolaan siklus proses cluster, jenis cluster dapat berpengaruh. Misalnya, cluster regional memiliki beberapa node bidang kontrol dengan node bidang kontrol di-upgrade secara otomatis satu per satu, sedangkan cluster zona memiliki satu node bidang kontrol. Jika Anda tidak menggunakan upgrade otomatis GKE dan jika Anda mempertimbangkan semua cluster Kubernetes sebagai infrastruktur sekali pakai, jenis cluster apa yang Anda pilih saat memutuskan strategi pengelolaan siklus proses cluster mungkin tidak akan terpengaruh. Anda dapat menerapkan strategi yang dibahas di bagian berikutnya, pengelolaan siklus proses multi-cluster GKE ke semua jenis cluster.
Penempatan dan jejak cluster
Pertimbangkan faktor-faktor berikut saat Anda memutuskan penempatan cluster dan jejak:
- Zona dan region tempat cluster harus berada.
- Jumlah dan ukuran cluster yang diperlukan.
Faktor pertama biasanya mudah ditangani karena zona dan region ditentukan oleh bisnis Anda dan region tempat Anda melayani pengguna.
Mengatasi jumlah dan ukuran cluster biasanya termasuk dalam kategori berikut, dengan kelebihan dan kekurangannya masing-masing:
- Sejumlah kecil cluster besar. Anda dapat memilih untuk menggunakan redundansi dan ketahanan yang disediakan oleh cluster regional serta menempatkan satu (atau dua) cluster regional besar per region. Manfaat pendekatan ini adalah overhead operasional yang rendah untuk pengelolaan beberapa cluster. Kekurangannya adalah pendekatan ini dapat memengaruhi sejumlah besar layanan sekaligus karena area dampaknya yang besar.
- Cluster kecil dalam jumlah besar. Anda dapat membuat cluster kecil dalam jumlah besar untuk mengurangi area dampak cluster karena layanan Anda dibagi ke banyak cluster. Pendekatan ini juga berfungsi dengan baik untuk cluster sementara berumur pendek (misalnya, cluster yang menjalankan workload batch). Kelemahan dari pendekatan ini adalah overhead operasional yang lebih tinggi karena ada lebih banyak cluster untuk diupgrade. Mungkin juga ada biaya tambahan yang terkait dengan jumlah node bidang kontrol yang lebih tinggi. Anda dapat mengimbangi biaya dan overhead operasional yang tinggi dengan otomatisasi, jadwal dan strategi yang dapat diprediksi, serta koordinasi yang cermat antara tim dan layanan yang terpengaruh.
Dokumen ini tidak merekomendasikan satu pendekatan di atas yang lain; semua ini adalah pilihan. Dalam beberapa kasus, Anda dapat memilih kedua pola desain tersebut untuk kategori layanan yang berbeda.
Strategi berikut ini cocok dengan salah satu pilihan desain.
Perencanaan kapasitas
Saat merencanakan kapasitas, penting untuk mempertimbangkan strategi siklus proses cluster yang dipilih. Perencanaan kapasitas harus mempertimbangkan peristiwa beban layanan dan pemeliharaan normal berikut:
- Peristiwa terencana seperti upgrade cluster
- Peristiwa tak terencana seperti pemadaman cluster, misalnya, push konfigurasi yang buruk dan peluncuran yang buruk
Saat perencanaan kapasitas, Anda harus mempertimbangkan pemadaman layanan total atau sebagian. Jika Anda mendesain hanya untuk peristiwa pemeliharaan terencana, semua Service yang terdistribusi harus memiliki satu cluster tambahan dari yang diperlukan, sehingga Anda dapat mengambil satu cluster dari rotasi pada satu waktu untuk upgrade tanpa mendowngrade layanan. Pendekatan ini juga disebut sebagai N+1 perencanaan kapasitas . Jika Anda merancang peristiwa pemeliharaan yang terencana dan tak terencana, maka semua layanan terdistribusi harus memiliki dua (atau lebih) cluster tambahan daripada yang diperlukan untuk melayani kapasitas yang diharapkan—satu untuk peristiwa yang direncanakan dan satu lagi untuk peristiwa yang tidak direncanakan jika hal tersebut terjadi selama masa pemeliharaan yang direncanakan. Pendekatan ini juga disebut sebagai N+2 perencanaan kapasitas.
Dalam arsitektur multi-cluster, istilah draining dan spilling sering digunakan. Istilah ini mengacu pada proses penghapusan (atau draining) traffic dari cluster dan mengalihkan (atau spilling) traffic ke cluster lain selama upgrade dan peristiwa pemeliharaan. Proses ini dilakukan dengan menggunakan solusi jaringan seperti multi-cluster Ingress atau metode load balancing lainnya. Penggunaan draining dan spilling dengan hati-hati adalah inti dari beberapa strategi pengelolaan siklus proses cluster. Saat merencanakan kapasitas, Anda harus mempertimbangkan draining dan spilling. Misalnya, jika satu cluster terkuras, Anda harus mempertimbangkan apakah cluster lain memiliki kapasitas yang cukup untuk menangani kelebihan traffic. Pertimbangan lainnya mencakup kapasitas yang memadai di zona atau region atau kebutuhan untuk mengirim traffic ke region yang berbeda (jika menggunakan satu cluster regional per region). Diagram berikut menunjukkan traffic yang sedang dihapus (terkadang disebut sebagai menguras cluster) dari satu cluster dan dikirim ke cluster lain yang menjalankan layanan terdistribusi yang sama.
Cluster dan Service terdistribusi
Desain cluster berbasis layanan menentukan bahwa arsitektur cluster (jumlah, ukuran, dan lokasi) ditentukan oleh Service yang perlu dijalankan di cluster tersebut. Oleh karena itu, penempatan cluster Anda ditentukan oleh tempat Service terdistribusi diperlukan. Pertimbangkan hal berikut saat menentukan penempatan Service yang terdistribusi:
- Persyaratan lokasi. Di region mana Service perlu disalurkan?
- Kekritisan. Seberapa penting ketersediaan Service untuk bisnis?
- SLO. Apa saja tujuan tingkat layanan untuk layanan (biasanya berdasarkan kekritisan)?
- Ketahanan. Seberapa tangguh seharusnya Service ini? Apakah Service ini harus tahan terhadap kegagalan cluster, zona, atau bahkan regional?
Saat merencanakan upgrade cluster, Anda harus mempertimbangkan jumlah Service yang terpengaruh oleh satu cluster saat cluster dikosongkan, dan Anda harus mempertimbangkan perlunya mengalihkan setiap Service ini ke cluster lain yang sesuai. Cluster dapat berupa tenant tunggal atau multi-tenant. Cluster tenant tunggal hanya melayani satu Service atau produk yang diwakili oleh serangkaian Service. Cluster tenant tunggal tidak membagikan cluster dengan Service atau produk lainnya. Cluster multi-tenant dapat menjalankan banyak Service dan produk yang biasanya dipartisi ke dalam namespace.
Berdampak bagi tim
Peristiwa cluster tidak hanya memengaruhi Service, tetapi juga dapat memengaruhi tim. Misalnya, tim DevOps mungkin perlu mengalihkan atau menghentikan pipeline CI/CD mereka selama upgrade cluster. Demikian pula, tim dukungan dapat diberi tahu tentang pemadaman yang direncanakan. Otomatisasi dan alat harus tersedia untuk membantu mengurangi dampaknya bagi beberapa tim. Upgrade fleet cluster atau cluster harus dianggap sebagai rutin dan tanpa insiden negatif saat semua tim diberi tahu.
Pengaturan waktu, penjadwalan, dan koordinasi
Kubernetes merilis versi minor baru setiap tiga bulan dan mempertahankan tiga rilis terakhir. Anda harus merencanakan waktu dan penjadwalan upgrade cluster dengan cermat. Harus ada perjanjian antara pemilik layanan, operator layanan, dan administrator platform tentang kapan upgrade ini dilakukan. Saat merencanakan upgrade, pertimbangkan pertanyaan-pertanyaan berikut:
- Seberapa sering Anda melakukan upgrade? Apakah Anda melakukan upgrade setiap kuartal atau pada linimasa yang berbeda?
- Kapan Anda melakukan upgrade? Apakah Anda melakukan upgrade di awal kuartal saat bisnis melambat atau selama periode nonaktif bisnis lainnya yang didorong oleh industri Anda?
- Kapan sebaiknya Anda tidak melakukan upgrade? Apakah Anda memiliki perencanaan yang jelas kapan sebaiknya tidak melakukan upgrade, misalnya, hindari peristiwa berskala puncak seperti Black Friday, Cyber Monday, atau selama konferensi tingkat tinggi serta acara khusus industri lainnya.
Penting untuk menerapkan strategi yang dikomunikasikan secara jelas dengan pemilik Service serta tim operasi dan dukungan. Seharusnya tidak ada kejutan dan semua orang harus tahu waktu dan cara cluster diupgrade. Hal ini membutuhkan koordinasi yang jelas dengan semua tim yang terlibat. Satu Service memiliki beberapa tim yang berinteraksi dengannya. Biasanya, tim ini dapat dikelompokkan ke dalam kategori berikut:
- Developer Service, yang bertanggung jawab untuk membuat dan membuat coding logika bisnis ke dalam Service.
- Operator Service, yang bertanggung jawab untuk menjalankan Service dengan aman dan andal. Operator dapat terdiri dari beberapa tim seperti administrator kebijakan atau keamanan, administrator jaringan, dan tim dukungan.
Semua orang harus saling berkomunikasi selama upgrade cluster agar dapat mengambil tindakan yang tepat selama waktu ini. Salah satu pendekatannya adalah merencanakan upgrade dengan cara yang sama seperti saat Anda merencanakan insiden pemadaman. Anda memiliki perintah insiden, ruang chat, dan retrospektif (meskipun tidak ada pengguna yang terpengaruh). Untuk mengetahui informasi selengkapnya, lihat Respons insiden.
Strategi siklus proses cluster GKE
Bagian ini membahas strategi pengelolaan siklus proses cluster utama yang sering digunakan dalam arsitektur multi-cluster GKE. Penting untuk diperhatikan bahwa tidak ada strategi tunggal yang dapat berfungsi untuk semua skenario dan Anda dapat memilih beberapa strategi untuk berbagai kategori layanan dan kebutuhan bisnis.
Upgrade berkelanjutan
Diagram berikut menunjukkan strategi upgrade berkelanjutan.
Dengan menggunakan load balancer, satu cluster GKE dihabiskan untuk semua traffic dan diupgrade. Beban traffic yang telah terkuras dialihkan ke cluster GKE yang berbeda.
Meluncurkan upgrade adalah strategi yang paling sederhana dan hemat biaya dari
strategi yang dibahas dalam dokumen ini. Anda mulai dengan n jumlah cluster
yang menjalankan versi old_ver (atau produksi saat ini). Kemudian, Anda menghabiskan m
cluster sekaligus, jika m kurang dari n. Kemudian, Anda menghapus dan membuat ulang cluster
baru dengan versi baru, atau mengupgrade cluster yang dikosongkan.
Keputusan antara menghapus dan mengupgrade cluster baru bergantung pada ukuran cluster serta jika Anda menganggap cluster tersebut sebagai infrastruktur yang tidak dapat diubah. Infrastruktur yang tidak dapat diubah menentukan bahwa daripada terus-menerus mengupgrade cluster, yang mungkin memberikan hasil yang tidak diinginkan dari waktu ke waktu, Anda perlu membuat cluster baru dan menghindari penyimpangan konfigurasi yang tidak terduga.
Jika menggunakan GKE, Anda dapat membuat cluster GKE dengan satu perintah atau panggilan API. Strategi cluster baru mengharuskan Anda menyimpan seluruh konfigurasi cluster (manifes cluster) di luar cluster, biasanya dalam Git. Kemudian, Anda dapat menggunakan template konfigurasi yang sama di cluster baru. Jika ini adalah cluster baru, pastikan pipeline CI/CD Anda mengarah ke cluster yang benar. Setelah cluster dikonfigurasi dengan benar, Anda dapat mendorong traffic kembali ke cluster secara perlahan sambil memantau SLO Service.
Proses ini diulang untuk semua cluster. Bergantung pada perencanaan kapasitas, Anda dapat mengupgrade beberapa cluster sekaligus tanpa melanggar SLO Service.
Jika Anda lebih mengutamakan kemudahan dan biaya daripada ketahanan, gunakan strategi upgrade berkelanjutan. Selama strategi ini, Anda tidak akan pernah melebihi kapasitas yang diperlukan fleet GKE untuk semua layanan yang terdistribusi.
Diagram berikut membandingkan linimasa dan persyaratan kapasitas Service selama upgrade cluster GKE dalam arsitektur multi-cluster.
Diagram sebelumnya menunjukkan bahwa selama proses upgrade GKE, kapasitas untuk mendukung layanan tidak pernah berada di bawah kapasitas yang diperlukan. Saat cluster GKE yang akan diupgrade dikeluarkan dari rotasi, cluster lain akan ditingkatkan skalanya untuk mendukung beban tersebut.
Upgrade biru/hijau
Diagram berikut menunjukkan strategi upgrade biru/hijau.
Dalam diagram sebelumnya, ditambahkan sebuah cluster GKE baru yang menjalankan versi baru. Kemudian, load balancer digunakan untuk mengirim traffic ke cluster baru sambil secara perlahan menghabiskan salah satu cluster lama hingga tidak ada traffic yang dikirim ke cluster tersebut. Cluster lama yang telah dikosongkan sepenuhnya kemudian dapat dihapus. Proses yang sama dapat diikuti untuk cluster yang tersisa.
Strategi upgrade berwarna biru/hijau memberikan ketahanan tambahan.
Strategi ini mirip dengan upgrade berkelanjutan, tetapi lebih mahal. Satu-satunya
perbedaan adalah bahwa daripada menghabiskan cluster yang ada
terlebih dahulu, Anda membuat cluster m baru dengan versi terlebih dahulu, dengan m
kurang dari atau sama dengan n. Anda menambahkan cluster baru ke pipeline CI/CD, lalu secara perlahan menghalihkan traffic sambil memantau SLO Service. Jika cluster baru sepenuhnya mengambil traffic, Anda harus menguras dan menghapus cluster dengan versi lama.
Strategi biru/hijau untuk mengupgrade cluster mirip dengan strategi biru/hijau yang biasanya digunakan untuk Service. Membuat beberapa cluster baru sekaligus akan meningkatkan biaya keseluruhan, tetapi memberi Anda manfaat karena mempercepat waktu upgrade fleet. Biaya tambahan hanya berlaku selama durasi upgrade saat cluster tambahan digunakan. Manfaat membuat cluster baru terlebih dahulu adalah jika terjadi kegagalan, Anda dapat melakukan roll back. Anda juga dapat menguji cluster baru sebelum mengirim traffic produksi ke cluster tersebut. Karena cluster ini berdampingan dengan versi lamanya dalam jangka waktu yang singkat, biaya tambahannya tidak terlalu besar.
Jika Anda lebih mengutamakan kemudahan dan ketahanan dibandingkan biaya, gunakan strategi upgrade biru/hijau. Cluster tambahan ditambahkan terlebih dahulu dan melebihi kapasitas yang diperlukan fleet GKE selama durasi upgrade.
Dalam diagram sebelumnya, penambahan cluster baru terlebih dahulu akan meningkatkan kapasitas yang tersedia melebihi kapasitas yang diperlukan untuk sementara, sedangkan cluster lain dalam fleet akan dikosongkan dan dihapus dari fleet. Namun, setelah menghapus salah satu cluster lama (terkuras sepenuhnya), kapasitas akan kembali ke yang dibutuhkan. Perubahan kapasitas ini ditandai karena mungkin ada peningkatan biaya dengan model ini, bergantung pada jumlah dan ukuran cluster di fleet.
Upgrade cluster Canary
Upgrade cluster canary adalah strategi yang paling tangguh dan kompleks dari hal yang dibahas dalam dokumen ini. Strategi ini sepenuhnya memisahkan pengelolaan siklus proses cluster dari pengelolaan siklus proses Service, sehingga menawarkan risiko terendah dan ketahanan tertinggi untuk layanan Anda. Dalam strategi upgrade berkelanjutan dan biru/hijau sebelumnya, Anda mempertahankan seluruh fleet GKE pada satu versi. Dalam strategi ini, Anda mempertahankan dua atau mungkin tiga fleet cluster GKE yang menjalankan versi berbeda. Daripada mengupgrade cluster, sebaiknya migrasikan Service dari satu fleet cluster ke fleet cluster lainnya dari waktu ke waktu. Jika fleet GKE terlama habis (artinya semua Service telah dimigrasikan ke fleet GKE versi berikutnya), hapus fleet tersebut.
Strategi ini mengharuskan Anda mempertahankan minimal dua fleet GKE, satu untuk produksi saat ini dan satu untuk versi kandidat produksi berikutnya. Anda juga dapat mengelola lebih dari dua fleet GKE. Fleet tambahan memberi Anda lebih banyak fleksibilitas, tetapi biaya dan overhead operasional Anda juga meningkat. Fleet tambahan ini tidak sama dengan memiliki cluster di lingkungan yang berbeda, misalnya lingkungan pengembangan, staging, dan produksi. Lingkungan non-produksi sangat cocok untuk menguji fitur dan Service Kubernetes dengan traffic non-produksi.
Strategi penggunaan upgrade cluster canary ini menentukan bahwa Anda mempertahankan beberapa versi fleet GKE di lingkungan produksi. Ini serupa dengan strategi rilis terbatas yang sering digunakan oleh Service. Dengan deployment Service canary, pemilik Service selalu dapat menemukan masalah pada versi Service tertentu. Dengan cluster canary, pemilik Service juga harus memperhitungkan versi fleet GKE yang menjalankan Service mereka. Satu versi Service terdistribusi memiliki potensi untuk berjalan di beberapa versi fleet GKE. Migrasi Service dapat terjadi secara bertahap, sehingga Anda dapat melihat efek Service pada fleet baru sebelum mengirim semua traffic untuk Service ke cluster berversi baru.
Diagram berikut menunjukkan bahwa mengelola berbagai fleet cluster GKE dapat sepenuhnya memisahkan siklus proses cluster dari siklus proses layanan.
Diagram sebelumnya menunjukkan frontend Service Terdistribusi yang dimigrasikan secara perlahan dari satu fleet cluster GKE ke fleet berikutnya yang menjalankan versi baru hingga fleet yang lebih lama benar-benar terkuras dari waktu ke waktu. Setelah
dikosongkan, fleet dapat dihapus dan fleet baru dibuat. Semua layanan dimigrasikan ke fleet berikutnya, dengan menghapus fleet yang lebih lama saat dikuras.
Jika Anda mengutamakan ketahanan daripada hal lainnya, gunakan strategi upgrade cluster canary.
Pilih strategi upgrade
Diagram berikut dapat membantu Anda menentukan strategi yang paling cocok untuk Anda berdasarkan Service dan kebutuhan bisnis.
Diagram sebelumnya adalah pohon keputusan untuk membantu Anda memilih strategi upgrade yang tepat untuk Anda:
- Jika tidak memerlukan kontrol penuh atas versi dan waktu upgrade yang tepat, Anda dapat memilih fitur upgrade otomatis yang tersedia di GKE.
- Jika prioritas Anda adalah biaya rendah, Anda dapat memilih strategi upgrade berkelanjutan.
- Jika prioritas Anda adalah menyeimbangkan biaya dan ketahanan, Anda dapat memilih strategi biru/hijau.
- Jika prioritas Anda adalah ketahanan daripada biaya, Anda dapat memilih strategi upgrade cluster canary.
Pengelolaan traffic multi-cluster untuk siklus proses cluster GKE
Untuk mempertahankan ketersediaan layanan selama upgrade multi-cluster, Anda harus menghentikan dan mengalihkan traffic antar-cluster. Anda dapat mengelola traffic ini menggunakan Gateway multi-cluster (direkomendasikan) atau Multi Cluster Ingress. Multi-cluster Gateway adalah penerus Multi Cluster Ingress, dan memberikan pendekatan yang lebih ekspresif dan berorientasi pada peran untuk jaringan layanan.
Menggunakan Gateway multi-cluster untuk pengelolaan siklus proses cluster
Multi-cluster Gateway (MCG) menggunakan Gateway API untuk mengelola traffic bagi layanan yang di-deploy di beberapa cluster GKE dalam fleet.
Pengontrol Gateway GKE adalah layanan yang dihosting oleh Google yang memantau resource Gateway dan HTTPRoute di cluster konfigurasi yang ditetapkan. Pengontrol secara otomatis menyediakan dan memelihara infrastruktur load balancing, sehingga memberikan satu titik entri terpadu untuk aplikasi di seluruh cluster dalam fleet. Arsitektur ini memungkinkan Anda memisahkan siklus proses load balancer dari setiap cluster GKE tempat workload berada.
Untuk pengelolaan siklus proses cluster GKE, Gateway multi-cluster memungkinkan strategi kontrol traffic lanjutan:
- Upgrade blue-green: men-deploy cluster "green" baru dan secara bertahap mengalihkan traffic dari cluster "blue" dengan mengubah bobot di resource HTTPRoute.
- Load balancing berbasis kapasitas: mengalihkan traffic secara otomatis saat layanan di satu cluster mencapai batas kapasitas yang ditentukan, yang membantu melindunginya dari kelebihan beban selama upgrade bertahap.
- Failover berbasis kesehatan: memantau kesehatan backend di semua cluster dan secara otomatis mengalihkan traffic dari cluster yang sedang dikuras atau mengalami masalah.
Untuk mengetahui informasi selengkapnya, ikuti tutorial untuk men-deploy Gateway multi-cluster untuk pemisahan traffic berbobot.
Menggunakan Multi Cluster Ingress untuk pengelolaan siklus proses cluster
Solusi lain untuk pengelolaan traffic multi-cluster adalah Multi Cluster Ingress. Multi Cluster Ingress adalah pengontrol multi-cluster ingress yang dihosting Google Clouduntuk cluster GKE yang mendukung deployment resource load balancing bersama di seluruh cluster dan di seluruh region. Multi Cluster Ingress adalah solusi untuk mengirimkan traffic klien ke layanan terdistribusi yang berjalan pada banyak cluster di banyak region. Seperti Ingress untuk GKE, solusi ini menggunakan Cloud Load Balancing untuk mengirim traffic ke layanan backend. Layanan backend adalah Service terdistribusi. Layanan backend mengirimkan traffic ke beberapa backend, yang merupakan Service Kubernetes yang berjalan di beberapa cluster GKE. Untuk traffic Service-to-Service di seluruh cluster, Anda dapat menggunakan teknologi mesh layanan seperti Cloud Service Mesh atau Istio, yang menyediakan fungsi serupa di seluruh Service terdistribusi.
Untuk mengetahui informasi selengkapnya, ikuti tutorial untuk mengupgrade lingkungan GKE multi-cluster dengan Multi Cluster Ingress.
Langkah berikutnya
- Pelajari lebih lanjut Gateway multi-cluster.
- Pelajari Multi Cluster Ingress lebih lanjut.