Halaman ini memberikan ringkasan komprehensif tentang apa saja yang didukung dan dapat dikonfigurasi melalui Kubernetes Ingress di Google Cloud.
Perbandingan fitur
Tabel berikut berisi daftar fitur yang didukung untuk Ingress di Google Cloud. Ketersediaan fitur, Ketersediaan umum (GA) atau Beta juga ditunjukkan.
Class Ingress | Ingress Eksternal | Ingress Internal | Multi Cluster Ingress | ||
---|---|---|---|---|---|
Pengontrol ingress | Pengontrol Ingress yang dihosting Google | Pengontrol GKE Ingress | |||
Jenis load balancer Google Cloud | LB HTTP(S) Eksternal | LB HTTP(S) Internal | LB HTTP(S) Eksternal | ||
Cakupan cluster | Cluster tunggal | Cluster tunggal | Multi-cluster | ||
Cakupan load balancer | Global | Regional | Global | ||
Dukungan lingkungan | GKE | GKE | GKE | ||
Dukungan VPC Bersama | GA | GA | GA | ||
Anotasi layanan | |||||
Load Balancing Berbasis Container (NEG) | GA | GA | GA | ||
HTTPS dari load balancer ke backend | GA | GA | GA | ||
HTTP/2 | GA | GA Khusus TLS |
GA | ||
Anotasi ingress | |||||
Alamat IP statis | GA | GA | GA | ||
Sertifikat berbasis Secret Kubernetes | GA | GA | GA | ||
Sertifikat SSL yang dikelola sendiri | GA | GA | GA | ||
Sertifikat SSL yang dikelola Google | GA | GA | |||
FrontendConfig | |||||
Kebijakan SSL | GA | GA dengan Gateway | GA | ||
Pengalihan HTTP-ke-HTTPS | GA
1.17.13-gke.2600+GA |
GA | |||
BackendConfig | |||||
Waktu tunggu layanan backend | GA | GA | GA | ||
Cloud CDN | GA | GA | |||
Waktu tunggu pengosongan koneksi | GA | GA | GA | ||
Konfigurasi health check load balancer kustom | GA | GA | GA | ||
Kebijakan keamanan Google Cloud Armor | GA
1.19.10-gke.700G |
GA | |||
Konfigurasi logging akses HTTP | GA | GA | GA | ||
Identity-Aware Proxy (IAP) | GA | GA | GA | ||
Afinitas sesi | GA | GA | GA | ||
Header permintaan yang ditentukan pengguna | GA | GA | |||
Header respons kustom | GA | GA |
BFitur ini tersedia dalam versi beta mulai dari versi yang ditentukan. Fitur tanpa versi yang tercantum didukung untuk semua versi GKE dan GKE Enterprise yang tersedia.
GFitur ini didukung sebagai GA mulai dari versi yang ditentukan.
Mengonfigurasi Ingress menggunakan pengontrol default
Anda tidak dapat mengonfigurasi fitur LoadBalancer secara manual menggunakan Google Cloud SDK atau Google Cloud Console. Anda harus menggunakan resource Kubernetes BackendConfig atau FrontendConfig.
Saat membuat Ingress menggunakan pengontrol default, Anda dapat memilih jenis load balancer (Load Balancer Aplikasi eksternal atau Load Balancer Aplikasi internal) dengan menggunakan anotasi pada objek Ingress. Anda dapat memilih apakah GKE membuat NEG zonasi atau menggunakan grup instance dengan menggunakan anotasi pada setiap objek Service.
Dengan definisi resource kustom (CRD) FrontendConfig dan BackendConfig, Anda dapat menyesuaikan load balancer lebih lanjut. CRD ini memungkinkan Anda menentukan fitur load balancer tambahan secara hierarkis, dengan cara yang lebih terstruktur daripada anotasi. Untuk menggunakan Ingress (dan CRD ini), Anda harus mengaktifkan add-on load balancing HTTP. Cluster GKE mengaktifkan load balancing HTTP secara default; Anda tidak boleh menonaktifkannya.
FrontendConfigs direferensikan dalam objek Ingress dan hanya dapat digunakan dengan Ingress eksternal. BackendConfig direferensikan oleh objek Layanan. CRD yang sama dapat dirujuk oleh beberapa objek Service atau Ingress untuk konsistensi konfigurasi. CRD FrontendConfig dan BackendConfig memiliki siklus proses yang sama dengan resource Ingress dan Service yang sesuai, dan keduanya sering di-deploy secara bersamaan.
Mengaitkan FrontendConfig dengan Ingress Anda
FrontendConfig hanya dapat digunakan dengan Ingress Eksternal.
Masuk
Gunakan anotasi networking.gke.io/v1beta1.FrontendConfig
:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...
Ganti FRONTENDCONFIG_NAME
dengan nama FrontendConfig Anda.
Mengaitkan BackendConfig dengan Ingress Anda
Anda dapat menggunakan anotasi
cloud.google.com/backend-config
atau beta.cloud.google.com/backend-config
untuk menentukan nama BackendConfig.
BackendConfig yang sama untuk semua port Layanan
Agar dapat menggunakan BackendConfig yang sama untuk semua port, gunakan kunci default
dalam
anotasi. Pengontrol Ingress menggunakan BackendConfig yang sama setiap kali membuat layanan backend load balancer untuk mereferensikan salah satu port Layanan.
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...
BackendConfig unik per port Layanan
Anda dapat menentukan BackendConfig kustom untuk satu atau beberapa port menggunakan kunci yang cocok dengan nama atau nomor port. Pengontrol Ingress menggunakan BackendConfig khusus saat membuat layanan backend load balancer untuk port Service yang direferensikan.GKE 1.16-gke.3 dan yang lebih baru
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/backend-config: '{"ports": {
"SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
"SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
}}'
spec:
ports:
- name: PORT_NAME_1
port: PORT_NUMBER_1
protocol: TCP
targetPort: 50000
- name: PORT_NAME_2
port: PORT_NUMBER_2
protocol: TCP
targetPort: 8080
...
Semua versi yang didukung
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/backend-config: '{"ports": {
PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
}}'
spec:
ports:
- name: PORT_NAME_1
port: PORT_NUMBER_1
protocol: TCP
targetPort: 50000
- name: PORT_NAME_2
port: PORT_NUMBER_2
protocol: TCP
targetPort: 8080
...
Ganti kode berikut:
BACKENDCONFIG_REFERENCE_A
: nama BackendConfig yang ada.BACKENDCONFIG_REFERENCE_B
: nama BackendConfig yang ada.SERVICE_REFERENCE_A
: gunakan nilaiPORT_NUMBER_1
atauPORT_NAME_1
. Hal ini karena anotasi BackendConfig Layanan dapat merujuk ke nama port (spec.ports[].name
) atau nomor port (spec.ports[].port
).SERVICE_REFERENCE_B
: gunakan nilaiPORT_NUMBER_2
atauPORT_NAME_2
. Hal ini karena anotasi BackendConfig Layanan dapat merujuk ke nama port (spec.ports[].name
) atau nomor port (spec.ports[].port
).
Saat merujuk ke port Layanan berdasarkan nomor, Anda harus menggunakan nilai port
, bukan nilai targetPort
. Nomor port yang digunakan di sini hanya untuk mengikat BackendConfig; load balancer tidak mengontrol port mana yang menjadi tujuan pengiriman pemeriksaan traffic atau health check:
Saat menggunakanload balancing asal container , load balancer mengirimkan traffic ke endpoint di grup endpoint jaringan (cocok dengan alamat IP Pod) pada port Layanan yang direferensikan
targetPort
(yang harus cocok dengancontainerPort
untuk Pod yang aktif). Jika tidak, load balancing akan mengirimkan traffic ke alamat IP node padanodePort
port Layanan yang direferensikan.Saat menggunakan BackendConfig untuk menyediakan health check load balancer kustom, nomor port yang Anda gunakan untuk health check load balancer dapat berbeda dengan angka
spec.ports[].port
Layanan. Untuk mengetahui detail tentang nomor port untuk health check, lihat Konfigurasi health check kustom.
Mengonfigurasi fitur Ingress melalui parameter FrontendConfig
Bagian berikut menunjukkan cara menetapkan FrontendConfig untuk mengaktifkan fitur Ingress tertentu.
Kebijakan SSL
Kebijakan SSL memungkinkan Anda menentukan serangkaian versi dan cipher TLS yang digunakan load balancer untuk menghentikan traffic HTTPS dari klien. Anda harus membuat kebijakan SSL terlebih dahulu di luar GKE. Setelah dibuat, Anda dapat mereferensikannya dalam
CRD FrontendConfig
.
Kolom sslPolicy
di FrontendConfig
mereferensikan nama kebijakan SSL dalam project Google Cloud yang sama dengan
cluster GKE. Aplikasi ini melampirkan kebijakan SSL ke proxy HTTPS target,
yang dibuat untuk load balancer HTTP(S) eksternal oleh Ingress. Resource FrontendConfig dan kebijakan SSL yang sama dapat dirujuk oleh beberapa resource Ingress. Jika kebijakan SSL yang direferensikan diubah, perubahan tersebut akan diterapkan ke Google Front Ends (GFE) yang mendukung load balancer HTTP(S) eksternal yang dibuat oleh Ingress.
Manifes FrontendConfig berikut mengaktifkan kebijakan SSL bernama
gke-ingress-ssl-policy
:
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
name: my-frontend-config
spec:
sslPolicy: gke-ingress-ssl-policy
Pengalihan HTTP ke HTTPS
Load balancer HTTP eksternal dapat mengalihkan kembali permintaan HTTP yang tidak dienkripsi ke load balancer HTTPS yang menggunakan alamat IP yang sama. Saat Anda membuat Ingress dengan pengalihan kembali HTTP ke HTTPS diaktifkan, kedua load balancer ini akan dibuat secara otomatis. Permintaan ke alamat IP eksternal Ingress pada port 80 secara otomatis dialihkan kembali ke alamat IP eksternal yang sama pada port 443. Fungsi ini dibuat berdasarkan pengalihan ulang HTTP ke HTTPS yang disediakan oleh Cloud Load Balancing.
Untuk mendukung pengalihan ulang HTTP ke HTTPS, Ingress harus dikonfigurasi untuk mengakomodir traffic HTTP dan HTTPS. Jika HTTP atau HTTPS dinonaktifkan, pengalihan ulang tidak akan berfungsi.
Pengalihan ulang HTTP ke HTTPS dikonfigurasi menggunakan kolom redirectToHttps
di
resource kustom FrontendConfig
. Pengalihan ulang diaktifkan untuk seluruh resource Ingress,
sehingga semua layanan yang dirujuk oleh Ingress akan mengaktifkan pengalihan
HTTPS.
Manifes FrontendConfig
berikut memungkinkan pengalihan kembali HTTP ke HTTPS. Tetapkan kolom
spec.redirectToHttps.enabled
ke true
untuk mengaktifkan pengalihan ulang HTTPS. Kolom
spec.responseCodeName
bersifat opsional. Jika dihilangkan, pengalihan kembali Moved
Permanently
301 akan digunakan.
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
name: my-frontend-config
spec:
redirectToHttps:
enabled: true
responseCodeName: RESPONSE_CODE
Ganti RESPONSE_CODE
dengan salah satu dari berikut ini:
MOVED_PERMANENTLY_DEFAULT
untuk menampilkan kode respons pengalihan ulang 301 (default jikaresponseCodeName
tidak ditentukan).FOUND
untuk menampilkan kode respons pengalihan ulang 302.SEE_OTHER
untuk menampilkan kode respons pengalihan ulang 303.TEMPORARY_REDIRECT
untuk menampilkan kode respons pengalihan ulang 307.PERMANENT_REDIRECT
untuk menampilkan kode respons pengalihan ulang 308.
Saat pengalihan ulang diaktifkan, pengontrol Ingress akan membuat load balancer seperti yang ditampilkan pada diagram berikut:
Untuk memvalidasi bahwa pengalihan ulang Anda berfungsi, gunakan perintah curl
:
curl http://IP_ADDRESS
Ganti IP_ADDRESS
dengan alamat IP Ingress Anda.
Respons menunjukkan kode respons pengalihan ulang yang Anda konfigurasi. Misalnya, contoh berikut adalah untuk FrontendConfig
yang dikonfigurasi dengan pengalihan ulang 301: MovedPermanently
:
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>
Mengonfigurasi fitur Ingress melalui parameter BackendConfig
Bagian berikut menunjukkan cara menetapkan BackendConfig untuk mengaktifkan fitur Ingress tertentu. Perubahan pada resource BackendConfig terus-menerus direkonsiliasi, sehingga Anda tidak perlu menghapus dan membuat ulang Ingress untuk melihat bahwa perubahan BackendConfig terwakili.
Untuk mengetahui informasi tentang batasan BackendConfig, lihat bagian batasan.
Waktu tunggu layanan backend
Anda dapat menggunakan BackendConfig untuk menetapkan periode waktu tunggu layanan backend dalam hitungan detik. Jika Anda tidak menentukan nilai, nilai defaultnya adalah 30 detik.
Manifes BackendConfig berikut menetapkan waktu tunggu 40 detik:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
timeoutSec: 40
Cloud CDN
Anda dapat mengaktifkan Cloud CDN menggunakan BackendConfig.
Manifes BackendConfig berikut menampilkan semua kolom yang tersedia saat mengaktifkan Cloud CDN:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
cdn:
enabled: CDN_ENABLED
cachePolicy:
includeHost: INCLUDE_HOST
includeProtocol: INCLUDE_PROTOCOL
includeQueryString: INCLUDE_QUERY_STRING
queryStringBlacklist: QUERY_STRING_DENYLIST
queryStringWhitelist: QUERY_STRING_ALLOWLIST
cacheMode: CACHE_MODE
clientTtl: CLIENT_TTL
defaultTtl: DEFAULT_TTL
maxTtl: MAX_TTL
negativeCaching: NEGATIVE_CACHING
negativeCachingPolicy:
code: NEGATIVE_CACHING_CODE
ttl: NEGATIVE_CACHING_TTL
requestCoalescing: REQ_COALESCING
serveWhileStale: SERVE_WHILE_STALE
signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
signedUrlKeys:
keyName: KEY_NAME
keyValue: KEY_VALUE
secretName: SECRET_NAME
Ganti kode berikut:
CDN_ENABLED
: Jika ditetapkan ketrue
, Cloud CDN akan diaktifkan untuk backend Ingress ini.INCLUDE_HOST
: Jika ditetapkan ketrue
, permintaan ke host yang berbeda akan disimpan dalam cache secara terpisah.INCLUDE_PROTOCOL
: Jika ditetapkan ketrue
, permintaan HTTP dan HTTPS akan disimpan dalam cache secara terpisah.INCLUDE_QUERY_STRING
: Jika ditetapkan ketrue
, parameter string kueri akan disertakan dalam kunci cache sesuai denganqueryStringBlacklist
atauqueryStringWhitelist
. Jika keduanya tidak ditetapkan, seluruh string kueri akan disertakan. Jika ditetapkan kefalse
, seluruh string kueri akan dikecualikan dari kunci cache.QUERY_STRING_DENYLIST
: Menentukan array string dengan nama parameter string kueri yang akan dikecualikan dari kunci cache. Semua parameter lainnya disertakan. Anda dapat menentukanqueryStringBlacklist
atauqueryStringWhitelist
, tetapi tidak keduanya.QUERY_STRING_ALLOWLIST
: Menentukan array string dengan nama parameter string kueri yang akan disertakan dalam kunci cache. Semua parameter lainnya dikecualikan. Anda dapatqueryStringBlacklist
atauqueryStringWhitelist
, tetapi tidak keduanya.
Kolom berikut hanya didukung di GKE versi 1.23.3-gke.900 dan yang lebih baru menggunakan GKE Ingress. Class tersebut tidak didukung menggunakan Multi Cluster Ingress:
CACHE_MODE
: Mode cache.CLIENT_TTL
,DEFAULT_TTL
, danMAX_TTL
: Konfigurasi TTL. Untuk mengetahui informasi selengkapnya, lihat Menggunakan setelan dan penggantian TTL.NEGATIVE_CACHING
: Jika ditetapkan ketrue
, caching negatif akan diaktifkan. Untuk informasi selengkapnya, lihat Menggunakan caching negatif.NEGATIVE_CACHING_CODE
danNEGATIVE_CACHING_TTL
: Konfigurasi caching negatif. Untuk informasi selengkapnya, lihat Menggunakan caching negatif.REQ_COALESCING
: Jika ditetapkan ketrue
, penyingkatan akan diaktifkan. Untuk mengetahui informasi selengkapnya, lihat Permintaan diciutkan (penggabungan).SERVE_WHILE_STALE
: Waktu, dalam detik, setelah respons berakhir saat Cloud CDN terus menayangkan versi yang tidak berlaku. Untuk informasi selengkapnya, lihat Menayangkan konten yang tidak berlaku.SIGNED_MAX_AGE
: Respons waktu maksimum dapat di-cache, dalam detik. Untuk informasi selengkapnya, lihat Menyesuaikan waktu cache maksimum secara opsional.KEY_NAME
,KEY_VALUE
, danSECRET_NAME
: Konfigurasi kunci URL yang ditandatangani. Untuk mengetahui informasi selengkapnya, lihat Membuat kunci permintaan yang ditandatangani.
Luaskan bagian berikut untuk melihat contoh yang men-deploy Cloud CDN melalui Ingress, lalu memvalidasi bahwa konten aplikasi sedang di-cache.
Waktu tunggu pengosongan koneksi
Anda dapat mengonfigurasi waktu tunggu pengosongan koneksi menggunakan BackendConfig. Waktu tunggu pengosongan koneksi adalah waktu, dalam detik, untuk menunggu koneksi dikosongkan. Untuk durasi waktu tunggu yang ditentukan, permintaan yang ada ke backend yang dihapus diberi waktu untuk diselesaikan. Load balancer tidak mengirim permintaan baru ke backend yang dihapus. Setelah durasi waktu tunggu tercapai, semua koneksi yang tersisa ke backend akan ditutup. Durasi waktu tunggu bisa dari 0 hingga 3600 detik. Nilai default adalah 0, yang juga menonaktifkan pengosongan koneksi.
Manifes BackendConfig berikut menentukan waktu tunggu yang menghabiskan koneksi selama 60 detik:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
connectionDraining:
drainingTimeoutSec: 60
Konfigurasi health check kustom
Ada berbagai cara GKE mengonfigurasi health check load balancer Google Cloud saat melakukan deployment melalui Ingress. Untuk mempelajari lebih lanjut cara GKE Ingress men-deploy health check, lihat Health check Ingress.
BackendConfig memungkinkan Anda mengontrol setelan health check load balancer dengan akurat.
Anda dapat mengonfigurasi beberapa Layanan GKE untuk mereferensikan BackendConfig yang sama sebagai template yang dapat digunakan kembali. Untuk parameter healthCheck
, health check Google Cloud unik dibuat untuk setiap layanan backend yang sesuai dengan setiap Layanan GKE.
Manifes BackendConfig berikut menampilkan semua kolom yang tersedia saat mengonfigurasi health check BackendConfig:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
healthCheck:
checkIntervalSec: INTERVAL
timeoutSec: TIMEOUT
healthyThreshold: HEALTH_THRESHOLD
unhealthyThreshold: UNHEALTHY_THRESHOLD
type: PROTOCOL
requestPath: PATH
port: PORT
Ganti kode berikut:
INTERVAL
: Menentukancheck-interval
, dalam detik, untuk setiap pemeriksaan health check. Ini adalah waktu dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Jika Anda menghilangkan parameter ini, default Google Cloud selama 5 detik akan digunakan. Untuk detail penerapan tambahan, lihat Beberapa pemeriksaan dan frekuensi.TIMEOUT
: Menentukan lamanya waktu Google Cloud menunggu respons terhadap pemeriksaan. NilaiTIMEOUT
harus kurang dari atau sama denganINTERVAL
. Unit dalam hitungan detik. Setiap pemeriksaan memerlukan kode responsHTTP 200 (OK)
untuk dikirimkan sebelum waktu tunggu pemeriksaan.HEALTH_THRESHOLD
danUNHEALTHY_THRESHOLD
: Menentukan jumlah upaya koneksi berurutan yang harus berhasil atau gagal, untuk sedikitnya satu masalah, untuk mengubah status respons dari sehat ke tidak sehat atau sebaliknya. Jika Anda menghilangkan salah satu parameter ini, Google Cloud akan menggunakan nilai default 2.PROTOCOL
: Menentukan protokol yang digunakan oleh sistem probe untuk health check.BackendConfig
hanya mendukung pembuatan health check menggunakan protokol HTTP, HTTPS, atau HTTP2. Untuk mengetahui informasi selengkapnya, lihat Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2. Anda tidak dapat menghilangkan parameter ini.PATH
: Untuk health check HTTP, HTTPS, atau HTTP2, tentukanrequest-path
yang harus terhubung ke sistem pemeriksaan. Jika Anda menghapus parameter ini, Google Cloud akan menggunakan default/
.PORT
: BackendConfig hanya mendukung penentuan port health check load balancer dengan menggunakan nomor port. Jika Anda menghapus parameter ini, Google Cloud akan menggunakan nilai default80
.Saat menggunakan penyeimbangan beban native container, Anda harus memilih port yang cocok dengan
containerPort
Pod penayangan (terlepas dari apakahcontainerPort
direferensikan olehtargetPort
dari Layanan). Karena load balancer mengirimkan pemeriksaan ke alamat IP Pod secara langsung, Anda tidak dibatasi padacontainerPort
yang dirujuk olehtargetPort
Layanan. Sistem pemeriksaan health check terhubung ke alamat IP Pod yang melayani di port yang Anda tentukan.Misalnya backend grup instance, Anda harus memilih port yang cocok dengan
nodePort
yang diekspos oleh Layanan. Sistem pemeriksaan health check kemudian terhubung ke setiap node pada port tersebut.
Untuk menyiapkan GKE Ingress dengan health check HTTP kustom, lihat GKE Ingress dengan health check HTTP kustom.
Kebijakan keamanan Ingress Google Cloud Armor
Kebijakan keamanan Google Cloud Armor membantu melindungi aplikasi ber-load balancer dari serangan berbasis web. Setelah mengonfigurasi kebijakan keamanan Google Cloud Armor, Anda dapat mereferensikannya menggunakan BackendConfig.
Tambahkan nama kebijakan keamanan Anda ke BackendConfig. Manifes BackendConfig berikut menentukan kebijakan keamanan bernama example-security-policy
:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
namespace: cloud-armor-how-to
name: my-backendconfig
spec:
securityPolicy:
name: "example-security-policy"
Dua Sumber Kebenaran
Meskipun dikonfigurasi melalui GKE, API BackendService
Compute Engine yang mendasarinya masih dapat digunakan untuk langsung mengubah kebijakan keamanan mana yang akan diterapkan. Langkah ini akan menghasilkan dua sumber tepercaya:
GKE dan Compute Engine. Perilaku Pengontrol Ingress GKE sebagai respons terhadap kolom securityPolicy
dalam BackendConfig
didokumentasikan dalam tabel di bawah. Untuk menghindari konflik dan perilaku yang tidak terduga, sebaiknya gunakan GKE BackendConfig
untuk pengelolaan kebijakan keamanan yang akan digunakan.
Kolom BackendConfig | Nilai | Perilaku |
---|---|---|
spec.securityPolicy.name |
CloudArmorPolicyName |
Pengontrol GKE Ingress menetapkan kebijakan Google Cloud Armor bernama CloudArmorPolicyName ke load balancer. Pengontrol GKE Ingress menimpa kebijakan apa pun yang sebelumnya ditetapkan. |
spec.securityPolicy.name |
String kosong ("" ) |
Pengontrol Ingress GKE menghapus kebijakan Google Cloud Armor yang dikonfigurasi dari load balancer. |
spec.securityPolicy |
nil |
Pengontrol GKE Ingress menggunakan konfigurasi yang ditetapkan pada objek BackendService yang dikonfigurasi melalui Compute Engine API menggunakan Konsol Google Cloud, atau gcloud CLI, atau Terraform. |
Untuk menyiapkan Ingress GKE dengan perlindungan Google Cloud Armor, lihat Ingress dengan dukungan Google Cloud Armor.
Logging akses HTTP
Ingress dapat mencatat semua permintaan HTTP dari klien ke Cloud Logging. Anda dapat mengaktifkan dan menonaktifkan logging akses menggunakan BackendConfig bersama dengan menetapkan frekuensi sampling logging akses.
Untuk mengonfigurasi logging akses, gunakan kolom logging
di BackendConfig. Jika
logging
dihilangkan, logging akses akan menggunakan perilaku default. Hal ini bergantung pada versi GKE.
Anda dapat mengonfigurasi kolom berikut:
enable
: Jika ditetapkan ketrue
, logging akses akan diaktifkan untuk Ingress ini dan log tersedia di Cloud Logging. Jika tidak, logging akses akan dinonaktifkan untuk Ingress ini.sampleRate
: Menentukan nilai dari 0,0 hingga 1,0. di mana 0,0 berarti tidak ada paket yang dicatat ke dalam log, dan 1,0 berarti 100% paket dicatat ke dalam log. Kolom ini hanya relevan jikaenable
ditetapkan ketrue
.sampleRate
adalah kolom opsional, tetapi jika dikonfigurasi,enable: true
juga harus ditetapkan atau kolom ini akan ditafsirkan sebagaienable: false
.
Manifes BackendConfig berikut mengaktifkan logging akses dan menetapkan frekuensi sampel ke 50% permintaan HTTP untuk resource Ingress tertentu:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
logging:
enable: true
sampleRate: 0.5
Identity-Aware Proxy
Guna mengonfigurasi BackendConfig untuk
Identity-Aware Proxy IAP,
Anda harus menentukan nilai enabled
dan secretName
ke blok iap
di BackendConfig. Untuk menentukan nilai ini, pastikan Anda memiliki izin compute.backendServices.update
.
Manifes BackendConfig berikut mengaktifkan Identity-Aware Proxy:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
iap:
enabled: true
oauthclientCredentials:
secretName: my-secret
Mengaktifkan IAP dengan Klien OAuth Terkelola Google
Mulai GKE 1.29.2-gke.1035000, IAP dapat dikonfigurasi untuk menggunakan Klien OAuth yang Dikelola Google menggunakan BackendConfig. Untuk memutuskan apakah akan menggunakan Klien Google OAuth atau Klien OAuth kustom, lihat Kapan harus menggunakan konfigurasi OAuth kustom dalam dokumentasi IAP.
Untuk mengaktifkan IAP dengan Klien OAuth Terkelola Google, jangan berikan OAuthCredentials di BackendConfig. Bagi pengguna yang telah mengonfigurasi IAP menggunakan OAuthCredentials tidak ada jalur migrasi untuk beralih menggunakan Klien OAuth Terkelola Google, Anda harus membuat ulang Backend (hapus Layanan dari Ingress dan lampirkan kembali). Sebaiknya lakukan operasi ini selama masa pemeliharaan karena akan menyebabkan periode nonaktif. Jalur migrasi yang sebaliknya dapat dilakukan untuk beralih dari OAuthClient yang Dikelola Google ke OAuthCredentials.
Manifes BackendConfig berikut mengaktifkan Identity-Aware Proxy dengan Klien OAuth yang Dikelola Google:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
iap:
enabled: true
Untuk mengetahui petunjuk lengkapnya, baca bagian Mengaktifkan IAP untuk GKE dalam dokumentasi IAP.
Identity-Aware Proxy dengan Ingress internal
Untuk mengonfigurasi Ingress internal untuk IAP, Anda harus menggunakan Paket Premium. Jika tidak menggunakan Paket Premium, Anda tidak dapat melihat atau membuat Load Balancer Aplikasi internal dengan Identity-Aware Proxy. Anda juga harus memiliki langganan BeyondCorp Enterprise untuk menggunakan Ingress internal untuk IAP.
Untuk menyiapkan Ingress GKE yang aman dengan autentikasi berbasis Identity-Aware Proxy, lihat contoh, Ingress yang mengaktifkan IAP.
Afinitas sesi
Anda dapat menggunakan BackendConfig untuk menetapkan afinitas sesi ke IP klien atau cookie yang dihasilkan.
Afinitas IP klien
Untuk menggunakan BackendConfig guna menetapkan
afinitas IP klien,
tetapkan affinityType
ke "CLIENT_IP"
, seperti dalam contoh berikut:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
sessionAffinity:
affinityType: "CLIENT_IP"
Afinitas berbasis cookie
Untuk menggunakan BackendConfig untuk menetapkan
afinitas cookie yang dihasilkan,
tetapkan affinityType
ke
GENERATED_COOKIE
di manifes BackendConfig. Anda juga dapat menggunakan
affinityCookieTtlSec
untuk menetapkan jangka waktu cookie agar tetap aktif.
Manifes berikut menetapkan jenis afinitas untuk cookie yang dihasilkan dan memberikan TTL selama 50 detik kepada cookie:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
sessionAffinity:
affinityType: "GENERATED_COOKIE"
affinityCookieTtlSec: 50
Header permintaan yang ditentukan pengguna
Anda dapat menggunakan BackendConfig untuk mengonfigurasi header permintaan yang ditentukan pengguna. Load balancer menambahkan header yang Anda tentukan ke permintaan yang diteruskan ke backend.
Untuk mengaktifkan header permintaan yang ditentukan pengguna, tentukan daftar header dalam
properti customRequestHeaders
resource BackendConfig. Tentukan setiap
header sebagai string header-name:header-value
.
Manifes BackendConfig berikut menambahkan tiga header permintaan:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
customRequestHeaders:
headers:
- "X-Client-Region:{client_region}"
- "X-Client-City:{client_city}"
- "X-Client-CityLatLong:{client_city_lat_long}"
Header respons kustom
Untuk mengaktifkan header respons kustom, tentukan daftar header di
properti customResponseHeaders
dari resource BackendConfig. Tentukan setiap
header sebagai string header-name:header-value
.
Manifes BackendConfig berikut adalah contoh untuk menambahkan header respons HTTP Strict Transport Security (HSTS):
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
customResponseHeaders:
headers:
- "Strict-Transport-Security: max-age=28800; includeSubDomains"
Latihan: Menetapkan waktu tunggu Ingress menggunakan layanan backend
Latihan berikut menunjukkan langkah-langkah yang diperlukan untuk mengonfigurasi waktu tunggu dan pengosongan koneksi menggunakan Ingress dengan resource BackendConfig.
Untuk mengonfigurasi properti backend sebuah Ingress, selesaikan tugas berikut:
- Membuat Deployment.
- Buat BackendConfig.
- Buat Layanan, dan kaitkan salah satu port-nya dengan BackendConfig.
- Buat Ingress, dan kaitkan Ingress dengan pasangan (Service, port).
- Validasi properti layanan backend.
- Pembersihan.
Membuat Deployment
Sebelum membuat BackendConfig dan Layanan, Anda perlu membuat Deployment.
Contoh manifes berikut adalah untuk Deployment yang bernama
my-deployment.yaml
:
# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
selector:
matchLabels:
purpose: bsc-config-demo
replicas: 2
template:
metadata:
labels:
purpose: bsc-config-demo
spec:
containers:
- name: hello-app-container
image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Buat Deployment dengan menjalankan perintah berikut:
kubectl apply -f my-deployment.yaml
Membuat BackendConfig
Gunakan BackendConfig untuk menentukan fitur Ingress yang ingin digunakan.
Manifes BackendConfig, yang bernama my-backendconfig.yaml
, menentukan:
- Waktu tunggu 40 detik.
- Waktu tunggu yang menguras koneksi berdurasi 60 detik.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
timeoutSec: 40
connectionDraining:
drainingTimeoutSec: 60
Buat BackendConfig dengan menjalankan perintah berikut:
kubectl apply -f my-backendconfig.yaml
Membuat Layanan
BackendConfig sesuai dengan kombinasi Service-Port tunggal, meskipun Layanan memiliki beberapa port. Setiap port dapat dikaitkan dengan satu CRD BackendConfig. Jika port Service direferensikan oleh Ingress, dan jika port Service dikaitkan dengan BackendConfig, layanan backend load balancing HTTP(S) akan mengambil sebagian dari konfigurasinya dari BackendConfig.
Berikut adalah contoh manifes Layanan bernama my-service.yaml
:
# my-service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
purpose: bsc-config-demo
annotations:
cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
cloud.google.com/neg: '{"ingress": true}'
spec:
type: ClusterIP
selector:
purpose: bsc-config-demo
ports:
- port: 80
protocol: TCP
targetPort: 8080
Anotasi cloud.google.com/backend-config
menentukan pemetaan antara port
dan objek BackendConfig. Di my-service.yaml
:
- Setiap Pod yang memiliki label
purpose: bsc-config-demo
adalah anggota Layanan. - Port TCP 80 Layanan dikaitkan dengan BackendConfig yang bernama
my-backendconfig
. Anotasicloud.google.com/backend-config
menentukan ini. - Permintaan yang dikirim ke port 80 Layanan diteruskan ke salah satu Pod anggota pada port 8080.
Untuk membuat skrip yang dimaksud, jalankan perintah berikut:
kubectl apply -f my-service.yaml
Membuat Ingress
Berikut ini adalah manifes Ingress bernama my-ingress.yaml.
. Dalam
contoh ini, permintaan masuk dirutekan ke port 80 Layanan bernama
my-service
.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: my-service
port:
number: 80
Untuk membuat skrip yang dimaksud, jalankan perintah berikut:
kubectl apply -f my-ingress.yaml
Tunggu beberapa menit hingga pengontrol Ingress mengonfigurasi Load Balancer Aplikasi eksternal dan layanan backend terkait. Setelah selesai, Anda telah mengonfigurasi Ingress untuk menggunakan waktu tunggu 40 detik dan waktu tunggu 60 detik yang menguras koneksi.
Memvalidasi properti layanan backend
Anda dapat memvalidasi bahwa setelan load balancer yang benar telah diterapkan melalui BackendConfig. Untuk melakukannya, identifikasi layanan backend yang telah di-deploy Ingress dan periksa setelannya untuk memvalidasi bahwa setelan tersebut cocok dengan manifes Deployment.
Pertama, jelaskan resource my-ingress
dan filter untuk anotasi yang
mencantumkan layanan backend yang terkait dengan Ingress. Contoh:
kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends
Anda akan melihat output yang mirip dengan berikut ini:
ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}
Output tersebut memberikan informasi tentang layanan backend Anda. Misalnya, anotasi ini berisi dua layanan backend:
"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY"
memberikan informasi tentang layanan backend yang terkait dengan Layanan Kubernetesmy-service
.k8s1-27fde173
adalah hash yang digunakan untuk mendeskripsikan cluster.default
adalah namespace Kubernetes.HEALTHY
menunjukkan bahwa backend responsif.
"k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"
memberikan informasi tentang layanan backend yang terkait dengan backend default (404-server).k8s1-27fde173
adalah hash yang digunakan untuk mendeskripsikan cluster.kube-system
adalah namespace.default-http-backend
adalah nama Layanan Kubernetes.80
adalah port host.HEALTHY
menunjukkan bahwa backend responsif.
Selanjutnya, periksa layanan backend yang terkait dengan my-service
menggunakan gcloud
.
Filter "drainingTimeoutSec"
dan "timeoutSec"
untuk mengonfirmasi bahwa keduanya telah
ditetapkan di control plane Load Balancer Google Cloud. Contoh:
# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500
# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"
Output:
drainingTimeoutSec: 60
timeoutSec: 40
Melihat drainingTimeoutSec
dan timeoutSec
dalam output mengonfirmasi bahwa nilainya
telah ditetapkan dengan benar melalui BackendConfig.
Pembersihan
Untuk mencegah tagihan yang tidak diinginkan pada akun Anda, hapus objek Kubernetes yang Anda buat untuk latihan ini:
kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment
Batasan BackendConfig
BackendConfig memiliki batasan berikut:
- Hanya satu pasangan (Service, port) yang hanya dapat menggunakan satu BackendConfig, meskipun beberapa objek Ingress mereferensikan (Service, port). Artinya, semua objek Ingress yang mereferensikan (Layanan, port) yang sama harus menggunakan konfigurasi yang sama untuk Google Cloud Armor, IAP, dan Cloud CDN.
- IAP dan Cloud CDN tidak dapat diaktifkan untuk layanan backend Load Balancing HTTP(S) yang sama. Ini berarti Anda tidak dapat mengonfigurasi IAP dan Cloud CDN di BackendConfig yang sama.
- Anda harus menggunakan
kubectl
1.7 atau yang lebih baru untuk berinteraksi dengan BackendConfig.
Menghapus konfigurasi yang ditetapkan di FrontendConfig atau BackendConfig
Untuk mencabut fitur Ingress, Anda harus secara eksplisit menonaktifkan konfigurasi fitur di FrontendConfig atau BackendConfig CRD. Pengontrol Ingress hanya merekonsiliasi konfigurasi yang ditentukan dalam CRD ini.
Untuk menghapus atau menonaktifkan konfigurasi yang sebelumnya diaktifkan, tetapkan nilai kolom ke string kosong (""
) atau ke nilai Boolean false
, bergantung pada jenis kolomnya.
Manifes BackendConfig berikut menonaktifkan kebijakan keamanan Google Cloud Armor dan Cloud CDN:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backendconfig
spec:
cdn:
enabled: false
securityPolicy:
name: ""
Menghapus FrontendConfig atau BackendConfig
FrontendConfig
Untuk menghapus FrontendConfig, ikuti langkah-langkah berikut:
Hapus nama FrontendConfig dari anotasi
networking.gke.io/v1beta1.FrontendConfig
dalam manifes Ingress.Terapkan manifes Ingress yang diubah ke cluster Anda. Misalnya, gunakan
kubectl apply
.Menghapus FrontendConfig. Misalnya, gunakan
kubectl delete frontendconfig config my-frontendconfig
.
BackendConfig
Untuk menghapus BackedConfiq, ikuti langkah-langkah berikut:
Hapus nama BackendConfig dari anotasi
cloud.google.com/backend-config
di manifes Layanan.Terapkan manifes Layanan yang diubah ke cluster Anda. Misalnya, gunakan
kubectl apply
.Menghapus BackendConfig. Misalnya, gunakan
kubectl delete backendconfig my-backendconfig
.
Pemecahan masalah
Anda dapat mendeteksi kesalahan konfigurasi umum menggunakan Alat diagnostik Ingress. Anda juga harus memastikan bahwa setiap health check dikonfigurasi dengan benar.
BackendConfig tidak ditemukan
Error ini terjadi saat BackendConfig untuk port Layanan ditentukan dalam anotasi Layanan, tetapi resource BackendConfig yang sebenarnya tidak dapat ditemukan.
Untuk mengevaluasi peristiwa Kubernetes, jalankan perintah berikut:
kubectl get event
Contoh output berikut menunjukkan BackendConfig tidak ditemukan:
KIND ... SOURCE
Ingress ... loadbalancer-controller
MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists
Untuk mengatasi masalah ini, pastikan Anda tidak membuat resource BackendConfig di namespace yang salah atau salah mengeja referensinya di anotasi Service.
Kebijakan keamanan Ingress tidak ditemukan
Setelah objek Ingress dibuat, jika kebijakan keamanan tidak dikaitkan dengan benar dengan Layanan LoadBalancer, evaluasi peristiwa Kubernetes untuk melihat apakah ada kesalahan konfigurasi. Jika BackendConfig menentukan kebijakan keamanan yang tidak ada, peristiwa peringatan akan dikeluarkan secara berkala.
Untuk mengevaluasi peristiwa Kubernetes, jalankan perintah berikut:
kubectl get event
Contoh output berikut menunjukkan kebijakan keamanan Anda tidak ditemukan:
KIND ... SOURCE
Ingress ... loadbalancer-controller
MESSAGE
Error during sync: The given security policy "my-policy" does not exist.
Untuk mengatasi masalah ini, tentukan nama kebijakan keamanan yang benar di BackendConfig.
Mengatasi 500 error seri dengan NEG selama penskalaan workload di GKE
Gejala:
Saat menggunakan NEG yang disediakan GKE untuk load balancing, Anda mungkin mengalami error 502 atau 503 untuk layanan selama penurunan skala beban kerja. Error 502 terjadi saat Pod dihentikan sebelum koneksi yang ada ditutup, sedangkan error 503 terjadi saat traffic diarahkan ke Pod yang dihapus.
Masalah ini dapat memengaruhi cluster jika Anda menggunakan produk load balancing terkelola GKE yang menggunakan NEG, termasuk Gateway, Ingress, dan NEG mandiri. Jika Anda sering menskalakan workload, cluster Anda akan berisiko lebih tinggi terpengaruh.
Diagnosis:
Menghapus Pod di Kubernetes tanpa menguras endpoint-nya dan menghapusnya dari NEG akan terlebih dahulu menyebabkan error seri 500. Untuk menghindari masalah selama penghentian Pod, Anda harus mempertimbangkan urutan operasi. Gambar berikut
menampilkan skenario jika BackendService Drain Timeout
tidak disetel dan
BackendService Drain Timeout
ditetapkan dengan BackendConfig
.
Skenario 1: BackendService Drain Timeout
tidak disetel.
Gambar berikut menampilkan skenario saat BackendService Drain Timeout
tidak ditetapkan.
Skenario 2: BackendService Drain Timeout
ditetapkan.
Gambar berikut menampilkan skenario saat BackendService Drain Timeout
ditetapkan.
Waktu persis terjadinya error deret 500 bergantung pada faktor-faktor berikut:
Latensi pelepasan NEG API: Latensi pelepasan NEG API menunjukkan waktu saat ini yang diperlukan untuk menyelesaikan operasi pelepasan di Google Cloud. Hal ini dipengaruhi oleh berbagai faktor di luar Kubernetes, termasuk jenis load balancer dan zona tertentu.
Latensi pengurasan: Latensi pengosongan menunjukkan waktu yang dibutuhkan load balancer untuk mulai mengalihkan traffic dari bagian tertentu dalam sistem Anda. Setelah pengosongan dimulai, load balancer berhenti mengirim permintaan baru ke endpoint, tetapi masih ada latensi dalam memicu pengosongan (Drain Latency) yang dapat menyebabkan error 503 sementara jika Pod sudah tidak ada lagi.
Konfigurasi health check: Batas health check yang lebih sensitif mengurangi durasi error 503 karena dapat memberikan sinyal kepada load balancer untuk berhenti mengirim permintaan ke endpoint meskipun operasi pelepasan belum selesai.
Masa tenggang penghentian: Masa tenggang penghentian menentukan durasi maksimum Pod untuk keluar. Namun, Pod dapat keluar sebelum masa tenggang penghentian selesai. Jika Pod memerlukan waktu lebih lama dari periode ini, Pod akan dipaksa untuk keluar pada akhir periode ini. Ini adalah setelan di Pod dan perlu dikonfigurasi di definisi beban kerja.
Potensi resolusi:
Untuk mencegah error 5XX tersebut, terapkan setelan berikut. Nilai waktu tunggu sugesti dan Anda mungkin perlu menyesuaikannya untuk aplikasi tertentu. Bagian berikut akan memandu Anda melakukan proses penyesuaian.
Gambar berikut menampilkan cara menjaga Pod tetap aktif dengan preStopHook
:
Untuk menghindari error seri 500, lakukan langkah-langkah berikut:
Setel
BackendService Drain Timeout
untuk layanan Anda ke 1 menit.Untuk Pengguna Ingress, lihat menetapkan waktu tunggu di BackendConfig.
Untuk Pengguna Gateway, lihat mengonfigurasi waktu tunggu di GCPBackendPolicy.
Bagi mereka yang mengelola BackendServices secara langsung saat menggunakan NEG Mandiri, lihat menetapkan waktu tunggu langsung di Layanan Backend.
Perluas
terminationGracePeriod
di Pod.Tetapkan
terminationGracePeriodSeconds
di Pod ke 3,5 menit. Jika digabungkan dengan setelan yang direkomendasikan, Pod Anda dapat memiliki waktu 30 hingga 45 detik untuk penonaktifan halus setelah endpoint Pod dihapus dari NEG. Jika memerlukan lebih banyak waktu untuk penonaktifan halus, Anda dapat memperpanjang masa tenggang atau mengikuti petunjuk yang disebutkan di bagian Menyesuaikan waktu tunggu.Manifes
BackendConfig
berikut menentukan waktu tunggu pengosongan koneksi 210 detik (3,5 menit):apiVersion: v1 kind: BackendConfig metadata: name: my-backendconfig spec: terminationGracePeriodSeconds: 210 containers: - name: my-app image: my-app-image:latest ports: - containerPort: 80
Terapkan
preStopHook
ke semua penampung.Terapkan
preStopHook
yang akan memastikan Pod aktif selama 120 detik saat endpoint Pod dihabiskan di load balancer dan endpoint dihapus dari NEG.apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: my-app # Container configuration details... lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 120s"]
Menyesuaikan waktu tunggu
Untuk memastikan kontinuitas Pod dan mencegah error seri 500, Pod harus aktif
hingga endpoint dihapus dari NEG. Khusus untuk mencegah error 502 dan 503,
pertimbangkan untuk menerapkan kombinasi waktu tunggu dan preStopHook
.
Agar Pod tetap aktif lebih lama selama proses penonaktifan, tambahkan preStopHook
ke
Pod. Jalankan preStopHook
sebelum Pod diberi sinyal untuk keluar, sehingga preStopHook
dapat digunakan untuk mempertahankan Pod hingga endpoint terkaitnya dihapus dari NEG.
Untuk memperpanjang durasi Pod tetap aktif selama proses penonaktifan,
sisipkan preStopHook
ke dalam konfigurasi Pod dengan cara berikut:
spec:
containers:
- name: my-app
...
lifecycle:
preStopHook:
exec:
command: ["/bin/sh", "-c", "sleep <latency time>"]
Anda dapat mengonfigurasi waktu tunggu dan setelan terkait untuk mengelola penonaktifan Pod
secara halus selama penurunan skala workload. Anda dapat menyesuaikan waktu tunggu berdasarkan kasus penggunaan tertentu. Sebaiknya mulai dengan waktu tunggu yang lebih lama dan kurangi
durasi seperlunya. Anda dapat menyesuaikan waktu tunggu dengan mengonfigurasi parameter terkait waktu tunggu dan preStopHook
dengan cara berikut:
Waktu Tunggu Pengosongan Layanan Backend
Parameter Backend Service Drain Timeout
tidak disetel secara default dan tidak
berpengaruh. Jika Anda menetapkan parameter Backend Service Drain Timeout
dan mengaktifkannya, load balancer akan berhenti mengarahkan permintaan baru ke endpoint dan menunggu waktu tunggu sebelum menghentikan koneksi yang ada.
Anda dapat menetapkan parameter Backend Service Drain Timeout
menggunakan BackendConfig
dengan Ingress, GCPBackendPolicy
dengan Gateway, atau secara manual di BackendService
dengan NEG mandiri. Waktu tunggu harus 1,5 hingga 2 kali lebih lama daripada waktu yang diperlukan untuk memproses permintaan. Hal ini memastikan jika permintaan masuk tepat sebelum pengosongan dimulai, permintaan itu akan selesai sebelum waktu tunggu selesai. Menetapkan parameter Backend Service Drain Timeout
ke nilai yang lebih besar dari 0 akan membantu mengurangi error 503 karena tidak ada permintaan baru yang dikirim ke endpoint yang dijadwalkan untuk dihapus. Agar waktu tunggu ini efektif, Anda harus
menggunakannya bersama dengan preStopHook
untuk memastikan Pod tetap
aktif saat pengosongan terjadi. Tanpa kombinasi ini, permintaan yang ada yang
tidak selesai akan menerima error 502.
preStopHook
kali
preStopHook
harus menunda penonaktifan Pod secara memadai agar latensi
pengurasan dan waktu tunggu pengurasan layanan backend selesai, yang memastikan
pengosongan koneksi dan penghapusan endpoint yang tepat dari NEG sebelum Pod dimatikan.
Untuk mendapatkan hasil yang optimal, pastikan waktu eksekusi preStopHook
kurang dari
atau sama dengan jumlah Backend Service Drain Timeout
dan Drain Latency.
Jumlah ini dapat dihitung menggunakan rumus:
preStopHook >= Backend Service Drain Timeout + Drain Latency
Sebaiknya tetapkan Drain Latency ke 1 menit. Jika 500 error terus berlanjut, perkirakan total durasi kemunculan dan tambahkan dua kali lipat waktu tersebut ke latensi. Hal ini memastikan bahwa Pod Anda memiliki cukup waktu untuk dihabiskan dengan lancar sebelum dihapus dari layanan. Anda dapat menyesuaikan nilai ini jika terlalu panjang untuk kasus penggunaan tertentu.
Atau, Anda dapat memperkirakan waktunya dengan memeriksa stempel waktu penghapusan dari Pod dan stempel waktu saat endpoint dihapus dari NEG di Cloud Audit Logs.
Parameter Masa Tenggang Penghentian
Anda harus mengonfigurasi parameter terminationGracePeriod
untuk memberikan waktu yang cukup bagi preStopHook
agar selesai dan Pod dapat menyelesaikan penonaktifan halus.
Secara default, jika tidak ditetapkan secara eksplisit, terminationGracePeriod
adalah 30 detik.
Anda dapat menghitung terminationGracePeriod
yang optimal menggunakan rumus:
terminationGracePeriod >= preStopHook Time + Pod shutdown time
Untuk menentukan terminationGracePeriod
dalam konfigurasi Pod sebagai berikut:
spec:
terminationGracePeriodSeconds: <terminationGracePeriod>
containers:
- name: my-app
...
...
NEG tidak ditemukan saat membuat resource Ingress Internal
Error berikut mungkin terjadi saat Anda membuat Ingress internal di GKE:
Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound
Error ini terjadi karena Ingress untuk Load Balancer Aplikasi internal memerlukan Grup Endpoint Jaringan (NEG) sebagai backend.
Di lingkungan VPC Bersama atau cluster dengan Kebijakan Jaringan yang diaktifkan,
tambahkan anotasi cloud.google.com/neg: '{"ingress": true}'
ke manifes
Layanan.
Waktu Tunggu Gateway 504: waktu tunggu permintaan upstream
Error berikut mungkin terjadi saat Anda mengakses Layanan dari Ingress internal di GKE:
HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain
upsteam request timeout
Error ini terjadi karena traffic yang dikirim ke Load Balancer Aplikasi internal di-proxy-kan oleh proxy envoy dalam rentang subnet khusus proxy.
Untuk mengizinkan traffic dari rentang subnet khusus proxy, buat aturan firewall pada targetPort
Layanan.
Error 400: Nilai tidak valid untuk kolom 'resource.target'
Error berikut mungkin terjadi saat Anda mengakses Layanan dari Ingress internal di GKE:
Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.
Untuk mengatasi masalah ini, buat subnet khusus proxy.
Kesalahan selama sinkronisasi: kesalahan menjalankan rutinitas sinkronisasi load balancer: loadbalancer tidak tersedia
Salah satu error berikut mungkin terjadi ketika upgrade bidang kontrol GKE atau saat Anda memodifikasi objek Ingress:
"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."
Atau:
Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid
Untuk mengatasi masalah ini, coba langkah-langkah berikut:
- Tambahkan kolom
hosts
di bagiantls
dari manifes Ingress, lalu hapus Ingress. Tunggu selama lima menit hingga GKE menghapus resource Ingress yang tidak digunakan. Kemudian, buat ulang Ingress. Untuk informasi selengkapnya, lihat Kolom host objek Ingress. - Kembalikan perubahan yang Anda buat ke Ingress. Kemudian, tambahkan sertifikat menggunakan anotasi atau Secret Kubernetes.
Masalah umum
Tidak dapat mengaktifkan Pengalihan ulang HTTPS dengan skema penamaan Ingress V1
Anda tidak dapat mengaktifkan pengalihan ulang HTTPS di resource GKE Ingress yang dibuat di GKE versi 1.16.8-gke.12 dan yang lebih lama. Anda harus membuat ulang Ingress sebelum dapat mengaktifkan pengalihan HTTPS, atau peristiwa error dibuat dan Ingress tidak disinkronkan.
Pesan peristiwa error mirip dengan yang berikut ini:
Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.
Kolom kebijakan keamanan Google Cloud Armor dihapus dari BackendConfig
Ada masalah umum saat mengupdate resource BackendConfig menggunakan API v1beta1
akan menghapus kebijakan keamanan Google Cloud Armor yang aktif dari Layanan.
Masalah ini memengaruhi versi GKE berikut:
- 1.18.19-gke.1400 hingga 1.18.20-gke.5099
- 1.19.10-gke.700 hingga 1.19.14-gke.299
- 1.20.6-gke.700 hingga 1.20.9-gke.899
Jika Anda tidak mengonfigurasi Google Cloud Armor pada resource Ingress melalui BackendConfig, masalah ini tidak akan memengaruhi cluster Anda.
Untuk cluster GKE yang mengonfigurasi Google Cloud Armor melalui BackendConfig, sangat disarankan agar hanya mengupdate resource BackendConfig menggunakan v1
API. Menerapkan BackendConfig ke cluster menggunakan resource BackendConfig v1beta1
akan menghapus kebijakan keamanan Google Cloud Armor
dari Layanan yang dirujuknya.
Untuk mengurangi masalah ini, hanya buat update pada BackendConfig menggunakan v1
BackendConfig API. BackendConfig v1
mendukung semua kolom yang sama seperti v1beta1
dan tidak membuat perubahan yang dapat menyebabkan gangguan sehingga kolom API dapat diperbarui secara transparan.
Ganti kolom apiVersion
dari manifes BackendConfig
yang aktif dengan cloud.google.com/v1
dan jangan gunakan cloud.google.com/v1beta1
.
Contoh manifes berikut menjelaskan resource BackendConfig yang menggunakan API
v1
:
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: my-backend-config
spec:
securityPolicy:
name: "ca-how-to-security-policy"
Jika Anda memiliki sistem atau alat CI/CD yang secara rutin mengupdate resource BackendConfig, pastikan Anda menggunakan grup API cloud.google.com/v1
di sistem tersebut.
Jika BackendConfig telah diperbarui dengan v1beta1
API,
kebijakan keamanan Google Cloud Armor Anda mungkin telah dihapus.
Anda dapat menentukan apakah hal ini telah terjadi dengan menjalankan perintah berikut:
kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'
Jika respons tersebut menampilkan output, berarti cluster Anda akan terpengaruh oleh masalah tersebut.
Output perintah ini akan menampilkan daftar resource BackendConfig
(<namespace>/<name>
) yang terpengaruh oleh masalah tersebut. Jika output kosong,
artinya BackendConfig belum diperbarui menggunakan v1beta1
API sejak
masalah muncul. Setiap update mendatang pada BackendConfig hanya boleh
menggunakan v1
.
Jika kebijakan keamanan Google Cloud Armor dihapus, Anda dapat menentukan kapan kebijakan tersebut dihapus menggunakan kueri Logging berikut:
resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"
Jika salah satu cluster Anda terpengaruh, hal ini dapat diperbaiki dengan mengirimkan
update ke resource BackendConfig yang menggunakan v1
API.
Upgrade bidang kontrol GKE Anda
ke salah satu versi terupdate berikut yang mem-patch masalah ini dan memungkinkan
resource BackendConfig v1beta1
digunakan dengan aman:
- 1.18.20-gke.5100 dan yang lebih baru
- 1.19.14-gke.300 dan yang lebih baru
- 1.20.9-gke.900 dan yang lebih baru