Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Men-deploy Gateway passthrough TLS

Autopilot Standard

Dokumen ini menunjukkan cara men-deploy resource Gateway Kubernetes yang dikonfigurasi untuk passthrough TLS guna mengaktifkan pemilihan rute berbasis Server Name Indication (SNI) di Google Kubernetes Engine (GKE). Pendekatan ini mempertahankan enkripsi end-to-end dan mutual TLS (mTLS) antara klien dan Pod backend, mendukung protokol berbasis TLS non-HTTP, dan menghemat alamat IP.

Dokumen ini ditujukan untuk Cloud Architect, Spesialis Jaringan, dan Developer yang mendesain, men-deploy, dan mengelola jaringan terenkripsi untuk workload dalam container. Untuk mempelajari lebih lanjut peran umum dan contoh tugas, lihat Peran dan tugas pengguna GKE umum.

Ringkasan

Selain Load Balancer Aplikasi HTTP dan HTTPS Lapisan 7, pengontrol Gateway GKE mendukung Load Balancer Jaringan proxy Lapisan 4 (load balancer proxy TCP) yang dikonfigurasi dengan passthrough TLS.

Dengan passthrough TLS, load balancer tidak menghentikan atau mendekripsi sesi TLS. Sebagai gantinya, saat klien memulai TLS handshake, load balancer akan memeriksa pesan ClientHello yang tidak dienkripsi untuk membaca nama host Server Name Indication (SNI). Berdasarkan nama host SNI ini, load balancer merutekan aliran TCP mentah yang dienkripsi ke Service Kubernetes backend yang sesuai, tempat Pod aplikasi Anda menghentikan TLS secara langsung.

Saat menggunakan passthrough TLS dengan Gateway API, Anda dapat melakukan hal berikut:

Mempertahankan enkripsi end-to-end dan mendukung kepatuhan zero-trust: menjaga traffic dienkripsi sepenuhnya dari klien ke Pod backend tanpa memberikan akses ke kunci pribadi atau data teks biasa kepada load balancer.
Menggunakan autentikasi mutual TLS (mTLS): mengautentikasi klien langsung di lapisan aplikasi backend.
Menghemat alamat IPv4: multipleks beberapa layanan TLS independen di berbagai domain atau subdomain yang berbeda menggunakan satu alamat IP dan port Gateway (seperti 443).
Mendukung protokol berbasis TLS non-HTTP: merutekan traffic terenkripsi untuk workload stateful, database, layanan gRPC kustom, atau protokol eksklusif yang berjalan melalui TLS.

GatewayClass yang Didukung

GatewayClass GKE berikut mendukung pemroses passthrough TLS dan resource TLSRoute:

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

Untuk perbandingan lengkap kemampuan GatewayClass, lihat Kemampuan GatewayClass.

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 memiliki cluster Autopilot atau Standard yang sudah ada dan menjalankan GKE versi 1.35 atau yang lebih baru dengan Gateway API yang diaktifkan. Untuk membuat cluster, lihat Membuat cluster Autopilot. Untuk mengaktifkan Gateway API di cluster yang ada, lihat Mengaktifkan Gateway API di cluster Anda.
Pastikan Anda telah menginstal alat command line OpenSSL. Anda menggunakan alat ini untuk membuat sertifikat TLS yang ditandatangani sendiri untuk aplikasi contoh.

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 men-deploy Gateway passthrough TLS dan resource TLSRoute, perhatikan batasan berikut:

Saat mengonfigurasi setelan protocol: TLS pada pemroses, Anda harus secara eksplisit menetapkan kolom tls.mode ke nilai Passthrough. GKE tidak mendukung mode Terminate default untuk pemroses TLS.
Pada pemroses TLS, jangan tetapkan kolom certificateRefs. Validasi sertifikat klien tingkat gateway (kolom spec.tls.frontendValidation) tidak berlaku untuk pemroses TLS. Untuk menggunakan mTLS, validasi sertifikat klien di backend Anda.
Pemroses TLS hanya dapat berbagi port dengan pemroses TLS lainnya. Anda tidak dapat mengonfigurasi pemroses HTTP atau HTTPS pada port yang sama dengan pemroses TLS.
Di kolom TLSRoute.spec.hostnames, Anda harus menentukan daftar 1 hingga 1.024 nama host SNI (nama host persis atau awalan karakter pengganti, seperti *.example.com). Setiap entri tidak boleh melebihi 253 karakter dan tidak boleh berupa alamat IP.
Di kolom TLSRoute.spec.rules, Anda dapat mengonfigurasi maksimal satu aturan.
Setiap aturan mendukung tepat satu entri backendRef. Backend proxy Lapisan 4 tidak mendukung pemisahan traffic berbobot di beberapa backend.
GatewayClass cluster tunggal hanya mendukung backend Service, dan GatewayClass multi-cluster hanya mendukung backend ServiceImport.
Di kolom TLSRoute.spec.rules.backendRefs, tetapkan kolom port ke port yang dideklarasikan oleh resource Service atau ServiceImport target, bukan ke port container.
Service Kubernetes backend (termasuk Service yang diekspor sebagai ServiceImport) yang direferensikan oleh resource TLSRoute harus menggunakan nilai TCP untuk protokol port-nya.
Anda tidak dapat melampirkan resource BackendTLSPolicy, Identity-Aware Proxy, atau kebijakan keamanan Google Cloud Armor ke backend TLSRoute karena pengontrol menolak konfigurasi jenis ini.
Saat Anda melampirkan resource GCPBackendPolicy ke Service atau ServiceImport yang direferensikan oleh resource TLSRoute, Anda harus menetapkan kolom spec.protocol ke nilai TCP (menghilangkan kolom spec.protocol akan ditetapkan secara default ke nilai HTTP, yang hanya berlaku untuk backend HTTPRoute). Service atau ServiceImport dapat memiliki satu kebijakan HTTP dan satu kebijakan TCP yang dilampirkan secara bersamaan; jika beberapa kebijakan dengan nilai spec.protocol yang sama menargetkan Service atau ServiceImport yang sama, kebijakan terlama akan diprioritaskan dan kebijakan yang lebih baru tidak akan dilampirkan.
Resource GCPBackendPolicy dengan kolom spec.protocol yang ditetapkan ke TCP hanya mendukung kolom berikut di kolom spec.default (saat menargetkan resource ServiceImport, Anda dapat menetapkan tiga kolom terakhir per cluster, zona, atau region di kolom spec.default.scopes):
- timeoutSec
- connectionDraining
- logging.enabled dan logging.sampleRate
- sessionAffinity.type (nilai yang valid adalah CLIENT_IP atau NONE)
- capacityScalerPercent
- balancingMode: CONNECTION
- maxConnectionsPerEndpoint
Anda tidak dapat membuat kebijakan TCP yang menyertakan kolom lain, atau kebijakan HTTP yang menyertakan kolom khusus TCP (balancingMode: CONNECTION dan maxConnectionsPerEndpoint); server Kubernetes API akan menolak kebijakan tersebut saat dibuat. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi resource Gateway menggunakan Kebijakan.
Jika resource HTTPRoute dan TLSRoute merujuk ke Service atau ServiceImport yang sama, melampirkan resource HealthCheckPolicy ke target tersebut akan menggantikan health check default yang terpisah dan menerapkan konfigurasi health check yang sama ke backend kedua rute. Untuk mengonfigurasi health check secara independen (seperti health check HTTP untuk backend HTTPRoute dan health check SSL atau TCP untuk backend TLSRoute), buat Service terpisah untuk setiap rute dan lampirkan resource HealthCheckPolicy ke setiap Service. Kedua Service dapat memilih Pod yang sama.
Fitur Lapisan 7 (seperti penulisan ulang URL, pemilihan rute berbasis jalur, dan transformasi header HTTP) tidak berlaku untuk load balancer proxy TCP Lapisan 4.

Mengonfigurasi subnet khusus proxy

Gateway regional memerlukan subnet khusus proxy (purpose=REGIONAL_MANAGED_PROXY) di setiap region tempat Anda men-deploy-nya. Satu subnet khusus proxy melayani semua load balancer berbasis Envoy regional di region tersebut. Jika region Anda belum memilikinya, lihat Mengonfigurasi subnet khusus proxy.

Sediakan alamat IP statis

Sebelum men-deploy Gateway, cadangkan alamat IP statis regional agar alamat Gateway tidak berubah dan Anda dapat me-resolve nama host contoh ke alamat tersebut. Untuk mengetahui petunjuk cara membuat alamat IP statis, lihat Membuat Gateway HTTP(S) eksternal regional.

Men-deploy Gateway dengan pemroses passthrough TLS

Gateway di bagian ini mengonfigurasi dua pemroses TLS yang menggunakan port 443 yang sama. Setiap pemroses mencocokkan nama host SNI yang berbeda dan meneruskan koneksi dalam mode passthrough ke resource TLSRoute yang terpasang.

Simpan manifes berikut sebagai store-gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-tls
spec:
  gatewayClassName: gke-l7-regional-external-managed
  listeners:
  # Accept TLS connections for store.example.com without decrypting them.
  - name: store
    protocol: TLS
    port: 443
    hostname: "store.example.com"
    tls:
      mode: Passthrough
    allowedRoutes:
      kinds:
      - kind: TLSRoute
  # A second listener on the same port, selected by a different SNI name.
  - name: store-german
    protocol: TLS
    port: 443
    hostname: "store-de.example.com"
    tls:
      mode: Passthrough
    allowedRoutes:
      kinds:
      - kind: TLSRoute
  addresses:
  - type: NamedAddress
    value: IP_ADDRESS_NAME

Ganti IP_ADDRESS_NAME dengan nama alamat IP statis yang Anda cadangkan.

Perhatikan bahwa blok tls tidak memiliki kolom certificateRefs. Dalam mode Passthrough, sertifikat TLS berada di Pod backend, bukan di load balancer.

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

Pastikan Gateway telah diprogram:

kubectl get gateway store-tls

Penyediaan load balancer memerlukan waktu beberapa menit. Outputnya mirip dengan hal berikut ini:

NAME        CLASS                              ADDRESS         PROGRAMMED   AGE
store-tls   gke-l7-regional-external-managed   35.118.32.224   True         53s

Menggunakan Gateway internal

Agar traffic tetap berada di dalam jaringan VPC, ubah nilai kolom gatewayClassName menjadi gke-l7-rilb dan hapus kolom addresses dari manifes Gateway. GKE kemudian membuat Load Balancer Jaringan proxy internal regional dan menetapkan alamat IP internal dari subnet cluster Anda. Langkah-langkah lainnya di halaman ini tidak berubah. Kirim permintaan pengujian Anda dari instance Compute Engine di jaringan VPC yang sama, karena alamat IP internal tidak dapat dijangkau dari internet.

Men-deploy aplikasi TLS contoh

Di bagian ini, Anda akan men-deploy dua Deployment NGINX (store-v1 dan store-german) yang menghentikan TLS di port 8443. Setiap Deployment menyajikan sertifikat TLS yang berbeda dan melaporkan nama host SNI yang diterimanya, sehingga Anda dapat memverifikasi bahwa pemilihan rute terjadi berdasarkan SNI.

Buat kunci pribadi dan sertifikat TLS yang ditandatangani sendiri untuk setiap nama host:

openssl req -x509 -newkey rsa:2048 -nodes -sha256 -days 365 \
    -keyout store.key -out store.crt \
    -subj '/CN=store.example.com' \
    -addext 'subjectAltName=DNS:store.example.com'
openssl req -x509 -newkey rsa:2048 -nodes -sha256 -days 365 \
    -keyout store-de.key -out store-de.crt \
    -subj '/CN=store-de.example.com' \
    -addext 'subjectAltName=DNS:store-de.example.com'

Gunakan sertifikat dari certificate authority Anda dalam produksi. Sertifikat yang ditandatangani sendiri membuat contoh ini mandiri.

Simpan setiap sertifikat dan kunci di Secret Kubernetes dengan menjalankan perintah berikut:

kubectl create secret tls store-cert \
    --cert=store.crt --key=store.key
kubectl create secret tls store-de-cert \
    --cert=store-de.crt --key=store-de.key

Simpan manifes berikut sebagai store-tls-app.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: store-nginx
data:
  default.conf: |
    server {
      listen 8443 ssl;
      ssl_certificate     /etc/nginx/ssl/tls.crt;
      ssl_certificate_key /etc/nginx/ssl/tls.key;
      default_type text/plain;
      # Report which Pod answered and which SNI name it received.
      return 200 "backend: $hostname\nsni: $ssl_server_name\n";
    }
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: store-v1
  template:
    metadata:
      labels:
        app: store-v1
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 8443
        volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d
        - name: cert
          mountPath: /etc/nginx/ssl
          readOnly: true
      volumes:
      - name: config
        configMap:
          name: store-nginx
      - name: cert
        secret:
          secretName: store-cert
---
apiVersion: v1
kind: Service
metadata:
  name: store-v1
spec:
  selector:
    app: store-v1
  ports:
  - port: 443
    targetPort: 8443
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-german
spec:
  replicas: 2
  selector:
    matchLabels:
      app: store-german
  template:
    metadata:
      labels:
        app: store-german
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 8443
        volumeMounts:
        - name: config
          mountPath: /etc/nginx/conf.d
        - name: cert
          mountPath: /etc/nginx/ssl
          readOnly: true
      volumes:
      - name: config
        configMap:
          name: store-nginx
      - name: cert
        secret:
          secretName: store-de-cert
---
apiVersion: v1
kind: Service
metadata:
  name: store-german
spec:
  selector:
    app: store-german
  ports:
  - port: 443
    targetPort: 8443

Layanan tidak memerlukan kolom appProtocol. GKE meneruskan traffic TLSRoute ke backend sebagai TCP, sehingga kolom ini tidak berpengaruh.

Terapkan manifes ke cluster Anda:
```
kubectl apply -f store-tls-app.yaml
```

Verifikasi bahwa Pod sedang berjalan:

kubectl get pods -l 'app in (store-v1,store-german)'

Outputnya mirip dengan hal berikut ini:

NAME                            READY   STATUS    RESTARTS   AGE
store-german-7d9f8c5b47-2xqkd   1/1     Running   0          41s
store-german-7d9f8c5b47-h6tzn   1/1     Running   0          41s
store-v1-6c4b9d8f65-kp8vr       1/1     Running   0          41s
store-v1-6c4b9d8f65-wm2ls       1/1     Running   0          41s

Men-deploy resource TLSRoute untuk pemilihan rute berbasis SNI

Resource TLSRoute terhubung ke pemroses Gateway dan merutekan koneksi yang cocok dengan nama host-nya ke satu layanan backend.

Simpan manifes berikut sebagai store-tls-routes.yaml:

kind: TLSRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: store-tls
    sectionName: store
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 443
---
kind: TLSRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-german
spec:
  parentRefs:
  - kind: Gateway
    name: store-tls
    sectionName: store-german
  hostnames:
  - "store-de.example.com"
  rules:
  - backendRefs:
    - name: store-german
      port: 443

Kolom sectionName memilih pemroses target di Gateway. Kolom port menentukan port Service (443), bukan port container.

Terapkan manifes TLSRoute:
```
kubectl apply -f store-tls-routes.yaml
```

Pastikan pengontrol Gateway menerima rute:

kubectl get tlsroute store -o yaml

Kolom status mirip dengan berikut ini:

status:
  parents:
  - controllerName: networking.gke.io/gateway
    parentRef:
      name: store-tls
      sectionName: store
    conditions:
    - type: ResolvedRefs
      status: "True"
      reason: ResolvedRefs
    - type: Accepted
      status: "True"
      reason: Accepted
    - type: Reconciled
      status: "True"
      reason: ReconciliationSucceeded

Kondisi Reconciled adalah kondisi status khusus GKE yang melaporkan apakah pengontrol Gateway membuat resourceGoogle Cloud yang mendasarinya.

Pastikan pemroses Gateway menerima rute:

kubectl get gateway store-tls -o yaml

Setiap entri di kolom status.listeners mirip dengan berikut ini:

- name: store
  supportedKinds:
  - group: gateway.networking.k8s.io
    kind: TLSRoute
  attachedRoutes: 1
  conditions:
  - type: ResolvedRefs
    status: "True"
    reason: ResolvedRefs
  - type: Accepted
    status: "True"
    reason: Accepted
  - type: Programmed
    status: "True"
    reason: Programmed

Memverifikasi pemilihan rute traffic

GKE melakukan health check pada backend passthrough TLS dengan menyelesaikan TLS handshake dengannya. Pod Anda mungkin memerlukan waktu beberapa menit untuk lulus health check awal.

Ambil alamat IP Gateway:

kubectl get gateway store-tls -o jsonpath='{.status.addresses[0].value}'

Kirim permintaan ke setiap nama host, dengan mengganti GATEWAY_IP dengan alamat IP dari langkah sebelumnya:
```
curl --resolve store.example.com:443:GATEWAY_IP \
    --cacert store.crt https://store.example.com
curl --resolve store-de.example.com:443:GATEWAY_IP \
    --cacert store-de.crt https://store-de.example.com
```
Setiap respons akan menyebutkan Pod yang menjawab dan menggemakan nama host SNI yang mencapainya:
```
backend: store-v1-6c4b9d8f65-kp8vr
sni: store.example.com
backend: store-german-7d9f8c5b47-2xqkd
sni: store-de.example.com
```
Karena setiap permintaan menggunakan file certificate authority yang berbeda dan keduanya berhasil, setiap backend menyajikan sertifikatnya sendiri. Load balancer meneruskan koneksi terenkripsi tanpa menghentikannya.
Pastikan perutean terjadi selama TLS handshake, sebelum klien mengirim permintaan HTTP apa pun:
```
openssl s_client -connect GATEWAY_IP:443 \
    -servername store-de.example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject
```
Output akan menampilkan sertifikat backend store-german:
```
subject=CN=store-de.example.com
```
Mengubah hanya nilai flag -servername akan mengubah sertifikat yang ditampilkan, yang mengonfirmasi bahwa load balancer memilih backend berdasarkan SNI saja.
Kirim permintaan dengan nama host SNI yang tidak cocok dengan pemroses mana pun:
```
curl --resolve other.example.com:443:GATEWAY_IP \
    https://other.example.com
```
Koneksi ditutup karena tidak ada pemroses di port 443 yang cocok dengan nama host SNI other.example.com.

Mengonfigurasi kapasitas koneksi backend

Untuk Service GKE yang direferensikan oleh resource TLSRoute, pengontrol Gateway GKE mengonfigurasi layanan backend TCP menggunakan mode load balancing CONNECTION, dan menetapkan nilai default kolom maxConnectionsPerEndpoint ke 100,000,000 (1e8).

Karena pengontrol Gateway tidak dapat menentukan batas koneksi serentak container secara otomatis, Anda dapat menggunakan resource GCPBackendPolicy untuk mengganti nilai default kolom maxConnectionsPerEndpoint (dari 1 menjadi 1,000,000,000). Untuk menentukan batas koneksi yang optimal untuk Pod backend, evaluasi hal berikut:

Batas software: periksa konfigurasi server atau aplikasi Anda, seperti perintah MaxRequestWorkers Apache, setelan worker_processes * worker_connections NGINX, atribut maxConnections Tomcat, atau batas kumpulan koneksi database.
Pengujian beban: tingkatkan koneksi serentak secara bertahap terhadap Pod yang terisolasi sambil memantau CPU, memori, latensi, dan batas soket atau deskriptor file.

Menerapkan GCPBackendPolicy kustom

Untuk mengganti nilai default kolom maxConnectionsPerEndpoint pada layanan backend TLSRoute, lampirkan resource GCPBackendPolicy dengan kolom spec.protocol ditetapkan ke TCP dan kolom balancingMode ditetapkan ke CONNECTION:

Simpan manifes berikut sebagai backend-policy.yaml:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store-v1-backend-policy
spec:
  protocol: TCP
  default:
    balancingMode: CONNECTION
    maxConnectionsPerEndpoint: 1000
  targetRef:
    group: ""
    kind: Service
    name: store-v1

Terapkan kebijakan:
```
kubectl apply -f backend-policy.yaml
```

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi kebijakan backend, lihat Mengonfigurasi resource Gateway menggunakan Kebijakan.

Mengonfigurasi health check untuk TLS passthrough

Secara default, untuk layanan backend yang terkait dengan resource TLSRoute passthrough TLS, GKE Gateway Controller otomatis menyediakan health check jenis SSL.

Menangani tidak adanya ekstensi SNI dari prober

Saat mengonfigurasi health check untuk backend passthrough TLS, Anda harus memperhitungkan cara Google Cloud pemeriksa health check berinteraksi dengan endpoint TLS.

Jika aplikasi backend Anda memerlukan nama host SNI yang valid untuk menyelesaikan TLS handshake, health check SSL default akan gagal. Untuk mengatasinya, gunakan salah satu pendekatan berikut:

Konfigurasi sertifikat penggantian: konfigurasikan server backend atau Pod Anda untuk menyajikan sertifikat TLS penggantian default saat koneksi TLS tiba tanpa ekstensi SNI.
Gunakan health check TCP dengan HealthCheckPolicy: lampirkan resource HealthCheckPolicy (dengan kolom config.type ditetapkan ke TCP) ke Service Anda untuk memeriksa konektivitas port TCP mentah dan menghindari TLS handshake.

Menerapkan HealthCheckPolicy kustom

Untuk mengonfigurasi parameter health check kustom atau beralih ke health check TCP, gunakan resource HealthCheckPolicy:

Simpan manifes berikut sebagai health-check-policy.yaml:

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: store-health-check
spec:
  default:
    checkIntervalSec: 10
    timeoutSec: 5
    healthyThreshold: 2
    unhealthyThreshold: 3
    config:
      type: TCP
      tcpHealthCheck:
        port: 8443
  targetRef:
    group: ""
    kind: Service
    name: store-service

Terapkan kebijakan:

kubectl apply -f health-check-policy.yaml

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi health check, lihat Mengonfigurasi resource Gateway menggunakan Kebijakan.

Konfigurasi lanjutan

Bagian ini menjelaskan pola perutean lanjutan, konfigurasi multi-tenant, dan deployment multi-cluster yang didukung dengan Gateway passthrough TLS dan resource TLSRoute.

Pencocokan nama host karakter pengganti

Resource TLSRoute mendukung pencocokan awalan karakter pengganti untuk nama host dan mengikuti aturan prioritas deterministik saat beberapa rute cocok dengan traffic masuk yang sama.

Simpan manifes berikut untuk menentukan TLSRoute karakter pengganti:

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: wildcard-tls-route
spec:
  parentRefs:
  - name: store-tls
    sectionName: store
  hostnames:
  - "*.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 443

Aturan prioritas dan resolusi konflik

Jika beberapa resource TLSRoute terpasang ke pemroses Gateway yang sama dan mengklaim nama host yang tumpang-tindih atau identik, pengontrol Gateway GKE akan menyelesaikan konflik menggunakan kekhususan nama host dan aturan stempel waktu pembuatan yang sama seperti rute Gateway lainnya:

Kecocokan nama host persis (seperti store.example.com) lebih diutamakan daripada kecocokan karakter pengganti (seperti *.example.com), dan kecocokan karakter pengganti yang lebih panjang lebih diutamakan daripada kecocokan karakter pengganti yang lebih luas (seperti *.com).
Jika dua atau beberapa resource TLSRoute mendeklarasikan nama host yang sama persis, rute dengan stempel waktu pembuatan terlama (metadata.creationTimestamp) akan diprioritaskan. Jika stempel waktu pembuatan cocok, ID <namespace>/<name> yang lebih kecil secara leksikografis akan memecahkan tie. Gateway Controller tidak menerima rute yang bertentangan, yang melaporkan kondisi Accepted: False dengan alasan Conflicted.

Untuk mengetahui informasi selengkapnya tentang prioritas rute, lihat Penggabungan, prioritas, dan validasi rute.

Pemilihan rute lintas-namespace dengan ReferenceGrant

Dalam lingkungan multi-tenant, tim platform terpusat dapat mengelola Gateway di namespace infrastruktur (seperti gateway-infra), sementara tim aplikasi mengelola resource TLSRoute dan Service di namespace developer (seperti store-ns).

Di pemroses Gateway, izinkan rute dari semua namespace (atau namespace yang dipilih):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-tls-gateway
  namespace: gateway-infra
spec:
  gatewayClassName: gke-l7-regional-external-managed
  listeners:
  - name: tls-passthrough
    protocol: TLS
    port: 443
    tls:
      mode: Passthrough
    allowedRoutes:
      namespaces:
        from: All
      kinds:
      - kind: TLSRoute

Di namespace aplikasi (store-ns), buat resource ReferenceGrant yang mengizinkan Gateway di namespace gateway-infra untuk mereferensikan resource TLSRoute atau Service:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-infra
  namespace: store-ns
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: Gateway
    namespace: gateway-infra
  to:
  - group: ""
    kind: Service

Di namespace aplikasi (store-ns), buat resource TLSRoute yang merujuk ke Gateway bersama:

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: store-tls-route
  namespace: store-ns
spec:
  parentRefs:
  - name: shared-tls-gateway
    namespace: gateway-infra
    sectionName: tls-passthrough
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-service
      port: 443

Gateway passthrough TLS multi-cluster

Anda dapat men-deploy Gateway multi-cluster dengan passthrough TLS di beberapa cluster GKE dalam sebuah fleet:

Gunakan GatewayClass multi-cluster yang didukung (gke-l7-regional-external-managed-mc, gke-l7-rilb-mc, atau gke-l7-cross-regional-internal-managed-mc).
Ekspor layanan backend Anda di seluruh fleet menggunakan resource ServiceExport.

Di resource TLSRoute, referensikan backend multi-cluster menggunakan resource ServiceImport:

apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: mc-store-tls-route
spec:
  parentRefs:
  - name: mc-tls-gateway
    sectionName: tls-passthrough
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-service
      port: 443

Beberapa alamat IP di Gateway multi-cluster

Saat men-deploy Gateway multi-cluster lintas region (seperti saat menggunakan GatewayClass gke-l7-cross-regional-internal-managed-mc), Anda dapat menentukan beberapa alamat IP di kolom spec.addresses untuk mengekspos VIP internal di berbagai region.

Saat Anda mengonfigurasi beberapa alamat IP dalam satu Gateway, pengontrol Gateway GKE akan menerjemahkan setiap alamat IP menjadi aturan penerusan yang terpisah. Pada saat yang sama, pengontrol mereferensikan proxy target bersama dan menggunakan kembali konfigurasi perutean pokok yang sama. Pengontrol tidak mengalikan resource TLSRoute yang mendasarinya dengan jumlah alamat IP, sehingga membantu mencegah duplikasi rute dan kehabisan kuota.

Contoh berikut menunjukkan Gateway multi-cluster yang dikonfigurasi dengan alamat IP sementara di dua region:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: internal-cross-region-tls-gateway
spec:
  gatewayClassName: gke-l7-cross-regional-internal-managed-mc
  addresses:
  - type: networking.gke.io/ephemeral-ipv4-address/us-west1
    value: "us-west1"
  - type: networking.gke.io/ephemeral-ipv4-address/us-east1
    value: "us-east1"
  listeners:
  - name: tls-passthrough
    protocol: TLS
    port: 443
    tls:
      mode: Passthrough
    allowedRoutes:
      kinds:
      - kind: TLSRoute

Untuk mengetahui informasi selengkapnya tentang cara men-deploy Gateway multi-cluster internal, lihat Men-deploy Gateway multi-cluster internal.

Penggabungan koneksi HTTP

Menurut RFC 7540 (Bagian 9.1.1), browser web dan klien HTTP/2 dapat menggunakan kembali koneksi TLS yang telah dibuat untuk beberapa permintaan jika kedua kondisi berikut terpenuhi:

Nama host target di-resolve ke alamat IP yang sama.
Sertifikat TLS yang ditampilkan server bersifat otoritatif untuk kedua nama host. Misalnya, sertifikat dapat mencakup beberapa nama host saat Anda menggunakan sertifikat karakter pengganti seperti *.example.com atau Subject Alternative Name (SAN) multi-domain.

Karena load balancer proxy TCP Lapisan 4 tidak memeriksa header permintaan HTTP setelah TLS handshake awal, load balancer meneruskan permintaan gabungan melalui koneksi yang ada ke Pod backend yang awalnya cocok.

Untuk mencegah masalah penggabungan koneksi:

Gunakan sertifikat TLS yang berbeda dan tidak tumpang-tindih: jangan berbagi sertifikat karakter pengganti atau identitas SAN umum di berbagai layanan backend yang dimultipleks di balik alamat IP Gateway yang sama.
Menampilkan HTTP 421 Misdirected Request: konfigurasikan server HTTPS backend Anda untuk memeriksa header HTTP :authority (atau Host). Jika host yang diminta tidak cocok dengan domain yang diharapkan server, tampilkan kode status HTTP 421 Misdirected Request, yang akan meminta klien untuk membuka koneksi baru.
Aktifkan Frame ORIGIN HTTP/2: terapkan dukungan Frame ORIGIN RFC 8336 di server asal Anda dan nyatakan secara eksplisit nama host mana yang valid untuk penggunaan kembali koneksi.

Pembersihan

Agar akun Google Cloud Anda tidak dikenai biaya untuk resource yang digunakan di halaman ini, hapus resource:

Hapus resource TLSRoute:

kubectl delete tlsroute store store-german

Hapus resource Gateway:
```
kubectl delete gateway store-tls
```

Hapus resource Deployment, Service, dan Secret contoh:

kubectl delete -f store-tls-app.yaml
kubectl delete secret store-cert store-de-cert

Langkah berikutnya

Pelajari kemampuan GatewayClass.
Pelajari keamanan Gateway.
Pelajari cara Mengonfigurasi resource Gateway menggunakan Kebijakan.