Halaman ini menunjukkan cara membuat Load Balancer Aplikasi eksternal untuk merutekan permintaan ke backend serverless. Di sini, istilah serverless mengacu pada produk komputasi serverless berikut:
- App Engine
- Cloud Run Functions
- Cloud Run
Integrasi Load Balancer Aplikasi eksternal dengan API Gateway memungkinkan backend serverless Anda memanfaatkan semua fitur yang disediakan oleh Cloud Load Balancing. Untuk mengonfigurasi Load Balancer Aplikasi eksternal guna merutekan traffic ke API Gateway, lihat Mulai menggunakan Load Balancer Aplikasi eksternal untuk API Gateway. Dukungan Load Balancer Aplikasi Eksternal untuk API Gateway tersedia dalam Pratinjau.
NEG serverless memungkinkan Anda menggunakan Google Cloud aplikasi serverless dengan Load Balancer Aplikasi eksternal. Setelah Anda mengonfigurasi load balancer dengan backend NEG serverless, permintaan ke load balancer akan dirutekan ke backend aplikasi serverless.
Untuk mempelajari lebih lanjut NEG serverless, baca ringkasan NEG serverless.
Jika Anda adalah pengguna Load Balancer Aplikasi klasik, pastikan Anda meninjau Ringkasan migrasi saat merencanakan deployment baru dengan Load Balancer Aplikasi eksternal global.Sebelum memulai
- Deploy fungsi App Engine, Cloud Run, atau layanan Cloud Run.
- Jika Anda belum melakukannya, instal Google Cloud CLI.
- Konfigurasi izin.
- Tambahkan resource sertifikat SSL.
Men-deploy App Engine, Cloud Run Functions, atau layanan Cloud Run
Petunjuk di halaman ini mengasumsikan bahwa Anda sudah menjalankan layanan Cloud Run, Cloud Run Functions, atau App Engine.
Untuk contoh di halaman ini, kami telah menggunakan Panduan memulai Python Cloud Run untuk men-deploy layanan Cloud Run di region us-central1
. Bagian selanjutnya di halaman ini menunjukkan cara menyiapkan Load Balancer Aplikasi eksternal yang menggunakan backend NEG tanpa server untuk merutekan permintaan ke layanan ini.
Jika Anda belum men-deploy aplikasi serverless, atau jika Anda ingin mencoba NEG serverless dengan aplikasi contoh, gunakan salah satu panduan memulai berikut. Anda dapat membuat aplikasi serverless di region mana pun, tetapi Anda harus menggunakan region yang sama nanti untuk membuat NEG serverless dan load balancer.
Cloud Run
Untuk membuat aplikasi Hello World sederhana, kemas ke dalam image container, lalu deploy image container ke Cloud Run, lihat Mulai Cepat: Membangun dan Men-deploy.
Jika Anda sudah mengupload container contoh ke Container Registry, lihat Panduan memulai: Men-deploy Container Contoh Bawaan.
Cloud Run Functions
Lihat Cloud Run functions: Python Quickstart.
App Engine
Lihat panduan memulai App Engine berikut untuk Python 3:
Menginstal Google Cloud CLI.
Instal Google Cloud CLI. Lihat Ringkasan gcloud untuk mengetahui informasi konseptual dan penginstalan tentang alat ini.
Jika Anda belum pernah menjalankan gcloud CLI sebelumnya, jalankan
gcloud init
terlebih dahulu untuk melakukan inisialisasi direktori gcloud Anda.
Konfigurasikan izin
Untuk mengikuti panduan ini, Anda perlu membuat NEG tanpa server dan membuat load balancer HTTP(S) eksternal dalam sebuah project. Anda harus menjadi pemilik atau editor project, atau Anda harus memiliki peran IAM Compute Engine berikut:
Tugas | Peran yang Diperlukan |
---|---|
Membuat komponen jaringan dan load balancer | Admin Jaringan |
Membuat dan mengubah NEG | Compute Instance Admin |
Membuat dan mengubah sertifikat SSL | Security Admin |
Mencadangkan alamat IP eksternal
Setelah layanan Anda aktif dan berjalan, siapkan alamat IP eksternal statis global yang akan digunakan pelanggan untuk menjangkau load balancer Anda.
Konsol
Di konsol Google Cloud , buka halaman External IP addresses.
Klik Reserve external static IP address.
Untuk Name, masukkan
example-ip
.Untuk Network service tier, pilih Premium.
Untuk IP version, pilih IPv4.
Untuk Type, pilih Global.
Klik Reserve.
gcloud
gcloud compute addresses create example-ip \ --network-tier=PREMIUM \ --ip-version=IPV4 \ --global
Perhatikan alamat IPv4 yang dicadangkan:
gcloud compute addresses describe example-ip \ --format="get(address)" \ --global
Membuat resource sertifikat SSL
Untuk membuat load balancer HTTPS, Anda harus menambahkan resource sertifikat SSL ke front end load balancer. Buat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri.
Sertifikat yang dikelola Google. Sebaiknya gunakan sertifikat yang dikelola Google karena Google Cloud memperoleh, mengelola, dan memperpanjang sertifikat ini secara otomatis. Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain dan data DNS untuk domain tersebut agar sertifikat dapat disediakan.
Selain itu, Anda perlu memperbarui data A DNS domain agar mengarah ke alamat IP load balancer yang dibuat di langkah sebelumnya (
example-ip
). Jika Anda memiliki beberapa domain dalam sertifikat yang dikelola Google, Anda harus memperbarui data DNS untuk semua domain dan subdomain agar mengarah ke alamat IP load balancer. Untuk petunjuk mendetail, lihat Menggunakan sertifikat yang dikelola Google.Sertifikat yang ditandatangani sendiri. Jika tidak ingin menyiapkan domain saat ini, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian.
Contoh ini mengasumsikan bahwa Anda telah membuat resource sertifikat SSL.
Jika ingin menguji proses ini tanpa membuat resource sertifikat SSL (atau domain seperti yang diwajibkan oleh sertifikat yang dikelola Google), Anda tetap dapat menggunakan petunjuk di halaman ini untuk menyiapkan load balancer HTTP.
Membuat load balancer
Dalam diagram berikut, load balancer menggunakan backend NEG serverless untuk mengarahkan permintaan ke layanan Cloud Run serverless. Untuk contoh ini, kita telah menggunakan panduan memulai Python Cloud Run untuk men-deploy layanan Cloud Run.
Karena health check tidak didukung untuk layanan backend dengan backend NEG serverless, Anda tidak perlu membuat aturan firewall yang mengizinkan health check jika load balancer hanya memiliki backend NEG serverless.
Konsol
Mulai konfigurasi
Di konsol Google Cloud , buka halaman Load balancing.
- Klik Create load balancer.
- Untuk Type of load balancer, pilih Application Load Balancer (HTTP/HTTPS), lalu klik Next.
- Untuk Public facing or internal, pilih Public facing (external), lalu klik Next.
- Untuk Global or single region deployment, pilih Best for global workloads, lalu klik Next.
- Untuk Load balancer generation, pilih Global external Application Load Balancer, lalu klik Next.
- Klik Configure.
Konfigurasi dasar
- Untuk nama load balancer, masukkan
serverless-lb
. - Biarkan jendela tetap terbuka untuk melanjutkan.
Konfigurasi frontend
- Klik Frontend configuration.
- Untuk Name, masukkan nama.
-
Untuk membuat load balancer HTTPS, Anda harus memiliki
sertifikat SSL
(
gcloud compute ssl-certificates list
).Sebaiknya gunakan sertifikat yang dikelola Google seperti yang dijelaskan sebelumnya.
- Klik Selesai.
Untuk mengonfigurasi Load Balancer Aplikasi eksternal, isi kolom sebagai berikut.
Pastikan opsi berikut dikonfigurasi dengan nilai ini:
Properti | Nilai (masukkan nilai atau pilih opsi yang ditentukan) |
---|---|
Protokol | HTTPS |
Network Service Tier | Premium |
IP version | IPv4 |
Alamat IP | example-ip |
Port | 443 |
Opsional: Waktu tunggu HTTP keep-alive | Masukkan nilai waktu tunggu dari 5 hingga 1.200 detik. Nilai defaultnya adalah 610 detik. |
Sertifikat | Pilih sertifikat SSL yang ada atau buat sertifikat baru. Untuk membuat load balancer HTTPS, Anda harus memiliki resource sertifikat SSL untuk digunakan di proxy HTTPS. Anda dapat membuat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri. Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain. Data A domain harus di-resolve ke alamat IP load balancer (dalam contoh ini, example-ip). Sebaiknya gunakan sertifikat yang dikelola Google karena Google Cloud memperoleh, mengelola, dan memperpanjang sertifikat ini secara otomatis. Jika tidak memiliki domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian. |
Opsional: Aktifkan Pengalihan HTTP ke HTTPS |
Gunakan kotak centang ini untuk mengaktifkan pengalihan HTTP ke HTTPS.
Dengan mencentang kotak ini, load balancer HTTP parsial tambahan akan dibuat yang menggunakan alamat IP yang sama dengan load balancer HTTPS Anda dan mengalihkan permintaan HTTP ke frontend HTTPS load balancer Anda. Kotak centang ini hanya dapat dipilih jika protokol HTTPS dipilih dan alamat IP yang dicadangkan digunakan. |
Jika ingin menguji proses ini tanpa menyiapkan resource sertifikat SSL (atau domain seperti yang diperlukan oleh sertifikat yang dikelola Google), Anda dapat menyiapkan load balancer HTTP.
Untuk membuat load balancer HTTP, pastikan opsi berikut dikonfigurasi dengan nilai ini:
Properti | Nilai (masukkan nilai atau pilih opsi yang ditentukan) |
---|---|
Protokol | HTTP |
Network Service Tier | Premium |
IP version | IPv4 |
Alamat IP | example-ip |
Port | 80 |
Opsional: Waktu tunggu HTTP keep-alive | Masukkan nilai waktu tunggu dari 5 hingga 1.200 detik. Nilai defaultnya adalah 610 detik. |
Konfigurasi backend
- Klik Backend configuration.
- Di daftar Backend services & backend buckets, klik Create a backend service.
- Untuk Name, masukkan nama.
- Di Backend type, pilih Serverless network endpoint group.
- Jangan ubah Protocol. Parameter ini diabaikan.
- Di bagian Backends, untuk New backend, pilih Create Serverless network endpoint group.
- Untuk Name, masukkan nama.
- Di Region, pilih us-central1, lalu pilih Cloud Run.
- Pilih Pilih nama layanan.
- Dalam daftar Service, pilih layanan Cloud Run yang ingin Anda buat load balancer-nya.
- Klik Buat.
- Di bagian New backend, klik Done.
- Klik Buat.
Aturan perutean
Aturan perutean menentukan cara pengarahan traffic Anda. Untuk mengonfigurasi pemilihan rute, Anda akan menyiapkan aturan host dan pencocok jalur, yang merupakan komponen konfigurasi peta URL Load Balancer Aplikasi eksternal.
Klik Routing rules.
- Pertahankan host dan jalur default. Untuk contoh ini, semua permintaan akan ditujukan ke layanan backend yang dibuat pada langkah sebelumnya.
Meninjau konfigurasi
- Klik Review and finalize.
- Tinjau semua setelan.
- Opsional: Klik Equivalent Code untuk melihat permintaan REST API yang akan digunakan untuk membuat load balancer.
- Klik Buat.
- Tunggu load balancer dibuat.
- Klik nama load balancer (serverless-lb).
- Catat alamat IP load balancer untuk tugas berikutnya. Fitur ini
disebut sebagai
IP_ADDRESS
.
gcloud
- Buat NEG tanpa server untuk aplikasi tanpa server Anda.
Untuk membuat NEG serverless dengan layanan Cloud Run:
Untuk opsi lainnya, lihat panduan referensigcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-run-service=CLOUD_RUN_SERVICE_NAME
gcloud
untukgcloud compute network-endpoint-groups create
. - Buat layanan backend.
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
- Tambahkan NEG tanpa server sebagai backend ke layanan backend:
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME \ --network-endpoint-group-region=us-central1
- Buat peta URL untuk mengarahkan permintaan masuk ke layanan backend:
gcloud compute url-maps create URL_MAP_NAME \ --default-service BACKEND_SERVICE_NAME
Peta URL contoh ini hanya menargetkan satu layanan backend yang merepresentasikan satu aplikasi serverless, jadi kita tidak perlu menyiapkan aturan host atau pencocok jalur. Jika memiliki lebih dari satu layanan backend, Anda dapat menggunakan aturan host untuk mengarahkan permintaan ke layanan yang berbeda berdasarkan nama host, dan Anda dapat menyiapkan pencocok jalur untuk mengarahkan permintaan ke layanan yang berbeda berdasarkan jalur permintaan.
-
Untuk membuat load balancer HTTPS, Anda harus memiliki
resource sertifikat SSLuntuk digunakan di proxy target HTTPS.
Anda dapat membuat resource sertifikat SSL menggunakan sertifikat SSL yang dikelola Google atau sertifikat SSL yang dikelola sendiri. Sebaiknya gunakan sertifikat yang dikelola Google karena Google Cloud memperoleh, mengelola, dan memperpanjang sertifikat ini secara otomatis. Google Cloud
Untuk membuat sertifikat yang dikelola Google, Anda harus memiliki domain. Jika tidak memiliki domain, Anda dapat menggunakan sertifikat SSL yang ditandatangani sendiri untuk pengujian.
Untuk membuat resource sertifikat SSL yang dikelola Google: Untuk membuat resource sertifikat SSL yang dikelola sendiri:gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --domains DOMAIN
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \ --certificate CRT_FILE_PATH \ --private-key KEY_FILE_PATH
-
Buat proxy HTTP(S) target untuk mengarahkan permintaan ke peta URL Anda.
Untuk load balancer HTTP, buat proxy target HTTP:
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --url-map=URL_MAP_NAME
Untuk load balancer HTTPS, buat proxy target HTTPS. Proxy adalah bagian dari load balancer yang menyimpan sertifikat SSL untuk Load Balancing HTTPS, sehingga Anda juga memuat sertifikat pada langkah ini.
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --ssl-certificates=SSL_CERTIFICATE_NAME \ --url-map=URL_MAP_NAME
Ganti kode berikut:
TARGET_HTTP_PROXY_NAME
: nama proxy HTTP target.TARGET_HTTPS_PROXY_NAME
: nama proxy HTTPS target.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: kolom opsional yang digunakan untuk menentukan waktu tunggu tetap aktif HTTP klien. Nilai waktu tunggu harus dari 5 hingga 1200 detik. Nilai defaultnya adalah 610 detik.SSL_CERTIFICATE_NAME
: nama sertifikat SSL.URL_MAP_NAME
: nama peta URL.
- Buat aturan penerusan untuk mengarahkan permintaan masuk ke proxy.
Untuk load balancer HTTP:
gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=example-ip \ --target-http-proxy=TARGET_HTTP_PROXY_NAME \ --global \ --ports=80
Untuk load balancer HTTPS:
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=example-ip \ --target-https-proxy=TARGET_HTTPS_PROXY_NAME \ --global \ --ports=443
Menghubungkan domain ke load balancer
Setelah load balancer dibuat, catat alamat IP yang terkait dengan load balancer, misalnya, 30.90.80.100
. Untuk mengarahkan domain ke load balancer, buat data A
menggunakan layanan pendaftaran domain. Jika
Anda menambahkan beberapa domain ke sertifikat SSL, Anda harus menambahkan data A
untuk setiap domain, yang semuanya mengarah ke alamat IP load balancer. Misalnya, untuk
membuat data A
bagi www.example.com
dan example.com
, gunakan string berikut:
NAME TYPE DATA www A 30.90.80.100 @ A 30.90.80.100
Jika Anda menggunakan Cloud DNS sebagai penyedia DNS, lihat Menambahkan, mengubah, dan menghapus data.
Menguji load balancer
Setelah mengonfigurasi load balancer, Anda dapat mulai mengirimkan traffic ke alamat IP load balancer. Jika mengonfigurasi domain, Anda juga dapat mengirim traffic ke nama domain tersebut. Namun, propagasi DNS memerlukan waktu untuk selesai, jadi Anda dapat memulai dengan menggunakan alamat IP untuk pengujian.
Di konsol Google Cloud , buka halaman Load balancing.
Klik load balancer yang baru saja dibuat.
Catat alamat IP load balancer internal.
Untuk load balancer HTTP, Anda dapat menguji load balancer menggunakan browser web dengan membuka
http://IP_ADDRESS
. GantiIP_ADDRESS
dengan alamat IP load balancer. Anda akan diarahkan ke halaman beranda layananhelloworld
.
Untuk load balancer HTTPS, Anda dapat menguji load balancer menggunakan browser web dengan membuka
https://IP_ADDRESS
. GantiIP_ADDRESS
dengan alamat IP load balancer. Anda akan diarahkan ke halaman beranda layananhelloworld
.
Jika tidak berhasil dan Anda menggunakan sertifikat yang dikelola Google, pastikan status resource sertifikat Anda adalah AKTIF. Untuk mengetahui informasi selengkapnya, lihat Status resource sertifikat SSL yang dikelola Google.
Jika Anda menggunakan sertifikat yang ditandatangani sendiri untuk pengujian, browser akan menampilkan peringatan. Anda harus secara eksplisit memerintahkan browser untuk menerima sertifikat yang ditandatangani sendiri. Klik peringatan untuk melihat halaman sebenarnya.
Opsi konfigurasi tambahan
Bagian ini memperluas contoh konfigurasi untuk memberikan opsi konfigurasi alternatif dan tambahan. Semua tugas bersifat opsional. Anda dapat melakukannya dalam urutan apa pun.
Menyiapkan load balancing multi-region
Dalam contoh yang dijelaskan sebelumnya di halaman ini, kita hanya memiliki satu
layanan Cloud Run yang berfungsi sebagai backend di region
us-central1
. Karena NEG serverless hanya dapat mengarah ke satu endpoint
dalam satu waktu, load balancing tidak dilakukan di beberapa region. Load Balancer Aplikasi eksternal hanya berfungsi sebagai frontend, dan memproksi traffic ke endpoint aplikasi helloworld
yang ditentukan. Namun, Anda mungkin ingin menayangkan aplikasi Cloud Run dari lebih dari satu region untuk meningkatkan latensi pengguna akhir.
Jika layanan backend memiliki beberapa NEG tanpa server yang terlampir, load balancer menyeimbangkan traffic dengan meneruskan permintaan ke NEG tanpa server di region terdekat yang tersedia. Namun, layanan backend hanya dapat berisi satu NEG serverless per region. Agar layanan Cloud Run Anda tersedia dari beberapa region, Anda perlu menyiapkan perutean lintas region. Anda harus dapat menggunakan skema URL tunggal yang berfungsi di mana pun di dunia, tetapi melayani permintaan pengguna dari region terdekat dengan pengguna.
Untuk menyiapkan penayangan multi-region, Anda harus menggunakan tingkat jaringan Premium untuk memastikan bahwa semua deployment Cloud Run regional kompatibel dan siap untuk menayangkan traffic dari region mana pun.
Untuk menyiapkan load balancer multi-region:
- Siapkan dua layanan Cloud Run di region yang berbeda. Misalkan Anda telah men-deploy dua layanan Cloud Run: satu ke region di AS, dan satu lagi ke region di Eropa.
- Buat Load Balancer Aplikasi eksternal dengan penyiapan berikut:
- Siapkan layanan backend global dengan dua NEG serverless:
- Buat NEG pertama di region yang sama dengan layanan Cloud Run yang di-deploy di Amerika Serikat.
- Buat NEG kedua di region yang sama dengan layanan Cloud Run yang di-deploy di Eropa.
- Siapkan konfigurasi frontend Anda dengan Tingkat Layanan Jaringan Premium.
- Siapkan layanan backend global dengan dua NEG serverless:
Penyiapan yang dihasilkan ditunjukkan dalam diagram berikut.
Bagian ini dibuat berdasarkan penyiapan load balancer yang dijelaskan sebelumnya di halaman ini, tempat Anda membuat satu NEG tanpa server di region us-central1
yang mengarah ke layanan Cloud Run di region yang sama. Panduan ini juga
mengasumsikan bahwa Anda telah membuat layanan Cloud Run kedua di
region europe-west1
. NEG serverless kedua yang Anda buat akan mengarah
ke layanan Cloud Run ini di region europe-west1
.
Dalam contoh ini, Anda akan menyelesaikan langkah-langkah berikut:
- Buat NEG tanpa server kedua di region
europe-west1
. - Lampirkan NEG tanpa server kedua ke layanan backend.
Untuk menambahkan NEG tanpa server kedua ke layanan backend yang ada, ikuti langkah-langkah berikut.
Konsol
Di konsol Google Cloud , buka halaman Load balancing.
Klik nama load balancer yang layanan backend-nya ingin Anda edit.
Di halaman Load balancer details, klik
Edit.Di halaman Edit global external Application Load Balancer, klik Backend configuration.
Di halaman Backend configuration, klik
Edit untuk layanan backend yang ingin Anda ubah.Di bagian Backend, klik Tambahkan backend.
Di daftar Serverless network endpoint groups, pilih Create Serverless network endpoint group.
Masukkan nama untuk NEG serverless.
Untuk Region, pilih
europe-west1
.Untuk Serverless network endpoint group type, pilih Cloud Run, lalu lakukan hal berikut:
- Pilih opsi Pilih Layanan.
- Dalam daftar Service, pilih layanan Cloud Run yang ingin Anda buat load balancer-nya.
Klik Buat.
Di halaman Backend baru, klik Selesai.
Klik Simpan.
Untuk memperbarui layanan backend, klik Update.
Untuk memperbarui load balancer, di halaman Edit global external Application Load Balancer, klik Update.
gcloud
Buat NEG tanpa server kedua di region yang sama tempat layanan Cloud Run di-deploy.
gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \ --region=europe-west1 \ --network-endpoint-type=SERVERLESS \ --cloud-run-service=CLOUD_RUN_SERVICE_2
Ganti kode berikut:
SERVERLESS_NEG_NAME_2
: nama NEG serverless keduaCLOUD_RUN_SERVICE_2
: nama layanan Cloud Run
Tambahkan NEG tanpa server kedua sebagai backend ke layanan backend.
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --global \ --network-endpoint-group=SERVERLESS_NEG_NAME_2 \ --network-endpoint-group-region=europe-west1
Ganti kode berikut:
BACKEND_SERVICE_NAME
: nama layanan backendSERVERLESS_NEG_NAME_2
: nama NEG serverless kedua
Menggunakan langganan push Pub/Sub terautentikasi dengan deployment Cloud Run multi-region
Untuk permintaan push yang diautentikasi, Cloud Run mengharapkan kolom audiens khusus wilayah secara default. Jika terjadi deployment Cloud Run multi-region, jika permintaan push dirutekan ke layanan Cloud Run di region lain, verifikasi token JWT akan gagal karena ketidakcocokan audiens.
Untuk mengatasi pembatasan spesifik per region ini:
- Konfigurasi audiens kustom yang sama untuk deployment layanan di berbagai region.
- Konfigurasi pesan push Pub/Sub untuk menggunakan audiens kustom sebagai audiens dalam token JWT.
Menyiapkan perutean regional
Alasan umum untuk menayangkan aplikasi dari beberapa region adalah untuk memenuhi persyaratan lokalitas data. Misalnya, Anda mungkin ingin memastikan bahwa permintaan yang dibuat oleh pengguna Eropa selalu ditayangkan dari region yang berlokasi di Eropa. Untuk menyiapkan ini, Anda memerlukan skema URL dengan URL terpisah untuk pengguna Uni Eropa dan non-Uni Eropa, serta mengarahkan pengguna Uni Eropa ke URL Uni Eropa.
Dalam skenario seperti itu, Anda akan menggunakan peta URL untuk mengarahkan permintaan dari URL tertentu ke wilayah yang sesuai. Dengan penyiapan seperti itu, permintaan yang ditujukan untuk satu region tidak akan pernah dikirimkan ke region lain. Hal ini memberikan isolasi antar-region. Di sisi lain, jika suatu region gagal, permintaan tidak akan dirutekan ke region lain. Jadi, penyiapan ini tidak meningkatkan ketersediaan layanan Anda.
Untuk menyiapkan perutean regional, Anda harus menggunakan tingkat jaringan Premium agar dapat menggabungkan berbagai region dalam satu aturan penerusan.
Untuk menyiapkan load balancer dengan perutean regional:
- Siapkan dua layanan Cloud Run di region yang berbeda. Misalkan Anda telah men-deploy dua layanan Cloud Run: hello-world-eu ke region di Eropa, dan hello-world-us ke region di AS.
- Buat Load Balancer Aplikasi eksternal dengan penyiapan berikut:
- Siapkan layanan backend dengan NEG tanpa server di Eropa. NEG tanpa server harus dibuat di region yang sama dengan layanan Cloud Run yang di-deploy di Eropa.
- Siapkan layanan backend kedua dengan NEG tanpa server lain di Amerika Serikat. NEG tanpa server ini harus dibuat di region yang sama dengan layanan Cloud Run yang di-deploy di AS.
- Siapkan peta URL Anda dengan aturan host dan jalur yang sesuai sehingga satu set URL diarahkan ke layanan backend Eropa, sementara semua permintaan diarahkan ke layanan backend AS.
- Siapkan konfigurasi frontend Anda dengan paket jaringan Premium.
Penyiapan lainnya dapat sama seperti yang dijelaskan sebelumnya. Konfigurasi yang dihasilkan akan terlihat seperti ini:
Menggunakan masker URL
Saat membuat NEG tanpa server, alih-alih memilih layanan Cloud Run tertentu, Anda dapat menggunakan masker URL untuk mengarah ke beberapa layanan yang ditayangkan di domain yang sama. Masker URL adalah template skema URL Anda. NEG tanpa server akan menggunakan template ini untuk mengekstrak nama layanan dari URL permintaan yang masuk dan memetakan permintaan ke layanan yang sesuai.
Masker URL sangat berguna jika layanan Anda dipetakan ke domain kustom, bukan alamat default yang disediakan Google Cloud untuk layanan yang di-deploy. Masker URL memungkinkan Anda menargetkan beberapa layanan dan versi dengan satu aturan, meskipun aplikasi Anda menggunakan pola URL kustom.
Jika Anda belum melakukannya, pastikan Anda membaca Ringkasan NEG serverless: Masker URL.
Membuat masker URL
Untuk membuat mask URL bagi load balancer, mulailah dengan URL layanan Anda. Untuk contoh ini, kita akan menggunakan aplikasi serverless contoh yang berjalan di
https://example.com/login
. Ini adalah URL tempat layanan login
aplikasi
akan ditayangkan.
- Hapus
http
atauhttps
dari URL. Anda memilikiexample.com/login
. - Ganti nama layanan dengan placeholder untuk mask URL.
- Cloud Run: Ganti nama layanan Cloud Run dengan
placeholder
<service>
. Jika layanan Cloud Run memiliki tag yang terkait dengannya, ganti nama tag dengan placeholder<tag>
. Dalam contoh ini, masker URL yang tersisa adalahexample.com/<service>
. - Fungsi Cloud Run: Ganti nama fungsi dengan placeholder
<function>
. Dalam contoh ini, masker URL yang tersisa adalahexample.com/<function>
. - App Engine: Ganti nama layanan dengan placeholder
<service>
. Jika layanan memiliki versi yang terkait dengannya, ganti versi dengan placeholder<version>
. Dalam contoh ini, masker URL yang tersisa adalahexample.com/<service>
. - API Gateway: Ganti nama gateway dengan placeholder
<gateway>
. Dalam contoh ini, masker URL yang tersisa adalahexample.com/<gateway>
.
- Cloud Run: Ganti nama layanan Cloud Run dengan
placeholder
(Opsional) Jika nama layanan (atau fungsi, versi, atau tag) dapat diekstrak dari bagian jalur URL,domain dapat dihilangkan. Bagian jalur masker URL dibedakan oleh karakter
/
pertama. Jika/
tidak ada di mask URL, mask tersebut dipahami hanya merepresentasikan host. Oleh karena itu, untuk contoh ini, masker URL dapat dikurangi menjadi/<service>
,/<gateway>
, atau/<function>
.Demikian pula, jika nama layanan dapat diekstrak dari bagian host URL, Anda dapat menghilangkan jalur sepenuhnya dari masker URL.
Anda juga dapat menghilangkan komponen host atau subdomain yang muncul sebelum placeholder pertama serta komponen jalur yang muncul setelah placeholder terakhir. Dalam kasus seperti itu, placeholder mengambil informasi yang diperlukan untuk komponen.
Berikut beberapa contoh lainnya yang menunjukkan aturan ini:
Cloud Run
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan Cloud Run Anda dipetakan ke domain ini menggunakan Load Balancer Aplikasi eksternal.
Layanan, Nama tag | URL domain kustom | Masker URL |
---|---|---|
service: login | https://login-home.example.com/web | <service>-home.example.com |
service: login | https://example.com/login/web | example.com/<service> atau /<service> |
service: login, tag: test | https://test.login.example.com/web | <tag>.<service>.example.com |
service: login, tag: test | https://example.com/home/login/test | example.com/home/<service>/<tag> atau /home/<service>/<tag> |
service: login, tag: test | https://test.example.com/home/login/web | <tag>.example.com/home/<service> |
Cloud Run Functions
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan fungsi Cloud Run Anda dipetakan ke domain ini.
Nama Fungsi | URL domain kustom | Masker URL |
---|---|---|
login | https://example.com/login | /<function> |
login | https://example.com/home/login | /home/<function> |
login | https://login.example.com | <function>.example.com |
login | https://login.home.example.com | <function>.home.example.com |
App Engine
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan semua layanan App Engine Anda dipetakan ke domain ini.
Nama layanan, versi | URL domain kustom | Masker URL |
---|---|---|
service: login | https://login.example.com/web | <service>.example.com |
service: login | https://example.com/home/login/web | example.com/home/<service>, atau /home/<service> |
service: login, version: test | https://test.example.com/login/web | <version>.example.com/<service> |
service: login, version: test | https://example.com/login/test | example.com/<service>/<version> |
Gateway API
Tabel ini mengasumsikan bahwa Anda memiliki domain kustom bernama example.com
dan
semua layanan API Gateway Anda dipetakan ke domain ini.
Gateway name | URL domain kustom API Gateway(Pratinjau) | Masker URL |
---|---|---|
login | https://example.com/login | /<gateway> |
login | https://example.com/home/login | /home/<gateway> |
login | https://login.example.com | <gateway>.example.com |
login | https://login.home.example.com | <gateway>.home.example.com |
Membuat NEG tanpa server dengan masker URL
Konsol
Untuk load balancer baru, Anda dapat menggunakan proses end-to-end yang sama seperti yang dijelaskan sebelumnya dalam topik ini. Saat mengonfigurasi layanan backend, masukkan masker URL, bukan memilih layanan tertentu.
Jika memiliki load balancer yang sudah ada, Anda dapat mengedit konfigurasi backend dan membuat NEG serverless mengarah ke masker URL, bukan layanan tertentu.
Untuk menambahkan NEG tanpa server berbasis masker URL ke layanan backend yang ada:
- Buka halaman Load balancing di konsol Google Cloud .
Buka halaman Load balancing - Klik nama load balancer yang layanan backend-nya ingin Anda edit.
- Di halaman Load balancer details, klik Edit .
- Di halaman Edit global external Application Load Balancer, klik Backend configuration.
- Di halaman Backend configuration, klik Edit untuk layanan backend yang ingin Anda ubah.
- Klik Add backend.
- Pilih Create Serverless network endpoint group.
- Untuk Name, masukkan
helloworld-serverless-neg
. - Di bagian Region, pilih us-central1.
- Di bagian Serverless network endpoint group type, pilih
platform tempat aplikasi serverless (atau layanan atau fungsi)
Anda dibuat.
- Pilih Gunakan Masker URL.
- Masukkan masker URL. Untuk mengetahui petunjuk cara membuat mask URL, lihat Membuat mask URL.
- Klik Buat.
- Untuk Name, masukkan
- Di bagian New backend, klik Done.
- Klik Perbarui.
gcloud: Cloud Run
Untuk membuat NEG Tanpa Server dengan contoh masker URL example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-run-url-mask="example.com/<service>"
gcloud: Cloud Run functions
Untuk membuat NEG Tanpa Server dengan contoh masker URL example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --cloud-function-url-mask="example.com/<service>"
gcloud: App Engine
Untuk membuat NEG Tanpa Server dengan contoh masker URL
example.com/<service>
:
gcloud compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --app-engine-url-mask="example.com/<service>"
gcloud: API Gateway
Untuk membuat NEG Tanpa Server dengan contoh masker URL
example.com/<gateway>
:
gcloud beta compute network-endpoint-groups create helloworld-neg-mask \ --region=us-central1 \ --network-endpoint-type=serverless \ --serverless-deployment-platform=apigateway.googleapis.com \ --serverless-deployment-resource=my-gateway \ --serverless-deployment-url-mask="example.com/<gateway>"
Untuk mempelajari cara load balancer menangani masalah ketidakcocokan mask URL, lihat Memecahkan masalah terkait NEG serverless.
Pindahkan domain kustom Anda agar ditayangkan oleh Load Balancer Aplikasi eksternal
Jika aplikasi komputasi serverless Anda dipetakan ke domain kustom, sebaiknya perbarui data DNS agar traffic yang dikirim ke URL domain kustom Cloud Run, Cloud Run Functions, API Gateway, atau App Engine yang ada dirutekan melalui load balancer.
Misalnya, jika Anda memiliki domain kustom bernama example.com
dan semua layanan Cloud Run dipetakan ke domain ini, Anda harus memperbarui data DNS untuk example.com
agar mengarah ke alamat IP load balancer.
Sebelum memperbarui data DNS, Anda dapat menguji konfigurasi secara lokal dengan
memaksa resolusi DNS lokal dari domain kustom ke alamat IP load balancer. Untuk menguji secara lokal, ubah file /etc/hosts/
di mesin lokal Anda agar example.com
mengarah ke alamat IP load balancer, atau gunakan tanda curl --resolve
untuk memaksa curl
menggunakan alamat IP load balancer untuk permintaan.
Saat catatan DNS untuk example.com
di-resolve ke alamat IP load balancer HTTP(S), permintaan yang dikirim ke example.com
mulai dirutekan melalui load balancer. Load balancer mengirimkannya ke layanan backend yang relevan
sesuai dengan peta URL-nya. Selain itu, jika layanan backend dikonfigurasi dengan
masker URL, NEG serverless menggunakan masker untuk merutekan permintaan ke
layanan Cloud Run, Cloud Run Functions,
API Gateway, atau App Engine yang sesuai.
Enable Cloud CDN
Dengan mengaktifkan Cloud CDN untuk layanan Cloud Run, Anda dapat mengoptimalkan pengiriman konten dengan menyimpan konten ke dalam cache yang dekat dengan pengguna.
Anda dapat mengaktifkan Cloud CDN pada layanan backend yang digunakan oleh
Load Balancer Aplikasi eksternal global menggunakan perintah gcloud compute
backend-services update
.
gcloud compute backend-services update helloworld-backend-service
--enable-cdn
--global
Cloud CDN didukung untuk layanan backend dengan backend Cloud Run, fungsi Cloud Run, API Gateway, dan App Engine.
Mengaktifkan IAP di Load Balancer Aplikasi eksternal
Catatan: IAP tidak kompatibel dengan Cloud CDN.Anda dapat mengonfigurasi IAP agar
diaktifkan atau dinonaktifkan (default). Jika diaktifkan, Anda harus memberikan nilai untuk
oauth2-client-id
dan oauth2-client-secret
.
Untuk mengaktifkan IAP, perbarui layanan backend
untuk menyertakan tanda --iap=enabled
dengan oauth2-client-id
dan
oauth2-client-secret
.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \ --global
Secara opsional, Anda dapat mengaktifkan IAP untuk resource Compute Engine menggunakan Google Cloud konsol, gcloud CLI, atau API.
Mengaktifkan Google Cloud Armor
Google Cloud Armor adalah produk keamanan yang memberikan perlindungan terhadap serangan distributed denial of service (DDoS) ke semua load balancer proxy GCLB. Google Cloud Armor juga menyediakan kebijakan keamanan yang dapat dikonfigurasi untuk layanan yang diakses melalui Load Balancer Aplikasi eksternal. Untuk mempelajari kebijakan keamanan Google Cloud Armor untuk Load Balancer Aplikasi eksternal, lihat Ringkasan kebijakan keamanan Google Cloud Armor.
Jika menggunakan fungsi Cloud Run, Anda dapat memastikan bahwa permintaan yang dikirim ke URL default diblokir dengan menggunakan setelan ingress internal-and-gclb
.
Jika menggunakan Cloud Run, Anda dapat memastikan bahwa permintaan yang dikirim ke URL default atau domain kustom lainnya yang disiapkan melalui Cloud Run diblokir dengan membatasi ingress ke "internal dan cloud load balancing".
Jika menggunakan App Engine, Anda dapat menggunakan kontrol traffic masuk agar aplikasi Anda hanya menerima permintaan yang dikirim dari load balancer (dan VPC jika Anda menggunakannya).
Tanpa setelan ingress yang tepat, pengguna dapat menggunakan URL default aplikasi serverless Anda untuk mengabaikan load balancer, kebijakan keamanan Google Cloud Armor, sertifikat SSL, dan kunci pribadi yang diteruskan melalui load balancer.
Opsional: Konfigurasi kebijakan keamanan backend default. Kebijakan keamanan default membatasi traffic di atas batas yang dikonfigurasi pengguna. Untuk mengetahui informasi selengkapnya tentang kebijakan keamanan default, lihat Ringkasan pembatasan kapasitas.
- Untuk menonaktifkan kebijakan keamanan default Google Cloud Armor, pilih
None
di menu daftar kebijakan keamanan backend. - Di bagian Security, pilih Default security policy.
- Di kolom Nama kebijakan, terima nama yang dibuat secara otomatis atau masukkan nama untuk kebijakan keamanan Anda.
- Di kolom Jumlah permintaan, terima jumlah permintaan
default atau masukkan bilangan bulat antara
1
dan10,000
. - Di kolom Interval, pilih interval.
- Di kolom Terapkan pada kunci, pilih salah satu nilai berikut: Semua, Alamat IP, atau Alamat IP X-Forwarded-For. Untuk mengetahui informasi selengkapnya tentang opsi ini, lihat Mengidentifikasi klien untuk pembatasan kecepatan.
Mengaktifkan logging dan pemantauan
Anda dapat mengaktifkan, menonaktifkan, dan melihat log untuk layanan backend Load Balancer Aplikasi eksternal. Saat menggunakan konsol Google Cloud , logging diaktifkan secara default
untuk layanan backend dengan backend NEG serverless. Anda dapat menggunakan gcloud
untuk
menonaktifkan logging untuk setiap layanan backend sesuai kebutuhan. Untuk mengetahui petunjuknya, lihat
Logging.
Load balancer juga mengekspor data pemantauan ke Cloud Monitoring. Metrik pemantauan dapat digunakan untuk mengevaluasi konfigurasi, penggunaan, dan performa load balancer. Metrik juga dapat digunakan untuk memecahkan masalah dan meningkatkan pemanfaatan resource serta pengalaman pengguna. Untuk mengetahui petunjuknya, lihat Monitoring.
Memperbarui waktu tunggu keep-alive HTTP klien
Load balancer yang dibuat pada langkah sebelumnya telah dikonfigurasi dengan nilai default untuk waktu tunggu keep-alive HTTP klien.Untuk memperbarui waktu tunggu keep-alive HTTP klien, gunakan petunjuk berikut.
Konsol
Di konsol Google Cloud , buka halaman Load balancing.
- Klik nama load balancer yang ingin Anda ubah.
- Klik Edit.
- Klik Frontend configuration.
- Luaskan Fitur lanjutan. Untuk HTTP keepalive timeout, masukkan nilai waktu tunggu.
- Klik Perbarui.
- Untuk meninjau perubahan, klik Tinjau dan selesaikan, lalu klik Perbarui.
gcloud
Untuk load balancer HTTP, perbarui proxy HTTP target menggunakan
perintah gcloud compute target-http-proxies update
:
gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Untuk load balancer HTTPS, perbarui proxy HTTPS target menggunakan
perintah gcloud compute target-https-proxies update
:
gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \ --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \ --global
Ganti kode berikut:
TARGET_HTTP_PROXY_NAME
: nama proxy HTTP target.TARGET_HTTPS_PROXY_NAME
: nama proxy HTTPS target.HTTP_KEEP_ALIVE_TIMEOUT_SEC
: nilai waktu tunggu HTTP keep-alive dari 5 hingga 600 detik.
Mengaktifkan deteksi pencilan
Anda dapat mengaktifkan deteksi pencilan pada layanan backend global untuk mengidentifikasi NEG tanpa server yang tidak responsif dan mengurangi jumlah permintaan yang dikirim ke NEG tanpa server yang tidak responsif.
Deteksi pencilan diaktifkan pada layanan backend menggunakan salah satu metode berikut:
- Metode
consecutiveErrors
(outlierDetection.consecutiveErrors
), yang di dalamnya kode status HTTP seri5xx
memenuhi syarat sebagai error. - Metode
consecutiveGatewayFailure
(outlierDetection.consecutiveGatewayFailure
), yang hanya kode status HTTP502
,503
, dan504
yang memenuhi syarat sebagai error.
Gunakan langkah-langkah berikut untuk mengaktifkan deteksi pencilan untuk layanan backend yang ada. Perhatikan bahwa meskipun setelah mengaktifkan deteksi pencilan, beberapa permintaan dapat dikirim ke layanan yang tidak responsif dan menampilkan kode status 5xx
ke klien. Untuk lebih mengurangi rasio error, Anda dapat mengonfigurasi nilai yang lebih agresif untuk parameter deteksi pencilan. Untuk mengetahui informasi selengkapnya, lihat kolom
outlierDetection
.
Konsol
Di konsol Google Cloud , buka halaman Load balancing.
Klik nama load balancer yang layanan backend-nya ingin Anda edit.
Di halaman Load balancer details, klik
Edit.Di halaman Edit global external Application Load Balancer, klik Backend configuration.
Di halaman Backend configuration, klik
Edit untuk layanan backend yang ingin Anda ubah.Scroll ke bawah dan luaskan bagian Konfigurasi lanjutan.
Di bagian Deteksi pencilan, centang kotak Aktifkan.
Klik
Edit untuk mengonfigurasi deteksi anomali.Verifikasi bahwa opsi berikut dikonfigurasi dengan nilai ini:
Properti Nilai Error berturut-turut 5 Interval 1000 Waktu ejeksi dasar 30000 Maks persentase ejeksi 50 Error berturut-turut yang berlaku 100 Dalam contoh ini, analisis deteksi pencilan berjalan setiap satu detik. Jika jumlah kode status HTTP
5xx
berturut-turut yang diterima oleh proxy Envoy adalah lima atau lebih, endpoint backend akan dikeluarkan dari kumpulan penyeimbangan beban proxy Envoy tersebut selama 30 detik. Jika persentase penerapan ditetapkan ke 100%, layanan backend akan menerapkan penghapusan endpoint yang tidak responsif dari kumpulan load balancing proxy Envoy tertentu setiap kali analisis deteksi outlier berjalan. Jika kondisi pengeluaran terpenuhi, hingga 50% endpoint backend dari kumpulan load balancing dapat dikeluarkan.Klik Simpan.
Untuk memperbarui layanan backend, klik Update.
Untuk memperbarui load balancer, di halaman Edit global external Application Load Balancer, klik Update.
gcloud
Ekspor layanan backend ke file YAML.
gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME.yaml --global
Ganti
BACKEND_SERVICE_NAME
dengan nama layanan backend.Edit konfigurasi YAML layanan backend untuk menambahkan kolom deteksi anomali seperti yang ditandai dalam konfigurasi YAML berikut, di bagian
outlierDetection
:Dalam contoh ini, analisis deteksi pencilan berjalan setiap satu detik. Jika jumlah kode status HTTP
5xx
berturut-turut yang diterima oleh proxy Envoy adalah lima atau lebih, endpoint backend akan dikeluarkan dari kumpulan penyeimbangan beban proxy Envoy tersebut selama 30 detik. Jika persentase penerapan ditetapkan ke 100%, layanan backend akan menerapkan penghapusan endpoint yang tidak responsif dari kumpulan load balancing proxy Envoy tertentu setiap kali analisis deteksi outlier berjalan. Jika kondisi pengeluaran terpenuhi, hingga 50% endpoint backend dari kumpulan load balancing dapat dikeluarkan.name: BACKEND_SERVICE_NAME backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME - balancingMode: UTILIZATION capacityScaler: 1.0 group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2 outlierDetection: baseEjectionTime: nanos: 0 seconds: 30 consecutiveErrors: 5 enforcingConsecutiveErrors: 100 interval: nanos: 0 seconds: 1 maxEjectionPercent: 50 port: 80 selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME sessionAffinity: NONE timeoutSec: 30 ...
Ganti kode berikut:
BACKEND_SERVICE_NAME
: nama layanan backendPROJECT_ID
: ID project AndaREGION_A
danREGION_B
: region tempat load balancer telah dikonfigurasi.SERVERLESS_NEG_NAME
: nama NEG serverless pertamaSERVERLESS_NEG_NAME_2
: nama NEG serverless kedua
Perbarui layanan backend dengan mengimpor konfigurasi terbaru.
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME.yaml --global
Deteksi pencilan kini diaktifkan di layanan backend.
Menghapus NEG serverless
Grup endpoint jaringan tidak dapat dihapus jika terpasang ke layanan backend. Sebelum Anda menghapus NEG, pastikan NEG tersebut dilepaskan dari layanan backend.
Konsol
- Untuk memastikan NEG tanpa server yang ingin Anda hapus tidak sedang digunakan oleh layanan backend mana pun, buka tab Backend services di Load balancing advanced menu.
Buka tab Backend services - Jika NEG serverless sedang digunakan:
- Klik nama layanan backend menggunakan NEG serverless.
- Klik Edit .
- Dari daftar Backend, klik untuk menghapus backend NEG serverless dari layanan backend.
- Klik Simpan.
- Buka halaman Network endpoint group di konsol Google Cloud .
Buka halaman Network Endpoint Group - Centang kotak untuk NEG serverless yang ingin Anda hapus.
- Klik Hapus.
- Klik Delete lagi untuk mengonfirmasi.
gcloud
Untuk menghapus NEG tanpa server dari layanan backend, Anda harus menentukan
region tempat NEG dibuat. Anda juga harus menentukan flag --global
karena helloworld-backend-service
adalah resource global.
gcloud compute backend-services remove-backend helloworld-backend-service \ --network-endpoint-group=helloworld-serverless-neg \ --network-endpoint-group-region=us-central1 \ --global
Untuk menghapus NEG tanpa server:
gcloud compute network-endpoint-groups delete helloworld-serverless-neg \ --region=us-central1
Langkah berikutnya
- Menggunakan logging dan pemantauan
- Memecahkan masalah NEG tanpa server
- Membersihkan penyiapan load balancer
- Menggunakan modul Terraform untuk load balancer HTTPS eksternal dengan backend Cloud Run