Ingress configuration on Google Cloud


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 nilai PORT_NUMBER_1 atau PORT_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 nilai PORT_NUMBER_2 atau PORT_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 direferensikantargetPort (yang harus cocok dengancontainerPort untuk Pod yang aktif). Jika tidak, load balancing akan mengirimkan traffic ke alamat IP node pada nodePort 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 jika responseCodeName 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:

Load balancer HTTP eksternal khusus pengalihan ulang yang terdiri dari aturan penerusan, proxy HTTP target, dan peta URL dengan pengalihan ulang ke load balancer HTTPS lengkap dengan layanan backend

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 ke true, Cloud CDN akan diaktifkan untuk backend Ingress ini.
  • INCLUDE_HOST: Jika ditetapkan ke true, permintaan ke host yang berbeda akan disimpan dalam cache secara terpisah.
  • INCLUDE_PROTOCOL: Jika ditetapkan ke true, permintaan HTTP dan HTTPS akan disimpan dalam cache secara terpisah.
  • INCLUDE_QUERY_STRING: Jika ditetapkan ke true, parameter string kueri akan disertakan dalam kunci cache sesuai dengan queryStringBlacklist atauqueryStringWhitelist. Jika keduanya tidak ditetapkan, seluruh string kueri akan disertakan. Jika ditetapkan ke false, 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 menentukan queryStringBlacklist atau queryStringWhitelist, 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 dapat queryStringBlacklist atau queryStringWhitelist, 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:

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: Menentukan check-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. Nilai TIMEOUT harus kurang dari atau sama dengan INTERVAL. Unit dalam hitungan detik. Setiap pemeriksaan memerlukan kode respons HTTP 200 (OK) untuk dikirimkan sebelum waktu tunggu pemeriksaan.
  • HEALTH_THRESHOLD dan UNHEALTHY_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, tentukan request-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 default 80.

    • Saat menggunakan penyeimbangan beban native container, Anda harus memilih port yang cocok dengan containerPort Pod penayangan (terlepas dari apakah containerPort direferensikan oleh targetPort dari Layanan). Karena load balancer mengirimkan pemeriksaan ke alamat IP Pod secara langsung, Anda tidak dibatasi pada containerPort yang dirujuk oleh targetPort 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 ke true, 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 jika enable ditetapkan ke true. sampleRate adalah kolom opsional, tetapi jika dikonfigurasi, enable: true juga harus ditetapkan atau kolom ini akan ditafsirkan sebagai enable: 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"

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:

  1. Membuat Deployment.
  2. Buat BackendConfig.
  3. Buat Layanan, dan kaitkan salah satu port-nya dengan BackendConfig.
  4. Buat Ingress, dan kaitkan Ingress dengan pasangan (Service, port).
  5. Validasi properti layanan backend.
  6. 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. Anotasi cloud.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 Kubernetes my-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:

  1. Hapus nama FrontendConfig dari anotasi networking.gke.io/v1beta1.FrontendConfig dalam manifes Ingress.

  2. Terapkan manifes Ingress yang diubah ke cluster Anda. Misalnya, gunakan kubectl apply.

  3. Menghapus FrontendConfig. Misalnya, gunakan kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Untuk menghapus BackedConfiq, ikuti langkah-langkah berikut:

  1. Hapus nama BackendConfig dari anotasi cloud.google.com/backend-config di manifes Layanan.

  2. Terapkan manifes Layanan yang diubah ke cluster Anda. Misalnya, gunakan kubectl apply.

  3. 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.

Waktu Tunggu Pengurasan BackendService tidak disetel

Skenario 2: BackendService Drain Timeout ditetapkan.

Gambar berikut menampilkan skenario saat BackendService Drain Timeout ditetapkan.

Waktu Tunggu Pengurasan BackendService disetel

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:

Waktu Tunggu Pengurasan BackendService disetel

Untuk menghindari error seri 500, lakukan langkah-langkah berikut:

  1. Setel BackendService Drain Timeout untuk layanan Anda ke 1 menit.

  2. 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
    
  3. 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 bagian tls 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

Langkah selanjutnya