Tentang upgrade GKE multi-cluster menggunakan Multi Cluster Ingress

Autopilot Standard

---

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, konsep dapat diterapkan ke solusi lain, misalnya, mengonfigurasi load balancer eksternal secara manual. Tersedia tutorial pendamping untuk dokumen ini yang menunjukkan cara mengupgrade lingkungan GKE multi-cluster dengan Multi Cluster Ingress. Dokumen ini ditujukan bagi administrator Google Cloud yang bertanggung jawab mengelola fleet untuk cluster GKE.

Kebutuhan akan arsitektur multi-cluster

Bagian ini membahas berbagai alasan mengapa Anda mungkin memerlukan arsitektur Kubernetes multi-cluster.

Kubernetes sebagai infrastruktur

Dokumen ini menganggap cluster Kubernetes sebagai komponen infrastruktur. Infrastruktur sekali pakai. Tidak ada perlakuan khusus yang harus diberikan pada komponen infrastruktur apa pun karena komponen telah disiapkan untuk memenuhi suatu tujuan. Tujuan Kubernetes adalah untuk memberikan otomatisasi dan orkestrasi kepada developer dan operator untuk melayani aplikasi dan layanan berbasis container kepada konsumen. Konsumen dapat berupa tim internal, layanan lain, atau pelanggan eksternal.

Skenario multi-cluster umum

Selain argumen Kubernetes sebagai infrastruktur, terdapat sejumlah alasan untuk memiliki lingkungan multi-cluster:

• Geografi. Banyak Service harus berada di beberapa region. Mendekatkan Service ke konsumen (di regionnya) akan memberikan pengalaman yang lebih baik berkat latensi yang lebih rendah daripada jika Service disajikan dari satu region. Cluster Kubernetes berjalan di satu region. Untuk deployment multi-regional, beberapa cluster Kubernetes di beberapa region diperlukan. Lingkungan multi-cloud atau hybrid cloud juga memerlukan beberapa cluster di setiap lingkungan. Cluster Kubernetes juga sering kali ditempatkan bersama sumber data Service (stateful). Aplikasi tertentu mungkin harus berada di lokasi (region dan zona) yang sama dengan backend-nya, misalnya, sistem manajemen database relasional (RDBMS).
• Tenancy dan lingkungan. Cluster Kubernetes dirancang untuk multi-tenancy. Beberapa tim dapat berbagi satu cluster untuk Service-nya masing-masing. Kubernetes menyediakan resource standar, seperti namespace, role-based access control (RBAC), kebijakan jaringan, dan autentikasi, untuk mengonfigurasi kontrol akses dengan benar di lingkungan multi-tenant. Dalam beberapa kasus, Service tertentu mungkin tidak dapat ditempatkan bersama dalam cluster dengan Service lain karena kebijakan perusahaan, privasi, keamanan, atau peraturan industri. Dalam kasus semacam ini, beberapa cluster diperlukan untuk memisahkan tenant tertentu ke dalam cluster-nya sendiri. Lingkungan (pengembangan, staging, dan produksi) juga sering dibuat sebagai cluster terpisah. Cakupan akses dan jenis aplikasi yang diinstal di lingkungan yang berbeda sangat bervariasi dan harus disimpan sebagai cluster terpisah.
• Komposisi dan fungsi. Ada kalanya, sebuah cluster dibuat untuk melakukan fungsi tertentu. Misalnya, alur kerja machine learning menggunakan Kubeflow atau tugas analisis data yang mungkin memerlukan node dengan GPU atau persyaratan hardware lainnya untuk cluster instance yang terdiri dari Spot VM untuk tujuan workload analisis batch. Persyaratan perangkat keras ini mungkin tidak berlaku untuk Service lain. Alur kerja ini mungkin tidak penting untuk menjalankan bisnis dan dapat memerlukan cluster sementara (cluster berdurasi singkat). Layanan bersama, seperti kemampuan observasi (logging, metrik, dan trace) serta alat CI/CD, lebih cocok di cluster admin platformnya sendiri. Cluster dengan fungsi khusus yang terpisah sering terlihat untuk alur kerja penting non-bisnis.
• Ketahanan. Beberapa cluster sering digunakan untuk meningkatkan ketahanan di lingkungan. Setiap cluster memiliki area dampak. Dalam konteks ini, area dampak adalah jumlah Service yang terkena dampak negatif karena malfungsi cluster, kesalahan konfigurasi, atau cluster yang offline karena pemeliharaan terencana atau tidak terencana. Jika Anda memiliki banyak cluster yang berukuran lebih kecil, Anda juga akan memiliki banyak area dampak yang berukuran lebih kecil. Jika sebuah Service ada di dua cluster, cluster tersebut akan berbagi beban secara merata. Jika satu cluster offline, 50% traffic akan terpengaruh. Jika Service yang sama disajikan oleh satu cluster, peristiwa apa pun pada cluster tersebut akan menyebabkan pemadaman 100% untuk Service tersebut. Karena alasan ini, banyak cluster juga sering digunakan untuk pemulihan dari bencana.

Dokumen ini berfokus pada aspek ketahanan dari deployment multi-cluster.

Service multi-cluster dan terdistribusi

Service terdistribusi adalah Service Kubernetes yang di-deploy ke beberapa cluster Kubernetes. Service Terdistribusi adalah Service stateless dan bertindak identik di beberapa cluster. Ini berarti layanan yang terdistribusi memiliki nama Service Kubernetes yang sama dan diterapkan dalam namespace yang sama di beberapa cluster. Service Kubernetes terikat dengan cluster Kubernetes tempatnya berjalan. Jika cluster Kubernetes offline, begitu pula Service Kubernetes. Service Terdistribusi diabstraksi dari cluster Kubernetes individual. Jika satu atau beberapa cluster Kubernetes tidak aktif, Service yang terdistribusi mungkin sedang online dan dalam tujuan tingkat layanan (SLO).

Dalam diagram berikut, frontend adalah Service terdistribusi yang berjalan di beberapa cluster dengan nama Service dan namespace yang sama.

Dengan arsitektur ini, Service frontend tidak terikat dengan satu cluster dan direpresentasikan secara konseptual dalam diagram sebagai lapisan yang mencakup lapisan infrastruktur cluster Kubernetes. Jika salah satu cluster individual yang menjalankan Service frontend tidak aktif, frontend akan tetap online. Tersedia Service tambahan yang berjalan pada satu cluster individual: Service accounts dan Service ledger. Waktu beroperasi dan ketersediaannya bergantung pada waktu beroperasi cluster Kubernetes tempat cluster tersebut berada.

Ketahanan adalah salah satu alasan deployment multicluster. Service Terdistribusi membuat layanan yang tangguh pada arsitektur multi-cluster. Layanan stateless adalah kandidat utama untuk layanan terdistribusi di lingkungan multi-cluster. Persyaratan dan pertimbangan berikut berlaku saat Anda bekerja dengan Service yang terdistribusi:

• Jaringan multi-cluster. Anda dapat mengirim traffic yang ditujukan ke Service terdistribusi ke cluster yang menjalankan Service tersebut menggunakan teknologi multi-cluster ingress seperti Multi Cluster Ingress atau dengan menggunakan load balancer eksternal atau solusi proxy Anda sendiri. Opsi mana pun yang Anda gunakan harus memberi Anda kontrol terkait kapan, di mana, dan berapa banyak traffic yang dirutekan ke instance tertentu dari Service yang terdistribusi. Diagram berikut menunjukkan load balancer yang mengirimkan traffic ke Service terdistribusi frontend yang berjalan di dua cluster GKE.

  

• Kemampuan observasi. Gunakan alat untuk mengukur SLO Anda—biasanya ketersediaan dan latensi—secara kolektif untuk Service yang terdistribusi. Konfigurasi ini menyediakan tampilan global tentang performa setiap Service di berbagai cluster. Meskipun Service terdistribusi bukanlah resource yang ditentukan dengan baik di sebagian besar solusi kemampuan observasi, Anda dapat mengumpulkan dan menggabungkan metrik Service Kubernetes satu per satu. Solusi seperti Cloud Monitoring atau alat open source seperti Grafana menyediakan metrik Service Kubernetes. Solusi mesh layanan seperti Istio dan Anthos Service Mesh juga menyediakan metrik Service tanpa memerlukan instrumentasi.

• Penempatan Service. Service Kubernetes menyediakan fault-tolerance level node dalam satu cluster Kubernetes. Ini berarti bahwa Service Kubernetes dapat menahan pemadaman node. Selama pemadaman node, node bidang kontrol Kubernetes secara otomatis menjadwalkan ulang Pod ke node yang berfungsi dengan baik. Service terdistribusi menyediakan fault tolerance tingkat cluster. Ini berarti bahwa Service yang terdistribusi dapat menahan pemadaman cluster. Saat Anda merencanakan kapasitas untuk Service yang terdistribusi, Anda harus mempertimbangkan penempatan Service ini. Service terdistribusi tidak perlu berjalan di setiap cluster. Cluster tempat Service terdistribusi berjalan bergantung pada persyaratan berikut:

  • Di mana, atau di wilayah mana, Service diperlukan?
  • SLO apa yang diperlukan untuk Service yang terdistribusi?
  • Jenis fault tolerance apa yang diperlukan untuk Service terdistribusi—cluster, zona, atau regional? Misalnya, apakah Anda memerlukan beberapa cluster dalam satu zona, atau beberapa cluster di seluruh zona dalam satu atau beberapa region?

  • Tingkat pemadaman layanan apa yang harus ditangani oleh Service yang terdistribusi dalam skenario terburuk? Opsi berikut tersedia di lapisan cluster:

    • N+1 (dengan N mewakili jumlah cluster yang diperlukan untuk memenuhi kebutuhan kapasitas layanan). Service terdistribusi dapat menghadapi kegagalan cluster tunggal
    • N+2. Service terdistribusi dapat menahan dua kegagalan serentak. Misalnya, pemadaman Service Kubernetes yang terencana dan tidak terencana di dua cluster secara bersamaan.

• Peluncuran dan rollback. Service Terdistribusi, seperti Service Kubernetes, memungkinkan peluncuran dan rollback bertahap. Tidak seperti Service Kubernetes, Service terdistribusi memungkinkan cluster menjadi unit deployment tambahan sebagai sarana untuk perubahan bertahap. Peluncuran dan rollback juga bergantung pada Persyaratan Service. Dalam beberapa kasus, Anda mungkin perlu mengupgrade layanan pada semua cluster sekaligus, misalnya, perbaikan bug. Dalam kasus lain, Anda mungkin perlu meluncurkan (atau mengatur bertahap) perubahan pada cluster satu per satu secara perlahan. Peluncuran bertahap ini menurunkan risiko pada Service terdistribusi dengan menerapkan perubahan pada layanan secara bertahap. Namun, proses ini mungkin memerlukan waktu lebih lama bergantung pada jumlah cluster. Tidak ada satu strategi upgrade yang dianggap terbaik. Sering kali, beberapa strategi peluncuran dan rollback digunakan bergantung pada persyaratan Service terdistribusi. Poin penting di sini adalah bahwa Service yang terdistribusi harus memungkinkan perubahan yang bertahap dan terkendali di lingkungan.

• Kelangsungan bisnis dan pemulihan dari bencana (BCDR). Istilah-istilah ini sering digunakan bersama. Kelangsungan bisnis mengacu pada kelanjutan layanan penting jika terjadi peristiwa besar (terencana atau tidak terencana), sedangkan pemulihan dari bencana mengacu pada langkah-langkah yang diambil atau diperlukan untuk mengembalikan operasi bisnis ke keadaan normal setelah peristiwa tersebut. Ada banyak strategi untuk BCDR yang berada di luar cakupan dokumen ini. BCDR membutuhkan beberapa tingkat redundansi dalam sistem dan Service. Premis kunci dari Service terdistribusi adalah layanan tersebut berjalan di beberapa lokasi (cluster, zona, dan region).

  Strategi BCDR sering kali bergantung pada strategi peluncuran dan rollback yang telah dibahas sebelumnya. Misalnya, jika peluncuran dilakukan secara bertahap atau terkontrol, efek bug atau push konfigurasi yang buruk dapat diketahui lebih awal tanpa memengaruhi sejumlah besar pengguna. Dalam skala besar dan disertai dengan laju perubahan yang cepat (misalnya dalam praktik CI/CD modern), umumnya tidak semua pengguna mendapatkan server versi yang sama dari Service terdistribusi. Perencanaan dan strategi BCDR dalam sistem dan Service terdistribusi berbeda dengan arsitektur monolitik tradisional. Dalam sistem tradisional, perubahan dilakukan secara menyeluruh, yang memengaruhi sejumlah besar—atau mungkin setiap—pengguna, sehingga harus memiliki sistem cadangan atau redundan jika terjadi efek yang tidak diinginkan dari peluncuran. Dalam sistem dan Service terdistribusi, hampir semua perubahan dilakukan secara bertahap agar hanya memengaruhi sejumlah kecil pengguna.

• Pengelolaan siklus proses cluster. Seperti peluncuran dan rollback terkontrol, Service terdistribusi memungkinkan pengelolaan siklus proses cluster terkontrol. Service Terdistribusi memberikan ketahanan tingkat cluster sehingga cluster dapat dikeluarkan dari rotasi untuk pemeliharaan. Pengelolaan siklus proses cluster adalah prinsip Service terdistribusi yang tidak berlaku untuk Service Kubernetes.

Bagian selanjutnya dari dokumen ini berfokus pada aspek siklus proses cluster dari Service terdistribusi.

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.

Dokumen ini berfokus pada pengelolaan siklus proses GKE. Namun, Anda dapat menerapkan konsep ini ke distribusi Kubernetes lainnya.

Pembuatan versi dan upgrade GKE

Sebelum membahas strategi dan perencanaan pengelolaan siklus proses cluster, penting untuk memahami apa yang membentuk upgrade cluster.

Cluster berisi dua komponen: node bidang kontrol dan worker node. Upgrade cluster Kubernetes mengharuskan semua node diupgrade ke versi yang sama. Kubernetes mengikuti skema pembuatan versi semantik. Versi Kubernetes diekspresikan sebagai X.Y.Z: dengan X adalah versi utama, Y adalah versi minor, dan Z adalah versi patch. Rilis minor terjadi kira-kira setiap tiga bulan (triwulanan) dan project Kubernetes mengelola cabang rilis untuk tiga rilis minor terbaru. Ini berarti bahwa rilis minor Kubernetes yang berusia sembilan bulan tidak lagi dikelola dan mungkin memerlukan perubahan API saat Anda mengupgrade ke versi terbaru. Upgrade Kubernetes harus direncanakan dengan ritme yang teratur. Sebaiknya lakukan upgrade GKE terrencana setiap tiga bulan atau setiap dua kuartal.

Cluster GKE mendukung pengoperasian versi Kubernetes dari rilis minor yang didukung. Setidaknya dua versi minor tersedia pada waktu tertentu.

GKE memiliki jenis ketersediaan cluster berikut:

• Cluster zona tunggal. Node bidang kontrol tunggal dan semua node pool berada dalam satu zona dalam satu region.
• Cluster multi-zona. Satu node bidang kontrol berada di satu zona dan node pool berada di beberapa zona dalam satu region.
• Cluster regional. Beberapa node bidang kontrol dan node pool di beberapa zona dalam satu region.

GKE adalah layanan terkelola dan menawarkan upgrade otomatis untuk node bidang kontrol dan worker node.

Upgrade otomatis GKE

Upgrade otomatis GKE adalah strategi siklus proses cluster yang populer dan sering digunakan. Upgrade otomatis GKE menyediakan cara yang terkelola sepenuhnya untuk terus mengupdate cluster GKE Anda ke versi yang didukung. GKE secara otomatis mengupgrade node bidang kontrol dan worker node secara terpisah:

• Upgrade otomatis master. Secara default, node bidang kontrol GKE diupgrade secara otomatis. Cluster zona tunggal dan multi-zona memiliki satu bidang kontrol (node bidang kontrol). Selama upgrade node bidang kontrol, workload terus berjalan. Namun, Anda tidak dapat men-deploy workload baru, mengubah workload yang ada, atau membuat perubahan lain pada konfigurasi cluster hingga upgrade selesai.

  Cluster regional memiliki beberapa replika bidang kontrol, dan hanya satu replika yang diupgrade dalam satu waktu. Selama upgrade, cluster akan tetap sangat tersedia, dan setiap replika bidang kontrol hanya tidak tersedia saat sedang diupgrade.

• Upgrade otomatis worker node. Node pool diupgrade satu per satu. Dalam node pool, node diupgrade satu per satu dalam urutan yang tidak ditentukan. Anda dapat mengubah jumlah node yang diupgrade sekaligus, tetapi proses ini dapat memerlukan waktu beberapa jam, bergantung pada jumlah node dan konfigurasi workloadnya.

Strategi siklus proses upgrade otomatis GKE

Sebaiknya gunakan upgrade otomatis GKE jika memungkinkan. Upgrade otomatis GKE memprioritaskan kenyamanan daripada kontrol. Namun, upgrade otomatis GKE menyediakan banyak cara untuk memengaruhi kapan dan bagaimana cluster Anda diupgrade dalam parameter tertentu. Anda dapat memengaruhi masa pemeliharaan dan pengecualian pemeliharaan. Saluran rilis memengaruhi pemilihan versi dan strategi upgrade node memengaruhi urutan dan waktu upgrade node. Terlepas dari kontrol dan cluster regional (dengan beberapa bidang kontrol Kubernetes), upgrade otomatis GKE tidak menjamin waktu beroperasi layanan. Anda dapat memilih untuk tidak menggunakan fitur upgrade otomatis GKE jika memerlukan satu atau beberapa hal berikut:

• Kontrol versi cluster GKE yang tepat.
• Kontrol waktu yang tepat untuk mengupgrade GKE.
• Mengontrol strategi upgrade (dibahas di bagian berikutnya) untuk fleet GKE Anda.

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.

Menggunakan Multi Cluster Ingress untuk pengelolaan siklus proses cluster GKE

Hampir semua strategi bergantung pada kemampuan untuk menghabiskan dan mengalihkan traffic ke cluster lain selama upgrade. Solusi yang menyediakan kemampuan multi-cluster ingress ini adalah Multi Cluster Ingress. Multi Cluster Ingress adalah pengontrol multi-cluster ingress yang dihosting Google Cloud untuk cluster GKE yang mendukung deployment resource load balancing bersama di seluruh cluster dan di berbagai 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 juga 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 sepertiAnthos Service Mesh atau Istio, yang menyediakan fungsi serupa di seluruh Service terdistribusi.

Pada lingkungan multi-cluster GKE, Anda dapat menggunakan Multi Cluster Ingress untuk memanipulasi traffic ke beberapa cluster sesuai dengan strategi pengelolaan siklus proses cluster yang telah dibahas sebelumnya. Anda dapat mengikuti tutorial menggunakan Multi Cluster Ingress untuk upgrade GKE menggunakan strategi biru-hijau.

Langkah selanjutnya

• Pelajari Multi Cluster Ingress lebih lanjut.
• Pelajari cara men-deploy Multi Cluster Ingress di berbagai cluster.