Banyak fitur yang dijelaskan dalam panduan ini hanya tersedia sebagai bagian dari GKE Enterprise. Untuk mengetahui detail selengkapnya, lihat opsi deployment GKE Enterprise.
Panduan ini ditujukan untuk arsitek Cloud yang ingin mulai menggunakan fleet di organisasi mereka. Sebelum membaca panduan ini, pastikan Anda sudah memahami Ringkasan pengelolaan perangkat dan Merencanakan resource fleet, yang membahas cara mengatur cluster baru atau yang sudah ada ke dalam fleet.
Praktik terbaik untuk adopsi fitur
Semua fitur fleet (kecuali kemampuan observasi fleet dasar) bersifat opsional, karena Anda perlu menentukan bahwa Anda ingin menggunakannya. Hanya menambahkan cluster yang sudah ada ke fleet tidak mengubah konfigurasinya. Saat Anda memutuskan untuk menggunakan fitur fleet, beberapa fitur dapat langsung diaktifkan dengan risiko minimal, tetapi Anda mungkin perlu menggunakan beberapa fitur dengan lebih hati-hati. Bagian ini memberikan beberapa panduan terkait penerapan fitur.
Khususnya dengan cluster dan workload yang ada, Anda harus sangat berhati-hati ketika fitur menggunakan kesamaan. Ini adalah konsep fleet, di mana namespace, layanan, atau identitas dengan nama yang sama di cluster yang berbeda dianggap oleh fitur sebagai hal yang sama. Anda dapat membaca lebih lanjut tentang prinsip kesamaan dan fitur mana yang menggunakannya dalam Cara kerja fleet.
Orientasi fitur berisiko rendah
"Ambient" berikut fitur tidak mengasumsikan jenis kesamaan apa pun dan tidak memengaruhi klaster dengan cara apa pun. Semuanya dapat digunakan dengan aman bahkan dengan workload dan cluster yang ada, sehingga Anda dapat langsung mendapatkan manfaat dari insight keamanan dan kemampuan observasi yang ditingkatkan di seluruh fleet Anda, serta kemampuan untuk mengelola urutan upgrade cluster berdasarkan keanggotaan fleet.
- Pengurutan peluncuran berbasis perangkat
- Kemampuan observasi perangkat
- Postur keamanan
- Postur kepatuhan
Fitur berikut diinstal pada masing-masing cluster. Fitur dapat mengasumsikan kesamaan, tetapi hanya saat mengonfigurasi atau menentukan resource di beberapa cluster. Artinya, Anda dapat mengaktifkan fitur-fitur ini dengan aman di cluster Anda dengan workload yang ada, dan hanya perlu mempertimbangkan kesamaan saat membuat atau menggunakan konfigurasi untuk cluster tersebut yang menggunakan pemilih opsional ini.
- Sinkronisasi Konfigurasi. Anda mungkin perlu mempertimbangkan kesamaan jika ingin menggunakan pemilih namespace dan cakupan tim opsional.
- Otorisasi Biner. Anda mungkin perlu mempertimbangkan namespace, identitas, atau kesamaan layanan jika ingin menggunakan aturan cakupan opsional.
- Pengontrol Kebijakan. Anda mungkin perlu mempertimbangkan kesamaan namespace jika ingin mengecualikan namespace dari penerapan.
Orientasi fitur multi-cluster lanjutan
Fitur canggih berikut mengurangi beban operasional pengelolaan banyak cluster. Namun, Anda perlu lebih berhati-hati dalam menggunakan fitur-fitur ini, karena semua fitur ini memerlukan asumsi satu atau beberapa jenis kesamaan agar dapat berfungsi. Selain itu, mengaktifkan atau menonaktifkannya dapat memengaruhi beberapa cluster dan workload-nya.
- Fleet Workload Identity Federation
- Cloud Service Mesh
- Gateway Multi-cluster
- Multi Cluster Ingress
- Pengelolaan tim armada
Misalnya, jika Anda memiliki namespace Kubernetes yang sudah ada dengan nama yang sama di cluster dan aplikasi yang berbeda (termasuk namespace default), Anda harus memastikan bahwa Anda ingin namespace tersebut diperlakukan sebagai namespace yang sama sebelum mengaktifkan fitur apa pun yang menggunakan asumsi ini. Demikian pula, jika ingin menggunakan Cloud Service Mesh, Anda harus memahami endpoint layanan mana yang akan digabungkan di seluruh cluster Anda, dan mengonfirmasi bahwa ini adalah perilaku yang diinginkan.
Kesamaan namespace audit
Jika mengetahui aplikasi Anda dengan baik, Anda dapat mengaudit namespace hanya dengan memverifikasi bahwa tidak ada dua hal yang "berbeda" menggunakan namespace yang sama. Secara khusus, perhatikan penggunaan ad hoc dari namespace default. Misalnya, jika Anda memiliki namespace bernama default
di satu cluster, dan namespace bernama default
di cluster lain, tetapi digunakan untuk tujuan yang berbeda, Anda harus mengganti nama salah satunya.
Untuk pendekatan yang lebih ketat, coba langkah berikut. Untuk setiap set namespace dengan nama yang sama di berbagai cluster fleet, pastikan:
- Di tiap cluster, aturan RBAC yang sama ada di cluster dan namespace akun utama diizinkan mengakses namespace.
- kumpulan gambar yang digunakan oleh Pod (tanpa hash/tag) sama.
- kumpulan Secret yang digunakan oleh Pod adalah identik.
Jika semua kondisi tersebut benar, namespace akan cukup mirip untuk diperlakukan sebagai "sama".
Jika namespace tidak cukup mirip, Anda dapat memigrasikan aplikasi ke namespace baru. Setelah Anda puas mengasumsikan kesamaan namespace, Anda dapat mengaktifkan fitur yang menggunakannya.
Audit layanan yang sama
Jika Anda ingin mengadopsi Cloud Service Mesh untuk mengelola aplikasi berbasis microservice, masalah lain yang perlu dipertimbangkan adalah kesamaan layanan. Artinya, untuk kombinasi namespace dan nama layanan apa pun, Cloud Service Mesh akan memperlakukannya sebagai layanan logis yang sama dalam hal:
- Identity (khususnya untuk keamanan Cloud Service Mesh): jika
namespace1/service1
diberi otorisasi untuk melakukan sesuatu, workload dengan identitas tersebut dari cluster mana pun akan diberi otorisasi. - Pengelolaan traffic: secara default, beban traffic diseimbangkan di seluruh layanan
namespace1/service1
di cluster mana pun. - Kemampuan observasi: metrik untuk
namespace1/service1
di semua cluster diagregasikan bersama.
Jika Anda mengaktifkan Cloud Service Mesh dengan cluster dan aplikasi baru, sebaiknya simpan kombinasi nama layanan/namespace unik di seluruh mesh Anda. Untuk aplikasi yang sudah ada, audit layanan Anda untuk memastikan bahwa layanan dengan namespace dan nama yang sama di seluruh cluster Anda adalah layanan yang ingin Anda perlakukan sebagai layanan yang sama dalam hal identitas, pengelolaan traffic, dan kemampuan observasi.
Secara khusus, pastikan layanan yang berbeda secara logis (misalnya, API akuntansi pembayaran dan API transaksi pembayaran) tidak menggunakan pasangan [namespace, name] yang sama (misalnya, payments/api
) karena layanan tersebut akan diperlakukan sebagai layanan yang sama setelah berada di mesh layanan. Penggabungan konseptual ini terjadi bahkan lintas batas wilayah. Selain itu, fungsi layanan mungkin terdampak.
Kesamaan namespace/nama layanan juga digunakan oleh Multi Cluster Ingress dan Gateway multi-cluster saat mengarahkan traffic ke layanan di beberapa cluster, meskipun hanya untuk layanan yang diekspos di luar cluster.
Mempertimbangkan workload identity
Fitur fleet yang canggih adalah Workload Identity Federation di seluruh fleet. Hal ini memperluas kemampuan yang disediakan di Workload Identity Federation untuk GKE, yang memungkinkan beban kerja di cluster Anda mengautentikasi ke Google tanpa mengharuskan Anda mendownload, merotasi secara manual, dan mengelola kunci akun layanan Google Cloud secara umum. Sebagai gantinya, workload mengautentikasi menggunakan token berumur singkat yang dihasilkan oleh cluster, dengan setiap cluster ditambahkan sebagai penyedia identitas ke kumpulan workload identity khusus. Workload yang berjalan di namespace tertentu dapat memiliki identitas Identity and Access Management yang sama di seluruh cluster.
Meskipun Workload Identity Federation for GKE reguler menggunakan kumpulan identitas seluruh project, Workload Identity Federation seluruh fleet menggunakan kumpulan workload identity untuk seluruh fleet, meskipun cluster berada di project yang berbeda, dengan kemiripan implisit untuk identitas di seluruh fleet serta kesamaan namespace dan layanan. Hal ini mempermudah penyiapan autentikasi untuk aplikasi Anda di seluruh project, tetapi dapat memiliki pertimbangan kontrol akses melebihi workload untuk Workload Identity Federation for GKE reguler jika Anda memilih untuk menggunakannya dalam fleet multi-project, terutama jika project host fleet memiliki campuran cluster fleet dan non-fleet.
Untuk mengetahui lebih lanjut Workload Identity Federation fleet dan cara menggunakannya untuk mengakses layanan Google Cloud, lihat Menggunakan fleet Workload Identity. Untuk mendapatkan panduan meminimalkan risiko dengan Workload Identity Federation fleet beserta beberapa contohnya, lihat Praktik terbaik untuk menggunakan Workload Identity fleet.
Default tingkat fleet
GKE Enterprise memberikan kemampuan menetapkan setelan default tingkat fleet untuk fitur perusahaan tertentu, termasuk Cloud Service Mesh, Config Sync, dan Pengontrol Kebijakan. Hal ini akan membantu Anda menyiapkan cluster untuk menggunakan fitur-fitur ini tanpa harus mengonfigurasi setiap cluster satu per satu. Misalnya, admin dapat mengaktifkan Pengontrol Kebijakan untuk perangkat mereka dan menetapkan kebijakan default di tingkat perangkat. Tindakan ini akan menginstal agen yang diperlukan di cluster anggota fleet baru dan menerapkan kebijakan default pada agen tersebut.
Namun, setelan default ini hanya berlaku secara otomatis untuk cluster baru yang Anda tambahkan ke fleet pada waktu pembuatan cluster. Cluster yang ada dan workload-nya tidak akan terpengaruh, meskipun Anda telah menambahkannya ke fleet, atau jika Anda menambahkan cluster setelah menyiapkan default fitur. Artinya, Anda dapat menyiapkan setelan default tingkat fleet dengan aman tanpa risiko mengaktifkan atau mengonfigurasi fitur pada cluster yang tidak siap Anda lakukan. Anda dapat memilih untuk menerapkan setelan default ke cluster yang ada kapan saja.
Persyaratan fitur
Ada beberapa batasan yang perlu dipertimbangkan saat menerapkan fleet berbasis di armada yang digunakan oleh suatu organisasi. Misalnya, beberapa fitur tidak mendukung bekerja dengan cluster yang tidak ada dalam project host fleet, sementara yang lain tidak didukung pada cluster di luar Google Cloud.
Tabel berikut menunjukkan persyaratan dan batasan setiap komponen saat ini, dengan beberapa panduan spesifik di bagian berikut.
Fitur |
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 batasan | Semua cluster yang digunakan dengan Cloud Service Mesh yang ada dalam project yang sama harus didaftarkan ke fleet yang sama. Untuk informasi selengkapnya, lihat Persyaratan fleet Cloud Service Mesh. | Cluster GKE harus berada di jaringan VPC yang sama. |
Layanan Multi-cluster (MCS) | GKE di Google Cloud | Tidak ada | Lihat MCS di VPC Bersama |
Multi Cluster Ingress dan Gateway multi-cluster | GKE di Google Cloud | Resource Ingress/Gateway, cluster GKE, dan fleet harus dalam proyek yang sama. | Resource Ingress/Gateway dan cluster GKE harus berada dalam jaringan VPC yang sama. |
Workload Identity pools | Dioptimalkan untuk GKE di Google Cloud dan Google Distributed Cloud di VMware. Kubernetes lainnya cluster didukung, tetapi memerlukan pekerjaan penyiapan tambahan. | Tidak ada | Tidak ada |
Otorisasi Biner | GKE di Google Cloud, Google Distributed Cloud di VMware, Google Distributed Cloud on bare metal | Tidak ada | Tidak ada |
Insight Kerentanan Lanjutan | GKE di Google Cloud | Tidak ada | Tidak ada |
Postur Keamanan | GKE di Google Cloud | Tidak ada | Tidak ada |
Postur Kepatuhan | GKE di Google Cloud | Tidak ada | Tidak ada |
Metrik pemanfaatan resource fleet | 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 | GKE di Google Cloud | Tidak ada | Tidak ada |
Enkripsi transparan antarnode | GKE di Google Cloud | Tidak ada | Tidak ada |
Pengontrol Konfigurasi | Tidak berlaku | Tidak ada | Tidak ada |
Pengurutan Peluncuran | GKE di Google Cloud | Tidak ada | Tidak ada |
Mempertimbangkan persyaratan Virtual Private Cloud
Jika berencana menggunakan fitur seperti Cloud Service Mesh yang mengharuskan cluster berada dalam satu jaringan Virtual Private Cloud (VPC) seperti ditunjukkan pada tabel sebelumnya, Anda harus membuat fleet untuk setiap VPC. Jika tidak berencana menggunakan fitur tersebut, beberapa VPC dapat dimasukkan ke dalam satu fleet.
Misalnya, salah satu pola umumnya adalah suatu organisasi memiliki beberapa project, masing-masing dengan VPC default-nya sendiri. Koneksi ini mungkin sudah memiliki koneksi peering antara satu sama lain. Jika Anda tidak menggunakan fitur dengan persyaratan VPC tunggal, semua fitur tersebut dapat digabungkan ke dalam satu perangkat. Pola umum lainnya mengikuti "hub and spoke" topologi jaringan, yang menggunakan beberapa VPC. Jika tidak menggunakan fitur dengan persyaratan VPC tunggal, Anda dapat menempatkan cluster dari semua VPC tersebut ke dalam satu fleet. Perlu diperhatikan bahwa dalam beberapa kasus, mengikuti panduan ini dapat membuat Anda hanya memiliki satu cluster. Dalam hal ini, Anda mungkin perlu mengabaikan penggunaan fitur dengan pembatasan VPC dan membuat fleet multi-project, atau mempertimbangkan kembali arsitektur Anda dan memindahkan beban kerja sebagaimana mestinya.
Persyaratan untuk jaringan multi-cluster
Jika Anda ingin menggunakan Multi Cluster Ingress atau Gateway multi-cluster untuk pengelolaan traffic, perhatikan bahwa dalam kedua kasus tersebut, pengontrol gateway tidak dapat mencakup project. Artinya, semua cluster yang ingin Anda gunakan dengan fitur-fitur ini harus berada dalam project serta fleet yang sama. Jika perlu membuat fleet yang menyertakan cluster dari beberapa project, Anda dapat menggunakan Gateway cluster tunggal, dan mengarahkan traffic ke Gateway yang tepat dengan cara lain (misalnya, dengan menggunakan DNS). Cluster yang menggunakan fitur ini juga harus berada di jaringan VPC yang sama.
Langkah selanjutnya
- Pelajari lebih lanjut cara mengelola fitur perangkat di Mengelola fitur tingkat fleet.
- Pelajari lebih lanjut cara kerja fleet di Cara kerja fleet.