Versi 1.20

Versi yang tersedia

1.20 (terbaru)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.12

219}

Halaman ini diterjemahkan oleh Cloud Translation API.

Mengonfigurasi Load Balancer Aplikasi klasik untuk Cloud Service Mesh

Ringkasan

Dokumen ini ditujukan bagi Anda jika Anda adalah pengguna Cloud Service Mesh yang sudah ada dan memiliki bidang kontrol yang dikelola Istiod dan ingin mengonfigurasi Application Load Balancer klasik sebagai gateway masuk. Load Balancer Aplikasi klasik juga dikenal sebagai Load Balancer Aplikasi eksternal klasik.

Jangan gunakan dokumen ini jika Anda adalah pengguna Cloud Service Mesh baru. Pengguna baru akan otomatis disiapkan dengan bidang kontrol terkelola Cloud Service Mesh. Anda tidak dapat menggunakan konfigurasi yang dijelaskan dalam dokumen ini dengan bidang kontrol terkelola Cloud Service Mesh

Cloud Load Balancing menyediakan banyak kemampuan edge terkelola cloud, termasuk load balancing anycast global, sertifikat terkelola Google, Identity and Access Management, Cloud Next Generation Firewall, dan Cloud Intrusion Detection System. Cloud Service Mesh dapat mengintegrasikan kemampuan edge ini dengan lancar dalam model ingress mesh berikut. Gateway cloud mesh layanan menyediakan cara terpadu untuk mengonfigurasi gateway ingress Cloud Service Mesh dengan Cloud Load Balancing secara bersamaan melalui Kubernetes Gateway API.

Diagram yang menunjukkan load balancer dengan Cloud Service Mesh

Dibandingkan dengan panduan pengguna kami sebelumnya, Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui Traffic masuk GKE, dengan gateway cloud mesh layanan, model ini kini dapat di-deploy melalui satu resource Kubernetes Gateway yang menyederhanakan proses deployment load balancing cloud dan yang dihosting cluster secara bersamaan.

Batasan pratinjau

Untuk rilis Pratinjau fitur ini, batasan berikut berlaku:

Gateway multi-cluster tidak didukung.
Cluster Autopilot tidak didukung.
Hanya Load Balancer Aplikasi klasik yang didukung. Load Balancer Aplikasi eksternal global (terkadang disebut Load Balancer Lanjutan) dan Load Balancer Aplikasi internal tidak didukung.
Traffic antara gateway masuk Load Balancer Aplikasi klasik dan Cloud Service Mesh dienkripsi menggunakan TLS. Namun, Load Balancer Aplikasi klasik tidak akan memverifikasi sertifikat yang disediakan oleh gateway masuk Cloud Service Mesh. Batasan ini berlaku untuk semua pengguna Load Balancer HTTP(S) Google Cloud.
Jika Cloud Service Mesh GatewayClasses dihapus dari cluster, GatewayClasses tersebut tidak akan diinstal ulang secara otomatis. Namun, hal ini tidak akan memengaruhi kegunaan fitur.
Logika pencocokan rute tidak mengikuti spesifikasi Gateway API dan cocok dengan urutan HTTPRoute. Hal ini akan berubah pada versi mendatang untuk mengikuti spesifikasi Gateway API.

Persyaratan

Cloud Service Mesh Terkelola yang diinstal di cluster Google Kubernetes Engine (GKE) yang menjalankan 1.24 atau yang lebih baru. Cluster GKE Enterprise lainnya tidak didukung.
Khusus versi Kubernetes Gateway API v1beta1.

Prasyarat

Aktifkan API berikut di project Anda:

compute.googleapis.com
container.googleapis.com
certificatemanager.googleapis.com
serviceusage.googleapis.com

gcloud services enable \
   compute.googleapis.com \
   container.googleapis.com \
   certificatemanager.googleapis.com \
   serviceusage.googleapis.com

Men-deploy gateway cloud mesh layanan untuk mesh cluster tunggal

Bagian ini menunjukkan cara men-deploy resource Kubernetes Gateway yang men-deploy Load Balancer Aplikasi klasik dan gateway ingress Cloud Service Mesh.

Mengaktifkan Gateway API dengan Cloud Service Mesh terkelola

Aktifkan Gateway API di cluster Anda. Cluster GKE harus versi 1.24 atau yang lebih baru.
Instal Cloud Service Mesh terkelola dengan rapid atau regular sebagai saluran rilisnya.

Men-deploy resource Gateway

Saat men-deploy gateway cloud mesh layanan, resource Gateway Kubernetes digunakan untuk men-deploy gateway masuk Cloud Load Balancing dan Cloud Service Mesh sebagai satu langkah. Perhatikan bahwa resource Kubernetes Gateway berbeda dengan resource Istio Gateway.

Untuk mengetahui informasi selengkapnya tentang perbedaannya, lihat Gateway Kubernetes dan Gateway Istio. Setiap Kubernetes Gateway memiliki GatewayClass yang menunjukkan jenis dan kemampuan bawaannya. Service Mesh Cloud Gateway memiliki GatewayClass yang memiliki kemampuan untuk men-deploy Cloud Load Balancing dan Cloud Service Mesh ingress gateway.

Simpan manifes GatewayClass berikut ke file bernama l7-gateway-class.yaml:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: asm-l7-gxlb
spec:
  controllerName: mesh.cloud.google.com/gateway

Deploy GatewayClass di cluster Anda:
```
kubectl apply -f l7-gateway-class.yaml
```
Pastikan GatewayClass ada setelah penginstalan:
```
kubectl get gatewayclasses.gateway.networking.k8s.io
```
Outputnya mirip dengan:
```
NAME          CONTROLLER
asm-l7-gxlb   mesh.cloud.google.com/gateway
gke-l7-rilb   networking.gke.io/gateway
gke-l7-gxlb   networking.gke.io/gateway
```
Mungkin perlu waktu beberapa menit hingga semua resource di-deploy. Jika Anda tidak melihat output yang diharapkan, pastikan Anda telah memenuhi prasyarat dengan benar.

Anda juga akan melihat GatewayClass berikut:
```
gke-l7-gxlb   networking.gke.io/gateway
```
Ini digunakan untuk men-deploy Load Balancer Aplikasi klasik Google Cloud yang mendasarinya.
Buat Namespace khusus untuk gateway cloud mesh layanan Anda:
```
kubectl create namespace istio-ingress
```

Simpan manifes Gateway berikut ke file bernama gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Deploy Gateway di cluster Anda di Namespace istio-ingress:
```
kubectl apply -f gateway.yaml
```

Pastikan objek Kubernetes Gateway API dibuat:

kubectl get gateways.gateway.networking.k8s.io -n istio-ingress

Outputnya mirip dengan:

NAME                                CLASS         ADDRESS         READY   AGE
asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
servicemesh-cloud-gw                asm-l7-gxlb                           9m44s

Hal berikut akan terjadi saat objek Kubernetes Gateway API ini di-deploy:

Load Balancer HTTP(S) eksternal di-deploy dan dikonfigurasi. Mungkin perlu waktu beberapa menit hingga muncul, tetapi saat muncul, Gateway akan menunjukkan alamat IP dan akan dianotasi dengan nama resource load balancer Compute Engine yang dibuat.
Deployment gateway masuk Cloud Service Mesh dibuat di namespace istio-ingress. Tindakan ini akan membuat instance proxy Envoy yang akan menerima traffic dari load balancer.
Load balancer akan mengenkripsi dan merutekan semua traffic ke gateway masuk Cloud Service Mesh.

Sekarang Anda memiliki infrastruktur lengkap yang diperlukan untuk menerima traffic internet ke dalam mesh. Perhatikan bahwa ini adalah deployment Gateway yang paling sederhana. Di bagian berikut, Anda akan menambahkan kebijakan dan kemampuan tambahan yang akan membuatnya siap produksi.

Deployment aplikasi dan pemilihan rute

Untuk sepenuhnya mendemonstrasikan kemampuan, Anda akan men-deploy aplikasi ke Cloud Service Mesh dan menerima traffic internet melalui Gateway untuk tujuan contoh.

Beri label pada Namespace default untuk mengaktifkan injeksi sidecar.

kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite

Simpan manifes Gateway berikut ke file bernama whereami.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v1
  template:
    metadata:
      labels:
        app: whereami-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: "whereami-v1"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v1
spec:
  selector:
    app: whereami-v1
  ports:
  - port: 8080
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whereami-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whereami-v2
  template:
    metadata:
      labels:
        app: whereami-v2
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "whereami-v2"
---
apiVersion: v1
kind: Service
metadata:
  name: whereami-v2
spec:
  selector:
    app: whereami-v2
  ports:
  - port: 8080
    targetPort: 8080

Manifes ini membuat Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1, dan Deployment/whereami-v2 untuk whereami, aplikasi sederhana yang menghasilkan output JSON untuk menunjukkan identitas dan lokasinya. Anda akan men-deploy dua versi yang berbeda.

Buat Layanan dan Deployment:
```
kubectl apply -f whereami.yaml
```
Setelah siap dan berjalan, Anda akan memiliki empat Pod whereami yang berjalan di cluster.

Pastikan keempat Pod sedang berjalan:

kubectl get pods

Outputnya mirip dengan:

whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s

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

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: where-route
spec:
 parentRefs:
 - kind: Gateway
   name: servicemesh-cloud-gw
   namespace: istio-ingress
 hostnames:
 - "where.example.com"
 rules:
 - matches:
   - headers:
     - name: version
       value: v2
   backendRefs:
   - name: whereami-v2
     port: 8080
 - backendRefs:
   - name: whereami-v1
     port: 8080

Deploy http-route.yaml ke cluster Anda:
```
kubectl apply -f http-route.yaml
```
HTTPRoute ini mereferensikan servicemesh-cloud-gw yang berarti bahwa HTTPRoute ini akan mengonfigurasi gateway cloud mesh layanan sehingga mengonfigurasi gateway masuk Cloud Service Mesh yang mendasarinya dengan aturan perutean ini. HTTPRoute menjalankan fungsi yang sama dengan VirtualService Istio, tetapi menggunakan Kubernetes Gateway API untuk melakukannya. Karena Gateway API adalah spesifikasi OSS dengan banyak penerapan yang mendasarinya, API ini adalah API terbaik yang cocok untuk menentukan pemilihan rute di seluruh kombinasi load balancer yang berbeda (seperti proxy dan load balancer Cloud Service Mesh).

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

VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)

Output-nya adalah alamat IP.

echo $VIP

34.111.61.135

Kirim traffic ke alamat IP Gateway untuk memvalidasi bahwa penyiapan ini berfungsi dengan benar. Kirim satu permintaan dengan header version: v2 dan satu permintaan tanpa header untuk menentukan bahwa pemilihan rute dilakukan dengan benar di kedua versi aplikasi.

curl ${VIP} -H "host: where.example.com"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v1",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

curl ${VIP} -H "host: where.example.com" -H "version: v2"

{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "whereami-v2",
  "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
  "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
  "pod_name_emoji": "⚒",
  "project_id": "church-243723",
  "timestamp": "2021-02-08T18:55:01",
  "zone": "us-central1-a"
}

Deployment gateway produksi

Bagian sebelumnya menunjukkan contoh gateway cloud mesh layanan yang sangat sederhana. Langkah-langkah berikut dibuat berdasarkan contoh sederhana untuk menampilkan penyiapan siap produksi yang menunjukkan keunggulan mendelegasikan beberapa fungsi pemilihan rute ingress ke load balancer.

Dalam contoh berikut, Anda akan mengambil servicemesh-cloud-gw dari bagian sebelumnya dan akan menambahkan kemampuan berikut untuk membuat Gateway yang lebih aman dan mudah dikelola:

Deploy Gateway dengan alamat IP statis yang akan dipertahankan meskipun infrastruktur yang mendasarinya berubah.
Konversikan Gateway untuk menerima traffic HTTPS dengan sertifikat yang ditandatangani sendiri.

Buat alamat IP eksternal statis. IP statis berguna karena infrastruktur yang mendasarinya dapat berubah di masa mendatang, tetapi alamat IP dapat dipertahankan.
```
gcloud compute addresses create whereami-ip \
    --global \
    --project PROJECT_ID
```

Buat sertifikat yang ditandatangani sendiri untuk domain where-example-com:

openssl genrsa -out key.pem 2048
cat <<EOF >ca.conf
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = where.example.com
[sans_list]
DNS.1                     = where.example.com
EOF

openssl req -new -key key.pem \
    -out csr.pem \
    -config ca.conf

openssl x509 -req \
    -signkey key.pem \
    -in csr.pem \
    -out cert.pem \
    -extfile ca.conf \
    -extensions extension_requirements \
    -days 365

gcloud compute ssl-certificates create where-example-com \
    --certificate=cert.pem \
    --private-key=key.pem \
    --global \
    --project PROJECT_ID

Ada banyak cara untuk membuat sertifikat TLS. Sertifikat tersebut dapat dibuat secara manual di command line, dibuat menggunakan sertifikat yang dikelola Google, atau dapat dibuat secara internal oleh sistem infrastruktur kunci publik (PKI) perusahaan Anda. Dalam contoh ini, Anda akan membuat sertifikat yang ditandatangani sendiri secara manual. Meskipun sertifikat yang ditandatangani sendiri biasanya tidak digunakan untuk layanan publik, sertifikat ini menunjukkan konsep ini dengan lebih mudah.

Untuk mengetahui informasi selengkapnya tentang cara membuat sertifikat yang ditandatangani sendiri melalui secret Kubernetes, lihat Mengamankan Gateway.

Update gateway.yaml dengan manifes berikut:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: servicemesh-cloud-gw
  namespace: istio-ingress
spec:
  gatewayClassName: asm-l7-gxlb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: All
    tls:
      mode: Terminate
      options:
        networking.gke.io/pre-shared-certs: where-example-com
  addresses:
  - type: NamedAddress
    value: whereami-ip

Deploy ulang Gateway di cluster Anda:
```
kubectl apply -f gateway.yaml
```

Dapatkan alamat IP IP statis:

VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")

Gunakan curl untuk mengakses domain Gateway. Karena DNS tidak dikonfigurasi untuk domain ini, gunakan opsi --resolve untuk memberi tahu curl agar me-resolve nama domain ke alamat IP Gateway:

curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v

Setelah selesai, output-nya akan mirip dengan:

...
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=example; CN=where.example.com
*  start date: Apr 19 15:54:50 2021 GMT
*  expire date: Apr 19 15:54:50 2022 GMT
*  common name: where.example.com (matched)
*  issuer: O=example; CN=where.example.com
*  SSL certificate verify ok.
...
{
  "cluster_name": "gke1",
  "host_header": "where.example.com",
  "metadata": "where-v1",
  "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
  "pod_name": "where-v1-84b47c7f58-tj5mn",
  "pod_name_emoji": "😍",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-04-19T16:30:08",
  "zone": "us-west1-a"
}

Output panjang mencakup TLS handshake yang berhasil, diikuti dengan respons dari aplikasi seperti output berikut. Hal ini membuktikan bahwa TLS dihentikan di Gateway dengan benar dan aplikasi merespons klien dengan aman.

Anda telah berhasil men-deploy arsitektur berikut:

Arsitektur ASM

servicemesh-cloud-gw dan GatewayClass asm-l7-gxlb-nya telah memisahkan beberapa komponen infrastruktur internal untuk menyederhanakan pengalaman pengguna. Cloud Load Balancing menghentikan traffic TLS menggunakan sertifikat internal dan juga melakukan health check pada lapisan proxy gateway traffic masuk Cloud Service Mesh. whereami-route yang di-deploy di Deployment Aplikasi & Pemilihan Rute mengonfigurasi proxy gateway masuk Cloud Service Mesh untuk merutekan traffic ke Layanan yang dihosting mesh yang benar.