Bagian ini menjelaskan kontrol yang digunakan di platform developer.
Identitas, peran, dan grup platform
Akses ke layanan Google Cloud memerlukan identitas Google Cloud. Blueprint ini menggunakan Workload Identity Federation fleet untuk GKE untuk memetakan akun layanan Kubernetes yang digunakan sebagai identitas untuk pod ke akun layanan Google Cloud yang mengontrol akses ke layanan Google Cloud. 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 blueprint, 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 blueprint dan mengintegrasikannya ke dalam sistem yang ada. Tim ini juga membuat template aplikasi baru.
- Administrator platform developer: Tim ini bertanggung jawab atas
hal berikut:
- Menyetujui pembuatan tim tenant baru.
- Melakukan tugas terjadwal dan tidak terjadwal yang memengaruhi beberapa tenant, termasuk hal berikut:
- Menyetujui promosi aplikasi ke lingkungan nonproduksi dan lingkungan produksi.
- Mengkoordinasikan 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 dua grup 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
meliputi 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.
- Mendesain 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 perubahan yang aman yang dilakukan oleh developer
aplikasi ke produksi. Mereka terkadang disebut operator layanan,
engineer sistem, atau administrator sistem. Tanggung jawab mereka mencakup
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, seperti saat layanan tidak memenuhi SLO-nya.
- Bekerja 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 perusahaan. Diagram berikut menunjukkan cara project blueprint aplikasi perusahaan sesuai dengan struktur blueprint fondasi.
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 factory aplikasi , yang digunakan untuk membuat arsitektur aplikasi single-tenant 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 untuk 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 fleet. Dalam blueprint ini, fleet adalah project yang menyertakan satu atau beberapa cluster. Namun, armada juga dapat mengelompokkan beberapa project. Flotte menyediakan batas keamanan yang logis untuk kontrol administratif. Fleet menyediakan cara untuk mengelompokkan dan menormalisasi cluster Kubernetes secara logis, serta mempermudah pengelolaan infrastruktur.
Diagram berikut menunjukkan dua cluster GKE, yang dibuat di setiap lingkungan untuk men-deploy aplikasi. Kedua cluster tersebut berfungsi sebagai cluster GKE yang identik di dua region yang berbeda untuk memberikan ketahanan multi-region. Untuk memanfaatkan kemampuan fleet, blueprint menggunakan konsep kesamaan di seluruh objek, layanan, dan identitas namespace.
Blueprint aplikasi perusahaan menggunakan cluster GKE dengan ruang pribadi yang diaktifkan melalui akses Private Service Connect ke bidang kontrol dan kumpulan node pribadi untuk menghapus potensi platform serangan dari internet. Node cluster maupun bidang kontrol tidak memiliki endpoint publik. Node cluster menjalankan Container-Optimized OS untuk membatasi platform serangannya dan node cluster menggunakan Node GKE yang Terlindungi untuk membatasi kemampuan penyerang dalam meniru identitas node.
Akses administratif ke cluster GKE diaktifkan melalui gateway Connect. Sebagai bagian dari deployment blueprint, 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 platform GKE Enterprise
Platform developer menggunakan komponen GKE Enterprise agar Anda dapat mem-build, men-deliver, dan mengelola siklus proses aplikasi. Komponen GKE Enterprise yang digunakan dalam deployment blueprint adalah sebagai berikut:
- GKE untuk pengelolaan container
- Pengontrol Kebijakan untuk pengelolaan dan penegakan kebijakan
- Cloud Service Mesh untuk pengelolaan layanan
- Otorisasi Biner untuk pengesahan image container
- GKE Gateway Controller untuk pengontrol gateway multi-cluster untuk cluster GKE
Pengelolaan fleet platform
Fleet memberi Anda kemampuan untuk mengelola beberapa cluster GKE dengan satu cara terpadu. Pengelolaan tim fleet memudahkan administrator platform menyediakan dan mengelola resource infrastruktur untuk tenant platform developer. Tenant memiliki kontrol resource yang dicakup dalam namespace mereka sendiri, termasuk aplikasi, log, dan metrik mereka.
Untuk menyediakan subset resource fleet berdasarkan 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 menggunakan dua cluster GKE yang di-deploy di satu fleet, dengan tiga cakupan tim, dan setiap cakupan memiliki satu namespace fleet.
Diagram berikut menunjukkan resource armada dan cakupan yang sesuai dengan contoh cluster di lingkungan, seperti yang diterapkan 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 untuk 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 terpisah.
Tabel berikut menjelaskan subnet VPC dan rentang alamat IP yang digunakan di berbagai lingkungan untuk men-deploy cluster blueprint. Untuk lingkungan pengembangan di Region cluster GKE aplikasi 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 | Non-produksi | 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 untuk menyediakan resolusi DNS untuk pod dan layanan Kubernetes. Cloud DNS untuk GKE adalah DNS terkelola yang tidak memerlukan penyedia DNS yang dihosting cluster.
Dalam blueprint, 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 secara 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 blueprint fondasi perusahaan memiliki aturan default untuk memblokir traffic di VPC Bersama.
Akses platform ke layanan Google Cloud
Karena aplikasi blueprint menggunakan cluster pribadi, Akses Google Pribadi memberikan akses ke layanan Google Cloud.
Ketersediaan tinggi platform
Blueprint 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 kritis untuk menayangkan dan merespons beban hanya 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 reaksi berbagai komponen terhadap pemadaman layanan region atau pemadaman layanan zona, dan cara Anda dapat memitigasi efek ini.
Cakupan kegagalan |
Efek layanan eksternal |
Efek database | Mem-build dan men-deploy efek | Efek pipeline Terraform |
---|---|---|---|---|
Zona Wilayah 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 Wilayah 2 |
Tersedia. |
Tersedia. |
Tersedia. |
Tersedia, perubahan manual mungkin diperlukan. Anda mungkin perlu memulai ulang
perintah |
Region 1 |
Tersedia. |
Diperlukan perubahan manual. 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 selesai. |
Tersedia. |
Pemadaman layanan penyedia cloud hanyalah salah satu sumber periode nonaktif. Ketersediaan tinggi juga bergantung pada proses dan operasi yang membantu mengurangi kemungkinan terjadinya kesalahan. Tabel berikut menjelaskan semua keputusan yang dibuat dalam blueprint yang terkait dengan ketersediaan tinggi dan alasan keputusan tersebut.
Keputusan blueprint | Dampak ketersediaan |
---|---|
Manajemen perubahan |
|
Gunakan GitOps dan IaC. |
Mendukung peninjauan sejawat atas perubahan dan mendukung pengembalian cepat ke konfigurasi sebelumnya. |
Mendorong perubahan secara bertahap melalui lingkungan. |
Mengurangi dampak error software dan konfigurasi. |
Buat lingkungan non-produksi dan produksi serupa. |
Memastikan bahwa perbedaan tidak menunda penemuan error. Kedua lingkungan tersebut adalah dual-region. |
Mengubah resource yang direplikasi satu region pada satu waktu dalam lingkungan. |
Memastikan bahwa masalah yang tidak terdeteksi oleh promosi bertahap hanya memengaruhi setengah infrastruktur run-time. |
Mengubah layanan di satu region pada satu waktu 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. |
Panel kontrol regional tersedia selama upgrade dan pengubahan ukuran. |
Membuat node pool multi-zona. |
Node pool cluster memiliki minimal tiga node yang tersebar di tiga zona. |
Mengonfigurasi jaringan VPC Bersama. |
Jaringan VPC Bersama mencakup dua region. Kegagalan regional hanya memengaruhi traffic jaringan ke dan dari resource di region yang gagal. |
Replikasi registry image. |
Image disimpan di Artifact Registry, yang dikonfigurasi untuk direplikasi ke beberapa region sehingga pemadaman layanan region cloud tidak mencegah penskalaan aplikasi di region yang masih aktif. |
Layanan yang direplikasi |
|
Men-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 melayani perubahan dalam region. |
Anda dapat mengupdate layanan Kubernetes menggunakan pola deployment update berkelanjutan yang mengurangi risiko dan periode nonaktif. |
Konfigurasikan tiga replika di region untuk setiap layanan. |
Layanan Kubernetes memiliki minimal tiga replika (pod) untuk mendukung update berkelanjutan di lingkungan produksi dan non-produksi. |
Menyebarkan 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 mengakibatkan traffic lintas region tambahan di antara layanan dependen. |
Penyimpanan yang direplikasi |
|
Men-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 region Google Cloud yang terpisah. |
Operasi |
|
Sediakan aplikasi untuk dua kali beban yang diharapkan. |
Jika satu cluster gagal (misalnya, karena pemadaman layanan regional), bagian layanan yang berjalan di cluster yang tersisa dapat menyerap beban sepenuhnya. |
Memperbaiki node secara otomatis. |
Cluster dikonfigurasi dengan perbaikan otomatis node. Jika health check berturut-turut node gagal berulang kali selama jangka waktu yang lama, GKE akan memulai proses perbaikan untuk node tersebut. |
Pastikan upgrade node pool berbasis aplikasi. |
Deployment menentukan anggaran gangguan pod dengan |
Memulai ulang layanan yang mengalami deadlock secara otomatis. |
Deployment yang mendukung layanan menentukan liveness probe, yang mengidentifikasi dan memulai ulang proses yang mengalami deadlock. |
Memeriksa secara otomatis apakah replika sudah siap. |
Deployment yang mendukung layanan menentukan pemeriksaan kesiapan, yang mengidentifikasi kapan aplikasi siap ditayangkan setelah dimulai. Uji kesiapan menghilangkan kebutuhan pemeriksaan manual atau waktu tunggu selama update rolling dan upgrade node pool. |
Arsitektur referensi dirancang untuk aplikasi dengan persyaratan ketersediaan tinggi zona dan regional. Memastikan ketersediaan tinggi akan menimbulkan beberapa biaya (misalnya, biaya cadangan 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 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 bergantung pada bucket untuk setiap tenant.
- Untuk membuat lebih dari 20 tenant, Anda dapat meminta peningkatan kuota project untuk resource Cakupan dan Namespace Cakupan. Untuk petunjuk cara melihat kuota, lihat Melihat dan mengelola kuota. Gunakan filter untuk menemukan
jenis kuota
gkehub.googleapis.com/global-per-project-scopes
dangkehub.googleapis.com/global-per-project-scope-namespaces
.
Langkah selanjutnya
- Baca tentang arsitektur layanan (dokumen berikutnya dalam rangkaian ini).