Dokumen ini memperkenalkan praktik terbaik untuk mendesain hierarki dan pemisahan workload di Google Distributed Cloud (GDC) dengan air gap 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, serta 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 untuk membuat beberapa resource organisasi untuk berbagai entitas dalam perusahaan. Misalnya, setiap departemen perusahaan mungkin merupakan pelanggan independen GDC dengan organisasi independen jika departemen tersebut memerlukan pemisahan fisik dan administratif yang lengkap untuk workload mereka.
Secara umum, sebaiknya Anda mengelompokkan beberapa workload ke dalam satu organisasi berdasarkan sinyal berikut:
- Workload dapat berbagi dependensi. Misalnya, ini mungkin berupa sumber data bersama, konektivitas antar-workload, atau alat pemantauan bersama.
- Workload dapat berbagi root of trust 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, asalkan ada pemisahan logis yang memadai.
- Pemegang anggaran yang sama memiliki akuntabilitas untuk anggaran workload secara agregat. 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 sebuah 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 set 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 otomatis dijadwalkan di semua cluster. Pod yang dijadwalkan ke cluster tertentu akan tetap dijadwalkan ke cluster tertentu tersebut.
Diagram berikut menunjukkan cara binding peran diterapkan ke project yang mencakup beberapa cluster.
Binding peran ditetapkan di level 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 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 di project lain. Perilaku kebijakan jaringan ini berlaku baik resource di-deploy ke cluster yang sama maupun 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 mengilustrasikan
resource kustom ProjectNetworkPolicy yang ditentukan untuk Backend Project guna
memungkinkan 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 universe GDC Anda yang ditujukan untuk semua operasi yang sesuai dengan fase siklus proses yang ditetapkan. 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 dibuat dalam project yang digunakan untuk lingkungan non-produksi tidak memengaruhi lingkungan produksi.
Memberikan binding peran level 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 mungkin memerlukan kontrol akses yang lebih terperinci. Dalam sebuah project, Anda memberikan binding peran terperinci untuk memungkinkan developer individu mengakses beberapa, tetapi tidak semua resource dalam project. Misalnya, sebuah tim mungkin memiliki administrator database yang harus mengelola database, tetapi tidak mengubah resource lain, sedangkan 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.