解决 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
向应用工作负载添加重试请求机制。
列出网关时返回空值
症状:在您成功创建 Anthos Service Mesh Gateway 后使用 kubectl get gateway --all-namespaces
列出网关时,该命令将返回 No resources found
。
GKE 1.20 及更高版本可能会发生此问题,因为 GKE Gateway Controller 会自动安装集群中的 GKE Gateway.networking.x-k8s.io/v1alpha1
资源。要解决此问题,请执行以下操作:
检查集群中是否有多个网关自定义资源:
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
如果列表显示了使用
apiVersion
networking.istio.io/v1beta1
的网关以外的条目,请在kubectl
命令中使用完整的资源名称或易辨认的简称。例如,运行kubectl get gw
或kubectl get gateways.networking.istio.io
(而非kubectl get gateway
)以确保列出 Istio Gateway。
如需详细了解此问题,请参阅 Kubernetes 网关和 Istio 网关。