Dokumen ini menjelaskan hierarki resource Google Distributed Cloud (GDC) dengan air gap dan cara resource dikelola dalam instance dengan air gap. Untuk konsep tentang mengelola resource di beberapa zona, lihat Ringkasan multi-zona.
Tujuan hierarki resource GDC ada dua:
- Memberikan hierarki kepemilikan, yang mengikat siklus proses resource ke induk langsungnya dalam hierarki.
- Menyediakan titik lampiran dan pewarisan untuk kontrol akses dan kebijakan organisasi.
Hierarki resource GDC menyerupai sistem file yang ditemukan dalam sistem operasi sebagai cara untuk mengatur dan mengelola entity secara hierarkis. Umumnya, setiap resource memiliki tepat satu induk. Organisasi hierarkis resource ini memungkinkan Anda menetapkan kebijakan kontrol akses, seperti Identity and Access Management (IAM), yang diwarisi oleh resource turunan.
Untuk mengetahui informasi selengkapnya tentang praktik terbaik dalam mengatur batas akses, lihat Mendesain batas akses antar-resource.
Struktur resource secara mendetail
Entity berikut adalah jenis resource yang dikenali dalam hierarki resource GDC:
Resource GDC diatur secara hierarkis. Sebagian besar resource dalam hierarki resource memiliki tepat satu induk. Pengecualian hanya berlaku untuk resource tertinggi. Pada level terendah, resource layanan adalah komponen dasar yang membentuk semua layanan GDC.
Organisasi adalah puncak hierarki resource GDC, dan semua resource yang menjadi milik organisasi dikelompokkan dalam resource organisasi. Hal ini memberikan visibilitas dan kontrol terpusat atas setiap resource yang dimiliki organisasi.
Project dan cluster Kubernetes bersama memiliki cakupan organisasi. Tag dapat dilampirkan satu sama lain untuk mengatur resource layanan. Namun, project dan cluster bersama berfungsi secara independen satu sama lain. Fleksibilitas ini memberikan banyak opsi berbeda untuk mengatur layanan dan workload. Misalnya, Anda dapat memiliki cluster bersama yang dikhususkan untuk satu project. Demikian pula, cluster bersama dapat mencakup beberapa project.
Resource layanan adalah entity yang harus dimiliki oleh project, dan tidak dapat dibagikan di seluruh project. Contoh resource layanan mencakup virtual machine (VM), cluster Kubernetes standar, database, bucket penyimpanan, dan cadangan. Sebagian besar resource level rendah ini memiliki resource project sebagai induknya.
Diagram berikut menunjukkan contoh hierarki resource GDC:

Untuk mengetahui informasi selengkapnya tentang praktik terbaik dalam mengatur hierarki resource untuk pengelolaan workload yang optimal, lihat Mendesain pemisahan workload pengguna.
Organisasi
Resource organisasi mewakili unit administratif atau fungsi bisnis, seperti perusahaan, dan merupakan resource tingkat teratas dalam hierarki resource GDC. Organisasi menentukan batas keamanan yang mencakup resource infrastruktur yang akan dikelola bersama sehingga pengguna dapat men-deploy workload aplikasi. Organisasi bersifat global dan mencakup semua zona di universe. Dalam organisasi, resource layanan seperti VM dan volume penyimpanan dikelompokkan secara logis berdasarkan project.
Semua project, cluster, dan resource layanan adalah milik organisasi Anda, bukan milik pembuatnya. Artinya, jenis resource apa pun untuk organisasi tidak akan dihapus jika pengguna yang membuatnya keluar dari organisasi. Sebagai gantinya, semua jenis resource mengikuti siklus proses organisasi di GDC.
Kebijakan kontrol akses IAM yang diterapkan ke resource organisasi berlaku di seluruh hierarki pada semua resource dalam organisasi. Untuk mengetahui informasi selengkapnya tentang cara memberikan kebijakan dan izin di seluruh organisasi, lihat bagian Kebijakan organisasi dan IAM.
Project
Project adalah unit tenancy yang harus diintegrasikan oleh setiap layanan. Project menyediakan pengelompokan logis resource layanan. Project bersifat global dan mencakup semua zona di universe.
Project memungkinkan segmentasi resource layanan dalam organisasi serta menyediakan siklus proses dan batas kebijakan untuk mengelola resource. Resource layanan di dalam project tidak akan pernah bertahan lebih lama dari project itu sendiri atau berpindah antar-project, sehingga memastikan bahwa kontrol tersedia selama masa aktif resource. Oleh karena itu, Anda harus men-deploy resource dari jenis apa pun dalam namespace project.
Project dianggap sebagai namespace Kubernetes yang tepat yang mencakup beberapa cluster bersama dalam sebuah organisasi. Kesamaan namespace menganggap semua namespace dengan nama tertentu sebagai namespace yang sama untuk semua cluster bersama dalam organisasi yang sama. Namespace tunggal memiliki pemilik yang konsisten di seluruh kumpulan cluster bersama. Penyedia layanan membuat layanan cakupan project dengan membuat komponen bidang kontrol dan bidang data di namespace.
Namespace untuk project menghosting hal berikut:
- API layanan cakupan project.
- Konfigurasi kebijakan level project, seperti peran dan binding peran.
Anda hanya dapat melampirkan project ke subset cluster bersama dalam organisasi. Anda dapat men-deploy workload dalam container di cluster bersama ini dalam namespace project. Konsep kesamaan namespace berlaku untuk namespace project di cluster bersama ini. Kebijakan cakupan namespace, seperti kebijakan kontrol akses berbasis peran (RBAC), berlaku untuk semua namespace tersebut.
Untuk mengetahui informasi selengkapnya tentang project, lihat Ringkasan project.
Cluster Kubernetes bersama
Cluster Kubernetes adalah sekumpulan node yang menjalankan workload dalam container sebagai bagian dari GKE di GDC. Anda dapat menyediakan cluster Kubernetes untuk mendukung persyaratan komputasi aplikasi Anda.
Cluster bersama adalah konfigurasi cluster yang tercakup dalam organisasi, dan harus dilampirkan ke satu atau beberapa project. Cluster standar adalah konfigurasi cluster lain yang hanya beroperasi dalam satu project, tetapi dianggap sebagai resource layanan dalam hierarki resource. Konfigurasi cluster Kubernetes ini dirancang untuk membangun arsitektur Kubernetes yang menawarkan opsi pengelolaan container di seluruh lingkungan pengembangan software, seperti untuk pengujian, pengembangan, dan produksi. Untuk mengetahui informasi selengkapnya tentang praktik terbaik pemisahan workload container, lihat Mendesain pemisahan workload.
Untuk mengetahui informasi selengkapnya tentang berbagai jenis cluster di GDC, lihat Konfigurasi cluster Kubernetes.

Cluster bersama membagi resource infrastruktur menjadi kumpulan terisolasi untuk digunakan oleh project dalam organisasi. Cluster juga dipisahkan secara logis satu sama lain untuk memberikan domain kegagalan dan jaminan isolasi yang berbeda. Penerapan kebijakan per organisasi memastikan cluster bersama dapat digunakan bersama oleh berbagai tim dan pengguna, sekaligus mempertahankan jaminan performa dan resource. Selain itu, kebijakan organisasi memungkinkan workload VM berjalan bersama workload container tanpa menimbulkan kompleksitas operasional.
Cluster bermanfaat untuk instance tempat Anda harus men-deploy workload dalam container. Namun, dengan opsi untuk men-deploy workload berbasis VM, keberadaan cluster Kubernetes tidak diperlukan di GDC.
Cluster hanya merupakan resource zona dan tidak dapat mencakup beberapa zona. Untuk mengoperasikan cluster dalam deployment multi-zona, Anda harus men-deploy cluster secara manual di setiap zona.
Untuk mengetahui informasi selengkapnya tentang cluster Kubernetes, lihat Ringkasan cluster Kubernetes.
Resource layanan
Resource layanan mencakup banyak entity, seperti:
- VM
- Cluster Kubernetes standar
- Database
- Bucket penyimpanan
- Workload dalam container
- Cadangan
Resource layanan harus dimiliki oleh satu project, dan tidak dapat dibagikan di beberapa project. Siklus proses khusus project ini berarti bahwa resource layanan di dalam project tidak akan pernah bertahan lebih lama dari project itu sendiri, sehingga memastikan bahwa kontrol tersedia selama masa aktif resource.
Resource layanan dapat di-deploy secara global atau zonal, bergantung pada jenisnya. Lihat dokumentasi layanan tertentu untuk mengetahui informasi tentang opsi deployment multi-zona. Resource layanan diaktifkan secara default dan dapat dinonaktifkan menggunakan kebijakan organisasi.