Panduan ini memberikan praktik terbaik, pertimbangan praktis, dan rekomendasi untuk mengimplementasikan perangkat di organisasi Anda.
Sebelum membaca panduan ini, Anda harus memahami konsep dalam Cara kerja fleet. Sebaiknya baca panduan ini sebelum melihat contoh kami.
Persyaratan komponen
Ada beberapa batasan yang perlu dipertimbangkan saat mengimplementasikan fleet berdasarkan komponen GKE Enterprise dan Google Cloud yang mendukung fleet yang ingin digunakan organisasi Anda. Misalnya, beberapa komponen mungkin belum mendukung penggunaan cluster yang tidak ada dalam project host fleet.
Tabel berikut menunjukkan persyaratan dan batasan setiap komponen saat ini. Tabel ini juga mencantumkan fitur yang disertakan dengan GKE Enterprise, tetapi tidak dikonfigurasi menggunakan Fleet API.
| Komponen |
Jenis cluster |
Persyaratan project |
Persyaratan VPC |
|---|---|---|---|
| Config Sync | Semua cluster yang didukung GKE Enterprise | Tidak ada | Tidak ada |
| Pengontrol Kebijakan | Semua cluster yang didukung GKE Enterprise | Tidak ada | Tidak ada |
| Mesh Layanan Cloud | Lihat Platform yang didukung | Cluster harus terdaftar ke fleet, dan semua cluster yang ada dalam project yang sama harus didaftarkan ke fleet yang sama. Untuk mengetahui informasi selengkapnya, lihat Persyaratan fleet Cloud Service Mesh. | Cluster GKE harus berada di jaringan VPC yang sama. |
| Multi Cluster Ingress dan Gateway multi-cluster | Cluster GKE di Google Cloud | Resource Ingress/Gateway, cluster GKE, dan fleet harus menggunakan project yang sama. | Resource Ingress/Gateway dan cluster GKE harus berada dalam jaringan VPC yang sama. |
| Workload Identity pools | Dioptimalkan untuk GKE Enterprise, GKE di Google Cloud, dan Google Distributed Cloud di VMware. Dengan GKE Enterprise, cluster Kubernetes lainnya didukung, tetapi memerlukan penyiapan manual. | Tidak ada | Tidak ada |
| Otorisasi Biner | Cluster GKE di Google Cloud, Google Distributed Cloud on VMware, Google Distributed Cloud on bare metal | Tidak ada | Tidak ada |
| Insight Kerentanan Lanjutan | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Postur Keamanan GKE | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Postur Keamanan GKE | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Postur Kepatuhan | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Metrik pemanfaatan resource fleet | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Pencatatan armada | Semua | Tidak ada | Tidak ada |
| hubungkan gateway | Semua | Tidak ada | Tidak ada |
| Pengelolaan tim armada | Semua | Tidak ada | Tidak ada |
| Kebijakan Jaringan FQDN Pod | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Enkripsi transparan antarnode | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
| Pengontrol Konfigurasi | Tidak berlaku | Tidak ada | Tidak ada |
| Pengurutan Peluncuran | Cluster GKE di Google Cloud | Tidak ada | Tidak ada |
Mengatur project dan jaringan VPC untuk fleet
Saat merancang untuk fleet, Anda perlu mempertimbangkan dua resource dasar: project Google Cloud dan jaringan Virtual Private Cloud (VPC).
Seperti yang tercantum dalam Cara kerja fleet, setiap fleet dibuat dalam satu project. Namun (dengan batasan yang tercantum dalam tabel sebelumnya), fleet dimaksudkan untuk bekerja dengan resource yang sadar perangkat dari project host fleet, project Google Cloud lain, penyedia cloud lain, atau infrastruktur lokal.
Meskipun tidak dicegah secara eksplisit dalam sebagian besar kasus, kami juga merekomendasikan agar resource yang peka perangkat dalam project yang sama ditambahkan ke fleet yang sama; resource tersebut tidak boleh dibagi di antara fleet yang berbeda. Memisahkan resource dalam project yang sama di seluruh perangkat dianggap sebagai anti-pola karena batas project memberikan perlindungan yang lebih kuat untuk tujuan kebijakan dan tata kelola.
Saat menentukan cara menempatkan resource yang sadar fleet dalam beberapa project, kami memperkirakan bahwa banyak organisasi akan memiliki persyaratan tenancy yang berbeda. Pertimbangkan dua ekstrem berikut:
- Beberapa organisasi mungkin memilih untuk menempatkan semua resource fleet di beberapa project yang dikontrol secara terpusat, dengan mengalokasikan namespace ke tim.
- Organisasi lain dapat memilih untuk memberikan cluster khusus kepada tim dalam project milik timnya.
Pada ekstrem pertama, lebih mudah untuk mempertahankan tata kelola terpusat atas resource, tetapi mungkin memerlukan upaya tambahan untuk mencapai isolasi yang diinginkan. Pada ekstrem kedua, kompromi ini dibalik. Dalam beberapa kasus yang kompleks, organisasi Anda mungkin memiliki campuran resource infrastruktur bersama dan resource khusus, yang diisolasi dalam project terpisah. Tidak peduli di mana pun Anda berakhir, seperti yang kita bahas di bagian Kepercayaan tinggi kami, menjaga kepercayaan bersama atas resource yang didaftarkan ke fleet adalah penting untuk menjaga integritas fleet.
Terkait erat dengan organisasi proyek adalah organisasi jaringan. Beberapa komponen perangkat, seperti yang disebutkan dalam tabel persyaratan komponen, memerlukan konektivitas spesifik antara resource terdaftar dalam fleet. Seiring waktu, beberapa persyaratan ini mungkin dilonggarkan; tetapi, misalnya, saat ini Multi Cluster Ingress mengharuskan pod berada di jaringan VPC yang sama, dengan cluster itu sendiri berada dalam project yang sama dengan fleet.
Ketika komponen dapat melonggarkan persyaratan project awal dan jaringan VPC ini, kami mengantisipasi bahwa mengadopsi model VPC Bersama akan menjadi praktik terbaik setiap kali Anda memerlukan beberapa project. Dalam model seperti itu, fleet dapat dibuat instance-nya dalam project host jaringan VPC dengan resource yang terdaftar dari project layanannya masing-masing. Jika memerlukan beberapa fleet dengan VPC Bersama, Anda dapat menominasikan project untuk menjadi project host fleet.
Menambahkan/menghapus resource fleet (cluster)
Resource yang mendukung fleet yang ada dapat ditambahkan ke fleet, tetapi Anda harus sangat berhati-hati untuk memastikan layanan tidak terganggu karena ditambahkan. Secara khusus, pastikan properti kepercayaan dan kesamaan dipertimbangkan sebelum menambahkan resource ke fleet. Administrator perangkat harus memberi perhatian khusus pada bagaimana komponen fleet yang aktif menggunakan kesamaan. Hal ini mungkin memerlukan migrasi ke praktik penamaan yang konsisten, menetapkan tata kelola resource, atau berpotensi melakukan tindakan lain sebelum menambahkan resource ke fleet.
Menghapus resource dari fleet juga memerlukan perhatian tambahan. Misalnya, resource yang secara aktif menjadi bagian dari mesh layanan atau ditargetkan sebagai bagian dari load balancer multi-cluster akan terpengaruh. Untuk menyiapkan penghapusan resource, sebaiknya tinjau setiap komponen yang telah Anda aktifkan di perangkat Anda, dan lakukan langkah-langkah yang diperlukan untuk menghabiskan traffic mesh layanan aktif atau traffic eksternal.
Seiring dengan perkembangan fleet, kami akan memberikan lebih banyak panduan in-band saat menambahkan dan menghapus resource fleet.
Mengaktifkan atau mengonfigurasi ulang komponen fleet
Mengaktifkan atau mengonfigurasi ulang komponen Google Cloud atau GKE Enterprise yang menggunakan fleet juga memerlukan beberapa kehati-hatian khusus. Saat mengaktifkan komponen baru, perhatikan potensi efek samping dari pengaktifan komponen tersebut di semua cluster. Misalnya, sebelum mengaktifkan Cloud Service Mesh, pahami endpoint layanan mana yang digabungkan di seluruh resource, dan pastikan ini adalah hasil yang diinginkan.
Kami akan memberikan panduan in-band lebih lanjut saat mengonfigurasi komponen yang kompatibel dengan fleet saat kami mengembangkan konsep fleet.
Apa langkah selanjutnya?
- Untuk beberapa skenario hipotetis yang menggambarkan pertimbangan yang dijelaskan dalam panduan ini, lihat Contoh perangkat.