Panduan ini menjelaskan arsitektur referensi yang digunakan untuk men-deploy Google Distributed Cloud (khusus software) on bare metal. Panduan ini ditujukan bagi administrator platform yang ingin menggunakan GKE Enterprise di platform bare metal dalam konfigurasi dengan ketersediaan tinggi dan redundan secara geografis. Untuk memahami panduan ini dengan lebih baik, Anda harus memahami konsep dasar GKE Enterprise, seperti yang diuraikan dalam ringkasan teknis GKE Enterprise. Anda juga harus memiliki pemahaman dasar tentang konsep Kubernetes dan Google Kubernetes Engine (GKE), seperti yang dijelaskan dalam Mempelajari Dasar-Dasar Kubernetes dan dokumentasi GKE.
Panduan ini memiliki repositori sumber GitHub yang menyertakan skrip yang dapat Anda gunakan untuk men-deploy arsitektur yang dijelaskan. Panduan ini juga menjelaskan komponen arsitektur yang berisi skrip dan modul yang digunakan untuk membuat komponen tersebut. Sebaiknya gunakan file ini sebagai template untuk membuat modul yang menggunakan kebijakan dan praktik terbaik organisasi Anda.
Model arsitektur
Dalam panduan GKE Enterprise Architecture Foundation, arsitektur platform dijelaskan secara berlapis. Resource di setiap lapisan menyediakan serangkaian fungsi tertentu. Resource ini dimiliki dan dikelola oleh satu atau beberapa persona. Seperti yang ditunjukkan pada diagram berikut, arsitektur platform GKE Enterprise untuk bare metal terdiri dari lapisan dan resource berikut:
- Infrastruktur: Lapisan ini mencakup penyimpanan, komputasi, dan jaringan, yang ditangani dengan konstruksi on-premise.
- Pengelolaan data: Untuk tujuan panduan ini, lapisan pengelolaan data memerlukan database SQL yang dikelola di luar cluster Kubernetes yang di-deploy.
- Lapisan pengelolaan penampung: Lapisan ini menggunakan cluster GKE.
- Lapisan Pengelolaan Layanan: Lapisan ini menggunakan Cloud Service Mesh.
- Lapisan Pengelolaan Kebijakan: Lapisan ini menggunakan Config Sync dan Policy Controller.
- Lapisan pengelolaan aplikasi: Lapisan ini menggunakan Cloud Build dan Cloud Source Repositories.
- Lapisan kemampuan observasi: Lapisan ini menggunakan dasbor Google Cloud Observability dan Cloud Service Mesh.
Setiap lapisan ini diulang di seluruh stack untuk berbagai lingkungan siklus proses, seperti pengembangan, staging, dan produksi.
Bagian berikut hanya mencakup informasi tambahan yang khusus untuk deployment bare metal. Panduan ini dibuat berdasarkan bagian masing-masing di panduan Dasar-Dasar Arsitektur GKE Enterprise. Sebaiknya Anda meninjau panduan tersebut saat membaca artikel ini.
Jaringan
Untuk mengetahui informasi selengkapnya tentang persyaratan jaringan, lihat Persyaratan jaringan.
Untuk load balancer Google Distributed Cloud, ada dua opsi yang tersedia: paket dan manual.
Dalam mode paket, software load balancing L4 di-deploy selama pembuatan cluster. Proses load balancer dapat berjalan pada kumpulan worker node khusus, atau pada node yang sama dengan bidang kontrol. Untuk mengiklankan alamat IP virtual (VIP), load balancer ini memiliki dua opsi:
- Address Resolution Protocol (ARP): Memerlukan konektivitas lapisan 2 antara node yang menjalankan load balancer.
- Border Gateway Protocol (BGP): Menggunakan peering untuk menghubungkan jaringan cluster Anda, yang merupakan sistem otonom, dengan sistem otonom lainnya, seperti jaringan eksternal.
Dalam mode manual, Anda mengonfigurasi solusi load balancing Anda sendiri untuk traffic bidang kontrol dan bidang data. Ada banyak opsi hardware dan software yang tersedia untuk load balancer eksternal. Anda harus menyiapkan load balancer eksternal untuk bidang kontrol sebelum membuat cluster bare metal. Load balancer bidang kontrol eksternal juga dapat digunakan untuk traffic bidang data, atau Anda dapat menyiapkan load balancer terpisah untuk bidang data. Untuk menentukan ketersediaan, load balancer harus dapat mendistribusikan traffic ke kumpulan node berdasarkan pemeriksaan kesiapan yang dapat dikonfigurasi.
Untuk informasi selengkapnya tentang load balancer untuk deployment bare metal, lihat Ringkasan load balancer.
Arsitektur cluster
Google Distributed Cloud mendukung beberapa model deployment di bare metal, yang memenuhi berbagai kebutuhan ketersediaan, isolasi, dan jejak resource. Model deployment ini dibahas di Memilih model deployment.
Pengelolaan identitas
Google Distributed Cloud menggunakan Identity Service GKE untuk berintegrasi dengan penyedia identitas. Layanan ini mendukung OpenID Connect (OIDC) dan Lightweight Directory Access Protocol (LDAP). Untuk aplikasi dan layanan, Cloud Service Mesh dapat digunakan dengan berbagai solusi identitas.
Untuk informasi selengkapnya tentang pengelolaan identitas, lihat Pengelolaan identitas dengan OIDC di Google Distributed Cloud dan Mengautentikasi dengan OIDC atau, Menyiapkan GKE Identity Service dengan LDAP.
Pengelolaan keamanan dan kebijakan
Untuk pengelolaan kebijakan dan keamanan Google Distributed Cloud, sebaiknya gunakan Config Sync dan Policy Controller. Pengontrol Kebijakan memungkinkan Anda membuat dan menerapkan kebijakan di seluruh cluster. Sinkronisasi Konfigurasi mengevaluasi perubahan dan menerapkannya ke semua cluster untuk mencapai status yang sesuai.
Layanan
Saat menggunakan mode paket Google Distributed Cloud untuk load
balancing dalam deployment bare metal, Anda dapat membuat
layanan jenis LoadBalancer. Saat Anda membuat layanan ini, Google Distributed Cloud akan menetapkan alamat IP dari kumpulan alamat IP load balancer yang dikonfigurasi ke layanan. Jenis layanan LoadBalancer digunakan untuk mengekspos layanan Kubernetes di luar cluster untuk traffic utara-selatan.
Saat menggunakan Google Distributed Cloud, IngressGateway juga dibuat dalam cluster secara default. Anda tidak dapat membuat layanan jenis LoadBalancer
untuk Google Distributed Cloud dalam mode manual. Sebagai gantinya, Anda
dapat membuat objek
Ingress
yang menggunakan IngressGateway atau membuat
layanan jenis
NodePort dan mengonfigurasi load balancer eksternal secara manual untuk menggunakan
layanan Kubernetes sebagai backend.
Untuk Pengelolaan Layanan, yang juga disebut sebagai traffic east-west, sebaiknya gunakan Cloud Service Mesh. Cloud Service Mesh didasarkan pada API terbuka Istio dan menyediakan kemampuan observasi, autentikasi, enkripsi, kontrol traffic terperinci, serta fitur dan fungsi lainnya yang seragam. Untuk mengetahui informasi selengkapnya tentang Pengelolaan Layanan, lihat Cloud Service Mesh.
Pengelolaan status dan persistensi
Google Distributed Cloud di bare metal sebagian besar bergantung pada infrastruktur yang ada untuk penyimpanan sementara, penyimpanan volume, dan penyimpanan PersistentVolume. Data efemeral menggunakan resource disk lokal pada node tempat Pod Kubernetes dijadwalkan. Untuk data persisten, GKE Enterprise kompatibel dengan Container Storage Interface (CSI), API standar terbuka yang didukung oleh banyak vendor penyimpanan. Untuk penyimpanan produksi, sebaiknya instal driver CSI dari partner penyimpanan GKE Enterprise Ready. Untuk mengetahui listingan lengkap partner penyimpanan GKE Enterprise Ready, lihat Partner penyimpanan GKE Enterprise Ready.
Untuk informasi selengkapnya tentang penyimpanan, lihat Mengonfigurasi penyimpanan.
Database
Google Distributed Cloud tidak menyediakan kemampuan khusus database tambahan di luar kemampuan standar platform GKE Enterprise. Sebagian besar database berjalan pada sistem manajemen data eksternal. Beban kerja di platform GKE Enterprise juga dapat dikonfigurasi untuk terhubung ke database eksternal yang dapat diakses.
Kemampuan observasi
Google Cloud Observability mengumpulkan log dan metrik pemantauan untuk cluster Google Distributed Cloud dengan cara yang mirip dengan kebijakan pengumpulan dan pemantauan cluster GKE. Secara default, log cluster dan metrik komponen sistem dikirim ke Cloud Monitoring.
Agar Google Cloud Observability mengumpulkan log dan metrik aplikasi, aktifkan opsi clusterOperations.enableApplication di file YAML konfigurasi cluster.
Untuk mengetahui informasi selengkapnya tentang kemampuan observasi, lihat Mengonfigurasi logging dan pemantauan.
Kasus penggunaan: Deployment Cymbal Bank
Untuk panduan ini, aplikasi Cymbal Bank/Bank of Anthos digunakan untuk melakukan simulasi proses perencanaan, deployment platform, dan deployment aplikasi untuk Google Distributed Cloud on bare metal.
Bagian lain dokumen ini terdiri dari tiga bagian. Bagian Perencanaan menguraikan keputusan yang dibuat berdasarkan opsi yang dibahas di bagian model arsitektur. Bagian Deployment platform membahas skrip dan modul yang disediakan oleh repositori sumber untuk men-deploy platform GKE Enterprise. Terakhir, di bagian Deployment aplikasi, aplikasi Cymbal Bank di-deploy di platform.
Panduan Google Distributed Cloud ini dapat digunakan untuk men-deploy ke instance instance Compute Engine atau host mandiri. Dengan menggunakan resource Google Cloud, siapa pun dapat menyelesaikan panduan ini tanpa memerlukan akses ke hardware fisik. Penggunaan instance Compute Engine hanya untuk tujuan demonstrasi. JANGAN gunakan instance ini untuk beban kerja produksi. Jika akses ke hardware fisik tersedia dan rentang alamat IP yang sama digunakan, Anda dapat menggunakan repositori sumber yang disediakan apa adanya. Jika lingkungan berbeda dengan yang diuraikan di bagian Perencanaan, Anda dapat mengubah skrip dan modul untuk mengakomodasi perbedaan tersebut. Repositori sumber terkait berisi petunjuk untuk hardware fisik dan skenario instance Compute Engine.
Perencanaan
Bagian berikut menjelaskan keputusan arsitektur yang dibuat saat merencanakan dan mendesain platform untuk deployment aplikasi GKE Enterprise Bank of America di Google Distributed Cloud. Bagian ini berfokus pada lingkungan produksi. Untuk mem-build lingkungan yang lebih rendah, seperti pengembangan atau staging, Anda dapat menggunakan langkah-langkah serupa.
Project Google Cloud
Saat membuat project di Google Cloud untuk Google Distributed Cloud, diperlukan project host armada. Project tambahan direkomendasikan untuk setiap lingkungan atau fungsi bisnis. Konfigurasi project ini memungkinkan Anda mengatur resource berdasarkan persona yang berinteraksi dengan resource.
Subbagian berikut membahas jenis project yang direkomendasikan dan persona yang terkait dengannya.
Project hub
Project hub hub-prod ditujukan untuk persona
administrator jaringan. Project ini adalah tempat pusat data lokal terhubung ke
Google Cloud menggunakan bentuk konektivitas campuran yang Anda pilih. Untuk mengetahui informasi selengkapnya tentang opsi konektivitas hybrid, lihat Konektivitas Google Cloud
Project host fleet
Project host fleet
fleet-prod ditujukan untuk persona
administrator platform. Project ini adalah tempat
cluster Google Distributed Cloud didaftarkan. Project ini juga
adalah tempat resource Google Cloud terkait platform berada. Resource ini mencakup Google Cloud Observability, Cloud Source Repositories, dan lainnya. Project Google Cloud tertentu hanya dapat memiliki satu fleet (atau tidak ada fleet) yang terkait dengannya. Pembatasan ini memperkuat penggunaan project Google Cloud untuk memberikan isolasi yang lebih kuat antar-resource yang tidak diatur atau digunakan bersama.
Aplikasi atau project tim
Aplikasi atau project tim app-banking-prod ditujukan untuk persona
developer. Project ini adalah tempat keberadaan resource Google Cloud khusus aplikasi atau
khusus tim. Proyek ini mencakup semuanya, kecuali
cluster GKE. Bergantung pada jumlah tim atau
aplikasi, mungkin ada beberapa instance jenis project ini. Dengan membuat project terpisah untuk tim yang berbeda, Anda dapat mengelola IAM, penagihan, dan kuota secara terpisah untuk setiap tim.
Jaringan
Setiap cluster Google Distributed Cloud memerlukan subnet alamat IP berikut:
- Alamat IP node
- Alamat IP Pod Kubernetes
- Alamat IP cluster/layanan Kubernetes
- Alamat IP load balancer (mode paket)
Untuk menggunakan rentang alamat IP yang tidak dapat dirutekan yang sama untuk Pod Kubernetes dan subnet layanan di setiap cluster, pilih model jaringan mode pulau. Dalam konfigurasi ini, Pod dapat langsung berkomunikasi satu sama lain di dalam cluster, tetapi tidak dapat dijangkau langsung dari luar cluster (menggunakan alamat IP Pod). Konfigurasi ini membentuk pulau dalam jaringan yang tidak terhubung ke jaringan eksternal. Cluster membentuk mesh node-ke-node lengkap di seluruh node cluster dalam pulau, sehingga Pod dapat langsung menjangkau Pod lain dalam cluster.
Alokasi alamat IP
| Cluster | Node | Pod | Perbankan & Keuangan | Load balancer |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | T/A |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3-10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3-10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | T/A |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3-10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3-10.195.2.10 |
Dalam mode pulau, penting untuk memastikan bahwa subnet alamat IP yang dipilih untuk Pod dan layanan Kubernetes tidak digunakan atau dapat dirutekan dari jaringan node.
Persyaratan jaringan
Guna menyediakan load balancer terintegrasi untuk Google Distributed Cloud yang tidak memerlukan konfigurasi, gunakan mode load balancer yang dipaketkan di setiap cluster. Saat beban kerja menjalankan layanan LoadBalancer, alamat IP akan ditetapkan dari kumpulan load balancer.
Untuk membaca informasi mendetail tentang persyaratan dan konfigurasi load balancer yang dipaketkan, lihat Ringkasan load balancer dan Mengonfigurasi load balancing yang dipaketkan.
Arsitektur cluster
Untuk lingkungan produksi, sebaiknya gunakan model deployment cluster admin dan pengguna dengan satu cluster admin dan dua cluster pengguna di setiap lokasi geografis untuk mencapai redundansi dan fault tolerance terbesar terhadap Google Distributed Cloud.
Sebaiknya gunakan minimal empat cluster pengguna untuk setiap lingkungan produksi. Gunakan dua lokasi yang redundan secara geografis yang masing-masing berisi dua cluster fault-tolerant. Setiap cluster fault-tolerant memiliki hardware redundan dan koneksi jaringan redundan. Mengurangi jumlah cluster akan mengurangi redundansi atau toleransi error arsitektur.
Untuk membantu memastikan ketersediaan tinggi, bidang kontrol untuk setiap cluster menggunakan tiga node. Dengan minimal tiga node pekerja per cluster pengguna, Anda dapat mendistribusikan beban kerja di seluruh node tersebut untuk menurunkan dampak jika node offline. Jumlah dan ukuran node pekerja sebagian besar bergantung pada jenis dan jumlah workload yang berjalan di cluster. Ukuran yang direkomendasikan untuk setiap node dibahas dalam Mengonfigurasi hardware untuk Google Distributed Cloud.
Tabel berikut menjelaskan ukuran node yang direkomendasikan untuk core CPU, memori, dan penyimpanan disk lokal dalam kasus penggunaan ini.
| Jenis node | CPU/vCPU | Memori | Penyimpanan |
|---|---|---|---|
| Bidang kontrol | 8 core | 32 GiB | 256 GiB |
| Pekerja | 8 core | 64 GiB | 512 GiB |
Untuk mengetahui informasi selengkapnya tentang prasyarat dan ukuran mesin, lihat Prasyarat mesin node cluster.
Pengelolaan identitas
Untuk pengelolaan identitas, sebaiknya lakukan integrasi dengan OIDC melalui Identity Service GKE. Dalam contoh yang diberikan di repositori sumber, autentikasi lokal digunakan untuk menyederhanakan persyaratan. Jika OIDC tersedia, Anda dapat mengubah contoh untuk menggunakannya. Untuk informasi selengkapnya, lihat Pengelolaan identitas dengan OIDC di Google Distributed Cloud.
Pengelolaan keamanan dan kebijakan
Dalam kasus penggunaan Cymbal Bank, Config Sync dan Policy Controller
digunakan untuk pengelolaan kebijakan. Cloud Source Repositories dibuat untuk menyimpan
data konfigurasi yang digunakan Config Sync. Operator
ConfigManagement, yang digunakan untuk menginstal dan mengelola Config Sync
dan Pengontrol Kebijakan, memerlukan akses hanya baca ke
repositori sumber konfigurasi. Untuk memberikan akses tersebut, gunakan bentuk autentikasi yang dapat diterima. Dalam contoh ini, akun layanan Google digunakan.
Layanan
Untuk Pengelolaan Layanan dalam kasus penggunaan ini, Cloud Service Mesh digunakan untuk
memberikan dasar bagi pembuatan layanan terdistribusi. Secara default, IngressGateway juga dibuat di cluster yang menangani objek
Ingress Kubernetes standar.
Pengelolaan status dan persistensi
Karena penyimpanan persisten sebagian besar bergantung pada infrastruktur yang ada, kasus penggunaan ini tidak memerlukannya. Namun, dalam kasus lain, sebaiknya gunakan opsi penyimpanan dari Partner Penyimpanan Siap GKE Enterprise. Jika tersedia, opsi penyimpanan CSI dapat diinstal di cluster menggunakan petunjuk yang disediakan vendor. Untuk bukti konsep dan kasus penggunaan lanjutan, Anda dapat menggunakan volume lokal. Namun, untuk sebagian besar kasus penggunaan, sebaiknya jangan gunakan volume lokal di lingkungan produksi.
Database
Banyak aplikasi stateful di Google Distributed Cloud menggunakan database sebagai penyimpanan persistensinya. Aplikasi database stateful memerlukan akses ke database untuk menyediakan logika bisnisnya kepada klien. Tidak ada pembatasan pada jenis Datastore yang digunakan oleh Google Distributed Cloud. Oleh karena itu, keputusan penyimpanan data harus dibuat oleh developer atau oleh tim pengelolaan data terkait. Karena aplikasi yang berbeda mungkin memerlukan datastore yang berbeda, datastore tersebut juga dapat digunakan tanpa batasan. Database dapat dikelola dalam cluster, di infrastruktur lokal, atau bahkan di cloud.
Aplikasi Cymbal Bank adalah aplikasi stateful yang mengakses dua database PostgreSQL. Akses database dikonfigurasi melalui variabel lingkungan. Database PostgreSQL harus dapat diakses dari node yang menjalankan beban kerja, meskipun database dikelola secara eksternal dari cluster. Dalam contoh ini, aplikasi mengakses database PostgreSQL eksternal yang sudah ada. Saat aplikasi berjalan di platform, database dikelola secara eksternal. Dengan demikian, database tersebut bukan bagian dari platform GKE Enterprise. Jika database PostgreSQL tersedia, gunakan database tersebut. Jika belum, buat dan gunakan database Cloud SQL untuk aplikasi Cymbal Bank.
Kemampuan observasi
Setiap cluster dalam kasus penggunaan Cymbal Bank dikonfigurasi agar Google Cloud Observability mengumpulkan log dan metrik untuk komponen sistem dan aplikasi. Ada beberapa dasbor Cloud Monitoring yang dibuat oleh penginstal konsol Google Cloud yang dapat dilihat dari halaman Dasbor pemantauan. Untuk mengetahui informasi selengkapnya tentang kemampuan observasi, lihat Mengonfigurasi logging dan pemantauan, serta Cara kerja Logging dan Monitoring untuk Google Distributed Cloud.
Deployment platform
Untuk mengetahui informasi selengkapnya, lihat bagian Men-deploy Platform dalam dokumentasi di repositori sumber GitHub.
Deployment aplikasi
Untuk mengetahui informasi selengkapnya, lihat bagian Men-deploy Aplikasi dalam dokumentasi di repositori sumber GitHub.
Langkah selanjutnya
- Baca selengkapnya tentang Cloud Service Mesh, Config Sync, dan Policy Controller.
- Lihat beberapa arsitektur referensi GKE Enterprise lainnya.
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.