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 otomatis mengonfigurasi ulang resource load balancer yang mendasarinya. 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
  • Jika ingin 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. gcloud CLI versi sebelumnya 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.networking.k8s.io Gateway.

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

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

  • 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 yang lebih lama akan diprioritaskan dan kebijakan kedua tidak akan terlampir.

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

  • Saat menggunakan Gateway dengan cakupan yang berbeda (seperti Eksternal Global dan Internal Regional), Anda tidak dapat menggunakan Service backend yang sama jika memerlukan konfigurasi GCPBackendPolicy yang berbeda. Misalnya, GCPBackendPolicy global tidak dapat diterapkan ke Gateway cakupan regional, dan sebaliknya. Untuk memastikan kebijakan khusus cakupan yang benar, buat Service yang berbeda untuk setiap cakupan Gateway.

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

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 Anda ke GCPGatewayPolicy. Secara default, Gateway tidak memiliki Kebijakan SSL apa pun yang ditentukan dan dilampirkan.

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

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 Cloudmembuat health check unik untuk setiap layanan backend untuk setiap Layanan GKE.

Agar load balancer Anda berfungsi normal, Anda mungkin perlu mengonfigurasi HealthCheckPolicy kustom untuk load balancer jika jalur health check Anda bukan "/" standar. Konfigurasi ini juga diperlukan jika jalur memerlukan header khusus atau 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 statusnya, Anda harus mengonfigurasi requestPath di HealthCheckPolicy dengan tepat.

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

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, nilai 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.

Konfigurasikan kebijakan keamanan backend Cloud Armor dengan menambahkan nama kebijakan keamanan Anda ke GCPBackendPolicy untuk mengamankan layanan backend. 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

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 client ID 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 dalam 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 dalam 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

Mengonfigurasi pemilihan backend menggunakan GCPBackendPolicy

Mode penyeimbangan 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

API GCPTrafficDistributionPolicy 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 minimumHashRingSize memberikan distribusi beban yang lebih terperinci.

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

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

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

Anda dapat mengonfigurasi afinitas sesi berdasarkan kriteria berikut:

  • Alamat IP klien
  • Cookie yang dihasilkan

Saat Anda mengonfigurasi afinitas sesi untuk Layanan, setelan localityLbPolicy Gateway ditetapkan ke MAGLEV.

Saat Anda menghapus konfigurasi 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

Anda dapat menggunakan nilai berikut untuk kolom sessionAffinity.type:

  • CLIENT_IP
  • GENERATED_COOKIE
  • NONE

Afinitas sesi yang diperluas menggunakan GCPTrafficDistributionPolicy

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

GKE Gateway mendukung jenis afinitas sesi yang diperluas dengan menggunakan resource GCPTrafficDistributionPolicy. Hal ini memberikan kontrol yang lebih terperinci, seperti perutean berdasarkan header HTTP kustom atau cookie yang dibuat oleh load balancer.

Catatan: Untuk afinitas sesi lanjutan, gunakan GCPTrafficDistributionPolicy. Meskipun GCPBackendPolicy juga mendukung jenis afinitas sesi tertentu, GCPBackendPolicy dianggap sebagai opsi lama untuk konfigurasi ini. Jika kedua kebijakan menargetkan Layanan yang sama, konfigurasi GCPTrafficDistributionPolicy akan diprioritaskan.

Tabel berikut menjelaskan jenis afinitas yang didukung saat menggunakan GCPTrafficDistributionPolicy:

Jenis Afinitas Deskripsi
HEADER_FIELD Afinitas berdasarkan header HTTP tertentu. Memerlukan localityLbAlgorithm yang ditetapkan ke MAGLEV atau RING_HASH.
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 menampilkan cookie yang diberikan oleh load balancer, dan load balancer menggunakannya untuk merutekan permintaan secara konsisten ke pod yang sama. Anda harus mengonfigurasi cookie.name, dan dapat secara opsional mengonfigurasi cookie.path dan cookie.ttl. Memerlukan localityLbAlgorithm yang 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, serta jalur cookie adalah /. Anda dapat secara opsional mengonfigurasi cookie.ttl hingga maksimum dua minggu; cookie.name dan cookie.path tidak dapat dikonfigurasi untuk jenis ini. Memerlukan localityLbAlgorithm yang ditetapkan ke MAGLEV atau RING_HASH.
CLIENT_IP Afinitas berdasarkan alamat IP klien. Memerlukan localityLbAlgorithm yang ditetapkan ke MAGLEV atau RING_HASH.

Contoh afinitas sesi yang diperluas

GCPTrafficDistributionPolicy mendukung beberapa jenis afinitas sesi, yang masing-masing memiliki persyaratan konfigurasi yang unik.

Untuk aplikasi stateful, seperti keranjang belanja atau server game, rute permintaan ke pod tertentu yang menyimpan data sesi pengguna. Konfigurasi ini menggunakan afinitas HTTP_COOKIE, yang mendasarkan afinitas sesi pada cookie tertentu yang dihasilkan oleh load balancer dan dikembalikan ke klien di header Set-Cookie.

  1. Simpan manifes berikut sebagai policy.yaml:

    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"
        ttl: "1h"
        path: "/"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  -   group: ""
    kind: Service
    name: my-stateful-service

  2. Terapkan kebijakan ke cluster Anda:

    kubectl apply -f policy.yaml

Perilaku TTL nol untuk afinitas sesi berbasis cookie:

Semua afinitas sesi berbasis cookie, seperti afinitas GENERATED_COOKIE dan HTTP_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. Artinya, cookie tetap ada di beberapa permintaan hingga aplikasi ditutup.
  • Klien lain memperlakukan sesi sebagai satu permintaan HTTP, dan langsung menghapus cookie setelahnya.
Mengonfigurasi afinitas sesi berbasis header

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

  1. Simpan manifes berikut sebagai policy.yaml:

    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

  2. Terapkan kebijakan ke cluster Anda:

    kubectl apply -f policy.yaml
Memverifikasi kebijakan

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

  1. Untuk memeriksa status kebijakan, jelaskan kebijakan tersebut:

    kubectl describe gcptrafficdistributionpolicy POLICY_NAME

    Ganti POLICY_NAME dengan nama kebijakan Anda.

  2. Pada output, cari bagian Conditions. Status True dengan alasan Attached menunjukkan bahwa konfigurasi valid dan telah diterapkan.

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

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 mengosongkan bagian GCPBackendPolicy tanpa 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 "orca_load_report".

Untuk mengaktifkan logging kolom opsional:

  • Tetapkan logging.OptionalMode ke CUSTOM.
  • Berikan daftar kolom opsional yang akan dicatat dalam log di logging.optionalFields. Lihat logging 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 menyetelnya ke 50% dari permintaan HTTP. Manifes juga memungkinkan 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
      - orca_load_report.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
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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, orca_load_report.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 sebesar 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 berlaku

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 terpasang ke Service yang sama

Gejala:

Kondisi status berikut dapat terjadi saat Anda melampirkan GCPBackendPolicy ke Service 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.

Beberapa GCPBackendPolicy yang terpasang 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 Service atau ServiceImport Anda.

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 terlebih dahulu sebelum menerapkan logika afinitas.

Solusi:

Hindari penggunaan pembagian 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