Men-deploy Gateway

Autopilot Standard

Deploy resource Gateway Kubernetes untuk mengelola cara traffic eksternal menjangkau aplikasi dalam satu cluster Google Kubernetes Engine (GKE). Mengonfigurasi Gateway GKE memberikan kontrol yang fleksibel dan andal atas traffic masuk, sehingga meningkatkan skalabilitas dan keandalan aplikasi Anda. Misalnya, GKE Gateway menawarkan kemampuan perutean dan penskalaan otomatis yang dioptimalkan. Kemampuan ini sangat penting untuk penyaluran online berlatensi rendah, sehingga memastikan pengalaman pengguna yang responsif sekaligus membantu mengontrol biaya.

Untuk men-deploy Gateway di beberapa cluster atau fleet, lihat Men-deploy Gateway Multi-Cluster. Untuk konfigurasi Gateway tertentu seperti pemilihan rute lintas namespace dan pemisahan traffic HTTP, lihat panduan pengguna Gateway API.

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.
  Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda menggunakan cluster zona, tetapkan compute/zone. Dengan menetapkan lokasi default, Anda dapat menghindari error di gcloud CLI seperti berikut: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan lokasi default yang Anda tetapkan.

• Pastikan Anda sudah memiliki cluster Autopilot atau Standard. Untuk membuat cluster baru, lihat Membuat cluster Autopilot.

• Pastikan akun pengguna Anda memiliki peran Certificate Manager Editor (roles/certificatemanager.editor) agar Anda dapat membuat peta sertifikat yang diperlukan.

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 menggunakan VPC Bersama, Anda harus menetapkan peran Compute Network User ke akun Layanan GKE untuk project layanan di project host.

Batas dan pembatasan

Saat menggunakan GKE Gateway, pahami batasan dan pembatasan berikut:

• GatewayClass GKE mendukung berbagai kemampuan, bergantung pada load balancer yang digunakan. Untuk mempelajari lebih lanjut berbagai fitur yang didukung oleh setiap GatewayClass, silakan melihat Kemampuan GatewayClass.

  Praktik terbaik:

  Untuk performa yang optimal, batasi jumlah Gateway hingga maksimum 100. Melebihi batas ini dapat memengaruhi performa atau menyebabkan peningkatan latensi.

• GKE Gateway hanya mendukung saluran rilis Gateway API Standard.

• GKE Gateway selalu diaktifkan di cluster Autopilot. Anda tidak dapat menginstal CRD saluran rilis Eksperimental Gateway API di cluster Autopilot.

• Anda tidak dapat menggunakan FrontendConfig atau BackendConfig untuk mengonfigurasi Gateway. Anda harus menggunakan Kebijakan.

• GKE Gateway memiliki perilaku yang berbeda dari Ingress; Gateway tidak menginferensikan parameter health check. Jika Layanan tidak menampilkan 200 untuk permintaan ke GET /, atau Anda memiliki pemeriksaan kesiapan pod lain yang telah disesuaikan, Anda harus mengonfigurasi HealthCheckPolicy untuk layanan.

• Anda tidak dapat menentukan nomor port secara langsung di nama host (misalnya, web.example.com:80) untuk pemilihan rute traffic.

• Anda dapat melihat resource load balancer yang dibuat GKE untuk Gateway di Konsol Google Cloud , tetapi resource ini tidak mereferensikan cluster GKE atau Gateway tempatnya terpasang.

• Anda tidak dapat membuat sertifikat SSL yang dikelola Google secara otomatis dengan Gateway, tetapi Anda dapat membuat dan mereferensikan sertifikat SSL yang dikelola Google secara manual. Untuk mengetahui informasi selengkapnya, silakan melihat Mengamankan Gateway.

• HTTPRoute adalah satu-satunya jenis Route yang didukung. TCPRoute, UDPRoute, dan TLSRoute tidak didukung. Untuk melihat daftar kolom yang didukung oleh GKE Gateway Controller, silakan melihat Kemampuan GatewayClass.

• Header permintaan dan respons kustom dengan Gateway atau pengalihan jalur, serta penulisan ulang URL dengan Gateway hanya tersedia di GKE versi 1.27 atau yang lebih baru.

• Untuk header permintaan dan respons kustom dengan Gateway dan pengalihan jalur, serta penulisan ulang URL dengan Gateway, GatewayClass gke-l7-gxlb tidak didukung.

• Saat mengonfigurasi header permintaan kustom HTTPRoute, variabelGoogle Cloud origin_request_header tidak didukung. Untuk mengonfigurasi CORS, Anda dapat menggunakan jenis filter CORS.

• Batasan Load Balancer Aplikasi klasikGoogle Cloud berlaku untuk GKE Gateway. Selain itu, Anda tidak dapat mengonfigurasi header respons Host kustom di layanan backend.

• Pengalihan jalur dan penulisan ulang URL tidak dapat muncul secara bersamaan, Anda tidak dapat menggunakan kedua filter secara bersamaan dalam aturan yang sama.

• Pengalihan traffic ke port lain tidak didukung dengan Cloud Load Balancing. Untuk melihat daftar kolom yang didukung oleh GKE Gateway Controller, silakan melihat Kemampuan GatewayClass.

• GKE Gateway tidak mendukung karakter pengganti dan URL dinamis. Ekspresi reguler tidak didukung dengan GatewayClass gke-l7-gxlb dan gke-l7-gxlb-mc. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi pencocokan ekspresi reguler.

• Jika Anda menentukan Gateway dengan class gateway eksternal regional, pengontrol akan menyediakan alamat IP internal, bukan alamat eksternal. Untuk mempelajari cara menggunakan alamat bernama dengan Load Balancer Aplikasi eksternal regional, silakan melihat men-deploy Gateway eksternal regional.

• Gateway menggunakan NEG Mandiri untuk menyediakan Grup Endpoint Jaringan. Untuk membantu memastikan bahwa pengontrol Gateway merekonsiliasi konfigurasi load balancer dengan benar, Anda tidak dapat mengubah anotasi cloud.google.com/neg untuk Service yang merupakan bagian dari Gateway.

• GKE Gateway tidak mendukung referensi Layanan yang juga direferensikan oleh GKE Ingress.

• Jika Gateway dikonfigurasi untuk menyediakan alamat IP, mengubah Gateway.spec.gatewayClass tidak didukung. Untuk membantu memastikan bahwa pengontrol Gateway merekonsiliasi load balancer dengan benar, hapus Gateway yang ada dan deploy ulang manifes dengan nilai gatewayClass yang diperbarui.

• Anotasi networking.gke.io/app-protocols tidak didukung. Sebagai gantinya, gunakan kolom appProtocol untuk mendapatkan hasil yang sama.

• Jika Anda menggunakan Gateway GKE dengan external-dns dan status respons Gateway tidak responsif, secara default, semua data DNS yang terkait dengan Gateway akan dihapus dari zona DNS Anda.

  Praktik terbaik:

  Saat menjalankan external-dns, tetapkan flag policy=upsert-only. Konfigurasi ini membantu mencegah penghapusan data DNS yang ada.

• Jika port dihapus dari Service yang direferensikan GKE Gateway melalui rute, anotasi NEG Mandiri pada Service juga harus mengupdate pengontrol NEG Mandiri pada Service untuk menghapus port tersebut. Jika tidak, pengontrol NEG pada akhirnya akan berhenti menyinkronkan endpoint Pod untuk Service ini. Untuk mengetahui detailnya, lihat Pengontrol NEG berhenti mengelola endpoint saat port dihapus dari Service.

• Deployment yang menggunakan Gateway Multi-Cluster (MCG) yang menggunakan cluster zona rentan terhadap gangguan layanan selama upgrade cluster. Masalah ini terjadi karena mekanisme penemuan Network Endpoint Group (NEG) lama mungkin salah melaporkan nol backend saat bidang kontrol cluster zona tidak tersedia untuk sementara. Perbaikan jangka panjang sedang berlangsung. Untuk menghindari titik tunggal kegagalan ini, gunakan cluster GKE regional dengan MCG.

Mengaktifkan Gateway API di cluster Anda

Sebelum menggunakan resource Gateway di GKE, cluster Anda harus mengaktifkan Gateway API.

Sebelum Anda mengupdate cluster GKE yang ada untuk mengaktifkan Gateway API, pastikan bahwa persyaratan minimum sudah dipenuhi sebelum melanjutkan update.

Untuk mengaktifkan Gateway API pada cluster GKE yang ada (Autopilot atau Standard), gunakan perintah berikut. Operasi ini mungkin memerlukan waktu hingga 45 menit agar cluster dapat merekonsiliasi dan menginstal CustomResourceDefinition.

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Ganti kode berikut:

• CLUSTER_NAME: nama cluster yang ada.

• CLUSTER_LOCATION: region atau zona Compute Engine cluster.

Flag --gateway-api=standard menginstruksikan GKE untuk menginstal CRD Gateway API Standard Channel dengan cluster.

Memverifikasi cluster Anda

Setelah membuat atau mengupgrade cluster, GKE Gateway Controller akan otomatis menginstal GatewayClass. Mungkin perlu waktu beberapa menit bagi pengontrol untuk mengenali CRD dan menginstal GatewayClass.

1. Pastikan Gateway API diaktifkan di bidang kontrol GKE:

   gcloud container clusters describe CLUSTER_NAME \
     --location=CLUSTER_LOCATION \
     --format json
   

   Outputnya mirip dengan yang berikut ini. Jika output ini kosong, jalankan kembali perintah update cluster.

   "networkConfig": {
     ...
     "gatewayApiConfig": {
       "channel": "CHANNEL_STANDARD"
     },
     ...
   },
   

2. Pastikan GatewayClass telah diinstal di cluster Anda:

   kubectl get gatewayclass
   

   Outputnya mirip dengan berikut ini:

   NAME                             CONTROLLER                  ACCEPTED   AGE
   gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
   gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
   gke-l7-gxlb                      networking.gke.io/gateway   True       16h
   gke-l7-rilb                      networking.gke.io/gateway   True       16h
   

Untuk memahami kemampuan setiap GatewayClass, silakan melihat kemampuan GatewayClass.

Hanya GatewayClass cluster tunggal yang diinstal secara otomatis. Guna menginstal dan menggunakan GatewayClass multi-cluster untuk load balancing multi-cluster internal dan eksternal, silakan melihat Mengaktifkan Gateway multi-cluster.

Men-deploy Gateway internal

Gateway internal mengekspos aplikasi yang hanya dapat dijangkau dari dalam VPC atau jaringan yang terhubung ke VPC.

Men-deploy Gateway internal regional

Contoh berikut menunjukkan cara men-deploy Gateway internal regional yang memungkinkan komunikasi yang efisien dan aman antara layanan dalam wilayah geografis tertentu.

Mengonfigurasi subnet khusus proxy

Anda harus mengonfigurasi subnet khusus proxy sebelum membuat Gateway yang menggunakan Load Balancer Aplikasi internal. Setiap region VPC tempat Anda menggunakan Load Balancer Aplikasi internal harus memiliki subnet khusus proxy. Subnet ini menyediakan alamat IP internal ke proxy load balancer.

1. Buat subnet khusus proxy:

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
   

   Jika Anda men-deploy resource Gateway regional (gke-l7-rilb atau gke-l7-regional-external-managed) di cluster IPv6 stack tunggal, Anda harus mengonfigurasi subnet khusus proxy stack ganda dengan flag --stack-type=IPV4_IPV6. Persyaratan ini berlaku untuk resource Gateway IPv4 dan IPv6 sehingga proxy load balancer dapat berkomunikasi dengan Pod backend IPv6. Subnet khusus proxy IPv6 stack tunggal (dibuat dengan flag --stack-type=IPV6_ONLY) tidak didukung, dan jaringan VPC harus mengaktifkan rentang IPv6 ULA internal (dengan flag --enable-ula-internal-ipv6):

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE \
       --stack-type=IPV4_IPV6
   

   Catatan: Jangan tentukan flag --ipv6-access-type saat membuat atau mengupdate subnet REGIONAL_MANAGED_PROXY. Compute Engine otomatis menetapkan awalan IPv6 Alamat Lokal Unik (ULA) /64 internal dan menolak flag --ipv6-access-type pada subnet khusus proxy.

   Ganti kode berikut:

   • SUBNET_NAME: nama subnet khusus proxy.
   • COMPUTE_REGION: region subnet khusus proxy.
   • VPC_NETWORK_NAME: nama jaringan VPC tempat Anda membuat subnet khusus proxy ini. Pastikan ini adalah jaringan VPC yang sama dengan tempat cluster GKE Anda berada dan tempat Anda men-deploy Gateway. Hal ini penting untuk komunikasi yang lancar antara load balancer dan layanan backend Anda.
   • CIDR_RANGE: rentang alamat IPv4 utama subnet. Nilai ini harus berupa rentang CIDR IPv4, bahkan untuk subnet khusus proxy dual-stack (IPV4_IPV6) karena Compute Engine otomatis mengalokasikan rentang alamat IPv6. Anda harus menggunakan subnet mask dengan panjang maksimal /26 agar ada minimal 64 alamat IPv4 yang tersedia untuk proxy di region tersebut. Subnet mask yang direkomendasikan adalah /23.

2. Pastikan subnet khusus proxy Anda:

   gcloud compute networks subnets describe SUBNET_NAME \
       --region=COMPUTE_REGION
   

   Outputnya mirip dengan berikut ini (untuk subnet khusus proxy stack ganda, outputnya mencakup kolom internalIpv6Prefix, ipv6AccessType, dan ipv6GceEndpoint):

   ...
   gatewayAddress: 10.1.1.1
   internalIpv6Prefix: fd20:1d14:f522:2:0:0:0:0/64
   ipCidrRange: 10.1.1.0/24
   ipv6AccessType: INTERNAL
   ipv6GceEndpoint: VM_AND_FR
   kind: compute#subnetwork
   name: proxy-subnet
   network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
   privateIpGoogleAccess: false
   privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
   purpose: REGIONAL_MANAGED_PROXY
   region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
   role: ACTIVE
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
   stackType: IPV4_IPV6
   state: READY
   

Membuat Gateway

Resource Gateway merepresentasikan bidang data yang merutekan traffic di Kubernetes. Gateway dapat merepresentasikan berbagai jenis load balancing dan pemilihan rute, bergantung pada GatewayClass tempat gateway berasal. Untuk mempelajari resource Gateway lebih lanjut, silakan melihat deskripsi Resource Gateway atau spesifikasi API.

Dalam kasus ini, administrator cluster GKE ingin membuat Gateway yang dapat digunakan oleh tim lain untuk mengekspos aplikasi mereka secara internal. Administrator men-deploy Gateway, dan tim aplikasi men-deploy Rute mereka secara independen dan melampirkannya ke Gateway ini.

1. Simpan manifes Gateway berikut ke file bernama gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
      name: internal-http
   spec:
     # Specify an existing GatewayClass.
     gatewayClassName: gke-l7-rilb
     listeners:
     # Listen for HTTP traffic on port 80.
     - name: http
       protocol: HTTP
       port: 80
   

   Manifes ini mencakup kolom berikut:

   • gatewayClassName: gke-l7-rilb: menentukan GatewayClass yang menjadi asal Gateway ini. gke-l7-rilb sesuai dengan Load Balancer Aplikasi internal.
   • port: 80: menentukan bahwa Gateway hanya mengekspos port 80 untuk memproses traffic HTTP.

   Gateway ini dikonfigurasi untuk menangani traffic HTTP hanya di port 80. Secara default, proxy ini tidak mendukung HTTPS (port 443), dan jika Anda mencoba terhubung melalui HTTPS, permintaan mungkin akan gagal.

2. Deploy Gateway di cluster Anda:

   kubectl apply -f gateway.yaml
   

3. Validasi bahwa Gateway telah di-deploy dengan benar. Mungkin diperlukan waktu beberapa menit untuk men-deploy semua resource-nya.

   kubectl describe gateways.gateway.networking.k8s.io internal-http
   

   Outputnya mirip dengan hal berikut ini:

   Name:         internal-http
   Namespace:    default
   Spec:
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Kinds:
           Group:  gateway.networking.k8s.io
           Kind:   HTTPRoute
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
    Status:
      Addresses:
        Type:   IPAddress
        Value:  192.168.1.14
      Conditions:
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
        Observed Generation:   1
        Reason:                Scheduled
        Status:                True
        Type:                  Scheduled
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Accepted
        Status:                True
        Type:                  Accepted
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Programmed
        Status:                True # Indicates that the Gateway is ready.
        Type:                  Programmed
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:               The OSS Gateway API has altered the "Ready" condition semantics and reserved it for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
        Observed Generation:   1
        Reason:                Ready
        Status:                True
        Type:                  Ready
        Last Transition Time:  2025-03-19T19:53:46Z
        Message:
        Observed Generation:   1
        Reason:                Healthy
        Status:                True
        Type:                  networking.gke.io/GatewayHealthy
   Events:
     Type    Reason  Age                From                       Message
     ----    ------  ----               ----                       -------
     Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
     Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
     Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success
   

   Dalam output ini, status True untuk kondisi Programmed menunjukkan bahwa Gateway sudah siap.

   Pada tahap ini, ada Gateway yang di-deploy di cluster Anda yang telah menyediakan load balancer dan alamat IP. Namun, Gateway tidak memiliki Rute, sehingga tidak tahu cara mengirim traffic ke backend. Tanpa Rute, semua traffic akan mengarah ke backend default, yang menampilkan HTTP 404. Selanjutnya, Anda akan men-deploy aplikasi dan Rute, yang memberi tahu Gateway cara menjangkau backend aplikasi.

Men-deploy aplikasi demo

Tim aplikasi dapat men-deploy aplikasi dan Rute mereka secara independen dari deployment Gateway. Dalam beberapa kasus, tim aplikasi mungkin juga ingin memiliki Gateway dan men-deploy-nya sendiri sebagai resource yang dikhususkan untuk aplikasi mereka. Lihat Binding rute untuk mengetahui berbagai model kepemilikan Gateway dan Rute. Namun, dalam contoh ini, tim toko men-deploy aplikasi mereka dan HTTPRoute yang menyertainya untuk mengekspos aplikasi mereka melalui Gateway internal-http yang dibuat di bagian sebelumnya.

Resource HTTPRoute memiliki banyak kolom yang dapat dikonfigurasi untuk pencocokan traffic. Untuk penjelasan tentang kolom HTTPRoute, silakan melihat spesifikasi API.

1. Deploy aplikasi toko (deployment store-v1, store-v2, dan store-german) ke cluster Anda:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Tindakan ini akan membuat tiga Deployment dan tiga Service yang diberi nama store-v1, store-v2, dan store-german.

2. Validasi bahwa aplikasi telah berhasil di-deploy:

   kubectl get pod
   

   Outputnya akan mirip dengan berikut ini setelah aplikasi berjalan:

   NAME                        READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Validasi bahwa Service telah di-deploy:

   kubectl get service
   

   Output menampilkan Layanan untuk setiap Deployment toko:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Men-deploy HTTPRoute

Resource rute menentukan aturan khusus protokol untuk memetakan traffic dari Gateway ke backend Kubernetes. Resource HTTPRoute melakukan pencocokan dan pemfilteran traffic HTTP dan HTTPS, serta didukung oleh semua GatewayClass gke-l7.

Di bagian ini, Anda akan men-deploy HTTPRoute, yang memprogram Gateway dengan aturan pemilihan rute yang diperlukan untuk menjangkau aplikasi toko Anda.

1. Simpan manifes HTTPRoute berikut ke file bernama store-route.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store
   spec:
     # Attach the HTTPRoute to a Gateway.
     parentRefs:
     - kind: Gateway
       name: internal-http
     # Route requests that have `store.example.com` in the Host header.
     hostnames:
     - "store.example.com"
     rules:
     # Send requests with the `env: canary` header to the `store-v2` Service.
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     # Send requests with `/de` in the path to the `store-german` Service.
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
     # Send unmatched requests to the store-v1 Service.
     - backendRefs:
       - name: store-v1
         port: 8080
   

2. Deploy HTTPRoute di cluster Anda:

   kubectl apply -f store-route.yaml
   

   HTTPRoute store terikat dengan Gateway internal-http menggunakan properti parentRefs. Aturan pemilihan rute ini dikonfigurasi pada load balancer yang mendasarinya, seperti dalam diagram berikut:

   

   Aturan pemilihan rute ini memproses traffic HTTP dengan cara berikut:

   • Traffic ke store.example.com/de dirutekan ke store-german Layanan.
   • Traffic ke store.example.com dengan header HTTP "env: canary" dirutekan ke store-v2 Layanan.
   • Sisa traffic ke store.example.com dirutekan ke store-v1 Layanan.

3. Pastikan HTTPRoute telah di-deploy:

   kubectl describe httproute store
   

   Outputnya mirip dengan berikut ini:

   Name:         store
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1
   Kind:         HTTPRoute
   # Multiple lines are omitted here.
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   internal-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
   Events:
     Type    Reason  Age                From                   Message
     ----    ------  ----               ----                   -------
     Normal  ADD     24m                sc-gateway-controller  default/store
     Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
     # Multiple lines are omitted here.
   

4. Pastikan HTTPRoute terikat ke Gateway:

   kubectl describe gateway
   

   Outputnya mirip dengan berikut ini:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.128.15.203
     Conditions:
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T03:47:01Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    http
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Mengirim traffic ke aplikasi Anda

Setelah Gateway, Route, dan aplikasi di-deploy di cluster, Anda dapat meneruskan traffic ke aplikasi. Gateway dikonfigurasi untuk menyalurkan traffic HTTP hanya di port 80. Permintaan yang dibuat dengan HTTPS mungkin gagal, kecuali jika TLS telah dikonfigurasi secara terpisah.

1. Ambil alamat IP dari Gateway agar Anda dapat mengirim traffic ke aplikasi:

   kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
   

   Output-nya adalah alamat IP.

2. Kirim traffic ke alamat IP ini dari instance virtual machine (VM) dengan konektivitas ke cluster. Langkah ini diperlukan karena Gateway memiliki alamat IP internal dan hanya dapat diakses dari dalam jaringan VPC Anda. Karena internal-http adalah load balancer regional, VM klien harus berada dalam region yang sama dengan cluster GKE.

   Buat VM pengujian di jaringan VPC dan region yang sama:

   gcloud compute instances create test-vm \
       --zone=COMPUTE_ZONE \
       --network=VPC_NETWORK_NAME
   

   Hubungkan ke VM menggunakan SSH:

   gcloud compute ssh test-vm --zone=COMPUTE_ZONE
   

   Dari dalam shell VM, buat permintaan ke store.example.com:

   curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   Ganti GATEWAY_IP_ADDRESS dengan alamat IP dari langkah sebelumnya.

   Output dari aplikasi demo menampilkan informasi tentang lokasi tempat aplikasi berjalan:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:31:17",
     "zone": "ZONE_NAME"
   }
   

3. Uji kecocokan jalur dengan membuka layanan toko versi Jerman di store.example.com/de:

   curl http://store.example.com/de --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   Output tersebut mengonfirmasi bahwa permintaan dilayani oleh Pod store-german:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!", 
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl", 
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:35:37",
     "zone": "ZONE_NAME"
   }
   

4. Terakhir, gunakan header HTTP env: canary untuk mengirim traffic ke versi canary Layanan toko:

   curl -H "env: canary" http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v
   

   Output tersebut mengonfirmasi bahwa permintaan dilayani oleh Pod store-v2:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2", 
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb", 
     "pod_name_emoji": "🦰",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:38:26",
     "zone": "ZONE_NAME"
   }
   

Men-deploy Gateway eksternal

Gateway eksternal mengekspos aplikasi yang dapat dijangkau dari internet atau jaringan di luar jaringan VPC Anda. Deployment ini mirip dengan deployment Gateway internal, tetapi Anda harus mengamankan aplikasi karena Gateway dapat diakses oleh internet publik.

Anda memiliki dua opsi untuk membuat Gateway eksternal: Gateway eksternal global atau Gateway eksternal regional.

• Gateway eksternal regional: Gateway ini menggunakan alamat IP regional sebagai frontend Gateway. Perilaku Gateway ini bergantung pada Network Service Tier yang Anda pilih:
  • Jika Anda memilih Network Service Tiers Standard (default), alamat IP regional hanya diberitahukan di region Compute Google Cloud lokal tempat Gateway eksternal regional di-deploy. Klien yang mengirim traffic ke alamat IP ini dirutekan oleh ISP lokal mereka dan melalui internet publik sebelum mencapai region Google tempat alamat IP tersebut diiklankan.
  • Jika Anda memilih Network Service Tier Premium, alamat IP regional akan diberitahukan di seluruh jaringan global Google. Artinya, traffic klien memasuki backbone global berkualitas tinggi milik Google di titik peering edge Google yang sedekat mungkin dengan klien, meskipun tujuannya adalah alamat IP regional. Lokasi ini mengurangi latensi secara signifikan dan meningkatkan performa dengan meminimalkan jarak tempuh traffic melalui internet publik.
• Gateway eksternal global: Gateway ini menggunakan alamat IP global (atau alamat IP Anycast) sebagai frontend Gateway. Alamat IP ini diberitahukan di semua region Google Cloud Compute. Klien yang mengirim traffic ke alamat IP Anycast ini akan dirutekan ke lokasi Google terdekat tempat alamat IP tersebut diiklankan. Gateway eksternal global hanya tersedia di Network Service Tiers Premium.

Men-deploy Gateway eksternal regional

Contoh berikut menunjukkan cara mengekspos aplikasi toko dengan beberapa sertifikat yang dilampirkan ke Gateway eksternal regional menggunakan HTTPRoute dan sertifikat yang dikelola sendiri.

Membuat subnet proxy untuk Gateway regional Anda

Anda harus mengonfigurasi subnet khusus proxy sebelum membuat Gateway yang menggunakan Load Balancer Aplikasi eksternal regional. Setiap region VPC tempat Anda menggunakan Load Balancer Aplikasi eksternal regional harus memiliki subnet external_managed_proxy. Subnet ini menyediakan alamat IP internal ke proxy load balancer.

Membuat sertifikat untuk mengamankan traffic klien Anda

Anda dapat menggunakan sertifikat yang diterbitkan dan divalidasi oleh certificate authority (CA) atau membuat sertifikat yang ditandatangani sendiri. Untuk mengetahui informasi selengkapnya tentang cara membuat sertifikat, silakan melihat Menyimpan sertifikat di Secret Kubernetes.

Untuk mengamankan traffic antara klien dan Gateway regional, Anda dapat menggunakan metode berikut:

• Sertifikat Certificate Manager yang dikelola Google atau dikelola sendiri
• Sertifikat SSL regional yang dikelola sendiri
• Secret Kubernetes

CertificateMap atau sertifikat SSL yang dikelola Google tidak didukung dengan Gateway regional.

Untuk mengetahui informasi selengkapnya, lihat Sertifikat dan load balancer Google Cloud .

Membuat Gateway HTTP(S) eksternal regional

1. Buat alamat IP statis regional untuk load balancer eksternal.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Ganti kode berikut:

   • IP_ADDRESS_NAME: nama alamat IP statis yang baru.
   • COMPUTE_REGION: Region Compute Engine tempat cluster Anda berjalan.

2. Buat Gateway Load Balancer Aplikasi eksternal regional menggunakan sertifikat yang dikelola sendiri sebagai berikut, dan simpan manifesnya sebagai regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1
     metadata:
       name: external-regional-http
     spec:
       # Name of an existing GatewayClass.
       gatewayClassName: gke-l7-regional-external-managed
       # Listen for HTTPS traffic on port 443
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           # Terminate the TLS session with the client at the Gateway.
           mode: Terminate
           # Certificates for the Gateway to use to create a new TLS session.
           certificateRefs:
           - name: store-example-com
       # The name of the static IP address of the external load balancer.
       # You can also use the `IPAddress` type to specify the actual IP address.
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Terapkan manifes regional-gateway:

     kubectl apply -f regional-gateway.yaml
   

4. Verifikasi konfigurasi Anda.

     kubectl get gateway
   

   Outputnya mirip dengan berikut ini:

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

   kubectl describe gateway
   

   Outputnya mirip dengan hal berikut ini:

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Men-deploy aplikasi demo

Tim aplikasi dapat men-deploy aplikasi dan Rute mereka secara independen dari deployment Gateway. Dalam beberapa kasus, tim aplikasi mungkin juga ingin memiliki Gateway dan men-deploy-nya sendiri sebagai resource yang dikhususkan untuk aplikasi mereka. Lihat Binding rute untuk berbagai model kepemilikan Gateway dan Rute. Dalam contoh ini, tim toko men-deploy aplikasi mereka dan HTTPRoute yang menyertainya untuk mengekspos aplikasi mereka melalui Gateway external-http yang dibuat di bagian sebelumnya.

Untuk informasi selengkapnya tentang kolom HTTPRoute, silakan melihat spesifikasi API.

1. Deploy aplikasi sampel ke cluster Anda:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Aplikasi sampel ini membuat tiga Deployment dan tiga Layanan yang diberi nama store-v1, store-v2, dan store-german.

2. Pastikan bahwa aplikasi telah berhasil di-deploy:

   kubectl get pod
   

   Outputnya mirip dengan berikut ini:

   NAME                            READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Pastikan bahwa Layanan telah berhasil di-deploy:

   kubectl get service
   

   Outputnya mirip dengan berikut ini:

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Membuat HTTPRoute

Resource rute menentukan aturan khusus protokol untuk memetakan traffic dari Gateway ke backend Kubernetes. Resource HTTPRoute melakukan pencocokan dan pemfilteran traffic HTTP dan HTTPS serta didukung oleh semua GatewayClass gke-l7-*.

Di bagian ini, Anda akan men-deploy HTTPRoute, yang mengonfigurasi Gateway dengan aturan pemilihan rute yang diperlukan untuk menjangkau aplikasi sampel.

1. Simpan manifes berikut ke file bernama store-route-external.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: store-external
   spec:
     parentRefs:
     # Bind the route to the 'external-http' Gateway.
     - kind: Gateway
       name: external-http
     hostnames:
     - "store.example.com"
     rules:
     # Default rule for store.example.com that sends traffic to the store-v1 service.
     - backendRefs:
       - name: store-v1
         port: 8080
     # Match requests with the "env: canary" header and send them to the store-v2 service.
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     # Match requests with the path "/de" and sends them to the store-german service.
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

   Manifes ini menjelaskan HTTPRoute yang mereferensikan Gateway external-http.

2. Terapkan manifes ke cluster Anda:

   kubectl apply -f store-route-external.yaml
   

   HTTPRoute store terikat dengan Gateway external-http menggunakan properti parentRefs. Diagram berikut menunjukkan aturan pemilihan rute yang dikonfigurasi pada load balancer yang mendasarinya:

   

   Aturan pemilihan rute memproses traffic HTTP sebagai berikut:

   • Traffic ke store.example.com/de dirutekan ke store-german Layanan.
   • Traffic ke store.example.com dengan header HTTP "env: canary" dirutekan ke store-v2 Layanan.
   • Sisa traffic ke store.example.com dirutekan ke store-v1 Layanan.

3. Pastikan HTTPRoute telah di-deploy:

   kubectl describe httproute store-external
   

   Outputnya mirip dengan berikut ini:

   Name:         store-external
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1
   Kind:         HTTPRoute
   # Multiple lines are omitted here.
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   external-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       # This section shows the status of this route in relation to each Gateway attached.
       Conditions:
         Last Transition Time:  2022-11-01T05:42:31Z
         Message:
         Reason:                Accepted
         Status:                True # Means that the Gateway has validated and accepted this route's configuration.
         Type:                  Accepted
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
   Events:
     Type     Reason  Age    From                   Message
     ----     ------  ----   ----                   -------
     Normal   ADD     2m48s  sc-gateway-controller  default/store-external
     Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
     ...
   

4. Pastikan HTTPRoute terikat ke Gateway:

   kubectl describe gateway external-http
   

   Outputnya mirip dengan berikut ini:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   # Multiple lines are omitted here.
   Status:
     Addresses:
       Type:   IPAddress
       Value:  34.149.207.45
     Conditions:
       Last Transition Time:  2022-11-01T05:37:21Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T05:43:18Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    https
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         # Multiple lines are omitted here.
   

Mengirim traffic ke aplikasi Anda

Setelah Gateway, Route, dan aplikasi di-deploy di cluster, Anda dapat meneruskan traffic ke aplikasi.

1. Dapatkan alamat IP Gateway:

   kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Output-nya adalah alamat IP.

2. Buat VM:

   gcloud cloud-shell ssh
   

3. Kirim traffic ke alamat IP Gateway dari VM. Anda harus menetapkan header host secara manual karena Anda bukan pemilik nama host example.com.

   curl https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Ganti GATEWAY_IP_ADDRESS dengan alamat IP Gateway dari langkah sebelumnya.

   cacert.pem: file sertifikat yang Anda buat. Anda harus menyimpan file ini di komputer yang digunakan untuk terhubung ke Gateway.

   Output menampilkan informasi dari aplikasi demo tentang lokasi tempat aplikasi berjalan:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:31:17",
     "zone": "us-central1-a"
   }
   

4. Uji kecocokan jalur dengan membuka layanan store versi Jerman di store.example.com/de:

   curl https://store.example.com/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Output tersebut mengonfirmasi bahwa permintaan dilayani oleh Pod store-german:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!",
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl",
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:35:37",
     "zone": "us-central1-a"
   }
   

5. Kirim traffic ke versi canary Service store menggunakan header HTTP env: canary:

   curl -H "env: canary" https://store.example.com --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Output tersebut mengonfirmasi bahwa permintaan dilayani oleh Pod store-v2:

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb",
     "pod_name_emoji": "👩🏿",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:38:26",
     "zone": "us-central1-a"
   }
   

Men-deploy Gateway eksternal global

Contoh berikut menunjukkan cara mengekspos aplikasi toko dengan beberapa sertifikat yang dilampirkan ke Gateway eksternal global dan dikelompokkan dalam peta sertifikat menggunakan Certificate Manager dan HTTPRoute.

Buat peta sertifikat

Google merekomendasikan agar Anda menggunakan Certificate Manager untuk mengelola sertifikat jika memerlukan 15 sertifikat atau lebih per Gateway atau Anda harus menggunakan sertifikat karakter pengganti.

Anda juga dapat mengamankan Gateway eksternal menggunakan Secret Kubernetes atau sertifikat SSL yang dikelola Google. Untuk mengetahui informasi selengkapnya, silakan melihat Keamanan gateway.

Di bagian ini, Anda akan membuat sertifikat menggunakan Certificate Manager untuk mengamankan aplikasi yang berjalan di cluster tersebut.

1. Aktifkan Certificate Manager API:

   gcloud services enable certificatemanager.googleapis.com
   

2. Buat peta sertifikat:

   gcloud beta certificate-manager maps create store-example-com-map
   

3. Muat sertifikat dan kunci yang dikelola Google ke dalam Certificate:

   gcloud beta certificate-manager certificates create store-example-com-cert \
       --certificate-file="CERTIFICATE_FILE" \
       --private-key-file="PRIVATE_KEY_FILE"
   

   Ganti kode berikut:

   • CERTIFICATE_FILE: nama file sertifikat Anda. File harus memiliki ekstensi .pem. Contohnya, cert.pem.
   • PRIVATE_KEY_FILE: nama file kunci pribadi Anda.

   Untuk mengetahui informasi selengkapnya, silakan melihat Membuat kunci pribadi dan sertifikat.

4. Buat CertificateMapEntry yang menetapkan sertifikat ke peta sertifikat:

   gcloud beta certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Untuk mempelajari cara mengamankan Gateway menggunakan sumber lain untuk sertifikat, seperti Secret Kubernetes atau sertifikat SSL, silakan melihat Mengamankan Gateway.

Membuat Gateway

Resource Gateway merepresentasikan bidang data yang merutekan traffic di Kubernetes. Gateway dapat merepresentasikan berbagai jenis load balancing dan pemilihan rute, bergantung pada GatewayClass yang digunakannya.

Untuk mempelajari resource Gateway lebih lanjut, silakan melihat deskripsi resource Gateway atau spesifikasi API.

Di bagian ini, Anda akan membuat Gateway. Tim aplikasi dapat menggunakan Gateway untuk mengekspos aplikasi mereka ke internet dengan men-deploy Rute secara independen dan melampirkannya dengan aman ke Gateway.

1. Simpan manifes berikut ke file bernama gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     # This GatewayClass uses a global external Application Load Balancer.
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
   
   

   Manifes ini menjelaskan Gateway dengan kolom berikut:

   • gatewayClassName: gke-l7-global-external-managed: menentukan GatewayClass untuk Gateway ini. Class gateway ini menggunakan Load Balancer Aplikasi eksternal global.
   • protocol: HTTPS dan port: 443: menentukan bahwa Gateway mengekspos port 443 untuk traffic HTTPS. Kolom ini mengaktifkan TLS.
   • networking.gke.io/certmap: store-example-com-map: menentukan nama pemetaan sertifikat di Certificate Manager.

   Tidak ada bagian TLS karena TLS dikonfigurasi dengan Certificate Manager menggunakan anotasi networking.gke.io/certmap.

2. Terapkan manifes ke cluster Anda:

   kubectl apply -f gateway.yaml
   

   Mungkin perlu waktu beberapa menit bagi GKE untuk men-deploy resource.

3. Pastikan Gateway berhasil di-deploy:

   kubectl describe gateway
   

   Outputnya mirip dengan berikut ini:

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-global-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
    ...
   

   Output ini menunjukkan bahwa Gateway yang di-deploy di cluster Anda memiliki load balancer dan alamat IP publik. Gateway tidak memiliki Rute, yang berarti Gateway tidak dapat mengirim traffic ke backend. Tanpa Rute, semua traffic akan mengarah ke backend default, yang menampilkan respons HTTP 404. Di bagian berikutnya, Anda akan men-deploy Route, yang menginstruksikan Gateway untuk mengirim traffic ke backend.

Men-deploy aplikasi demo

Anda dapat men-deploy aplikasi dan rute secara independen dari deployment Gateway.

Untuk informasi selengkapnya tentang cara men-deploy aplikasi demo, silakan melihat Men-deploy aplikasi demo.

Membuat HTTPRoute

Anda harus membuat HTTPRoute untuk melakukan pencocokan dan pemfilteran traffic HTTP dan HTTPS.

Mengirim Traffic ke aplikasi Anda

Setelah men-deploy aplikasi dan membuat HTTPRoute, Anda dapat meneruskan traffic ke aplikasi Anda.

Untuk mengetahui informasi selengkapnya tentang cara mengirim traffic ke aplikasi, silakan melihat Mengirim traffic ke aplikasi.

Men-deploy Gateway eksternal regional

Contoh berikut menunjukkan cara mengekspos aplikasi toko dengan beberapa sertifikat yang dilampirkan ke Gateway eksternal regional menggunakan HTTPRoute dan sertifikat yang dikelola sendiri.

Membuat subnet proxy untuk Gateway regional Anda

Anda harus mengonfigurasi subnet khusus proxy sebelum membuat Gateway yang menggunakan Load Balancer Aplikasi eksternal regional. Setiap region VPC tempat Anda menggunakan Load Balancer Aplikasi eksternal regional harus memiliki subnet external_managed_proxy. Subnet ini menyediakan alamat IP internal ke proxy load balancer.

Membuat sertifikat untuk mengamankan traffic klien Anda

Anda dapat menggunakan sertifikat yang diterbitkan dan divalidasi oleh certificate authority (CA) atau membuat sertifikat yang ditandatangani sendiri. Untuk mengetahui informasi selengkapnya tentang cara membuat sertifikat, silakan melihat Menyimpan sertifikat di Secret Kubernetes.

Untuk mengamankan traffic antara klien dan Gateway regional, Anda dapat menggunakan metode berikut:

• Sertifikat Certificate Manager yang dikelola Google atau dikelola sendiri
• Sertifikat SSL regional yang dikelola sendiri
• Secret Kubernetes

CertificateMap atau sertifikat SSL yang dikelola Google tidak didukung dengan Gateway regional.

Untuk mengetahui informasi selengkapnya, lihat Sertifikat dan load balancer Google Cloud

Membuat Gateway HTTP(S) eksternal regional

Catatan: Pada cluster IPv6 stack tunggal yang subnet node utamanya menggunakan alamat IPv6 internal (--ipv6-access-type=INTERNAL), resource Gateway IPv6 gke-l7-regional-external-managed memerlukan subnet terpisah di jaringan VPC dan region yang sama dengan --ipv6-access-type=EXTERNAL. Tentukan subnet tersebut menggunakan flag --subnet saat membuat alamat IPv6 statis, atau lampirkan resource GCPGatewayPolicy dengan kolom spec.default.subnetwork yang ditetapkan saat menggunakan alamat IPv6 sementara. Untuk mengetahui petunjuknya, lihat Persyaratan subnet IPv6 eksternal regional pada cluster IPv6 internal.

1. Buat alamat IP statis regional untuk load balancer eksternal.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Ganti kode berikut:

   • IP_ADDRESS_NAME: nama alamat IP statis yang baru.
   • COMPUTE_REGION: Region Compute Engine tempat cluster Anda berjalan.

2. Buat Gateway Load Balancer Aplikasi eksternal regional menggunakan sertifikat yang dikelola sendiri sebagai berikut, dan simpan manifesnya sebagai regional-gateway.yaml:

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1
     metadata:
       name: external-regional-http
     spec:
       # Name of an existing GatewayClass.
       gatewayClassName: gke-l7-regional-external-managed
       # Listen for HTTPS traffic on port 443
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           # Terminate the TLS session with the client at the Gateway.
           mode: Terminate
           # Certificates for the Gateway to use to create a new TLS session.
           certificateRefs:
           - name: store-example-com
       # The name of the static IP address of the external load balancer.
       # You can also use the `IPAddress` type to specify the actual IP address.
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Terapkan manifes regional-gateway:

     kubectl apply -f regional-gateway.yaml
   

4. Verifikasi konfigurasi Anda.

     kubectl get gateway
   

   Outputnya mirip dengan berikut ini:

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

   kubectl describe gateway
   

   Outputnya mirip dengan berikut ini:

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Men-deploy aplikasi demo

Anda dapat men-deploy aplikasi dan rute secara independen dari deployment Gateway.

Untuk informasi selengkapnya tentang cara men-deploy aplikasi demo, silakan melihat Men-deploy aplikasi demo.

Membuat HTTPRoute

Anda harus membuat HTTPRoute untuk melakukan pencocokan dan pemfilteran traffic HTTP dan HTTPS.

Mengirim Traffic ke aplikasi Anda

Setelah men-deploy aplikasi dan membuat HTTPRoute, Anda dapat meneruskan traffic ke aplikasi Anda.

Untuk mengetahui informasi selengkapnya tentang cara mengirim traffic ke aplikasi, silakan melihat Mengirim traffic ke aplikasi.

Menggunakan Gateway bersama

Gateway API menggunakan resource terpisah, yaitu resource Gateway dan Rute, untuk men-deploy load balancer dan aturan pemilihan rute. Ini berbeda dari Ingress, yang menggabungkan semuanya dalam satu resource. Dengan membagi tanggung jawab antar-resource, Gateway memungkinkan load balancer dan aturan pemilihan rutenya di-deploy secara terpisah serta di-deploy oleh pengguna atau tim yang berbeda. Hal ini memungkinkan Gateway menjadi Gateway bersama yang terlampir di banyak Rute yang berbeda, yang dapat dimiliki dan dikelola sepenuhnya oleh tim independen, bahkan di berbagai namespace.

Men-deploy rute terhadap Gateway bersama

Contoh ini dibuat berdasarkan Gateway internal-http yang di-deploy di Men-deploy Gateway internal.

Dalam contoh ini, tim situs men-deploy aplikasi, Layanan, dan HTTPRoute mereka untuk mencocokkan traffic dari Gateway ke Layanan tersebut.

1. Deploy aplikasi sampel:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
   

2. Simpan manifes berikut ke file bernama site-route-internal.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: site-internal
   spec:
     # Attach the HTTPRoute to the `internal-http` Gateway.
     parentRefs:
     - kind: Gateway
       name: internal-http
     # Route requests that have `site.example.com` in the Host header.
     hostnames:
     - "site.example.com"
     # Send all requests to the `site-v1` Service.
     rules:
     - backendRefs:
       - name: site-v1
         port: 8080
   

   Manifes ini menjelaskan HTTPRoute yang cocok dengan semua traffic untuk site.example.com dan merutekannya ke Layanan site-v1.

3. Terapkan manifes ke cluster Anda:

   kubectl apply -f site-route-internal.yaml
   

4. Pastikan bahwa HTTPRoute terlampir di Gateway:

   kubectl describe httproute.gateway.networking.k8s.io site-internal
   

   Outputnya mirip dengan berikut ini:

   Status:
     Parents:
       Conditions:
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
         ...
   

   Jika kondisi Accepted untuk Gateway adalah True, HTTPRoute telah berhasil terikat ke Gateway. Untuk mempelajari kolom Status lebih lanjut, silakan melihat status rute.

5. Pastikan traffic ke Gateway dirutekan dengan benar:

   curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
   curl -H "host: store.example.com" GATEWAY_IP_ADDRESS
   

   Ganti GATEWAY_IP_ADDRESS dengan alamat IP Gateway internal.

   Anda harus menggunakan virtual machine (VM) di VPC yang sama dengan Gateway.

   Outputnya mirip dengan hal berikut ini:

   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "site.example.com",
     "metadata": "site-v1",
     "pod_name": "site-v1-5d64fc4d7d-fz6f6",
     "pod_name_emoji": "👩🏼‍🍳",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   ...
   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "pod_name": "store-v1-6d8d58d78-vz8pn",
     "pod_name_emoji": "🧝🏻‍♂️",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   

   Output ini menunjukkan bahwa permintaan dengan header Host site.example.com mencapai Service site-v1, sedangkan permintaan dengan header Host store.example.com mencapai Service store-v1.

Mengonfigurasi tingkat jaringan

Anda dapat menentukan tingkat jaringan dan versi IP untuk alamat pemroses sementara Gateway menggunakan kolom type dalam array addresses[] di definisi Gateway. Jika Anda menghilangkan kolom spec.addresses, pengontrol Gateway akan menyediakan alamat IP sementara default berdasarkan jenis stack cluster Anda (alamat IPv4 pada cluster IPv4 stack tunggal dan stack ganda, atau alamat IPv6 pada cluster IPv6 stack tunggal jika subnetwork yang kompatibel tersedia). Untuk resource Gateway gke-l7-regional-external-managed, jika kolom spec.addresses dihilangkan, alamat IPv4 sementara Paket Standar akan ditetapkan secara default di cluster IPv4 stack tunggal dan stack ganda, atau alamat IPv6 sementara Paket Premium di cluster IPv6 stack tunggal (Paket Standar tidak didukung untuk alamat IPv6).

Pada cluster IPv6 stack tunggal, saat mengalokasikan alamat IP sementara untuk resource Gateway regional (gke-l7-rilb atau gke-l7-regional-external-managed), pengontrol Gateway memilih subnetwork dalam urutan berikut:

1. Jika resource GCPGatewayPolicy yang dilampirkan ke resource Gateway menentukan kolom spec.default.subnetwork, alamat IP sementara akan dialokasikan dari subnetwork tersebut.
2. Jika tidak ada subnetwork yang ditentukan dalam resource GCPGatewayPolicy dan subnetwork node utama cluster memiliki jenis akses IPv6 yang diperlukan (INTERNAL untuk gke-l7-rilb atau EXTERNAL untuk gke-l7-regional-external-managed), alamat IP sementara akan dialokasikan dari subnetwork node utama.
3. Jika tidak ada subnetwork yang kompatibel, pengontrol Gateway akan melaporkan error. Untuk mengetahui petunjuk cara mengonfigurasi subnetwork kustom, lihat Persyaratan subnet IPv6 eksternal regional pada cluster IPv6 internal.

Gunakan nilai berikut untuk kolom type:

• networking.gke.io/premium-ephemeral-ipv4-address: menetapkan alamat IPv4 sementara Paket Premium (gke-l7-regional-external-managed).
• networking.gke.io/standard-ephemeral-ipv4-address: menetapkan alamat IPv4 sementara Paket Standar (gke-l7-regional-external-managed).
• networking.gke.io/premium-ephemeral-ipv6-address: menetapkan alamat IPv6 sementara Paket Premium (gke-l7-regional-external-managed).
• networking.gke.io/ephemeral-ipv4-address/REGION: menetapkan alamat IPv4 sementara regional di REGION (gke-l7-rilb dan gke-l7-cross-regional-internal-managed-mc).
• networking.gke.io/ephemeral-ipv6-address/REGION: menetapkan alamat IPv6 sementara regional di REGION (gke-l7-rilb).

Untuk menetapkan alamat IP dari kedua tingkat jaringan atau kedua versi IP (misalnya, alamat IPv4 dan alamat IPv6 di cluster dual-stack), tentukan beberapa jenis di kolom addresses.

Contoh berikut menunjukkan cara membuat Google Cloud menetapkan alamat IP Paket Premium ke Gateway. Untuk menyediakan alamat IPv4 Paket Standar, gunakan networking.gke.io/standard-ephemeral-ipv4-address.

1. Simpan manifes contoh berikut sebagai external-regional-http.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-regional-http
   spec:
     # Name of an existing GatewayClass.
     gatewayClassName: gke-l7-regional-external-managed
     # Listen for HTTPS traffic on port 443.
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
       tls:
         # Terminate the TLS session with the client at the Gateway.
         mode: Terminate
         # Certificates for the Gateway to use to create a new TLS session.
         certificateRefs:
         - name: store-example-com
     addresses:
     # Request a Premium Tier ephemeral IPv4 address for the Gateway.
     # For a Premium Tier ephemeral IPv6 address, use:
     # networking.gke.io/premium-ephemeral-ipv6-address
     - type: networking.gke.io/premium-ephemeral-ipv4-address
   

   Catatan: Untuk menyediakan alamat IPv4 Paket Standar, gunakan networking.gke.io/standard-ephemeral-ipv4-address.

2. Terapkan manifes contoh:

   kubectl apply -f external-regional-http.yaml
   

Catatan: Jika Anda membuat resource Gateway Load Balancer Aplikasi eksternal regional yang menggunakan GatewayClass gke-l7-regional-external-managed tanpa menentukan alamat di kolom spec.addresses, Gateway akan secara default menggunakan alamat IPv4 sementara Paket Standar (pada cluster IPv4 stack tunggal dan stack ganda) atau alamat IPv6 sementara Paket Premium (pada cluster IPv6 stack tunggal). Mengubah manifes Gateway nanti untuk menentukan jenis alamat eksplisit, seperti networking.gke.io/standard-ephemeral-ipv4-address, networking.gke.io/premium-ephemeral-ipv4-address, atau networking.gke.io/premium-ephemeral-ipv6-address, akan mengakibatkan perubahan alamat IP, yang dapat mengganggu layanan. Untuk mencegah gangguan layanan, tentukan konfigurasi alamat saat Anda membuat Gateway.

Mengonfigurasi backend default Gateway

Semua GatewayClass gke-l7-* menampilkan HTTP 404 ke traffic yang tidak cocok. Anda dapat mengonfigurasi backend default menggunakan Rute default eksplisit yang mengirimkan traffic yang tidak cocok ke Layanan yang disediakan pengguna.

Gateway dikonfigurasi untuk menangani kode error seperti 404 (Not Found) dan 500 (Server Error), bahkan tanpa definisi backend eksplisit. Perilaku default dapat bervariasi di antara implementasi Gateway. Untuk kontrol yang lebih besar atas penanganan error, pertimbangkan untuk mengonfigurasi backend kustom.

HTTPRoute berikut adalah contoh cara menyesuaikan backend default. Jika Anda menerapkan HTTPRoute yang mirip dengan yang berikut ini, konfigurasi tersebut akan lebih diprioritaskan daripada backend default implisit:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  # Omit the `hostnames` field to route all unmatched traffic from the
  # attached Gateway.
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

HTTPRoute ini cocok dengan semua traffic dari Gateway tertentu. Anda hanya dapat memiliki satu aturan untuk setiap Gateway. Jika tidak, aturan akan bertentangan dan pengurutan prioritas akan berlaku.

Anda dapat menggunakan backend default untuk mencegah seseorang agar tidak membuat Backend rute default yang merutekan semua traffic Gateway. HTTPRoute yang eksplisit selalu lebih diprioritaskan daripada HTTPRoute baru dengan aturan pemilihan rute yang bertentangan.

Mengonfigurasi alamat IP statis untuk Gateway

Setiap Gateway memiliki alamat IP yang digunakan untuk memproses traffic. Jika Anda tidak menentukan alamat IP di Gateway, pengontrol Gateway akan otomatis menyediakan alamat IP. Anda juga dapat membuat alamat IP statis sehingga alamat IP tersebut ada secara independen dari siklus proses Gateway.

Setelah Gateway di-deploy, alamat IP-nya akan ditampilkan di kolom status:

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

Bergantung pada GatewayClass, alamat IP dialokasikan dari pool dan subnet berikut:

GatewayClass	Kumpulan alamat IPv4 default	Kumpulan alamat IPv6 default (sementara dan statis)
gke-l7-rilb gke-l7-rilb-mc	Alamat IPv4 pribadi regional dari rentang alamat IPv4 node utama	Alamat IPv6 internal regional dari rentang alamat IPv6 internal subnet node utama (ULA /64) saat subnet node utama menggunakan ipv6AccessType: INTERNAL, atau dari subnetwork di region yang sama yang dikonfigurasi dengan ipv6AccessType: INTERNAL (khusus gke-l7-rilb)
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Alamat IPv4 publik regional dari kumpulan alamat IPv4 eksternal regional Google	Alamat IPv6 eksternal regional dari rentang alamat IPv6 eksternal subnet node utama (GUA publik /64) saat subnet node utama menggunakan ipv6AccessType: EXTERNAL, atau dari subnetwork VPC terpisah di region yang sama yang dikonfigurasi dengan ipv6AccessType: EXTERNAL (khusus gke-l7-regional-external-managed; lihat Persyaratan subnet IPv6 eksternal regional di cluster IPv6 internal)
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Alamat IPv4 publik global dari rentang alamat IPv4 eksternal global Google	Alamat IPv6 publik global dari rentang alamat IPv6 eksternal global Google

Persyaratan subnet IPv6 eksternal regional di cluster IPv6 internal

Tidak seperti alamat IPv4 eksternal regional (yang dialokasikan dari kumpulan yang dikelola Google dan tidak bergantung pada subnet VPC), alamat IPv6 eksternal regional Compute Engine (NETLB) harus dialokasikan dari subnetwork VPC yang dikonfigurasi dengan ipv6AccessType: EXTERNAL.

Jika subnet node utama cluster Anda sudah dikonfigurasi dengan --ipv6-access-type=EXTERNAL, pengontrol Gateway akan menggunakan subnet node utama secara default untuk alamat IPv6 gke-l7-regional-external-managed.

Jika cluster Anda menggunakan subnet node IPv6 internal (--ipv6-access-type=INTERNAL), subnet node utama cluster hanya memiliki Alamat Lokal Unik (ULA) pribadi. Sebelum men-deploy resource Gateway IPv6 gke-l7-regional-external-managed (menggunakan alamat IPv6 sementara atau statis), Anda harus membuat subnetwork di jaringan VPC dan region yang sama dengan --ipv6-access-type=EXTERNAL:

1. Buat subnetwork khusus IPv6 (atau stack ganda) dengan akses IPv6 eksternal di jaringan VPC dan region yang sama dengan cluster Anda:

   gcloud compute networks subnets create EXTERNAL_IPV6_SUBNET_NAME \
       --network=VPC_NETWORK_NAME \
       --region=COMPUTE_REGION \
       --stack-type=IPV6_ONLY \
       --ipv6-access-type=EXTERNAL
   

   Ganti kode berikut:

   • EXTERNAL_IPV6_SUBNET_NAME: nama subnetwork dengan akses IPv6 eksternal.
   • VPC_NETWORK_NAME: nama jaringan VPC tempat cluster GKE Anda berjalan.
   • COMPUTE_REGION: region Compute Engine tempat cluster Anda berjalan.

   Untuk membuat subnetwork dual-stack, bukan subnetwork khusus IPv6, ganti --stack-type=IPV6_ONLY dengan --stack-type=IPV4_IPV6 --range=IPV4_CIDR_RANGE, dengan IPV4_CIDR_RANGE adalah rentang CIDR IPv4 utama yang tidak digunakan di jaringan VPC.

2. Konfigurasikan resource Gateway Anda untuk menggunakan subnetwork IPv6 eksternal:

   • Untuk alamat IPv6 sementara: lampirkan resource GCPGatewayPolicy ke resource Gateway Anda dan tentukan nama subnetwork di kolom spec.default.subnetwork. Simpan manifes berikut sebagai gateway-policy.yaml:

     apiVersion: networking.gke.io/v1
     kind: GCPGatewayPolicy
     metadata:
       name: GATEWAY_POLICY_NAME
       namespace: GATEWAY_NAMESPACE
     spec:
       default:
         subnetwork: EXTERNAL_IPV6_SUBNET_NAME
       targetRef:
         group: gateway.networking.k8s.io
         kind: Gateway
         name: GATEWAY_NAME
     

     Ganti kode berikut:

     • GATEWAY_POLICY_NAME: nama resource GCPGatewayPolicy.
     • GATEWAY_NAMESPACE: namespace resource Gateway target.
     • EXTERNAL_IPV6_SUBNET_NAME: nama subnetwork yang Anda buat di langkah sebelumnya.
     • GATEWAY_NAME: nama resource Gateway target.

     Terapkan manifes gateway-policy.yaml:

     kubectl apply -f gateway-policy.yaml
     

     Catatan: Pada cluster IPv6 stack tunggal, Anda juga dapat menetapkan kolom spec.default.subnetwork di resource GCPGatewayPolicy yang dilampirkan ke resource Gateway gke-l7-rilb untuk mengalokasikan alamat IPv4 atau IPv6 internal sementara dari subnetwork kustom (misalnya, jika subnet node utama cluster Anda menggunakan --ipv6-access-type=EXTERNAL).

   • Untuk alamat IPv6 statis (NamedAddress): tentukan flag --subnet=EXTERNAL_IPV6_SUBNET_NAME saat Anda membuat resource alamat IPv6 statis, seperti yang ditunjukkan dalam Menggunakan alamat IP bernama.

Catatan: Compute Engine tidak mendukung hairpinning VPC dari sumber alamat IPv6 internal (ULA) ke tujuan load balancer alamat IPv6 eksternal (GUA) di jaringan VPC yang sama. Permintaan yang dikirim dari Pod atau VM khusus IPv6 internal dalam jaringan VPC yang sama tidak dapat menjangkau VIP IPv6 gke-l7-regional-external-managed eksternal. Uji resource Gateway IPv6 eksternal regional dari klien IPv6 eksternal di luar jaringan VPC, atau gunakan gke-l7-rilb untuk klien internal.

Kolom addresses.NamedAddress memungkinkan Anda menentukan alamat IP secara independen dari Gateway. Anda dapat membuat resource alamat IP statis sebelum deployment Gateway dan resource tersebut akan direferensikan oleh NamedAddress. Anda dapat menggunakan kembali alamat IP statis meskipun Gateway dihapus.

Menggunakan alamat IP yang telah diberi nama

Anda dapat mengonfigurasi alamat IPv4 atau alamat IPv6 statis dengan menentukan NamedAddress. Anda harus menyediakan alamat IP statis sebelum membuat Gateway.

1. Buat resource alamat IP statis:

   • Alamat IPv4 internal regional (gke-l7-rilb):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --purpose=SHARED_LOADBALANCER_VIP \
         --region=COMPUTE_REGION \
         --subnet=SUBNET \
         --project=PROJECT_ID
     

   • Alamat IPv6 internal regional (gke-l7-rilb):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --region=COMPUTE_REGION \
         --subnet=CLUSTER_NODE_SUBNET \
         --ip-version=IPV6 \
         --project=PROJECT_ID
     

     Catatan: Flag --purpose=SHARED_LOADBALANCER_VIP tidak didukung untuk alamat IPv6 internal. Anda tidak dapat berbagi satu alamat IPv6 internal statis di beberapa aturan penerusan atau pemroses Gateway di port yang berbeda.

   • Alamat IPv6 eksternal regional (gke-l7-regional-external-managed):

     gcloud compute addresses create IP_ADDRESS_NAME \
         --region=COMPUTE_REGION \
         --subnet=EXTERNAL_IPV6_SUBNET_NAME \
         --ip-version=IPV6 \
         --endpoint-type=NETLB \
         --project=PROJECT_ID
     

   Ganti kode berikut:

   • IP_ADDRESS_NAME: nama alamat IP statis yang baru.
   • COMPUTE_REGION: untuk Gateway regional, region Compute Engine tempat cluster Anda berjalan. Flag ini tidak diperlukan untuk Gateway eksternal global.
   • SUBNET atau CLUSTER_NODE_SUBNET: subnet untuk alamat IP internal. Flag ini tidak diperlukan untuk Gateway eksternal global.
   • EXTERNAL_IPV6_SUBNET_NAME: subnet regional yang dikonfigurasi dengan ipv6AccessType: EXTERNAL untuk mengalokasikan alamat IPv6 eksternal regional.
   • PROJECT_ID: project tempat cluster GKE Anda berjalan.

   Perintah sebelumnya secara otomatis mengalokasikan alamat IP dari subnet yang ditentukan. Anda juga dapat menentukan alamat IPv4 kustom atau rentang alamat IPv6 /96 kustom dengan flag --addresses. Untuk mengetahui informasi selengkapnya, lihat Mencadangkan alamat IP internal statis dan Mencadangkan alamat IP eksternal statis.

2. Simpan manifes berikut ke file bernama named-ip-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
     addresses:
     - type: NamedAddress
       value: IP_ADDRESS_NAME
   

   Manifes ini menjelaskan Gateway yang mereferensikan alamat IP yang diberi nama.

3. Terapkan manifes ke cluster Anda:

   kubectl apply -f named-ip-gateway.yaml
   

4. Verifikasi alamat IP Gateway Anda:

   kubectl describe gateway internal-http
   

   Outputnya mirip dengan hal berikut ini:

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Addresses:
       Type:              NamedAddress
       Value:             IP_ADDRESS_NAME
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.15.32.103
   

Mengonfigurasi aturan firewall IPv6 untuk VPC Bersama atau pengelolaan firewall manual

Jika pembuatan aturan firewall otomatis dinonaktifkan atau dibatasi (seperti dalam project layanan VPC Bersama), Anda harus membuat aturan firewall IPv6 ingress secara manual untuk mengizinkan traffic dari pemeriksa health check IPv6 Google Cloud (2600:2d00:1:b029::/64), proxy Google Front End (GFE) untuk Load Balancer Aplikasi eksternal global (2600:2d00:1:1::/64), dan internalIpv6Prefix subnet khusus proxy regional untuk Load Balancer Aplikasi regional:

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --network=VPC_NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --rules=tcp:80,tcp:443 \
    --source-ranges="2600:2d00:1:b029::/64,2600:2d00:1:1::/64,PROXY_SUBNET_INTERNAL_IPV6_PREFIX" \
    --target-tags=GKE_NODE_TAG

Ganti kode berikut:

• FIREWALL_RULE_NAME: nama aturan firewall.
• VPC_NETWORK_NAME: nama jaringan VPC Anda.
• PROXY_SUBNET_INTERNAL_IPV6_PREFIX: awalan IPv6 /64 internal subnet khusus proxy regional Anda (internalIpv6Prefix).
• GKE_NODE_TAG: tag jaringan yang diterapkan ke node cluster Anda.

Catatan: Di flag --rules, tentukan port TCP yang diproses oleh Pod backend Anda untuk traffic yang di-load balance dan health check (seperti tcp:80,tcp:443 atau tcp:8080).

Mengonfigurasi pengalihan HTTP ke HTTPS

Cloud Load Balancing menawarkan fungsi pengalihan HTTP ke HTTPS. Load Balancer Aplikasi eksternal mengalihkan kembali permintaan HTTP yang tidak dienkripsi ke load balancer HTTPS yang menggunakan alamat IP yang sama. Saat Anda membuat Gateway dengan pengalihan HTTP-ke-HTTPS yang diaktifkan, kedua load balancer ini akan dibuat secara otomatis. Permintaan ke alamat IP eksternal Gateway pada port 80 akan otomatis dialihkan ke alamat IP eksternal yang sama pada port 443.

Secara default, pengalihan HTTP ke HTTPS tidak ditentukan di Gateway.

Untuk mengalihkan traffic HTTP ke HTTPS, konfigurasikan Gateway untuk menangani traffic HTTP dan HTTPS. Jika Anda menonaktifkan HTTP atau HTTPS, Gateway tidak akan mengalihkan traffic.

Contoh berikut menunjukkan cara menggunakan pengalihan HTTP ke HTTPS sebagai sarana untuk membantu memastikan bahwa traffic dari klien yang menuju ke aplikasi web Anda selalu dialihkan ke halaman yang aman.

Pengalihan HTTP-ke-HTTPS tidak didukung dengan GatewayClass gke-l7-gxlb dan gke-l7-gxlb-mc. Untuk mempelajari lebih lanjut berbagai fitur yang didukung oleh setiap GatewayClass, silakan melihat Kemampuan GatewayClass.

Perhatikan bahwa bagian hostnames di HTTPRoute bersifat opsional. Anda dapat membuat pengalihan menyeluruh untuk semua nama host di port HTTP tertentu dengan menghilangkan bagian hostnames. Selain itu, Anda dapat menggunakan pengalihan karakter pengganti, misalnya:

...
hostnames:
- "*.example.com" # Matches all subdomains of example.com
...

Mengalihkan traffic HTTP dari namespace infrastruktur

Dalam beberapa kasus, tidak ada perbedaan yang jelas antara tim admin infrastruktur atau platform dan tim aplikasi, sehingga mencegah penyalahgunaan Gateway terkadang memang tidak mudah.

Contoh berikut lebih lanjut membatasi penggunaan pemroses HTTP untuk mencegah penggunaan protokol yang tidak aman secara tidak sengaja dari tim aplikasi. Contoh ini mengonfigurasi Gateway untuk mengizinkan HTTPRoute menggunakan pemroses HTTP hanya jika rute berada dalam namespace yang memiliki label otherInfra: httpToHttps. Namun, Gateway mengizinkan HTTPRoute di namespace mana pun untuk menggunakan pemroses HTTPS. Anda dapat membatasi namespace http-redirect menggunakan Kubernetes RBAC sehingga tim aplikasi tidak dapat membuat HTTPRoute di namespace ini secara tidak sengaja.

1. Buat namespace Gateway. Simpan manifes sebagai gateway-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Terapkan manifes:

   kubectl apply -f gateway-namespace.yaml
   

3. Buat namespace Gateway dan simpan manifes sebagai redirect-namespace.yaml:

   apiVersion: v1
   kind: Namespace
   metadata:
     name: http-redirect
     labels:
       otherInfra: httpToHttps
   

   Namespace http-redirect ini memiliki label otherInfra: httpToHttps.

4. Terapkan manifes:

   kubectl apply -f redirect-namespace.yaml
   

5. Untuk membatasi penggunaan pemroses http, buat Gateway menggunakan manifes berikut. Simpan manifes sebagai external-gateway.yaml:

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     # Name of an existing GatewayClass.
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       #  Allow only HTTPRoutes from namespaces that have the
       # `otherInfra: httpToHttps` label to use this listener.
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: Selector
           selector:
             matchLabels:
               otherInfra: httpToHttps
     - name: https
       protocol: HTTPS
       port: 443
       # Allow HTTPRoutes from any namespace to use this listener.
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   • Kolom namespace menentukan bahwa Gateway dibuat di namespace gateway-infra.

   • Kolom namespaces di bagian allowedRoutes membatasi pemroses http ke namespace yang cocok dengan label otherInfra: httpToHttps.

6. Terapkan manifes:

   kubectl apply -f external-gateway.yaml
   

7. Untuk memaksa pengalihan HTTPS, buat HTTPRoute default menggunakan manifes berikut. Simpan manifes sebagai http-redirect.yaml:

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1
   metadata:
     name: redirect
     # Create the HTTPRoute in the `http-redirect` namespace.
     namespace: http-redirect
   spec:
     # Attach the HTTPRoute to the `http` listener in the `external-http`
     # Gateway.
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     # Respond to the request with an HTTPS redirection.
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Kolom sectionName menginstruksikan Gateway untuk hanya mencocokkan pemroses http. Filter RequestRedirect memaksa pengalihan ke pemroses https.

8. Terapkan manifes:

   kubectl apply -f http-redirect.yaml
   

9. Buat Layanan untuk aplikasi menggunakan manifes berikut. Simpan manifes sebagai service-deployment.yaml:

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: store
         version: v1
     template:
       metadata:
         labels:
           app: store
           version: v1
       spec:
         containers:
         - name: whereami
           image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
           ports:
           - containerPort: 8080
           env:
           - name: METADATA
             value: "store-v1"
   

10. Terapkan manifes:

    kubectl apply -f service-deployment.yaml
    

11. Buat HTTPRoute untuk aplikasi yang hanya mengizinkan HTTPS menggunakan manifes berikut. Simpan manifes sebagai http-route.yaml:

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1
    metadata:
      name: store-external
      labels:
        gateway: external-http
    spec:
      # Attach the HTTPRoute to the HTTPS listener in the `external-http`
      # Gateway.
      parentRefs:
      - name: external-http
        namespace: gateway-infra
        sectionName: https
      # Match requests that have the `store.example.com` Host header.
      hostnames:
      - "store.example.com"
      # Route requests to the `store-v1` Service.
      rules:
      - backendRefs:
        - name: store-v1
          port: 8080
    

12. Terapkan manifes:

    kubectl apply -f http-route.yaml
    

Mengonfigurasi pengalihan jalur dan penulisan ulang URL

Pengalihan jalur melibatkan pengalihan permintaan masuk dari satu jalur URL ke jalur URL lainnya. Pengalihan jalur memungkinkan Anda mengubah struktur URL saat Anda perlu menangani URL yang sudah tidak berlaku atau tidak digunakan lagi.

Penulisan ulang URL membantu mengubah URL yang masuk sebelum memprosesnya di server. Penulisan ulang URL memungkinkan Anda mengubah struktur atau format URL tanpa benar-benar mengubah konten atau struktur file yang mendasarinya. Penulisan ulang URL berguna untuk membuat URL yang mudah digunakan dan ramah SEO, yang mudah diingat dan dipahami. Secara default, pengalihan jalur dan penulisan ulang URL tidak dikonfigurasi, Anda harus mengonfigurasi pengalihan atau penulisan ulang tersebut secara eksplisit menggunakan filter di HTTPRoute.

GKE Gateway mendukung pengalihan jalur dan penulisan ulang URL. Untuk mengetahui informasi selengkapnya, silakan melihat Pengalihan dan penulisan ulang jalur HTTP.

Mengonfigurasi pengalihan jalur

Anda dapat mengonfigurasi pengalihan jalur untuk mengganti seluruh jalur atau hanya awalan di URL.

Mengganti seluruh jalur

1. Untuk mengganti seluruh jalur, konfigurasikan filter di HTTPRoute yang menggantikan URL apa pun yang berisi awalan /any-path di jalur URL dengan nilai ketat /new-path.

2. Buat manifes HTTPRoute sebagai berikut dan beri nama store.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: store
     spec:
       parentRefs:
       - kind: Gateway
         name: external-http
       hostnames:
       - store.example.com
       rules:
       - matches:
         - path:
             # Match requests by a prefix, like `/any-path` and `/any-path/home`.
             type: PathPrefix
             value: /any-path
         filters:
         - type: RequestRedirect
           requestRedirect:
             path:
               # Replace the full path with `/new-path`. For example, both
               # `/any-path/home` and `/any-path` become `/new-path`.
               type: ReplaceFullPath
               replaceFullPath: /new-path
             statusCode: 302
   

   Misalnya, manifes ini menetapkan aturan pemilihan rute untuk HTTPRoute sebagai berikut: Semua rute ke URL https://store.example.com/any-path/... harus dialihkan ke lokasi baru, https://store.example.com/new-path/ (ketat).

3. Terapkan manifes:

   kubectl apply -f store.yaml
   

Aturan pemilihan rute ini mengikuti aturan pengalihan yang ketat, yang berarti bahwa browser tidak berupaya meng-cache pengalihan, tetapi mengalihkan ke versi terbaru.

Hanya mengganti awalan

1. Untuk mengganti awalan saja, konfigurasikan filter di HTTPRoute yang akan menggantikan URL apa pun yang berisi awalan /any-prefix di jalur URL dengan nilai ketat /new-prefix.

2. Buat manifes HTTPRoute sebagai berikut dan beri nama store.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: store
   spec:
     parentRefs:
       - kind: Gateway
         name: external-http
     hostnames:
     - store.example.com
     rules:
     - matches:
         - path:
             # Match requests by prefix, like `/any-prefix` and
             # `/any-prefix/home`.
             type: PathPrefix
             value: /any-prefix
       filters:
       - type: RequestRedirect
         requestRedirect:
           path:
             # Replace the matched prefix with `/new-prefix`. For example,
             # `/any-prefix` becomes `/new-prefix` and `/any-prefix/home`
             # becomes `/new-prefix/home`.
             type: ReplacePrefixMatch
             replacePrefixMatch: /new-prefix
           statusCode: 302
   

   Misalnya, manifes ini menetapkan aturan pemilihan rute untuk HTTPRoute sebagai berikut: Semua rute ke URL https://store.example.com/any-path/v1/... harus dialihkan ke lokasi baru, https://store.example.com/new-path/v1/... (saja).

3. Terapkan manifes:

     kubectl apply -f store.yaml
   

Aturan pemilihan rute ini mengikuti satu-satunya aturan pengalihan, yang membantu memastikan bahwa browser selalu mengalihkan Anda ke halaman yang sama yang dimaksud.

Mengonfigurasi penulisan ulang URL

Tetapkan penulisan ulang URL untuk mengubah cara URL ditampilkan kepada pengguna. Anda dapat menggunakan penulisan ulang URL untuk membuat URL lebih mudah digunakan, meningkatkan SEO, atau mengalihkan pengguna ke halaman baru.

Menulis ulang seluruh nama host

Untuk menulis ulang seluruh nama host:

1. Konfigurasikan filter di HTTPRoute yang menginstruksikan Gateway untuk mengganti informasi Host di header permintaan dari www.example.com ke store.example.com sebelum meneruskan permintaan tersebut ke layanan backend.

2. Buat manifes HTTPRoute sebagai berikut dan beri nama www.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - filters:
         - type: URLRewrite
           # Replace the hostname in the URL with `store.example.com`.
           urlRewrite:
             hostname: store.example.com
         backendRefs:
         - name: store-v1
           port: 8080
   

   Misalnya, dengan konfigurasi di atas, permintaan apa pun ke https://www.example.com akan diteruskan ke layanan backend dengan header Host: store.example.com, bukannya Host: www.example.com.

3. Terapkan manifes:

     kubectl apply -f www.yaml
   

Menulis ulang menggunakan pengubah jalur

Anda dapat menggabungkan penulisan ulang dengan pengubah jalur untuk memberikan URL tingkat lanjut dan modifikasi jalur sebelum meneruskan permintaan ke layanan backend.

Untuk menulis ulang menggunakan pengubah jalur:

1. Konfigurasikan filter di HTTPRoute yang menginstruksikan Gateway untuk mengganti informasi 'Host' di header permintaan dari www.example.comto store.example.com dan mengganti nilai /store dengan / sebelum meneruskan permintaan tersebut ke layanan backend.

2. Buat manifes HTTPRoute sebagai berikut dan beri nama www.yaml:

     apiVersion: gateway.networking.k8s.io/v1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /store
         filters:
         - type: URLRewrite
           # For URLs that have `/store` in the path, replace the hostname with
           # store.example.com and replace the `/store` prefix with `/de`.
           urlRewrite:
             hostname: store.example.com
             path:
               type: ReplacePrefixMatch
               replacePrefixMatch: /de
         backendRefs:
         - name: store-german
           port: 8080
   

   Misalnya, dengan konfigurasi di atas, permintaan apa pun ke https://www.example.com/store/... akan diteruskan ke layanan backend dengan Host: store.example.com di header permintaan (bukan Host: www.example.com) dan /store akan ditulis ulang menjadi /de.

3. Terapkan manifes:

   kubectl apply -f www.yaml
   

Menulis ulang menggunakan ekspresi reguler

Anda dapat menggunakan resource GCPHTTPFilter dengan spec.urlRewrite.regexModifier untuk menulis ulang jalur URL menggunakan ekspresi reguler sebelum meneruskan permintaan ke layanan backend.

Untuk menulis ulang jalur URL menggunakan ekspresi reguler:

1. Simpan manifes berikut sebagai store-regex-rewrite-filter.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPHTTPFilter
   metadata:
     name: store-regex-rewrite-filter
   spec:
     urlRewrite:
       regexModifier:
         pathPattern: /service1/
         pathSubstitution: /service2/
   

   Manifes ini menjelaskan GCPHTTPFilter dengan properti berikut:

   • urlRewrite.regexModifier: mengonfigurasi penulisan ulang jalur URL menggunakan ekspresi reguler.
   • pathPattern: menentukan ekspresi reguler RE2 yang cocok dengan jalur URL permintaan, seperti /service1/([a-zA-Z0-9]+).
   • pathSubstitution: menentukan string pengganti yang menggantikan jalur URL yang cocok, yang dapat mereferensikan grup tangkapan bernomor dari pathPattern, seperti /service2/\1.

2. Terapkan manifes ke cluster:

   kubectl apply -f store-regex-rewrite-filter.yaml
   

3. Simpan manifes berikut sebagai www-regex-rewrite.yaml:

   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: www-regex-rewrite
   spec:
     parentRefs:
     - kind: Gateway
       name: external-http
     hostnames:
     - www.example.com
     rules:
     - matches:
       - path:
           type: PathPrefix
           value: /service1/
       filters:
       - type: ExtensionRef
         extensionRef:
           group: networking.gke.io
           kind: GCPHTTPFilter
           name: store-regex-rewrite-filter
       backendRefs:
       - name: store-v1
         port: 8080
   

   Manifes ini menjelaskan HTTPRoute dengan properti berikut:

   • extensionRef: mereferensikan store-regex-rewrite-filter GCPHTTPFilter yang dibuat pada langkah sebelumnya.
   • backendRefs: meneruskan permintaan yang ditulis ulang ke Layanan store-v1. Misalnya, permintaan ke https://www.example.com/service1/item123 ditulis ulang menjadi /service2/item123 sebelum diteruskan ke layanan backend store-v1.

4. Terapkan manifes ke cluster:

   kubectl apply -f www-regex-rewrite.yaml
   

Verifikasi konfigurasi Anda

Untuk memastikan filter telah diterapkan setelah membuat HTTPRoute dengan filter penulisan ulang URL atau pengalihan jalur, lakukan tindakan berikut:

kubectl get httproute www -o yaml

Outputnya mirip dengan berikut ini:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

kubectl describe httproute

Mengonfigurasi Cross-Origin Resource Sharing (CORS)

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Cross-Origin Resource Sharing (CORS) adalah mekanisme keamanan yang membantu aplikasi web yang berjalan di satu origin (domain) mengakses resource yang dihosting di origin lain dengan aman.

Anda dapat mengonfigurasi kebijakan CORS langsung dalam resource HTTPRoute menggunakan filter CORS. Pendekatan ini memungkinkan load balancer memasukkan header respons CORS yang sesuai dan menangani permintaan preflight CORS (OPTIONS), sehingga meringankan beban layanan backend Anda.

Mengonfigurasi kebijakan CORS

Contoh berikut menunjukkan HTTPRoute yang dikonfigurasi dengan filter CORS yang mengizinkan permintaan lintas origin dari https://www.example.com untuk metode dan header tertentu:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-with-cors
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: my-backend
      port: 8080
    filters:
    - type: CORS
      cors:
        allowOrigins:
        - "https://www.example.com"
        allowMethods:
        - GET
        - POST
        - DELETE
        allowHeaders:
        - "x-request-header-1"
        - "x-request-header-2"
        exposeHeaders:
        - "x-response-header-a"
        - "x-response-header-b"
        allowCredentials: true
        maxAge: 3600

Blok konfigurasi cors mendukung kolom berikut:

• allowOrigins: daftar origin yang diizinkan. Protokol http dan https didukung. Anda dapat menentukan origin ini dalam salah satu format berikut:
  • Asal eksplisit (misalnya, https://www.example.com).
  • Satu karakter pengganti umum (*) untuk mengizinkan semua origin. Jika karakter pengganti ini digunakan, tidak ada origin lain yang dapat ditentukan. Demi alasan keamanan, sebaiknya jangan menggabungkan karakter pengganti umum dengan setelan allowCredentials (untuk informasi selengkapnya, lihat definisi kolom berikut).
  • Pola karakter pengganti (misalnya, https://*.domain.com). Karakter pengganti * harus muncul tepat setelah skema (http:// atau https://) dan harus diikuti dengan titik (misalnya, http://*.domain.com), port (misalnya, https://*:4433), atau menjadi karakter terakhir (misalnya, http://*).
• allowMethods: metode HTTP yang diizinkan untuk permintaan CORS. Mendukung karakter pengganti (*) untuk mengizinkan semua metode. Jika karakter pengganti digunakan, tidak ada metode lain yang dapat ditentukan.
• allowHeaders: header HTTP yang diizinkan untuk dikirim oleh klien. Mendukung karakter pengganti (*) untuk mengizinkan semua header. Jika karakter pengganti digunakan, tidak ada header lain yang dapat ditentukan.
• exposeHeaders: header HTTP yang aman untuk diekspos ke skrip klien. Mendukung karakter pengganti (*) untuk mengekspos semua header.
• allowCredentials: mengontrol apakah browser dapat membagikan respons server untuk permintaan yang dikirim dalam mode kredensial, seperti permintaan yang berisi cookie atau autentikasi HTTP. Defaultnya adalah false. Saat Anda mengonfigurasi setelan ini, pertimbangkan aspek keamanan berikut:
  • Jika Anda menentukan karakter pengganti * sebagai nilai untuk kolom allowMethods, allowHeaders, atau exposeHeaders, browser akan memblokir respons terhadap permintaan mode kredensial. Pemblokiran ini terjadi meskipun nilai kolom allowCredentials ditetapkan ke true karena alasan keamanan.
  • Jika allowOrigins berisi karakter pengganti *, pengontrol GKE Gateway tidak akan menyalin karakter pengganti * secara harfiah dari kolom allowOrigins ke header respons. Akibatnya, browser tidak akan memblokir respons tersebut terhadap permintaan mode kredensial, sehingga situs yang berpotensi berbahaya dapat mengakses data pengguna. Oleh karena itu, kami sangat tidak menyarankan konfigurasi dengan setelan berikut: allowCredentials: true dan allowOrigins dengan karakter pengganti *.
• maxAge: menentukan berapa lama (dalam detik) browser dapat meng-cache respons preflight. Defaultnya adalah 5 detik. Nilai harus 1 atau lebih besar.

Batasan

• Khusus gateway cluster tunggal: CORS tidak didukung untuk gateway multi-cluster.
• Inkompatibilitas dengan RequestRedirect: Anda tidak dapat menggunakan filter CORS dan filter RequestRedirect dalam aturan rute yang sama.
• Batas ekspresi reguler: pengontrol Gateway GKE secara internal merepresentasikan pola karakter pengganti dalam nilai kolom allowOrigins sebagai ekspresi reguler. Ada batasan penggunaan ekspresi reguler, yang memengaruhi GatewayClass sebagai berikut:
  • Untuk GatewayClass gke-l7-global-external-managed, Anda hanya dapat menggunakan satu ekspresi reguler per pemroses Gateway (dibagikan dengan fitur lain). Batasan ini tunduk pada aturan penghitungan ganda, yang berarti menggabungkan pola karakter pengganti dengan pencocokan PathPrefix tidak didukung.
  • Untuk GatewayClass gke-l7-regional-external-managed dan gke-l7-rilb, Anda dapat menggunakan hingga lima ekspresi reguler per nama host (digunakan bersama dengan fitur lain).
  • Karakter pengganti umum (*) tidak mengurangi batas ini.
  • Satu pola karakter pengganti dalam filter CORS dapat dihitung beberapa kali terhadap batas ekspresi reguler. Pengontrol Gateway GKE mengalikan filter CORS dalam aturan HTTPRoute dengan jumlah kecocokan dalam aturan tersebut. Selain itu, kecocokan jenis PathPrefix dihitung dua kali kecuali jalurnya adalah /.

Untuk mengetahui informasi selengkapnya tentang perilaku CORS standar di Gateway API, lihat Panduan Pengguna CORS upstream.

Mengonfigurasi header permintaan dan header respons kustom

Header header respons dan permintaan kustom memungkinkan Anda menentukan header tambahan untuk permintaan dan respons HTTP(S). Bergantung pada informasi yang dideteksi oleh load balancer, header ini dapat menyertakan informasi berikut:

• Latensi ke klien
• Lokasi geografis alamat IP klien
• Parameter koneksi TLS

Secara default, tidak ada header kustom yang ditambahkan ke permintaan yang dikirim/diterima ke/dari layanan backend Anda. Anda harus mengonfigurasi header kustom secara eksplisit menggunakan filter di HTTPRoute.

Anda dapat mengonfigurasi header kustom dengan menambahkan bagian filter di aturan HTTPRoute sebagai berikut:

Mengonfigurasi header permintaan kustom

Buat manifes HTTPRoute dengan filter RequestHeaderModifier dan simpan sebagai http-route-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Terapkan manifes:

  kubectl apply -f http-route-request.yaml

Mengonfigurasi header respons kustom

Buat manifes HTTPRoute dengan filter ResponseHeaderModifier dan simpan sebagai http-route-response.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Terapkan manifes:

  kubectl apply -f http-route-response.yaml

Catatan: GKE Gateway Controller menerapkan header kustom di peta URL, bukan di layanan backend.

Anda dapat menambahkan, menetapkan, dan menghapus header seperti yang dijelaskan dalam implementasi Gateway API. Anda dapat mengonfigurasi HTTPRoute dengan header kustom menggunakan Google Cloud variabel yang didukung.

Contoh 1:

Untuk mengonfigurasi HTTPRoute yang menambahkan informasi lokasi klien ke permintaan HTTP sebelum mengirimkannya ke layanan backend, buat manifes HTTPRoute dan beri nama external-http-request.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          # Add custom headers to requests that have `/fr` in the path.
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Misalnya, untuk klien yang berada di Strasbourg, Prancis, Gateway menambahkan header sebagai X-Client-Geo-Location:FR,Strasbourg.

Contoh 2:

Untuk mengonfigurasi HTTPRoute yang menambahkan header respons kustom untuk mendukung HTTP Strict Transport Security, buat manifes HTTPRoute dan beri nama external-http-response.yaml:

  apiVersion: gateway.networking.k8s.io/v1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          # Add custom headers to responses to requests that have `/de` in the
          # path.
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Memverifikasi konfigurasi Anda

1. Untuk memverifikasi konfigurasi setelah mengonfigurasi header respons dan permintaan kustom, lakukan tindakan berikut:

     kubectl get httproute
   

   Outputnya mirip dengan berikut ini:

     NAME    HOSTNAMES               AGE
     store   ["store.example.com"]   4d23h
   

2. Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

     kubectl describe httproute
   

   Outputnya mirip dengan hal berikut ini:

     Name:         store
     Namespace:    default
     Labels:       <none>
     Annotations:  <none>
     API Version:  gateway.networking.k8s.io/v1
     Kind:         HTTPRoute
     Metadata:
       Creation Timestamp:  2023-05-27T00:51:01Z
       Generation:          5
       Resource Version:    25418887
       UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
     Spec:
       Hostnames:
         store.example.com
       Parent Refs:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
       Rules:
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v1
           Port:    8080
           Weight:  1
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v2
           Port:    8080
           Weight:  1
         Matches:
           Headers:
             Name:   env
             Type:   Exact
             Value:  canary
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-german
           Port:    8080
           Weight:  1
         Filters:
           Request Header Modifier:
             Add:
               Name:   X-Client-Geo-Location
               Value:  {client_region},{client_city}
           Type:       RequestHeaderModifier
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /de
     Status:
       <...>
   

Mengonfigurasi pencocokan ekspresi reguler

GKE Gateway mendukung pencocokan ekspresi reguler untuk jalur, parameter kueri, dan header HTTPRoute. Anda dapat menggunakan ekspresi reguler untuk menentukan aturan pemilihan rute yang fleksibel.

Pencocokan ekspresi reguler didukung di GatewayClass berikut:

• gke-l7-global-external-managed
• gke-l7-global-external-managed-mc
• gke-l7-regional-external-managed
• gke-l7-regional-external-managed-mc
• gke-l7-rilb
• gke-l7-rilb-mc
• gke-l7-cross-regional-internal-managed-mc

Batasan

• Sintaksis RE2: hanya sintaksis RE2 yang didukung. RE2 tidak mendukung lookahead, lookbehind, atau referensi balik.
• Kuota dan batas:
  • Pencocokan ekspresi reguler maksimum: Anda dapat mengonfigurasi hingga lima pencocokan ekspresi reguler per pencocok jalur (HTTPRoute).
  • Panjang maksimum: panjang maksimum ekspresi reguler adalah 250 karakter.
• Dampak performa: pencocokan ekspresi reguler memerlukan komputasi yang mahal. Menggunakan pencocok ekspresi reguler dapat meningkatkan latensi permintaan:
  • Satu pencocok ekspresi reguler: peningkatan latensi sekitar 100 mikrodetik per permintaan.
  • Lima pencocok ekspresi reguler: peningkatan latensi sekitar 200 mikrodetik per permintaan.

Mengonfigurasi pencocokan ekspresi reguler jalur

Untuk mengonfigurasi pencocokan jalur menggunakan ekspresi reguler, di aturan pencocokan path, tetapkan nilai kolom type ke RegularExpression.

Contoh berikut merutekan permintaan, dengan jalur yang cocok dengan ekspresi reguler /videos/hd.* (misalnya, /videos/hd-123 atau /videos/hd-promo.mp4), ke layanan store-videos-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-path-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: /videos/hd.*
    backendRefs:
    - name: store-videos-hd
      port: 8080

Mengonfigurasi pencocokan ekspresi reguler parameter kueri

Untuk mencocokkan parameter kueri menggunakan ekspresi reguler, di aturan pencocokan queryParams, tetapkan nilai kolom type ke RegularExpression.

Contoh berikut merutekan permintaan, dengan parameter kueri param1 yang cocok dengan ekspresi reguler .*param_value.*-hd, ke layanan android-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-query-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - queryParams:
      - name: param1
        type: RegularExpression
        value: .*param_value.*-hd
    backendRefs:
    - name: android-hd
      port: 8080

Mengonfigurasi pencocokan ekspresi reguler header

Untuk mencocokkan header HTTP menggunakan ekspresi reguler, di aturan pencocokan headers, tetapkan nilai kolom type ke RegularExpression.

Contoh berikut merutekan permintaan, dengan header User-Agent yang cocok dengan ekspresi reguler .*Android.*-hd, ke layanan android-hd:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: store-header-regex
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - name: User-Agent
        type: RegularExpression
        value: .*Android.*-hd
    backendRefs:
    - name: android-hd
      port: 8080

Mengonfigurasi mTLS frontend

Untuk mengaktifkan autentikasi sertifikat klien, Load Balancer Aplikasi Google menyediakan mTLS frontend. Untuk Gateway GKE, mTLS frontend memungkinkan Anda mengonfigurasi dan menerapkan validasi sertifikat klien ke semua resource GatewayClass yang didukung, baik global maupun regional. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi mTLS frontend untuk Gateway.

Mengonfigurasi TLS backend

TLS yang diautentikasi backend adalah fitur keamanan yang memungkinkan load balancer GKE Gateway memverifikasi identitas backend yang terhubung dengannya. Untuk Gateway GKE, fungsi ini memungkinkan Anda mengonfigurasi dan menerapkan validasi sertifikat backend ke GatewayClass yang didukung, seperti load balancer terkelola eksternal global atau regional dan load balancer internal regional.

Untuk mengetahui informasi selengkapnya, silakan melihat Mengamankan Gateway.

Agar Gateway juga mengautentikasi identitasnya sendiri ke backend Anda (mutual TLS), Anda harus menggunakan sertifikat klien pada resource Gateway. Untuk mengetahui petunjuknya, lihat Mengonfigurasi mutual TLS (mTLS) backend untuk Gateway.

Status rute

Resource HTTPRoute memunculkan kondisi dan peristiwa untuk membantu pengguna memahami apakah HTTPRoute telah berhasil terikat ke satu atau beberapa Gateway, atau apakah HTTPRoute ditolak.

Kondisi HTTPRoute

Kondisi HTTPRoute menunjukkan status Rute dan Gateway termpatnya terikat. Karena suatu Rute dapat diikat ke beberapa Gateway, maka ini merupakan daftar Gateway dan kondisi individual antara Rute dan setiap Gateway.

• Accepted=True menunjukkan bahwa HTTPRoute berhasil dikaitkan ke Gateway.
• Accepted=False menunjukkan bahwa proses pengaitan HTTPRoute dengan Gateway ini telah ditolak.

Jika tidak ada Gateway yang tercantum di judul Gateway bindings, label HTTPRoute dan pemilih label Gateway Anda mungkin tidak cocok. Hal ini dapat terjadi jika Rute Anda tidak dipilih oleh Gateway mana pun.

Peristiwa HTTPRoute

Peristiwa HTTPRoute memberikan detail tentang status HTTPRoute. Peristiwa dikelompokkan berdasarkan alasan berikut:

• Peristiwa ADD dipicu oleh penambahan resource.
• Peristiwa UPDATE dipicu oleh resource yang diupdate.
• Peristiwa SYNC dipicu oleh rekonsiliasi berkala.

Penggabungan, prioritas, dan validasi rute

Prioritas rute

Gateway API menetapkan aturan prioritas yang ketat terkait cara traffic dicocokkan dengan Rute yang memiliki aturan pemilihan rute yang tumpang tindih. Prioritas antara dua HTTPRoute yang tumpang tindih adalah sebagai berikut:

1. Penggabungan nama host: Kecocokan nama host paling panjang/spesifik.
2. Penggabungan jalur: Kecocokan jalur paling panjang/spesifik.
3. Penggabungan header: Jumlah header HTTP terbesar yang cocok.
4. Konflik: Jika tiga aturan sebelumnya tidak menetapkan prioritas, prioritas akan diberikan pada resource HTTPRoute dengan stempel waktu terlama.

Penggabungan rute

Untuk GatewayClass gke-l7, semua HTTPRoute untuk Gateway tertentu digabungkan ke dalam resource peta URL yang sama. Cara HTTPRoute digabungkan bergantung pada jenis tumpang tindih antara HTTPRoute. HTTPRoute dari contoh sebelumnya dapat dibagi menjadi tiga HTTPRoute yang terpisah untuk menggambarkan penggabungan dan prioritas rute:

1. Penggabungan rute: Ketiga HTTPRoute dilampirkan ke Gateway internal-http yang sama, sehingga digabungkan bersama.
2. Penggabungan nama host: Ketiga Rute cocok dengan store.example.com, sehingga aturan nama host-nya digabungkan.
3. Penggabungan jalur: store-german-route memiliki jalur yang lebih spesifik, /de, sehingga tidak digabungkan lebih lanjut. store-v1-route dan store-v2-route cocok dengan jalur /* yang sama, sehingga digabungkan di jalur tersebut.
4. Penggabungan header: store-v2-route memiliki kumpulan kecocokan header HTTP yang lebih spesifik daripada store-v1-route, sehingga tidak digabungkan lebih lanjut.
5. Konflik: Karena Rute dapat digabungkan pada nama host, jalur, dan header, tidak ada konflik, dan semua aturan pemilihan rute diterapkan ke traffic.

HTTPRoute tunggal yang digunakan dalam contoh sebelumnya setara dengan tiga rute terpisah berikut:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Gateway Kubernetes dan Gateway Istio

Perlu diperhatikan bahwa Kubernetes Gateway API dan Istio API memiliki resource bernama Gateway. Meskipun menjalankan fungsi yang serupa, keduanya bukanlah resource yang sama. Jika Anda menggunakan Istio dan Gateway API di cluster Kubernetes yang sama, nama-nama ini akan tumpang-tindih saat menggunakan kubectl di command line. kubectl get gateway mungkin menampilkan resource Gateway Kubernetes dan bukan resource Gateway Istio, atau sebaliknya.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Jika Anda menggunakan Istio dan mengupgrade ke GKE 1.20 dan yang lebih baru, sebaiknya mulai gunakan nama singkat resource Gateway atau tentukan grup API. Nama pendek untuk Gateway Kubernetes adalah gtw dan nama pendek untuk Gateway Istio adalah gw. Perintah berikut masing-masing menampilkan resource Gateway Kubernetes dan Gateway Istio.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Pemecahan masalah

Subnet khusus proxy tidak ada di region

Gejala:

Masalah berikut mungkin terjadi saat Anda membuat Gateway regional (internal atau eksternal):

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Alasan:

Pesan error ini menunjukkan bahwa tidak ada subnet khusus proxy di region untuk Gateway Anda.

Solusi:

Untuk mengatasi masalah ini, konfigurasikan subnet khusus proxy.

Subnet khusus proxy sudah ada di region dengan tujuan yang salah

Gejala:

Masalah berikut mungkin terjadi saat Anda membuat subnet khusus proxy untuk Gateway regional (internal atau eksternal):

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Alasan:

Pesan error ini menunjukkan bahwa Anda mencoba membuat subnet khusus proxy regional di region yang sudah memiliki subnet khusus proxy.

Solusi:

Untuk mengatasi masalah ini, lakukan langkah-langkah berikut:

1. Pastikan subnet khusus proxy sudah ada di region dan pastikan subnet tersebut memiliki tujuan yang benar:

   1. Cantumkan subnet Anda untuk menemukan subnet khusus proxy di region tersebut:

      gcloud compute networks subnets list --regions=COMPUTE_REGION
      

      Ganti COMPUTE_REGION dengan region Compute Engine tempat Anda ingin membuat Gateway regional.

   2. Deskripsikan subnet khusus proxy Anda di region tersebut untuk menemukan tujuannya:

      gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
          --region COMPUTE_REGION | grep -E 'name|purpose'
      

      Ganti PROXY_ONLY_SUBNET dengan subnet khusus proxy.

   Gateway GKE hanya mendukung subnet khusus proxy REGIONAL_MANAGED_PROXY untuk Gateway regional (internal atau regional).

2. Jika subnet khusus proxy yang ada di region dibuat dengan tujuan INTERNAL_HTTPS_LOAD_BALANCER, migrasikan tujuannya ke REGIONAL_MANAGED_PROXY.

Tidak ada upstream yang responsif

Gejala:

Masalah berikut mungkin terjadi saat Anda membuat Gateway, tetapi tidak dapat mengakses layanan backend (kode respons 503):

no healthy upstream

Alasan:

Pesan error ini menunjukkan bahwa pemeriksaan health check tidak dapat menemukan layanan backend yang responsif. Layanan backend Anda mungkin responsif, tetapi Anda mungkin perlu menyesuaikan health check.

Solusi:

Untuk mengatasi masalah ini, sesuaikan health check Anda berdasarkan persyaratan aplikasi Anda (misalnya, /health) menggunakan HealthCheckPolicy.

Resource Gateway tanpa induk setelah penghapusan cluster

Gejala:

Saat mencoba membuat ulang Gateway, resource load balancer yang dikelola GKE masih tetap terlihat di konsol Google Cloud , tetapi tidak dapat dihapus menggunakan UI, yang menampilkan pesan yang mirip dengan berikut ini:

This load balancing service is read-only. It is managed by GKE and can be modified only by GKE.

Alasan:

Masalah ini terjadi saat pengontrol Gateway gagal membersihkan resource Google Cloud yang mendasarinya dan sudah tidak berlaku selama penghapusan dan pembuatan ulang cluster atau gateway.

Solusi:

Untuk mengatasi masalah ini, hapus resource load balancing yang tidak terpakai menggunakan perintah Google Cloud CLI sebagai berikut:

gcloud compute forwarding-rules delete FORWARDING_RULE_NAME

# For HTTP proxies
gcloud compute target-http-proxies delete PROXY_NAME

# For HTTPS proxies
gcloud compute target-https-proxies delete PROXY_NAME

gcloud compute url-maps delete URL_MAP_NAME

# For global backend services
gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

# For regional backend services
gcloud compute backend-services delete BACKEND_SERVICE_NAME --region=REGION

gcloud compute health-checks delete HEALTH_CHECK_NAME

gcloud compute network-endpoint-groups delete NEG_NAME --zone=ZONE

Ganti kode berikut:

• FORWARDING_RULE_NAME: nama aturan penerusan.
• PROXY_NAME: nama proxy target.
• URL_MAP_NAME: nama peta URL.
• BACKEND_SERVICE_NAME: nama layanan backend.
• HEALTH_CHECK_NAME: nama health check.
• NEG_NAME: nama grup endpoint jaringan.
• REGION: region layanan backend regional.
• ZONE: zona grup endpoint jaringan.

Langkah berikutnya

• Pelajari Pengontrol gateway lebih lanjut.
• Pelajari cara Mengonfigurasi resource Gateway menggunakan Kebijakan.
• Pelajari konfigurasi Gateway lainnya dalam dokumentasi Gateway API.