Dokumen ini memperkenalkan praktik terbaik untuk merancang hierarki dan pemisahan workload dalam lingkungan air-gapped Google Distributed Cloud (GDC) menggunakan organisasi, project, dan cluster Kubernetes. Panduan ini menyeimbangkan penggunaan resource yang efisien, pengisolasian beban kerja, dan kemudahan operasi.
Mendesain organisasi untuk isolasi fisik dan logis antar-pelanggan
Resource Organization adalah root untuk semua resource yang dimiliki oleh satu
pelanggan. Kontrol akses terperinci antara workload dalam organisasi dapat
ditentukan melalui pengikatan peran dan kebijakan jaringan. Lihat
Identity and access management untuk mengetahui informasi selengkapnya.
Setiap organisasi dalam zona GDC menyediakan isolasi fisik untuk infrastruktur komputasi, dan isolasi logis untuk jaringan, penyimpanan, dan layanan lainnya. Pengguna di satu organisasi tidak memiliki akses ke resource di organisasi lain kecuali jika diberi akses secara eksplisit. Konektivitas jaringan dari satu organisasi ke organisasi lain tidak diizinkan secara default, kecuali dikonfigurasi secara eksplisit untuk mengizinkan transfer data keluar dari satu organisasi dan transfer data masuk ke organisasi lain.
Menentukan cakupan workload yang dapat berbagi organisasi
Cakupan organisasi dalam konteks perusahaan Anda dapat bervariasi berdasarkan cara perusahaan Anda menentukan batas kepercayaan. Beberapa perusahaan mungkin lebih memilih untuk membuat beberapa resource organisasi untuk entitas yang berbeda dalam perusahaan. Misalnya, setiap departemen perusahaan dapat menjadi pelanggan GDC independen dengan organisasi independen jika departemen tersebut memerlukan pemisahan fisik dan administratif yang lengkap untuk workload-nya.
Secara umum, sebaiknya Anda mengelompokkan beberapa beban kerja ke dalam satu organisasi berdasarkan sinyal berikut:
- Workload dapat berbagi dependensi. Misalnya, ini bisa berupa sumber data bersama, konektivitas antar-workload, atau alat pemantauan bersama.
- Workload dapat berbagi root tepercaya administratif. Administrator yang sama dapat dipercaya untuk memiliki akses istimewa ke semua beban kerja dalam organisasi.
- Beban kerja diizinkan untuk berbagi infrastruktur fisik yang mendasarinya dengan beban kerja lain dalam organisasi yang sama, selama pemisahan logis yang memadai diterapkan.
- Pemegang anggaran yang sama memiliki akuntabilitas untuk anggaran beban kerja secara keseluruhan. Untuk mengetahui detail tentang cara melihat biaya gabungan untuk organisasi atau analisis terperinci per workload, lihat halaman Penagihan.
- Persyaratan ketersediaan workload harus mengikuti persyaratan ketersediaan tinggi Anda untuk jarak multi-zona.
Mendesain project untuk isolasi logis antar-workload
Dalam organisasi, sebaiknya sediakan beberapa project untuk membuat pemisahan logis antar-resource. Project dalam organisasi yang sama dapat berbagi infrastruktur fisik yang mendasarinya, tetapi project digunakan untuk memisahkan beban kerja dengan batas logis berdasarkan kebijakan Identity and Access Management (IAM) dan kebijakan jaringan.
Saat mendesain batas project, pikirkan kumpulan fungsi terbesar yang dapat dibagikan oleh resource, seperti binding peran, kebijakan jaringan, atau persyaratan kemampuan observasi. Kelompokkan resource yang dapat berbagi fungsi ini ke dalam project, dan pindahkan resource yang tidak dapat berbagi fungsi ini ke project lain.
Dalam istilah Kubernetes, project adalah namespace Kubernetes yang dicadangkan di semua cluster dalam organisasi. Meskipun namespace dicadangkan di beberapa cluster, hal itu tidak berarti pod dijadwalkan secara otomatis di semua cluster. Pod yang dijadwalkan ke cluster tertentu tetap dijadwalkan ke cluster tersebut.
Diagram berikut menunjukkan cara penerapan binding peran ke project yang mencakup beberapa cluster.
Binding peran ditetapkan di tingkat project untuk menentukan siapa yang dapat melakukan tindakan apa pada jenis resource mana. Workload seperti VM atau pod di-deploy ke project, dan akses ke workload ini diatur oleh pengikatan peran. Pengikatan peran berlaku secara konsisten untuk workload berbasis VM dan workload berbasis container, terlepas dari cluster tempat workload tersebut di-deploy.
Diagram berikut menunjukkan cara kebijakan jaringan mengelola akses antar-project.
Komunikasi antar-project antara Backend Project, Frontend Project,
dan Database Project dinonaktifkan. Namun, resource dalam setiap project dapat
berkomunikasi satu sama lain.
Kebijakan jaringan ditetapkan di level project untuk mengizinkan akses jaringan antar-resource secara selektif. Secara default, semua resource dalam satu project diizinkan untuk berkomunikasi satu sama lain di jaringan internal, dan resource dalam satu project tidak dapat berkomunikasi dengan resource dalam project lain. Perilaku kebijakan jaringan ini berlaku terlepas dari apakah resource di-deploy ke cluster yang sama atau tidak.
Anda juga dapat menentukan resource kustom ProjectNetworkPolicy untuk mengaktifkan
komunikasi antar-project. Kebijakan ini ditentukan untuk setiap project guna mengizinkan traffic ingress dari project lain. Diagram berikut menggambarkan resource kustom ProjectNetworkPolicy yang ditentukan untuk Backend Project guna mengaktifkan transfer data dari Frontend Project dan Database Project.
Selain itu, stack pemantauan mengumpulkan metrik di seluruh organisasi, tetapi Anda dapat memfilter dan membuat kueri di berbagai tingkat hierarki resource. Anda dapat membuat kueri metrik dengan entitas seperti cluster atau namespace.
Membuat project per lingkungan deployment
Untuk setiap workload, sebaiknya buat project terpisah untuk produksi, pengembangan, dan lingkungan deployment lain yang Anda perlukan. Dengan memisahkan lingkungan deployment produksi dan pengembangan, Anda dapat menentukan pengikatan peran dan kebijakan jaringan secara terperinci, sehingga perubahan yang dilakukan dalam project yang digunakan untuk pengembangan tidak memengaruhi lingkungan produksi.
Memberikan binding peran tingkat resource dalam project
Bergantung pada struktur dan persyaratan tim, Anda dapat mengizinkan developer untuk mengubah resource apa pun dalam project yang mereka kelola, atau Anda dapat mewajibkan kontrol akses yang lebih terperinci. Dalam project, Anda memberikan binding peran terperinci untuk memungkinkan masing-masing developer mengakses beberapa, tetapi tidak semua resource dalam project. Misalnya, tim mungkin memiliki administrator database yang harus mengelola database, tetapi tidak boleh mengubah resource lain, sementara developer software dalam tim tidak boleh memiliki izin untuk mengubah database.
Mendesain cluster untuk isolasi logis operasi Kubernetes
Cluster Kubernetes bukanlah batas tenant yang ketat karena binding peran dan kebijakan jaringan berlaku untuk project, bukan cluster Kubernetes. Cluster dan project Kubernetes memiliki hubungan many-to-many. Anda mungkin memiliki beberapa cluster Kubernetes dalam satu project, atau satu cluster Kubernetes yang mencakup beberapa project.