Merencanakan fitur fleet

Bagian penting dari perencanaan untuk armada adalah menentukan fitur yang kompatibel dengan armada yang ingin Anda gunakan. Khususnya jika Anda menggunakan cluster dan beban kerja produksi yang ada, sebaiknya identifikasi fitur fleet yang dapat langsung diterapkan dengan hambatan atau risiko minimal untuk aplikasi yang ada, sambil merencanakan fitur lain yang mungkin memerlukan penerapan yang lebih bertahap atau hati-hati. Panduan ini menjelaskan berbagai jenis fitur yang diaktifkan dengan menggunakan fleet dan persyaratannya, serta memberikan beberapa panduan praktis tentang adopsi fitur.

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 memulai penggunaan fleet di organisasi mereka. Sebelum membaca panduan ini, pastikan Anda sudah memahami Ringkasan pengelolaan fleet dan Merencanakan resource fleet, yang membahas cara mengatur cluster baru atau yang sudah ada ke dalam fleet.

Praktik terbaik untuk penerapan fitur

Semua fitur fleet (kecuali visibilitas fleet dasar) bersifat opsional, sehingga Anda harus menentukan bahwa Anda ingin menggunakannya. Menambahkan cluster yang ada ke fleet tidak akan mengubah konfigurasinya. Jika 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 untuk mengadopsi fitur.

Khususnya dengan cluster dan beban kerja yang ada, Anda harus sangat berhati-hati saat fitur menggunakan kesamaan. Ini adalah konsep fleet tempat namespace, layanan, atau identitas dengan nama yang sama di berbagai cluster dianggap oleh fitur tersebut sebagai hal yang sama. Anda dapat membaca selengkapnya tentang prinsip kesamaan dan fitur yang menggunakannya di Cara kerja fleet.

Mengaktifkan fitur berisiko rendah

Fitur "ambient" berikut tidak mengasumsikan jenis kesamaan apa pun dan tidak memengaruhi cluster dengan cara apa pun. Semuanya dapat digunakan dengan aman bahkan dengan workload dan cluster yang ada, sehingga Anda dapat langsung mendapatkan manfaat dari peningkatan visibilitas dan insight keamanan di seluruh fleet, serta kemampuan untuk mengelola urutan upgrade cluster berdasarkan keanggotaan fleet.

Fitur berikut diinstal di setiap cluster. Fitur tersebut dapat mengasumsikan kesamaan, tetapi hanya saat mengonfigurasi atau menentukan resource di beberapa cluster. Artinya, Anda dapat mengaktifkan fitur ini dengan aman di cluster dengan beban kerja yang ada, dan hanya perlu mempertimbangkan kesamaan saat membuat atau menggunakan konfigurasi untuknya yang menggunakan pemilih opsional ini.

Melakukan aktivasi fitur multi-cluster lanjutan

Fitur canggih berikut mengurangi overhead operasional pengelolaan beberapa cluster. Namun, fitur ini harus digunakan dengan lebih hati-hati, karena semuanya memerlukan asumsi satu atau beberapa jenis kesamaan agar dapat berfungsi, dan mengaktifkan atau menonaktifkannya dapat memengaruhi beberapa cluster dan workload-nya.

Misalnya, jika Anda memiliki namespace Kubernetes yang sudah ada dengan nama yang sama di cluster dan aplikasi yang berbeda (termasuk namespace default), Anda harus memeriksa apakah Anda ingin namespace tersebut diperlakukan sebagai namespace yang sama sebelum mengaktifkan fitur apa pun yang membuat asumsi ini. Demikian pula, jika ingin menggunakan Cloud Service Mesh, Anda harus memahami endpoint layanan mana yang akan digabungkan di seluruh cluster, dan mengonfirmasi bahwa ini adalah perilaku yang diinginkan.

Mengaudit kesamaan namespace

Jika Anda mengetahui aplikasi dengan baik, Anda dapat mengaudit namespace hanya dengan memverifikasi bahwa tidak ada dua aplikasi "berbeda" yang menggunakan namespace yang sama. Secara khusus, perhatikan penggunaan ad hoc namespace default. Misalnya, jika Anda memiliki namespace bernama default di satu cluster, dan namespace bernama default di cluster lain, tetapi keduanya digunakan untuk tujuan yang berbeda, Anda harus mengganti nama salah satunya.

Untuk pendekatan yang lebih ketat, coba langkah berikut. Untuk setiap kumpulan namespace dengan nama yang sama di berbagai cluster dalam satu fleet, pastikan:

  • di setiap cluster, aturan RBAC yang sama ada di cluster dan namespace akun utama diizinkan untuk mengakses namespace.
  • kumpulan gambar yang digunakan oleh Pod (minus hash/tag) sama.
  • kumpulan Secret yang digunakan oleh Pod identik.

Jika semua hal ini benar, namespace tersebut cukup mirip untuk diperlakukan sebagai "sama".

Jika namespace Anda tidak cukup mirip, Anda dapat memigrasikan aplikasi ke namespace baru. Setelah yakin bahwa namespace sama, Anda dapat mengaktifkan fitur yang menggunakannya.

Mengaudit kesamaan layanan

Jika Anda ingin menggunakan Cloud Service Mesh untuk mengelola aplikasi berbasis microservice, masalah lain yang perlu dipertimbangkan adalah kesamaan layanan. Artinya, untuk setiap kombinasi namespace dan nama layanan, Cloud Service Mesh akan memperlakukannya sebagai layanan logis yang sama dalam hal:

  • Identitas (khusus 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, traffic di-load balancing di seluruh layanan namespace1/service1 di cluster mana pun.
  • Kemampuan observasi: metrik untuk namespace1/service1 di semua cluster digabungkan.

Jika Anda mengaktifkan Cloud Service Mesh dengan cluster dan aplikasi baru, sebaiknya Anda mencadangkan kombinasi nama layanan/namespace unik di seluruh mesh. Untuk aplikasi yang ada, audit layanan Anda untuk memastikan bahwa layanan dengan namespace dan nama yang sama di seluruh cluster adalah layanan yang ingin Anda perlakukan sebagai layanan yang sama dalam hal identitas, pengelolaan traffic, dan visibilitas.

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 di seluruh batas regional. Selain itu, fungsi layanan mungkin terpengaruh.

Kesamaan namespace/nama layanan juga diasumsikan 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.

Pertimbangkan workload identity

Fitur yang efektif untuk seluruh fleet adalah Workload Identity Federation. Hal ini memperluas kemampuan yang disediakan di Workload Identity Federation untuk GKE, yang memungkinkan workload di cluster Anda mengautentikasi ke Google tanpa mengharuskan Anda mendownload, merotasi secara manual, dan secara umum mengelola kunci akun layanan Google Cloud. Sebagai gantinya, beban kerja melakukan autentikasi menggunakan token berumur pendek yang dihasilkan oleh cluster, dengan setiap cluster ditambahkan sebagai penyedia identitas ke kumpulan workload identity khusus. Workload yang berjalan di namespace tertentu dapat menggunakan identitas Identity and Access Management yang sama di seluruh cluster.

Meskipun Workload Identity Federation reguler untuk GKE menggunakan kumpulan identitas seluruh project, Workload Identity Federation seluruh fleet menggunakan kumpulan identitas workload untuk seluruh fleet, meskipun cluster berada dalam project yang berbeda, dengan kesamaan 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 di atas dan di luar pertimbangan untuk Workload Identity Federation reguler untuk GKE jika Anda memilih untuk menggunakannya di 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 Workload Identity fleet. Untuk panduan tentang cara meminimalkan risiko dengan Workload Identity Federation fleet beserta beberapa contoh, lihat Praktik terbaik untuk menggunakan Workload Identity fleet.

Default tingkat armada

GKE Enterprise menyediakan kemampuan untuk menetapkan setelan default tingkat fleet untuk fitur perusahaan tertentu, termasuk Cloud Service Mesh, Config Sync, dan Policy Controller. Hal ini membantu Anda menyiapkan cluster untuk menggunakan fitur ini tanpa harus mengonfigurasi setiap cluster satu per satu. Misalnya, admin dapat mengaktifkan Pengontrol Kebijakan untuk fleet-nya dan menetapkan kebijakan default di tingkat fleet. Tindakan ini akan menginstal agen yang diperlukan di cluster anggota fleet baru dan menerapkan kebijakan default ke cluster 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 beban kerjanya 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 di cluster yang belum siap untuk melakukannya. Anda selalu dapat memilih untuk menerapkan setelan default ke cluster yang ada nanti.

Persyaratan fitur

Ada beberapa batasan yang perlu dipertimbangkan saat menerapkan fleet berdasarkan fitur fleet yang ingin digunakan organisasi Anda. Misalnya, beberapa fitur tidak mendukung penggunaan cluster yang tidak ada dalam project host fleet, sementara fitur lainnya tidak didukung di cluster di luar Google Cloud.

Tabel berikut menunjukkan persyaratan dan batasan saat ini untuk setiap komponen, 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 berada dalam project yang sama harus terdaftar ke armada yang sama. Untuk mengetahui informasi selengkapnya, lihat Persyaratan fleet Cloud Service Mesh. Cluster GKE harus berada di jaringan VPC yang sama.
Service 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 berada dalam project yang sama. Resource Ingress/Gateway dan cluster GKE harus berada di jaringan VPC yang sama.
Workload Identity pools Dioptimalkan untuk GKE di Google Cloud dan Google Distributed Cloud di VMware. Cluster Kubernetes lainnya didukung, tetapi memerlukan pekerjaan penyiapan tambahan. Tidak ada Tidak ada
Otorisasi Biner GKE di Google Cloud, Google Distributed Cloud di VMware, Google Distributed Cloud di bare metal Tidak ada Tidak ada
Advanced Vulnerability Insights 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
Logging fleet Semua Tidak ada Tidak ada
Menghubungkan gateway Semua Tidak ada Tidak ada
Pengelolaan tim fleet Semua Tidak ada Tidak ada
Kebijakan Jaringan FQDN Pod GKE di Google Cloud Tidak ada Tidak ada
Enkripsi transparan antar-node 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

Pertimbangkan persyaratan Virtual Private Cloud

Jika Anda berencana menggunakan fitur seperti Cloud Service Mesh yang mengharuskan cluster berada dalam satu jaringan Virtual Private Cloud (VPC), seperti yang 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 umum adalah organisasi memiliki beberapa project, masing-masing dengan VPC default-nya sendiri. Kedua jaringan tersebut mungkin sudah memiliki koneksi peering satu sama lain. Jika Anda tidak menggunakan fitur dengan persyaratan VPC tunggal, semua fitur tersebut dapat dimasukkan ke dalam satu fleet. Pola umum lainnya mengikuti topologi "hub and spoke", yang menggunakan beberapa VPC. Jika tidak menggunakan fitur dengan persyaratan VPC tunggal, Anda dapat menempatkan cluster dari semua VPC tersebut ke dalam satu fleet. Perhatikan bahwa dalam beberapa kasus, mengikuti panduan ini dapat menyebabkan Anda memiliki armada yang hanya memiliki satu cluster. Dalam hal ini, Anda mungkin perlu berhenti menggunakan fitur dengan batasan VPC dan membuat fleet multi-project, atau mempertimbangkan kembali arsitektur Anda dan memindahkan workload, 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 menjangkau project. Artinya, semua cluster yang ingin Anda gunakan dengan fitur ini harus berada dalam project yang sama 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 dalam jaringan VPC yang sama.

Langkah selanjutnya