Halaman ini memberikan pemahaman lebih mendalam tentang cara fleet membantu Anda mengelola deployment multi-cluster, termasuk beberapa terminologi dan konsep fleet utama. Armada adalah konsep Google Cloud untuk mengatur cluster secara logis dan resource Anda, sehingga Anda dapat menggunakan dan mengelola kemampuan multi-cluster dan kebijakan yang konsisten di seluruh sistem Anda. Armada menjadi bagian penting dari bagaimana fungsi multi-cluster perusahaan di Google Cloud.
Panduan ini dirancang untuk pembaca teknis, termasuk arsitek sistem, operator platform, dan operator layanan, yang ingin memanfaatkan berbagai cluster dan infrastruktur terkait. Konsep ini berguna di mana pun organisasi menjalankan beberapa klaster, baik dalam Google Cloud, di beberapa penyedia cloud, atau secara lokal.
Anda seharusnya sudah memahami konsep dasar Kubernetes seperti cluster dan namespaces; jika tidak, lihat Kubernetes dasar-dasar, Dokumentasi GKE, dan Menyiapkan aplikasi untuk Cloud Service Mesh.
Jika Anda ingin mempelajari lebih lanjut platform GKE Enterprise dan komponen yang menggunakan fleet, lihat GKE Enterprise teknis ringkasan dan Eksplorasi GKE Enterprise. Namun, Anda tidak perlu 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 dikelompokkan dan dikelola sebagai armada. Hanya cluster Kubernetes yang saat ini dapat anggota armada.
Project host fleet
Implementasi fleet, seperti banyak resource Google Cloud lainnya, berakar pada project Google Cloud, yang kami sebut sebagai project host fleet. J mengingat project Google Cloud 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 secara bersamaan.
Infrastruktur pengelompokan
Konsep penting pertama mengenai fleet adalah konsep pengelompokan—yaitu, memilih bagian terkait resource sadar perangkat harus menjadi bagian dari armada. Keputusan tentang apa yang akan dikelompokkan bersama-sama harus menjawab pertanyaan berikut:
- Apakah sumber daya terkait satu sama lain?
- Resource yang memiliki manfaat komunikasi lintas layanan dalam jumlah besar hasil maksimal dari dikelola bersama-sama dalam sebuah armada.
- Resource dalam lingkungan deployment yang sama (misalnya, produksi Anda harus dikelola bersama-sama dalam sebuah armada.
- Siapa yang mengelola sumber daya?
- Memiliki kontrol terpadu (atau setidaknya kepercayaan bersama) atas resource penting untuk memastikan integritas armada itu.
Untuk mengilustrasikan hal ini, pertimbangkan sebuah organisasi yang memiliki banyak bisnis (LOB). Dalam kasus ini, layanan jarang berkomunikasi di LOB batas, layanan di LOB yang berbeda dikelola secara berbeda (misalnya, memiliki siklus {i>upgrade <i}yang berbeda di antara LOB, dan mereka bahkan mungkin memiliki administrator untuk setiap LOB. Dalam hal ini, mungkin masuk akal untuk memiliki armada per LOB. Setiap LOB juga kemungkinan mengadopsi beberapa armada untuk memisahkan produksi dan non-produksi.
Saat konsep armada lainnya dibahas di bagian berikut, Anda mungkin menemukan alasan lain untuk membuat banyak armada saat mempertimbangkan kebutuhan organisasi.
Kesamaan
Konsep penting dalam armada adalah konsep kesamaan. Artinya, saat Anda menggunakan fitur yang diaktifkan oleh fleet tertentu, beberapa objek Kubernetes seperti namespace yang memiliki nama yang sama di cluster yang berbeda akan diperlakukan seolah-olah mereka adalah hal yang sama. Normalisasi ini dilakukan untuk mempermudah pengelolaan resource fleet. Jika Anda menggunakan fitur yang memanfaatkan kesamaan, asumsi kesamaan ini memberikan beberapa panduan kuat tentang cara menyiapkan namespace, layanan, dan identitas. Namun, cara ini juga mengikuti apa yang kami temukan oleh sebagian besar organisasi yang telah mereka terapkan sendiri.
Jenis kesamaan yang berbeda 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 berbagai 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 ini, fitur perangkat yang berbeda bergantung pada jenis kemiripan yang berbeda. Sebagian kecil fitur tidak menggunakan kesamaan sama sekali. Anda dapat mempelajari hal ini lebih lanjut di Fitur mana yang menggunakan kesamaan?, termasuk fitur mana yang dapat Anda gunakan tanpa harus mempertimbangkan kesamaan di seluruh perangkat 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 membayangkan properti ini adalah bahwa ruang nama secara logis didefinisikan di seluruh armada, bahkan jika pembuatan instance hanya ada di subset resource fleet.
Perhatikan contoh namespace backend berikut. Meskipun namespace
Hanya dibuat instance-nya di Cluster A dan B, secara implisit dicadangkan di Cluster C
(memungkinkan layanan dalam namespace backend juga dijadwalkan ke Cluster C jika perlu).
Ini berarti bahwa namespace dialokasikan untuk seluruh fleet dan bukan per
. Oleh karena itu, kesamaan namespace memerlukan kepemilikan namespace yang konsisten
di seluruh armada.
Kesamaan layanan
Cloud Service Mesh dan Multi Cluster Ingress menggunakan konsep kesamaan layanan dalam sebuah 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 dengan berkenaan dengan penamaan. Oleh karena itu, penting untuk memastikan bahwa identik layanan bernama di dalam namespace yang sama sebenarnya adalah hal yang sama.
Pada contoh berikut, beban traffic internet diseimbangkan di satu server dengan nama yang sama
di namespace frontend yang ada di Cluster B dan C. Demikian pula,
menggunakan properti mesh layanan dalam fleet, layanan dalam namespace frontend dapat
menjangkau layanan dengan nama yang sama di namespace auth yang ada di Cluster A dan C.
Identitas yang sama saat mengakses resource eksternal
Dengan fleet Workload Identity Federation, layanan dalam suatu fleet dapat memanfaatkan identitas umum saat layanan keluar ke mengakses resource eksternal seperti layanan Google Cloud, penyimpanan objek, dan seterusnya. Identitas umum ini memungkinkan memberikan layanan dalam akses fleet ke resource eksternal sekali, bukan ke cluster per cluster.
Untuk lebih menggambarkan poin ini, pertimbangkan contoh berikut. Gugus A, B,
dan C terdaftar di identitas
yang sama dalam armada mereka. Kapan layanan di
backend mengakses resource Google Cloud, identitas mereka
dipetakan ke akun layanan Google Cloud umum yang disebut back. Tujuan
Akun layanan Google Cloud back dapat diberi otorisasi pada sejumlah
dan layanan terkelola, mulai dari Cloud Storage hingga Cloud SQL. Karena sumber daya armada baru
seperti cluster yang ditambahkan dalam namespace backend, cluster tersebut secara otomatis
mewarisi properti
kesamaan workload identity.
Karena identitas yang sama, semua sumber daya dalam sebuah armada
dipercaya dan diatur dengan baik. Meninjau kembali contoh sebelumnya, jika Cluster C
milik tim terpisah yang tidak tepercaya, mereka juga dapat membuat namespace backend
dan mengakses layanan terkelola seolah-olah layanan tersebut adalah backend di Cluster A
atau B.
Kesamaan identitas dalam suatu fleet
Dalam fleet, kesamaan identitas digunakan mirip dengan identitas eksternal kesamaan yang telah kita bahas sebelumnya. Sama seperti layanan armada yang diotorisasi satu kali untuk layanan eksternal, mereka dapat diotorisasi secara internal juga.
Pada 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 dalam cluster B dan C dapat
mengakses backend di Cluster A dan B. Sebagai gantinya, kita cukup menentukan bahwa frontend
di fleet dapat mengakses backend di fleet. Properti ini tidak hanya membuat
otorisasi lebih sederhana, hal itu juga membuat batas sumber daya lebih fleksibel; sekarang
workload dapat dengan mudah dipindahkan dari satu cluster ke cluster lain tanpa memengaruhi cara kerjanya
diotorisasi. Seperti pada kesamaan workload identity, tata kelola pada fleet
resource Anda sangat penting untuk memastikan
integritas layanan-ke-layanan
komunikasi antarlayanan.
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 segala bentuk kesamaan di seluruh armada Anda. Fitur lainnya (termasuk Sinkronisasi Konfigurasi 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, terdapat fitur seperti Multi Cluster Ingress dan Workload Identity Federation 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 fleet Workload Identity Federation) mengharuskan seluruh fleet Anda siap untuk asumsi kesamaan yang digunakan. Fitur lain seperti pengelolaan tim memungkinkan Anda secara bertahap memilih untuk mendapatkan kesamaan di level namespace atau cakupan 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 antarnode | T/A | Tidak | Tidak | Tidak |
| Kebijakan Jaringan Berbasis Nama Domain yang Memenuhi Syarat Sepenuhnya | T/A | Tidak | Tidak | Tidak |
| Hubungkan 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 |
| Insight Kerentanan Lanjutan | 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 |
| Federasi Identitas Workload Fleet | Tidak | Ya | Ya | Ya |
| Mesh Layanan Cloud | Tidak | Ya | Ya | Ya |
Eksklusivitas
Resource yang peka perangkat hanya dapat menjadi anggota dari satu perangkat di waktu, pembatasan yang diterapkan oleh alat dan komponen. Batasan ini memastikan bahwa hanya ada satu sumber tepercaya yang mengatur cluster. Tanpa eksklusivitas, komponen yang paling sederhana pun akan kompleks untuk digunakan, mengharuskan organisasi Anda untuk memikirkan dan mengkonfigurasi bagaimana banyak komponen dari beberapa armada akan berinteraksi.
Kepercayaan tinggi
Kesamaan layanan, kesamaan identitas workload, dan kesamaan identitas mesh dibangun di atas prinsip kepercayaan yang tinggi antara anggota armada. Ini kepercayaan memungkinkan untuk meningkatkan manajemen sumber daya ini ke armada, alih-alih mengelola resource-by-resource (yaitu, cluster-demi-cluster untuk resource Kubernetes), dan pada akhirnya membuat batas cluster menjadi kurang penting.
Dengan kata lain, dalam sebuah fleet, klaster memberikan perlindungan dari ledakan masalah radius, ketersediaan (baik bidang kontrol maupun bidang infrastruktur), tetangga yang berisiko, dan sebagainya. Namun, ide-ide tersebut tidaklah kuat batasan terpisah untuk kebijakan dan tata kelola karena administrator dari anggota dalam sebuah armada dapat berpotensi mempengaruhi operasi layanan di semua anggota armada.
Karena alasan ini, sebaiknya cluster yang tidak dipercaya oleh fleet administrator ditempatkan di armada mereka sendiri untuk menjaga mereka tetap terisolasi. Kemudian, ketika diperlukan, setiap layanan dapat diotorisasi ke seluruh batas armada.
Cakupan tim
Ruang lingkup tim adalah mekanisme untuk membagi lebih lanjut armada Anda menjadi beberapa kelompok cluster, sehingga Anda dapat menentukan resource ditugaskan ke tim aplikasi tertentu. Bergantung pada kasus penggunaan Anda, cluster anggota fleet individu dapat dikaitkan tanpa tim, satu tim, atau beberapa tim, sehingga beberapa tim dapat berbagi cluster. Anda juga dapat menggunakan cakupan tim untuk urutan peluncuran upgrade cluster di seluruh armada, meskipun ini mengharuskan setiap klaster 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
Komponen GKE Enterprise dan GKE berikut semuanya memanfaatkan seperti namespace dan identitas identitas guna memberikan layanan yang untuk bekerja dengan cluster dan layanan Anda. Untuk persyaratan saat ini atau batasan untuk menggunakan armada dengan setiap komponen, lihat komponen persyaratan.
Kumpulan identitas beban kerja
Armada menawarkan kumpulan identitas beban kerja umum yang dapat digunakan untuk mengautentikasi dan memberi otorisasi beban kerja secara seragam dalam mesh layanan dan layanan eksternal.Mesh Layanan Cloud
Cloud Service Mesh adalah rangkaian alat yang membantu Anda memantau dan mengelola mesh layanan di Google Cloud, infrastruktur lokal, dan lingkungan yang didukung lainnya. Anda dapat membentuk mesh layanan di seluruh cluster yang merupakan bagian dari armada yang sama.Sinkronisasi Konfigurasi
Config Sync memungkinkan Anda men-deploy dan memantau deklaratif paket konfigurasi untuk sistem Anda yang disimpan di sumber kebenaran pusat, seperti repositori Git, memanfaatkan konsep Kubernetes inti seperti namespace, label, dan anotasi. Dengan Config Sync, konfigurasi ditentukan di seluruh perangkat, tetapi diterapkan dan diberlakukan secara lokal di setiap sumber daya anggota.Pengontrol Kebijakan
Pengontrol Kebijakan memungkinkan Anda menerapkan dan memberlakukan kebijakan deklaratif untuk ke cluster Kubernetes Anda. Kebijakan ini bertindak sebagai pengaman dan dapat membantu praktik terbaik, keamanan, dan pengelolaan kepatuhan cluster dan fleet Anda.Ingress Multi Cluster
Multi Cluster Ingress menggunakan fleet untuk menentukan kumpulan cluster dan layanan endpoint di mana traffic dapat diseimbangkan oleh beban, sehingga memungkinkan latensi rendah dan ketersediaan tinggi dan layanan yang tinggi.Penayangan Knative
Penyajian Knative adalah developer Knative yang dikelola dan didukung Google yang menghilangkan kompleksitas infrastruktur dasar, sehingga memungkinkan proses membangun, men-deploy, serta mengelola aplikasi dan layanan di seluruh cluster dalam armada Anda.
Apa langkah selanjutnya?
- Baca selengkapnya tentang kapan harus menggunakan beberapa cluster untuk memenuhi kebutuhan teknis dan bisnis Anda dalam Kasus penggunaan multi-cluster.
- Siap memikirkan untuk menerapkan konsep ini ke sistem Anda sendiri? Lihat Merencanakan resource fleet.