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 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
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 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 dalam cluster. Secret ini memungkinkan cluster melakukan load balancing traffic ke cluster lain dalam 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 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 bermigrasi 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 cluster mana yang harus dituju traffic di mesh untuk setiap cluster. Untuk mengetahui daftar lengkap perbedaan antara fitur yang didukung dari API deklaratif dan secret Istio, lihat Fitur yang didukung menggunakan API Istio.

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 Anda, 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 memiliki label istio.io/owned-by: mesh.googleapis.com yang diterapkan.

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 for GKE

Workload Identity Federation adalah metode aman yang direkomendasikan untuk beban kerja Google Kubernetes Engine. Hal ini memungkinkan akses ke layanan seperti Compute Engine, BigQuery, dan Machine Learning API. Google Cloud 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 Anda 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 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 Anda 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 (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 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 lebih tinggi, 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 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 mungkin akan dibatalkan atau salah diarahkan. 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:
- 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 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 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.
  - 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 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 Anda, 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 (signal-to-noise ratio) pemindai Common Vulnerabilities and Exposures (CVE). Image Distroless Sidecar memiliki serangkaian dependensi minimal, yang telah dihapus dari semua dapat dieksekusi, library, dan alat proses 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 kompatibel dengan image tanpa distro

Hapus referensi ke biner yang tidak didukung (seperti bash atau curl) dari konfigurasi Anda. Terutama 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. 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 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 bertahap ke gateway Istio baru, sehingga Anda dapat memantau performanya pada sebagian kecil permintaan dan dengan cepat melakukan pengembalian jika diperlukan. Perlu diingat bahwa mengonfigurasi pembagian traffic Lapisan 7 dapat menjadi tantangan bagi 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 ulang 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 gateway baru yang dapat disesuaikan tanpa batasan penyiapan yang ada. Namun, ada peningkatan risiko waktu non-operasional jika masalah tak terduga muncul dengan 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 gateway ingress istio baru

Mengubah Ingress yang ada untuk pemisahan traffic

Setelah mengonfirmasi penyiapan gateway baru yang berhasil (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 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 rujukan:

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

Sebelumnya, Cloud Service Mesh 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 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 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/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 disuntikkan dengan saluran reguler.

Jika semua workload Anda sudah menggunakan channel yang sama, Anda dapat langsung membuka langkah Hapus channel 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 disuntikkan 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 channel 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.

Menghapus channel tambahan

Setelah memverifikasi bahwa semua workload Anda berjalan di satu channel, Anda dapat menghapus channel tambahan yang tidak digunakan. Jika ketiga saluran rilis telah 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/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 teratas telah dihentikan 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 Wajib

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

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 di 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 operasi yang berhasil dari 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 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 tingkat 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, izin tambahan diperlukan 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 terpengaruh jika:

Cluster GKE Anda berada di project layanan.
Cluster ini menggunakan jaringan VPC Bersama yang dihosting dalam project lain (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 armada Anda. Untuk mengetahui detail selengkapnya tentang cara memahami dan menyelesaikan masalah ini, termasuk opsi yang dikelola sistem dan dikelola pengguna, lihat Memahami pemeriksaan kondisi.

Konfigurasi Bidang Kontrol Tidak Ada

Praktik terbaik Cloud Service Mesh untuk mengelola mesh layanan menggunakan Google Kubernetes Engine Fleet API untuk menyetel kolom Pengelolaan ke AUTOMATIC. Hal ini memberikan pengelolaan yang sepenuhnya otomatis untuk banyak fitur mesh seperti webhook dan bidang kontrol. Selain itu, cluster akan disiapkan 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 menambalnya.

Bagaimana cara mengetahui apakah saya terpengaruh?

Periksa apakah Anda memiliki ControlPlaneRevision di cluster Anda:

kubectl get controlplanerevisions -n istio-system

Jika Anda sudah memiliki ControlPlaneRevision di cluster, panduan ini tidak berlaku bagi 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 tindakan yang perlu dilakukan agar konfigurasi Anda sesuai dengan standar saat ini.

gcloud container fleet mesh describe --project PROJECT_ID

Lakukan langkah-langkah berikut bergantung pada output:

Output	Langkah-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)?`	Balas `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 jaring.
`... resourceState: state: ACTIVE ...`	Lanjutkan ke 2. Daftarkan cluster Anda ke Fleet.

1. Mengaktifkan fitur mesh

Fitur mesh dapat diaktifkan menggunakan perintah berikut. Tindakan ini memungkinkan Cloud Service Mesh berjalan di project Anda. Untuk mengetahui detail selengkapnya dan kemungkinan efek samping, lihat Menyediakan Service Mesh.

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 channel 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 channel, ikuti petunjuk di Memperbaiki beberapa bidang kontrol untuk mengurangi penggunaan Anda menjadi satu channel.

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 beban kerja di cluster dan memfilter output untuk menampilkan bidang kontrol dan tag injeksi yang digunakan untuk beban kerja 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 cocok dengan channel dengan cara ini. Jika ada beberapa channel yang digunakan, ikuti petunjuk di Memperbaiki beberapa bidang kontrol untuk mengurangi jumlah channel menjadi satu:

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

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

4. Buat resource ControlPlaneRevision untuk channel 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 "Nonaktifkan" di Endpoint discovery declarative API 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 Fleet-managed Cloud Service Mesh 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. Verifikasi 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 telah menyetel pengelolaan dengan benar ke MANAGEMENT_AUTOMATIC.
Setiap keanggotaan memiliki daftar kondisi status yang terkait dengannya. Pastikan tidak ada error atau peringatan di sini, dan ikuti link dokumentasi yang diberikan untuk menyelesaikan masalah.
controlPlaneManagement berisi status bidang kontrol Anda. Pastikan bidang kontrol berada dalam status ACTIVE.
dataPlaneManagement berisi status bidang data. Sebaiknya fitur ini diaktifkan.