Versi 1.20

Versi yang tersedia

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

219}

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyediakan Cloud Service Mesh yang terkelola dengan asmcli

Ringkasan

Managed Cloud Service Mesh dengan asmcli adalah bidang kontrol terkelola dan bidang data terkelola yang mudah dikonfigurasi. Google menangani keandalannya, upgrade, penskalaan, dan keamanan untuk Anda dengan cara yang kompatibel dengan versi sebelumnya. Ini panduan ini menjelaskan cara menyiapkan atau memigrasikan aplikasi ke Cloud Service Mesh terkelola dalam konfigurasi tunggal atau multi-cluster dengan asmcli.

Untuk mempelajari fitur yang didukung dan batasan Cloud Service Mesh terkelola, lihat Fitur yang didukung Managed Cloud Service Mesh.

Prasyarat

Sebagai titik awal, panduan ini mengasumsikan bahwa Anda telah:

Project Cloud
Akun Penagihan Cloud
Memperoleh izin yang diperlukan untuk menyediakan Cloud Service Mesh
Alat penginstalan asmcli, kpt, dan alat yang ditentukan dalam Menginstal alat yang diperlukan

Untuk penyediaan yang lebih cepat, cluster Anda harus memiliki Identitas Beban Kerja mengaktifkan pembuatan versi. Jika Workload Identity tidak diaktifkan, penyediaan akan mengaktifkannya secara otomatis.

Persyaratan

Satu atau beberapa klaster dengan versi GKE yang didukung, di salah satu region yang didukung.
Pastikan bahwa cluster Anda memiliki kapasitas yang cukup untuk komponen yang diperlukan yang penginstalan Cloud Service Mesh terkelola di cluster.
- Deployment mdp-controller di CPU permintaan namespace kube-system: 50m, memori: 128Mi.
- Daemonset istio-cni-node dalam namespace kube-system meminta cpu: 100m, memori: 100Mi di setiap node.
Pastikan kebijakan organisasi constraints/compute.disableInternetNetworkEndpointGroup dinonaktifkan. Jika kebijakan ini disetel ke aktif, ServiceEntry mungkin tidak berfungsi.
Pastikan komputer klien tempat Anda menyediakan Cloud Service Mesh terkelola konektivitas jaringan ke server API.
Cluster Anda harus terdaftar ke fleet. Langkah ini dapat dilakukan secara terpisah sebelum penyediaan atau sebagai bagian dari penyediaan dengan meneruskan tanda --enable-registration dan --fleet-id.
Project Anda harus mengaktifkan fitur fleet Service Mesh. Anda dapat mengaktifkannya sebagai bagian dari penyediaan dengan meneruskan --enable-gcp-components, atau dengan menjalankan perintah berikut:
```
gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
```
dengan FLEET_PROJECT_ID adalah project-id dari project host fleet.
Autopilot GKE hanya didukung pada versi GKE 1.21.3+.
Cloud Service Mesh dapat menggunakan beberapa cluster GKE lingkungan jaringan tunggal project-tunggal atau lingkungan jaringan tunggal multi-project lingkungan fleksibel App Engine.
- Jika Anda bergabung dengan cluster yang tidak berada dalam project yang sama, cluster tersebut harus terdaftar di project host perangkat, dan cluster harus berada di VPC bersama konfigurasi bersama di jaringan yang sama.
- Untuk lingkungan multi-cluster project tunggal, project fleet dapat berupa sama dengan project cluster. Untuk informasi selengkapnya tentang armada, lihat Ringkasan Armada.
- Untuk lingkungan multi-project, sebaiknya Anda menghosting fleet dalam project terpisah dari project cluster. Jika organisasi Anda konfigurasi yang ada dan kebijakan yang ada mengizinkannya, sebaiknya Anda menggunakan project VPC bersama sebagai project host fleet. Untuk informasi selengkapnya, lihat Menyiapkan cluster dengan VPC Bersama.
- Jika organisasi Anda menggunakan Kontrol Layanan VPC dan Anda melakukan penyediaan Cloud Service Mesh di cluster GKE dengan rilis lebih besar atau sama dengan 1.22.1-gke.10, maka Anda mungkin perlu mengambil langkah konfigurasi:
  - Jika Anda menyediakan Cloud Service Mesh pada reguler atau stabil saluran rilis, lalu Anda harus menggunakan flag --use-vpcsc tambahan saat menerapkan bidang kontrol yang terkelola Panduan Kontrol Layanan VPC (pratinjau). Jika tidak, penyediaan akan gagal dalam kontrol keamanan.
  - Jika Anda menyediakan Cloud Service Mesh pada rapid saluran rilis, lalu Anda tidak perlu menggunakan flag --use-vpcsc tambahan saat menerapkan bidang kontrol terkelola, tetapi Anda harus mengikuti Panduan Kontrol Layanan VPC (GA).

Peran yang diperlukan untuk menginstal Cloud Service Mesh

Tabel berikut menjelaskan peran yang diperlukan untuk menginstal aplikasi terkelola dan Cloud Service Mesh.

Nama peran	ID Peran	Berikan lokasi	Deskripsi
GKE Hub Admin	roles/gkehub.admin	Project fleet	Akses penuh ke GKE Hubs dan resource terkait.
Service Usage Admin	roles/serviceusage.serviceUsageAdmin	Project fleet	Kemampuan untuk mengaktifkan, menonaktifkan, dan memeriksa status layanan, memeriksa operasional, dan menghabiskan kuota dan penagihan untuk project konsumen. ^{(Catatan 1)}
Admin Layanan CA ^Beta	roles/privateca.admin	Project fleet	Akses penuh ke semua resource CA Service. ^{(Catatan 2)}

Batasan

Sebaiknya Anda meninjau daftar Fitur dan batasan yang didukung Cloud Service Mesh. Secara khusus, perhatikan hal-hal berikut:

IstioOperator API tidak didukung karena tujuan utamanya adalah untuk mengontrol komponen dalam cluster.

Catatan: Anda tetap dapat mengaktifkan fitur opsional tanpa menggunakan IstioOperator API. lihat Mengaktifkan fitur opsional pada Cloud Service Mesh terkelola. Anda juga dapat menggunakan alat migrasi yang disertakan dengan asmcli untuk secara otomatis mengonversi fitur opsional IstioOperator lainnya agar kompatibel dengan dalam bidang kontrol terkelola. Untuk informasi selengkapnya, lihat Bermigrasi dari IstioOperator.
Untuk cluster GKE Autopilot, penyiapan lintas project hanya didukung dengan GKE 1.23 atau yang lebih baru.
Untuk cluster Autopilot GKE, agar dapat beradaptasi dengan Batas resource Autopilot GKE, batas dan permintaan resource proxy default diatur ke 500 m CPU dan 512 Mb memori. Anda dapat mengganti nilai {i>default<i} menggunakan injeksi kustom.
Selama proses penyediaan untuk bidang kontrol yang terkelola, Istio CRD yang disediakan di cluster yang ditentukan. Jika sudah ada CRD Istio di bagian cluster, mereka akan ditimpa
CNI Istio dan Cloud Service Mesh tidak kompatibel dengan GKE Sandbox. Oleh karena itu, Cloud Service Mesh terkelola dengan implementasi TRAFFIC_DIRECTOR melakukan tidak mendukung cluster dengan GKE Sandbox aktif.
Alat asmcli harus memiliki akses ke endpoint Google Kubernetes Engine (GKE). Anda dapat mengonfigurasi akses melalui "lompat" server web, seperti VM Compute Engine dalam Virtual Private Cloud (VPC) yang memberikan akses.

Sebelum memulai

Mengonfigurasi gcloud

Selesaikan langkah-langkah berikut meskipun Anda menggunakan Cloud Shell.

Melakukan autentikasi dengan Google Cloud CLI:
```
gcloud auth login --project PROJECT_ID
```
dengan PROJECT_ID sebagai ID unik project cluster Anda. Jalankan perintah berikut untuk mendapatkan PROJECT_ID Anda:
```
   gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```
```
Update komponen:
```
gcloud components update
```

Konfigurasi kubectl agar mengarah ke cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

Mendownload alat penginstalan

Download versi alat terbaru ke direktori kerja saat ini:

curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

Jadikan alat ini dapat dieksekusi:
```
chmod +x asmcli
```

Mengonfigurasi setiap cluster

Gunakan langkah-langkah berikut untuk mengonfigurasi Cloud Service Mesh terkelola untuk setiap cluster di mesh Anda.

Menerapkan bidang kontrol terkelola

Sebelum menerapkan bidang kontrol terkelola, Anda harus memilih saluran rilis. Saluran Cloud Service Mesh Anda ditentukan oleh saluran cluster GKE Anda di waktu penyediaan Cloud Service Mesh terkelola. Perhatikan bahwa beberapa saluran dalam cluster yang sama dan waktu yang sama tidak didukung.

Jalankan alat penginstalan untuk setiap cluster yang akan menggunakan Cloud Service Mesh terkelola. Sebaiknya Anda menyertakan kedua opsi berikut:

--enable-registration --fleet_id FLEET_PROJECT_ID Kedua flag ini mendaftarkan cluster ke fleet, tempat FLEET_ID adalah project-id project host fleet. Jika menggunakan project tunggal, FLEET_PROJECT_ID sama dengan PROJECT_ID, fleet project host dan project cluster sama. Dalam lebih kompleks seperti multi-project, sebaiknya gunakan host fleet yang terpisah proyek.
--enable-all. Penanda ini mengaktifkan komponen dan pendaftaran yang diperlukan.

Alat asmcli mengonfigurasi bidang kontrol terkelola secara langsung menggunakan alat dan logika di dalam alat CLI. Gunakan rangkaian petunjuk di bawah ini bergantung pada CA pilihan Anda.

Otoritas Sertifikat

Pilih Certificate Authority yang akan digunakan untuk mesh Anda.

Jaring CA

Jalankan perintah berikut untuk menginstal bidang kontrol dengan fitur default dan Mesh CA. Masukkan nilai Anda di placeholder yang disediakan.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

CA Service

Ikuti langkah-langkah di Mengonfigurasi Certificate Authority Service.
Jalankan perintah berikut untuk menginstal bidang kontrol dengan default fitur dan Certificate Authority Service. Masukkan nilai Anda di placeholder yang disediakan.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

Alat ini mendownload semua file untuk mengonfigurasi bidang kontrol terkelola ke --output_dir yang ditentukan, menginstal alat dan contoh istioctl menggunakan berbagai aplikasi obrolan. Langkah-langkah dalam panduan ini mengasumsikan bahwa Anda menjalankan istioctl dari --output_dir lokasi yang Anda tetapkan saat menjalankan asmcli install, dengan istioctl ada di subdirektori <Istio release dir>/bin-nya.

Jika Anda menjalankan kembali asmcli di cluster yang sama, cluster tersebut akan menimpa konfigurasi bidang kontrol yang ada. Pastikan untuk menentukan opsi dan jika Anda menginginkan konfigurasi yang sama.

Memverifikasi bahwa bidang kontrol telah disediakan

Setelah beberapa menit, verifikasi bahwa status bidang kontrol adalah ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Outputnya mirip dengan:

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Jika statusnya tidak sampai ACTIVE` dalam beberapa menit, lihat Memeriksa status bidang kontrol terkelola untuk informasi selengkapnya tentang error yang mungkin terjadi.

Upgrade zero-touch

Setelah bidang kontrol terkelola diinstal, Google akan mengupgrade secara otomatis ketika rilis atau {i>patch<i} baru tersedia.

Bidang data terkelola

Jika Anda menggunakan Cloud Service Mesh terkelola, Google akan mengelola sepenuhnya upgrade proxy Anda. kecuali jika Anda menonaktifkannya.

Dengan bidang data terkelola, {i>proxy<i} file bantuan dan {i>gateway<i} yang dimasukkan secara otomatis diperbarui bersamaan dengan bidang kontrol yang dikelola oleh memulai ulang beban kerja untuk memasukkan ulang versi baru proxy. Hal ini biasanya selesai 1-2 minggu setelah bidang kontrol terkelola diupgrade.

Jika dinonaktifkan, pengelolaan proxy akan dijalankan berdasarkan siklus proses alami dari pod dalam cluster dan harus dipicu secara manual oleh pengguna untuk mengontrol update besar.

Bidang data terkelola mengupgrade proxy dengan mengeluarkan pod yang berjalan {i>proxy<i} versi sebelumnya. Penggusuran tersebut dilakukan secara bertahap, untuk menghormati anggaran gangguan pod dan mengendalikan tingkat perubahan.

Bidang data terkelola tidak mengelola hal berikut:

Pod yang tidak dimasukkan
Pod yang dimasukkan secara manual
Pekerjaan
StatefulSet
DaemonSet

Jika telah menyediakan Cloud Service Mesh terkelola pada cluster yang lebih lama, Anda dapat mengaktifkan pengelolaan bidang data untuk seluruh cluster:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

Atau, Anda dapat mengaktifkan bidang data terkelola secara selektif untuk revisi bidang kontrol, namespace, atau pod tertentu dengan memberi anotasi anotasi yang sama. Jika Anda mengontrol masing-masing komponen secara selektif, urutan prioritasnya adalah revisi bidang kontrol, lalu namespace, kemudian pod.

Diperlukan waktu hingga sepuluh menit agar layanan siap mengelola menggunakan beberapa proxy di cluster. Jalankan perintah berikut untuk memeriksa status:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Output yang diharapkan

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Jika layanan tidak siap dalam waktu sepuluh menit, lihat Status bidang data terkelola untuk mengetahui langkah selanjutnya.

Menonaktifkan bidang data terkelola (opsional)

Jika menyediakan Cloud Service Mesh terkelola pada cluster baru, Anda dapat menonaktifkan bidang data terkelola sepenuhnya, atau untuk namespace atau pod individual. Bidang data terkelola akan terus dinonaktifkan untuk cluster yang ada dengan dinonaktifkan secara {i> default<i} atau secara manual.

Untuk menonaktifkan bidang data terkelola pada tingkat cluster dan kembali ke mengelola proxy file bantuan sendiri, ubah anotasi:

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Cara menonaktifkan bidang data terkelola untuk namespace:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Untuk menonaktifkan bidang data terkelola untuk pod:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Aktifkan notifikasi pemeliharaan

Anda dapat meminta untuk diberi tahu tentang pemeliharaan pesawat data terkelola mendatang hingga seminggu sebelum pemeliharaan dijadwalkan. Notifikasi pemeliharaan tidak dikirim secara {i>default<i}. Anda juga harus Mengonfigurasi masa pemeliharaan GKE sebelum Anda dapat menerima notifikasi. Jika diaktifkan, notifikasi akan dikirim pada setidaknya dua hari sebelum operasi upgrade.

Untuk memilih ikut serta dalam notifikasi pemeliharaan bidang data terkelola:

Buka halaman Komunikasi.

Buka halaman Komunikasi
Di baris Cloud Service Mesh Upgrade, pada kolom Email, pilih untuk MENGAKTIFKAN notifikasi pemeliharaan.

Setiap pengguna yang ingin menerima notifikasi harus memilih ikut serta secara terpisah. Jika Anda ingin untuk menyetel filter email bagi notifikasi ini, baris subjeknya adalah:

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME".

Contoh berikut menunjukkan pemeliharaan bidang data terkelola standar notifikasi:

Subject Line: Upgrade mendatang untuk cluster Cloud Service Mesh Anda "<location/cluster-name>"

Pengguna Cloud Service Mesh yang terhormat,

Komponen Cloud Service Mesh dalam cluster Anda ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) dijadwalkan untuk diupgrade pada ${scheduled_date_human_readable} pada ${scheduled_time_human_readable}.

Anda dapat memeriksa catatan rilis (https://cloud.google.com/service-mesh/docs/release-notes) untuk mempelajari update baru ini.

Jika pemeliharaan ini dibatalkan, Anda akan menerima email baru.

Hormat kami,

Tim Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Kami mengirimkan pengumuman ini untuk memberi tahu Anda mengenai perubahan penting pada Google Cloud Platform atau akun Anda. Anda dapat memilih untuk tidak menerima notifikasi masa pemeliharaan dengan mengedit preferensi pengguna: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Mengonfigurasi penemuan endpoint (hanya untuk penginstalan multi-cluster)

Jika mesh Anda hanya memiliki satu cluster, lewati langkah multi-cluster ini dan lanjutkan ke Deploy aplikasi atau Memigrasikan aplikasi.

Sebelum melanjutkan, pastikan bahwa Cloud Service Mesh dikonfigurasi pada .

Cluster publik

Mengonfigurasi penemuan endpoint di antara cluster publik

Jika Anda beroperasi pada klaster publik (klaster non-pribadi), Anda dapat Mengonfigurasi penemuan endpoint di antara cluster publik atau lebih sederhana Mengaktifkan penemuan endpoint di antara cluster publik.

Cluster pribadi

Mengonfigurasi penemuan endpoint di antara cluster pribadi

Saat menggunakan cluster pribadi GKE, Anda harus mengonfigurasi endpoint bidang kontrol cluster menjadi titik akhir publik, bukan titik akhir pribadi. Lihat Mengonfigurasi penemuan endpoint di antara cluster pribadi.

Untuk aplikasi contoh dengan dua cluster, lihat Contoh layanan HelloWorld.

Men-deploy aplikasi

Mengaktifkan namespace untuk injeksi. Langkah-langkah bergantung pada penerapan bidang kontrol Anda.

Terkelola (TD)

Terapkan label injeksi default ke namespace:

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

Terkelola (Istiod)

Direkomendasikan: Jalankan perintah berikut untuk menerapkan injeksi default label ke namespace:

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

Jika Anda sudah menjadi pengguna dengan bidang kontrol Istio Terkelola: Kami menyarankan agar Anda menggunakan injeksi default, tetapi injeksi berbasis revisi didukung. Gunakan petunjuk berikut:

Jalankan perintah berikut untuk menemukan saluran rilis yang tersedia:
```
kubectl -n istio-system get controlplanerevision
```
Outputnya mirip dengan hal berikut ini:
```
NAME                AGE
asm-managed-rapid   6d7h
```
CATATAN: Jika dua revisi bidang kontrol muncul dalam daftar di atas, hapus salah satu. Memiliki beberapa saluran bidang kontrol dalam cluster tidak didukung.

Pada output, nilai pada kolom NAME adalah label revisi yang sesuai dengan saluran rilis yang tersedia untuk versi Cloud Service Mesh.

Terapkan label revisi ke namespace:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Pada tahap ini, Anda telah berhasil mengonfigurasi Cloud Service Mesh terkelola. Jika Anda memiliki beban kerja yang ada di namespace berlabel, kemudian memulai ulang beban kerja tersebut {i>proxy<i} yang dimasukkan.

Jika Anda men-deploy aplikasi dalam penyiapan multi-cluster, replikasikan Kubernetes dan konfigurasi bidang kontrol di semua cluster, kecuali Anda berencana untuk membatasi konfigurasi tertentu tersebut ke subset dari cluster. Tujuan konfigurasi yang diterapkan ke cluster tertentu adalah sumber kebenaran untuk itu .

Sesuaikan injeksi (opsional)

Anda dapat mengganti nilai default dan menyesuaikan setelan injeksi, tetapi ini juga dapat menyebabkan error konfigurasi yang tidak terduga dan masalah file bantuan container. Sebelum menyesuaikan injeksi, baca informasi setelah contoh untuk catatan tentang pengaturan dan rekomendasi tertentu.

Konfigurasi per pod tersedia untuk mengganti opsi ini di tiap pod. Hal ini dilakukan dengan menambahkan container istio-proxy ke pod Anda. File bantuan injeksi ini akan memperlakukan konfigurasi apa pun yang didefinisikan di sini sebagai penggantian terhadap template injeksi default.

Misalnya, konfigurasi berikut menyesuaikan berbagai pengaturan, termasuk menurunkan permintaan CPU, menambahkan pemasangan volume, dan Hook preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

Secara umum, kolom apa pun dalam pod dapat ditetapkan. Namun, Anda harus berhati-hati saat {i>field<i} tertentu:

Kubernetes mengharuskan kolom image ditetapkan sebelum injeksi berjalan. Meskipun Anda dapat menetapkan gambar tertentu untuk menggantikan gambar default, sebaiknya Anda menyetel image ke auto, yang akan menyebabkan injektor file bantuan untuk otomatis memilih gambar yang akan digunakan.
Beberapa kolom di containers bergantung pada setelan terkait. Misalnya, harus kurang dari atau sama dengan batas CPU. Jika kedua {i>field<i} tidak benar terkonfigurasi, pod dapat gagal untuk dimulai.
Kubernetes memungkinkan Anda menetapkan requests dan limits untuk resource di Pod spec. Autopilot GKE hanya mempertimbangkan requests. Untuk selengkapnya informasi selengkapnya, lihat Menyetel batas resource di Autopilot.

Selain itu, beberapa kolom tertentu dapat dikonfigurasi berdasarkan anotasi di Pod, meskipun disarankan untuk menggunakan pendekatan di atas untuk menyesuaikan setelan. Berikan perhatian tambahan untuk anotasi berikut:

Untuk GKE Standard, jika sidecar.istio.io/proxyCPU disetel, pastikan pastikan untuk menyetel sidecar.istio.io/proxyCPULimit secara eksplisit. Jika tidak, file bantuan Batas CPU akan ditetapkan sebagai tidak terbatas.
Untuk GKE Standard, jika sidecar.istio.io/proxyMemory disetel, pastikan untuk menetapkan sidecar.istio.io/proxyMemoryLimit secara eksplisit. Jika tidak, batas memori file bantuan akan ditetapkan sebagai tidak terbatas.
Untuk Autopilot GKE, mengonfigurasi resource requests dan limits penggunaan anotasi dapat menyediakan sumber daya secara berlebihan. Menggunakan pendekatan template gambar sebaiknya dihindari. Lihat Contoh modifikasi resource di Autopilot.

Misalnya, lihat anotasi resource di bawah:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Memverifikasi metrik bidang kontrol

Anda dapat melihat versi bidang kontrol dan bidang data di Metrics Explorer.

Untuk memverifikasi bahwa konfigurasi Anda berfungsi seperti yang diharapkan:

Di konsol Google Cloud, lihat metrik bidang kontrol:

Buka Metrics Explorer
Pilih ruang kerja Anda dan tambahkan kueri kustom menggunakan parameter berikut:
- Jenis resource: Container Kubernetes
- Metrik: Klien Proxy
- Filter: container_name="cr-REVISION_LABEL"
- Kelompokkan Menurut: label revision dan label proxy_version
- Agregator: sum
- Periode: 1 menit
Saat Anda menjalankan Cloud Service Mesh dengan bidang kontrol yang dikelola Google dan dalam cluster, Anda dapat membedakan metrik berdasarkan nama container-nya. Misalnya, layanan terkelola metrik memiliki container_name="cr-asm-managed", sedangkan metrik yang tidak dikelola memiliki container_name="discovery". Untuk menampilkan metrik dari keduanya, hapus Filter pada container_name="cr-asm-managed".
Verifikasi versi bidang kontrol dan versi proxy dengan memeriksa kolom berikut di Metrics Explorer:
- Kolom revision menunjukkan versi bidang kontrol.
- Kolom proxy_version menunjukkan proxy_version.
- Kolom value menunjukkan jumlah proxy yang terhubung.
Untuk pemetaan versi saluran ke Cloud Service Mesh saat ini, lihat Versi Cloud Service Mesh per saluran.

Memigrasikan aplikasi ke Mesh Layanan Cloud terkelola

Mempersiapkan untuk migrasi

Untuk menyiapkan migrasi aplikasi dari Cloud Service Mesh dalam cluster ke terkelola Cloud Service Mesh, lakukan langkah-langkah berikut:

Jalankan alat seperti yang ditunjukkan di bagian Menerapkan bidang kontrol yang dikelola Google.

(Opsional) Jika Anda ingin menggunakan bidang data yang dikelola Google, aktifkan data manajemen pesawat:

  kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Memigrasikan aplikasi

Untuk memigrasikan aplikasi dari Cloud Service Mesh dalam cluster ke Cloud Service Mesh terkelola, lakukan langkah-langkah berikut:

Ganti label namespace saat ini. Langkah-langkah bergantung pada penerapan bidang kontrol Anda.

Terkelola (TD)

Terapkan label injeksi default ke namespace:

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

Terkelola (Istiod)

Direkomendasikan: Jalankan perintah berikut untuk menerapkan injeksi default label ke namespace:

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

Jika Anda sudah menjadi pengguna dengan bidang kontrol Istio Terkelola: Kami menyarankan agar Anda menggunakan injeksi default, tetapi injeksi berbasis revisi didukung. Gunakan petunjuk berikut:

Jalankan perintah berikut untuk menemukan saluran rilis yang tersedia:
```
kubectl -n istio-system get controlplanerevision
```
Outputnya mirip dengan hal berikut ini:
```
NAME                AGE
asm-managed-rapid   6d7h
```
CATATAN: Jika dua revisi bidang kontrol muncul dalam daftar di atas, hapus salah satu. Memiliki beberapa saluran bidang kontrol dalam cluster tidak didukung.

Pada output, nilai pada kolom NAME adalah label revisi yang sesuai dengan saluran rilis yang tersedia untuk versi Cloud Service Mesh.

Terapkan label revisi ke namespace:

kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Lakukan upgrade berkelanjutan untuk deployment di namespace:
```
kubectl rollout restart deployment -n NAMESPACE
```
Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.
Jika Anda memiliki beban kerja di namespace lain, ulangi langkah-langkah sebelumnya untuk setiap namespace.
Jika Anda men-deploy aplikasi dalam penyiapan multi-cluster, replikasikan Konfigurasi Kubernetes dan Istio di semua cluster, kecuali jika ada keinginan untuk membatasi konfigurasi itu pada {i>subset<i} saja. Tujuan konfigurasi yang diterapkan pada cluster tertentu adalah sumber kebenaran untuk gugus itu.

Jika puas karena aplikasi Anda berfungsi seperti yang diharapkan, Anda dapat menghapus dalam cluster istiod setelah Anda mengalihkan semua namespace ke kontrol terkelola bidang, atau menyimpannya sebagai cadangan - istiod akan otomatis menurunkan skala untuk digunakan lebih sedikit sumber daya. Untuk menghapus, langsung ke Hapus bidang kontrol lama.

Jika Anda mengalami masalah, Anda dapat mengidentifikasi dan menyelesaikannya dengan menggunakan informasi di Menyelesaikan masalah bidang kontrol terkelola dan jika perlu, kembalikan ke versi sebelumnya.

Hapus bidang kontrol lama

Setelah Anda menginstal dan mengonfirmasi bahwa semua namespace menggunakan kontrol yang dikelola Google bidang kontrol yang lama, Anda dapat menghapus bidang kontrol yang lama.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Jika Anda menggunakan istioctl kube-inject, bukan injeksi otomatis, atau jika Anda menginstal {i>gateway<i} tambahan, periksa metrik untuk bidang kontrol, dan memverifikasi bahwa jumlah endpoint yang terhubung adalah nol.

Kembalikan

Lakukan langkah-langkah berikut jika Anda perlu melakukan rollback ke kontrol sebelumnya versi bidang:

Mengupdate beban kerja untuk dimasukkan dengan versi sebelumnya bidang kontrol. Dalam perintah berikut, nilai revisi asm-191-1 adalah hanya digunakan sebagai contoh. Ganti contoh nilai dengan label revisi bidang kontrol Anda sebelumnya.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Mulai ulang Pod untuk memicu injeksi ulang sehingga proxy memiliki versi sebelumnya:
```
kubectl rollout restart deployment -n NAMESPACE
```

Bidang kontrol yang dikelola akan otomatis diskalakan ke nol dan tidak menggunakan resource saat tidak digunakan. Webhook dan penyediaan yang bermutasi akan tetap ada dan tidak memengaruhi perilaku cluster.

Gateway sekarang disetel ke revisi asm-managed. Untuk melakukan roll back, jalankan kembali perintah instal Mesh Layanan Cloud, yang akan men-deploy ulang gateway ke bidang kontrol dalam cluster Anda:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Output yang akan dihasilkan saat berhasil:

deployment.apps/istio-ingressgateway rolled back

Uninstal

Bidang kontrol terkelola menskalakan otomatis hingga nol saat tidak ada namespace yang menggunakannya. Sebagai langkah-langkah mendetailnya, lihat Meng-uninstal Cloud Service Mesh.

Pemecahan masalah

Untuk mengidentifikasi dan menyelesaikan masalah saat menggunakan bidang kontrol terkelola, lihat Menyelesaikan masalah bidang kontrol terkelola.

Apa langkah selanjutnya?

Pelajari saluran rilis.
Bermigrasi dari IstioOperator.
Memigrasikan gateway ke bidang kontrol terkelola.
Pelajari cara Aktifkan fitur Cloud Service Mesh terkelola opsional, seperti: