Mengonfigurasi resource Gateway menggunakan Kebijakan

Halaman ini menunjukkan cara mengonfigurasi load balancer yang dibuat Google Kubernetes Engine (GKE) saat Anda men-deploy Gateway di cluster GKE.

Saat Anda men-deploy Gateway, konfigurasi GatewayClass akan menentukan load balancer yang dibuat GKE. Load balancer terkelola ini telah dikonfigurasi sebelumnya dengan setelan default yang dapat Anda ubah menggunakan Kebijakan.

Anda dapat menyesuaikan resource Gateway agar sesuai dengan persyaratan infrastruktur atau aplikasi dengan melampirkan Kebijakan ke Gateway, Layanan, atau ServiceImports. Setelah Anda menerapkan atau mengubah Kebijakan, pengontrol Gateway akan memprosesnya dan mengonfigurasi ulang resource load balancer yang mendasarinya secara otomatis. Dengan cara ini, Anda tidak perlu menghapus atau membuat ulang resource Gateway, Route, atau Service.

Anda juga dapat menggunakan BackendTLSPolicy untuk mengonfigurasi setelan TLS yang diautentikasi backend guna memverifikasi identitas backend yang terhubung ke Gateway. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi TLS backend.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.

Persyaratan GKE Gateway Controller

  • Gateway API hanya didukung di cluster native VPC.
  • Jika menggunakan GatewayClass regional atau lintas region, Anda harus mengaktifkan subnet khusus proxy.
  • Cluster Anda harus mengaktifkan add-on HttpLoadBalancing.
  • Jika menggunakan Istio, Anda harus mengupgrade Istio ke salah satu versi berikut:
    • 1.15.2 atau yang lebih baru
    • 1.14.5 atau yang lebih baru
    • 1.13.9 atau yang lebih baru.
  • Jika Anda menggunakan VPC Bersama, di project host, Anda harus menetapkan peran Compute Network User ke Akun layanan GKE untuk project layanan.

Batasan dan Pembatasan

Selain pembatasan dan batasan pengontrol GKE Gateway, batasan berikut berlaku khusus untuk Kebijakan yang diterapkan pada resource Gateway:

  • Resource GCPGatewayPolicy hanya dapat dilampirkan ke Gateway gateway.networking.k8s.io.

  • Resource GCPGatewayPolicy harus ada di namespace yang sama dengan Gateway target.

  • Saat menggunakan Gateway cluster tunggal, resource GCPBackendPolicy, dan HealthCheckPolicy harus merujuk ke resource Layanan.

  • Saat menggunakan Gateway multi-cluster, GCPBackendPolicy, dan HealthCheckPolicy, resource harus merujuk ke resource ServiceImport.

  • Hanya satu GCPBackendPolicy yang dapat dilampirkan ke Layanan dalam satu waktu. Jika dua kebijakan GCPBackendPolicy dibuat yang menargetkan Service atau ServiceImport yang sama, kebijakan terlama akan diprioritaskan dan kebijakan kedua tidak dapat dilampirkan.

  • Kebijakan hierarkis tidak didukung dengan GKE Gateway.

  • Resource HealthCheckPolicy dan GCPBackendPolicy harus ada di namespace yang sama dengan resource Service atau ServiceImport target.

  • Resource GCPBackendPolicy dan HealthCheckPolicy disusun sedemikian rupa sehingga hanya dapat mereferensikan satu layanan backend.

  • GCPBackendPolicy tidak mendukung opsi HEADER_FIELD atau HTTP_COOKIE untuk afinitas sesi. Untuk afinitas sesi HEADER_FIELD atau HTTP_COOKIE, gunakan resource GCPTrafficDistributionPolicy.

  • Jangan gunakan Layanan backend yang sama di seluruh Gateway dengan jenis GatewayClass yang berbeda (seperti Global versus Regional, Internal versus Eksternal, atau Terkelola versus Klasik) jika Gateway tersebut memerlukan konfigurasi yang tidak kompatibel. Misalnya, GCPBackendPolicy yang dikonfigurasi dengan fitur yang tidak didukung oleh GatewayClass "Klasik" tidak dapat diterapkan ke Layanan yang juga digunakan oleh Gateway "Klasik". Untuk memastikan konfigurasi yang benar, buat Layanan yang berbeda untuk setiap Gateway yang memerlukan setelan kebijakan yang berbeda.

  • Afinitas sesi yang dikonfigurasi menggunakan GCPTrafficDistributionPolicy hanya didukung untuk Gateway cluster tunggal.

  • Afinitas sesi GCPTrafficDistributionPolicy tidak kompatibel dengan resource InferencePool karena menggunakan algoritma load balancing lokalitas khusus.

  • GCPTrafficDistributionPolicy tidak mendukung konfigurasi afinitas sesi atau kebijakan load balancing lokalitas untuk Load Balancer Aplikasi klasik.

  • Saat menggunakan Gateway cluster tunggal, resource GCPBackendPolicy dan HealthCheckPolicy harus merujuk ke resource Service atau InferencePool.

  • Saat menggunakan Gateway multi-cluster, resource GCPBackendPolicy dan HealthCheckPolicy harus merujuk ke resource ServiceImport atau GCPInferencePoolImport.

  • Hanya satu GCPBackendPolicy yang dapat dilampirkan ke satu resource target (Service, ServiceImport, InferencePool, atau GCPInferencePoolImport) pada waktu tertentu. Jika beberapa resource GCPBackendPolicy dibuat yang menargetkan resource yang sama, kebijakan terlama akan diutamakan dan kebijakan yang lebih baru gagal dilampirkan.

  • Resource HealthCheckPolicy dan GCPBackendPolicy harus ada di namespace yang sama dengan resource Service, ServiceImport, InferencePool, atau GCPInferencePoolImport target.

  • Resource GCPBackendPolicy dan HealthCheckPolicy hanya dapat menargetkan satu resource (seperti Service atau InferencePool).

Praktik terbaik: Buat Layanan yang berbeda untuk setiap Gateway menggunakan GatewayClass yang berbeda untuk memastikan kompatibilitas antara kebijakan Layanan dan jenis load balancer.

Mengonfigurasi akses global untuk Gateway internal regional

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Untuk mengaktifkan akses global dengan Gateway internal, lampirkan kebijakan ke resource Gateway.

Manifes GCPGatewayPolicy berikut mengaktifkan Gateway internal regional untuk akses global:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Mengonfigurasi region untuk Gateway multi-cluster

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.30.3-gke.1225000 atau yang lebih baru.

Jika armada Anda memiliki cluster di beberapa region, Anda mungkin perlu men-deploy Gateway regional di berbagai region untuk berbagai kasus penggunaan, misalnya, redundansi lintas region, latensi rendah, dan kedaulatan data. Di cluster konfigurasi Gateway multi-cluster, Anda dapat menentukan region tempat Anda ingin men-deploy Gateway regional. Jika Anda tidak menentukan region, region default-nya adalah region cluster config.

Untuk mengonfigurasi region untuk Gateway multi-cluster, gunakan kolom region di GCPGatewayPolicy. Dalam contoh berikut, Gateway dikonfigurasi di region us-central1:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

Mengonfigurasi kebijakan SSL untuk mengamankan traffic client-to-load-balancer

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Untuk mengamankan traffic client-to-load-balancer, konfigurasikan kebijakan SSL dengan menambahkan nama kebijakan ke GCPGatewayPolicy. Secara default, Gateway tidak memiliki kebijakan SSL yang ditentukan dan dilampirkan.

Pastikan Anda membuat kebijakan SSL sebelum merujuk kebijakan di resource GCPGatewayPolicy.

Manifes GCPGatewayPolicy berikut menentukan kebijakan keamanan bernama gke-gateway-ssl-policy:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Mengonfigurasi health check

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Secara default, untuk layanan backend yang menggunakan protokol aplikasi HTTP atau kubernetes.io/h2c, HealthCheck adalah jenis HTTP. Untuk protokol HTTPS, HealthCheck default adalah jenis HTTPS. Untuk protokol HTTP2, HealthCheck default adalah jenis HTTP2.

Anda dapat menggunakan HealthCheckPolicy untuk mengontrol setelan health check load balancer. Setiap jenis health check (http, https, grpc, http2, dan tcp) memiliki parameter yang dapat Anda tentukan. Google Cloud membuat health check yang unik untuk setiap layanan backend untuk setiap Layanan GKE.

Agar load balancer berfungsi normal, Anda mungkin perlu mengonfigurasi HealthCheckPolicy kustom untuk load balancer jika jalur health check bukan "/" standar. Konfigurasi ini juga diperlukan jika Anda perlu menyesuaikan parameter health check. Misalnya, jika jalur permintaan default adalah "/", tetapi layanan Anda tidak dapat diakses di jalur permintaan tersebut dan menggunakan "/health" untuk melaporkan kondisinya, Anda harus mengonfigurasi requestPath di HealthCheckPolicy Anda dengan tepat.

Saat mengonfigurasi pemeriksaan kesehatan, perhatikan batasan berikut:

  • Tidak seperti GKE Ingress, GKE Gateway tidak secara otomatis menyimpulkan parameter health check (seperti jalur, port, atau protokol) dari pemeriksaan kesiapan atau keaktifan Pod Anda. Jika layanan Anda tidak menampilkan respons yang berhasil di jalur root default (/), Anda harus mengonfigurasi HealthCheckPolicy secara eksplisit.
  • Pemeriksaan kondisiGoogle Cloud secara ketat memerlukan kode respons HTTP 200 (OK). Jika aplikasi Anda menampilkan pengalihan (misalnya, HTTP 301 atau 302) atau error klien (misalnya, HTTP 401 atau 403 di endpoint yang diautentikasi) di jalur yang diselidiki, load balancer akan menandai backend sebagai tidak responsif, sehingga menghasilkan error "No healthy upstream".
  • Anda tidak dapat mengonfigurasi header permintaan HTTP kustom (seperti header Authorization) dalam pemeriksaan HealthCheckPolicy GKE Gateway. Jika backend Anda memerlukan header autentikasi, Anda harus mengonfigurasi aplikasi untuk mengizinkan akses yang tidak diautentikasi secara khusus ke jalur health check khusus Anda (misalnya, /healthz atau /ping) untuk Google Cloud rentang IP health check.

Manifes HealthCheckPolicy berikut menunjukkan semua kolom yang tersedia saat mengonfigurasi kebijakan health check:

Layanan

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Ganti kode berikut:

  • INTERVAL: menentukan interval pemeriksaan, 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 adalah 15 detik jika tidak ada HealthCheckPolicy yang ditentukan, dan 5 detik jika HealthCheckPolicy ditentukan tanpa nilai checkIntervalSec. Untuk mengetahui informasi selengkapnya, lihat Beberapa pemeriksaan dan frekuensi.
  • TIMEOUT: menentukan jumlah waktu yang diperlukanGoogle Cloud untuk 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.
  • HEALTHY_THRESHOLDdan UNHEALTHY_THRESHOLD: menentukan jumlah upaya koneksi berurutan yang harus berhasil atau gagal, minimal satu kali, untuk mengubahstatus kondisi dari bagus menjadi tidak bagus atau tidak bagus menjadi bagus. Jika Anda menghilangkan salah satu parameter ini, default Google Cloud adalah 2.
  • PROTOCOL: menentukan protokol yang digunakan oleh sistem pemeriksaan untuk health check. Untuk mengetahui informasi selengkapnya, lihat Kriteria keberhasilan untuk HTTP, HTTPS, dan HTTP/2, Kriteria keberhasilan untuk gRPC dan Kriteria keberhasilan untuk TCP. Parameter ini wajib diisi.
  • ENABLED: menentukan apakah logging diaktifkan atau dinonaktifkan.
  • PORT_SPECIFICATION: menentukan apakah health check menggunakan port tetap (USE_FIXED_PORT), port bernama (USE_NAMED_PORT), atau port inferensi (USE_SERVING_PORT). Jika tidak ditentukan, health check akan mengikuti perilaku yang ditentukan di kolom port. Jika port tidak ditentukan, kolom ini akan ditetapkan secara default ke USE_SERVING_PORT.
  • PORT: HealthCheckPolicy hanya mendukung penentuan port health check load balancer menggunakan nomor port. Jika Anda menghilangkan parameter ini, nilai default Google Cloud adalah 80. Karena load balancer mengirimkan pemeriksaan ke alamat IP Pod secara langsung, Anda harus memilih port yang cocok dengan containerPort Pod yang aktif, meskipun containerPort direferensikan oleh targetPort dari Layanan. Anda tidak dibatasi pada containerPorts yang dirujuk oleh targetPort Layanan.
  • HOST: nilai header host dalam permintaan health check. Nilai ini menggunakan definisi RFC 1123 dari nama host, kecuali alamat IP numerik tidak diizinkan. Jika tidak ditentukan atau dibiarkan kosong, nilai ini akan ditetapkan secara default ke alamat IP health check.
  • REQUEST: Menentukan data aplikasi yang akan dikirim setelah koneksi TCP dibuat. Jika tidak ditentukan, nilai defaultnya adalah kosong. Jika permintaan dan respons kosong, koneksi yang terhubung itu sendiri menunjukkan respons. Data permintaan hanya dapat dalam format ASCII.
  • REQUEST_PATH: menentukan request-path dari permintaan health check. Jika tidak ditentukan atau dibiarkan kosong, setelan defaultnya adalah /.
  • RESPONSE: menentukan byte yang akan dicocokkan dengan awal data respons. Jika tidak ditentukan atau dibiarkan kosong, GKE akan mengartikan bahwa respons apa pun sebagai responsif. Data respons hanya bisa berupa ASCII.
  • PROXY_HEADER: menentukan jenis header proxy. Anda dapat menggunakan NONE atau PROXY_V1. Setelan defaultnya adalah NONE.
  • GRPC_SERVICE_NAME: nama opsional Layanan gRPC. Hapus kolom ini untuk menentukan semua Layanan.

Untuk mengetahui informasi selengkapnya tentang kolom HealthCheckPolicy, lihat referensi healthChecks.

Mengonfigurasi kebijakan keamanan backend Cloud Armor untuk mengamankan layanan backend Anda

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Konfigurasi kebijakan keamanan backend Cloud Armor dengan menambahkan nama kebijakan keamanan Anda ke GCPBackendPolicy untuk mengamankan layanan backend Anda. Secara default, Gateway tidak memiliki kebijakan keamanan backend Cloud Armor yang ditentukan dan dilampirkan.

Pastikan Anda membuat kebijakan keamanan backend Cloud Armor sebelum merujuk kebijakan tersebut di GCPBackendPolicy Anda. Jika mengaktifkan Gateway regional, Anda harus membuat kebijakan keamanan backend Cloud Armor regional.

Manifes GCPBackendPolicy berikut menentukan kebijakan keamanan backend bernama example-security-policy:

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Mengonfigurasi IAP

Identity-Aware Proxy (IAP) menerapkan kebijakan kontrol akses pada layanan backend yang terkait dengan HTTPRoute. Dengan penerapan ini, hanya pengguna atau aplikasi terautentikasi dengan peran Identity and Access Management (IAM) yang tepat yang dapat mengakses layanan backend ini.

Secara default, tidak ada IAP yang diterapkan ke layanan backend, Anda harus mengonfigurasi IAP secara eksplisit di GCPBackendPolicy.

Untuk mengonfigurasi IAP dengan Gateway, lakukan hal berikut:

  1. Dapatkan ID klien dan rahasia klien untuk klien OAuth Anda. Rahasia klien hanya tersedia saat Anda membuat klien OAuth. Untuk mengetahui informasi selengkapnya, lihat Mengelola Klien OAuth.

  2. Aktifkan IAP untuk GKE.

    Anda tidak perlu membuat BackendConfig, karena BackendConfig adalah resource konfigurasi Ingress.

  3. Untuk menentukan kebijakan IAP yang merujuk secret:

    1. Simpan manifes GCPBackendPolicy berikut sebagai backend-policy.yaml:

      Layanan

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: SERVICE_NAME

      Ganti kode berikut:

      • CLIENT_SECRET: rahasia klien OAuth.
      • CLIENT_ID: ID klien OAuth.
      • SERVICE_NAME: nama Layanan yang akan ditargetkan di GCPBackendPolicy.

      Layanan Multi-cluster

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    # IAP OAuth2 settings. For more information about these fields,
    # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
    iap:
      enabled: true
      oauth2ClientSecret:
        name: CLIENT_SECRET
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: SERVICEIMPORT_NAME

      Ganti kode berikut:

      • CLIENT_SECRET: rahasia klien OAuth.
      • CLIENT_ID: ID klien OAuth.
      • SERVICEIMPORT_NAME: nama ServiceImport yang akan ditargetkan di GCPBackendPolicy.

    2. Terapkan manifes backend-policy.yaml:

      kubectl apply -f backend-policy.yaml

  4. Verifikasi konfigurasi Anda:

    1. Pastikan kebijakan diterapkan setelah membuat GCPBackendPolicy dengan IAP:

      kubectl get gcpbackendpolicy

      Outputnya mirip dengan hal berikut ini:

      NAME             AGE
backend-policy   45m

    2. Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

      kubectl describe gcpbackendpolicy

      Outputnya mirip dengan hal berikut ini:

      Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPBackendPolicy "default/backend-policy" was a success

Mengonfigurasi waktu tunggu layanan backend

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Manifes GCPBackendPolicy berikut menentukan periode waktu tunggu layanan backend selama 40 detik. Setelan default kolom timeoutSec adalah 30 detik.

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Mengonfigurasi pemilihan backend menggunakan GCPBackendPolicy

Mode load balancing CUSTOM_METRICS dalam GCPBackendPolicy memungkinkan Anda mengonfigurasi metrik kustom tertentu yang memengaruhi cara layanan backend load balancer mendistribusikan traffic. Mode penyeimbangan ini memungkinkan load balancing berdasarkan metrik kustom yang Anda tentukan, dan yang dilaporkan oleh backend aplikasi.

Untuk mengetahui informasi selengkapnya, lihat Pengelolaan traffic dengan load balancing berbasis metrik kustom.

Array customMetrics[], di kolom backends[], berisi kolom berikut:

  • name: menentukan nama metrik kustom yang ditentukan pengguna.
  • maxUtilization: menetapkan target atau penggunaan maksimum untuk metrik ini. Rentang yang valid adalah [0, 100].
  • dryRun: kolom boolean. Jika benar (true), data metrik dilaporkan ke Cloud Monitoring, tetapi tidak memengaruhi keputusan load balancing.

Contoh

Contoh berikut menunjukkan manifes GCPBackendPolicy yang mengonfigurasi metrik kustom untuk pemilihan backend dan perutean tingkat endpoint.

  1. Simpan manifes berikut sebagai my-backend-policy.yaml:

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
  namespace: team-awesome
spec:
  # Attach to the super-service Service.
  targetRef:
    kind: Service
    name: super-service
  default:
    backends:
    # Configuration for all locations.
    - location: "*"
      # Use the rate balancing mode for the load balancer.
      balancingMode: RATE
      # Maximum number of requests per second for each endpoint.
      maxRatePerEndpoint: 9000
    # Configuration for us-central1-a
    - location: us-central1-a
      # maxRatePerEndpoint: 9000 inherited from the * configuration.
      # Use the custom metrics balancing mode for the load balancer.
      balancingMode: CUSTOM_METRICS
      # Configure the custom metrics for the load balancer to use.
      customMetrics:
      - name: gpu-load
        maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
        dryRun: false

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f my-backend-policy.yaml

Load balancer mendistribusikan traffic berdasarkan mode load balancing RATE dan metrik gpu-load kustom.

Mengonfigurasi perutean tingkat endpoint dengan GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy API di Gateway Google Kubernetes Engine (GKE) menyediakan kemampuan pengelolaan traffic tingkat lanjut yang memungkinkan kontrol yang tepat atas cara traffic didistribusikan ke pod aplikasi Anda. Resource terpadu dan berbasis GKE ini menyederhanakan pengelolaan algoritma load balancing dan setelan afinitas sesi.

GCPTrafficDistributionPolicy memungkinkan Anda mengonfigurasi:

  • Algoritma Load Balancing: tentukan cara traffic didistribusikan di antara endpoint dalam backend.

    • WEIGHTED_ROUND_ROBIN: saat Anda memilih algoritma ini, load balancer menggunakan metrik kustom untuk menghitung bobot dan mendistribusikan traffic berdasarkan metrik yang dilaporkan ini. Array customMetrics[] dalam konfigurasi GCPTrafficDistributionPolicy mencakup kolom berikut:

      • name: menentukan nama metrik kustom yang ditentukan pengguna.
      • dryRun: saat true, data metrik dilaporkan ke Cloud Monitoring, tetapi tidak memengaruhi load balancing.

  • RING_HASH: algoritma ini bermanfaat untuk layanan yang sensitif terhadap performa cache. Load balancer ini menggunakan hashing yang konsisten untuk meminimalkan pemetaan ulang permintaan saat pod backend ditambahkan atau dihapus, yang membantu memastikan stabilitas selama peristiwa penskalaan. Mengonfigurasi kolom minimumHashRingSize memberikan distribusi beban yang lebih terperinci.

  • Afinitas sesi: membantu memastikan bahwa permintaan dari klien yang sama secara konsisten dirutekan ke Pod backend yang sama. Hal ini sangat penting untuk workload stateful, seperti keranjang belanja e-commerce atau sesi game. GKE Gateway menggunakan GCPTrafficDistributionPolicy untuk mendukung semua jenis afinitas sesi yang tersedia di instance Load Balancer Aplikasi Google Cloud, termasuk STRONG_COOKIE_AFFINITY, HEADER_FIELD, HTTP_COOKIE, GENERATED_COOKIE, dan CLIENT_IP.

Untuk mengetahui informasi selengkapnya, lihat Pengelolaan traffic dengan load balancing berbasis metrik kustom.

Contoh

Contoh berikut menunjukkan manifes GCPTrafficDistributionPolicy yang mengonfigurasi perutean tingkat endpoint menggunakan algoritma load balancing WEIGHTED_ROUND_ROBIN dan metrik kustom.

  1. Simpan manifes contoh berikut sebagai GCPTrafficDistributionPolicy.yaml:

    apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: echoserver-v2
  namespace: team1
spec:
  targetRefs:
  # Attach to the echoserver-v2 Service in the cluster.
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    # Use custom metrics to distribute traffic across endpoints.
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    # Configure metrics from an ORCA load report to use for traffic
    # distribution.
    customMetrics:
    - name: orca.named_metrics.bescm11
      dryRun: false
    - name: orca.named_metrics.bescm12
      dryRun: true

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f GCPTrafficDistributionPolicy.yaml

Load balancer mendistribusikan traffic ke endpoint berdasarkan algoritma WEIGHTED_ROUND_ROBIN dan metrik kustom yang diberikan.

Mengonfigurasi ukuran ring hash

Untuk layanan yang meminimalkan cache miss sangat penting, gunakan algoritma RING_HASH. Menyesuaikan kolom minimumHashRingSize memungkinkan distribusi beban yang lebih terperinci di seluruh backend. Meskipun load balancer mengelola ukuran ring secara otomatis, memberikan nilai minimum yang lebih tinggi dapat membantu memastikan distribusi permintaan yang lebih merata untuk set backend yang lebih besar.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-service

Mengonfigurasi afinitas sesi

Konfigurasi afinitas sesi untuk membantu memastikan bahwa permintaan dari klien yang sama secara konsisten dirutekan ke Pod backend yang sama.

Mengonfigurasi afinitas sesi menggunakan GCPTrafficDistributionPolicy (default)

Jenis afinitas sesi yang dijelaskan di bagian ini memerlukan versi GKE minimum berikut:

  • CLIENT_IP, HEADER_FIELD, GENERATED_COOKIE, dan HTTP_COOKIE: versi 1.35.2-gke.1269001 atau yang lebih baru.
  • STRONG_COOKIE_AFFINITY: versi 1.36.3-gke.1767000 atau yang lebih baru.

Gateway GKE mendukung semua jenis afinitas sesi dengan menggunakan resource GCPTrafficDistributionPolicy. Resource ini memberikan kontrol yang lebih terperinci, seperti perutean berdasarkan header HTTP atau cookie kustom. Mengonfigurasi afinitas sesi menggunakan GCPTrafficDistributionPolicy adalah metode default dan yang direkomendasikan.

Tabel berikut menjelaskan jenis afinitas yang didukung saat Anda menggunakan GCPTrafficDistributionPolicy:

Jenis afinitas Deskripsi
STRONG_COOKIE_AFFINITY Persistensi sesi berbasis cookie stateful. Membantu memastikan kelekatan sesi yang kuat di seluruh peristiwa penskalaan dan pengubahan ukuran kumpulan Pod. Anda harus mengonfigurasi kolom cookie.name, dan dapat mengonfigurasi kolom cookie.path dan cookie.ttl secara opsional. Berfungsi dengan setelan localityLbAlgorithm apa pun (nilai defaultnya adalah ROUND_ROBIN).
HTTP_COOKIE Afinitas berdasarkan cookie HTTP. Saat merespons permintaan pertama, load balancer membuat cookie dan memberikannya di header respons Set-Cookie. Pada permintaan berikutnya, klien akan menampilkan cookie yang diberikan oleh load balancer, dan load balancer akan menggunakannya untuk merutekan permintaan secara konsisten ke Pod yang sama. Anda harus mengonfigurasi kolom cookie.name, dan dapat mengonfigurasi kolom cookie.path dan cookie.ttl secara opsional. Memerlukan kolom localityLbAlgorithm ditetapkan ke MAGLEV atau RING_HASH.
GENERATED_COOKIE Load balancer membuat cookie untuk melacak sesi. Nama cookie adalah GCLB untuk Load Balancer Aplikasi eksternal global, dan GCILB untuk Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional. Jalur cookie adalah /. Anda dapat secara opsional mengonfigurasi kolom cookie.ttl hingga maksimum dua minggu; kolom cookie.name dan cookie.path tidak dapat dikonfigurasi untuk jenis ini. Memerlukan kolom localityLbAlgorithm ditetapkan ke MAGLEV atau RING_HASH.
HEADER_FIELD Afinitas berdasarkan header HTTP tertentu. Memerlukan kolom localityLbAlgorithm disetel ke MAGLEV atau RING_HASH.
CLIENT_IP Afinitas berdasarkan alamat IP klien. Memerlukan kolom localityLbAlgorithm disetel ke MAGLEV atau RING_HASH.
NONE Menonaktifkan afinitas sesi.

Contoh berikut menunjukkan cara mengonfigurasi GCPTrafficDistributionPolicy yang dikelompokkan menurut kategori afinitas: afinitas sesi berbasis cookie, berbasis header, dan berbasis IP klien.

Untuk menerapkan salah satu konfigurasi afinitas sesi berikut ke cluster Anda, lakukan hal berikut:

  1. Simpan manifes yang dipilih sebagai policy.yaml.

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f policy.yaml

Afinitas sesi berbasis cookie mencakup jenis afinitas STRONG_COOKIE_AFFINITY, HTTP_COOKIE, dan GENERATED_COOKIE.

Afinitas cookie stateful (STRONG_COOKIE_AFFINITY)

Afinitas cookie stateful (STRONG_COOKIE_AFFINITY) memberikan persistensi sesi stateful yang mempertahankan kelekatan bahkan selama peristiwa penskalaan backend.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: strong-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: STRONG_COOKIE_AFFINITY
      cookie:
        name: "GKE_STATEFUL_SESSION"
        path: "/"
        ttl: "24h"
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Afinitas cookie HTTP (HTTP_COOKIE)

Jenis afinitas HTTP_COOKIE mendasarkan afinitas pada cookie bernama tertentu yang ditampilkan di header Set-Cookie. Untuk menggunakan jenis afinitas sesi selain NONE dan STRONG_COOKIE_AFFINITY, Anda harus menyetel kolom localityLbAlgorithm ke MAGLEV atau RING_HASH.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: http-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HTTP_COOKIE
      cookie:
        name: "my-app-session-id"
        path: "/"
        ttl: "3600s"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Afinitas cookie yang dihasilkan (GENERATED_COOKIE)

Jenis afinitas GENERATED_COOKIE memungkinkan load balancer membuat dan memberi nama cookie sesi secara otomatis. Anda dapat mengonfigurasi nilai kolom cookie.ttl hingga dua minggu (336h).

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: generated-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookie:
        ttl: "2h30m"
    # GENERATED_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Perilaku TTL nol untuk afinitas sesi berbasis cookie mencakup hal berikut:

  • Semua afinitas sesi berbasis cookie (STRONG_COOKIE_AFFINITY, HTTP_COOKIE, dan GENERATED_COOKIE) memiliki atribut ttl.

  • TTL nol detik berarti load balancer tidak menetapkan atribut Expires ke cookie. Dalam hal ini, klien memperlakukan cookie sebagai cookie sesi. Definisi sesi bervariasi bergantung pada klien:

    • Beberapa klien, seperti browser web, menyimpan cookie selama seluruh sesi penjelajahan. Pendekatan ini berarti cookie tetap ada di beberapa permintaan hingga aplikasi ditutup.
    • Klien lain memperlakukan sesi sebagai satu permintaan HTTP, dan langsung menghapus cookie setelah sesi berakhir.

Afinitas sesi berbasis header

Jenis afinitas HEADER_FIELD merutekan traffic berdasarkan header HTTP tertentu untuk skenario seperti pengujian A/B atau perutean klien khusus yang tidak cocok untuk cookie. Untuk menggunakan jenis afinitas sesi selain NONE dan STRONG_COOKIE_AFFINITY, Anda harus menyetel kolom localityLbAlgorithm ke MAGLEV atau RING_HASH. Tidak seperti ROUND_ROBIN default, algoritma ini mendukung hashing yang konsisten berdasarkan kolom kustom seperti header HTTP.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: header-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HEADER_FIELD
      httpHeaderName: "X-User-Group-ID"
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Afinitas sesi berbasis alamat IP klien

Jenis afinitas CLIENT_IP merutekan traffic dari alamat IP klien tertentu ke Pod backend yang sama berdasarkan upaya terbaik. Untuk menggunakan jenis afinitas sesi selain NONE dan STRONG_COOKIE_AFFINITY, Anda harus menetapkan kolom localityLbAlgorithm ke MAGLEV atau RING_HASH.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: client-ip-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Memverifikasi kebijakan

Untuk memastikan GCPTrafficDistributionPolicy Anda dikonfigurasi dan aktif dengan benar, verifikasi statusnya setelah Anda menerapkannya:

  1. Untuk memeriksa status kebijakan, jalankan perintah berikut:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ganti POLICY_NAME dengan nama kebijakan Anda.

  2. Pada output, periksa bagian Conditions. Status True dengan alasan Attached menunjukkan bahwa konfigurasi valid dan aktif.

Mengonfigurasi afinitas sesi menggunakan GCPBackendPolicy

Bagian ini menjelaskan cara mengonfigurasi afinitas sesi menggunakan GCPBackendPolicy.

Anda dapat mengonfigurasi afinitas sesi GCPBackendPolicy berdasarkan kriteria berikut:

  • Alamat IP klien (CLIENT_IP)
  • Cookie yang dihasilkan (GENERATED_COOKIE)

Saat Anda mengonfigurasi afinitas sesi untuk Layanan menggunakan GCPBackendPolicy, Gateway akan menyetel setelan localityLbPolicy pada layanan backend ke MAGLEV. Saat Anda menghapus afinitas sesi dari GCPBackendPolicy, Gateway akan mengembalikan setelan localityLbPolicy ke nilai default, ROUND_ROBIN.

Manifes GCPBackendPolicy berikut menentukan afinitas sesi berdasarkan alamat IP klien:

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Manifes GCPBackendPolicy berikut menentukan afinitas sesi berdasarkan cookie yang dihasilkan dan mengonfigurasi TTL cookie ke 50 detik:

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Mengonfigurasi waktu tunggu pengosongan koneksi

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Anda dapat mengonfigurasi waktu tunggu pengosongan koneksi menggunakan GCPBackendPolicy. Waktu tunggu pengosongan koneksi adalah waktu, dalam detik, untuk menunggu koneksi dikosongkan. Durasi waktu tunggu bisa dari 0 hingga 3600 detik. Nilai defaultnya adalah 0, yang juga menonaktifkan pengosongan koneksi.

Manifes GCPBackendPolicy berikut menentukan waktu tunggu pengosongan koneksi selama 60 detik:

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

yaml apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: my-backend-policy namespace: lb-service-namespace spec: default: connectionDraining: drainingTimeoutSec: 60 # Attach to a multi-cluster InferencePool. targetRef: group: networking.gke.io kind: GCPInferencePoolImport name: my-inference-pool-import

Selama durasi waktu tunggu yang ditentukan, GKE menunggu penyelesaian permintaan yang ada ke backend yang dihapus. Load balancer tidak mengirim permintaan baru ke backend yang dihapus. Setelah durasi waktu tunggu tercapai, GKE akan menutup semua koneksi yang tersisa ke backend.

Logging akses HTTP

Bagian ini menjelaskan fungsionalitas yang tersedia di cluster GKE yang menjalankan versi 1.24 atau yang lebih baru.

Secara default:

  • Pengontrol Gateway mencatat semua permintaan HTTP dari klien ke Cloud Logging.
  • Frekuensi pengambilan sampel adalah 1.000.000, yang berarti semua permintaan dicatat ke dalam log.
  • Tidak ada kolom opsional yang dicatat.

Anda dapat menonaktifkan logging akses di Gateway menggunakan GCPBackendPolicy dengan tiga cara:

  • Anda dapat membiarkan GCPBackendPolicy tanpa bagian logging
  • Anda dapat menyetel logging.enabled ke false
  • Anda dapat menyetel logging.enabled ke true dan menyetel logging.sampleRate ke 0

Anda juga dapat mengonfigurasi frekuensi sampling logging akses dan daftar kolom opsional, misalnya tls.cipher atau orcaLoadReport.

Untuk mengaktifkan logging kolom opsional:

  • Tetapkan logging.OptionalMode ke CUSTOM.
  • Berikan daftar kolom opsional yang akan dicatat dalam log di logging.optionalFields. Lihat pencatatan log dan pemantauan untuk mengetahui daftar kolom yang didukung.

Anda dapat menonaktifkan logging kolom opsional dengan dua cara:

  • Anda dapat menghapus semua entri dari logging.optionalFields.
  • Anda dapat menyetel logging.OptionalMode ke EXCLUDE_ALL_OPTIONAL.

Manifes GCPBackendPolicy berikut mengubah frekuensi sampel default logging akses dan menetapkannya ke 50% permintaan HTTP. Manifes juga mengaktifkan logging dua kolom opsional untuk resource Layanan tertentu:

Layanan

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Layanan Multi-cluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Manifes ini memiliki kolom berikut:

  • enable: true: mengaktifkan logging akses secara eksplisit. Log tersedia di Logging.
  • sampleRate: 500000: menentukan bahwa 50% paket dicatat ke dalam log. Anda dapat menggunakan nilai antara 0 dan 1.000.000. GKE mengonversi nilai ini menjadi nilai floating point di rentang [0, 1] dengan membagi dengan 1.000.000. Kolom ini hanya relevan jika enable ditetapkan ke true. sampleRate adalah kolom opsional, tetapi jika dikonfigurasi, enable: true juga harus ditetapkan. Jika enable ditetapkan ke true dan sampleRate tidak disediakan, GKE menetapkan enable ke false.
  • optionalMode: CUSTOM: menentukan bahwa sekumpulan optionalFields harus disertakan dalam entri log.
  • optionalFields: tls.cipher, orcaLoadReport.cpu_utilization: menentukan bahwa entri log harus menyertakan nama sandi yang digunakan untuk handshake TLS dan pemanfaatan CPU layanan, jika tersedia.

Mengonfigurasi penskalaan otomatis berbasis traffic untuk Gateway cluster tunggal

Pastikan cluster GKE Anda menjalankan versi 1.31.1-gke.2008000 atau yang lebih baru.

Untuk mengaktifkan penskalaan otomatis berbasis traffic dan load balancing berbasis kapasitas di Gateway cluster tunggal, Anda dapat mengonfigurasi kapasitas Layanan. Kapasitas layanan adalah kemampuan untuk menentukan jumlah kapasitas traffic yang dapat diterima Layanan sebelum Pod diskalakan otomatis atau traffic diluapkan ke cluster lain yang tersedia.

Untuk mengonfigurasi kapasitas Layanan, buat Layanan dan GCPBackendPolicy terkait. Manifes GCPBackendPolicy menggunakan kolom maxRatePerEndpoint yang menentukan nilai Permintaan per Detik (RPS) maksimum per Pod dalam Layanan. Manifes GCPBackendPolicy berikut menentukan RPS maksimum 10:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

Untuk mempelajari lebih lanjut penskalaan otomatis berbasis traffic, lihat Penskalaan otomatis berdasarkan traffic load balancer.

Pemecahan masalah

Bagian ini memberikan panduan untuk memecahkan masalah umum saat mengonfigurasi resource Gateway menggunakan Kebijakan.

GCPTrafficDistributionPolicy tidak diterapkan

Gejala: Traffic tidak didistribusikan sesuai dengan afinitas sesi atau setelan lokalitas yang ditentukan dalam kebijakan Anda.

Alasan: Hal ini biasanya terjadi jika kebijakan tidak terikat dengan benar ke Layanan atau jika pengontrol Gateway mengalami error validasi saat mencoba menyinkronkan konfigurasi ke load balancer.

Solusi:

  1. Verifikasi status kebijakan: Periksa apakah kebijakan telah dilampirkan ke Layanan Anda:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ganti POLICY_NAME dengan nama kebijakan Anda.

    Pada output, cari bagian Conditions. Status True dengan alasan Attached menunjukkan bahwa konfigurasi valid dan telah diterapkan. Jika statusnya False, periksa kolom Reason dan Message untuk mengetahui error validasi (misalnya, algoritma yang tidak didukung untuk jenis afinitas yang dipilih).

  2. Verifikasi sinkronisasi konfigurasi Gateway: Pastikan Gateway yang mengelola traffic telah berhasil menyinkronkan setelan ini dengan infrastruktur cloud.

    Di bagian Status, verifikasi bahwa kondisi Programmed memiliki Status True. Jika False, hal ini menunjukkan bahwa pengontrol Gateway mengalami error, yang mungkin terkait dengan GCPTrafficDistributionPolicy Anda.

    Periksa kolom Reason dan Message di samping kondisi Programmed untuk mengetahui detailnya secara langsung. Untuk mengetahui pesan error yang lebih terperinci atau histori kegagalan sinkronisasi, periksa Events di bagian bawah output.

Beberapa GCPBackendPolicy yang dilampirkan ke Layanan yang sama

Gejala:

Kondisi status berikut mungkin terjadi saat Anda melampirkan GCPBackendPolicy ke Layanan atau ServiceImport:

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

Alasan:

Kondisi status ini menunjukkan bahwa Anda mencoba menerapkan GCPBackendPolicy kedua ke Service atau ServiceImport yang sudah memiliki GCPBackendPolicy terlampir.

Beberapa GCPBackendPolicy yang dilampirkan ke Service atau ServiceImport yang sama tidak didukung dengan GKE Gateway. Lihat Pembatasan dan Batasan untuk mengetahui detail selengkapnya.

Solusi:

Konfigurasi satu GCPBackendPolicy yang mencakup semua konfigurasi kustom dan lampirkan ke target resource Anda (Service, ServiceImport, InferencePool, atau GCPInferencePoolImport).

Afinitas sesi diabaikan selama pemisahan traffic

Gejala:

Permintaan tidak dirutekan secara konsisten ke Pod backend yang sama meskipun afinitas sesi dikonfigurasi.

Alasan:

Pemisahan traffic berbobot lebih diutamakan daripada afinitas sesi. Jika HTTPRoute menentukan bobot untuk beberapa backend, load balancer akan memilih backend berdasarkan bobot sebelum menerapkan logika afinitas.

Solusi:

Hindari penggunaan pemisahan traffic berbobot pada aturan HTTPRoute yang sama jika diperlukan kelekatan sesi.

Kebijakan keamanan Cloud Armor tidak ditemukan

Gejala:

Pesan error berikut mungkin muncul saat Anda mengaktifkan Cloud Armor di Gateway regional:

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

Alasan:

Pesan error menunjukkan bahwa kebijakan keamanan Cloud Armor regional yang ditentukan tidak ada di project Google Cloud Anda.

Solusi:

Buat kebijakan keamanan Cloud Armor regional di project Anda dan rujuk kebijakan ini di GCPBackendPolicy Anda.

Langkah berikutnya