Bagian ini menjelaskan kontrol yang digunakan di platform developer.
Identitas, peran, dan grup platform
Akses ke layanan Google Cloud memerlukan Google Cloud identitas. Blueprint ini menggunakan Workload Identity Federation untuk GKE di fleet untuk memetakan akun layanan Kubernetes yang digunakan sebagai identitas untuk pod ke Google Cloud akun layanan yang mengontrol akses ke Google Cloud layanan. Untuk membantu melindungi dari eskalasi lintas lingkungan, setiap lingkungan memiliki kumpulan identitas terpisah (dikenal sebagai kumpulan penyedia identitas tepercaya) untuk akun Workload Identity Federation for GKE-nya.
Persona platform
Saat men-deploy cetak biru, Anda membuat tiga jenis grup pengguna: tim platform developer, tim aplikasi (satu tim per aplikasi), dan tim operasi keamanan.
Tim platform developer bertanggung jawab atas pengembangan dan pengelolaan platform developer. Anggota tim ini adalah sebagai berikut:
- Developer platform developer: Anggota tim ini memperluas cetak biru dan mengintegrasikannya ke dalam sistem yang ada. Tim ini juga membuat template aplikasi baru.
- Administrator platform developer: Tim ini bertanggung jawab atas hal-hal berikut:
- Menyetujui pembuatan tim tenant baru.
- Melakukan tugas terjadwal dan tidak terjadwal yang memengaruhi beberapa tenant, termasuk:
- Menyetujui promosi aplikasi ke lingkungan non-produksi dan lingkungan produksi.
- Mengoordinasikan update infrastruktur.
- Membuat rencana kapasitas tingkat platform.
Tenant platform developer adalah satu tim pengembangan software dan orang-orang yang bertanggung jawab atas pengoperasian software tersebut. Tim tenant terdiri dari dua grup: developer aplikasi dan operator aplikasi. Tugas kedua kelompok tim tenant adalah sebagai berikut:
- Developer aplikasi: Tim ini menulis dan men-debug kode aplikasi. Mereka
terkadang juga disebut software engineer atau developer full-stack. Tanggung jawab mereka mencakup hal-hal berikut:
- Melakukan pengujian dan jaminan kualitas pada komponen aplikasi saat di-deploy ke lingkungan pengembangan.
- Mengelola resource cloud milik aplikasi (seperti database dan bucket penyimpanan) di lingkungan pengembangan.
- Merancang skema database atau penyimpanan untuk digunakan oleh aplikasi.
- Operator aplikasi atau site reliability engineer (SRE): Tim ini mengelola keandalan aplikasi yang berjalan di lingkungan produksi, dan kemajuan yang aman dari perubahan yang dilakukan oleh developer aplikasi ke dalam produksi. Mereka terkadang disebut operator layanan,
engineer sistem, atau administrator sistem. Tanggung jawab mereka mencakup hal-hal berikut:
- Merencanakan kebutuhan kapasitas tingkat aplikasi.
- Membuat kebijakan pemberitahuan dan menetapkan tujuan tingkat layanan (SLO) untuk layanan.
- Mendiagnosis masalah layanan menggunakan log dan metrik yang khusus untuk aplikasi tersebut.
- Merespons pemberitahuan dan halaman, misalnya saat layanan tidak memenuhi SLO-nya.
- Bekerja sama dengan satu atau beberapa grup developer aplikasi.
- Menyetujui deployment versi baru ke produksi.
- Mengelola resource cloud milik aplikasi di lingkungan non-produksi dan produksi (misalnya, pencadangan dan update skema).
Struktur organisasi platform
Blueprint aplikasi perusahaan menggunakan struktur organisasi yang disediakan oleh blueprint dasar-dasar perusahaan. Diagram berikut menunjukkan cara project cetak biru aplikasi perusahaan sesuai dengan struktur cetak biru dasar.
Project platform
Tabel berikut menjelaskan project tambahan, selain yang disediakan oleh cetak biru dasar, yang diperlukan oleh cetak biru aplikasi untuk men-deploy resource, konfigurasi, dan aplikasi.
| Folder | Project | Deskripsi |
|---|---|---|
|
|
Berisi pipeline infrastruktur multi-tenant untuk men-deploy infrastruktur tenant. |
|
Berisi application factory , yang digunakan untuk membuat arsitektur aplikasi tenant tunggal dan pipeline continuous integration dan continuous deployment (CI/CD). Project ini juga berisi Config Sync yang digunakan untuk konfigurasi cluster GKE. |
|
|
Berisi pipeline CI/CD aplikasi, yang berada dalam project independen untuk memungkinkan pemisahan antar-tim pengembangan. Ada satu pipeline untuk setiap aplikasi. |
|
|
|
Berisi cluster GKE untuk platform developer dan logika yang digunakan untuk mendaftarkan cluster ke pengelolaan fleet. |
( |
Berisi layanan aplikasi tenant tunggal seperti database atau layanan terkelola lainnya yang digunakan oleh tim aplikasi. |
Arsitektur cluster platform
Blueprint men-deploy aplikasi di tiga lingkungan: pengembangan, non-produksi, dan produksi. Setiap lingkungan dikaitkan dengan armada. Dalam blueprint ini, armada adalah project yang mencakup satu atau beberapa cluster. Namun, kumpulan project juga dapat mengelompokkan beberapa project. Kumpulan menyediakan batas keamanan logis untuk kontrol administratif. Fleet menyediakan cara untuk mengelompokkan dan menormalisasi cluster Kubernetes secara logis, serta mempermudah administrasi infrastruktur.
Diagram berikut menunjukkan dua cluster GKE, yang dibuat di setiap lingkungan untuk men-deploy aplikasi. Kedua cluster berfungsi sebagai cluster GKE yang identik di dua region berbeda untuk memberikan ketahanan multi-region. Untuk memanfaatkan kemampuan fleet, cetak biru ini menggunakan konsep kesamaan di seluruh objek namespace, layanan, dan identitas.
Blueprint aplikasi perusahaan menggunakan cluster GKE dengan ruang pribadi yang diaktifkan melalui akses Private Service Connect ke bidang kontrol dan kumpulan node pribadi untuk menghilangkan potensi permukaan serangan dari internet. Node cluster maupun bidang kontrol tidak memiliki endpoint publik. Node cluster menjalankan Container-Optimized OS untuk membatasi permukaan serangan mereka dan node cluster menggunakan Node GKE yang Terlindungi untuk membatasi kemampuan penyerang dalam meniru identitas sebuah node.
Akses administratif ke cluster GKE diaktifkan melalui gateway Connect. Sebagai bagian dari deployment cetak biru, satu instance Cloud NAT digunakan untuk setiap lingkungan guna memberikan mekanisme pada pod dan Config Sync untuk mengakses resource di internet seperti GitHub. Akses ke cluster GKE dikontrol oleh otorisasi RBAC Kubernetes yang didasarkan pada Google Grup untuk GKE. Grup memungkinkan Anda mengontrol identitas menggunakan sistem pengelolaan identitas terpusat yang dikontrol oleh administrator identitas.
Komponen GKE Enterprise platform
Platform developer menggunakan komponen GKE Enterprise untuk memungkinkan Anda membangun, menyediakan, dan mengelola siklus proses aplikasi Anda. Komponen GKE Enterprise yang digunakan dalam deployment blueprint adalah sebagai berikut:
- GKE untuk pengelolaan container
- Policy Controller untuk pengelolaan dan penegakan kebijakan
- Cloud Service Mesh untuk pengelolaan layanan
- Otorisasi Biner untuk pengesahan image container
- Pengontrol GKE Gateway untuk pengontrol gateway multi-cluster bagi cluster GKE
Pengelolaan fleet platform
Fleet memberi Anda kemampuan untuk mengelola beberapa cluster GKE dengan cara terpadu. Pengelolaan tim fleet memudahkan administrator platform untuk menyediakan dan mengelola resource infrastruktur bagi tenant platform developer. Tenant memiliki kontrol tercakup atas resource dalam namespace mereka sendiri, termasuk aplikasi, log, dan metrik.
Untuk menyediakan subset resource fleet berdasarkan per tim, administrator dapat menggunakan cakupan tim. Cakupan tim memungkinkan Anda menentukan subset resource fleet untuk setiap tim, dengan setiap cakupan tim terkait dengan satu atau beberapa cluster anggota fleet.
Namespace armada memberikan kontrol atas siapa yang memiliki akses ke namespace tertentu dalam armada Anda. Aplikasi ini menggunakan dua cluster GKE yang di-deploy di satu armada, dengan tiga cakupan tim, dan setiap cakupan memiliki satu namespace armada.
Diagram berikut menunjukkan resource armada dan cakupan yang sesuai dengan cluster contoh di lingkungan, sebagaimana diimplementasikan oleh blueprint.
Jaringan platform
Untuk jaringan, cluster GKE di-deploy di VPC Bersama yang dibuat sebagai bagian dari blueprint dasar-dasar perusahaan. Cluster GKE memerlukan beberapa rentang alamat IP yang ditetapkan di lingkungan pengembangan, non-produksi, dan produksi. Setiap cluster GKE yang digunakan oleh blueprint memerlukan rentang alamat IP terpisah yang dialokasikan untuk node, pod, layanan, dan bidang kontrol. Instance AlloyDB untuk PostgreSQL juga memerlukan rentang alamat IP yang terpisah.
Tabel berikut menjelaskan subnet VPC dan rentang alamat IP yang digunakan di berbagai lingkungan untuk men-deploy cluster cetak biru. Untuk lingkungan pengembangan di Application GKE cluster region 2, blueprint hanya men-deploy satu ruang alamat IP meskipun ada ruang alamat IP yang dialokasikan untuk dua cluster GKE pengembangan.
| Resource | Jenis rentang alamat IP | Pengembangan | Nonproduksi | Produksi |
|---|---|---|---|---|
Region cluster GKE aplikasi 1 |
Rentang alamat IP utama |
10.0.64.0/24 |
10.0.128.0/24 |
10.0.192.0/24 |
Rentang alamat IP pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Rentang alamat IP layanan |
100.0.80.0/24 |
100.0.144.0/24 |
100.0.208.0/24 |
|
Rentang alamat IP bidang kontrol GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
Region cluster GKE aplikasi 2 |
Rentang alamat IP utama |
10.1.64.0/24 |
10.1.128.0/24 |
10.1.192.0/24 |
Rentang alamat IP pod |
100.64.64.0/24 |
100.64.128.0/24 |
100.64.192.0/24 |
|
Rentang alamat IP layanan |
100.1.80.0/24 |
100.1.144.0/24 |
100.1.208.0/24 |
|
Rentang alamat IP bidang kontrol GKE |
10.16.0.0/21 |
10.16.8.0/21 |
10.16.16.0/21 |
|
AlloyDB untuk PostgreSQL |
Rentang alamat IP database |
10.9.64.0/18 |
10.9.128.0/18 |
10.9.192.0/18 |
Jika Anda perlu mendesain skema alokasi alamat IP sendiri, lihat Pengelolaan alamat IP di GKE dan Perencanaan alamat IPv4 GKE.
DNS Platform
Blueprint ini menggunakan Cloud DNS untuk GKE guna menyediakan resolusi DNS untuk pod dan layanan Kubernetes. Cloud DNS untuk GKE adalah DNS terkelola yang tidak memerlukan penyedia DNS yang dihosting cluster.
Dalam cetak biru, Cloud DNS dikonfigurasi untuk cakupan VPC. Cakupan VPC memungkinkan layanan di semua cluster GKE dalam project berbagi satu zona DNS. Satu zona DNS memungkinkan layanan di-resolve di seluruh cluster, dan VM atau pod di luar cluster dapat me-resolve layanan dalam cluster.
Firewall platform
GKE otomatis membuat aturan firewall saat membuat cluster GKE, layanan GKE, firewall GKE Gateway, dan firewall GKE Ingress yang memungkinkan cluster beroperasi di lingkungan Anda. Prioritas untuk semua aturan firewall yang dibuat secara otomatis adalah 1000. Aturan ini diperlukan karena cetak biru fondasi perusahaan memiliki aturan default untuk memblokir traffic di VPC Bersama.
Akses platform ke Google Cloud layanan
Karena aplikasi blueprint menggunakan cluster pribadi, Akses Google Pribadi menyediakan akses ke layanan Google Cloud .
Ketersediaan tinggi platform
Blueprint ini dirancang agar tahan terhadap pemadaman layanan zona dan region. Resource yang diperlukan agar aplikasi tetap berjalan tersebar di dua region. Anda memilih region tempat Anda ingin men-deploy blueprint. Resource yang tidak berada di jalur penting untuk penayangan dan merespons beban hanya berada di satu region atau bersifat global. Tabel berikut menjelaskan resource dan tempat resource tersebut di-deploy.
Lokasi |
Region 1 |
Region 2 |
Global |
|---|---|---|---|
Lingkungan dengan resource di lokasi ini |
|
|
|
Project dengan resource di lokasi ini |
|
|
|
Jenis resource di lokasi ini |
|
|
|
Tabel berikut merangkum cara berbagai komponen bereaksi terhadap gangguan wilayah atau gangguan zona, dan cara Anda dapat memitigasi efek ini.
Cakupan kegagalan |
Efek layanan eksternal |
Efek database | Membangun dan men-deploy efek | Efek pipeline Terraform |
|---|---|---|---|---|
Zona Region 1 |
Tersedia. |
Tersedia. Instance standby menjadi aktif dengan RPO nol. |
Tersedia, perubahan manual mungkin diperlukan. Anda mungkin perlu memulai ulang perintah
|
Tersedia, perubahan manual mungkin diperlukan. Anda mungkin perlu memulai ulang perintah
|
Zona Region 2 |
Tersedia. |
Tersedia. |
Tersedia. |
Tersedia, perubahan manual mungkin diperlukan. Anda mungkin perlu memulai ulang perintah
|
Region 1 |
Tersedia. |
Perubahan manual diperlukan. Operator harus mempromosikan cluster sekunder secara manual. |
Tidak tersedia. |
Tidak tersedia. |
Region 2 |
Tersedia. |
Tersedia. |
Tersedia, perubahan manual mungkin diperlukan Build tetap tersedia. Anda mungkin perlu men-deploy build baru secara manual. Build yang ada mungkin tidak berhasil diselesaikan. |
Tersedia. |
Pemadaman penyedia cloud hanyalah salah satu penyebab periode nonaktif. Ketersediaan tinggi juga bergantung pada proses dan operasi yang membantu mengurangi kemungkinan terjadinya kesalahan. Tabel berikut menjelaskan semua keputusan yang dibuat dalam cetak biru yang terkait dengan ketersediaan tinggi dan alasan keputusan tersebut.
| Keputusan blueprint | Dampak ketersediaan |
|---|---|
Manajemen perubahan |
|
Gunakan GitOps dan IaC. |
Mendukung peninjauan perubahan oleh rekan sejawat dan mendukung pengembalian dengan cepat ke konfigurasi sebelumnya. |
Mempromosikan perubahan secara bertahap melalui lingkungan. |
Mengurangi dampak kesalahan software dan konfigurasi. |
Buat lingkungan non-produksi dan produksi serupa. |
Memastikan bahwa perbedaan tidak menunda penemuan error. Kedua lingkungan adalah dual-region. |
Ubah resource yang direplikasi satu region dalam satu waktu di dalam lingkungan. |
Memastikan bahwa masalah yang tidak terdeteksi oleh promosi bertahap hanya memengaruhi setengah infrastruktur runtime. |
Ubah layanan di satu region dalam satu waktu di dalam lingkungan. |
Memastikan bahwa masalah yang tidak terdeteksi oleh promosi bertahap hanya memengaruhi setengah replika layanan. |
Infrastruktur komputasi yang direplikasi |
|
Gunakan bidang kontrol cluster regional. |
Bidang kontrol regional tersedia selama upgrade dan pengubahan ukuran. |
Buat node pool multi-zona. |
Node pool cluster memiliki setidaknya tiga node yang tersebar di tiga zona. |
Konfigurasi jaringan VPC Bersama. |
Jaringan VPC Bersama mencakup dua region. Kegagalan regional hanya memengaruhi traffic jaringan ke dan dari resource di region yang gagal. |
Mereplikasi registry image. |
Image disimpan di Artifact Registry, yang dikonfigurasi untuk mereplikasi ke beberapa region sehingga pemadaman layanan region cloud tidak mencegah penskalaan aplikasi di region yang masih berfungsi. |
Layanan yang direplikasi |
|
Deploy replika layanan ke dua region. |
Jika terjadi pemadaman layanan regional, layanan Kubernetes tetap tersedia di lingkungan produksi dan non-produksi. |
Gunakan update berkelanjutan untuk perubahan layanan dalam suatu region. |
Anda dapat mengupdate layanan Kubernetes menggunakan pola deployment update berkelanjutan yang mengurangi risiko dan periode nonaktif. |
Konfigurasi tiga replika di satu region untuk setiap layanan. |
Layanan Kubernetes memiliki minimal tiga replika (pod) untuk mendukung update bertahap di lingkungan produksi dan non-produksi. |
Sebarkan pod deployment di beberapa zona. |
Layanan Kubernetes tersebar di seluruh VM di zona yang berbeda menggunakan stanza anti-afinitas. Gangguan satu node atau pemadaman zona penuh dapat ditoleransi tanpa menimbulkan traffic lintas region tambahan antara layanan yang bergantung. |
Penyimpanan yang direplikasi |
|
Deploy instance database multi-zona. |
AlloyDB untuk PostgreSQL menawarkan ketersediaan tinggi di suatu region. Node redundan instance utamanya terletak di dua zona region yang berbeda. Instance utama mempertahankan ketersediaan regional dengan memicu failover otomatis ke zona standby jika zona aktif mengalami masalah. Penyimpanan regional membantu memberikan ketahanan data jika terjadi kehilangan zona tunggal. |
Mereplikasi database lintas region. |
AlloyDB untuk PostgreSQL menggunakan replikasi lintas-region untuk memberikan kemampuan pemulihan dari bencana. Database mereplikasi data cluster utama Anda secara asinkron ke dalam cluster sekunder yang terletak di Google Cloud region terpisah. |
Operasi |
|
Sediakan aplikasi untuk dua kali lipat beban yang diharapkan. |
Jika satu cluster gagal (misalnya, karena gangguan layanan regional), bagian layanan yang berjalan di cluster yang tersisa dapat sepenuhnya menyerap beban. |
Memperbaiki node secara otomatis. |
Cluster dikonfigurasi dengan perbaikan otomatis node. Jika health check node gagal berturut-turut selama jangka waktu yang lama, GKE akan memulai proses perbaikan untuk node tersebut. |
Pastikan upgrade node pool kompatibel dengan aplikasi. |
Deployment menentukan anggaran gangguan pod dengan |
Mulai ulang layanan yang mengalami kebuntuan secara otomatis. |
Deployment yang mendukung layanan menentukan pemeriksaan keaktifan, yang mengidentifikasi dan memulai ulang proses yang mengalami kebuntuan. |
Memeriksa secara otomatis apakah replika sudah siap. |
Deployment yang mendukung layanan menentukan pemeriksaan kesiapan, yang mengidentifikasi kapan aplikasi siap melayani setelah dimulai. Pemeriksaan kesiapan menghilangkan kebutuhan akan pemeriksaan manual atau menunggu yang diatur waktunya selama update bertahap dan upgrade node pool. |
Arsitektur referensi ini dirancang untuk aplikasi dengan persyaratan ketersediaan tinggi zona dan regional. Memastikan ketersediaan tinggi akan menimbulkan beberapa biaya (misalnya, biaya suku cadang standby atau biaya replikasi lintas region). Bagian Alternatif menjelaskan beberapa cara untuk mengurangi biaya ini.
Kuota platform, batas performa, dan batas penskalaan
Anda dapat mengontrol kuota, performa, dan penskalaan resource di platform developer. Daftar berikut menjelaskan beberapa item yang perlu dipertimbangkan:
- Infrastruktur dasar memerlukan banyak project, dan setiap tenant tambahan memerlukan empat project. Anda mungkin perlu meminta kuota project tambahan sebelum men-deploy dan sebelum menambahkan lebih banyak tenant.
- Ada batas 100 resource MultiClusterGateway untuk setiap project. Setiap layanan Kubernetes yang menghadap internet di platform developer memerlukan satu MultiClusterGateway.
- Cloud Logging memiliki batas 100 bucket dalam satu project. Akses log per tenant dalam blueprint mengandalkan bucket untuk setiap tenant.
- Untuk membuat lebih dari 20 tenant, Anda dapat meminta penambahan kuota project untuk resource Cakupan dan Namespace Cakupan. Untuk mengetahui petunjuk tentang cara melihat kuota, lihat Melihat dan mengelola kuota. Gunakan filter untuk menemukan jenis kuota
gkehub.googleapis.com/global-per-project-scopesdangkehub.googleapis.com/global-per-project-scope-namespaces.
Langkah berikutnya
- Baca tentang arsitektur layanan (dokumen berikutnya dalam seri ini).