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

Halaman ini diterjemahkan oleh Cloud Translation API.

Menyediakan Cloud Service Mesh terkelola dengan asmcli

Ringkasan

Managed Cloud Service Mesh dengan asmcli adalah bidang kontrol terkelola dan bidang data terkelola yang dapat Anda konfigurasi dengan mudah. Google menangani keandalan, upgrade, penskalaan, dan keamanan bidang tersebut untuk Anda dengan cara yang kompatibel mundur. Panduan ini menjelaskan cara menyiapkan atau memigrasikan aplikasi ke Managed Cloud Service Mesh dalam konfigurasi cluster tunggal atau multi-cluster dengan asmcli.

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

Prasyarat

Sebagai titik awal, panduan ini mengasumsikan bahwa Anda telah:

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

Untuk penyediaan yang lebih cepat, cluster Anda harus mengaktifkan Workload Identity. Jika Workload Identity tidak diaktifkan, penyediaan akan mengaktifkannya secara otomatis.

Persyaratan

Satu atau beberapa cluster dengan versi GKE yang didukung, di salah satu region yang didukung.
Perhatikan bahwa Managed Cloud Service Mesh menggunakan saluran rilis GKE untuk menyeimbangkan antara stabilitas dan kecepatan upgrade. Perubahan baru pada komponen dalam cluster Cloud Service Mesh (termasuk CNI, MDPC, proxy, dan CRD Istio) akan diluncurkan terlebih dahulu ke cluster yang berlangganan saluran cepat GKE. Kemudian, versi tersebut akan dipromosikan ke saluran reguler GKE, dan akhirnya ke saluran stabil GKE, setelah menunjukkan stabilitas yang memadai.
- Managed Cloud Service Mesh tidak mendukung perubahan saluran rilis GKE dengan aman.
- Jika Anda mengubah saluran rilis GKE, Cloud Service Mesh akan otomatis mengupgrade/mendowngrade komponen dalam cluster (CNI, MDPC, versi proxy yang disuntikkan default, dan CRD Istio) agar sesuai dengan saluran rilis GKE saat ini.
Pastikan cluster Anda memiliki kapasitas yang cukup untuk komponen yang diperlukan yang diinstal Managed Cloud Service Mesh di cluster.
- Deployment mdp-controller di namespace kube-system meminta cpu: 50m, memory: 128Mi.
- Daemonset istio-cni-node di namespace kube-system meminta cpu: 100m, memory: 100Mi di setiap node.
Pastikan kebijakan organisasi constraints/compute.disableInternetNetworkEndpointGroup dinonaktifkan. Jika kebijakan diaktifkan, ServiceEntry mungkin tidak berfungsi.
Pastikan mesin klien tempat Anda menyediakan Cloud Service Mesh terkelola memiliki 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 project host fleet.
GKE Autopilot hanya didukung dengan GKE versi 1.21.3+.
Cloud Service Mesh dapat menggunakan beberapa cluster GKE dalam lingkungan satu project satu jaringan atau lingkungan multi-project satu jaringan.
- Jika Anda menggabungkan cluster yang tidak berada dalam project yang sama, cluster tersebut harus didaftarkan ke project host fleet yang sama, dan cluster harus berada dalam konfigurasi VPC bersama bersama di jaringan yang sama.
- Untuk lingkungan multi-cluster project tunggal, project fleet dapat sama dengan project cluster. Untuk mengetahui informasi selengkapnya tentang fleet, lihat Ringkasan Fleet.
- Untuk lingkungan multi-project, sebaiknya host fleet di project terpisah dari project cluster. Jika kebijakan organisasi dan konfigurasi yang ada mengizinkannya, sebaiknya gunakan project VPC bersama sebagai project host fleet. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan cluster dengan VPC Bersama.
- Jika organisasi Anda menggunakan Kontrol Layanan VPC dan Anda menyediakan Cloud Service Mesh di cluster GKE dengan rilis yang lebih besar atau sama dengan 1.22.1-gke.10, Anda mungkin perlu melakukan langkah-langkah konfigurasi tambahan:
  - Jika Anda menyediakan Cloud Service Mesh di channel rilis reguler atau stabil , maka Anda harus menggunakan flag --use-vpcsc tambahan saat menerapkan managed control plane dan mengikuti panduan Kontrol Layanan VPC (pratinjau). Jika tidak, penyediaan akan gagal dalam kontrol keamanan.
  - Jika Anda menyediakan Cloud Service Mesh di rapid channel rilis, maka 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 Managed Cloud Service Mesh.

Nama peran	ID Peran	Memberikan akses 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 pengoperasian, serta menggunakan kuota dan penagihan untuk project konsumen. ^{(Catatan 1)}
CA Service Admin ^Beta	roles/privateca.admin	Project fleet	Akses penuh ke semua resource CA Service. ^{(Catatan 2)}

Peran yang diperlukan untuk menjalankan Cloud Service Mesh

Tabel berikut menjelaskan peran yang diperlukan oleh akun layanan untuk menjalankan Cloud Service Mesh terkelola. Jika project jaringan atau cluster Anda berbeda dari project host fleet, Anda harus memberikan akses ke peran ini di project lain kepada akun layanan di project fleet.

Nama peran	ID Peran	Memberikan akses lokasi	Deskripsi
Anthos Service Mesh Service Agent	roles/anthosservicemesh.serviceAgent	Project fleet
Mesh Managed Control Plane Service Agent (lama)	roles/meshcontrolplane.serviceAgent	Project fleet	Ini adalah peran lama yang merupakan bagian dari penginstalan Cloud Service Mesh yang lebih lama. Jika penginstalan Anda memiliki peran layanan ini, Anda dapat membiarkannya seperti apa adanya. Penginstalan baru tidak memerlukan peran ini.

Batasan

Sebaiknya tinjau daftar fitur dan batasan yang didukung Cloud Service Mesh. Khususnya, perhatikan hal berikut:

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

Catatan: Anda tetap dapat mengaktifkan fitur opsional tanpa menggunakan IstioOperator API, lihat Mengaktifkan fitur opsional di Cloud Service Mesh terkelola. Anda juga dapat menggunakan alat migrasi yang disertakan dengan asmcli untuk mengonversi fitur opsional IstioOperator lainnya secara otomatis agar kompatibel dengan bidang kontrol terkelola. Untuk mengetahui informasi selengkapnya, lihat Bermigrasi dari IstioOperator.
Untuk cluster Autopilot GKE, penyiapan lintas project hanya didukung dengan GKE 1.23 atau yang lebih baru.
Untuk cluster GKE Autopilot, agar dapat beradaptasi dengan batas resource GKE Autopilot, permintaan dan batas resource proxy default ditetapkan ke 500 m CPU dan 512 MB memori. Anda dapat mengganti nilai default menggunakan penyisipan kustom.
Untuk cluster GKE Autopilot, mungkin ada peringatan untuk komponen Cloud Service Mesh "DaemonSet has no nodes selected" hingga NodePool cluster diskalakan.
Selama proses penyediaan untuk bidang kontrol terkelola, CRD Istio akan disediakan di cluster yang ditentukan. Jika ada CRD Istio yang sudah ada di cluster, CRD tersebut akan ditimpa.
Istio CNI dan Cloud Service Mesh tidak kompatibel dengan GKE Sandbox. Oleh karena itu, Cloud Service Mesh terkelola dengan penerapan TRAFFIC_DIRECTOR tidak mendukung cluster dengan GKE Sandbox yang diaktifkan.
Alat asmcli harus memiliki akses ke endpoint Google Kubernetes Engine (GKE). Anda dapat mengonfigurasi akses melalui server "jump", seperti VM Compute Engine dalam Virtual Private Cloud (VPC) yang memberikan akses tertentu.

Sebelum memulai

Mengonfigurasi gcloud

Selesaikan langkah-langkah berikut meskipun Anda menggunakan Cloud Shell.

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

Konfigurasi kubectl untuk mengarah ke cluster.

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

Download alat penginstalan

Download versi terbaru alat ke direktori kerja saat ini:

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

Buat alat agar 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 pada saat penyediaan Cloud Service Mesh terkelola. Perhatikan bahwa beberapa channel dalam cluster yang sama pada saat yang sama tidak didukung.

Jalankan alat penginstalan untuk setiap cluster yang akan menggunakan Managed Cloud Service Mesh. Sebaiknya sertakan kedua opsi berikut:

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

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

Otoritas Sertifikat

Pilih Otoritas Sertifikasi yang akan digunakan untuk mesh Anda.

Mesh 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 control plane dengan fitur default 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 managed control plane ke --output_dir yang ditentukan, menginstal alat istioctl dan aplikasi contoh. Langkah-langkah dalam panduan ini mengasumsikan bahwa Anda menjalankan istioctl dari lokasi --output_dir yang Anda tentukan saat menjalankan asmcli install, dengan istioctl yang ada di subdirektori <Istio release dir>/bin-nya.

Jika Anda menjalankan ulang asmcli di cluster yang sama, konfigurasi bidang kontrol yang ada akan digantikan. Pastikan untuk menentukan opsi dan flag yang sama jika Anda menginginkan konfigurasi yang sama.

Pastikan 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 status tidak mencapai ACTIVE` dalam beberapa menit, lihat Periksa status bidang kontrol terkelola untuk mengetahui informasi selengkapnya tentang kemungkinan error.

Upgrade zero-touch

Setelah bidang kontrol terkelola diinstal, Google akan otomatis mengupgradenya saat rilis atau patch baru tersedia.

Bidang data terkelola

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

Dengan fitur bidang data terkelola diaktifkan, proxy sidecar dan gateway yang disuntikkan akan diupdate secara aktif dan otomatis bersama dengan bidang kontrol terkelola dengan memulai ulang beban kerja untuk menyuntikkan kembali versi proxy yang baru. Proses ini dimulai setelah bidang kontrol diupgrade dan biasanya selesai dalam waktu 2 minggu setelah dimulai.

Perhatikan bahwa bidang data terkelola mengandalkan saluran rilis GKE. Jika Anda mengubah saluran rilis GKE saat bidang data terkelola diaktifkan, Cloud Service Mesh terkelola akan memperbarui proxy semua workload yang ada seperti peluncuran bidang data terkelola.

Jika dinonaktifkan, pengelolaan proxy dilakukan secara pasif - didorong oleh siklus proses alami pod dalam cluster dan harus dipicu secara manual oleh pengguna untuk mengontrol kecepatan update.

Managed data plane mengupgrade proxy dengan mengeluarkan pod yang menjalankan proxy versi sebelumnya. Pengusiran dilakukan secara bertahap, dengan mematuhi anggaran gangguan pod dan mengontrol laju perubahan.

Bidang data terkelola tidak mengelola hal berikut:

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

Jika Anda telah menyediakan Cloud Service Mesh terkelola di 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 managed data plane secara selektif untuk revisi control plane, namespace, atau pod tertentu dengan memberikan anotasi yang sama. Jika Anda mengontrol setiap komponen secara selektif, maka urutan prioritasnya adalah revisi bidang kontrol, lalu namespace, lalu pod.

Mungkin perlu waktu hingga sepuluh menit agar layanan siap mengelola 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 managed data plane untuk mengetahui langkah selanjutnya.

Nonaktifkan bidang data terkelola (opsional)

Jika Anda menyediakan Cloud Service Mesh terkelola di cluster baru, Anda dapat menonaktifkan bidang data terkelola sepenuhnya, atau untuk namespace atau pod tertentu. Managed data plane akan terus dinonaktifkan untuk cluster yang ada jika dinonaktifkan secara default atau manual.

Untuk menonaktifkan bidang data terkelola di tingkat cluster dan kembali ke mengelola sendiri proxy sidecar, ubah anotasi:

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

Untuk 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"}'

Mengaktifkan masa pemeliharaan untuk bidang data terkelola

Jika Anda telah mengonfigurasi masa pemeliharaan GKE, upgrade aktif akan dimulai pada awal masa pemeliharaan berikutnya yang tersedia dan berlanjut tanpa jeda hingga semua pod terkelola telah diupdate (biasanya 12 jam). Masa pemeliharaan tidak diamati untuk peluncuran terkait CVE.

Cloud Service Mesh menggunakan periode pemeliharaan GKE untuk diselaraskan dengan GKE.

Mengaktifkan notifikasi pemeliharaan untuk bidang data terkelola

Anda dapat meminta untuk diberi tahu tentang pemeliharaan managed data plane mendatang hingga satu minggu sebelum pemeliharaan dijadwalkan. Notifikasi pemeliharaan tidak dikirim secara default. Anda juga harus Mengonfigurasi masa pemeliharaan GKE sebelum dapat menerima notifikasi. Jika diaktifkan, notifikasi akan dikirim setidaknya dua hari sebelum operasi upgrade.

Untuk mengaktifkan notifikasi pemeliharaan bidang data terkelola:

Buka halaman Komunikasi.

Buka halaman Komunikasi
Di baris Upgrade Cloud Service Mesh, di kolom Email, pilih tombol pilihan untuk mengAKTIFkan notifikasi pemeliharaan.

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

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

Contoh berikut menunjukkan notifikasi pemeliharaan bidang data terkelola yang umum:

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

Pengguna Cloud Service Mesh yang terhormat,

Komponen Cloud Service Mesh di cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) Anda dijadwalkan untuk diupgrade pada ${scheduled_date_human_readable} pukul ${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 pemberitahuan baru melalui email.

Hormat kami,

Tim Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Kami mengirim pengumuman ini untuk menginformasikan 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-langkah multi-cluster ini dan lanjutkan ke Deploy aplikasi atau Migrasikan aplikasi.

Sebelum melanjutkan, pastikan Cloud Service Mesh dikonfigurasi di setiap cluster.

Cluster publik

Mengonfigurasi penemuan endpoint antara cluster publik

Jika Anda beroperasi di cluster publik (cluster non-pribadi), Anda dapat Mengonfigurasi penemuan endpoint antar-cluster publik atau lebih sederhananya Mengaktifkan penemuan endpoint antar-cluster publik.

Cluster pribadi

Mengonfigurasi penemuan endpoint antar-cluster pribadi

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

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

Men-deploy aplikasi

Aktifkan namespace untuk injeksi. Langkah-langkahnya 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

Dikelola (Istiod)

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

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

Jika Anda adalah pengguna lama dengan Managed Istiod control plane: Sebaiknya gunakan 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 satunya. Memiliki beberapa saluran bidang kontrol di cluster tidak didukung.

Dalam output, nilai di 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

Validasi bahwa label namespace diterapkan dengan benar menggunakan perintah berikut.

  kubectl get namespace -L istio-injection

Contoh output:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

Pada tahap ini, Anda telah berhasil mengonfigurasi Cloud Service Mesh terkelola. Jika Anda memiliki workload yang ada di namespace berlabel, mulai ulang workload tersebut agar proxy disuntikkan.

Jika Anda men-deploy aplikasi dalam penyiapan multi-cluster, replikasi konfigurasi Kubernetes dan bidang kontrol di semua cluster, kecuali jika Anda berencana membatasi konfigurasi tertentu tersebut ke subset cluster. Konfigurasi yang diterapkan ke cluster tertentu adalah sumber tepercaya untuk cluster tersebut.

Menyesuaikan penyisipan (opsional)

Anda dapat mengganti nilai default dan menyesuaikan setelan injeksi, tetapi hal ini dapat menyebabkan error konfigurasi yang tidak terduga dan masalah yang dihasilkan dengan penampung sidecar. Sebelum menyesuaikan penyisipan, baca informasi setelah contoh untuk mengetahui catatan tentang setelan dan rekomendasi tertentu.

Konfigurasi per-pod tersedia untuk mengganti opsi ini di setiap pod. Hal ini dilakukan dengan menambahkan penampung istio-proxy ke pod Anda. Penyisipan sidecar akan memperlakukan konfigurasi apa pun yang ditentukan di sini sebagai penggantian template penyisipan default.

Misalnya, konfigurasi berikut menyesuaikan berbagai setelan, termasuk menurunkan permintaan CPU, menambahkan pemasangan volume, dan menambahkan 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 mengisi kolom tertentu:

Kubernetes mengharuskan kolom image ditetapkan sebelum injeksi dijalankan. Meskipun Anda dapat menetapkan gambar tertentu untuk menggantikan gambar default, sebaiknya tetapkan image ke auto, yang akan menyebabkan injektor sidecar memilih gambar yang akan digunakan secara otomatis.
Beberapa kolom di containers bergantung pada setelan terkait. Misalnya, harus kurang dari atau sama dengan batas CPU. Jika kedua kolom tidak dikonfigurasi dengan benar, pod mungkin gagal dimulai.
Kubernetes dapat Anda gunakan untuk menetapkan requests dan limits untuk resource di Pod spec. GKE Autopilot hanya mempertimbangkan requests. Untuk mengetahui informasi selengkapnya, lihat Menetapkan batas resource di Autopilot.

Selain itu, kolom tertentu dapat dikonfigurasi dengan anotasi di Pod, meskipun sebaiknya gunakan pendekatan di atas untuk menyesuaikan setelan. Berikan perhatian tambahan untuk anotasi berikut:

Untuk GKE Standard, jika sidecar.istio.io/proxyCPU ditetapkan, pastikan untuk menetapkan sidecar.istio.io/proxyCPULimit secara eksplisit. Jika tidak, batas CPU sidecar akan ditetapkan sebagai tidak terbatas.
Untuk GKE Standard, jika sidecar.istio.io/proxyMemory ditetapkan, pastikan untuk menetapkan sidecar.istio.io/proxyMemoryLimit secara eksplisit. Jika tidak, batas memori sidecar akan ditetapkan tanpa batas.
Untuk GKE Autopilot, mengonfigurasi resource requests dan limits menggunakan anotasi dapat menyebabkan penyediaan resource yang berlebihan. Gunakan pendekatan template gambar untuk menghindari hal ini. Lihat Contoh modifikasi resource di Autopilot.

Misalnya, lihat anotasi sumber di bawah ini:

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 Berdasarkan: Label revision dan label proxy_version
- Agregator: sum
- Periode: 1 menit
Saat menjalankan Cloud Service Mesh dengan bidang kontrol yang dikelola Google dan dalam cluster, Anda dapat membedakan metrik berdasarkan nama container-nya. Misalnya, metrik terkelola memiliki container_name="cr-asm-managed", sedangkan metrik tidak terkelola memiliki container_name="discovery". Untuk menampilkan metrik dari keduanya, hapus Filter di 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 Cloud Service Mesh ke saluran saat ini, lihat Versi Cloud Service Mesh per saluran.

Memigrasikan aplikasi ke Cloud Service Mesh terkelola

Mempersiapkan untuk migrasi

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

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

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

  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:

Mengganti label namespace saat ini. Langkah-langkahnya 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

Dikelola (Istiod)

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

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

Jika Anda adalah pengguna lama dengan Managed Istiod control plane: Sebaiknya gunakan 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 satunya. Memiliki beberapa saluran bidang kontrol di cluster tidak didukung.

Dalam output, nilai di 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 pada deployment di namespace:
```
kubectl rollout restart deployment -n NAMESPACE
```
Uji aplikasi Anda untuk memverifikasi bahwa workload berfungsi dengan benar.
Jika Anda memiliki workload di namespace lain, ulangi langkah-langkah sebelumnya untuk setiap namespace.
Jika Anda men-deploy aplikasi dalam penyiapan multi-cluster, replikasi konfigurasi Kubernetes dan Istio di semua cluster, kecuali jika Anda ingin membatasi konfigurasi tersebut hanya pada sebagian cluster. Konfigurasi yang diterapkan ke cluster tertentu adalah sumber tepercaya untuk cluster tersebut.

Jika Anda puas bahwa aplikasi Anda berfungsi seperti yang diharapkan, Anda dapat menghapus istiod dalam cluster setelah mengalihkan semua namespace ke bidang kontrol terkelola, atau menyimpannya sebagai cadangan - istiod akan otomatis di-downscale untuk menggunakan lebih sedikit resource. Untuk menghapus, lanjutkan ke Hapus bidang kontrol lama.

Jika mengalami masalah, Anda dapat mengidentifikasi dan menyelesaikannya menggunakan informasi dalam Menyelesaikan masalah panel kontrol terkelola dan jika perlu, melakukan roll back ke versi sebelumnya.

Hapus panel kontrol lama

Setelah menginstal dan mengonfirmasi bahwa semua namespace menggunakan bidang kontrol yang dikelola Google, Anda dapat menghapus bidang kontrol 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 gateway tambahan, periksa metrik untuk bidang kontrol, dan verifikasi bahwa jumlah endpoint yang terhubung adalah nol.

Dibatalkan

Lakukan langkah-langkah berikut jika Anda perlu melakukan roll back ke versi panel kontrol sebelumnya:

Perbarui workload yang akan disisipkan dengan versi bidang kontrol sebelumnya. Dalam perintah berikut, nilai revisi asm-191-1 hanya digunakan sebagai contoh. Ganti nilai contoh dengan label revisi bidang kontrol sebelumnya.
```
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
```
Mulai ulang Pod untuk memicu penyuntikan ulang sehingga proxy memiliki versi sebelumnya:
```
kubectl rollout restart deployment -n NAMESPACE
```

Bidang kontrol terkelola akan otomatis diskalakan ke nol dan tidak menggunakan resource apa pun saat tidak digunakan. Webhook dan penyediaan yang mengubah akan tetap ada dan tidak memengaruhi perilaku cluster.

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

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

Output ini akan muncul jika berhasil:

deployment.apps/istio-ingressgateway rolled back

Uninstal

Bidang kontrol terkelola akan melakukan penskalaan otomatis ke nol saat tidak ada namespace yang menggunakannya. Untuk langkah-langkah mendetail, lihat Menghapus instalasi 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.
Migrasi dari IstioOperator.
Memigrasikan gateway ke bidang kontrol terkelola.
Pelajari cara Mengaktifkan fitur Cloud Service Mesh terkelola opsional, seperti: