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 keandalan, upgrade, penskalaan, dan keamanannya dengan cara yang kompatibel dengan versi lama. Panduan
ini menjelaskan cara menyiapkan atau memigrasikan aplikasi ke Cloud Service Mesh terkelola
dalam konfigurasi tunggal atau multi-cluster dengan asmcli
.
Untuk mempelajari fitur dan batasan Cloud Service Mesh terkelola yang didukung, lihat Fitur yang didukung Cloud Service Mesh Terkelola.
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 lainnya yang ditentukan dalam Menginstal alat yang diperlukan
Untuk penyediaan yang lebih cepat, cluster Anda harus mengaktifkan Workload Identity. Jika Workload Identity belum 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 yang diperlukan yang mengelola penginstalan Cloud Service Mesh di cluster.
- Deployment
mdp-controller
dalam namespacekube-system
meminta cpu:50m, memory: 128Mi. - Daemon
istio-cni-node
dalam namespacekube-system
meminta cpu: 100m, memory: 100Mi pada setiap node.
- Deployment
- 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 dari project host fleet.
Autopilot GKE hanya didukung dengan GKE versi 1.21.3+.
Cloud Service Mesh dapat menggunakan beberapa cluster GKE dalam lingkungan jaringan tunggal project tunggal 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 perangkat 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 Armada.
- Untuk lingkungan multi-project, sebaiknya Anda menghosting fleet dalam 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 setara dengan 1.22.1-gke.10, Anda mungkin perlu melakukan langkah konfigurasi tambahan:
- Jika Anda menyediakan Cloud Service Mesh di saluran rilis reguler atau stabil, Anda harus menggunakan flag
--use-vpcsc
tambahan saat menerapkan bidang kontrol terkelola dan mengikuti panduan Kontrol Layanan VPC (pratinjau). Jika tidak, penyediaan akan gagal dalam kontrol keamanan. - Jika Anda menyediakan Cloud Service Mesh di saluran rilis cepat, Anda tidak perlu menggunakan flag
--use-vpcsc
tambahan saat menerapkan bidang kontrol terkelola, tetapi Anda harus mengikuti panduan Kontrol Layanan VPC (GA).
- Jika Anda menyediakan Cloud Service Mesh di saluran rilis reguler atau stabil, Anda harus menggunakan flag
Peran yang diperlukan untuk menginstal Cloud Service Mesh
Tabel berikut menjelaskan peran yang diperlukan untuk menginstal Cloud Service Mesh terkelola.
Nama peran | ID Peran | Berikan lokasi | Deskripsi |
---|---|---|---|
GKE Hub Admin | roles/gkehub.admin | Project fleet | Akses penuh ke GKE Hub dan resource terkait. |
Service Usage Admin | roles/serviceusage.serviceUsageAdmin | Project fleet | Kemampuan untuk mengaktifkan, menonaktifkan, dan memeriksa status layanan, memeriksa operasi, 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) |
Batasan
Sebaiknya tinjau daftar fitur dan batasan yang didukung Cloud Service Mesh. Secara khusus, perhatikan hal-hal berikut:
IstioOperator
API tidak didukung karena tujuan utamanya adalah mengontrol komponen dalam cluster.Untuk cluster GKE Autopilot, penyiapan lintas project hanya didukung dengan GKE 1.23 atau yang lebih baru.
Untuk cluster GKE Autopilot, guna beradaptasi dengan batas resource GKE Autopilot, batas dan permintaan resource proxy default ditetapkan ke 500 m CPU dan memori 512 Mb. Anda dapat mengganti nilai default menggunakan injeksi kustom.
Selama proses penyediaan untuk bidang kontrol terkelola, Istio CRD disediakan di cluster yang ditentukan. Jika sudah ada CRD Istio di cluster, CRD tersebut akan ditimpa
Istio CNI dan Cloud Service Mesh tidak kompatibel dengan GKE Sandbox. Oleh karena itu, Cloud Service Mesh yang dikelola dengan implementasi
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"lompat", 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.
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 pada saat penyediaan Cloud Service Mesh yang terkelola. Perlu diperhatikan bahwa beberapa saluran dalam cluster yang sama secara bersamaan 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, dengan FLEET_ID adalah project-id dari project host fleet. Jika menggunakan project tunggal, FLEET_PROJECT_ID sama dengan PROJECT_ID, project host fleet dan project cluster sama. Dalam konfigurasi yang lebih kompleks seperti multi-project, sebaiknya gunakan project host fleet terpisah.--enable-all
. Tanda ini memungkinkan pendaftaran dan komponen 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.
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 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 bidang kontrol terkelola
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
ada dalam subdirektori <Istio release dir>/bin
.
Jika Anda menjalankan kembali asmcli
di cluster yang sama, konfigurasi bidang kontrol yang 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 Cloud Service Mesh terkelola, Google akan sepenuhnya mengelola upgrade proxy Anda, kecuali jika Anda menonaktifkannya.
Dengan bidang data terkelola, proxy file bantuan dan gateway yang dimasukkan akan otomatis diupdate bersama bidang kontrol terkelola dengan memulai ulang workload untuk memasukkan ulang versi baru proxy. Proses ini biasanya selesai 1-2 minggu setelah bidang kontrol terkelola diupgrade.
Jika dinonaktifkan, pengelolaan proxy didorong oleh siklus proses alami dari 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 sebelumnya. Penghapusan dilakukan secara bertahap, sesuai dengan anggaran gangguan pod dan pengendalian tingkat perubahan.
Bidang data terkelola tidak mengelola hal berikut:
- Pod yang tidak dimasukkan
- Pod yang dimasukkan secara manual
- Tugas
- StatefulSets
- DaemonSets
Jika telah menyediakan Cloud Service Mesh terkelola pada 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 masing-masing komponen secara selektif, urutan prioritasnya adalah revisi bidang kontrol, lalu namespace, kemudian pod.
Diperlukan 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 bidang data terkelola untuk mengetahui langkah berikutnya.
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, yang dinonaktifkan secara default atau manual.
Untuk menonaktifkan bidang data terkelola di tingkat cluster dan kembali ke pengelolaan 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 bidang 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 ikut serta dalam notifikasi pemeliharaan bidang data terkelola:
Buka halaman Komunikasi.
Di baris Cloud Service Mesh Upgrade, pada kolom Email, pilih tombol pilihan untuk MENGAKTIFKAN notifikasi pemeliharaan.
Setiap pengguna yang ingin menerima notifikasi harus memilih ikut serta secara terpisah. Jika Anda ingin menetapkan 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 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.
Terima kasih,
Tim Cloud Service Mesh
(c) 2023 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)
Jika mesh Anda hanya memiliki satu cluster, lewati langkah multi-cluster ini dan lanjutkan ke Men-deploy aplikasi atau Memigrasikan aplikasi.
Sebelum melanjutkan, pastikan bahwa Cloud Service Mesh dikonfigurasi pada setiap cluster.
Cluster publik
Mengonfigurasi penemuan endpoint di antara cluster publik
Jika Anda beroperasi di cluster publik (cluster non pribadi), Anda dapat Mengonfigurasi penemuan endpoint antar-cluster publik atau lebih sederhana lagi 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 endpoint publik, bukan endpoint 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 label injeksi default ke namespace:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Jika Anda adalah pengguna lama dengan bidang kontrol Istio yang Terkelola: 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 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 sudah memiliki workload di namespace berlabel, mulai ulang workload tersebut agar proxy dapat dimasukkan.
Jika Anda men-deploy aplikasi di penyiapan multi-cluster, replikasikan konfigurasi bidang kontrol dan Kubernetes di semua cluster, kecuali Anda berencana membatasi konfigurasi tersebut ke subset cluster. Konfigurasi yang diterapkan ke cluster tertentu adalah sumber tepercaya untuk cluster tersebut.
Sesuaikan injeksi (opsional)
Anda dapat mengganti nilai default dan menyesuaikan setelan injeksi, tetapi hal ini dapat menyebabkan error konfigurasi yang tidak terduga dan mengakibatkan masalah pada penampung file bantuan. Sebelum menyesuaikan injeksi, baca informasi setelah contoh untuk catatan tentang setelan 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. Injeksi file bantuan
akan memperlakukan konfigurasi apa pun yang ditentukan di sini sebagai penggantian terhadap
template injeksi 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, kolom tertentu harus diperhatikan:
- Kubernetes mengharuskan kolom
image
ditetapkan sebelum injeksi berjalan. Meskipun Anda dapat menyetel gambar tertentu untuk mengganti gambar default, sebaiknya tetapkanimage
keauto
, yang akan menyebabkan injektor file bantuan 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 kolom tidak dikonfigurasi dengan benar, pod mungkin gagal dimulai. - Kubernetes memungkinkan Anda menetapkan
requests
danlimits
untuk resource di Podspec
. Autopilot GKE hanya mempertimbangkanrequests
. Untuk mengetahui informasi selengkapnya, lihat Menetapkan batas resource di Autopilot.
Selain itu, kolom tertentu dapat dikonfigurasi oleh 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 menetapkansidecar.istio.io/proxyCPULimit
secara eksplisit. Jika tidak, batas CPU file bantuan akan ditetapkan sebagai tidak terbatas. - Untuk GKE Standard, jika
sidecar.istio.io/proxyMemory
ditetapkan, pastikan untuk menetapkansidecar.istio.io/proxyMemoryLimit
secara eksplisit. Jika tidak, batas memori file bantuan akan ditetapkan sebagai tidak terbatas. - Untuk GKE Autopilot, mengonfigurasi resource
requests
danlimits
menggunakan anotasi dapat menyediakan resource secara berlebihan. Sebaiknya hindari pendekatan template gambar. 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 menampilkan 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:
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 labelproxy_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 yang tidak dikelola memilikicontainer_name="discovery"
. Untuk menampilkan metrik dari keduanya, hapus Filter dicontainer_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 Cloud Service Mesh terkelola, 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 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:
- 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 label injeksi default ke namespace:
kubectl label namespace NAMESPACE \
istio.io/rev- istio-injection=enabled --overwrite
Jika Anda adalah pengguna lama dengan bidang kontrol Istio yang Terkelola: 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 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 workload di namespace lain, ulangi langkah-langkah sebelumnya untuk setiap namespace.
Jika Anda men-deploy aplikasi dalam penyiapan multi-cluster, buat replika konfigurasi Kubernetes dan Istio di semua cluster, kecuali jika ada keinginan untuk membatasi konfigurasi tersebut ke sebagian cluster saja. Konfigurasi yang diterapkan ke cluster tertentu adalah sumber tepercaya untuk cluster tersebut.
Jika puas dengan aplikasi Anda bekerja sesuai harapan, Anda dapat menghapus istiod
dalam cluster setelah mengalihkan semua namespace ke bidang kontrol terkelola, atau menyimpannya sebagai cadangan - istiod
akan otomatis memperkecil skala untuk menggunakan lebih sedikit resource. Untuk menghapus, lanjutkan ke
Menghapus bidang kontrol lama.
Jika mengalami masalah, Anda dapat mengidentifikasi dan menyelesaikannya menggunakan informasi di 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
menginstal gateway tambahan, periksa metrik untuk bidang kontrol,
dan verifikasi bahwa jumlah endpoint yang terhubung adalah nol.
Roll back
Lakukan langkah-langkah berikut jika Anda perlu melakukan roll back ke versi bidang kontrol sebelumnya:
Update workload yang akan dimasukkan 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 injeksi 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 jika 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 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 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. Untuk mengetahui langkah-langkah mendetail, 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 Mengaktifkan fitur Mesh Layanan Cloud terkelola opsional, seperti: