Fitur fleet rencana

Bagian penting dari perencanaan untuk armada adalah memutuskan fitur berkemampuan armada mana yang ingin Anda gunakan. Khususnya, jika Anda bekerja dengan cluster dan beban kerja produksi yang sudah ada, sebaiknya identifikasi fitur fleet yang dapat segera diadopsi dengan hambatan atau risiko minimal pada aplikasi yang ada, sekaligus merencanakan fitur lain yang mungkin memerlukan adopsi 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 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.

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.

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.

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