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

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

Update konfigurasi untuk modernisasi

Dokumen ini menjelaskan update konfigurasi yang harus Anda lakukan pada cluster Cloud Service Mesh terkelola jika ditandai oleh pemeriksaan kompatibilitas sebelum melakukan modernisasi dari bidang kontrol ISTIOD yang tidak digunakan lagi ke bidang kontrol TRAFFIC_DIRECTOR sebelum batas waktu akhir dukungan.

Berikut adalah daftar kemungkinan update konfigurasi yang diperlukan untuk mempersiapkan 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 Gateway Ingress Istio
Memodernisasi konfigurasi kompresor EnvoyFilter
Mengaktifkan Grup Endpoint Jaringan Internet
Izin VPC Bersama
Konfigurasi Bidang Kontrol Tidak Ada

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

Ringkasan secret Istio versus API deklaratif

Penemuan endpoint multi-cluster istio open source berfungsi menggunakan istioctl atau alat lain untuk membuat Secret Kubernetes dalam cluster. Secret ini memungkinkan cluster melakukan load balancing traffic ke cluster lain di mesh. Bidang kontrol 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 di masa 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 untuk ke depannya.

Jika Anda menggunakan Istio Secrets, segera migrasikan untuk menggunakan 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 untuk 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 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 akan 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 mengaktifkan 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 agar cluster tidak menggunakan penemuan endpoint:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Hapus secret lama.

Setelah menetapkan multicluster_mode=connected di cluster Anda, setiap cluster akan memiliki secret baru yang dibuat untuk setiap cluster lain yang juga memiliki multicluster_mode=connected yang ditetapkan. 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 memastikan metrik tersebut 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 layanan Google Cloud 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 kumpulan Workload Identity Federation yang 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 bagian Mengupdate cluster yang ada untuk mengaktifkan workload identity pada 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, update node pool menggunakan panduan Memperbarui node pool yang ada.

Mengaktifkan antarmuka jaringan container (CNI) 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 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 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 intersepsi traffic untuk file bantuan Istio. Plugin CNI menjalankan 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 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. 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 sidecar Istio dimulai bersama dengan container aplikasi.

Oleh karena itu, jika container init mencoba membuat koneksi jaringan keluar atau terhubung ke layanan dalam mesh, permintaan jaringan dari container init dapat dihapus 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 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 container init Anda. Pertimbangkan alternatif berikut:
- Mengubah 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 ConfigMap atau secret Kubernetes: Simpan data konfigurasi yang diambil oleh permintaan jaringan di ConfigMap atau secret Kubernetes dan pasang ke container aplikasi Anda. Untuk solusi alternatif, lihat dokumentasi Istio.
Aktifkan CNI terkelola di cluster Anda:
1. Buat 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 anotasi 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 annotate 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.
  - Pastikan 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 dan 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 untuk membuat deployment Anda kompatibel dengan image proxy envoy distroless.

Image sidecar proxy envoy distroless

Cloud Service Mesh menggunakan dua jenis image sidecar proxy Envoy berdasarkan konfigurasi bidang kontrol Anda: image proxy default (berisi berbagai biner debug) dan image proxy distroless.

Untuk cluster dengan bidang kontrol TRAFFIC_DIRECTOR terkelola:

Cluster yang diaktivasi secara langsung: Menggunakan image distroless secara default.
Cluster yang dimigrasikan dari CSM-ISTIOD: Menggunakan image default secara default. Anda dapat secara eksplisit memilih untuk menggunakan image distroless guna meningkatkan postur keamanan Anda.

Untuk mengaktifkan image distroless bagi cluster yang dimigrasikan dari CSM-ISTIOD, Anda dapat mengonfigurasinya secara global menggunakan defaultConfig.image.imageType: distroless di MeshConfig, atau per workload menggunakan anotasi pod sidecar.istio.io/proxyImageType: 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 container hanya pada paket yang diperlukan. Pendekatan ini meningkatkan keamanan dan rasio sinyal terhadap derau pemindai Common Vulnerabilities and Exposures (CVE). Image Sidecar Distroless memiliki kumpulan dependensi minimal, tanpa 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 container.

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 Lifecycle 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. Sebagai contoh, lihat Mengumpulkan log {service_mesh_name}.

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

Bermigrasi ke Gateway Ingress Istio

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

Migrasi Bertahap dengan Pemisahan Traffic

Metode ini memprioritaskan meminimalkan gangguan, yaitu Anda akan mengirim traffic secara bertahap ke gateway Istio baru, sehingga Anda dapat memantau performanya pada sebagian kecil permintaan dan melakukan rollback dengan cepat jika diperlukan. Perlu diingat bahwa mengonfigurasi pemisahan traffic Lapisan 7 dapat menjadi tantangan bagi beberapa aplikasi, sehingga 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 ulang semua traffic secara bersamaan ke gateway Istio baru setelah Anda melakukan pengujian secara menyeluruh. Keuntungan dari pendekatan ini adalah pemisahan total dari infrastruktur gateway lama, sehingga memungkinkan konfigurasi gateway baru yang dapat disesuaikan 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 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 (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 Gateway Ingress Istio baru

Deploy Gateway Ingress baru dengan mengikuti langkah-langkah di bagian Men-deploy contoh gateway dan sesuaikan contoh konfigurasi dengan kebutuhan 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 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

Mengakses layanan backend (httpbin) melalui Gateway Ingress Istio 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, perbarui 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 Gateway Ingress 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 ReferenceGrant.

Agar HTTPRoute Anda di namespace aplikasi (default) dapat 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

Verifikasi permintaan ke alamat IP eksternal yang ada (misalnya, 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

Tingkatkan persentase traffic secara perlahan

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

Gunakan perintah berikut untuk mengupdate HTTPRoute yang ada:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migrasi traffic penuh dan penghapusan gateway lama

Jika Gateway Ingress Istio yang baru menunjukkan performa yang stabil dan penanganan permintaan yang berhasil, alihkan semua traffic ke gateway tersebut. Perbarui HTTPRoute Anda untuk menetapkan 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 Gateway Istio Ingress 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 Gateway Ingress Istio 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

Mengakses layanan backend (httpbin) melalui Gateway Ingress Istio 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

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 Gateway Ingress Istio baru.
Pantau metrik utama seperti rasio keberhasilan permintaan, latensi, tingkat error, dan pemanfaatan resource pod aplikasi Anda untuk memverifikasi stabilitas dengan Gateway Istio Ingress yang 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 Gateway Ingress Istio baru jika aplikasi Anda memerlukan HTTPS. Lihat Menyiapkan TLS termination di gateway ingress untuk mengetahui detail selengkapnya.

Memperbaiki beberapa bidang kontrol

Cloud Service Mesh sebelumnya mendukung aktivasi 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 mesh baru 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 saluran dengan mencari kondisi status UNSUPPORTED_MULTIPLE_CONTROL_PLANES pada keanggotaan 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 bidang 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.30/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 saluran 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 disediakan:
- asm-managed-stable -> STABLE
- asm-managed -> REGULAR
- asm-managed-rapid -> RAPID
Jika hanya 1 hasil yang muncul, berarti hanya satu saluran yang disediakan di cluster Anda, dan Anda dapat melewati langkah-langkah selanjutnya.

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

Menggabungkan workload ke satu saluran

Sebelum dapat menghapus saluran tambahan, Anda harus memastikan workload Anda hanya menggunakan satu saluran.

Temukan semua label yang Anda gunakan di cluster:
```
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 diinjeksikan dengan saluran reguler.

Jika semua workload Anda sudah menggunakan saluran yang sama, Anda dapat langsung melanjutkan ke langkah Menghapus 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 dimasukkan langsung dalam beberapa kasus dengan label sidecar.istio.io/inject. Pastikan untuk memeriksa juga penggunaan tersebut.
- Anda dapat mengabaikan label istio-injection=enabled untuk langkah ini. Namespace dengan label tersebut akan otomatis berubah agar sesuai 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 saluran ini tidak ada, pilih salah satu saluran yang aktif.
- Saluran sebenarnya yang Anda pilih tidak menjadi masalah. 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 saluran tersebut. Setiap saluran menggunakan configmap terpisah untuk konfigurasi, sehingga menggabungkan dua saluran menjadi satu akan memastikan perilaku yang konsisten di antara kedua saluran tersebut. 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 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 workload agar diinjeksikan oleh bidang kontrol yang benar.

Menghapus saluran tambahan

Setelah memverifikasi bahwa semua workload berjalan di satu saluran, Anda dapat menghapus saluran 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 telah terdaftar ke fleet.
- PROJECT_ID adalah project ID project Anda.
- MEMBERSHIP_LOCATION adalah lokasi keanggotaan Anda (region, atau global). Anda dapat memeriksa lokasi keanggotaan 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.30/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.
...

Memodernisasi konfigurasi kompresor EnvoyFilter

Jika Anda menggunakan filter envoy.extensions.filters.http.compressor.v3.Compressor, beberapa kolom tingkat atas tidak digunakan lagi di Envoy dan dipindahkan ke response_direction_config.common_config dan request_direction_config.common_config.

Untuk mempelajari cara mengupdate resource EnvoyFilter ke format modern dan yang didukung, lihat panduan Memodernisasi konfigurasi kompresor EnvoyFilter.

Mengaktifkan Kebijakan Organisasi yang Diperlukan

Cloud Service Mesh memerlukan kebijakan tertentu untuk diaktifkan agar dapat beroperasi dengan sukses.

Kebijakan yang Diperlukan

compute.disableInternetNetworkEndpointGroup

Cloud Service Mesh memerlukan kemampuan untuk membuat Grup Endpoint Jaringan (NEG) Internet. NEG ini adalah komponen penting untuk merutekan traffic ke layanan di luar Google Cloud.

Batasan constraints/compute.disableInternetNetworkEndpointGroup dapat mencegah pembuatan NEG Internet yang diperlukan ini.

Jika kebijakan organisasi ini diterapkan pada project, folder, atau organisasi Anda, kebijakan ini akan memblokir Cloud Service Mesh agar tidak berfungsi dengan benar dengan bidang kontrol Traffic Director. Tindakan ini akan mencegah migrasi ke atau keberhasilan operasi konfigurasi Cloud Service Mesh ini.

Jika Enforced ditetapkan ke true, pembuatan NEG Internet akan dinonaktifkan.

Bagaimana cara mengetahui apakah saya terpengaruh?

Anda dapat memeriksa kebijakan yang berlaku untuk project Anda menggunakan konsol Google Cloud atau Google Cloud CLI. Petunjuk untuk melihat kebijakan organisasi dapat ditemukan di bagian Melihat kebijakan organisasi dalam dokumentasi resmi.

Misalnya, Anda dapat menggunakan perintah Google Cloud CLI ini:

gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective

Jika kebijakan menampilkan nilai enforced: true, berarti Anda terpengaruh.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
  enforced: true

Jika kebijakan menampilkan nilai yang berbeda atau kosong, Anda tidak akan terpengaruh.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

Menyelesaikan Masalah

Jika kebijakan diterapkan, Anda harus menonaktifkan batasan ini (ditetapkan ke false) di level organisasi, folder, atau project.

Petunjuk mendetail tentang cara mengubah kebijakan organisasi, termasuk batasan boolean seperti ini, dapat ditemukan dalam panduan Membuat dan mengelola kebijakan organisasi. Biasanya, Anda memerlukan peran roles/orgpolicy.policyAdmin untuk melakukan perubahan ini.

Izin VPC Bersama

Saat menggunakan Cloud Service Mesh terkelola dengan VPC Bersama, tempat cluster Anda berada di project layanan dan jaringan VPC berada di project host, diperlukan izin tambahan untuk agen layanan Cloud Service Mesh di project fleet.

Sebagai bagian dari migrasi ke bidang kontrol TRAFFIC_DIRECTOR, Cloud Service Mesh memerlukan izin untuk mengelola aturan firewall di project host guna memastikan health check dan fungsi jaringan yang tepat. Hal ini tidak diperlukan untuk bidang kontrol ISTIOD sebelumnya.

Bagaimana cara mengetahui apakah saya terpengaruh?

Anda akan terpengaruh jika:

Cluster GKE Anda berada dalam project layanan.
Cluster ini menggunakan jaringan VPC Bersama yang dihosting di project yang berbeda (project host VPC).
Agen layanan Cloud Service Mesh project Fleet tidak memiliki izin untuk mengelola aturan firewall di project host VPC.

Anda mungkin melihat pesan peringatan dengan kode SHARED_VPC_MISSING_PERMISSIONS di status fitur fleet Anda. Untuk mengetahui detail selengkapnya tentang cara memahami dan menyelesaikan masalah ini, termasuk opsi yang dikelola sistem dan dikelola pengguna, lihat Memahami health check.

Konfigurasi Bidang Kontrol Tidak Ada

Praktik terbaik Cloud Service Mesh untuk mengelola mesh layanan menggunakan Fleet API Google Kubernetes Engine untuk menetapkan kolom Management ke AUTOMATIC. Hal ini menyediakan pengelolaan otomatis sepenuhnya untuk banyak fitur mesh seperti webhook dan bidang kontrol. Selain itu, perintah ini menyiapkan cluster untuk otomatis menerima update dan fitur baru saat dirilis. Beberapa metode penginstalan lama tidak mengonfigurasi Cloud Service Mesh dengan cara ini, dan Anda harus melakukan beberapa langkah manual untuk menerapkan patch.

Bagaimana cara mengetahui apakah saya terpengaruh?

Periksa apakah Anda memiliki ControlPlaneRevision di cluster:

kubectl get controlplanerevisions -n istio-system

Jika Anda sudah memiliki ControlPlaneRevision di cluster, panduan ini tidak berlaku untuk Anda. Jika Anda tidak memiliki ControlPlaneRevision, gunakan panduan ini untuk memodernisasi cluster Anda.

Jika Anda menerima peringatan MISSING_CONTROL_PLANE_CONFIG dan tidak ingin menggunakan Cloud Service Mesh, nonaktifkan Cloud Service Mesh.

Langkah-Langkah Modernisasi

Ikuti langkah-langkah berikut untuk menentukan hal yang perlu dilakukan agar konfigurasi Anda selaras dengan standar saat ini.

gcloud container fleet mesh describe --project PROJECT_ID

Lakukan langkah-langkah berikut bergantung pada output:

Output	Langkah yang harus dilakukan
`API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)?`	Respons `y` dan coba lagi.
`ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled`	Lanjutkan ke 1. Aktifkan fitur mesh.
`... resourceState: state: ACTIVE ...`	Lanjutkan ke 2. Daftarkan cluster Anda ke Fleet.

1. Mengaktifkan fitur mesh

Mengaktifkan fitur mesh dapat dilakukan menggunakan perintah berikut. Tindakan ini memungkinkan Cloud Service Mesh berjalan di project Anda. Untuk mengetahui detail selengkapnya dan potensi efek samping, lihat Menyediakan Mesh Layanan.

gcloud container fleet mesh enable --project PROJECT_ID

Setelah mengaktifkan fitur mesh, lanjutkan ke 2. Daftarkan cluster Anda ke Fleet.

2. Mendaftarkan cluster Anda ke Fleet

Periksa apakah cluster Anda sudah terdaftar ke fleet:

gcloud container fleet memberships list --project PROJECT_ID

Jika cluster Anda tidak tercantum, ikuti petunjuk berikut untuk mendaftarkannya: Mendaftarkan cluster ke fleet.

Dengan mendaftarkan cluster ke fleet, cluster tersebut dapat mengelola fitur, seperti Cloud Service Mesh, melalui fleet.

3. Menentukan saluran mesh Anda

Cloud Service Mesh bergantung pada saluran Google Kubernetes Engine cluster Anda, bukan saluran mesh independen. Sebelumnya, Cloud Service Mesh mendukung pemilihan satu atau beberapa saluran mesh (berbeda dengan saluran cluster Google Kubernetes Engine). Anda mungkin masih memiliki referensi ke saluran ini dalam konfigurasi mesh.

Pertama, tentukan saluran yang Anda gunakan. Jika Anda menggunakan beberapa saluran, ikuti petunjuk di Memperbaiki beberapa bidang kontrol untuk mengurangi penggunaan menjadi satu saluran.

Untuk menentukan saluran mesh yang Anda gunakan, periksa label di namespace Anda. Perhatikan bahwa Anda mungkin juga perlu memeriksa workload jika telah menambahkan label injeksi secara khusus pada workload. Perintah berikut memeriksa semua workload dalam cluster dan memfilter output untuk menampilkan bidang kontrol dan tag injeksi yang digunakan untuk workload tersebut.

kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"

Jika Anda membuat tag kustom atau webhook secara manual, Anda juga perlu memeriksanya.

Outputnya mirip dengan:

namespace/default                                 Active   153d   istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments                                Active   42d    istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default    pod/frontend-847f569874-v9kjz          2/2      Running  0   2m     app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments   pod/checkout-0                         2/2      Running  0   5d     app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default    deployment.apps/frontend               1/1      1        1   153d   app=frontend,istio.io/rev=asm-managed
payments   statefulset.apps/checkout              1/1      1        1   42d    app=checkout,istio.io/rev=asm-managed-stable

Perhatikan nilai yang ada untuk istio.io/rev={channel}. Nama-nama tersebut cocok dengan saluran dengan cara ini. Jika ada beberapa saluran yang digunakan, ikuti petunjuk di Memperbaiki beberapa bidang kontrol untuk menguranginya menjadi satu saluran:

Nilai	Saluran
`asm-managed-stable`	Stabil
`asm-managed`	Reguler
`asm-managed-rapid`	Cepat

Jika saluran mesh Anda cocok dengan saluran Cluster Google Kubernetes Engine, lanjutkan ke langkah 5.

4. Membuat resource ControlPlaneRevision untuk saluran mesh Anda

Jika saluran mesh Anda cocok dengan saluran Cluster Google Kubernetes Engine, Anda dapat melewati langkah ini. Mengaktifkan pengelolaan bidang kontrol otomatis akan otomatis membuat resource ControlPlaneRevision ini jika saluran Anda cocok dengan saluran cluster.

Buat resource ControlPlaneRevision untuk saluran mesh yang Anda gunakan:

Stabil

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-stable
  namespace: istio-system
spec:
  type: managed_service
  channel: stable
EOF

Reguler

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed
  namespace: istio-system
spec:
  type: managed_service
  channel: regular
EOF

Cepat

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-rapid
  namespace: istio-system
spec:
  type: managed_service
  channel: rapid
EOF

5. Mengaktifkan Pengelolaan Otomatis

Untuk menonaktifkan penemuan endpoint multi-cluster, ikuti petunjuk "Menonaktifkan" di API deklaratif penemuan endpoint sebelum mengaktifkan pengelolaan bidang kontrol otomatis.

Untuk menonaktifkan bidang data terkelola, ikuti petunjuk di Menonaktifkan bidang data terkelola.

Untuk mengaktifkan pengelolaan otomatis, jalankan perintah berikut. Tindakan ini akan memungkinkan Cloud Service Mesh yang dikelola Fleet untuk mengelola konfigurasi bidang kontrol cluster Anda.

gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID

Ganti MY_CLUSTER_MEMBERSHIP dengan nama keanggotaan cluster Anda.

6. Memverifikasi Penginstalan

Jalankan perintah berikut:

gcloud container fleet mesh describe --project PROJECT_ID

Outputnya mirip dengan:

createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    servicemesh:
      conditions: [] # See item 2 below
      controlPlaneManagement: # See item 3 below
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement: # See item 4 below
        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.
      updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'

Dalam membershipSpecs, setiap keanggotaan dalam fleet Anda memiliki spesifikasi terpisah. Pastikan setiap anggota memiliki pengelolaan yang ditetapkan ke MANAGEMENT_AUTOMATIC dengan benar.
Setiap keanggotaan memiliki daftar kondisi status yang terkait dengannya. Pastikan tidak ada error atau peringatan di sini, dan ikuti link dokumentasi yang disediakan untuk menyelesaikan masalah.
controlPlaneManagement berisi status bidang kontrol Anda. Pastikan bidang kontrol berada dalam status ACTIVE.
dataPlaneManagement berisi status bidang data. Sebaiknya aktifkan fitur ini.