Kontrol platform developer

Last reviewed 2024-04-19 UTC

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 dan folder blueprint.

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

common

eab-infra-cicd

Berisi pipeline infrastruktur multi-tenant untuk men-deploy infrastruktur tenant.

eab-app-factory

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.

eab-{tenant}-cicd

Berisi pipeline CI/CD aplikasi, yang berada dalam project independen untuk memungkinkan pemisahan antar-tim pengembangan. Ada satu pipeline untuk setiap aplikasi.

development,
nonproduction,
production

eab-gke

Berisi cluster GKE untuk platform developer dan logika yang digunakan untuk mendaftarkan cluster untuk pengelolaan fleet.

eab-{tenant}

(1-n)

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.

Cluster blueprint.

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:

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.

Resource cakupan dan fleet 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
  • common
  • development
  • nonproduction
  • production
  • nonproduction
  • production
  • common
  • development
  • nonproduction
  • production

Project dengan resource di lokasi ini
  • eab-gke-{env}
  • eab-infra-cicd
  • eab-{ns}-cicd
  • eab-gke-{env}
  • eab-{ns}-cicd (only for the Artifact Registry mirror)
  • eab-gke-{env}

Jenis resource di lokasi ini
  • Cluster GKE (aplikasi dan konfigurasi Gateway)
  • Artifact Registry
  • AlloyDB untuk PostgreSQL
  • Cloud Build
  • Cloud Deploy
  • Cluster GKE (khusus aplikasi)
  • Artifact Registry
  • AlloyDB untuk PostgreSQL
  • Cloud Logging
  • Cloud Monitoring
  • Cloud Load Balancing
  • Cakupan fleet
  • Namespace fleet

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 terraform apply yang sedang berlangsung, tetapi selesai selama penghentian layanan.

Tersedia, perubahan manual mungkin diperlukan.

Anda mungkin perlu memulai ulang perintah terraform apply yang sedang berlangsung, tetapi selesai selama penghentian layanan.

Zona Wilayah 2

Tersedia.

Tersedia.

Tersedia.

Tersedia, perubahan manual mungkin diperlukan.

Anda mungkin perlu memulai ulang perintah terraform apply yang sedang berlangsung, tetapi selesai selama penghentian layanan.

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 maxUnavailable: 1 untuk mengizinkan upgrade node pool paralel di cluster besar. Tidak lebih dari satu dari tiga (di lingkungan pengembangan) atau satu dari enam (di non-produksi dan produksi) replika tidak tersedia selama upgrade node pool.

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 dan gkehub.googleapis.com/global-per-project-scope-namespaces.

Langkah selanjutnya