解决 Anthos Service Mesh 中的流量管理问题

本部分介绍常见的 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
    
  • 向应用工作负载添加重试请求机制。