Cara kerja fleet

Halaman ini memberikan pemahaman 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, sehingga Anda dapat menggunakan dan mengelola kemampuan multi-cluster serta menerapkan kebijakan yang konsisten di seluruh sistem Anda. Armada menjadi 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, atau secara lokal.

Anda seharusnya sudah memahami konsep Kubernetes dasar 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 Jelajahi GKE Enterprise. Namun, Anda tidak harus memahami GKE Enterprise untuk mengikuti panduan ini.

Terminologi

Berikut adalah beberapa istilah penting yang kita gunakan saat berbicara tentang armada.

Resource sadar armada

Resource yang sadar fleet adalah resource project Google Cloud yang secara logis dapat dikelompokkan dan dikelola sebagai fleet. Saat ini, hanya cluster Kubernetes yang dapat menjadi anggota fisik.

Project host fleet

Implementasi fleet, seperti banyak resource Google Cloud lainnya, di-root di 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. Pembatasan ini memperkuat penggunaan project Google Cloud untuk memberikan isolasi yang lebih kuat antara resource yang tidak diatur atau digunakan bersama.

Infrastruktur pengelompokan

Konsep penting pertama mengenai armada adalah konsep pengelompokan—yaitu, memilih bagian mana dari terkait sumber daya yang sadar armada yang harus dijadikan bagian dari armada. Keputusan tentang apa yang akan dikelompokkan harus menjawab pertanyaan berikut:

  • Apakah sumber daya terkait satu sama lain?
    • Resource yang memiliki komunikasi lintas layanan dalam jumlah besar akan paling diuntungkan jika dikelola bersama dalam satu fleet.
    • Resource dalam lingkungan deployment yang sama (misalnya, lingkungan produksi Anda) harus dikelola bersama dalam satu fleet.
  • Siapa yang mengelola sumber daya?
    • Memiliki kontrol terpadu (atau setidaknya saling tepercaya) atas resource sangat penting untuk memastikan integritas fleet.

Untuk menggambarkan hal ini, pertimbangkan organisasi yang memiliki beberapa lini bisnis (LOB). Dalam kasus ini, layanan jarang berkomunikasi di seluruh batas LOB, layanan di LOB yang berbeda dikelola secara berbeda (misalnya, siklus upgrade berbeda antar-LOB), dan layanan tersebut bahkan mungkin memiliki kumpulan administrator yang berbeda untuk setiap LOB. Dalam hal ini, sebaiknya miliki fleet per LOB. Setiap LOB juga kemungkinan mengadopsi beberapa fleet untuk memisahkan layanan produksi dan non-produksi.

Saat konsep fleet lainnya dipelajari di bagian berikut, Anda mungkin menemukan alasan lain untuk membuat beberapa fleet saat mempertimbangkan kebutuhan organisasi tertentu.

Kesamaan

Konsep penting dalam armada adalah konsep kesamaan. Artinya, beberapa objek Kubernetes seperti namespace dengan nama yang sama di cluster yang berbeda diperlakukan sebagai hal yang sama. Normalisasi ini dilakukan untuk membuat pengelolaan resource fleet lebih mudah. Panduan ini memberikan beberapa panduan kuat tentang cara menyiapkan namespace, layanan, dan identitas. Namun, cara ini juga mengikuti apa yang menurut kami telah diimplementasikan oleh sebagian besar organisasi.

Kesamaan namespace

Contoh dasar kesamaan dalam fleet adalah kesamaan namespace. Namespace dengan nama yang sama di cluster yang berbeda dianggap sama oleh banyak komponen. Cara lain untuk membayangkan properti ini adalah bahwa namespace secara logis didefinisikan di seluruh fleet, meskipun pembuatan instance namespace hanya ada dalam subset resource fleet.

Perhatikan contoh namespace backend berikut. Meskipun namespace hanya dibuat di Cluster A dan B, secara implisit dicadangkan di Cluster C (ini memungkinkan layanan dalam namespace backend juga dijadwalkan ke Cluster C jika perlu). Artinya, namespace dialokasikan untuk seluruh fleet, bukan per cluster. Dengan demikian, kesamaan namespace memerlukan kepemilikan namespace yang konsisten di seluruh fleet.

Diagram yang menggambarkan kesamaan namespace dalam suatu fleet
Kesamaan namespace dalam 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, kami merekomendasikan praktik serupa terkait penamaan. Oleh karena itu, sebaiknya pastikan layanan dengan nama yang identik dalam namespace yang sama sebenarnya adalah layanan yang sama.

Pada contoh berikut, traffic internet diseimbangkan oleh beban di seluruh layanan dengan nama yang sama di namespace frontend yang ada di Cluster B dan C. Demikian pula, dengan menggunakan properti mesh layanan dalam fleet, layanan di namespace frontend dapat mencapai layanan dengan nama yang sama di namespace auth yang ada di Cluster A dan C.

Diagram yang menggambarkan kesamaan layanan dalam suatu fleet
Kesamaan layanan dalam fleet

Identitas yang sama saat mengakses resource eksternal

Layanan dalam fleet dapat memanfaatkan identitas umum saat traffic keluar untuk mengakses resource eksternal seperti layanan Google Cloud, penyimpanan objek, dan sebagainya. Identitas umum ini memungkinkan untuk memberikan layanan dalam akses singkat ke resource eksternal satu kali, bukan per cluster.

Untuk lebih menggambarkan poin ini, pertimbangkan contoh berikut. Cluster A, B, dan C terdaftar di identitas umum dalam fleet-nya. Saat layanan di namespace backend mengakses resource Google Cloud, identitasnya dipetakan ke akun layanan Google Cloud umum yang disebut back. Akun layanan Google Cloud back dapat diberi otorisasi pada sejumlah layanan terkelola, dari Cloud Storage hingga Cloud SQL. Saat resource fleet baru seperti cluster ditambahkan di namespace backend, resource fleet baru akan otomatis mewarisi properti kesamaan workload identity.

Karena kesamaan identitas, semua resource dalam fleet harus dipercaya dan diatur dengan baik. Dengan meninjau 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.

Diagram yang menggambarkan kesamaan identitas dalam mengakses resource di luar fleet
Kesamaan identitas dalam mengakses resource di luar fleet

Kesamaan identitas dalam suatu fleet

Dalam fleet, kesamaan identitas digunakan mirip dengan kesamaan identitas eksternal yang telah kita bahas sebelumnya. Sama seperti layanan fleet diberi otorisasi sekali untuk layanan eksternal, layanan ini juga dapat diotorisasi secara internal.

Dalam contoh berikut, kami 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 dalam fleet dapat mengakses backend di fleet. Properti ini tidak hanya menyederhanakan otorisasi, tetapi juga membuat batas resource lebih fleksibel. Kini, beban kerja dapat dengan mudah dipindahkan dari cluster ke cluster tanpa memengaruhi cara pemberian otorisasi. Seperti halnya kesamaan identitas workload, tata kelola atas resource fleet sangat penting untuk memastikan integritas komunikasi layanan-ke-layanan.

Diagram yang menggambarkan kesamaan identitas di dalam fleet
Kesamaan identitas di dalam fleet

Eksklusivitas

Resource yang berbasis perangkat hanya dapat menjadi anggota dari satu fleet pada waktu tertentu, yaitu pembatasan yang diberlakukan oleh alat dan komponen Google Cloud. Pembatasan ini memastikan bahwa hanya ada satu sumber tepercaya yang mengatur cluster. Tanpa eksklusivitas, penggunaan komponen yang paling sederhana pun akan menjadi rumit, sehingga organisasi Anda harus memikirkan dan mengonfigurasi cara interaksi beberapa komponen dari beberapa fleet.

Kepercayaan tinggi

Kesamaan layanan, kesamaan identitas workload, dan kesamaan identitas mesh dibangun di atas prinsip kepercayaan yang tinggi di antara anggota fleet. Kepercayaan ini memungkinkan Anda untuk meningkatkan pengelolaan resource ke fleet, bukan mengelola resource-demi-resource (yaitu, cluster demi cluster untuk resource Kubernetes), dan pada akhirnya membuat batas cluster tidak begitu 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, keduanya bukanlah batasan isolasi yang kuat bagi kebijakan dan tata kelola karena administrator anggota fleet berpotensi memengaruhi operasi layanan di anggota fleet lainnya.

Karena alasan ini, sebaiknya cluster yang tidak dipercaya oleh administrator inventaris ditempatkan di fleet-nya sendiri agar tetap terisolasi. Kemudian, jika perlu, setiap layanan dapat diotorisasi di seluruh batas fleet.

Cakupan tim

Cakupan tim adalah mekanisme untuk membagi lagi fleet Anda lebih lanjut ke dalam beberapa grup cluster, yang memungkinkan Anda menentukan resource menyeluruh yang ditetapkan untuk tim aplikasi tertentu. Bergantung pada kasus penggunaan Anda, cluster anggota fleet individual dapat dikaitkan dengan tidak ada tim, satu tim, atau beberapa tim, sehingga beberapa tim dapat berbagi cluster. Anda juga dapat menggunakan cakupan tim untuk peluncuran upgrade cluster urutan di seluruh fleet, meskipun hal ini mengharuskan setiap cluster hanya dikaitkan dengan satu tim.

Cakupan tim dapat secara eksplisit menentukan namespace fleet yang 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 didukung perangkat lunak

Semua komponen GKE Enterprise dan GKE berikut memanfaatkan konsep singkat seperti namespace dan kesamaan identitas untuk memberikan cara yang lebih sederhana dalam bekerja dengan cluster dan layanan Anda. Untuk mengetahui persyaratan atau batasan saat ini dalam menggunakan fleet dengan setiap komponen, lihat persyaratan komponen.

  • Kumpulan identitas workload
    Fleksibel menawarkan kumpulan identitas workload umum yang dapat digunakan untuk mengautentikasi dan memberi otorisasi workload secara seragam dalam mesh layanan dan ke layanan eksternal.

  • Cloud Service Mesh
    Cloud Service Mesh adalah rangkaian alat yang membantu Anda memantau dan mengelola mesh layanan yang andal di Google Cloud, infrastruktur lokal, dan lingkungan lain yang didukung. Anda dapat membentuk mesh layanan di seluruh cluster yang merupakan bagian dari fleet yang sama.

  • Sinkronisasi Konfigurasi
    Sinkronisasi Konfigurasi memungkinkan Anda men-deploy dan memantau paket konfigurasi deklaratif untuk sistem Anda yang disimpan di sumber tepercaya terpusat, seperti repositori Git, memanfaatkan konsep Kubernetes inti seperti namespace, label, dan anotasi. Dengan Config Sync, konfigurasi ditentukan di seluruh fleet, tetapi diterapkan dan diterapkan secara lokal di setiap resource anggota.

  • Pengontrol Kebijakan
    Pengontrol Kebijakan memungkinkan Anda menerapkan dan menerapkan kebijakan deklaratif untuk cluster Kubernetes Anda. Kebijakan ini berfungsi sebagai pagar pembatas dan dapat membantu menerapkan praktik terbaik, keamanan, serta pengelolaan kepatuhan cluster dan fleet Anda.

  • Multi Cluster Ingress
    Multi Cluster Ingress menggunakan fleet untuk menentukan kumpulan cluster dan endpoint layanan yang dapat diseimbangkan oleh traffic sehingga memungkinkan layanan berlatensi rendah dan ketersediaan tinggi.

  • Penyajian Knative
    Penyaluran Knative adalah platform developer Knative yang dikelola dan didukung Google yang menghilangkan kompleksitas infrastruktur dasar, sehingga memudahkan untuk membangun, men-deploy, dan mengelola aplikasi dan layanan di seluruh cluster dalam armada Anda.

Apa langkah selanjutnya?