使用 kubectl get pods 时,应该注入边车的 pod 未显示,但 kubectl get replicaset 中的相应副本集却存在。
请按照以下步骤排查 Sidecar 注入问题。
验证您的命名空间或 Pod 是否具有正确的注入标签。
如果您运行的是单个修订版本的 Istio(默认情况),请验证您的命名空间或 Pod 规范是否具有 istio-inject=enabled 标签。
如果您运行的是多个修订版本 Istio(用于零停机时间迁移、多个控制平面等),请验证命名空间或 pod 规范是否具有正确的 istio.io/rev=REVISION 标签,其中 REVISION 是 istiod 上的 Cloud Service Mesh 修订版本号,对应于您选择的 Cloud Service Mesh 版本。如需详细了解修订版本标签,请参阅注入边车代理。
验证您的 Istio Sidecar 注入 Webhook 是否存在以及是否具有 CA 软件包。
Sidecar 注入器 Webhook(用于自动执行 Sidecar 注入)需要使用 CA 软件包,以便与 API 服务器和 istiod 建立安全连接。此 CA 软件包由 istiod 修补到配置中,但有时可能会被覆盖(例如,如果您重新应用 Webhook 配置)。
您可以使用以下命令验证 CA 软件包是否存在。该命令包含 istio-sidecar-injector-asm-1228-5,它特定于此版本的 Cloud Service Mesh。如果实际修订版本不同,请确保使用它。
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1228-5 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
如果输出不为空,则说明 CA 软件包已配置。如果缺少 CA 软件包,请重启 istiod 以使其重新扫描 Webhook 并重新安装 CA 软件包。
检查是否存在 Sidecar 注入故障。
如果您已启用注入,但未看到 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
这可能是网络钩子证书问题。
检查网络钩子上是否已正确设置 caBundle。
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 的验证网络钩子可能会干扰升级或安装。
检查以确认所有网络钩子仍在集群中,并移除所有引用不再安装的版本的网络钩子。
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"]],["最后更新时间 (UTC):2025-08-28。"],[],[],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.22/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.22/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.22/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-1228-5`, 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-1228-5 -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.22/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."]]