Seperti yang Anda pelajari dalam Ringkasan pengelolaan perangkat, fleet adalah mekanisme pengelompokan untuk mengelola, mengonfigurasi, dan mengamankan cluster Kubernetes dalam skala besar. Armada merupakan alat canggih yang menghilangkan kebutuhan untuk melakukan operasi berulang di lingkungan multi-cluster serta memberikan konsistensi dan kemampuan observasi yang komprehensif terhadap kelompok cluster yang besar. Sejumlah fitur GKE Enterprise hanya tersedia melalui fleet.
Strategi pengelompokan yang Anda gunakan untuk membuat armada dapat bervariasi tergantung pada kebutuhan teknis dan bisnis organisasi Anda. Misalnya, satu organisasi mungkin mengelompokkan cluster berdasarkan jenis aplikasi yang berjalan di dalamnya, sementara organisasi lain mungkin mengelompokkannya berdasarkan region, lingkungan, atau faktor relevan lainnya. Jika semua hal lainnya sama, Anda dapat memiliki armada sesedikit mungkin yang diperlukan dalam organisasi Anda.
Panduan ini ditujukan untuk arsitek Cloud yang ingin mulai menggunakan fleet di organisasi mereka. Hal ini memberikan beberapa panduan praktis untuk mengatur cluster Anda ke dalam fleet, termasuk:
- Saat Anda ingin membuat cluster yang benar-benar baru.
- Saat Anda ingin membuat fleet dengan cluster yang ada.
Pola yang dijelaskan di sini berlaku untuk banyak organisasi, tetapi pola tersebut bukan satu-satunya cara untuk merencanakan armada. Armada bersifat fleksibel dan Anda dapat memutuskan untuk menggunakan pola pengelompokan yang berbeda untuk cluster Anda.
Anda harus memahami konsep yang tercakup dalam Ringkasan pengelolaan perangkat sebelum membaca panduan ini. Panduan ini juga mengasumsikan bahwa Anda telah memahami konsep dasar Kubernetes dan hierarki resource Google Cloud.
Keterbatasan armada dan sumber daya
Batasan umum berikut berlaku saat membuat fleet:
- Project Google Cloud tertentu hanya dapat memiliki satu fleet (atau tidak ada fleet) yang terkait dengannya, meskipun fleet tersebut dapat mencakup cluster dari beberapa project. Project yang terkait dengan fleet dikenal sebagai project host armada fleet.
- Cluster hanya bisa menjadi anggota fleet tunggal pada waktu tertentu.
- Batas default untuk jumlah cluster dalam fleet adalah 250, meskipun Anda dapat meminta batas yang lebih tinggi jika perlu.
Akan lebih praktis karena berbagai alasan untuk menempatkan beberapa cluster dalam project yang sama. Namun, pertimbangkan batasan berikut ini saat merencanakan cluster yang akan disatukan dalam sebuah project:
- Satu project tidak boleh memiliki lebih dari 32.000 VM. Jika Anda memperkirakan akan membutuhkan lebih banyak VM dari jumlah ini, pertimbangkan untuk menggunakan lebih banyak project.
- Jaringan Virtual Private Cloud (VPC) tidak boleh memiliki lebih dari 75 cluster pribadi.
- Jika Anda berencana menggunakan Multi Cluster Ingress atau Gateway multi-cluster, pertimbangkan batas untuk resource
MultiClusterIngress
danMultiClusterService
dalam sebuah project.
Prinsip umum
Berikut adalah pertanyaan umum yang harus Anda tanyakan saat memutuskan apakah akan mengelompokkan cluster bersama dalam satu fleet. Kita akan melihat bagaimana hal ini berlaku secara lebih mendetail di bagian berikut.
- Apakah sumber daya terkait satu sama lain?
- Resource yang memiliki komunikasi lintas layanan dalam jumlah besar akan mendapatkan manfaat paling besar jika dikelola bersama dalam sebuah armada.
- Resource di lingkungan deployment yang sama (misalnya, lingkungan produksi Anda) harus dikelola bersama dalam sebuah fleet.
- Siapa yang mengelola sumber daya?
- Memiliki kontrol terpadu (atau setidaknya saling tepercaya) atas resource sangat penting untuk memastikan integritas armada.
Merencanakan fleet untuk cluster baru
Bagian ini menjelaskan cara merencanakan fleet jika Anda memiliki sekumpulan aplikasi yang diketahui, tetapi fleksibel dalam hal di mana aplikasi tersebut di-deploy. Hal ini mungkin karena Anda belum mengembangkan aplikasi tersebut, atau sedang memigrasikannya dari platform kontainer lain. Atau, Anda mungkin sudah memiliki aplikasi yang berjalan di cluster yang ada, tetapi terbuka untuk memindahkan aplikasi ke cluster baru untuk mencapai arsitektur pilihan.
Setelah fleet diidentifikasi, Anda dapat membuat project baru per fleet, membuat fleet di setiap project, serta membuat dan mendaftarkan cluster ke fleet yang dimaksud.
Mengaudit workload Anda
Mulailah dengan daftar semua beban kerja Kubernetes (misalnya Deployment) yang ingin Anda deploy. Daftar ini tidak harus berupa daftar secara literal; itu hanya gambaran tentang beban kerja apa yang Anda perlukan. Kemudian, ikuti langkah-langkah di sisa bagian ini untuk secara bertahap membagi kumpulan aplikasi tersebut menjadi subset hingga Anda memiliki set pengelompokan minimal yang diperlukan. Hal ini akan menentukan fleet dan cluster yang Anda butuhkan.
Pertimbangkan unit bisnis
Organisasi Anda mungkin memiliki struktur IT federasi, di mana ada satu tim IT pusat untuk organisasi, serta tim IT terpisah untuk setiap unit bisnis. Dalam hal ini, setiap tim IT yang tergabung mungkin ingin mengelola armadanya sendiri. Gunakan armada terpisah jika dua unit bisnis (misalnya, audit dan perdagangan di bank) tidak dapat saling berkomunikasi sama sekali karena alasan peraturan.
Memisahkan workload berdasarkan lingkungan
Pola umum yang berfungsi untuk banyak organisasi adalah mengelompokkan cluster berdasarkan lingkungan. Konfigurasi umum adalah memiliki tiga lingkungan utama: pengembangan, non-produksi (atau staging), dan produksi. Perubahan aplikasi biasanya di-deploy secara bertahap (atau dipromosikan) ke setiap lingkungan dalam daftar. Oleh karena itu, Anda memiliki deployment terpisah di setiap lingkungan untuk aplikasi dasar yang sama, seperti nama image container dasar yang sama. Lihat Blueprint fondasi perusahaan untuk mengetahui contoh cara membuat lingkungan di organisasi Anda.
Armada hanya boleh berisi cluster dari satu lingkungan. Tiga lingkungan, dengan satu perangkat di setiap lingkungan, mungkin cukup untuk banyak organisasi. Lihat Blueprint aplikasi perusahaan untuk mengetahui contoh yang menunjukkan setiap lingkungan memiliki satu fleet dan cara aplikasi dapat di-deploy secara bertahap.
Menggabungkan instance workload yang redundan
Saat aplikasi membutuhkan ketersediaan tinggi, salah satu polanya adalah menjalankannya di dua atau beberapa region. Untuk itu, diperlukan dua cluster atau lebih yang menjalankan deployment dengan konfigurasi yang sangat mirip dan dikelola sebagai satu unit. Sering kali instance tersebut akan memiliki load balancer yang mencakup instance aplikasi di semua cluster, atau menggunakan load balancing DNS.
Dalam skenario ini, tempatkan semua cluster tersebut ke dalam fleet yang sama. Cluster di region yang berbeda umumnya tidak perlu berada di fleet terpisah, kecuali jika diwajibkan untuk alasan peraturan atau lainnya.
Merencanakan fleet dengan cluster yang ada
Bagian ini menjelaskan cara merencanakan fleet saat Anda memiliki workload yang berjalan di cluster yang ada, dan Anda tidak berencana untuk memindahkannya. Cluster tersebut mungkin berada di dalam atau di luar Google Cloud. Dalam skenario ini, tujuannya adalah untuk membuat satu set fleet dalam organisasi Anda dan menetapkan cluster yang ada kepada mereka.
Setelah fleet diidentifikasi, Anda dapat membuat project baru per fleet, membuat fleet di setiap project, dan mendaftarkan cluster ke fleet yang dimaksud.
Audit cluster Anda
Mulailah dengan daftar semua cluster Kubernetes di organisasi Anda. Inventaris Aset Cloud adalah salah satu cara untuk menelusuri resource cluster Kubernetes di organisasi Anda.
Kemudian, Anda dapat mengikuti langkah-langkah di bagian selanjutnya ini untuk secara bertahap membagi kumpulan aplikasi tersebut menjadi subset hingga Anda memiliki set pengelompokan minimal yang diperlukan. Hal ini akan menentukan armada apa yang Anda butuhkan.
Pertimbangkan unit bisnis
Organisasi Anda mungkin memiliki struktur IT federasi, di mana ada satu tim IT pusat untuk organisasi, serta tim IT terpisah untuk setiap unit bisnis. Tim IT per unit bisnis ini mungkin sudah membuat cluster Anda yang ada. Biasanya dalam hal ini, Anda melakukan partisi kumpulan cluster berdasarkan unit bisnis. Contohnya adalah ketika unit bisnis tertentu (misalnya, audit dan perdagangan di bank) tidak dapat saling berkomunikasi sama sekali karena alasan peraturan.
Jika unit bisnis semata-mata untuk tujuan akuntansi biaya, tetapi menggunakan tim IT yang sama, maka pertimbangkan untuk menggabungkan cluster mereka dalam satu perangkat, terutama jika ada ketergantungan antar-layanan yang signifikan di seluruh unit bisnis.
Mengelompokkan cluster berdasarkan lingkungan
Mengidentifikasi lingkungan yang digunakan di organisasi Anda. Nama lingkungan yang umum adalah dev, non-production (atau staging), dan prod.
Jika setiap cluster jelas hanya berada di salah satu lingkungan Anda, pisahkan daftar cluster Anda berdasarkan lingkungan. Namun, jika beberapa cluster berisi workload yang secara logis dimiliki oleh lingkungan yang berbeda, sebaiknya Anda men-deploy ulang aplikasi ke dalam cluster yang hanya berisi aplikasi yang dimiliki oleh satu lingkungan logis.
Meminimalkan jumlah pemilik cluster
Saat menggabungkan project yang ada ke dalam fleet, mungkin terdapat kumpulan pengguna berbeda yang diizinkan untuk bertindak sebagai administrator di cluster tersebut, dengan mempertimbangkan kebijakan IAM (container.admin
) dan RBAC (admin ClusterRoleBinding). Jika Anda berencana menggunakan fitur yang memerlukan kesamaan, sasarannya adalah mendapatkan semua cluster yang memiliki sekumpulan admin yang sama, dan menyediakan sekelompok kecil admin untuk seluruh perangkat. Jika cluster harus memiliki admin yang berbeda, dan tujuannya adalah menggunakan fitur yang memerlukan kesamaan, cluster tersebut mungkin tidak termasuk dalam perangkat yang sama.
Misalnya, jika cluster C1 dan C2 memiliki admin berbeda yang tidak saling percaya, dan tidak bersedia membagikan izin admin ke tim platform pusat yang mengelola fleet, maka cluster tersebut tidak boleh dikelompokkan bersama dalam satu fleet.
Anda dapat mempelajari lebih lanjut kesamaan dan fitur mana yang memerlukannya dalam Cara kerja fleet.
Mempertimbangkan fitur fleet
Terlepas dari apakah Anda bekerja dengan klaster baru atau yang sudah ada, fitur perangkat yang Anda pilih juga dapat memengaruhi pengaturan perangkat yang optimal. Misalnya, jika memilih untuk menggunakan Workload Identity Federation seluruh fleet, Anda mungkin ingin mengatur fleet dengan cara yang meminimalkan risiko saat menyiapkan autentikasi workload di seluruh fleet, atau jika ingin menggunakan Cloud Service Mesh, Anda mungkin memerlukan cluster tertentu untuk berada di fleet yang sama. Jika Anda menggunakan Virtual Private Cloud (VPC), beberapa fitur memerlukan penggunaan VPC tunggal per fleet.
Anda dapat mengetahui lebih lanjut cara mengadopsi fitur fleet serta persyaratan dan batasannya dalam panduan berikutnya dalam seri ini, Fitur fleet rencana.
Mempertimbangkan perimeter VPC
Masalah lain yang perlu dipertimbangkan untuk cluster baru dan yang sudah ada adalah jika Anda telah memilih atau ingin membuat jaringan pribadi sendiri di Google Cloud dengan Virtual Private Cloud (VPC). Cluster dalam perimeter VPC (misalnya pada VPC Bersama yang memiliki Kontrol Layanan VPC), dapat berada dalam satu fleet. Jika Anda memiliki VPC Bersama yang dibatasi dan tidak dibatasi, praktik yang baik adalah menempatkannya ke dalam fleet yang terpisah.
Jika Anda berencana menggunakan perimeter Kontrol Layanan VPC, biasanya beberapa workload berada dalam perimeter dan beberapa di luarnya. Anda harus merencanakan untuk memiliki versi Kontrol Layanan VPC dan Kontrol Layanan non-VPC dari setiap fleet di setiap lingkungan (atau setidaknya produksi dan lingkungannya tepat sebelum produksi).
Saat merencanakan fleet dengan VPC, beberapa fitur fleet memiliki persyaratan VPC spesifik, misalnya mewajibkan semua cluster yang menggunakannya berada dalam jaringan VPC yang sama.
Langkah selanjutnya
- Dapatkan praktik terbaik untuk menambahkan fitur ke perangkat Anda di Fitur fleet rencana.
- Pelajari lebih lanjut cara kerja fleet di Cara kerja fleet.
- Mulai buat fleet dengan mengikuti Ringkasan pembuatan fleet