Dokumen ini memperkenalkan praktik terbaik untuk mendesain hierarki dan pemisahan workload di Google Distributed Cloud (GDC) yang terisolasi menggunakan organisasi, project, dan cluster Kubernetes. Panduan ini menyeimbangkan penggunaan resource yang efisien, isolasi workload, 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 binding 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 jika 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 mungkin bervariasi berdasarkan cara perusahaan Anda menentukan batas kepercayaan. Beberapa perusahaan mungkin lebih memilih membuat beberapa resource organisasi untuk entity yang berbeda di perusahaan. Misalnya, setiap departemen perusahaan mungkin merupakan pelanggan GDC independen dengan organisasi independen jika departemen tersebut memerlukan pemisahan fisik dan administratif yang lengkap untuk workload-nya.
Secara umum, sebaiknya kelompokkan beberapa workload ke dalam satu organisasi berdasarkan sinyal berikut:
- Workload dapat berbagi dependensi. Misalnya, ini mungkin merupakan sumber data bersama, konektivitas antar-workload, atau alat pemantauan bersama.
- Workload dapat berbagi root kepercayaan administratif. Administrator yang sama dapat dipercaya dengan akses istimewa atas semua workload dalam organisasi.
- Workload diizinkan untuk berbagi infrastruktur fisik yang mendasarinya dengan workload lain dalam organisasi yang sama, selama pemisahan logis yang memadai diterapkan.
- Pemegang anggaran yang sama memiliki tanggung jawab atas anggaran workload secara agregat. Untuk mengetahui detail tentang cara melihat biaya agregat 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 mungkin berbagi infrastruktur fisik yang mendasarinya, tetapi project digunakan untuk memisahkan workload 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 observabilitas persyaratan. 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 ini tidak berarti pod otomatis dijadwalkan di semua cluster. Pod yang dijadwalkan ke cluster tertentu tetap dijadwalkan ke cluster tertentu tersebut.
Diagram berikut menunjukkan cara binding peran diterapkan ke project yang mencakup beberapa cluster.
Binding peran ditetapkan di tingkat project untuk menentukan siapa yang dapat melakukan tindakan tertentu pada jenis resource tertentu. Workload seperti VM atau pod di-deploy ke project, dan akses ke workload ini diatur oleh binding peran. Binding peran berlaku secara konsisten untuk workload berbasis VM dan workload berbasis container, terlepas dari cluster mana yang 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 tingkat 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 di project lain. Perilaku untuk 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 masuk dari project lain. Diagram berikut menggambarkan resource kustom ProjectNetworkPolicy yang ditentukan untuk Backend Project guna mengaktifkan transfer data masuk 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 entity seperti cluster atau namespace.
Membuat project per lingkungan pengembangan software
Untuk setiap workload, sebaiknya buat project terpisah untuk setiap lingkungan pengembangan software. Lingkungan pengembangan software adalah area dalam GDC universe yang ditujukan untuk semua operasi yang sesuai dengan fase siklus proses yang ditentukan. Misalnya, Anda dapat memiliki lingkungan pengembangan software untuk pengujian, pengembangan, dan produksi. Dengan memisahkan lingkungan pengembangan software, Anda dapat menentukan binding peran dan kebijakan jaringan secara terperinci, sehingga perubahan yang dilakukan dalam project yang digunakan untuk lingkungan non-produksi tidak memengaruhi lingkungan produksi.
Memberikan binding peran tingkat resource dalam project
Bergantung pada struktur dan persyaratan tim Anda, Anda dapat mengizinkan developer mengubah resource apa pun dalam project yang mereka kelola, atau Anda mungkin memerlukan kontrol akses yang lebih terperinci. Dalam project, Anda memberikan binding peran terperinci untuk mengizinkan developer mengakses beberapa, tetapi tidak semua resource dalam project. Misalnya, tim mungkin memiliki administrator database yang harus mengelola database tetapi tidak mengubah resource lain, sementara developer software di tim tidak boleh memiliki izin untuk mengubah database.
Mendesain cluster untuk isolasi logis operasi Kubernetes
Cluster Kubernetes bukanlah batas tenant yang sulit 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.