Menyediakan Anthos Service Mesh terkelola dengan asmcli

Ringkasan

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

Catatan: Sebaiknya gunakan opsi API fitur fleet untuk mengonfigurasi Anthos Service Mesh terkelola, tetapi Anda juga dapat menggunakan panduan ini untuk mengonfigurasi Anthos Service Mesh terkelola menggunakan alat asmcli.

Untuk mempelajari fitur dan batasan yang didukung Anthos Service Mesh terkelola, lihat Fitur yang didukung Anthos Service Mesh Terkelola.

Prasyarat

Sebagai titik awal, panduan ini mengasumsikan bahwa Anda telah:

• Project Cloud
• Akun Penagihan Cloud
• Memperoleh izin yang diperlukan untuk menyediakan Anthos Service Mesh terkelola
• Alat penginstalan asmcli, kpt, dan alat lain 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 otomatis mengaktifkannya.

Persyaratan

• Satu atau beberapa cluster dengan versi GKE yang didukung, di salah satu region yang didukung.
• Pastikan cluster Anda memiliki kapasitas yang cukup untuk komponen wajib yang mengelola penginstalan Anthos Service Mesh di cluster.
  • Deployment mdp-controller dalam namespace kube-system meminta CPU: 50m, memori: 128Mi.
  • Daemonset istio-cni-node dalam namespace kube-system meminta cpu: 100 m, memori: 100Mi pada setiap node.
• Pastikan komputer klien tempat Anda menyediakan Anthos Service Mesh terkelola memiliki konektivitas jaringan ke server API.
• Cluster Anda harus didaftarkan 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.

• GKE Autopilot hanya didukung dengan GKE versi 1.21.3+.

• Istio CNI diperlukan dan diinstal secara default saat menyediakan Anthos Service Mesh terkelola.

• Anthos Service Mesh terkelola dapat menggunakan beberapa cluster GKE dalam lingkungan jaringan tunggal project atau lingkungan jaringan tunggal multi-project.

  • Jika Anda bergabung dengan 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 bisa sama dengan project cluster. Untuk mengetahui informasi selengkapnya tentang fleet, lihat Ringkasan Armada.
  • Untuk lingkungan multi-project, sebaiknya Anda menghosting fleet dalam project yang terpisah dari project cluster. Jika kebijakan organisasi dan konfigurasi yang ada memungkinkan hal tersebut, 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 Anthos Service Mesh terkelola di cluster GKE, Anda juga harus mengikuti langkah-langkah di Kontrol Layanan VPC untuk Anthos Service Mesh.

Batasan

Perhatian: Perhatikan batasan khusus fleet berikut: - Semua cluster Anthos Service Mesh untuk satu mesh harus selalu didaftarkan ke fleet yang sama setiap saat agar dapat menggunakan Anthos Service Mesh. Cluster lain dalam project cluster Anthos Service Mesh tidak boleh didaftarkan ke fleet yang berbeda.

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

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

  Catatan: Anda masih dapat mengaktifkan fitur opsional tanpa menggunakan IstioOperator API. Baca Mengaktifkan fitur opsional di Anthos Service Mesh terkelola. Anda juga dapat menggunakan alat migrasi yang disertakan dengan asmcli untuk secara otomatis mengonversi fitur opsional IstioOperator lainnya agar kompatibel dengan bidang kontrol terkelola. Untuk informasi selengkapnya, lihat Bermigrasi dari IstioOperator.

• Migrasi dari Anthos Service Mesh terkelola dengan asmcli ke Anthos Service Mesh dengan fleet API tidak didukung. Demikian pula, mengonfigurasi Anthos Service Mesh terkelola dengan fleet API dari --management manual ke --management automatic tidak didukung.

• Untuk cluster GKE Autopilot, 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 memori 512 Mb. Anda dapat mengganti nilai default ini menggunakan injeksi kustom.

• Fitur sebenarnya yang tersedia untuk Anthos Service Mesh terkelola bergantung pada saluran rilis. Untuk mengetahui informasi selengkapnya, tinjau daftar lengkap fitur dan batasan yang didukung Anthos Service Mesh terkelola.

• Selama proses penyediaan untuk bidang kontrol terkelola, CRD Istio yang sesuai dengan saluran yang dipilih akan disediakan di cluster yang ditentukan. Jika ada CRD Istio yang sudah ada di cluster, CRD tersebut akan ditimpa.

• Istio CNI tidak kompatibel dengan GKE Sandbox. Oleh karena itu, Anthos Service Mesh terkelola di Autopilot, tidak berfungsi dengan GKE Sandbox karena Istio CNI terkelola diperlukan.

• 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

Peringatan: Alat GitOps (termasuk Config Sync, Argo CD, Terraform, dan Jenkins) dapat mengganggu proses penginstalan, migrasi, atau upgrade Anthos Service Mesh Anda. Untuk hasil terbaik, nonaktifkan alat GitOps Anda sebelum menginstal, memigrasikan, atau mengupgrade Anthos Service Mesh.

Mengonfigurasi gcloud

Lakukan langkah-langkah berikut meskipun Anda menggunakan Cloud Shell.

1. Lakukan autentikasi dengan Google Cloud CLI:

   gcloud auth login --project PROJECT_ID
   

2. Update komponen:

   gcloud components update
   

3. Konfigurasi kubectl agar mengarah ke cluster.

   Catatan: Gunakan --region, bukan --zone, jika cluster adalah cluster regional.

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

Mendownload alat penginstalan

Penting: Alat asmcli hanya mendukung sistem operasi Linux.

1. Download alat versi terbaru ke direktori kerja saat ini:

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

2. Jadikan alat ini dapat dieksekusi:

   chmod +x asmcli
   

Mengonfigurasi setiap cluster

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

Menerapkan bidang kontrol terkelola

Catatan: Sebagai alternatif, Anda dapat menggunakan fleet API dan gcloud, bukan asmcli, untuk menyiapkan Anthos Service Mesh terkelola. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Anthos Service Mesh terkelola dengan fleet API.

Sebelum menerapkan bidang kontrol terkelola, Anda harus memilih saluran rilis.

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

Peringatan: Opsi berikut diperlukan. Untuk daftar lengkap opsi, lihat halaman referensi asmcli.

• --enable-registration --fleet_id FLEET_PROJECT_ID Kedua flag ini mendaftarkan cluster ke fleet, dengan FLEET_ID adalah project-id dari project host fleet. Jika menggunakan satu project, FLEET_PROJECT_ID sama dengan PROJECT_ID, project host fleet dan project cluster akan sama. Dalam konfigurasi yang lebih kompleks seperti multi-project, sebaiknya gunakan project host fleet yang 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 ini, bergantung pada CA pilihan Anda.

Peringatan: Agar Anthos Service Mesh berfungsi dengan benar, Anda harus men-deploy istio-cni-node DaemonSet ke node dengan izin kontrol akses berbasis peran (RBAC) yang ditingkatkan, seperti kemampuan untuk mengubah semua deployment dan membuat configmap. Izin ini diperlukan agar istio-cni-node dapat mengelola siklus proses dan konfigurasi pod.

Certificate Authority

Pilih Certificate Authority yang akan digunakan untuk mesh Anda.

CA Mesh

Jalankan perintah berikut untuk menginstal bidang kontrol dengan fitur default dan Mesh CA. Masukkan nilai Anda di placeholder yang disediakan. Ganti RELEASE_CHANNEL dengan saluran yang sesuai: regular, stable, atau rapid.

  ./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

1. Ikuti langkah-langkah di Mengonfigurasi Certificate Authority Service.
2. Jalankan perintah berikut untuk menginstal bidang kontrol dengan fitur default dan Certificate Authority Service. Masukkan nilai Anda di placeholder yang disediakan. Ganti RELEASE_CHANNEL dengan saluran yang sesuai: regular, stable, atau rapid.

Catatan: Saat menggunakan Certificate Authority Service sebagai bagian dari mesh multi-cluster MCP, semua cluster harus memiliki rantai kumpulan CA subordinat masing-masing ke kumpulan CA root yang sama. Jika tidak, semuanya harus menggunakan kumpulan CA yang sama.

  ./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, lalu 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 kembali asmcli di cluster yang sama, konfigurasi bidang kontrol yang sudah ada akan ditimpa. Pastikan untuk menentukan opsi dan flag yang sama 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 mencapai ACTIVE` dalam beberapa menit, lihat Memeriksa 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 Anthos Service Mesh terkelola, Google akan mengelola sepenuhnya upgrade proxy Anda kecuali jika Anda menonaktifkannya di tingkat namespace, workload, atau revisi.

Dengan bidang data terkelola, proxy file bantuan dan gateway yang dimasukkan akan otomatis diupdate bersamaan dengan bidang kontrol terkelola dengan memulai ulang beban kerja untuk memasukkan ulang proxy versi baru. Proses ini biasanya selesai 1-2 minggu setelah bidang kontrol terkelola diupgrade.

Jika dinonaktifkan, pengelolaan proxy akan dijalankan oleh siklus proses alami pod di cluster dan harus dipicu secara manual oleh pengguna untuk mengontrol kecepatan update.

Bidang data terkelola mengupgrade proxy dengan mengeluarkan pod yang menjalankan versi proxy yang lebih lama. Penghapusan dilakukan secara bertahap, dengan memenuhi anggaran gangguan pod dan mengontrol laju perubahan.

Catatan: Jika cluster memiliki masa pemeliharaan GKE, penghapusan pod 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.

Bidang data terkelola tidak mengelola hal berikut:

• Pod yang tidak dimasukkan
• Pod yang dimasukkan secara manual
• Pekerjaan
• StatefulSets
• DaemonSets

Jika telah menyediakan Anthos Service Mesh terkelola di cluster 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 menganotasinya menggunakan anotasi yang sama. Jika Anda mengontrol setiap komponen secara selektif, urutan prioritasnya adalah revisi bidang kontrol, lalu namespace, lalu pod.

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

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 sepuluh menit, lihat Status bidang data terkelola untuk langkah berikutnya.

Menonaktifkan bidang data terkelola (opsional)

Jika menyediakan Anthos Service Mesh terkelola di 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, ketika dinonaktifkan secara default atau 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 \
REVISION_LABEL \
  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 sebuah 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 yang akan datang hingga seminggu 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 memilih menerima notifikasi perawatan pesawat data terkelola:

1. Buka halaman Komunikasi.

   Buka halaman Komunikasi

2. Di baris Anthos Service Mesh Upgrade, di kolom Email, pilih tombol pilihan untuk mengaktifkan notifikasi pemeliharaan ON.

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

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

Contoh berikut menunjukkan notifikasi pemeliharaan pesawat data terkelola yang umum:

Subject Line: Upgrade mendatang untuk cluster ASM "<location/cluster-name>"

Pengguna Anthos Service Mesh yang terhormat,

Komponen Anthos Service Mesh di cluster Anda ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) dijadwalkan untuk diupgrade pada ${schedule_date_human_readable} pada ${schedule_time_human_readable}.

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

Jika pemeliharaan ini dibatalkan, Anda akan menerima pemberitahuan baru melalui email.

Terima kasih,

Tim Anthos Service Mesh

(c) 2022 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Kami mengirimkan 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)

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

Sebelum melanjutkan, Anda harus sudah mengonfigurasi Anthos Service Mesh terkelola di setiap cluster seperti yang dijelaskan pada langkah sebelumnya. Tidak perlu menunjukkan bahwa cluster adalah cluster utama, ini adalah perilaku default.

Selain itu, pastikan Anda telah mendownload asmcli (hanya jika ingin memverifikasi konfigurasi dengan aplikasi contoh) serta menetapkan variabel project dan cluster.

Catatan: Untuk informasi selengkapnya tentang penemuan endpoint, lihat Penemuan endpoint dengan beberapa bidang kontrol.

Cluster publik

Mengonfigurasi penemuan endpoint di antara cluster publik

Jika Anda beroperasi di cluster publik (cluster non-pribadi), Anda dapat Mengonfigurasi penemuan endpoint antara cluster publik atau lebih sederhana Mengaktifkan penemuan endpoint 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 endpoint publik, bukan endpoint pribadi. Lihat Mengonfigurasi penemuan endpoint di antara cluster pribadi.

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

Catatan: Contoh layanan HelloWorld menggunakan Docker Hub. Di cluster pribadi, runtime container dapat mengambil image container dari Artifact Registry secara default. Runtime container tidak dapat mengambil image dari registry image container lain di internet. Anda dapat mendownload image dan mengirim file ke Artifact Registry atau menggunakan Cloud NAT untuk menyediakan akses internet keluar untuk node pribadi tertentu. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan container eksternal dan Membuat cluster pribadi.

Men-deploy aplikasi

Untuk men-deploy aplikasi, gunakan label yang sesuai dengan saluran yang Anda konfigurasi selama penginstalan, atau istio-injection=enabled jika Anda menggunakan label injeksi default.

Label injeksi default

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

Catatan: Anda dapat mengabaikan error label "istio.io/rev" not found apa pun.

Label revisi

Sebelum men-deploy aplikasi, hapus label istio-injection sebelumnya dari namespace-nya dan tetapkan label istio.io/rev=REVISION_LABEL.

Untuk mengubahnya ke label revisi tertentu, klik REVISION_LABEL, dan ganti dengan label yang berlaku: asm-managed-rapid untuk Cepat, asm-managed untuk Reguler, atau asm-managed-stable untuk Stabil.

Label revisi sesuai dengan saluran rilis:

Label revisi	Saluran
asm-managed	Reguler
asm-managed-rapid	Cepat
asm-managed-stable	Stabil

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

Catatan: Anda dapat mengabaikan error label "istio-injection" not found apa pun.

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

Sekarang Anda siap men-deploy aplikasi, atau Anda dapat men-deploy aplikasi contoh Bookinfo.

Jika Anda men-deploy aplikasi dalam konfigurasi multi-cluster, replikasikan Kubernetes dan konfigurasi 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.

Sesuaikan injeksi (opsional)

Perhatian: Mengganti dan menyesuaikan setelan injeksi dapat menyebabkan error konfigurasi yang tidak terduga dan masalah yang ditimbulkan pada container file bantuan.

Konfigurasi per-pod tersedia untuk mengganti opsi ini pada masing-masing pod. Hal ini dilakukan dengan menambahkan container istio-proxy ke pod Anda. Injeksi sidecar akan memperlakukan konfigurasi apa pun yang ditentukan di sini sebagai pengganti template injeksi default.

Misalnya, konfigurasi berikut menyesuaikan berbagai setelan, termasuk menurunkan permintaan CPU, menambahkan penyangga 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"
      limites:
        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 sangat berhati-hati untuk kolom tertentu:

• Kubernetes memerlukan kolom image yang ditetapkan sebelum injeksi berjalan. Meskipun Anda dapat menyetel gambar tertentu untuk mengganti gambar default, sebaiknya setel image ke auto yang akan menyebabkan injektor file bantuan secara otomatis memilih gambar yang akan digunakan.
• Beberapa kolom di containers bergantung pada setelan terkait. Misalnya, permintaan CPU harus kurang dari batas CPU. Jika kedua kolom tidak dikonfigurasi dengan benar, pod dapat gagal dimulai.
• Kubernetes memungkinkan Anda menetapkan requests dan limits untuk resource di PodSpec. GKE Autopilot hanya mempertimbangkan requests. Untuk mengetahui informasi selengkapnya, lihat Menetapkan batas resource di Autopilot.

Selain itu, kolom tertentu dapat dikonfigurasi oleh anotasi pada pod, meskipun sebaiknya gunakan pendekatan di atas untuk menyesuaikan setelan. Anda harus sangat berhati-hati saat menggunakan anotasi tertentu:

• Untuk GKE Standard, jika sidecar.istio.io/proxyCPU disetel, pastikan untuk menyetel sidecar.istio.io/proxyCPULimit secara eksplisit. Jika tidak, batas CPU file bantuan akan ditetapkan sebagai tidak terbatas.
• Untuk GKE Standard, jika sidecar.istio.io/proxyMemory disetel, pastikan untuk menyetel sidecar.istio.io/proxyMemoryLimit secara eksplisit. Jika tidak, batas memori file bantuan akan ditetapkan sebagai tidak terbatas.
• Untuk GKE Autopilot, mengonfigurasi resource requests dan limits menggunakan anotasi mungkin akan menyediakan resource secara berlebihan. Gunakan pendekatan template gambar untuk menghindarinya. Lihat Contoh modifikasi resource di Autopilot.

Misalnya, lihat konfigurasi anotasi resource 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 memastikan konfigurasi Anda berfungsi dengan benar:

1. Di konsol Google Cloud, lihat metrik bidang kontrol:

   Buka Metrics Explorer

2. 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: jumlah
   • Menstruasi: 1 menit

   Saat menjalankan Anthos 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 yang tidak dikelola memiliki container_name="discovery". Untuk menampilkan metrik dari keduanya, hapus Filter pada container_name="cr-asm-managed".

3. Verifikasi versi bidang kontrol dan versi proxy dengan memeriksa kolom berikut di Metrics Explorer:

   • Kolom revisi menunjukkan versi bidang kontrol.
   • Kolom proxy_version menunjukkan proxy_version.
   • Kolom value menunjukkan jumlah proxy yang terhubung.

   Untuk mengetahui pemetaan saluran saat ini ke versi Anthos Service Mesh, lihat Versi Anthos Service Mesh per saluran.

Memigrasikan aplikasi ke Anthos Service Mesh terkelola

Peringatan: Selama proses migrasi, CRD Istio yang sesuai dengan saluran yang dipilih akan diinstal di cluster yang ditentukan. Jika ada CRD Istio yang sudah ada di cluster, CRD tersebut akan ditimpa.

Mempersiapkan untuk migrasi

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

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

2. (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"}'
   

Migrasikan aplikasi

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

1. Ganti label namespace saat ini. Langkah-langkah yang diperlukan bergantung pada apakah Anda ingin menggunakan label injeksi default (misalnya, istio-injection enabled) atau label revisi.

   Label injeksi default

   1. Jalankan perintah berikut untuk memindahkan tag default ke revisi terkelola:

      istioctl tag set default --revision REVISION_LABEL
      

   2. Jalankan perintah berikut untuk memberi label namespace menggunakan istio-injection=enabled, jika belum dilakukan:

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

   Label revisi

   Jika Anda menggunakan label istio.io/rev=REVISION_LABEL, jalankan perintah berikut:

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

2. Lakukan upgrade deployment berkelanjutan dalam namespace:

   kubectl rollout restart deployment -n NAMESPACE
   

3. Uji aplikasi Anda untuk memverifikasi bahwa beban kerja berfungsi dengan benar.

4. Jika Anda memiliki beban kerja di namespace lain, ulangi langkah sebelumnya untuk setiap namespace.

5. Jika Anda men-deploy aplikasi dalam konfigurasi multi-cluster, replikasikan konfigurasi Kubernetes dan Istio di semua cluster, kecuali jika Anda ingin membatasi konfigurasi tersebut hanya untuk subset cluster saja. Konfigurasi yang diterapkan pada cluster tertentu adalah sumber tepercaya untuk cluster tersebut.

6. Pastikan metrik muncul seperti yang diharapkan dengan mengikuti langkah-langkah dalam Memverifikasi metrik bidang kontrol.

Jika yakin bahwa aplikasi 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 menurunkan skala untuk menggunakan resource yang lebih sedikit. Untuk menghapus, lanjutkan ke Menghapus bidang kontrol lama.

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

Hapus bidang 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 pastikan jumlah endpoint yang terhubung adalah nol.

Roll back

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

1. Mengupdate workload yang akan dimasukkan dengan bidang kontrol versi sebelumnya. Dalam perintah berikut, nilai revisi asm-191-1 hanya digunakan sebagai contoh. Ganti contoh nilai dengan label revisi bidang kontrol sebelumnya.

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
   

2. Mulai ulang Pod untuk memicu injeksi ulang sehingga proxy memiliki versi sebelumnya:

   kubectl rollout restart deployment -n NAMESPACE
   

Bidang kontrol terkelola akan otomatis diskalakan hingga nol dan tidak menggunakan resource apa pun saat tidak digunakan. Penyediaan dan webhook yang berubah akan tetap ada dan tidak memengaruhi perilaku cluster.

Gateway kini disetel ke revisi asm-managed. Untuk melakukan roll back, jalankan kembali perintah instal Anthos Service Mesh, yang akan men-deploy ulang gateway dengan mengarahkan kembali ke bidang kontrol dalam cluster:

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

Nantikan output ini 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 mengetahui langkah-langkah mendetail, lihat Meng-uninstal Anthos 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 Mengaktifkan fitur Anthos Service Mesh terkelola opsional, seperti:
  • Log akses Envoy
  • Pelacakan
  • Gambar tanpa hambatan
  • Autentikasi pengguna akhir