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 pembaruan konfigurasi yang diperlukan untuk menyiapkan cluster Anda untuk modernisasi. Lihat setiap bagian untuk mengetahui petunjuk update:

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

Untuk mengetahui informasi selengkapnya tentang alur kerja modernisasi, lihat halaman Modernisasi bidang kontrol terkelola.

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 memodernisasi dari penggunaan secret multi-cluster Istio ke penggunaan multicluster_mode.

Ringkasan API deklaratif versus rahasia Istio

Penemuan endpoint multi-cluster istio open source berfungsi dengan menggunakan istioctl atau alat lain untuk membuat Secret Kubernetes di cluster. Secret ini memungkinkan cluster menyeimbangkan beban traffic ke cluster lain dalam mesh. Bidang kontrol ISTIOD kemudian membaca rahasia 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 penerapan 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 depannya.

Jika Anda menggunakan Istio Secrets, segera bermigrasi ke penggunaan API deklaratif. 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 setiap cluster yang harus mengarahkan traffic ke cluster lain dalam mesh. Untuk mengetahui daftar lengkap perbedaan antara fitur yang didukung dari API deklaratif dan secret Istio, lihat Fitur yang didukung menggunakan Istio API.

Bermigrasi dari rahasia 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 sebentar ke perutean lokal, bukan load balancing ke cluster lain. Untuk mengetahui informasi selengkapnya, lihat masalah GitHub.

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

Aktifkan API deklaratif untuk setiap cluster di 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 mengikutsertakan cluster dalam penemuan endpoint multi-cluster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Gunakan perintah berikut untuk membatalkan keikutsertaan cluster dalam penemuan endpoint:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Hapus secret lama.

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

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

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

Mengaktifkan Workload Identity Federation untuk GKE

Workload Identity Federation adalah metode aman yang direkomendasikan untuk beban kerja 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

Periksa apakah Workload Identity Federation diaktifkan untuk cluster Anda. Untuk melakukannya, pastikan cluster GKE telah mengonfigurasi set pool Workload Identity Federation, yang penting untuk validasi kredensial IAM.

Gunakan perintah berikut untuk memeriksa setelan workload identity pool 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 Mengupdate 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.

Mencantumkan semua node pool cluster Standard. 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 (CNI) container terkelola

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

Ringkasan CNI terkelola

Antarmuka jaringan container (CNI) terkelola adalah implementasi Istio CNI 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 istimewa untuk init-container yang diperlukan untuk mengelola iptables.

Plugin CNI Istio menggantikan container istio-init. Container istio-init sebelumnya bertanggung jawab untuk menyiapkan lingkungan jaringan pod guna mengaktifkan pencegatan traffic untuk file bantuan Istio. Plugin CNI melakukan fungsi pengalihan jaringan yang sama, tetapi dengan manfaat tambahan berupa pengurangan 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 Managed Cloud Service Mesh.

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. Container 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 container init dijalankan dan diselesaikan.
Proxy file bantuan Istio dimulai bersama dengan container aplikasi.

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

Aktifkan CNI terkelola untuk cluster Anda

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

Hapus dependensi jaringan dari init container Anda. Pertimbangkan alternatif berikut:
- Ubah logika atau container aplikasi: Anda dapat mengubah layanan untuk menghapus dependensi pada container init yang memerlukan permintaan jaringan atau melakukan operasi jaringan dalam container aplikasi, setelah proxy sidecar dimulai.
- Gunakan ConfigMaps atau secret Kubernetes: Simpan data konfigurasi yang diambil oleh permintaan jaringan di ConfigMaps atau secret Kubernetes dan pasang ke dalam container 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 akan memicu mulai ulang 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 Fleet Anda. Umumnya, FLEET_PROJECT_ID memiliki nama yang sama dengan project.
  - Verifikasi bahwa kondisi MANAGED_CNI_NOT_ENABLED dihapus dari servicemesh.conditions.
  - Perhatikan bahwa pembaruan status dapat memerlukan waktu hingga 15-20 menit. Coba tunggu beberapa menit dan jalankan kembali perintah.
3. Setelah controlPlaneManagement.state menjadi Active di status fitur cluster, mulai ulang pod.

Beralih dari Penggunaan Biner Non-Standar di Sidecar

Bagian ini menyarankan cara membuat deployment Anda kompatibel dengan image proxy envoy tanpa distro.

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 keamanan dan pengoptimalan resource dengan hanya menyertakan komponen penting. Permukaan serangan dikurangi untuk membantu mencegah kerentanan. Untuk mengetahui informasi selengkapnya, lihat dokumentasi tentang Image proxy tanpa distro.

Kompatibilitas biner

Sebagai praktik terbaik, Anda harus membatasi konten runtime penampung hanya pada paket yang diperlukan. Pendekatan ini meningkatkan keamanan dan rasio sinyal terhadap derau pemindai Common Vulnerabilities and Exposures (CVE). Gambar Distroless Sidecar memiliki serangkaian dependensi minimal, yang tidak memiliki semua dapat dieksekusi, library, dan alat debug yang tidak penting. Oleh karena itu, perintah shell tidak dapat dieksekusi atau curl, ping, atau utilitas debug lainnya seperti kubectl exec tidak dapat digunakan di dalam penampung.

Membuat cluster yang kompatibel dengan gambar tanpa distro

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 container 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. Untuk contohnya, lihat Mengumpulkan log Cloud Service Mesh.

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

Bermigrasi ke Istio Ingress Gateway

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 minimisasi gangguan dengan mengirimkan traffic secara inkremental ke gateway Istio baru, sehingga Anda dapat memantau performanya pada sebagian kecil permintaan dan dengan cepat melakukan revert jika perlu. Perlu diingat bahwa mengonfigurasi pemisahan traffic Lapisan 7 bisa jadi sulit untuk beberapa aplikasi, jadi Anda perlu mengelola kedua sistem gateway secara bersamaan selama transisi. Lihat Migrasi Bertahap dengan pemisahan traffic untuk mengetahui langkah-langkahnya.
Migrasi Langsung

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

Contoh migrasi berikut mengasumsikan 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 (di 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 Gateway Ingress baru dengan mengikuti langkah-langkah di bagian Deploy gateway contoh dan sesuaikan konfigurasi contoh dengan kebutuhan Anda. Contoh di repositori anthos-service-mesh ditujukan untuk men-deploy layanan istio-ingressgateway loadBalancer 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 perutean 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

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

Tetapkan variabel lingkungan Ingress Host 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}')

Verifikasi bahwa 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 istio ingress gateway baru

Mengubah Ingress yang ada untuk pemisahan traffic

Setelah mengonfirmasi keberhasilan penyiapan gateway baru (mis. 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 sebagian besar traffic 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

Berikan Izin untuk Referensi Lintas Namespace dengan pemberian referensi.

Untuk mengizinkan HTTPRoute Anda 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 pemberian 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 masuk 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 Istio Ingress Gateway baru dengan menyesuaikan bobot backend di HTTPRoute. Tingkatkan bobot untuk istio-ingressgateway dan kurangi bobot untuk gateway lama secara bertahap, misalnya 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

Setelah Istio Ingress Gateway baru menunjukkan performa yang stabil dan penanganan permintaan yang berhasil, alihkan semua traffic ke Istio Ingress Gateway baru. Perbarui HTTPRoute Anda untuk menyetel bobot backend gateway lama ke 0 dan gateway baru ke 100.
Setelah traffic sepenuhnya dirutekan 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

Menyediakan Istio Ingress Gateway baru

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

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

Tetapkan variabel lingkungan Ingress Host 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}')

Verifikasi bahwa 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 istio ingress gateway baru

Menguji dan Memantau gateway baru

Uji semua aturan perutean, validasi konfigurasi TLS, kebijakan keamanan, dan fitur lainnya. Lakukan pengujian beban untuk memverifikasi bahwa gateway baru dapat menangani traffic yang diharapkan.
Setelah gateway baru diuji sepenuhnya, 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.
Pantau metrik utama seperti tingkat keberhasilan permintaan, latensi, tingkat error, dan pemanfaatan resource pod aplikasi Anda untuk memverifikasi stabilitas dengan Istio Ingress Gateway baru. Setelah stabil, Anda dapat menghapus gateway lama dan resource terkaitnya
```
kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE
```

Pertimbangan Penting: Pastikan sertifikat dan konfigurasi TLS disiapkan dengan benar di Istio Ingress Gateway baru jika aplikasi Anda memerlukan HTTPS. Lihat Menyiapkan penghentian TLS di gateway ingress untuk mengetahui detail selengkapnya.

Memperbaiki beberapa bidang kontrol

Cloud Service Mesh sebelumnya mendukung onboarding menggunakan asmcli (tidak digunakan lagi) yang tidak memblokir penyediaan beberapa bidang kontrol. Cloud Service Mesh kini menerapkan praktik terbaik untuk men-deploy hanya satu saluran per cluster yang cocok dengan saluran cluster dan tidak mendukung penggunaan beberapa saluran yang di-deploy dalam cluster yang sama.

Jika Anda menginginkan deployment canary pada versi baru mesh di saluran cepat sebelum tersedia di saluran stabil atau reguler, Anda harus menggunakan dua cluster berbeda yang masing-masing memiliki saluran terpisah. Perhatikan bahwa saluran dikontrol oleh Saluran Cluster GKE, dan Mesh tidak memiliki saluran terpisah yang terkait dengannya.

Anda dapat memeriksa apakah Anda memiliki beberapa channel dengan mencari UNSUPPORTED_MULTIPLE_CONTROL_PLANES kondisi status di langganan Anda. Jika peringatan ini tidak muncul, berarti Anda tidak terpengaruh dan dapat melewati bagian ini.

Jalankan perintah berikut untuk memeriksa apakah cluster Anda memiliki beberapa saluran panel kontrol:

gcloud container fleet mesh describe

Outputnya mirip dengan:

...
projects/.../locations/global/memberships/my-membership:
    servicemesh:
      conditions:
      - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
        details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
        documentationLink: https://cloud.google.com/service-mesh/v1.26/docs/migrate/modernization-configuration-updates#multiple_control_planes
        severity: WARNING
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-stable'
        implementation: ISTIOD
        state: ACTIVE
...

Jika kondisi UNSUPPORTED_MULTIPLE_CONTROL_PLANES muncul, tentukan channel mana yang ada untuk cluster Anda:
```
kubectl get controlplanerevisions -n istio-system
```
Outputnya mirip dengan:
```
NAME                 RECONCILED   STALLED   AGE
asm-managed-stable   True         False     97d
asm-managed          True         False     97d
asm-managed-rapid    True         False     97d
```
Dalam contoh ini, ketiga saluran telah disediakan:
- asm-managed-stable -> STABIL
- asm-managed -> REGULAR
- asm-managed-rapid -> RAPID
Jika hanya 1 hasil yang muncul, berarti hanya ada satu channel yang disediakan di cluster Anda, dan Anda dapat melewati langkah-langkah lainnya.

Jika 2 hasil atau lebih muncul, ikuti langkah-langkah selanjutnya untuk menghapus channel yang berlebih.

Menggabungkan beban kerja ke satu saluran

Sebelum dapat menghapus channel tambahan, Anda harus memastikan beban kerja Anda hanya menggunakan satu channel.

Temukan semua label yang Anda gunakan di cluster Anda:
```
kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL
```
Bergantung pada output dari perintah sebelumnya, ganti RELEASE_CHANNEL dengan asm-managed-stable, asm-managed, atau asm-managed-rapid. Ulangi langkah ini untuk setiap saluran yang disediakan.

Outputnya mirip dengan:
```
NAME      STATUS   AGE
default   Active   110d
```
Perhatikan bahwa dalam contoh ini, namespace default disisipkan dengan saluran reguler.

Jika semua workload Anda sudah menggunakan saluran yang sama, Anda dapat melewati langkah Hapus saluran tambahan. Jika tidak, lanjutkan di bagian ini.
Ubah label sehingga hanya satu saluran yang digunakan:

Perhatian: Pertimbangkan hal berikut sebelum mengubah label.
- Pod juga dapat disisipkan langsung dalam beberapa kasus dengan label sidecar.istio.io/inject. Pastikan untuk memeriksa penggunaan tersebut juga.
- Anda dapat mengabaikan label istio-injection=enabled untuk langkah ini. Namespace dengan label tersebut akan otomatis berubah agar cocok dengan saluran mana pun yang tersisa di cluster.
- Saat memilih saluran yang akan dipertahankan, coba pilih saluran yang sama dengan Saluran Cluster GKE Anda. Jika channel ini tidak ada, pilih salah satu channel aktif.
- Channel yang Anda pilih tidak penting. Saluran Cluster GKE menentukan versi mesh yang Anda dapatkan, bukan saluran Mesh.
- Periksa konfigurasi meshconfig Anda di antara saluran aktif yang sedang digunakan untuk memastikan tidak ada perbedaan di antara keduanya. Setiap saluran menggunakan configmap terpisah untuk konfigurasi, sehingga menggabungkan dua saluran menjadi satu akan memastikan perilaku yang konsisten di antara kedua saluran. kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml
```
kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
```
Ganti NAMESPACE dengan nama namespace Anda.

Praktik terbaiknya adalah menggunakan istio-injection=enabled. Namun, jika Anda tidak ingin menggunakan label tersebut, Anda juga dapat menggunakan istio.io/rev=RELEASE_CHANNEL.

Setelah mengubah label untuk namespace / pod, Anda harus memulai ulang semua beban kerja agar disuntikkan oleh bidang kontrol yang benar.

Hapus channel tambahan

Setelah memverifikasi bahwa semua workload Anda berjalan di satu channel, Anda dapat menghapus channel tambahan yang tidak digunakan. Jika ketiga saluran rilis disediakan, jangan lupa untuk menjalankan perintah berikut untuk setiap saluran.

Hapus resource ControlPlaneRevision tambahan:
```
kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system
```
Ganti RELEASE_CHANNEL dengan asm-managed-stable, asm-managed, atau asm-managed-rapid.

Hapus MutatingWebhookConfiguration.

kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL

Hapus configmap meshconfig:

kubectl delete configmap istio-RELEASE_CHANNEL

Mengaktifkan pengelolaan otomatis

Jalankan perintah berikut untuk mengaktifkan pengelolaan otomatis:
```
gcloud container fleet mesh update \
    --management automatic \
    --memberships MEMBERSHIP_NAME \
    --project PROJECT_ID \
    --location MEMBERSHIP_LOCATION
```
Ganti kode berikut:
- MEMBERSHIP_NAME adalah nama keanggotaan yang tercantum saat Anda memverifikasi bahwa cluster Anda terdaftar ke fleet.
- PROJECT_ID adalah project ID project Anda.
- MEMBERSHIP_LOCATION adalah lokasi langganan Anda (baik wilayah, atau global). Anda dapat memeriksa lokasi langganan dengan gcloud container fleet memberships list --project PROJECT_ID.

Pastikan pengelolaan otomatis diaktifkan:

gcloud container fleet mesh describe

Outputnya mirip dengan:

...
membershipSpecs:
  projects/.../locations/us-central1/memberships/my-member:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/.../locations/us-central1/memberships/my-member:
    servicemesh:
      conditions:
      - code: VPCSC_GA_SUPPORTED
        details: This control plane supports VPC-SC GA.
        documentationLink: http://cloud.google.com/service-mesh/v1.26/docs/managed/vpc-sc
        severity: INFO
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
...