使用 kubectl get pods 時，應注入 sidecar 的 Pod 永遠不會顯示，但 kubectl get replicaset 的對應副本集會存在。
請按照下列步驟排解側載注入問題。
確認命名空間或 Pod 具有正確的插入標籤。
如果您執行單一修訂版本的 Istio (預設)，請確認您的命名空間或 Pod 規格具有 istio-injection=enabled 標籤。
如果您執行的是多個修訂版本的 Istio (用於零停機遷移、多個控制平面等)，請確認您的命名空間或 Pod 規格具有適當的 istio.io/rev=REVISION 標籤，其中 REVISION 是 istiod 上的 Cloud Service Mesh 修訂版本號碼，對應您所選的 Cloud Service Mesh 版本。如要進一步瞭解修訂版本標籤，請參閱「插入附屬 Proxy」。
確認 istio sidecar 注入 webhook 是否存在，且具有 CA 套件。
補充資訊注入器 webhook (用於自動補充資訊注入) 需要 CA 套件，才能與 API 伺服器和 istiod 建立安全連線。這個 CA 組合會由 istiod 修補至設定中，但有時可能會遭到覆寫 (例如，如果您重新套用 webhook 設定)。
您可以使用下列指令驗證 CA 套件的存在情形。這項指令包含 istio-sidecar-injector-asm-1246-9，這是專屬於這個版本的 Cloud Service Mesh。如果不同，請務必使用實際修訂版本。
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1246-9 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
如果輸出內容不為空白，表示已設定 CA 組合。如果 CA 套件遺失，請重新啟動 istiod，讓它重新掃描 webhook，並重新安裝 CA 套件。
檢查是否有附加元件插入失敗的情況。
如果您已啟用插入功能，但未看到 Pod 排程，請檢查下一個較高層級的抽象層級狀態。舉例來說，如果您正在執行部署作業，但沒有任何 Pod 排程，請使用下列指令檢查對應的複本集的狀態：
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
net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
這可能是網路連線問題。
請確認防火牆規則可透過通訊埠 15017 連線至 `istiod`。
no endpoints available for service 'istiod'
如果 `istiod` Pod 無法使用或尚未就緒，就可能發生這種情況。
檢查 `istiod` Pod，確認它們是否正在執行且就緒。
Service "istiod" not found
如果不存在 `istiod` 服務，就可能發生這種情況。
確認 Istio 安裝作業是否成功且正確無誤。
x509: certificate signed by unknown authority
這可能是 webhook 憑證問題。
請確認 caBundle 已正確設定在 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.
舊版 Istio 或已解除安裝的 Cloud Service Mesh 中的驗證 webhook 可能會干擾升級或安裝作業。
檢查叢集中是否仍有所有 Webhook，並移除參照已不再安裝的版本的 Webhook。
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
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],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."]]
