Halaman ini memberikan penjelasan mendalam tentang cara armada membantu Anda mengelola deployment multi-cluster, termasuk beberapa terminologi dan konsep utama armada. Fleet adalah Google Cloud konsep 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 di Google Cloud.
Panduan ini dirancang untuk pembaca yang memiliki latar belakang 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 secara lokal.
Sebelum membaca halaman ini, pastikan Anda sudah 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 armada.
Resource yang kompatibel dengan fleet
Resource yang kompatibel dengan 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
Penerapan fleet, seperti banyak resource lainnya, berakar pada project, yang kami sebut sebagai project host fleet. Google Cloud Google Cloud Project Google Cloud tertentu hanya dapat memiliki satu fleet (atau tidak ada fleet) yang terkait dengannya. 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 armada adalah konsep pengelompokan—yaitu, memilih bagian terkait dari resource yang kompatibel dengan armada yang harus menjadi bagian dari armada. Keputusan tentang apa yang harus 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 armada.
- Resource di lingkungan deployment yang sama (misalnya, lingkungan produksi Anda) harus dikelola bersama dalam armada.
- Siapa yang mengelola resource?
- Memiliki kontrol terpadu (atau setidaknya saling dipercaya) atas resource sangat penting untuk memastikan integritas inventaris.
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 di antara LOB), dan bahkan mungkin memiliki serangkaian administrator yang berbeda untuk setiap LOB. Dalam hal ini, sebaiknya miliki armada per LOB. Setiap LOB juga cenderung mengadopsi beberapa fleet untuk memisahkan layanan produksi dan non-produksinya.
Saat konsep armada lainnya dijelaskan di bagian berikut, Anda mungkin menemukan alasan lain untuk membuat beberapa armada saat mempertimbangkan kebutuhan organisasi tertentu.
Kesamaan
Konsep penting dalam armada adalah konsep kesamaan. Artinya, saat Anda menggunakan fitur yang kompatibel dengan armada tertentu, 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 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 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 dalam namespace yang sama menggunakan pemilih label yang sama. |
|
| Kombinasi namespace dan akun layanan (identitas) dianggap sama di beberapa cluster. |
|
Seperti yang ditunjukkan di atas, berbagai fitur armada mengandalkan berbagai jenis kesamaan. 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 mendasar 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 didefinisikan secara logis di seluruh fleet, meskipun instansiasi namespace hanya ada di sebagian kecil resource fleet.
Perhatikan contoh namespace backend berikut. Meskipun namespace hanya di-instantiate 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. Oleh karena itu, 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 menjadi lebih eksplisit; namun, sebaiknya gunakan praktik serupa terkait penamaan. Oleh karena itu, 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 bernama 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 bernama sama di namespace auth yang ada di Cluster A dan C.
Kesamaan identitas saat mengakses resource eksternal
Dengan Fleet Workload Identity Federation, layanan dalam fleet dapat memanfaatkan identitas umum saat keluar untuk mengakses resource eksternal seperti layanan, penyimpanan objek, dan sebagainya. Google Cloud Identitas umum ini memungkinkan pemberian akses ke layanan dalam fleet ke resource eksternal hanya sekali, bukan per cluster.
Untuk lebih menggambarkan hal ini, perhatikan contoh berikut. Cluster A, B, dan C terdaftar dalam identitas umum di dalam fleetnya. 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 workload.
Karena kesamaan identitas, semua resource dalam armada harus tepercaya dan dikelola dengan baik. Kembali ke contoh sebelumnya, jika Cluster C dimiliki oleh tim lain 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 armada
Dalam armada, kesamaan identitas digunakan dengan cara yang sama seperti kesamaan identitas eksternal yang telah kita bahas sebelumnya. Sama seperti layanan fleet yang diizinkan satu kali untuk layanan eksternal, layanan tersebut juga dapat diizinkan 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 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 menyederhanakan otorisasi, tetapi juga membuat batas resource lebih fleksibel; kini workload dapat dipindahkan dengan mudah dari cluster ke cluster tanpa memengaruhi cara otorisasi. Seperti halnya kesamaan workload identity, tata kelola atas resource fleet
sangat penting untuk memastikan integritas komunikasi antar-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 mewajibkannya untuk semua kasus penggunaan. Terakhir, ada fitur seperti Multi Cluster Ingress dan Federasi Workload Identity di seluruh fleet yang selalu mengasumsikan beberapa bentuk kesamaan di seluruh cluster, dan mungkin harus diterapkan dengan hati-hati, bergantung pada kebutuhan dan beban kerja yang ada.
Beberapa fitur armada (seperti Workload Identity Federation armada) mengharuskan seluruh armada Anda siap untuk asumsi kesamaan yang mereka gunakan. Fitur lain seperti pengelolaan tim memungkinkan Anda secara bertahap memilih untuk menggunakan kesamaan di tingkat namespace atau cakupan tim.
Tabel berikut menunjukkan fitur mana yang memerlukan 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 Sepenuhnya Memenuhi Syarat | 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 |
| Fleet Workload Identity Federation | Tidak | Ya | Ya | Ya |
| Cloud Service Mesh | Tidak | Ya | Ya | Ya |
Eksklusivitas
Resource yang kompatibel dengan fleet hanya dapat menjadi anggota satu fleet dalam satu waktu, batasan yang diterapkan oleh alat dan komponen Google Cloud . 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 organisasi Anda harus mempertimbangkan dan mengonfigurasi cara berinteraksi beberapa komponen dari beberapa armada.
Kepercayaan tinggi
Kesamaan layanan, kesamaan identitas workload, dan kesamaan identitas mesh dibangun berdasarkan prinsip kepercayaan tinggi antara anggota armada. Kepercayaan ini memungkinkan peningkatan pengelolaan resource ini ke fleet, daripada 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 armada, cluster memberikan perlindungan dari masalah radius ledakan, ketersediaan (bidang kontrol dan infrastruktur yang mendasarinya), tetangga yang mengganggu, dan sebagainya. Namun, batas isolasi ini tidak kuat untuk kebijakan dan tata kelola karena administrator anggota mana pun dalam armada berpotensi memengaruhi operasi layanan di anggota armada lainnya.
Oleh karena itu, sebaiknya cluster yang tidak dipercaya oleh administrator fleet ditempatkan di fleetnya 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 kompatibel dengan fleet yang ditetapkan ke tim aplikasi tertentu. Bergantung pada kasus penggunaan Anda, cluster anggota fleet individual dapat dikaitkan dengan nol 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 Anda, meskipun hal ini mengharuskan setiap cluster hanya dikaitkan dengan satu tim.
Cakupan tim dapat memiliki namespace armada yang ditentukan secara eksplisit dan terkait dengannya, dengan namespace dianggap sama di seluruh cakupan. Hal ini memberi Anda kontrol yang lebih terperinci atas namespace daripada kesamaan namespace default yang disediakan oleh fleet saja.
Komponen yang kompatibel dengan armada
Semua komponen berikut memanfaatkan konsep armada seperti kesamaan namespace dan identitas untuk menyediakan cara yang lebih sederhana dalam berinteraksi dengan 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 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, infrastruktur 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 Anda yang disimpan dalam sumber tepercaya terpusat, seperti repositori Git, dengan memanfaatkan konsep inti Kubernetes 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 menegakkan 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 dalam Kasus penggunaan multi-cluster.
- Siap memikirkan penerapan konsep ini pada sistem Anda sendiri? Lihat Merencanakan resource armada.