本部分介绍常见的 Anthos Service Mesh 问题以及如何解决这些问题。如果您需要其他帮助，请参阅获取支持。
Istiod 日志中的 API 服务器连接错误
如果您看到类似于以下内容的错误，则说明 Istiod 无法连接到 apiserver：
error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused
您可以使用正则表达式字符串 /error.*cannot list resource/ 在日志中查找此错误。
此错误通常是暂时性的，如果您使用 kubectl 访问了代理日志，则问题可能已解决。此错误通常是因为某些事件（例如，未使用高可用性配置的 API 服务器由于升级或自动扩缩更改而重新启动）使得 API 服务器暂时不可用而导致的。
istio-init 容器崩溃
如果 Pod iptables 规则未应用于 Pod 网络命名空间，则可能会出现此问题。具体的原因可能是以下几个：
- Pod 安全政策 (PSP) 过于严格
- istio-cni 安装不完整
- 工作负载 Pod 权限不足（缺少
CAP_NET_ADMIN权限）
如果您使用的是限制 CAP_NET_ADMIN 权限的 Pod 安全政策，请改用 Istio CNI 插件。
如果您使用 Istio CNI 插件，请验证您是否已完全按照说明进行操作。验证 istio-cni-node 容器是否已准备就绪，并检查日志。如果问题仍然存在，请建立与主机节点的安全 Shell (SSH) 连接，然后在节点日志中搜索 nsenter 命令，看看是否存在任何错误。
如果您不使用 Istio CNI 插件或 Pod 安全政策，请验证工作负载 Pod 是否具有 CAP_NET_ADMIN 权限（Sidecar 注入器会自动设置该权限）。
Pod 启动后连接被拒
当 Pod 启动并获取 connection refused 尝试连接到端点时，问题可能在于应用容器在 isto-proxy 容器之前启动。在这种情况下，应用容器将请求发送到 istio-proxy，但由于 istio-proxy 尚未侦听端口，因此连接被拒。
在这种情况下，您可以：
修改应用的启动代码，以便向
istio-proxy运行状况端点持续发出请求，直到应用收到 200 代码。istio-proxy运行状况端点如下：http://localhost:15020/healthz/ready向应用工作负载添加重试请求机制。