Merencanakan fitur fleet

Bagian penting dari perencanaan untuk armada adalah memutuskan fitur yang kompatibel dengan armada yang ingin Anda gunakan. Khususnya jika Anda bekerja dengan cluster dan workload produksi yang ada, Anda mungkin ingin mengidentifikasi fitur armada yang dapat langsung diterapkan dengan hambatan atau risiko minimal pada 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 armada dan persyaratannya, serta memberikan beberapa panduan praktis tentang adopsi fitur.

Panduan ini ditujukan bagi arsitek Cloud yang ingin mulai menggunakan armada di organisasi mereka. Sebelum membaca panduan ini, pastikan Anda memahami Ringkasan pengelolaan fleet dan Merencanakan resource fleet, yang membahas cara mengatur cluster baru atau yang sudah ada ke dalam fleet.

Praktik terbaik untuk penggunaan fitur

Semua fitur fleet (kecuali kemampuan observasi fleet dasar) bersifat keikutsertaan, yang berarti Anda harus menentukan bahwa Anda ingin menggunakannya. Menambahkan cluster yang ada ke fleet saja tidak akan mengubah konfigurasinya. Saat Anda memutuskan untuk menggunakan fitur fleet, beberapa fitur dapat diaktifkan segera dengan risiko minimal, tetapi Anda mungkin perlu lebih berhati-hati saat menggunakan beberapa fitur lainnya. Bagian ini memberikan beberapa panduan untuk adopsi fitur.

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

Mengaktifkan fitur berisiko rendah

Fitur "sekitar" berikut tidak mengasumsikan kesamaan jenis apa pun dan tidak memengaruhi cluster dengan cara apa pun. Semua fitur ini dapat digunakan dengan aman meskipun dengan workload dan cluster yang ada, sehingga Anda dapat langsung memperoleh manfaat dari peningkatan kemampuan observasi dan insight keamanan di seluruh fleet, serta kemampuan untuk mengelola urutan upgrade cluster berdasarkan keanggotaan fleet.

Fitur berikut diinstal di setiap cluster. Fitur 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 untuk fitur tersebut yang menggunakan pemilih opsional ini.

Mengaktifkan fitur multi-cluster lanjutan

Fitur canggih berikut mengurangi biaya operasional pengelolaan beberapa cluster. Namun, fitur ini harus digunakan dengan lebih hati-hati karena semuanya memerlukan asumsi tentang 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 berbagai cluster dan aplikasi (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 Anda 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 memahami aplikasi Anda dengan baik, Anda dapat mengaudit namespace hanya dengan memverifikasi bahwa tidak ada dua aplikasi "berbeda" yang menggunakan namespace yang sama. Khususnya, perhatikan penggunaan namespace default secara ad hoc. 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-langkah berikut. Untuk setiap set namespace dengan nama yang sama di berbagai cluster dalam fleet, periksa apakah:

  • Di setiap cluster, aturan RBAC yang sama ada di cluster dan namespace principal diizinkan mengakses namespace.
  • kumpulan gambar yang digunakan oleh Pod (tanpa hash/tag) sama.
  • kumpulan Secret yang digunakan oleh Pod identik.

Jika semuanya benar, namespace tersebut cukup serupa untuk dianggap "sama".

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

Kesamaan layanan audit

Jika Anda ingin menggunakan 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:

  • 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 balance di namespace1/service1 layanan dalam 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 cadangkan kombinasi nama layanan/namespace yang 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.

Khususnya, pastikan layanan yang berbeda secara logis (misalnya, API akuntansi pembayaran dan API transaksi pembayaran) tidak menggunakan pasangan [namespace, nama] yang sama (misalnya payments/api) karena akan diperlakukan sebagai layanan yang sama setelah berada di service mesh. Penggabungan konseptual ini terjadi bahkan di seluruh batas regional. Selain itu, fungsi layanan mungkin terpengaruh.

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

Mempertimbangkan workload identity

Fitur armada yang canggih adalah Workload Identity Federation di seluruh armada. 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, memutar secara manual, dan umumnya mengelola kunci akun layanan Google Cloud . Sebagai gantinya, workload melakukan autentikasi menggunakan token berumur pendek yang dihasilkan oleh cluster, dengan setiap cluster ditambahkan sebagai penyedia identitas ke workload identity pool khusus. Workload yang berjalan di namespace tertentu dapat berbagi identitas Identity and Access Management yang sama di seluruh cluster.

Meskipun Workload Identity Federation reguler untuk GKE menggunakan kumpulan identitas di seluruh project, Workload Identity Federation di seluruh fleet menggunakan kumpulan identitas workload untuk seluruh fleet, meskipun cluster berada di project yang berbeda, dengan kesamaan implisit untuk identitas di seluruh fleet serta kesamaan namespace dan layanan. Hal ini menyederhanakan penyiapan autentikasi untuk aplikasi Anda di seluruh project, tetapi dapat menimbulkan pertimbangan kontrol akses di atas dan di luar pertimbangan untuk Federasi Identitas Beban Kerja 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 tentang Workload Identity Federation fleet dan cara menggunakannya untuk mengakses Google Cloud layanan, lihat Menggunakan Workload Identity fleet. Untuk mendapatkan panduan tentang cara meminimalkan risiko dengan Workload Identity Federation fleet beserta beberapa contohnya, lihat Praktik terbaik untuk menggunakan Workload Identity fleet.

Default tingkat armada

GKE memberikan kemampuan untuk menetapkan default tingkat fleet untuk fitur perusahaan tertentu, termasuk Cloud Service Mesh, Config Sync, dan Pengontrol Kebijakan. 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 mereka dan menetapkan kebijakan default di tingkat fleet. Tindakan ini akan menginstal agen yang diperlukan di cluster anggota armada baru dan menerapkan kebijakan default padanya.

Namun, nilai default ini hanya diterapkan secara otomatis ke cluster baru yang Anda tambahkan ke fleet pada saat pembuatan cluster. Cluster yang ada dan beban kerjanya tidak terpengaruh, meskipun Anda telah menambahkannya ke fleet, atau jika Anda menambahkan cluster setelah menyiapkan default fitur. Artinya, Anda dapat menyiapkan default tingkat fleet dengan aman tanpa berisiko mengaktifkan atau mengonfigurasi fitur di cluster yang belum siap Anda lakukan. Anda dapat memilih untuk menerapkan setelan default ke cluster yang ada nanti.

Persyaratan fitur

Ada beberapa batasan yang perlu dipertimbangkan saat menerapkan armada berdasarkan fitur armada yang ingin digunakan organisasi Anda. Misalnya, beberapa fitur tidak mendukung penggunaan cluster yang tidak ada di 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 khusus di bagian berikut.

Fitur
 Jenis cluster
 Persyaratan project
 Persyaratan VPC
Config Sync Semua cluster yang didukung GKE Tidak ada Tidak ada
Pengontrol Kebijakan Semua cluster yang didukung GKE Tidak ada Tidak ada
Cloud Service Mesh Lihat batasan. Semua cluster yang digunakan dengan Cloud Service Mesh yang berada dalam project yang sama harus didaftarkan ke armada yang sama. Untuk mengetahui informasi selengkapnya, lihat Persyaratan armada 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 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 lain didukung, tetapi memerlukan upaya 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

Mempertimbangkan 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 dalam tabel sebelumnya, Anda harus membuat armada untuk setiap VPC. Jika tidak berencana menggunakan fitur tersebut, beberapa VPC dapat dimasukkan ke dalam satu armada.

Misalnya, salah satu pola umum adalah organisasi memiliki beberapa project, yang masing-masing memiliki VPC defaultnya sendiri. Keduanya mungkin sudah memiliki koneksi peering satu sama lain. Jika Anda tidak menggunakan fitur dengan persyaratan VPC tunggal, semuanya dapat dimasukkan ke dalam satu armada. Pola umum lainnya mengikuti topologi "hub and spoke", yang menggunakan beberapa VPC. Jika Anda 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 mengurungkan penggunaan fitur dengan batasan VPC dan membuat fleet multi-project, atau mempertimbangkan kembali arsitektur dan memindahkan workload, sebagaimana mestinya.

Persyaratan untuk jaringan multi-cluster

Jika Anda ingin menggunakan Multi Cluster Ingress atau Gateway multi-cluster untuk pengelolaan traffic, perlu diketahui bahwa dalam kedua kasus tersebut, pengontrol gateway tidak dapat mencakup beberapa project. Artinya, semua cluster yang ingin Anda gunakan dengan fitur ini harus berada dalam project yang sama dan fleet yang sama. Jika Anda perlu membuat fleet yang menyertakan cluster dari beberapa project, Anda dapat menggunakan Gateway cluster tunggal sebagai gantinya, 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 berikutnya