Halaman ini memberikan pembahasan yang lebih mendalam tentang cara fleet membantu Anda mengelola deployment multi-cluster, termasuk beberapa terminologi dan konsep fleet utama. Fleet adalah Google Cloud konsep untuk mengatur cluster dan resource lainnya secara logis, sehingga memungkinkan Anda menggunakan dan mengelola kemampuan multi-cluster serta menerapkan kebijakan yang konsisten di seluruh sistem Anda. Fleet membentuk bagian penting dari cara fungsi multi-cluster bekerja di Google Cloud.
Panduan ini ditujukan 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, atau di infrastruktur lokal.
Sebelum membaca halaman ini, pastikan Anda memahami konsep dasar Kubernetes seperti cluster dan namespace. Jika belum, lihat Dasar-dasar Kubernetes, dokumentasi GKE, dan Menyiapkan aplikasi untuk Cloud Service Mesh.
Terminologi
Berikut adalah beberapa istilah penting yang kami gunakan saat membahas fleet.
Resource yang mendukung fleet
Resource yang mendukung fleet adalah Google Cloud resource project yang dapat dikelompokkan dan dikelola secara logis sebagai fleet. Saat ini, hanya cluster Kubernetes yang dapat menjadi anggota fleet.
Project host fleet
Implementasi fleet, seperti banyakresource lainnya, berakar padaproject, yang kami sebut sebagai project host fleet. Google Cloud Google Cloud Project tertentu hanya dapat memiliki satu fleet (atau tidak ada fleet) yang terkait dengannya. Google Cloud Pembatasan ini memperkuat penggunaan Google Cloud project 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 dari resource yang mendukung fleet dan terkait yang harus dijadikan bagian dari fleet. Keputusan tentang apa yang akan dikelompokkan memerlukan jawaban atas pertanyaan berikut:
- Apakah resource tersebut saling terkait?
- Resource yang memiliki komunikasi lintas layanan dalam jumlah besar akan mendapatkan manfaat terbesar dari pengelolaan bersama dalam fleet.
- Resource di lingkungan deployment yang sama (misalnya, lingkungan produksi Anda) harus dikelola bersama dalam fleet.
- Siapa yang mengelola resource?
- Memiliki kontrol terpadu (atau setidaknya saling tepercaya) atas resource sangat penting untuk memastikan integritas fleet.
Untuk mengilustrasikan poin 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 antar-LOB), dan bahkan mungkin memiliki kumpulan administrator yang berbeda untuk setiap LOB. Dalam hal ini, sebaiknya Anda memiliki fleet per LOB. Setiap LOB juga kemungkinan akan mengadopsi beberapa fleet untuk memisahkan layanan produksi dan non-produksi.
Saat konsep fleet lainnya dijelajahi di bagian berikut, Anda mungkin menemukan alasan lain untuk membuat beberapa fleet saat mempertimbangkan kebutuhan organisasi Anda yang spesifik.
Kesamaan
Konsep penting dalam fleet adalah konsep kesamaan. Artinya, saat Anda menggunakan fitur tertentu yang mendukung fleet, beberapa objek Kubernetes seperti namespace yang memiliki nama yang sama di cluster yang berbeda akan diperlakukan seolah-olah sama. Normalisasi ini dilakukan untuk memudahkan pengelolaan resource fleet. Jika Anda menggunakan fitur yang memanfaatkan kesamaan, asumsi kesamaan ini memberikan panduan yang kuat tentang cara menyiapkan namespace, layanan, dan identitas. Namun, hal ini juga mengikuti apa yang kami temukan bahwa sebagian besar organisasi sudah menerapkannya sendiri.
Berbagai jenis kesamaan memberikan manfaat yang berbeda, seperti 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 fleet yang berbeda bergantung pada 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 mana yang dapat Anda gunakan tanpa harus mempertimbangkan kesamaan di seluruh fleet dan fitur mana 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 memikirkan properti ini adalah bahwa namespace secara logis ditentukan di seluruh fleet, meskipun instance namespace hanya ada di subset resource fleet.
Pertimbangkan contoh namespace backend berikut. Meskipun namespace hanya dibuat instance-nya di Cluster A dan B, namespace tersebut secara implisit dicadangkan di Cluster C (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 menunjukkan 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 menjadi lebih eksplisit; namun, sebaiknya gunakan praktik serupa terkait penamaan. Karena hal ini, penting untuk memastikan bahwa layanan dengan nama yang sama dalam namespace yang sama sebenarnya adalah hal yang sama.
Dalam contoh berikut, traffic internet di-load balance di seluruh layanan dengan nama yang sama di 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 Google Cloud layanan, penyimpanan objek, dan sebagainya. Identitas umum ini memungkinkan pemberian akses ke layanan dalam fleet ke resource eksternal satu kali, bukan per cluster.
Untuk mengilustrasikan poin ini lebih lanjut, pertimbangkan contoh berikut. Cluster A, B, dan C terdaftar dalam identitas umum dalam fleet-nya. Saat layanan di
backend namespace mengakses Google Cloud resource, identitasnya
dipetakan ke akun umum Google Cloud layanan yang disebut back. Akun layanan back dapat diotorisasi pada sejumlah
layanan terkelola, dari Cloud Storage hingga Cloud SQL.Google Cloud Saat resource fleet baru seperti cluster ditambahkan di namespace backend, resource tersebut akan otomatis mewarisi properti kesamaan identitas workload.
Karena kesamaan identitas, penting agar semua resource dalam fleet tepercaya dan dikelola dengan baik. Dengan meninjau kembali contoh sebelumnya, jika Cluster C dimiliki oleh tim yang terpisah dan 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 diotorisasi satu kali untuk layanan eksternal, layanan tersebut juga dapat diotorisasi secara internal.
Dalam contoh berikut, kita menggunakan Cloud Service Mesh
untuk membuat service mesh multi-cluster tempat frontend memiliki akses ke backend.
Dengan Cloud Service Mesh dan fleet, 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 di fleet dapat mengakses backend di fleet. Properti ini tidak hanya membuat otorisasi lebih sederhana, tetapi juga membuat batas resource lebih fleksibel; kini workload dapat dengan mudah dipindahkan dari cluster ke cluster tanpa memengaruhi cara workload diotorisasi. Seperti halnya kesamaan identitas workload, tata kelola atas resource fleet 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 Pengontrol Kebijakan) 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 Workload Identity Federation di seluruh fleet yang selalu mengasumsikan beberapa bentuk kesamaan di seluruh cluster, dan mungkin harus diadopsi dengan hati-hati bergantung pada kebutuhan dan workload yang ada.
Beberapa fitur fleet (seperti Workload Identity Federation fleet) mengharuskan seluruh fleet Anda siap untuk asumsi kesamaan yang digunakan. Fitur lain seperti pengelolaan tim memungkinkan Anda secara bertahap memilih kesamaan di tingkat cakupan namespace atau tim.
Tabel berikut menunjukkan fitur mana yang memerlukan satu atau beberapa konsep kesamaan yang dijelaskan di bagian ini.
| Fitur | Mendukung adopsi 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 Sepenuhnya Memenuhi Syarat | T/A | Tidak | Tidak | Tidak |
| Connect 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 |
| Multi Cluster Services | Ya | Ya | Ya | Ya |
| Workload Identity Federation fleet | Tidak | Ya | Ya | Ya |
| Cloud Service Mesh | Tidak | Ya | Ya | Ya |
Eksklusivitas
Resource yang mendukung fleet hanya dapat menjadi anggota satu fleet dalam satu waktu, batasan yang diterapkan oleh Google Cloud alat dan komponen. Pembatasan ini memastikan bahwa hanya ada satu sumber tepercaya yang mengatur cluster. Tanpa eksklusivitas, bahkan komponen yang paling sederhana pun akan menjadi rumit untuk digunakan, sehingga mengharuskan organisasi Anda untuk mempertimbangkan dan mengonfigurasi cara beberapa komponen dari beberapa fleet akan berinteraksi.
Kepercayaan tinggi
Kesamaan layanan, kesamaan identitas workload, dan kesamaan identitas mesh dibangun berdasarkan prinsip kepercayaan tinggi antara anggota fleet. Kepercayaan ini memungkinkan pengelolaan resource ini ditingkatkan ke fleet, bukan mengelola resource satu per satu (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 (bidang kontrol dan infrastruktur yang mendasarinya), tetangga yang berisik, dan sebagainya. Namun, cluster bukan batas isolasi yang kuat untuk kebijakan dan tata kelola karena administrator anggota mana pun dalam fleet berpotensi memengaruhi operasi layanan di anggota fleet 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 diotorisasi di seluruh batas fleet.
Cakupan tim
Cakupan tim adalah mekanisme untuk membagi lebih lanjut fleet Anda menjadi kelompok cluster, sehingga Anda dapat menentukan resource yang mendukung 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 memungkinkan beberapa tim 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 fleet yang ditentukan secara eksplisit yang terkait dengannya, dengan namespace yang dianggap sama di seluruh cakupan. Hal ini memberi Anda kontrol yang lebih terperinci atas namespace daripada kesamaan namespace default yang hanya disediakan oleh fleet.
Komponen yang mendukung fleet
Semua komponen berikut memanfaatkan konsep fleet seperti kesamaan namespace dan identitas untuk menyediakan cara yang lebih sederhana dalam menggunakan cluster dan layanan Anda. Untuk mengetahui persyaratan atau batasan saat ini terkait penggunaan fleet dengan setiap komponen, lihat persyaratan komponen.
Workload identity pools
Fleet menawarkan workload identity pool umum yang dapat digunakan untuk mengautentikasi dan mengotorisasi workload secara seragam dalam service mesh dan ke layanan eksternal.Cloud Service Mesh
Cloud Service Mesh adalah rangkaian alat yang membantu Anda memantau dan mengelola service mesh yang andal di Google Cloud, di infrastruktur lokal, dan lingkungan lain yang didukung. Anda dapat membentuk service mesh 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 Anda yang disimpan dalam sumber tepercaya pusat, seperti repositori Git, dengan memanfaatkan konsep Kubernetes inti seperti namespace, label, dan anotasi. Dengan Config Sync, konfigurasi ditentukan di seluruh fleet, tetapi diterapkan dan diberlakukan secara lokal di setiap resource anggota.Pengontrol Kebijakan
Pengontrol Kebijakan memungkinkan Anda menerapkan dan memberlakukan kebijakan deklaratif untuk cluster Kubernetes Anda. Kebijakan ini bertindak sebagai penjaga dan dapat membantu dengan praktik terbaik, keamanan, dan manajemen kepatuhan cluster serta fleet Anda.Multi Cluster Ingress
Multi Cluster Ingress menggunakan fleet untuk menentukan kumpulan cluster dan endpoint layanan yang dapat di-load balance traffic-nya, sehingga memungkinkan layanan latensi rendah dan ketersediaan tinggi.
Apa langkah selanjutnya?
- Baca lebih lanjut 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 fleet.