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

本部分介绍常见的 Cloud 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 网络命名空间，则可能会出现此问题。具体的原因可能是以下几个：

  • istio-cni 安装不完整
  • 工作负载 Pod 权限不足（缺少 CAP_NET_ADMIN 权限）

如果您使用 Istio CNI 插件，请验证您是否已完全按照说明进行操作。验证 istio-cni-node 容器是否已准备就绪，并检查日志。如果问题仍然存在，请建立与主机节点的安全 Shell (SSH) 连接，然后在节点日志中搜索 nsenter 命令，看看是否存在任何错误。

如果您不使用 Istio CNI 插件，请验证工作负载 Pod 是否具有 CAP_NET_ADMIN 权限（边车注入器会自动设置该权限）。

Pod 启动后连接被拒

当 Pod 启动并获取 connection refused 尝试连接到端点时，问题可能在于应用容器在 isto-proxy 容器之前启动。在这种情况下，应用容器将请求发送到 istio-proxy，但由于 istio-proxy 尚未侦听端口，因此连接被拒。

在这种情况下，您可以：

  • 修改应用的启动代码，以便向 istio-proxy 运行状况端点持续发出请求，直到应用收到 200 代码。istio-proxy 运行状况端点如下：

    http://localhost:15020/healthz/ready

  • 向应用工作负载添加重试请求机制。

列出网关时返回空值

症状：在您成功创建 Cloud Service Mesh Gateway 后使用 kubectl get gateway --all-namespaces 列出网关时，该命令将返回 No resources found。

GKE 1.20 及更高版本可能会发生此问题，因为 GKE Gateway Controller 会自动安装集群中的 GKE Gateway.networking.x-k8s.io/v1alpha1 资源。要解决此问题，请执行以下操作：

  1. 检查集群中是否有多个网关自定义资源：

    kubectl api-resources | grep gateway

    输出示例： 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. 如果列表显示了使用 apiVersion networking.istio.io/v1beta1 的网关以外的条目，请在 kubectl 命令中使用完整的资源名称或易辨认的简称。例如，运行 kubectl get gw 或 kubectl get gateways.networking.istio.io（而非 kubectl get gateway）以确保列出 Istio Gateway。

如需详细了解此问题，请参阅 Kubernetes 网关和 Istio 网关。