Contoh fleet

Contoh di halaman ini menunjukkan beberapa skenario hipotesis menggunakan fleet yang menggambarkan beberapa konsep dan praktik terbaik dari panduan kami. Sebelum membaca panduan ini, Anda harus sudah memahami konsep dalam Memperkenalkan fleet dan Persyaratan perangkat dan praktik terbaik.

Contoh 1: Armada dengan resource produksi, staging, dan pengembangan

Pada contoh pertama, ada empat klaster. Dua cluster adalah untuk produksi (di dua region untuk redundansi), satu untuk staging dan pengujian, dan yang terakhir untuk pengembangan. Semua cluster dimiliki dan dikelola secara terpusat oleh tim platform. Dalam contoh sederhana ini, ada dua layanan: frontend dan backend. Namun, skenario yang lebih kompleks mungkin memiliki jumlah layanan dan cluster yang lebih besar.

Diagram yang mengilustrasikan sistem dengan resource produksi, staging, dan pengembangan
Sistem dengan resource produksi, staging, dan pengembangan

Pendekatan 1: Armada terpisah untuk produksi, staging, dan pengembangan

Salah satu pendekatan yang dapat dilakukan untuk memanfaatkan fleet adalah dengan membuat fleet terpisah untuk resource produksi, staging, dan pengembangan.

Untuk melakukannya, kita membuat tiga project host fleet yang terpisah, dan salah satu dari resource tempat dalam project tersebut. Atau, untuk cluster pengembangan lokal, daftarkan cluster ke project example-dev. Kami tidak perlu mengatasi banyak masalah kesamaan namespace dan kesamaan layanan karena perincian dalam contoh ini, tetapi kami memastikan bahwa namespace cluster prod-east dan prod-west dinormalisasi dengan baik.

Keuntungan dari pendekatan ini adalah bahwa kami memiliki isolasi yang sangat kuat antara setiap fleet. Kelemahan utama dari pendekatan ini adalah kami perlu mengelola tiga fleet yang berbeda, sehingga mempersulit pencapaian konsistensi antara produksi, staging, dan pengembangan. Untuk tim pengembangan, juga lebih sulit untuk mengembangkannya dengan layanan bertahap.

Diagram yang menggambarkan fleet terpisah untuk resource produksi, staging, dan pengembangan
Farmasi terpisah untuk resource produksi, staging, dan pengembangan

Pendekatan 2: Satu fleet untuk semua resource

Dalam pendekatan ini, kita membuat satu fleet untuk semua resource.

Untuk melakukannya, kita dapat membiarkan resource dalam project example, dan membuat fleet dalam project tersebut. Kita dapat memisahkan resource produksi dan staging dengan menempatkannya di project host fleet lain dan memanfaatkan VPC Bersama, tetapi kami memilih tidak melakukannya demi kemudahan dalam contoh ini.

Dengan pendekatan ini, kami perlu memastikan bahwa namespace dan layanan kami dinormalisasi di seluruh fleet. Misalnya, kami mengganti nama frontend generik menjadi frontend-prod dan frontend-staging masing-masing di cluster produksi dan staging. Terakhir, meskipun kami dapat mempertahankan nama asli untuk namespace pengembangan, kami memberikan nama yang lebih jelas (seperti frontend-dev-alice) untuk menunjukkan bahwa nama tersebut adalah namespace pengembangan.

Dengan pendekatan ini, kami mengorbankan isolasi untuk kemudahan pengelolaan. Kami mengandalkan otorisasi mesh layanan untuk mencegah komunikasi antarlayanan yang tidak diinginkan, tetapi kami dapat dengan mudah mengelola keseluruhan sistem dengan satu armada. Pengaturan ini memungkinkan kami menerapkan kebijakan di semua resource, yang dapat memberi kami keyakinan bahwa pengembangan terlihat dan terasa sangat mirip dengan produksi.

Diagram yang menggambarkan satu fleet dengan resource produksi, staging, dan pengembangan
Satu fleet dengan resource produksi, staging, dan pengembangan

Pendekatan 3: Perangkat terpisah untuk produksi dan non-produksi

Dalam pendekatan ini, kami mengambil jalan tengah yang menggabungkan resource staging dan pengembangan menjadi fleet non-produksi sekaligus menempatkan produksi di fleet yang terpisah.

Untuk melakukannya, kami membuat dua project host fleet, yaitu satu untuk produksi dan satu untuk non-produksi. Kami juga menempatkan resource langsung ke dalam project tersebut, dengan cluster dev secara lokal yang terdaftar ke fleet non-produksi kami. Kita perlu menormalisasi namespace dan layanan antara resource staging dan pengembangan untuk memberikan kejelasan; misalnya, kita mengganti nama frontend menjadi frontend-staging di cluster staging.

Keuntungannya di sini adalah produksi terpisah dengan baik dari non-produksi. Misalnya, kita dapat mengaktifkan layanan pengembangan untuk berkomunikasi dengan layanan staging, sehingga frontend developer Alice dapat berkomunikasi dengan backend bertahap selagi dia mengembangkan layanannya.

Diagram yang menggambarkan fleet produksi dan non-produksi
Perangkat produksi dan non-produksi

Ringkasan

Masing-masing pendekatan yang diuraikan dalam Contoh 1 adalah valid. Mana yang dipilih organisasi Anda bergantung pada isolasi versus konsistensi (dan kemudahan pengelolaan); dengan kata lain, seberapa banyak isolasi yang diperlukan antara jenis resource yang berbeda dibandingkan seberapa banyak konsistensi yang diperlukan di seluruh resource. Konsistensi lebih mudah dicapai dengan armada yang lebih sedikit. Pendekatan ketiga ditawarkan sebagai kemungkinan penyusupan, sehingga produksi tetap terisolasi sepenuhnya sekaligus memberi developer kemampuan untuk bekerja terhadap layanan bertahap.

Contoh 2: Armada dengan pemilik resource yang berbeda

Untuk contoh ini, kita memiliki dua tim, tim-a dan tim-b. Tim ini memiliki dan mengelola cluster mereka sendiri, dan keduanya telah menggunakan namespace frontend dan backend untuk layanan yang mereka hasilkan. Namun, baik frontend maupun backend tim-a sebenarnya tidak sama dengan tim-b. Kedua tim ini ingin membuat mesh layanan agar layanan mereka dapat berinteraksi.

Diagram yang mengilustrasikan sistem dengan sumber daya dua tim
Sistem dengan resource dua tim

Tanpa intervensi, tidak ada cara untuk membuat cluster ini menjadi bagian dari mesh yang sama. Salah satu titik awal yang baik adalah mentransfer kepemilikan cluster ke tim platform terpusat untuk membangun kepercayaan di antara mereka. Atau, jika tim-a dan tim-b saling percaya, mereka juga dapat berkoordinasi untuk membentuk kepercayaan ini. Langkah berikutnya adalah menormalisasi penggunaan namespace sehingga frontend dan backend tidak lagi kelebihan beban di cluster kedua tim ini. Setelah ini selesai, mereka dapat membuat satu fleet di seluruh resource dan membuat mesh layanannya.

Diagram yang mengilustrasikan resource dua tim dalam satu armada
Resource dua tim dalam satu fleet

Jika tingkat kepercayaan ini tidak dapat dibangun, tim-a dan tim-b harus membentuk dua fleet terpisah yang menggunakan dua project host fleet yang berbeda. Kelemahan pendekatan ini adalah bahwa sekarang metode ini perlu memanfaatkan federasi mesh yang lebih sulit dikelola daripada mesh tunggal. Manfaatnya adalah tidak ada tim yang perlu menormalisasi namespace dan layanan yang di-deploy, dan hanya komunikasi eksplisit dan resmi yang dapat dilakukan.

Diagram yang mengilustrasikan resource dua tim dalam armada terpisah
Resource dua tim dalam fleet terpisah