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 fleet Workload Identity 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-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 yang berikut:
- Menyetujui promosi aplikasi ke lingkungan non-produksi dan lingkungan produksi.
- Mengkoordinasikan update infrastruktur.
- Membuat rencana kapasitas tingkat platform.
Penyewa 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 grup tim tenant adalah sebagai berikut:
- Developer aplikasi: Tim ini menulis dan melakukan debug kode aplikasi. Mereka
terkadang juga disebut sebagai software engineer atau developer stack lengkap. Tanggung jawab
mereka meliputi:
- Melakukan pengujian dan uji mutu 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 dibuat oleh developer aplikasi ke tahap produksi. Mereka terkadang disebut sebagai operator layanan, engineer sistem, atau administrator sistem. Tanggung jawab mereka meliputi
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 sekelompok atau beberapa kelompok 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 kesesuaian project blueprint aplikasi perusahaan dengan struktur blueprint dasar.
Project platform
Tabel berikut menjelaskan project tambahan, selain yang disediakan oleh blueprint dasar, yang diperlukan oleh blueprint 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 tenant tunggal serta 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 antartim 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 cetak biru ini, fleet adalah proyek yang mencakup satu atau beberapa klaster. Namun, fleet juga dapat mengelompokkan beberapa project. Armada memberikan batas keamanan logis untuk kontrol administratif. Armada 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 ini berfungsi sebagai cluster GKE yang identik di dua region 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 permukaan serangan dari internet. Node cluster maupun bidang kontrol tidak memiliki endpoint publik. Node cluster menjalankan Container-Optimized OS untuk membatasi permukaan serangannya, dan node cluster menggunakan Shielded GKE Node untuk membatasi kemampuan penyerang meniru identitas sebuah node.
Akses administratif ke cluster GKE diaktifkan melalui gateway Connect. Sebagai bagian dari deployment blueprint, satu instance Cloud NAT digunakan untuk setiap lingkungan guna memberi pod dan Config Sync mekanisme 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 agar Anda dapat membuat, mengirim, 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
- Anthos Service Mesh untuk pengelolaan layanan
- Otorisasi Biner untuk pengesahan image container
- Pengontrol Gateway GKE untuk pengontrol gateway multi-cluster untuk cluster GKE
Pengelolaan fleet platform
Armada memberi Anda kemampuan untuk mengelola beberapa cluster GKE dalam satu cara terpadu. Pengelolaan tim lengkap memudahkan administrator platform menyediakan dan mengelola resource infrastruktur untuk tenant platform developer. Penyewa memiliki kontrol terbatas atas resource dalam namespace mereka sendiri, termasuk aplikasi, log, dan metrik mereka.
Untuk menyediakan subset resource fleet 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 fleet memberikan kontrol atas siapa yang memiliki akses ke namespace tertentu dalam fleet Anda. Aplikasi ini menggunakan dua cluster GKE yang di-deploy pada satu fleet, dengan tiga cakupan tim, dan setiap cakupan memiliki satu namespace fleet.
Diagram berikut menunjukkan resource fleet dan cakupan yang sesuai dengan cluster contoh di lingkungan, seperti yang diterapkan oleh cetak biru.
Jaringan platform
Untuk jaringan, cluster GKE di-deploy di VPC Bersama yang dibuat sebagai bagian dari blueprint 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 cluster GKE Aplikasi 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 | 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 Anda sendiri, lihat Pengelolaan alamat IP di GKE dan perencanaan alamat IPv4 GKE.
DNS Platform
Blueprint menggunakan Cloud DNS untuk GKE guna memberikan resolusi DNS untuk pod dan service Kubernetes. Cloud DNS untuk GKE adalah DNS terkelola yang tidak memerlukan penyedia DNS yang dihosting di cluster.
Di blueprint, Cloud DNS dikonfigurasi untuk cakupan VPC. Dengan cakupan VPC, layanan di semua cluster GKE dalam sebuah project dapat 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 di dalam cluster.
Firewall platform
GKE otomatis membuat aturan firewall saat membuat cluster GKE, layanan GKE, firewall Gateway GKE, dan firewall GKE Ingress yang memungkinkan cluster beroperasi di lingkungan Anda. Prioritas untuk semua aturan firewall yang dibuat secara otomatis adalah 1.000. 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 akan menyediakan akses ke layanan Google Cloud.
Ketersediaan tinggi platform
Blueprint dirancang agar tahan terhadap gangguan zona dan region. Resource yang diperlukan untuk menjaga aplikasi tetap berjalan tersebar di dua region. Pilih region tempat Anda ingin men-deploy blueprint. Resource yang tidak berada di jalur penting untuk menyalurkan dan merespons pemuatan hanya merupakan satu region atau bersifat global. Tabel berikut menjelaskan resource dan tempat di-deploy.
Location |
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 bagaimana berbagai komponen bereaksi terhadap pemadaman layanan region atau pemadaman layanan zona, dan cara mengurangi efek ini.
Cakupan kegagalan |
Efek layanan eksternal |
Efek database | Membuat dan men-deploy efek | Efek pipeline Terraform |
|---|---|---|---|---|
Zona Wilayah 1 |
Tersedia. |
Tersedia. Instance standby menjadi aktif dengan nol RPO. |
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 diselesaikan. |
Tersedia. |
Pemadaman penyedia cloud hanyalah salah satu sumber periode nonaktif. Ketersediaan tinggi juga bergantung pada proses dan operasi yang mengurangi kemungkinan kesalahan. Tabel berikut menjelaskan semua keputusan yang dibuat dalam blueprint yang terkait dengan ketersediaan tinggi dan alasan untuk keputusan tersebut.
| Keputusan cetak biru | Dampak ketersediaan |
|---|---|
Manajemen perubahan |
|
Menggunakan GitOps dan IaC. |
Mendukung peninjauan sejawat atas perubahan dan mendukung pengembalian dengan cepat ke konfigurasi sebelumnya. |
Promosikan perubahan secara bertahap melalui lingkungan. |
Mengurangi dampak error software dan konfigurasi. |
Buat lingkungan non-produksi dan produksi yang serupa. |
Memastikan bahwa perbedaan tidak menunda penemuan error. Kedua lingkungan merupakan region ganda. |
Mengubah resource yang direplikasi satu region dalam satu waktu dalam suatu lingkungan. |
Memastikan bahwa masalah yang tidak ditemukan oleh promosi bertahap hanya memengaruhi setengah dari infrastruktur runtime. |
Mengubah layanan di satu region pada satu waktu dalam lingkungan. |
Memastikan bahwa masalah yang tidak terdeteksi oleh promosi bertahap hanya memengaruhi setengah dari replika layanan. |
Infrastruktur komputasi replika |
|
Gunakan bidang kontrol cluster regional. |
Bidang kontrol regional tersedia selama upgrade dan perubahan ukuran. |
Buat kumpulan node multi-zona. |
Kumpulan node cluster memiliki setidaknya 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. |
Mereplikasi registry image. |
Image disimpan di Artifact Registry, yang dikonfigurasi untuk mereplikasi ke beberapa region sehingga pemadaman layanan region cloud tidak mencegah peningkatan skala aplikasi di region yang bertahan. |
Layanan replika |
|
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 sebuah region untuk setiap layanan. |
Layanan Kubernetes memiliki minimal tiga replika (pod) untuk mendukung update peluncuran di lingkungan produksi dan non-produksi. |
Menyebarkan pod deployment di berbagai zona. |
Layanan Kubernetes tersebar di seluruh VM di zona yang berbeda menggunakan stanza anti-afinitas. Gangguan node tunggal atau pemadaman zona penuh dapat ditoleransi tanpa menyebabkan traffic lintas region tambahan antara layanan dependen. |
Penyimpanan replika |
|
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 ini secara asinkron mereplikasi data cluster utama Anda ke dalam cluster sekunder yang berada di region Google Cloud terpisah. |
Operasi |
|
Sediakan aplikasi untuk beban dua kali lipat yang diharapkan. |
Jika satu cluster gagal (misalnya, karena pemadaman 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 berturut-turut gagal berulang kali dalam jangka waktu yang panjang, GKE akan memulai proses perbaikan untuk node tersebut. |
Pastikan upgrade kumpulan node peka aplikasi. |
Deployment menentukan anggaran gangguan pod dengan |
Mulai ulang layanan yang mengalami deadlock secara otomatis. |
Deployment yang mendukung layanan menentukan pemeriksaan keaktifan, yang mengidentifikasi dan memulai ulang proses yang mengalami deadlock. |
Periksa secara otomatis apakah replika sudah siap. |
Deployment yang mendukung layanan menentukan pemeriksaan kesiapan, yang mengidentifikasi kapan aplikasi siap disalurkan setelah dimulai. Pemeriksaan kesiapan menghilangkan kebutuhan akan pemeriksaan manual atau waktu tunggu selama update berkelanjutan dan upgrade kumpulan node. |
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 mendeskripsikan 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 terhubung ke internet di platform developer memerlukan satu MultiClusterGateway.
- Cloud Logging memiliki batas 100 bucket dalam sebuah project. Akses log per tenant di blueprint bergantung pada bucket untuk setiap tenant.
- Untuk membuat lebih dari 20 tenant, Anda dapat meminta penambahan kuota project untuk resource Cakupan dan Cakupan Namespace. Untuk mendapatkan 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 selanjutnya
- Baca arsitektur layanan (dokumen berikutnya dalam seri ini).