Konfigurasi ingress di Google Cloud

Autopilot Standard

---

Ringkasan

Halaman ini memberikan ringkasan komprehensif tentang apa saja yang dapat Anda konfigurasikan melalui Kubernetes Ingress di Google Cloud. Dokumen ini juga membandingkan fitur yang didukung untuk Ingress di Google Cloud dan memberikan petunjuk untuk mengonfigurasi Ingress menggunakan pengontrol default, parameter FrontendConfig, dan parameter BackendConfig.

Halaman ini ditujukan bagi spesialis Jaringan yang mendesain dan merancang jaringan untuk organisasi mereka serta menginstal, mengonfigurasi, dan mendukung peralatan jaringan. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

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
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.700^G		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 1.25-gke+^G	GA 1.25-gke+^G

^BFitur ini tersedia dalam versi beta mulai dari versi yang ditentukan. Fitur tanpa versi yang tercantum akan didukung untuk semua versi GKE 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.

Diagram berikut menggambarkan caranya:

• Anotasi pada objek Ingress atau MultiClusterIngress mereferensikan CRD FrontendConfig. CRD FrontendConfig merujuk pada Kebijakan SSL Google Cloud.

• Anotasi pada objek Layanan atau MultiClusterService mereferensikan CRD BackendConfig. CRD BackendConfig menetapkan setelan kustom untuk health check layanan backend yang sesuai.

Gambar: Ringkasan BackendConfig dan FrontendConfig

Mengaitkan FrontendConfig dengan Ingress Anda

FrontendConfig hanya dapat digunakan dengan Ingress Eksternal.

Anda dapat mengaitkan FrontendConfig dengan Ingress atau MultiClusterIngress.

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.

MultiClusterIngress

Gunakan anotasi networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "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

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

Anda dapat menggunakan kunci default untuk resource Ingress dan MultiClusterIngress.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

BackendConfig unik per port Layanan

Untuk Ingress dan MultiClusterIngress, Anda dapat menentukan BackendConfig kustom untuk satu atau beberapa port menggunakan kunci yang cocok dengan nama atau nomor port. Pengontrol Ingress menggunakan BackendConfig tertentu saat membuat layanan backend load balancer untuk port Layanan 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.

Catatan: Port layanan yang terkait dengan BackendConfig juga harus digunakan di kolom definisi Ingress backend.service.port. Jika port layanan tidak digunakan dalam objek Ingress apa pun, BackendConfig akan diabaikan.

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:

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.

Catatan: Anda tidak dapat mengaktifkan IAP dan Cloud CDN di BackendConfig. Jika BackendConfig tidak memiliki blok iap, setelan IAP yang ada di layanan backend akan diturunkan.

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:

• CACHE_MODE: Mode cache.
• CLIENT_TTL, DEFAULT_TTL, dan MAX_TTL: Konfigurasi TTL. Untuk mengetahui informasi selengkapnya, lihat Menggunakan setelan dan penggantian TTL.
• NEGATIVE_CACHING: Jika ditetapkan ke true, caching negatif akan diaktifkan. Untuk informasi selengkapnya, lihat Menggunakan caching negatif.
• NEGATIVE_CACHING_CODE dan NEGATIVE_CACHING_TTL: Konfigurasi caching negatif. Untuk informasi selengkapnya, lihat Menggunakan caching negatif.
• REQ_COALESCING: Jika ditetapkan ke true, 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, dan SECRET_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.

Contoh Cloud CDN

Untuk menggunakan BackendConfig untuk mengonfigurasi Cloud CDN, lakukan tugas berikut:

1. Buat namespace khusus untuk contoh ini untuk dijalankan di:
   

   kubectl create namespace cdn-how-to
   

2. Buat file Deployment bernama my-deployment.yaml berdasarkan manifes Deployment berikut. Manifes ini mendeklarasikan bahwa Anda ingin menjalankan dua replika aplikasi web ingress-gce-echo-amd64.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     namespace: cdn-how-to
     name: my-deployment
   spec:
     selector:
       matchLabels:
         purpose: demonstrate-cdn
     replicas: 2
     template:
       metadata:
         labels:
           purpose: demonstrate-cdn
       spec:
         containers:
         - name: echo-amd64
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app-cdn:1.0

3. Buat resource Deployment:

   kubectl apply -f my-deployment.yaml
   

4. Buat BackendConfig bernama my-backendconfig.yaml berdasarkan manifes BackendConfig berikut. Manifes tersebut menentukan kebijakan cache Cloud CDN dan mendeklarasikan bahwa Cloud CDN harus diaktifkan:

     apiVersion: cloud.google.com/v1
     kind: BackendConfig
     metadata:
       namespace: cdn-how-to
       name: my-backendconfig
     spec:
       cdn:
         enabled: true
         cachePolicy:
           includeHost: true
           includeProtocol: true
           includeQueryString: false

5. Buat resource BackendConfig:

   kubectl apply -f my-backendconfig.yaml
   

6. Buat file bernama my-service.yaml berdasarkan manifes Layanan berikut:

   apiVersion: v1
   kind: Service
   metadata:
     namespace: cdn-how-to
     name: my-service
     labels:
       purpose: demonstrate-cdn
     annotations:
       cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
   spec:
     type: NodePort
     selector:
       purpose: demonstrate-cdn
     ports:
     - port: 80
       protocol: TCP
       targetPort: 8080

7. Buat resource Service:

   kubectl apply -f my-service.yaml
   

8. Buat alamat IP yang dicadangkan:

   gcloud compute addresses create cdn-how-to-address --global
   

9. Buat file bernama my-ingress.yaml berdasarkan manifes Ingress berikut:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     namespace: cdn-how-to
     name: my-ingress
     annotations:
       kubernetes.io/ingress.global-static-ip-name: "cdn-how-to-address"
   spec:
     rules:
     - http:
         paths:
         - path: /*
           pathType: ImplementationSpecific
           backend:
             service:
               name: my-service
               port:
                 number: 80

10. Buat resource Ingress:

    kubectl apply -f my-ingress.yaml
    

11. Tunggu sekitar sepuluh menit agar pengontrol Ingress Kubernetes mengonfigurasi load balancer Google Cloud, lalu ambil alamat IP yang digunakan oleh aturan penerusan load balancing dari resource Ingress.

    kubectl describe ingress my-ingress --namespace=cdn-how-to | grep "Address"
    

    Output:

    Address:         ADDRESS
    

    ADDRESS adalah alamat IP eksternal Ingress Anda.

Memvalidasi cache Cloud CDN

Untuk memvalidasi apakah konten Anda di-cache, masukkan perintah curl ini dua kali:

curl -v ADDRESS/?cache=true

Ganti ADDRESS dengan alamat IP eksternal Ingress Anda.

Output menunjukkan header dan isi respons. Di header respons, Anda dapat melihat bahwa konten telah di-cache. Header Age memberi tahu Anda berapa detik konten telah di-cache:

HTTP/1.1 200 OK
Date: Fri, 25 Jan 2019 02:34:08 GMT
Content-Length: 70
Content-Type: text/plain; charset=utf-8
Via: 1.1 google
Cache-Control: max-age=86400,public
Age: 2716

Hello, world!
Version: 1.0.0
Hostname: my-deployment-7f589cc5bc-l8kr8
...

Jika konten Anda tidak di-cache, pastikan aplikasi Anda dikonfigurasi dengan benar untuk mengaktifkan penyimpanan konten dalam cache. Untuk informasi selengkapnya, lihat Konten yang dapat di-cache.

Pembersihan

Untuk mencegah tagihan yang tidak diinginkan pada akun Anda, bebaskan alamat IP statis yang Anda cadangkan:

gcloud compute addresses delete cdn-how-to-address --global

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.

Peringatan: Menetapkan nilai tinggi untuk drainingTimeoutSec (misalnya, 3600 detik) pada Ingress atau Service yang menggunakan grup instance akan menyebabkan penundaan secara proporsional ke durasi yang disetel di drainingTimeoutSec saat memperbarui resource Ingress lainnya di cluster. Hal ini karena semua resource Ingress berbasis grup instance dalam satu cluster memiliki grup instance yang sama. Jika Anda memerlukan nilai tinggi, pertimbangkan untuk menggunakan Layanan yang didukung oleh grup endpoint jaringan.

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.

Catatan: Ingress tidak mendukung gRPC untuk konfigurasi health check kustom.

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"

Peringatan: Anda tidak boleh langsung mengubah resource BackendService dalam Compute Engine untuk melampirkan kebijakan Google Cloud Armor ke layanan backend terkelola GKE.

Dua Sumber Kebenaran

Meskipun dikonfigurasi melalui GKE, Compute Engine BackendService API dasar masih dapat digunakan untuk langsung mengubah kebijakan keamanan yang akan diterapkan. Hal ini akan membuat dua sumber tepercaya: GKE dan Compute Engine. Perilaku Pengontrol GKE Ingress sebagai respons terhadap kolom securityPolicy dalam BackendConfig didokumentasikan dalam tabel di bawah. Untuk menghindari konflik dan perilaku yang tidak terduga, sebaiknya gunakan BackendConfig GKE 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 menulis ulang kebijakan apa pun yang ditetapkan sebelumnya.
spec.securityPolicy.name	String kosong ("")	Pengontrol GKE Ingress menghapus semua kebijakan Google Cloud Armor yang dikonfigurasi dari load balancer.
spec.securityPolicy	nil	Pengontrol Ingress GKE menggunakan konfigurasi yang ditetapkan pada objek BackendService yang dikonfigurasi melalui Compute Engine API menggunakan konsol Google Cloud, gcloud CLI, atau Terraform.

Untuk menyiapkan Ingress GKE dengan perlindungan Google Cloud Armor, lihat Ingress dengan dukungan Google Cloud Armor.

Logging akses HTTP

Catatan: Secara default, GKE mengaktifkan logging akses untuk semua jenis ingress (termasuk Multi Cluster Ingress). Setelan logging akses untuk GKE Ingress tidak didukung untuk versi GKE sebelum 1.16.8-gke.10. Untuk GKE versi 1.16.8-gke.10 atau yang lebih baru, Anda dapat mengonfigurasi setelan logging akses untuk GKE Ingress melalui BackendConfig.

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.

Catatan: Anda tidak dapat mengaktifkan IAP dan Cloud CDN di BackendConfig. Jika BackendConfig tidak memiliki blok iap, setelan IAP yang ada di layanan backend akan diturunkan.

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 yang Dikelola Google

Mulai GKE 1.29.4-gke.1043000, IAP dapat dikonfigurasi untuk menggunakan Klien OAuth yang Dikelola Google menggunakan BackendConfig. Untuk memutuskan apakah akan menggunakan Klien OAuth Google atau Klien OAuth kustom, lihat Kapan harus menggunakan konfigurasi OAuth kustom dalam dokumentasi IAP.

Untuk mengaktifkan IAP dengan Klien OAuth yang Dikelola Google, jangan berikan OAuthCredentials di BackendConfig. Untuk pengguna yang sudah mengonfigurasi IAP menggunakan OAuthCredentials, tidak ada jalur migrasi untuk beralih menggunakan Klien OAuth yang Dikelola Google. Anda harus membuat ulang Backend (hapus Layanan dari Ingress dan pasang kembali). Sebaiknya jalankan operasi ini selama masa pemeliharaan karena akan menyebabkan periode nonaktif. Jalur migrasi yang berlawanan, beralih dari OAuthClient yang Dikelola Google ke OAuthCredentials dapat dilakukan.

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.

Catatan: Jika Anda menggunakan IAP di cluster GKE versi 1.29.2-gke.1521000, 1.29.3-gke.1093000, 1.29.3-gke.1093002, atau 1.29.3-gke.1282000, untuk memastikan tidak ada pemadaman layanan, upgrade ke cluster GKE versi 1.29.4-gke.1043000.

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 Chrome Enterprise Premium 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.

Penting: Gunakan cluster native VPC jika Anda ingin mengonfigurasi afinitas sesi. Afinitas sesi hanya berguna untuk Layanan yang didukung oleh grup endpoint jaringan, dan grup endpoint jaringan memerlukan cluster native VPC.

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.

Load balancer menambahkan header permintaan kustom hanya ke permintaan klien, bukan ke pemeriksaan kondisi. Jika backend Anda memerlukan header tertentu untuk otorisasi yang tidak ada dalam paket health check, health check mungkin akan gagal.

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.

Header respons kustom hanya tersedia di cluster GKE versi 1.25 dan yang lebih baru.

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.

Perhatian: Jangan hapus objek FrontendConfig sebelum Anda menghapus namanya dari anotasi networking.gke.io/v1beta1.FrontendConfig dan terapkan manifes Ingress yang telah diperbarui. Jika Anda melakukannya, konfigurasi tidak akan dihapus dari layanan backend Load Balancing HTTP(S). Selain itu, Anda juga akan melihat error sebagai peristiwa Kubernetes pada objek Ingress.

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.

Perhatian: Jangan hapus objek BackendConfig sebelum menghapus namanya dari anotasi cloud.google.com/backend-config dan terapkan Manifes layanan.yang diperbarui. Jika Anda melakukannya, konfigurasi tidak akan dihapus dari layanan backend Load Balancing HTTP(S). Selain itu, Anda juga akan melihat error sebagai peristiwa Kubernetes pada objek Ingress.

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 ditetapkan 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 bahwa 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 error seri 500 dengan NEG selama penskalaan beban kerja di GKE

Gejala:

Saat menggunakan NEG yang disediakan GKE untuk load balancing, Anda mungkin mengalami error 502 atau 503 untuk layanan selama penskalaan turun 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 beban kerja, cluster Anda berisiko lebih tinggi untuk terpengaruh.

Diagnosis:

Menghapus Pod di Kubernetes tanpa menghabiskan endpoint-nya dan menghapusnya dari NEG terlebih dahulu akan menyebabkan error seri 500. Untuk menghindari masalah selama penghentian Pod, Anda harus mempertimbangkan urutan operasi. Gambar berikut menampilkan skenario saat BackendService Drain Timeout tidak ditetapkan dan BackendService Drain Timeout ditetapkan dengan BackendConfig.

Catatan: Penyelesaian berikut tidak efektif dalam menyelesaikan error seri 500 lainnya yang dihasilkan dari preemption node atau Pod di GKE, terutama dalam kasus GKE dengan Spot VM dan preemptible VM.

Skenario 1: BackendService Drain Timeout tidak ditetapkan.

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 terjadinya error seri 500 bergantung pada faktor-faktor berikut:

• Latensi pemisahan NEG API: Latensi pemisahan NEG API mewakili waktu saat ini yang diperlukan untuk menyelesaikan operasi pemisahan di Google Cloud. Hal ini dipengaruhi oleh berbagai faktor di luar Kubernetes, termasuk jenis load balancer dan zona tertentu.

• Latensi drain: Latensi drain adalah waktu yang diperlukan load balancer untuk mulai mengalihkan traffic dari bagian tertentu pada sistem Anda. Setelah drain dimulai, load balancer berhenti mengirim permintaan baru ke endpoint, tetapi masih ada latensi dalam memicu drain (latensi drain) yang dapat menyebabkan error 503 sementara jika Pod tidak ada lagi.

• Konfigurasi health check: Batas health check yang lebih sensitif mengurangi durasi error 503 karena dapat memberi sinyal kepada load balancer untuk berhenti mengirim permintaan ke endpoint meskipun operasi pemisahan belum selesai.

• Masa tenggang penghentian: Masa tenggang penghentian menentukan jumlah waktu maksimum yang diberikan Pod untuk keluar. Namun, Pod dapat keluar sebelum masa tenggang penghentian selesai. Jika Pod memerlukan waktu lebih lama dari periode ini, Pod akan dipaksa keluar pada akhir periode ini. Ini adalah setelan di Pod dan harus dikonfigurasi dalam definisi beban kerja.

Kemungkinan penyelesaian:

Untuk mencegah error 5XX tersebut, terapkan setelan berikut. Nilai waktu tunggu adalah sugestif dan Anda mungkin perlu menyesuaikannya untuk aplikasi tertentu. Bagian berikut akan memandu Anda dalam proses penyesuaian.

Gambar berikut menampilkan cara mempertahankan Pod dengan preStopHook:

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

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

   Catatan: Jika waktu permintaan rata-rata Anda lebih dari 30 detik, lihat Menyesuaikan waktu tunggu untuk menyesuaikan BackendService Drain Timeout.

   • Untuk Pengguna Ingress, lihat menetapkan waktu tunggu di BackendConfig.

   • Untuk Pengguna Gateway, lihat mengonfigurasi waktu tunggu di GCPBackendPolicy.

   • Untuk pengguna yang mengelola BackendServices secara langsung saat menggunakan NEG mandiri, lihat menetapkan waktu tunggu langsung di Layanan Backend.

2. Perluas terminationGracePeriod di Pod.

   Tetapkan terminationGracePeriodSeconds di Pod ke 3,5 menit. Jika digabungkan dengan setelan yang direkomendasikan, hal ini akan memberi Pod Anda periode waktu 30 hingga 45 detik untuk penonaktifan yang mulus setelah endpoint Pod dihapus dari NEG. Jika memerlukan lebih banyak waktu untuk penonaktifan yang wajar, Anda dapat memperluas masa tenggang atau mengikuti petunjuk yang disebutkan di bagian Menyesuaikan waktu tunggu.

   Manifes Pod berikut menentukan waktu tunggu pengosongan koneksi selama 210 detik (3,5 menit):

   spec:
     terminationGracePeriodSeconds: 210
     containers:
     - name: my-app
       ...
     ...
   

3. Terapkan preStopHook ke semua penampung.

   Terapkan preStopHook yang akan memastikan Pod aktif selama 120 detik lebih lama saat endpoint Pod dikosongkan di load balancer dan endpoint dihapus dari NEG.

   Catatan: Terapkan preStopHook ke setiap penampung di Pod Anda. Tanpa ini, penampung tanpa hook akan keluar segera setelah Pod dihapus. Jika Anda menggunakan alat yang memasukkan penampung, pastikan penampung yang dimasukkan akan memiliki preStopHook yang diperlukan.

   spec:
     containers:
     - name: my-app
       ...
       lifecycle:
         preStopHook:
           exec:
             command: ["/bin/sh", "-c", "sleep 120s"]
     ...
   

Menyesuaikan waktu tunggu

Untuk memastikan kelangsungan 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.

Catatan: Jika konfigurasi health check disetel untuk mendeteksi kegagalan dengan segera, hal ini dapat menyebabkan load balancer berhenti mengirim permintaan lebih cepat, sehingga berpotensi mengurangi terjadinya error 503. Namun, perhatikan bahwa error 503 mungkin masih terjadi selama durasi nilai minimum yang tidak sehat. Anda harus memahami bahwa mengonfigurasi health check tidak akan mencegah error 502, yang terjadi saat koneksi yang ada dihentikan sebelum waktunya.

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-nya yang sesuai dihapus dari NEG.

Untuk memperpanjang durasi Pod tetap aktif selama proses penonaktifan, masukkan preStopHook ke dalam konfigurasi Pod sebagai berikut:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStopHook:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Catatan: Di Pod multi-penampung, pastikan Anda menambahkan preStopHook ke setiap penampung agar semua penampung tetap aktif. Tanpa ini, hanya penampung dengan hook yang berjalan, dan sisanya berhenti. Jika Anda menggunakan alat yang menambahkan penampung, pastikan penampung yang ditambahkan tersebut juga memiliki preStopHook yang diperlukan.

Anda dapat mengonfigurasi waktu tunggu dan setelan terkait untuk mengelola penonaktifan Pod secara halus selama penskalaan turun beban kerja. Anda dapat menyesuaikan waktu tunggu berdasarkan kasus penggunaan tertentu. Sebaiknya mulai dengan waktu tunggu yang lebih lama dan kurangi durasi jika diperlukan. 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 ditetapkan secara default dan tidak berpengaruh. Jika Anda menetapkan parameter Backend Service Drain Timeout dan mengaktifkannya, load balancer akan berhenti merutekan permintaan baru ke endpoint dan menunggu waktu tunggu habis 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 dari waktu yang diperlukan untuk memproses permintaan. Hal ini memastikan bahwa jika permintaan datang tepat sebelum pemborosan dimulai, permintaan tersebut akan selesai sebelum waktu tunggu selesai. Menetapkan parameter Backend Service Drain Timeout ke nilai yang lebih besar dari 0 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 bahwa Pod tetap aktif saat pemborosan terjadi. Tanpa kombinasi ini, permintaan yang ada yang tidak selesai akan menerima error 502.

Waktu preStopHook

preStopHook harus menunda penonaktifan Pod secara memadai agar latensi drain dan waktu tunggu drain layanan backend selesai, sehingga memastikan drain koneksi dan penghapusan endpoint yang tepat dari NEG sebelum Pod dinonaktifkan.

Untuk hasil yang optimal, pastikan waktu eksekusi preStopHook lebih besar dari atau sama dengan jumlah Backend Service Drain Timeout dan latensi drain.

Hitung waktu eksekusi preStopHook ideal Anda dengan rumus berikut:

preStopHook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

Ganti kode berikut:

• BACKEND_SERVICE_DRAIN_TIMEOUT: waktu yang Anda konfigurasikan untuk Backend Service Drain Timeout.
• DRAIN_LATENCY: estimasi waktu untuk latensi pengosongan. Sebaiknya gunakan satu menit sebagai perkiraan Anda.

Jika error 500 terus berlanjut, estimasi total durasi kemunculan dan tambahkan dua kali waktu tersebut ke estimasi latensi drain. Hal ini memastikan bahwa Pod Anda memiliki waktu yang cukup untuk dikosongkan dengan baik sebelum dihapus dari layanan. Anda dapat menyesuaikan nilai ini jika terlalu lama 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 memadai agar preStopHook selesai dan Pod menyelesaikan penghentian yang halus.

Secara default, jika tidak ditetapkan secara eksplisit, terminationGracePeriod adalah 30 detik. Anda dapat menghitung terminationGracePeriod yang optimal menggunakan formula:

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 atau cluster VPC Bersama yang mengaktifkan Kebijakan Jaringan, 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 di 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

• GKE Ingress untuk load balancing cluster tunggal.

• Tutorial ingress untuk men-deploy perutean HTTP(S) untuk aplikasi GKE.

• Mengimplementasikan GKE Ingress dengan health check HTTP kustom