Halaman ini memberikan penjelasan lebih mendalam tentang cara fleet membantu Anda mengelola deployment multi-cluster, termasuk beberapa terminologi dan konsep fleet utama. Fleet adalah konsep Google Cloud untuk mengatur cluster dan resource lainnya secara logis, serta memungkinkan Anda menggunakan dan mengelola kemampuan multi-cluster serta menerapkan kebijakan yang konsisten di seluruh sistem Anda. Fleet membentuk bagian penting dari cara kerja fungsi multi-cluster perusahaan di Google Cloud.
Panduan ini dirancang untuk pembaca teknis, termasuk arsitek sistem, operator platform, dan operator layanan, yang ingin memanfaatkan beberapa cluster dan infrastruktur terkait. Konsep ini berguna di mana pun organisasi Anda menjalankan beberapa cluster, baik di Google Cloud, di beberapa penyedia cloud, maupun di lokal.
Anda harus memahami konsep dasar Kubernetes seperti cluster dan namespace; jika belum, lihat dasar-dasar Kubernetes, dokumentasi GKE, dan Menyiapkan aplikasi untuk Cloud Service Mesh.
Jika Anda ingin mempelajari lebih lanjut platform GKE Enterprise dan komponen yang menggunakan fleet, lihat ringkasan teknis GKE Enterprise dan tutorial Menjelajahi GKE Enterprise. Namun, Anda tidak perlu memahami GKE Enterprise untuk mengikuti panduan ini.
Terminologi
Berikut adalah beberapa istilah penting yang kami gunakan saat membahas fleet.
Resource yang mengetahui fleet
Resource yang mengetahui fleet adalah resource project Google Cloud yang dapat dikelompokkan dan dikelola secara logis sebagai fleet. Saat ini, hanya cluster Kubernetes yang dapat menjadi anggota fleet.
Project host fleet
Penerapan fleet, seperti banyak resource Google Cloud lainnya, berakar pada project Google Cloud, yang kami sebut sebagai project host fleet. Project Google Cloud tertentu hanya dapat memiliki satu fleet (atau tidak ada fleet) yang terkait dengannya. Batasan ini memperkuat penggunaan project Google Cloud untuk memberikan isolasi yang lebih kuat antara resource yang tidak diatur atau digunakan bersama.
Mengelompokkan infrastruktur
Konsep penting pertama dari fleet adalah konsep pengelompokan—yaitu, memilih bagian resource yang terkait dengan fleet-aware yang harus dijadikan bagian dari fleet. Keputusan tentang apa yang akan dikelompokkan bersama memerlukan jawaban atas pertanyaan berikut:
- Apakah resource saling terkait?
- Resource yang memiliki komunikasi lintas layanan dalam jumlah besar akan mendapatkan manfaat terbesar jika dikelola bersama dalam satu grup.
- Resource di lingkungan deployment yang sama (misalnya, lingkungan produksi Anda) harus dikelola bersama dalam satu fleet.
- Siapa yang mengelola resource?
- Memiliki kontrol terpadu (atau setidaknya saling dipercaya) atas resource sangat penting untuk memastikan integritas inventaris.
Untuk mengilustrasikan hal ini, pertimbangkan organisasi yang memiliki beberapa lini bisnis (LOB). Dalam hal ini, layanan jarang berkomunikasi di seluruh batas LOB, layanan di LOB yang berbeda dikelola secara berbeda (misalnya, siklus upgrade berbeda di antara LOB), dan layanan tersebut bahkan mungkin memiliki kumpulan administrator yang berbeda untuk setiap LOB. Dalam hal ini, sebaiknya Anda memiliki fleet per LOB. Setiap LOB juga kemungkinan mengadopsi beberapa fleet untuk memisahkan layanan produksi dan non-produksi.
Saat konsep fleet lainnya dibahas di bagian berikut, Anda mungkin menemukan alasan lain untuk membuat beberapa fleet saat mempertimbangkan kebutuhan organisasi tertentu.
Kesamaan
Konsep penting dalam fleet adalah konsep kesamaan. Artinya, saat Anda menggunakan fitur tertentu yang diaktifkan untuk fleet, beberapa objek Kubernetes seperti namespace yang memiliki nama yang sama di cluster yang berbeda akan diperlakukan seolah-olah objek tersebut sama. Normalisasi ini dilakukan untuk mempermudah pengelolaan resource armada. Jika Anda menggunakan fitur yang memanfaatkan kesamaan, asumsi kesamaan ini memberikan beberapa panduan yang kuat tentang cara menyiapkan namespace, layanan, dan identitas. Namun, hal ini juga mengikuti apa yang kami temukan bahwa sebagian besar organisasi telah menerapkannya sendiri.
Berbagai jenis kesamaan memberikan manfaat yang berbeda, seperti yang ditunjukkan dalam tabel berikut:
| Properti kesamaan | Memungkinkan Anda... |
|---|---|
| Namespace dianggap sama di beberapa cluster. |
|
| Kombinasi namespace dan nama layanan dianggap sama di beberapa cluster. Layanan dengan nama yang sama di namespace yang sama menggunakan pemilih label yang sama. |
|
| Kombinasi namespace dan akun layanan (identitas) dianggap sama di beberapa cluster. |
|
Seperti yang ditunjukkan, fitur armada yang berbeda mengandalkan jenis kesamaan yang berbeda. Sejumlah kecil fitur tidak menggunakan kesamaan sama sekali. Anda dapat mempelajari lebih lanjut hal ini di Fitur mana yang menggunakan kesamaan?, termasuk fitur yang dapat Anda gunakan tanpa harus mempertimbangkan kesamaan di seluruh fleet dan fitur yang mungkin memerlukan perencanaan yang lebih cermat.
Kesamaan namespace
Contoh dasar kesamaan dalam fleet adalah kesamaan namespace. Namespace dengan nama yang sama di cluster yang berbeda dianggap sama oleh banyak fitur fleet. Cara lain untuk memahami properti ini adalah bahwa namespace ditentukan secara logis di seluruh fleet, meskipun pembuatan instance namespace hanya ada di sebagian resource fleet.
Perhatikan contoh namespace backend berikut. Meskipun instance namespace hanya dibuat di Cluster A dan B, namespace tersebut secara implisit dicadangkan di Cluster C (hal ini memungkinkan layanan di namespace backend juga dijadwalkan ke Cluster C jika diperlukan).
Artinya, namespace dialokasikan untuk seluruh fleet, bukan per cluster. Dengan demikian, kesamaan namespace memerlukan kepemilikan namespace yang konsisten di seluruh fleet.
Kesamaan layanan
Cloud Service Mesh dan Multi Cluster Ingress menggunakan konsep kesamaan layanan dalam namespace. Seperti kesamaan namespace, hal ini menyiratkan bahwa layanan dengan namespace dan nama layanan yang sama dianggap sebagai layanan yang sama.
Endpoint layanan dapat digabungkan di seluruh mesh dalam kasus Cloud Service Mesh. Dengan Multi Cluster Ingress, resource MultiClusterService (MCS) membuat penggabungan endpoint lebih eksplisit; namun, sebaiknya gunakan praktik serupa terkait penamaan. Oleh karena itu, penting untuk memastikan bahwa layanan yang bernama sama dalam namespace yang sama sebenarnya adalah hal yang sama.
Pada contoh berikut, traffic internet di-load balance di seluruh layanan bernama sama
dalam namespace frontend yang ada di Cluster B dan C. Demikian pula,
dengan menggunakan properti service mesh dalam fleet, layanan di namespace frontend dapat
menjangkau layanan dengan nama yang sama di namespace auth yang ada di Cluster A dan C.
Kesamaan identitas saat mengakses resource eksternal
Dengan Workload Identity Federation fleet, layanan dalam fleet dapat memanfaatkan identitas umum saat keluar untuk mengakses resource eksternal seperti layanan Google Cloud, object store, dan sebagainya. Identitas umum ini memungkinkan layanan dalam armada untuk mengakses resource eksternal satu kali, bukan per cluster.
Untuk mengilustrasikan hal ini lebih lanjut, pertimbangkan contoh berikut. Cluster A, B,
dan C terdaftar dalam identitas umum dalam fleet mereka. Saat layanan di
namespace backend mengakses resource Google Cloud, identitasnya
akan dipetakan ke akun layanan Google Cloud umum yang disebut back. Akun layanan Google Cloud back dapat diberi otorisasi di sejumlah layanan terkelola, mulai dari Cloud Storage hingga Cloud SQL. Saat resource fleet baru
seperti cluster ditambahkan di namespace backend, resource tersebut akan otomatis
mewarisi properti kesamaan identitas beban kerja.
Karena kesamaan identitas, semua resource dalam fleet harus dipercaya dan dikelola dengan baik. Melihat kembali contoh sebelumnya, jika Cluster C dimiliki oleh tim terpisah yang tidak tepercaya, mereka juga dapat membuat namespace backend dan mengakses layanan terkelola seolah-olah mereka adalah backend di Cluster A atau B.
Kesamaan identitas dalam fleet
Dalam fleet, kesamaan identitas digunakan dengan cara yang sama seperti kesamaan identitas eksternal yang telah kita bahas sebelumnya. Sama seperti layanan fleet yang diberi otorisasi satu kali untuk layanan eksternal, layanan tersebut juga dapat diberi otorisasi secara internal.
Dalam contoh berikut, kita menggunakan Cloud Service Mesh
untuk membuat mesh layanan multi-cluster tempat frontend memiliki akses ke backend.
Dengan Cloud Service Mesh dan
armada, kita tidak perlu menentukan bahwa frontend di cluster B dan C dapat
mengakses backend di Cluster A dan B. Sebagai gantinya, kita hanya menentukan bahwa frontend
dalam fleet dapat mengakses backend dalam fleet. Properti ini tidak hanya membuat
otorisasi lebih sederhana, tetapi juga membuat batas resource lebih fleksibel; sekarang
workload dapat dengan mudah dipindahkan dari cluster ke cluster tanpa memengaruhi cara
otorisasinya. Seperti kesamaan identitas beban kerja, tata kelola atas resource
armada sangat penting untuk memastikan integritas komunikasi
layanan ke layanan.
Fitur mana yang menggunakan kesamaan?
Sejumlah fitur fleet tidak bergantung pada kesamaan sama sekali, dan dapat diaktifkan serta digunakan tanpa harus mempertimbangkan apakah Anda ingin mengasumsikan bentuk kesamaan apa pun di seluruh fleet. Fitur lain (termasuk Config Sync dan Policy Controller) dapat menggunakan kesamaan - misalnya, jika Anda ingin memilih namespace di beberapa cluster anggota fleet untuk konfigurasi dari satu sumber tepercaya - tetapi tidak memerlukannya untuk semua kasus penggunaan. Terakhir, ada fitur seperti Multi Cluster Ingress dan Federasi Workload Identity seluruh fleet yang selalu mengasumsikan beberapa bentuk kesamaan di seluruh cluster, dan mungkin harus diterapkan dengan hati-hati bergantung pada kebutuhan Anda dan workload yang ada.
Beberapa fitur armada (seperti Workload Identity Federation armada) mengharuskan seluruh armada Anda siap untuk asumsi kesamaan yang digunakannya. Fitur lain seperti pengelolaan tim memungkinkan Anda secara bertahap memilih untuk menggunakan kesamaan di tingkat namespace atau cakupan tim.
Tabel berikut menunjukkan fitur yang require satu atau beberapa konsep kesamaan yang dijelaskan di bagian ini.
| Fitur | Mendukung penerapan kesamaan bertahap | Bergantung pada kesamaan namespace | Bergantung pada kesamaan layanan | Bergantung pada kesamaan identitas |
|---|---|---|---|---|
| Fleet | T/A | Tidak | Tidak | Tidak |
| Otorisasi Biner | T/A | Tidak | Tidak | Tidak |
| Enkripsi transparan antar-node | T/A | Tidak | Tidak | Tidak |
| Kebijakan Jaringan Berbasis Nama Domain yang Memenuhi Syarat Sepenuhnya | T/A | Tidak | Tidak | Tidak |
| Menghubungkan gateway | T/A | Tidak | Tidak | Tidak |
| Config Sync | T/A | Tidak | Tidak | Tidak |
| Pengontrol Kebijakan | T/A | Tidak | Tidak | Tidak |
| Postur Keamanan GKE | T/A | Tidak | Tidak | Tidak |
| Advanced Vulnerability Insights | T/A | Tidak | Tidak | Tidak |
| Postur Kepatuhan | T/A | Tidak | Tidak | Tidak |
| Pengurutan peluncuran | T/A | Tidak | Tidak | Tidak |
| Pengelolaan tim | Ya | Ya | Ya | Tidak |
| Multi Cluster Ingress | Ya | Ya | Ya | Ya |
| Layanan Multi-Cluster | Ya | Ya | Ya | Ya |
| Workload Identity Federation Flotte | Tidak | Ya | Ya | Ya |
| Mesh Layanan Cloud | Tidak | Ya | Ya | Ya |
Eksklusivitas
Resource yang mengetahui fleet hanya dapat menjadi anggota satu fleet pada waktu tertentu, yaitu batasan yang diterapkan oleh alat dan komponen Google Cloud. Batasan ini memastikan bahwa hanya ada satu sumber tepercaya yang mengatur cluster. Tanpa eksklusivitas, bahkan komponen yang paling sederhana sekalipun akan menjadi rumit untuk digunakan, sehingga organisasi Anda harus memahami dan mengonfigurasi cara beberapa komponen dari beberapa fleet akan berinteraksi.
Kepercayaan tinggi
Kesamaan layanan, kesamaan identitas beban kerja, dan kesamaan identitas mesh dibangun berdasarkan prinsip kepercayaan tinggi di antara anggota fleet. Kepercayaan ini memungkinkan peningkatan pengelolaan resource ini ke fleet, bukan mengelola resource per resource (yaitu, cluster per cluster untuk resource Kubernetes), dan pada akhirnya membuat batas cluster menjadi kurang penting.
Dengan kata lain, dalam fleet, cluster memberikan perlindungan dari masalah radius ledakan, ketersediaan (baik bidang kontrol maupun infrastruktur yang mendasarinya), tetangga yang berisik, dan sebagainya. Namun, batasan ini bukan merupakan batas isolasi yang kuat untuk kebijakan dan tata kelola karena administrator anggota apa pun dalam grup berpotensi memengaruhi operasi layanan di anggota grup lainnya.
Oleh karena itu, sebaiknya cluster yang tidak dipercaya oleh administrator fleet ditempatkan di fleet mereka sendiri agar tetap terisolasi. Kemudian, jika diperlukan, setiap layanan dapat diberi otorisasi di seluruh batas armada.
Cakupan tim
Cakupan tim adalah mekanisme untuk membagi lebih lanjut fleet Anda menjadi grup cluster, sehingga Anda dapat menentukan resource yang mengetahui fleet yang ditetapkan ke tim aplikasi tertentu. Bergantung pada kasus penggunaan Anda, setiap cluster anggota fleet dapat dikaitkan dengan tidak ada tim, satu tim, atau beberapa tim, sehingga beberapa tim dapat berbagi cluster. Anda juga dapat menggunakan cakupan tim untuk mengurutkan peluncuran upgrade cluster di seluruh fleet, meskipun hal ini mengharuskan setiap cluster hanya dikaitkan dengan satu tim.
Cakupan tim dapat memiliki namespace armada yang ditentukan secara eksplisit yang terkait dengannya, dengan namespace dianggap sama di seluruh cakupan. Hal ini memberi Anda kontrol yang lebih terperinci atas namespace dibandingkan kesamaan namespace default yang disediakan oleh fleet saja.
Komponen yang mendukung Fleet
Semua komponen GKE Enterprise dan GKE berikut memanfaatkan konsep fleet seperti kesamaan namespace dan identitas untuk memberikan cara yang lebih sederhana untuk menggunakan cluster dan layanan Anda. Untuk persyaratan atau batasan saat ini terkait penggunaan fleet dengan setiap komponen, lihat persyaratan komponen.
Workload identity pool
Flot menawarkan workload identity pool umum yang dapat digunakan untuk melakukan autentikasi dan memberikan otorisasi pada beban kerja secara seragam dalam mesh layanan dan ke layanan eksternal.Cloud Service Mesh
Cloud Service Mesh adalah serangkaian alat yang membantu Anda memantau dan mengelola mesh layanan yang andal di Google Cloud, lokal, dan lingkungan yang didukung lainnya. Anda dapat membentuk mesh layanan di seluruh cluster yang merupakan bagian dari fleet yang sama.Config Sync
Config Sync memungkinkan Anda men-deploy dan memantau paket konfigurasi deklaratif untuk sistem yang disimpan di sumber tepercaya pusat, seperti repositori Git, yang memanfaatkan konsep inti Kubernetes seperti namespace, label, dan anotasi. Dengan Config Sync, konfigurasi ditentukan di seluruh armada, tetapi diterapkan dan diberlakukan secara lokal di setiap resource anggota.Pengontrol Kebijakan
Pengontrol Kebijakan memungkinkan Anda menerapkan dan menegakkan kebijakan deklaratif untuk cluster Kubernetes. Kebijakan ini berfungsi sebagai pembatasan dan dapat membantu pengelolaan praktik terbaik, keamanan, dan kepatuhan cluster dan fleet Anda.Multi Cluster Ingress
Multi Cluster Ingress menggunakan fleet untuk menentukan kumpulan cluster dan endpoint layanan yang dapat di-load balance oleh traffic, sehingga memungkinkan layanan dengan latensi rendah dan ketersediaan tinggi.Penayangan Knative
Penayangan Knative adalah platform developer Knative yang dikelola dan didukung Google yang memisahkan kompleksitas infrastruktur yang mendasarinya, sehingga memudahkan pembuatan, deployment, dan pengelolaan aplikasi dan layanan di seluruh cluster dalam armada Anda.
Apa langkah selanjutnya?
- Baca selengkapnya tentang kapan harus menggunakan beberapa cluster untuk memenuhi kebutuhan teknis dan bisnis Anda di Kasus penggunaan multi-cluster.
- Siap memikirkan penerapan konsep ini ke sistem Anda sendiri? Lihat Merencanakan resource armada.