Cloud Service Mesh dan Traffic Director kini bergabung menjadi Cloud Service Mesh. Untuk mengetahui informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Halaman ini diterjemahkan oleh Cloud Translation API.

Update konfigurasi untuk modernisasi

Dokumen ini menjelaskan pembaruan konfigurasi yang mungkin perlu Anda lakukan pada Cloud Service Mesh terkelola sebelum memodernisasi mesh ke bidang kontrol TRAFFIC_DIRECTOR dari bidang kontrol ISTIOD.

Berikut adalah daftar kemungkinan update konfigurasi yang diperlukan untuk menyiapkan cluster Anda untuk modernisasi. Lihat setiap bagian untuk mengetahui petunjuk update:

Multi-cluster
Mengaktifkan Workload Identity Federation untuk GKE
Mengaktifkan CNI terkelola
Penggunaan Biner Non-Standar di Sidecar
Bermigrasi ke Istio Ingress Gateway

Untuk informasi selengkapnya tentang alur kerja modernisasi, lihat halaman Modernisasi 'managed control plane'.

Bermigrasi dari secret Istio ke multicluster_mode

Secret multi-cluster tidak didukung saat cluster menggunakan bidang kontrol TRAFFIC_DIRECTOR. Dokumen ini menjelaskan cara Anda dapat melakukan modernisasi dari menggunakan secret multi-cluster Istio menjadi menggunakan multicluster_mode.

Ringkasan rahasia Istio versus API deklaratif

Penemuan endpoint multi-cluster istio open source berfungsi dengan menggunakan istioctl atau alat lain untuk membuat Secret Kubernetes di cluster. Secret ini memungkinkan cluster melakukan load balancing traffic ke cluster lain dalam mesh. Control plane ISTIOD kemudian membaca secret ini dan mulai merutekan traffic ke cluster lain tersebut.

Cloud Service Mesh memiliki API deklaratif untuk mengontrol traffic multi-cluster, bukan membuat secret Istio secara langsung. API ini memperlakukan secret Istio sebagai detail implementasi dan lebih andal daripada membuat secret Istio secara manual. Fitur Cloud Service Mesh mendatang akan bergantung pada API deklaratif, dan Anda tidak akan dapat menggunakan fitur baru tersebut dengan secret Istio secara langsung. API deklaratif adalah satu-satunya jalur yang didukung ke depan.

Jika Anda menggunakan Istio Secrets, bermigrasilah untuk menggunakan API deklaratif sesegera mungkin. Perhatikan bahwa setelan multicluster_mode mengarahkan setiap cluster untuk mengarahkan traffic ke setiap cluster lain dalam mesh. Penggunaan secret memungkinkan konfigurasi yang lebih fleksibel, sehingga Anda dapat mengonfigurasi untuk setiap cluster ke cluster lain yang akan mengarahkan traffic di mesh. Untuk mengetahui daftar lengkap perbedaan antara fitur yang didukung dari API deklaratif dan secret Istio, lihat Fitur yang didukung menggunakan API Istio.

Bermigrasi dari secret Istio ke API deklaratif

Jika Anda menyediakan Cloud Service Mesh menggunakan pengelolaan otomatis dengan fleet feature API, Anda tidak perlu mengikuti petunjuk ini. Langkah-langkah ini hanya berlaku jika Anda melakukan aktivasi menggunakan asmcli --managed.

Perhatikan bahwa proses ini mengubah secret yang mengarah ke cluster. Selama proses ini, endpoint dihapus, lalu ditambahkan kembali. Di antara endpoint yang dihapus dan ditambahkan, traffic akan kembali ke perutean secara lokal untuk sementara, bukan load balancing ke cluster lain. Untuk mengetahui informasi selengkapnya, lihat masalah GitHub.

Untuk beralih dari menggunakan secret Istio ke API deklaratif, ikuti langkah-langkah berikut. Jalankan langkah-langkah ini secara bersamaan atau secara berurutan:

Aktifkan API deklaratif untuk setiap cluster dalam fleet tempat Anda ingin mengaktifkan penemuan endpoint multi-cluster dengan menetapkan multicluster_mode=connected. Perhatikan bahwa Anda harus menetapkan multicluster_mode=disconnected secara eksplisit jika tidak ingin cluster dapat ditemukan.

Gunakan perintah berikut untuk memilih ikut serta dalam cluster untuk penemuan endpoint multi cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Gunakan perintah berikut untuk memilih tidak ikut penemuan endpoint di cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Menghapus secret lama.

Setelah menetapkan multicluster_mode=connected di cluster, setiap cluster akan memiliki secret baru yang dibuat untuk setiap cluster lain yang juga telah menetapkan multicluster_mode=connected. Secret ditempatkan di namespace istio-system dan memiliki format berikut:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Setiap secret juga akan menerapkan label istio.io/owned-by: mesh.googleapis.com.

Setelah secret baru dibuat, Anda dapat menghapus secret apa pun yang dibuat secara manual dengan istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Setelah dimigrasikan, periksa metrik permintaan Anda untuk memastikannya dirutekan seperti yang diharapkan.

Mengaktifkan Workload Identity Federation untuk GKE

Workload Identity Federation adalah metode aman yang direkomendasikan untuk workload Google Kubernetes Engine. Hal ini memungkinkan akses ke Google Cloud layanan seperti Compute Engine, BigQuery, dan Machine Learning API. Workload Identity Federation tidak memerlukan konfigurasi manual atau metode yang kurang aman seperti file kunci akun layanan karena menggunakan kebijakan IAM. Untuk mengetahui detail selengkapnya tentang Workload Identity Federation, lihat Cara kerja Workload Identity Federation untuk GKE.

Bagian berikut menjelaskan cara mengaktifkan Workload Identity Federation.

Mengaktifkan Workload Identity Federation di cluster

Pastikan Workload Identity Federation diaktifkan untuk cluster Anda. Untuk melakukannya, pastikan cluster GKE memiliki set Workload Identity Federation yang telah dikonfigurasi, yang penting untuk validasi kredensial IAM.

Gunakan perintah berikut untuk memeriksa workload identity pool yang ditetapkan untuk cluster:
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
Ganti CLUSTER_NAME dengan nama cluster GKE Anda. Jika belum menentukan zona atau region default untuk gcloud, Anda mungkin juga perlu menentukan flag --region atau --zone saat menjalankan perintah ini.
Jika output kosong, ikuti petunjuk di Memperbarui cluster yang ada untuk mengaktifkan workload identity di cluster GKE yang ada.

Mengaktifkan Workload Identity Federation di node pool

Setelah Workload Identity Federation diaktifkan di cluster, node pool harus dikonfigurasi untuk menggunakan server metadata GKE.

Cantumkan semua node pool cluster Standar. Jalankan perintah gcloud container node-pools list:
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
Ganti CLUSTER_NAME dengan nama cluster GKE Anda. Jika belum menentukan zona atau region default untuk gcloud, Anda mungkin juga perlu menentukan flag --region atau --zone saat menjalankan perintah ini.
Pastikan setiap node pool menggunakan server metadata GKE:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Ganti kode berikut:
- NODEPOOL_NAME dengan nama nodepool Anda.
- CLUSTER_NAME dengan nama cluster GKE Anda.
Jika output tidak berisi GKE_METADATA, perbarui node pool menggunakan panduan Memperbarui node pool yang ada.

Mengaktifkan antarmuka jaringan penampung (CNI) terkelola

Bagian ini memandu Anda mengaktifkan CNI terkelola untuk Cloud Service Mesh di Google Kubernetes Engine.

Ringkasan CNI terkelola

Antarmuka jaringan container terkelola (CNI) adalah implementasi CNI Istio yang dikelola Google. Plugin CNI menyederhanakan jaringan pod dengan mengonfigurasi aturan iptables. Hal ini memungkinkan pengalihan traffic antara aplikasi dan proxy Envoy, sehingga tidak memerlukan izin dengan hak istimewa untuk init-container yang diperlukan untuk mengelola iptables.

Plugin CNI Istio mengganti penampung istio-init. Container istio-init sebelumnya bertanggung jawab untuk menyiapkan lingkungan jaringan pod guna mengaktifkan intersepsi traffic untuk sidecar Istio. Plugin CNI menjalankan fungsi pengalihan jaringan yang sama, tetapi dengan manfaat tambahan untuk mengurangi kebutuhan akan hak istimewa yang ditingkatkan, sehingga meningkatkan keamanan.

Oleh karena itu, untuk meningkatkan keamanan dan keandalan, serta menyederhanakan pengelolaan dan pemecahan masalah, CNI terkelola diperlukan di semua deployment Cloud Service Mesh Terkelola.

Dampak pada container init

Container init adalah container khusus yang berjalan sebelum container aplikasi untuk tugas penyiapan. Tugas penyiapan dapat mencakup tugas seperti mendownload file konfigurasi, berkomunikasi dengan layanan eksternal, atau melakukan inisialisasi pra-aplikasi. Penampung init yang mengandalkan akses jaringan mungkin mengalami masalah saat CNI terkelola diaktifkan di cluster.

Proses penyiapan pod dengan CNI terkelola adalah sebagai berikut:

Plugin CNI menyiapkan antarmuka jaringan pod, menetapkan IP pod, dan mengalihkan traffic ke proxy sidecar Istio yang belum dimulai.
Semua penampung init dijalankan dan selesai.
Proxy sidecar Istio dimulai bersama dengan container aplikasi.

Oleh karena itu, jika penampung init mencoba membuat koneksi jaringan keluar atau terhubung ke layanan dalam mesh, permintaan jaringan dari penampung init dapat dihapus atau salah dirutekan. Hal ini karena proxy sidecar Istio, yang mengelola traffic jaringan untuk pod, tidak berjalan saat permintaan dibuat. Untuk detail selengkapnya, lihat dokumentasi CNI Istio.

Mengaktifkan CNI terkelola untuk cluster Anda

Ikuti langkah-langkah di bagian ini untuk mengaktifkan CNI terkelola di cluster Anda.

Hapus dependensi jaringan dari penampung init Anda. Pertimbangkan alternatif berikut:
- Mengubah logika atau penampung aplikasi: Anda dapat mengubah layanan untuk menghapus dependensi pada penampung init yang memerlukan permintaan jaringan atau melakukan operasi jaringan dalam penampung aplikasi, setelah proxy sidecar dimulai.
- Gunakan ConfigMap atau secret Kubernetes: Simpan data konfigurasi yang diambil oleh permintaan jaringan di ConfigMap atau secret Kubernetes dan pasang ke dalam penampung aplikasi Anda. Untuk solusi alternatif, lihat dokumentasi Istio.
Aktifkan CNI terkelola di cluster Anda:
1. Lakukan perubahan konfigurasi berikut:
  1. Jalankan perintah berikut untuk menemukan controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. Di resource kustom (CR) ControlPlaneRevision (CPR), tetapkan label mesh.cloud.google.com/managed-cni-enabled ke true.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    Ganti CPR_NAME dengan nilai di kolom NAME dari output langkah sebelumnya.
  3. Di ConfigMap asm-options, tetapkan nilai ASM_OPTS ke CNI=on.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. Di resource kustom (CR) ControlPlaneRevision (CPR), tetapkan label mesh.cloud.google.com/force-reprovision ke true. Tindakan ini memicu dimulai ulangnya bidang kontrol.
    
    Catatan: Metode ini bukan metode yang direkomendasikan untuk memulai ulang bidang kontrol, dan hanya boleh digunakan untuk upaya modernisasi Cloud Service Mesh.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. Periksa status fitur. Ambil status fitur menggunakan perintah berikut:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  Ganti FLEET_PROJECT_ID dengan ID project Host Flotte Anda. Umumnya, FLEET_PROJECT_ID memiliki nama yang sama dengan project.
  - Verifikasi bahwa kondisi MANAGED_CNI_NOT_ENABLED dihapus dari servicemesh.conditions.
  - Perhatikan bahwa mungkin perlu waktu hingga 15-20 menit agar status diperbarui. Coba tunggu beberapa menit, lalu jalankan kembali perintah.
3. Setelah controlPlaneManagement.state menjadi Active dalam status fitur cluster, mulai ulang pod.

Beralih dari Penggunaan Biner Non-Standar di Sidecar

Bagian ini menyarankan cara agar deployment Anda kompatibel dengan image proxy envoy distroless.

Gambar sidecar proxy envoy tanpa distro

Cloud Service Mesh menggunakan dua jenis image sidecar proxy Envoy berdasarkan konfigurasi bidang kontrol, image berbasis Ubuntu yang berisi berbagai biner dan image Distroless. Image dasar tanpa distro adalah image container minimal yang memprioritaskan pengoptimalan keamanan dan resource dengan hanya menyertakan komponen penting. Permukaan serangan dikurangi untuk membantu mencegah kerentanan. Untuk informasi selengkapnya, lihat dokumentasi tentang Image proxy Distroless.

Kompatibilitas biner

Sebagai praktik terbaik, Anda harus membatasi konten runtime penampung hanya ke paket yang diperlukan. Pendekatan ini meningkatkan keamanan dan rasio sinyal-derau pemindai Common Vulnerabilities and Exposures (CVE). Image Sidecar Distroless memiliki kumpulan dependensi minimal, yang dihapus dari semua file yang dapat dieksekusi, library, dan alat proses debug yang tidak penting. Oleh karena itu, Anda tidak dapat menjalankan perintah shell atau menggunakan curl, ping, atau utilitas debug lainnya seperti kubectl exec di dalam penampung.

Membuat cluster kompatibel dengan image distroless

Hapus referensi ke biner yang tidak didukung (seperti bash atau curl) dari konfigurasi Anda. Khususnya di dalam pemeriksaan Kesiapan, Startup, dan Keaktifan, serta hook PostStart dan PreStop Siklus Proses dalam penampung istio-proxy, istio-init, atau istio-validation.
Pertimbangkan alternatif seperti holdApplicationUntilProxyStarts untuk kasus penggunaan tertentu.
Untuk proses debug, Anda dapat menggunakan container sementara untuk dilampirkan ke Pod workload yang sedang berjalan. Kemudian, Anda dapat memeriksanya dan menjalankan perintah kustom. Misalnya, lihat Mengumpulkan log Cloud Service Mesh.

Jika Anda tidak dapat menemukan solusi untuk kasus penggunaan tertentu, hubungi Google Cloud Dukungan di Mendapatkan dukungan.

Bermigrasi ke Gateway Masuk Istio

Bagian ini menunjukkan cara bermigrasi ke Istio Ingress Gateway. Ada dua metode untuk bermigrasi ke Istio Ingress Gateway:

Migrasi Bertahap dengan Pemisahan Traffic

Metode ini memprioritaskan pengurangan gangguan dengan mengirim traffic secara bertahap ke gateway Istio baru, sehingga Anda dapat memantau performanya pada sebagian kecil permintaan dan dengan cepat kembali ke gateway lama jika diperlukan. Perlu diingat bahwa mengonfigurasi pemisahan traffic Lapisan 7 dapat menjadi tantangan untuk beberapa aplikasi, sehingga Anda perlu mengelola kedua sistem gateway secara serentak selama transisi. Lihat Migrasi Bertahap dengan pemisahan traffic untuk mengetahui langkah-langkahnya.
Migrasi Langsung

Metode ini melibatkan pengalihan ulang semua traffic secara bersamaan ke gateway Istio baru setelah Anda melakukan pengujian secara menyeluruh. Keuntungan pendekatan ini adalah pemisahan total dari infrastruktur gateway lama, yang memungkinkan konfigurasi gateway baru yang dapat disesuaikan tanpa batasan penyiapan yang ada. Namun, ada peningkatan risiko periode nonaktif jika gateway baru mengalami masalah yang tidak terduga selama transisi. Lihat Migrasi Langsung untuk mengetahui langkah-langkahnya.

Contoh migrasi berikut mengasumsikan bahwa Anda memiliki layanan HTTP (httpbin) yang berjalan di namespace aplikasi (default) dan diekspos secara eksternal menggunakan Kubernetes Gateway API. Konfigurasi yang relevan adalah:

Gateway: k8-api-gateway (di namespace istio-ingress) - dikonfigurasi untuk memproses traffic HTTP di port 80 untuk nama host apa pun yang diakhiri dengan .example.com.
HTTPRoute: httpbin-route (dalam namespace default) - mengarahkan permintaan HTTP apa pun dengan nama host httpbin.example.com dan jalur yang dimulai dengan /get ke layanan httpbin dalam namespace default.
Aplikasi httpbin dapat diakses menggunakan IP eksternal 34.57.246.68.

Diagram gateway dasar

Migrasi Bertahap dengan pemisahan traffic

Menyediakan Istio Ingress Gateway baru

Deploy Ingress Gateway baru dengan mengikuti langkah-langkah di Deploy sample gateway section dan sesuaikan konfigurasi contoh dengan persyaratan Anda. Contoh dalam repositori anthos-service-mesh dimaksudkan untuk men-deploy layanan loadBalancer istio-ingressgateway dan pod ingress-gateway yang sesuai.

Contoh Resource Gateway (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

Terapkan konfigurasi Gateway untuk mengelola traffic:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Pastikan 'spec.selector' di resource Gateway Anda cocok dengan label pod ingress-gateway Anda. Misalnya, jika pod ingress-gateway memiliki label istio=ingressgateway, konfigurasi Gateway Anda juga harus memilih label istio=ingressgateway ini.

Mengonfigurasi pemilihan rute awal untuk Gateway baru

Tentukan aturan perutean awal untuk aplikasi Anda menggunakan VirtualService Istio.

Contoh VirtualService (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

Terapkan VirtualService:

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Mengakses layanan backend (httpbin) melalui Istio Ingress Gateway yang baru di-deploy

Tetapkan variabel lingkungan Host Ingress ke alamat IP eksternal yang terkait dengan load balancer istio-ingressgateway yang baru di-deploy:

export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Pastikan aplikasi (httpbin) dapat diakses menggunakan gateway baru:
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
Outputnya mirip dengan:
```
HTTP/1.1 200 OK
```

Alur permintaan dengan gateway ingress istio baru

Mengubah Ingress yang ada untuk pemisahan traffic

Setelah mengonfirmasi keberhasilan penyiapan gateway baru (misalnya, istio-api-gateway), Anda dapat mulai merutekan sebagian traffic melalui gateway tersebut. Untuk melakukannya, update HTTPRoute saat ini untuk mengarahkan sebagian kecil traffic ke gateway baru, sementara bagian yang lebih besar terus menggunakan gateway yang ada (k8-api-gateway).

Buka httproute untuk mengedit:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Tambahkan referensi backend baru yang mengarah ke layanan load balancer Ingress Gateway baru dengan bobot awal 10% dan perbarui bobot untuk backend gateway lama.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

Memberikan Izin untuk Referensi Lintas Namespace dengan pemberian referensi.

Untuk mengizinkan HTTPRoute di namespace aplikasi (default) mengakses layanan loadbalancer di namespace gateway (istio-ingress), Anda mungkin perlu membuat pemberian referensi. Resource ini berfungsi sebagai kontrol keamanan, yang secara eksplisit menentukan referensi lintas namespace yang diizinkan.

istio-ingress-grant.yaml berikut menjelaskan contoh pemberian referensi:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

Terapkan hibah referensi:

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

Memverifikasi permintaan ke alamat IP eksternal yang ada (mis. 34.57.246.68) tidak gagal. check-traffic-flow.sh berikut menjelaskan skrip untuk memeriksa kegagalan permintaan:

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

Jalankan skrip untuk mengonfirmasi bahwa tidak ada permintaan yang gagal, terlepas dari rute traffic:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Alur permintaan dengan pemisahan traffic antara gateway yang ada dan gateway ingress istio baru

Meningkatkan persentase traffic secara perlahan

Jika tidak ada kegagalan permintaan yang terlihat untuk alamat IP eksternal yang ada (misalnya, 34.57.246.68), secara bertahap alihkan lebih banyak traffic ke Gateway Ingress Istio baru dengan menyesuaikan bobot backend di HTTPRoute Anda. Naikkan bobot untuk istio-ingressgateway dan turunkan bobot untuk gateway lama dalam penambahan kecil seperti 10%, 20%, dan seterusnya.

Gunakan perintah berikut untuk memperbarui HTTPRoute yang ada:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migrasi traffic penuh dan menghapus gateway lama

Saat Istio Ingress Gateway baru menunjukkan performa yang stabil dan penanganan permintaan yang berhasil, alihkan semua traffic ke gateway tersebut. Perbarui HTTPRoute untuk menetapkan bobot backend gateway lama ke 0 dan gateway baru ke 100.
Setelah traffic dirutekan sepenuhnya ke gateway baru, perbarui data DNS eksternal untuk nama host aplikasi Anda (misalnya, httpbin.example.com) agar mengarah ke alamat IP eksternal layanan load balancer yang dibuat di Menyediakan Istio Ingress Gateway baru.

Terakhir, hapus gateway lama dan resource terkaitnya:

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Migrasi Langsung