Halaman ini diterjemahkan oleh Cloud Translation API.

Men-deploy Gateway

Autopilot Standard

Halaman ini menjelaskan cara men-deploy resource Gateway Kubernetes untuk load balancing traffic masuk ke satu cluster Google Kubernetes Engine (GKE).

Untuk men-deploy Gateway guna melakukan load balancing traffic masuk di beberapa cluster (atau fleet), lihat Men-deploy Gateway Multi-Cluster.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

Aktifkan Google Kubernetes Engine API.

Aktifkan Google Kubernetes Engine API

Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region dan 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.

Persyaratan GKE Gateway Controller

Untuk Standard, GKE versi 1.24 atau yang lebih baru.

Untuk Autopilot, GKE versi 1.26 atau yang lebih baru.
Google Cloud CLI versi 407.0.0 atau yang lebih baru.
Gateway API hanya didukung di cluster native VPC.
Jika menggunakan GatewayClass internal, 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, di project host, Anda harus menetapkan peran Compute Network User ke Akun Layanan GKE untuk project layanan.

Batas dan pembatasan

Saat menggunakan GKE Gateway, pahami batasan dan batasan 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.
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 Rute 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, gke-l7-gxlb GatewayClass tidak didukung.

Saat mengonfigurasi header permintaan dan respons kustom HTTPRoute, variabel Google Cloud berikut tidak didukung:
- cdn_cache_id (Cloud CDN tidak didukung dengan GKE Gateway)
- cdn_cache_status (Cloud CDN tidak didukung dengan GKE Gateway)
- origin_request_header (Kebijakan CORS tidak didukung dengan GKE Gateway)
GKE Gateway tidak mendukung fitur load balancing Cloud CDN.

Header kustom Mutual TLS tidak didukung (mTLS dengan Gateway GKE tidak didukung)
Batasan Load Balancer Aplikasi klasik Google Cloud berlaku untuk Gateway GKE. 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, ekspresi reguler, dan URL dinamis.
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, lihat men-deploy Gateway eksternal regional.
Gateway menggunakan NEG Mandiri untuk menyediakan Grup Endpoint Jaringan. Untuk memastikan pengontrol Gateway merekonsiliasi konfigurasi load balancer dengan benar, Anda tidak dapat mengubah anotasi cloud.google.com/neg untuk Layanan yang merupakan bagian dari Gateway.
GKE Gateway tidak mendukung referensi Layanan yang juga direferensikan oleh GKE Ingress.
Jika Gateway dikonfigurasi untuk menyediakan alamat IP, perubahan Gateway.spec.gatewayClass tidak didukung. Untuk 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 GKE Gateway dengan external-dns dan status kesehatan Gateway tidak baik, 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 Gateway GKE melalui rute, anotasi NEG mandiri di Layanan juga harus mengupdate pengontrol NEG Mandiri di Layanan untuk menghapus port tersebut. Jika tidak, pengontrol NEG pada akhirnya akan berhenti menyinkronkan endpoint Pod untuk Layanan ini. Untuk mengetahui detailnya, lihat Pengontrol NEG berhenti mengelola endpoint saat port dihapus dari Layanan.

Mengaktifkan Gateway API di cluster Anda

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

Membuat cluster baru dengan Gateway API yang diaktifkan

GKE mendukung Gateway API di cluster Autopilot mulai dengan GKE versi 1.26. Jika Anda membuat cluster Autopilot baru di GKE 1.26 atau yang lebih baru, Gateway API akan diaktifkan secara default. Untuk cluster yang ada di GKE versi 1.25 atau yang lebih lama, Gateway API dinonaktifkan secara default.

Jika Anda membuat cluster terlebih dahulu tanpa menentukan jaringan (dengan menggunakan flag --network), GKE akan membuat cluster di jaringan default. Dalam hal ini, Anda juga harus membuat subnet khusus proxy di jaringan default. Jika Anda menentukan jaringan selama pembuatan cluster, pastikan Anda juga membuat subnet khusus proxy di jaringan yang sama.

Autopilot

Buat cluster Autopilot GKE baru dengan Gateway API yang diaktifkan:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Ganti kode berikut:

CLUSTER_NAME: nama cluster.
CLUSTER_LOCATION: region atau zona Compute Engine untuk cluster baru.
RELEASE_CHANNEL: nama saluran rilis.
VERSION: versi GKE, yang harus merupakan versi 1.26 atau yang lebih baru. Anda juga dapat menggunakan flag --release-channel untuk memilih saluran rilis. Saluran rilis harus memiliki versi default 1.26 atau yang lebih baru.

Saat membuat cluster, Anda tidak perlu menggunakan flag gcloud flag --gateway-api=standard.

Standar

Dengan GKE Standard, Gateway API dikontrol oleh flag --gateway-api. Anda dapat menggunakan standar nilai saat mengaktifkan dan nonaktif saat menonaktifkan.

Buat cluster GKE native VPC baru dengan Gateway API yang diaktifkan:

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Ganti kode berikut:

RELEASE_CHANNEL: nama saluran rilis.
CLUSTER_NAME: nama cluster.
VERSION: versi GKE, yang harus merupakan versi 1.24 atau yang lebih baru. Anda juga dapat menggunakan flag --release-channel untuk memilih saluran rilis. Saluran rilis harus memiliki versi default 1.24 atau yang lebih baru.
CLUSTER_LOCATION: region atau zona Compute Engine untuk cluster baru.

Flag --gateway-api=standard memerintahkan GKE untuk menginstal CRD v1beta1 dengan cluster.

Mengaktifkan Gateway API di cluster yang ada

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

Pastikan versi cluster Autopilot Anda adalah 1.26 atau yang lebih baru dan versi cluster Standard Anda adalah 1.24 atau yang lebih baru. Untuk mempelajari lebih lanjut cara mengupgrade versi cluster Standar, lihat Upgrade cluster standar. Untuk mempelajari lebih lanjut cara mengupgrade versi cluster Autopilot, lihat Upgrade cluster Autopilot.

Untuk mengaktifkan Gateway API di cluster GKE yang ada (Autopilot atau Standard), gunakan perintah berikut. Saat mengaktifkan Gateway di cluster yang ada, mungkin perlu waktu hingga 45 menit agar cluster dapat merekonsiliasi dan menginstal CRD.

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 memerintahkan GKE untuk menginstal CRD v1beta1 dengan cluster.

Memverifikasi cluster

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.

Pastikan Gateway API diaktifkan di panel kontrol GKE:

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

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

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

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. Untuk menginstal dan menggunakan GatewayClass multi-cluster untuk load balancing multi-cluster internal dan eksternal, lihat 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.

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
```
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 IP utama subnet. Anda harus menggunakan subnet mask dengan ukuran maksimal /26 agar ada minimal 64 alamat IP yang tersedia untuk proxy di region tersebut. Subnet mask yang direkomendasikan adalah /23.

Pastikan subnet khusus proxy Anda:

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

Outputnya mirip dengan berikut ini:

...
gatewayAddress: 10.1.1.1
ipCidrRange: 10.1.1.0/24
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
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 lihat 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.

Simpan manifes Gateway berikut ke file bernama gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-http
spec:
  gatewayClassName: gke-l7-rilb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
```
Manifes ini mencakup kolom berikut:
- gatewayClassName: gke-l7-rilb: menentukan GatewayClass yang menjadi sumber Gateway ini. gke-l7-rilb sesuai dengan Load Balancer Aplikasi internal.
- port: 80: menentukan bahwa Gateway hanya mengekspos port 80 untuk memproses traffic HTTP.
Deploy Gateway di cluster Anda:
```
kubectl apply -f gateway.yaml
```

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 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:  1970-01-01T00:00:00Z
    Message:               Waiting for controller
    Reason:                NotReconciled
    Status:                False
    Type:                  Scheduled
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

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 diarahkan ke backend default, yang menampilkan HTTP 404. Selanjutnya, Anda men-deploy aplikasi dan Rute, yang memberi tahu Gateway cara membuka 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 didedikasikan untuk aplikasi mereka. Lihat Pemikatan rute untuk 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.

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 Layanan yang bernama store-v1, store-v2, dan store-german.

Validasi bahwa aplikasi telah berhasil di-deploy:

kubectl get pod

Outputnya 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

Validasi bahwa Layanan 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.

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

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

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.

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/v1beta1
Kind:         HTTPRoute
<...>
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",
  <...>

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, Rute, dan aplikasi di-deploy di cluster, Anda dapat meneruskan traffic ke aplikasi.

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.

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

Buat permintaan ke store.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 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"
}
```

Uji kecocokan jalur dengan membuka layanan toko 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 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"
}

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

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

Output 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 VPC Anda. Deployment ini mirip dengan deployment Gateway internal, kecuali 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 global menggunakan alamat IP Global (atau alamat IP Anycast) sebagai frontend Gateway yang diiklankan di semua region Google Cloud Compute. Klien yang mengirim traffic ke alamat IP Anycast ini akan dirutekan ke lokasi Google terdekat tempat IP tersebut diiklankan. Gateway eksternal global hanya tersedia di Network Service Tiers Premium.

Gateway eksternal regional menggunakan IP Regional sebagai frontend Gateway yang hanya diiklankan di region Google Cloud Compute lokal tempat Gateway eksternal regional di-deploy. Klien yang mengirim traffic ke alamat IP regional ini akan dirutekan oleh ISP lokal mereka dan melalui Internet sebelum mencapai region Google tempat IP tersebut diiklankan. Gateway eksternal regional hanya tersedia di Network Service Tiers Standard.

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.

Membuat 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 Kubernetes Secrets 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.

Aktifkan Certificate Manager API:

gcloud services enable certificatemanager.googleapis.com

Buat peta sertifikat:

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

Muat sertifikat dan kunci yang dikelola Google ke Sertifikat:
```
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 baru yang Anda pilih. File harus memiliki ekstensi .pem. Misalnya, cert.pem.
- PRIVATE_KEY_FILE: nama file kunci pribadi Anda.
Untuk mengetahui informasi selengkapnya, silakan melihat Membuat kunci pribadi dan sertifikat.

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

Untuk mempelajari resource Gateway lebih lanjut, lihat 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.

Simpan manifes berikut ke file bernama gateway.yaml:
```
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  annotations:
    networking.gke.io/certmap: store-example-com-map
spec:
  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 peta sertifikat di Pengelola Sertifikat.
Tidak ada bagian TLS karena TLS dikonfigurasi dengan Certificate Manager menggunakan anotasi networking.gke.io/certmap.
Terapkan manifes ke cluster Anda:
```
kubectl apply -f gateway.yaml
```
Mungkin perlu waktu beberapa menit hingga GKE men-deploy resource.
Pastikan bahwa 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 diarahkan ke backend default, yang menampilkan respons HTTP 404. Di bagian berikutnya, Anda akan men-deploy Rute, yang menginstruksikan Gateway untuk mengirim traffic ke backend.

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 didedikasikan untuk aplikasi mereka. Lihat Penautan 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.

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.

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

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

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

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

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

Manifes ini menjelaskan HTTPRoute yang mereferensikan Gateway external-http.

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.

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/v1beta1
Kind:         HTTPRoute
<...>
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:
    Conditions:
      Last Transition Time:  2022-11-01T05:42:31Z
      Message:
      Reason:                Accepted
      Status:                True
      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",
  ...

Pastikan HTTPRoute terikat ke Gateway:

kubectl describe gateway external-http

Outputnya mirip dengan berikut ini:

Name:         external-http
Namespace:    default
Labels:       <none>
<...>
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
      <...>

Mengirim traffic ke aplikasi Anda

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

Dapatkan alamat IP Gateway:

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

Output-nya adalah alamat IP.

Buat VM:
```
gcloud cloud-shell ssh
```

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.

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

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

Kirim traffic ke versi canary Layanan store menggunakan header HTTP env: canary:

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

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

CertificateMap atau sertifikat SSL yang dikelola Google tidak didukung dengan Gateway regional. Gunakan secret atau sertifikat SSL regional yang dikelola sendiri untuk mengamankan traffic antara klien dan Gateway regional Anda. Untuk mengetahui informasi selengkapnya tentang Load balancer Google Cloud dan Sertifikat, silakan melihat Load balancer Google Cloud dan Sertifikat

Membuat Gateway HTTP(S) eksternal regional

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 baru.
- COMPUTE_REGION: Region Compute Engine tempat cluster Anda berjalan.

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/v1beta1
  metadata:
    name: external-regional-http
  spec:
    gatewayClassName: gke-l7-regional-external-managed
    listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
        - name: store-example-com
    addresses:
    - type: NamedAddress
      value: IP_ADDRESS_NAME

Terapkan manifes regional-gateway:

  kubectl apply -f regional-gateway.yaml

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 terpisah dari deployment Gateway.

Untuk informasi selengkapnya tentang cara men-deploy aplikasi demo, lihat 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, lihat 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 ke 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.

Deploy aplikasi sampel:

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

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: site-internal
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "site.example.com"
  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.

Terapkan manifes ke cluster Anda:

kubectl apply -f site-route-internal.yaml

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.

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.

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

Outputnya mirip dengan 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"
}

Mengonfigurasi backend default Gateway

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

Gateway dikonfigurasi untuk menangani kode error seperti 404 (Tidak Ditemukan) dan 500 (Error Server), 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/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-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 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 subnet berikut:

GatewayClass	Pul IP Default
gke-l7-rilb gke-l7-rilb-mc	Alamat IP pribadi regional dari rentang alamat IPv4/IPv6 node utama
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Alamat IP publik regional dari rentang IPv4/IPv6 eksternal regional Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Alamat IP publik global dari rentang IPv4/IPv6 eksternal global Google

Kolom addresses.NamedAddress memungkinkan Anda menentukan alamat IP secara terpisah 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 IPv6 dengan menentukan NamedAddress. Anda harus menyediakan alamat IP statis sebelum membuat Gateway.

Buat resource alamat IP statis:
```
gcloud compute addresses create IP_ADDRESS_NAME \
    --purpose=SHARED_LOADBALANCER_VIP \
    --region=COMPUTE_REGION \
    --subnet=SUBNET \
    --project=PROJECT_ID
```
Ganti kode berikut:
- IP_ADDRESS_NAME: nama alamat IP statis baru
- COMPUTE_REGION: untuk Gateway regional, region Compute Engine tempat cluster Anda berjalan. Flag ini tidak diperlukan untuk Gateway eksternal global.
- SUBNET: subnet untuk alamat IP. Flag ini tidak diperlukan untuk Gateway eksternal global.
- PROJECT_ID: project tempat cluster GKE Anda berjalan.

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

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
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 disebutkan.

Terapkan manifes ke cluster Anda:
```
kubectl apply -f named-ip-gateway.yaml
```

Verifikasi alamat IP Gateway Anda:

kubectl describe gateway internal-http

Outputnya mirip dengan 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 pengalihan HTTP-ke-HTTPS

Cloud Load Balancing menawarkan fungsi pengalihan HTTP ke HTTPS. Load Balancer Aplikasi eksternal mengalihkan 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 cara untuk 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.

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 tertentu (pengalihan http) saat Gateway tersebut membuka pemroses HTTPS untuk semua namespace. Anda dapat membatasi namespace http-redirect menggunakan Kubernetes RBAC sehingga tim aplikasi tidak dapat membuat HTTPRoute di namespace ini secara tidak sengaja.

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

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

Terapkan manifes:

kubectl apply -f gateway-namespace.yaml

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

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

Label tertentu ditetapkan untuk namespace ini.

Terapkan manifes:

kubectl apply -f redirect-namespace.yaml

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

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
      namespaces:
        from: selector
        selector:
          matchLabels:
            otherInfra: httpToHttps
  - name: https
    protocol: HTTPS
    port: 443
    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.

Terapkan manifes:
```
kubectl apply -f external-gateway.yaml
```

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: redirect
  namespace: http-redirect
spec:
  parentRefs:
  - namespace: gateway-infra
    name: external-http
    sectionName: http
  rules:
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https

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

Terapkan manifes:
```
kubectl apply -f http-redirect.yaml
```

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.2.20
        ports:
        - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"

Terapkan manifes:

kubectl apply -f service-deployment.yaml

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-external
  labels:
    gateway: external-http
spec:
  parentRefs:
  - name: external-http
    namespace: gateway-infra
    sectionName: https
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Terapkan manifes:
```
kubectl apply -f http-route.yaml
```

Mengonfigurasi pengalihan jalur dan penulisan ulang URL

Pengalihan jalur mencakup pengalihan permintaan masuk dari satu jalur URL ke jalur URL lainnya. Pengalihan jalur memungkinkan Anda mengubah struktur URL saat perlu menangani URL yang sudah tidak digunakan 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

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.

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

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
    - matches:
      - path:
          type: PathPrefix
          value: /any-path
      filters:
      - type: RequestRedirect
        requestRedirect:
          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).

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

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.

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

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  parentRefs:
    - kind: Gateway
      name: external-http
  hostnames:
  - store.example.com
  rules:
  - matches:
      - path:
          type: PathPrefix
          value: /any-prefix
    filters:
    - type: RequestRedirect
      requestRedirect:
        path:
          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).

Terapkan manifes:
```
  kubectl apply -f store.yaml
```

Aturan pemilihan rute ini mengikuti satu-satunya aturan pengalihan, yang 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:

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.

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

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: www
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - www.example.com
    rules:
    - filters:
      - type: URLRewrite
        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, bukan Host: www.example.com.

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:

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.

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

  apiVersion: gateway.networking.k8s.io/v1beta1
  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
        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 ditulis ulang menjadi /de.

Terapkan manifes:
```
kubectl apply -f www.yaml
```

Memverifikasi 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/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","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 header permintaan dan respons kustom

Header header respons dan permintaan kustom memungkinkan Anda menentukan header tambahan untuk permintaan dan respons HTTP(S). Bergantung pada informasi yang terdeteksi 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 dalam 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/v1beta1
  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/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Terapkan manifes:

  kubectl apply -f http-route-response.yaml

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

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/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          - 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 akan menambahkan header sebagai X-Client-Geo-Location:FR,Strasbourg.

Contoh 2:

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

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Memverifikasi konfigurasi Anda

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

Untuk mendapatkan detail selengkapnya, gunakan perintah describe:

  kubectl describe httproute

Outputnya mirip dengan berikut ini:

  Name:         store
  Namespace:    default
  Labels:       <none>
  Annotations:  <none>
  API Version:  gateway.networking.k8s.io/v1beta1
  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:
    <...>

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 bagian 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 resource yang ditambahkan.
Peristiwa UPDATE dipicu oleh resource yang diperbarui.
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:

Penggabungan nama host: Kecocokan nama host paling panjang/spesifik.
Penggabungan jalur: Kecocokan jalur paling panjang/spesifik.
Penggabungan header: Jumlah terbesar header HTTP yang cocok.
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:

Penggabungan rute: Ketiga HTTPRoute dilampirkan ke Gateway internal-http yang sama, sehingga digabungkan bersama.
Penggabungan nama host: Ketiga Rute cocok dengan store.example.com, sehingga aturan nama host-nya digabungkan.
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.
Penggabungan header: store-v2-route memiliki kumpulan kecocokan header HTTP yang lebih spesifik daripada store-v1-route, sehingga tidak digabungkan lebih lanjut.
Konflik: Karena Rute dapat digabungkan pada nama host, jalur, dan header, tidak ada konflik, dan semua aturan pemilihan rute diterapkan ke traffic.

Satu HTTPRoute yang digunakan dalam contoh sebelumnya setara dengan tiga rute terpisah ini:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
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/v1beta1
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/v1beta1
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

Perhatikan bahwa Kubernetes Gateway API dan Istio API memiliki resource bernama Gateway. Meskipun melakukan fungsi yang serupa, keduanya bukan resource yang sama. Jika Anda menggunakan Istio dan Gateway API di cluster Kubernetes yang sama, 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, gunakan langkah-langkah berikut:

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:
```
gcloud compute networks subnets list --regions=COMPUTE_REGION
```
  Ganti COMPUTE_REGION dengan region Compute Engine tempat Anda ingin membuat Gateway regional.
2. Jelaskan subnet khusus proxy Anda di region 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.
GKE Gateway hanya mendukung subnet khusus proxy REGIONAL_MANAGED_PROXY untuk Gateway regional (internal atau regional).
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 sehat

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 pemeriksa health check tidak dapat menemukan layanan backend yang berfungsi. Mungkin layanan backend Anda dalam kondisi baik, tetapi Anda mungkin perlu menyesuaikan health check.

Solusi:

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

Langkah selanjutnya

Pelajari Pengontrol gateway lebih lanjut.
Pelajari cara Mengonfigurasi resource Gateway menggunakan Kebijakan.