Webhook validasi memastikan konfigurasi Istio yang diterapkan valid.
Webhook yang berubah menetapkan injeksi sidecar otomatis pada pod baru.
Masalah konfigurasi di salah satu webhook ini dapat menyebabkan pod baru gagal
dinyalakan, atau kubectl apply menghasilkan pesan error.
Masalah injeksi sidecar
Jika Anda telah menyediakan Cloud Service Mesh terkelola, hubungi dukungan.
Injeksi sidecar tidak berfungsi dengan benar jika Anda melihat salah satu hal berikut:
pod yang dijadwalkan tanpa sidecar
pod yang seharusnya memiliki sidecar yang dimasukkan tidak pernah muncul saat menggunakan
kubectl get pods, tetapi set replika yang sesuai dari
kubectl get replicaset ada.
Gunakan langkah-langkah berikut untuk memecahkan masalah injeksi sidecar.
Pastikan namespace atau pod Anda memiliki label injeksi yang benar.
Jika Anda menjalankan Istio revisi tunggal (default), pastikan
spec namespace atau pod Anda memiliki label istio-injection=enabled.
Jika Anda menjalankan Istio dengan beberapa revisi (untuk migrasi tanpa periode nonaktif,
beberapa bidang kontrol, dll.), pastikan namespace atau spesifikasi pod Anda memiliki
label istio.io/rev=REVISION yang sesuai, dengan
REVISION adalah nomor revisi Cloud Service Mesh di istiod
yang sesuai dengan versi Cloud Service Mesh yang Anda pilih. Untuk informasi
selengkapnya tentang label revisi, lihat Memasukkan proxy sidecar.
Pastikan webhook injeksi sidecar istio Anda ada dan memiliki paket CA.
Webhook injector sidecar (yang digunakan untuk injeksi sidecar otomatis)
memerlukan paket CA untuk membuat koneksi aman dengan server API dan
istiod. Paket CA ini di-patch ke dalam konfigurasi oleh istiod, tetapi
terkadang dapat ditimpa (misalnya, jika Anda menerapkan ulang konfigurasi
webhook).
Anda dapat memverifikasi keberadaan paket CA menggunakan perintah berikut. Perintah ini
menyertakan istio-sidecar-injector-asm-1246-9, yang
khusus untuk Cloud Service Mesh versi ini. Pastikan Anda menggunakan revisi
yang sebenarnya jika berbeda.
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1246-9 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
Jika output tidak kosong, paket CA akan dikonfigurasi. Jika paket CA
tidak ada, mulai ulang istiod agar memindai ulang webhook dan
menginstal ulang paket CA.
Periksa kegagalan injeksi sidecar.
Jika Anda telah mengaktifkan injeksi, tetapi tidak melihat penjadwalan pod, periksa
status tingkat abstraksi yang lebih tinggi berikutnya. Misalnya, jika Anda
menjalankan deployment, tetapi tidak ada pod yang dijadwalkan, periksa status
set replika yang sesuai menggunakan perintah berikut:
Jika set replika ada, periksa log peristiwa di bagian bawah
deskripsi untuk menemukan error. Jika error terkait dengan injeksi sidecar, periksa log istiod untuk mengetahui indikasi penyebab error.
Jika masalah berlanjut, masalahnya mungkin salah satu dari hal berikut:
Proksi Envoy tidak menerima konfigurasi dari istiod
Ada beberapa masalah yang dapat mencegah proxy menerima konfigurasi
dari istiod.
istiod tidak akan mendorong konfigurasi ke proxy envoy jika mengalami masalah,
seperti masalah RBAC yang mencegahnya membaca resource konfigurasinya.
Alamat penemuan salah (error 'tidak ada upstream yang sehat')
Alamat penemuan yang diberikan ke injector sidecar salah. Jika
Anda melihat log yang menyebutkan gRPC config stream closed, no healthy upstream,
periksa apakah alamat penemuan di mesh
ProxyConfig
sudah benar dan mengarah ke layanan istiod Anda.
Konfigurasi yang tidak valid dikirim ke proxy. Dalam hal ini, konfigurasi
berhasil dikirim ke proxy, tetapi konfigurasi tidak valid. Anda akan
melihat pesan berulang yang mirip dengan berikut ini:
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
Dalam contoh ini, cds adalah Layanan Penemuan Cluster (yang melaporkan 1
update yang didorong dari istiod), dan lds adalah Layanan Penemuan Pemroses
(yang melaporkan 1 update yang ditolak dari istiod). Sering kali Anda akan melihat
pesan error sebelumnya yang menjelaskan alasan penolakan, yang
biasanya dimulai dengan peringatan tentang konfigurasi envoy atau yang serupa.
Untuk memperbaiki masalah ini, selidiki penyebab konfigurasi yang ditolak. Salah satu
penyebab umum adalah resource EnvoyFilter yang buruk. Jika tidak ada alasan yang jelas,
kirim laporan bug dengan dump konfigurasi proxy.
Pembuatan pod gagal
Jika Anda mengamati bahwa pod tidak berhasil dibuat, cari pesan error
yang mungkin memberikan petunjuk ke akar masalah, menggunakan perintah berikut:
kubectl describe replicaset YOUR_REPLICA_SET
Pesan error webhook umum
Pesan error yang dihasilkan oleh perintah kubectl apply dapat memberikan petunjuk tentang
penyebab utamanya. Lihat tabel berikut untuk mengetahui pesan error umum, penyebabnya, dan kemungkinan penyelesaiannya.
Pesan error
Penyebab
Resolusi
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Hal ini mungkin disebabkan oleh masalah konektivitas jaringan.
Pastikan aturan firewall Anda menyediakan konektivitas ke `istiod` di port 15017.
no endpoints available for service 'istiod'
Hal ini dapat terjadi jika pod `istiod` tidak tersedia atau belum siap.
Periksa pod `istiod` untuk memastikan pod tersebut berjalan dan siap.
Service "istiod" not found
Hal ini dapat terjadi jika layanan `istiod` tidak ada.
Pastikan penginstalan Istio Anda berhasil dan benar.
x509: certificate signed by unknown authority
Hal ini mungkin merupakan masalah sertifikat webhook.
Pastikan caBundle ditetapkan dengan benar di webhook.
Failed to update validatingwebhookconfiguration
istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail,
resourceVersion=[version]): Operation cannot be fulfilled on
validatingwebhookconfigurations.admissionregistration.k8s.io
"istio-validator-asm-[version-n]-istio-system": the object has been
modified; please apply your changes to the latest version and try
again.
Webhook yang memvalidasi dari Istio versi lama atau Cloud Service Mesh yang telah di-uninstal dapat mengganggu upgrade atau penginstalan.
Pastikan semua webhook masih ada di cluster dan hapus webhook apa pun
yang mereferensikan versi yang tidak lagi diinstal.
Error from server (InternalError): Internal error occurred: failed
calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded
Untuk cluster pribadi, port 15017 harus terbuka. Pesan error ini
menunjukkan bahwa port 15017 mungkin tidak terbuka.
Pastikan aturan firewall Anda menyediakan konektivitas ke Istiod di port
15017. Untuk mengetahui informasi selengkapnya, lihat
Membuka port di cluster pribadi.
[[["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-09-02 UTC."],[],[],null,["# Resolving sidecar proxy/webhook issues in Cloud Service Mesh\n============================================================\n\nThis section explains common Cloud Service Mesh problems and how to resolve\nthem. If you need additional assistance, see\n[Getting support](/service-mesh/v1.24/docs/getting-support).\n| **Note:** These instructions are only applicable to in-cluster Cloud Service Mesh.\n\nCloud Service Mesh contains two\n[webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/):\n\n- The validating webhook ensures applied Istio configuration is valid.\n- The mutating webhook sets automatic sidecar injection on new pods.\n\nA configuration issue in one of these webhooks might cause new pods to fail\nstart up, or `kubectl apply` generating error messages.\n\nSidecar injection problems\n--------------------------\n\nIf you have provisioned managed Cloud Service Mesh, then\n[contact support](/service-mesh/v1.24/docs/getting-support).\n\nSidecar injection is not working correctly if you see any of the following:\n\n- pods that are scheduling without sidecars\n- pods that should have sidecars injected never appear when using `kubectl get pods`, but the corresponding replica set from `kubectl get replicaset` exists.\n\nUse the following steps to troubleshoot sidecar injection problems.\n\n1. Verify that your namespace or pod has the correct injection label.\n\n If you are running single-revision Istio (the default), verify that your\n namespace or pod spec have the istio-injection=enabled label.\n\n If you are running multiple-revision Istio (for zero-downtime migrations,\n multiple control planes, etc), verify that your namespace or pod spec have\n the appropriate `istio.io/rev=`\u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e label, where\n \u003cvar translate=\"no\"\u003eREVISION\u003c/var\u003e is the Cloud Service Mesh revision number on `istiod`\n that corresponds with your selected Cloud Service Mesh version. For more\n information about revision labels, see [Injecting sidecar proxies](/service-mesh/v1.24/docs/onboarding/kubernetes-workloads#inject_sidecar_proxies).\n2. Verify that your istio sidecar injection webhook is present and has a CA bundle.\n\n The sidecar injector webhook (which is used for automatic sidecar injection)\n requires a CA bundle to establish secure connections with the API server and\n `istiod`. This CA bundle is patched into the configuration by `istiod`, but\n can sometimes be overwritten (for example, if you reapply the webhook\n configuration).\n\n You can verify the presence of the CA bundle using the following command. The\n command includes `istio-sidecar-injector-asm-1246-9`, which is\n specific to this version of Cloud Service Mesh. Ensure you use your actual\n revision if it differs. \n\n ```\n kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1246-9 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'\n ```\n\n If the output is not empty, the CA bundle is configured. If the CA bundle is\n missing, restart `istiod` to cause it to rescan the webhook and\n reinstall the CA bundle.\n3. Check for sidecar injection failures.\n\n If you have injection enabled, but are not seeing pods scheduling, check the\n status of the next higher level of abstraction. For example, if you are\n running a deployment but no pods are scheduling, check the status of the\n corresponding replica sets using the following command: \n\n ```\n kubectl -n my-namespace describe replicaset your-deployment-name\n ```\n\n If the replica set is present, check the events log at the bottom of the\n description for errors. If the error relates to sidecar injection, check the\n `istiod` logs for an indication of what is causing the error.\n4. If the problem persists, the issue might be any of the following:\n\n - Bad configuration passed to the injector\n - Firewall configuration problems\n - A problem in the Istio code itself\n\n See [Troubleshooting Istio](https://github.com/istio/istio/wiki/Troubleshooting-Istio#diagnostics)\n for additional diagnostic steps.\n\nEnvoy proxies don't receive configuration from `istiod`\n-------------------------------------------------------\n\nThere are several issues that can prevent proxies from receiving configuration\nfrom `istiod`.\n\n1. `istiod` will not push configuration to the envoy proxies if it has problems,\n such as an RBAC issue preventing it from reading its configuration resource.\n\n2. Discovery address is incorrect ('no healthy upstream' errors)\n\n3. The discovery address provided to the sidecar injector being incorrect. If\n you see logs that mention `gRPC config stream closed, no healthy upstream`,\n check that the discovery address in the mesh\n [`ProxyConfig`](https://istio.io/v1.24/docs/reference/config/istio.mesh.v1alpha1/#ProxyConfig)\n is correct and points to your `istiod` service.\n\n4. Invalid configuration being pushed to the proxy. In this case, configuration\n is successfully pushed to the proxy, but the configuration is invalid. You will\n see repeating messages similar to the following:\n\n ```\n Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected\n ```\n\n In this example, `cds` is the Cluster Discovery Service (which reports 1\n update pushed from `istiod`), and `lds` is the Listener Discovery Service\n (which reports 1 update rejected from `istiod`). Often you will see an\n earlier error message that explains the reason for the rejection, which\n usually starts with a warning about envoy configuration or similar.\n\n To fix the issue, investigate the cause of the rejected configuration. One\n common cause is bad `EnvoyFilter` resources. If no reason is obvious,\n submit a bug report with a configuration dump of the proxy.\n\nPod creation fails\n------------------\n\nIf you observe that pods are not being created successfully, look for error\nmessages that might give clues to the root problem, using the following command: \n\n```\nkubectl describe replicaset YOUR_REPLICA_SET\n```\n\nCommon webhook error messages\n-----------------------------\n\nError messages output by the `kubectl apply` command can provide a hint about\ntheir root cause. See the following table for common error messages, their\ncauses and potential resolutions."]]
