Cara kerja fleet

Halaman ini memberikan pembahasan lebih mendalam tentang cara fleet membantu Anda mengelola deployment multi-cluster, termasuk beberapa terminologi dan konsep fleet yang penting. 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 membentuk bagian penting dari cara kerja fungsi multi-cluster perusahaan di Google Cloud.

Panduan ini didesain 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 harus memahami konsep dasar Kubernetes seperti cluster dan namespace. Jika belum, baca dasar-dasar Kubernetes, dokumentasi GKE, dan Menyiapkan aplikasi untuk Anthos Service Mesh.

Jika Anda ingin mempelajari lebih lanjut platform GKE Enterprise dan komponen yang menggunakan fleet, lihat ringkasan teknis GKE Enterprise kami dan tutorial Menjelajahi GKE Enterprise. Namun, Anda tidak perlu memahami GKE Enterprise untuk mengikuti panduan ini.

Terminologi

Berikut adalah beberapa istilah penting yang kita gunakan saat membahas tentang fleet.

Resource yang peka perangkat

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

Project host fleet

Implementasi fleet, seperti resource Google Cloud lainnya, berakar pada project Google Cloud, yang kami sebut sebagai project host fleet. Project Google Cloud tertentu hanya dapat memiliki fleet tunggal (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-sama.

Mengelompokkan infrastruktur

Konsep penting pertama fleet adalah konsep pengelompokan—yaitu, memilih bagian terkait sumber daya yang peka armada yang harus dijadikan bagian dari armada. Keputusan tentang apa yang harus dikelompokkan bersama memerlukan jawaban atas pertanyaan-pertanyaan berikut:

  • Apakah sumber daya tersebut saling terkait?
    • Resource yang memiliki komunikasi lintas layanan dalam jumlah besar akan paling diuntungkan jika dikelola bersama dalam suatu 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 tepercaya bersama) atas resource sangat penting untuk memastikan integritas fleet.

Untuk menggambarkan poin ini, pikirkan sebuah organisasi yang memiliki banyak 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, masuk akal untuk memiliki fleet per LOB. Setiap LOB mungkin juga mengadopsi beberapa fleet untuk memisahkan layanan produksi dan non-produksi.

Seperti konsep fleet lainnya yang 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, beberapa objek Kubernetes, seperti namespace dengan nama yang sama di cluster berbeda, diperlakukan sebagai hal yang sama. Normalisasi ini dilakukan untuk membuat sumber daya armada menjadi lebih mudah dikelola. Panduan ini berisi beberapa panduan kuat tentang cara menyiapkan namespace, layanan, dan identitas. Namun, model ini juga mengikuti hal yang kami temukan sebagian besar organisasi telah menerapkannya sendiri.

Kesamaan namespace

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

Perhatikan contoh namespace backend berikut. Meskipun instance namespace hanya dibuat di Cluster A dan B, namespace tersebut secara implisit dicadangkan di Cluster C (dengan begitu, layanan di namespace backend juga dapat dijadwalkan ke Cluster C jika perlu). Artinya, namespace dialokasikan untuk seluruh fleet, bukan per cluster. Oleh karena itu, kesamaan namespace memerlukan kepemilikan namespace yang konsisten di seluruh fleet.

Diagram yang mengilustrasikan kesamaan namespace dalam fleet
Kesamaan namespace dalam fleet

Kesamaan layanan

Anthos Service Mesh dan Multi Cluster Ingress menggunakan konsep kesamaan layanan dalam namespace. Seperti halnya 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 Anthos Service Mesh. Dengan Multi Cluster Ingress, resource MultiClusterService (MCS) membuat penggabungan endpoint lebih eksplisit; namun, sebaiknya lakukan praktik serupa terkait penamaan. Oleh karena itu, penting untuk memastikan bahwa layanan dengan nama yang identik dalam namespace yang sama sebenarnya adalah hal yang sama.

Pada contoh berikut, traffic internet melakukan load balancing di seluruh layanan bernama sama dalam namespace frontend yang ada di Cluster B dan C. Demikian pula, dengan menggunakan properti mesh layanan dalam fleet, layanan di namespace frontend dapat menjangkau layanan bernama sama di namespace auth yang ada di Cluster A dan C.

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

Kesamaan identitas saat mengakses resource eksternal

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

Untuk menggambarkan poin ini lebih lanjut, pertimbangkan contoh berikut. Cluster A, B, dan C terdaftar dalam identitas yang sama 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, mulai dari Cloud Storage hingga Cloud SQL. Saat resource fleet baru seperti cluster ditambahkan di namespace backend, resource tersebut secara otomatis mewarisi properti kesamaan identitas workload.

Karena adanya kesamaan identitas, semua resource dalam armada harus dipercaya dan diatur dengan baik. 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 saat mengakses resource di luar fleet
Kesamaan identitas saat mengakses resource di luar fleet

Kesamaan identitas dalam satu fleet

Dalam fleet, kesamaan identitas digunakan mirip dengan kesamaan identitas eksternal yang telah kita bahas sebelumnya. Seperti halnya layanan fleet yang diberi otorisasi satu kali untuk layanan eksternal, layanan tersebut juga dapat diotorisasi secara internal.

Dalam contoh berikut, kita menggunakan Anthos Service Mesh untuk membuat mesh layanan multi-cluster tempat frontend memiliki akses ke backend. Dengan Anthos 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 cukup 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 diotorisasi. Seperti halnya kesamaan identitas workload, tata kelola atas resource fleet sangat penting untuk memastikan integritas komunikasi antarlayanan.

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

Eksklusivitas

Resource yang peka terhadap armada hanya dapat menjadi anggota dari satu fleet pada waktu tertentu, pembatasan yang diterapkan oleh alat dan komponen Google Cloud. Pembatasan ini memastikan bahwa hanya ada satu sumber tepercaya yang mengatur cluster. Tanpa eksklusivitas, komponen yang paling sederhana pun akan menjadi kompleks untuk digunakan, 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 berdasarkan prinsip kepercayaan tinggi di antara anggota fleet. Dengan kepercayaan ini, Anda dapat meningkatkan pengelolaan resource ini ke fleet, bukan mengelola resource demi resource (yaitu, cluster demi 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, hal ini bukanlah batas isolasi yang kuat untuk kebijakan dan tata kelola karena administrator setiap anggota dalam fleet berpotensi memengaruhi operasi layanan di anggota fleet lainnya.

Oleh karena itu, sebaiknya cluster yang tidak dipercaya oleh administrator fleet ditempatkan di fleet-nya sendiri untuk menjaganya tetap terisolasi. Kemudian, jika diperlukan, setiap layanan dapat diberi otorisasi di seluruh batas armada.

Cakupan tim

Cakupan tim adalah mekanisme untuk membagi fleet Anda lebih lanjut ke dalam beberapa grup cluster, sehingga Anda dapat menentukan resource fleet aktif yang ditetapkan ke tim aplikasi tertentu. Bergantung pada kasus penggunaan Anda, setiap cluster anggota fleet dapat dikaitkan dengan tanpa tim, satu tim, atau beberapa tim, sehingga beberapa tim dapat berbagi cluster. Anda juga dapat menggunakan cakupan tim untuk menyusun 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 disediakan oleh fleet saja.

Komponen yang mendukung fleet

Komponen GKE Enterprise dan GKE berikut ini semuanya memanfaatkan konsep armada seperti namespace dan kesamaan identitas untuk memberikan cara yang lebih sederhana untuk bekerja dengan cluster dan layanan Anda. Untuk persyaratan atau batasan saat ini terkait penggunaan fleet dengan setiap komponen, lihat persyaratan komponen.

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

  • Anthos Service Mesh
    Anthos Service Mesh adalah rangkaian 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 utama, seperti repositori Git, memanfaatkan konsep inti Kubernetes 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. Kebijakan ini berfungsi sebagai pagar pembatas dan dapat membantu menangani praktik terbaik, keamanan, dan pengelolaan kepatuhan cluster dan fleet Anda.

  • Multi Cluster Ingress
    Multi Cluster Ingress menggunakan fleet untuk menentukan kumpulan cluster dan endpoint layanan yang dapat digunakan untuk menyeimbangkan beban traffic, sehingga memungkinkan layanan berlatensi rendah dan ketersediaan tinggi.

  • Cloud Run for Anthos
    Cloud Run for Anthos adalah platform developer Knative yang dikelola dan didukung Google yang menghilangkan kompleksitas infrastruktur dasar, sehingga mem-build, men-deploy, serta mengelola aplikasi dan layanan di seluruh cluster di armada Anda menjadi lebih mudah.

Apa langkah selanjutnya?