Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Menyuntikkan proxy sidecar dengan Cloud Service Mesh
Dokumen ini membahas cara mengonfigurasi penyisipan proxy sidecar dengan Cloud Service Mesh untuk meningkatkan keamanan, keandalan, dan kemampuan observasi jaringan. Fungsi ini
diabstrakkan dari penampung utama aplikasi dan diimplementasikan dalam
proxy out-of-process umum (sidecar), yang dikirimkan sebagai penampung terpisah di
Pod yang sama. Hal ini menyediakan
fitur Cloud Service Mesh tanpa mendesain ulang
aplikasi produksi Anda untuk berpartisipasi dalam mesh layanan.
Injeksi proxy sidecar otomatis (injeksi otomatis) terjadi saat Cloud Service Mesh
mendeteksi label namespace yang Anda konfigurasi untuk Pod workload. Proxy mencegat semua traffic masuk dan keluar ke workload serta berkomunikasi dengan Cloud Service Mesh.
Izin yang diperlukan untuk tugas ini
Untuk melakukan tugas di halaman ini, Anda harus memiliki
peran roles/container.clusterAdmin atau yang lebih tinggi. Lihat
Peran Google Kubernetes Engine untuk
detail tentang izin yang disertakan dalam peran ini.
Mengaktifkan injeksi sidecar otomatis
Cara yang direkomendasikan untuk menyuntikkan proxy file bantuan adalah dengan menggunakan injektor file bantuan otomatis berbasis webhook, meskipun Anda dapat memperbarui konfigurasi Kubernetes Pod secara manual.
Untuk mengaktifkan injeksi otomatis, Anda memberi label pada namespace dengan
label injeksi default
jika tag default disiapkan, atau dengan
label revisi ke namespace Anda.
Label yang Anda tambahkan juga bergantung pada apakah Anda men-deploy
Cloud Service Mesh terkelola (dengan
fleet API atau dengan
asmcli), atau
menginstal bidang kontrol dalam cluster. Label digunakan oleh webhook injektor sidecar
untuk mengaitkan sidecar yang diinjeksi dengan revisi bidang kontrol
tertentu.
Untuk mengaktifkan penyuntikan otomatis:
Dalam cluster
Gunakan perintah berikut untuk menemukan label revisi di istiod:
kubectl -n istio-system get pods -l app=istiod --show-labels
Dalam output, di kolom LABELS, catat nilai label revisi istiod, yang mengikuti awalan istio.io/rev=. Dalam
contoh ini, nilainya adalah asm-11910-9.
Terapkan label revisi ke namespace dan hapus label istio-injection
(jika ada). Pada perintah berikut, NAMESPACE adalah
nama namespace tempat Anda ingin mengaktifkan penyuntikan otomatis, dan
REVISION adalah label revisi yang Anda catat pada
langkah sebelumnya.
Anda dapat mengabaikan pesan "istio-injection not found" dalam
output. Artinya, namespace sebelumnya tidak memiliki label
istio-injection, yang akan Anda lihat di penginstalan
Cloud Service Mesh atau deployment baru. Karena perilaku injeksi otomatis tidak ditentukan saat namespace memiliki label revisi dan istio-injection, semua perintah kubectl label dalam dokumentasi Cloud Service Mesh secara eksplisit memastikan bahwa hanya satu yang ditetapkan.
Mulai ulang pod yang terpengaruh, menggunakan langkah-langkah di bagian berikutnya.
Mesh layanan terkelola
Gunakan perintah berikut untuk menemukan saluran rilis yang tersedia:
kubectl -n istio-system get controlplanerevision
Outputnya mirip dengan hal berikut ini:
NAME AGE
asm-managed 6d7h
Dalam output, pilih nilai di kolom NAME adalah label
REVISION yang sesuai dengan
saluran rilis yang tersedia
untuk versi Cloud Service Mesh. Terapkan label ini ke namespace Anda, dan
hapus label istio-injection (jika ada).
Pada perintah berikut, ganti REVISION dengan
label revisi yang Anda catat di atas, dan ganti
NAMESPACE dengan nama namespace tempat Anda
ingin mengaktifkan injeksi otomatis:
Anda dapat mengabaikan pesan "istio-injection not found" dalam
output. Artinya, namespace sebelumnya tidak memiliki label
istio-injection, yang akan Anda lihat di penginstalan
Cloud Service Mesh atau deployment baru. Karena perilaku injeksi otomatis tidak ditentukan saat namespace memiliki label revisi dan istio-injection, semua perintah kubectl label dalam dokumentasi Cloud Service Mesh secara eksplisit memastikan bahwa hanya satu yang ditetapkan.
Mulai ulang pod yang terpengaruh, menggunakan langkah-langkah di bagian berikutnya.
Jika Anda tidak menggunakan Deployment, hapus Pod, dan Pod akan otomatis
dibuat ulang dengan sidecar:
kubectl delete pod -n YOUR_NAMESPACE --all
Pastikan semua Pod di namespace memiliki sidecar yang disuntikkan:
kubectl get pod -n YOUR_NAMESPACE
Dalam contoh output berikut dari perintah sebelumnya, perhatikan bahwa kolom
READY menunjukkan ada dua container untuk setiap beban kerja Anda: container utama dan container untuk proxy sidecar.
NAME READY STATUS RESTARTS AGE
YOUR_WORKLOAD 2/2 Running 0 20s
...
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-19 UTC."],[],[],null,["# Inject sidecar proxies with Cloud Service Mesh\n==============================================\n\nThis document covers how to configure sidecar proxy injection with Cloud Service Mesh\nto enhance network security, reliability, and observability. These functions are\nabstracted away from the application's primary container and implemented in a\ncommon out-of-process proxy (the sidecar), delivered as a separate container in\nthe same Pod. This provides the\n[Cloud Service Mesh's features](/service-mesh/v1.19/docs/overview) without redesigning your\nproduction applications to participate in a service mesh.\n\nAutomatic sidecar proxy injection (auto-injection) occurs when Cloud Service Mesh\ndetects a namespace label you configure for the workload's Pod. The proxy\nintercepts all inbound and outbound traffic to the workloads and communicates\nwith Cloud Service Mesh.\n\n#### Permissions required for these tasks\n\n\nTo perform the tasks on this page, you must have the\n`roles/container.clusterAdmin` or a higher role. See\n[Google Kubernetes Engine roles](/iam/docs/understanding-roles#container) for\ndetails on the permissions included in this role.\n\nEnabling automatic sidecar injection\n------------------------------------\n\nThe recommended way to inject sidecar proxies is to use the webhooks-based\nautomatic sidecar injector, although you can manually update your Pods'\nKubernetes configuration.\n\nTo enable auto-injection, you label your namespaces with the\n*[default injection labels](https://istio.io/latest/docs/setup/upgrade/canary/#default-tag)*\nif the default tag is set up, or with the\n[revision label](/service-mesh/v1.19/docs/revisions-overview) to your namespace.\nThe label that you add also depends on whether you deployed\nmanaged Cloud Service Mesh (with the\n[fleet API](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh) or with\n[`asmcli`](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh-asmcli)), or\ninstalled the in-cluster control plane. The label is used by the sidecar\ninjector webhook to associate injected sidecars with a particular control plane\nrevision.\n\nTo enable auto-injection: \n\n### In-cluster\n\n1. Use the following command to locate the revision label on `istiod`:\n\n kubectl -n istio-system get pods -l app=istiod --show-labels\n\n The output looks similar to the following: \n\n ```bash\n NAME READY STATUS RESTARTS AGE LABELS\n istiod-asm-11910-9-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-11910-9,istio=istiod,pod-template-hash=5788d57586\n istiod-asm-11910-9-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-11910-9,istio=istiod,pod-template-hash=5788d57586\n ```\n\n In the output, under the `LABELS` column, note the value of the `istiod`\n revision label, which follows the prefix `istio.io/rev=`. In this\n example, the value is `asm-11910-9`.\n\n\n | **Note:** You can substitute `istio.io/rev` with the `istio-injection=enabled` label if the [default tag](https://istio.io/latest/docs/setup/upgrade/canary/#default-tag) is configured. Verify the default tag exists by running ` istioctl tag list` with the `istioctl` from \u003cvar translate=\"no\"\u003eOUTPUT_DIR\u003c/var\u003e.\n\n \u003cbr /\u003e\n\n2. Apply the revision label to namespaces and remove the istio-injection label\n (if it exists). In the following command, \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e is\n the name of the namespace where you want to enable auto-injection, and\n \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e is the revision label you noted in the\n previous step.\n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio-injection- istio.io/rev=\u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e --overwrite\n\n\n You can ignore the message `\"istio-injection not found\"` in the\n output. That means that the namespace didn't previously have the\n `istio-injection` label, which you should expect in new\n installations of Cloud Service Mesh or new deployments. Because auto-injection\n behavior is undefined when a namespace has both the `istio-injection`\n and the revision label, all `kubectl label` commands in the\n Cloud Service Mesh documentation explicitly ensure that only one is set.\n3. Restart the affected pods, using the steps in the next section.\n\n### Managed service mesh\n\n1. Use the following command to locate the available release channels:\n\n kubectl -n istio-system get controlplanerevision\n\n The output is similar to the following: \n\n NAME AGE\n asm-managed 6d7h\n\n In the output, select the value under the `NAME` column is the\n \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e label that corresponds to the available\n [release channel](/service-mesh/v1.19/docs/managed/select-a-release-channel#anthos_service_mesh_versions_per_channel)\n for the Cloud Service Mesh version. Apply this label to your namespaces, and\n remove the `istio-injection` label (if it exists).\n In the following command, replace \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e with the\n revision label you noted above, and replace\n \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e` ` with the name of the namespace where you\n want to enable auto-injection: \n\n kubectl label namespace \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e istio-injection- istio.io/rev=\u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e --overwrite\n\n\n You can ignore the message `\"istio-injection not found\"` in the\n output. That means that the namespace didn't previously have the\n `istio-injection` label, which you should expect in new\n installations of Cloud Service Mesh or new deployments. Because auto-injection\n behavior is undefined when a namespace has both the `istio-injection`\n and the revision label, all `kubectl label` commands in the\n Cloud Service Mesh documentation explicitly ensure that only one is set.\n2. Restart the affected pods, using the steps in the next section.\n\n3. If you also deployed the optional\n [Google-managed data plane](/service-mesh/v1.19/docs/managed/provision-managed-anthos-service-mesh#managed-data-plane),\n annotate the `demo` namespace as follows:\n\n kubectl annotate --overwrite namespace \u003cvar translate=\"no\"\u003eYOUR_NAMESPACE\u003c/var\u003e \\\n mesh.cloud.google.com/proxy='{\"managed\":\"true\"}'\n\n### Restart Pods to update sidecar proxies\n\n| **Warning:** Unless you have a load balancer or router setup for [blue-green deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html), make sure you test restarting Pods in a staging environment to verify that your services can handle any potential traffic interruption.\n\nWith automatic sidecar injection, you can update the sidecars for existing Pods\nwith a Pod restart:\n\nHow you restart Pods depends on if they were created as part of a\n[Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).\n\n1. If you used a Deployment, restart the Deployment, which restarts all Pods\n with sidecars:\n\n ```\n kubectl rollout restart deployment -n YOUR_NAMESPACE\n ```\n\n If you didn't use a Deployment, delete the Pods, and they are automatically\n recreated with sidecars: \n\n ```\n kubectl delete pod -n YOUR_NAMESPACE --all\n ```\n2. Check that all the Pods in the namespace have sidecars injected:\n\n ```\n kubectl get pod -n YOUR_NAMESPACE\n ```\n\n In the following example output from the previous command, notice that the\n `READY` column indicates there are two containers for each of your\n workloads: the primary container and the container for the sidecar proxy. \n\n ```\n NAME READY STATUS RESTARTS AGE\n YOUR_WORKLOAD 2/2 Running 0 20s\n ...\n ```\n\nWhat's next\n-----------\n\nLearn more about:\n\n- [Cloud Service Mesh control plane revisions](/service-mesh/v1.19/docs/revisions-overview)\n- [Deploying workloads](/kubernetes-engine/docs/how-to/deploying-workloads-overview)\n- [Customizing injection](https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/#customizing-injection)"]]