Istio CNI 插件故障排除
此页面介绍了如何排除 Istio CNI 插件的问题。在阅读本文之前,您应该阅读CNI 安装和操作指南。
日志
Istio CNI 插件日志提供了有关插件如何根据PodSpec
配置应用程序 Pod 流量重定向的信息。
插件在容器运行时进程空间中运行,因此您可以在kubelet
日志中看到 CNI 日志条目。为了简化调试,CNI 插件还会将其日志发送到istio-cni-node
DaemonSet。
CNI 插件的默认日志级别为info
。要获取更详细的日志输出,您可以通过编辑values.cni.logLevel
安装选项并重新启动 CNI DaemonSet Pod 来更改级别。
Istio CNI DaemonSet Pod 日志还提供了有关 CNI 插件安装和竞争条件修复的信息。
监控
CNI DaemonSet生成指标,可用于监控 CNI 安装、就绪状态和竞争条件缓解。Prometheus 抓取注释(prometheus.io/port
、prometheus.io/path
)默认情况下会添加到istio-cni-node
DaemonSet Pod。您可以通过标准 Prometheus 配置收集生成的指标。
DaemonSet 就绪状态
CNI DaemonSet 的就绪状态指示 Istio CNI 插件是否已正确安装和配置。如果 Istio CNI DaemonSet 未就绪,则表明存在问题。查看istio-cni-node
DaemonSet 日志以进行诊断。您还可以通过istio_cni_install_ready
指标跟踪 CNI 安装就绪状态。
竞争条件修复
默认情况下,Istio CNI DaemonSet 已启用竞争条件缓解,这将驱逐在 CNI 插件就绪之前启动的 Pod。要了解哪些 Pod 被驱逐,请查找以下类似的日志行
2021-07-21T08:32:17.362512Z info Deleting broken pod: service-graph00/svc00-0v1-95b5885bf-zhbzm
您还可以通过istio_cni_repair_pods_repaired_total
指标跟踪修复的 Pod。
诊断 Pod 启动失败
CNI 插件的一个常见问题是 Pod 由于容器网络设置失败而无法启动。通常,故障原因会写入 Pod 事件,并且可以通过 Pod 描述查看。
$ kubectl describe pod POD_NAME -n POD_NAMESPACE
如果 Pod 不断出现初始化错误,请检查初始化容器istio-validation
日志中是否存在以下类似的“连接被拒绝”错误
$ kubectl logs POD_NAME -n POD_NAMESPACE -c istio-validation
...
2021-07-20T05:30:17.111930Z error Error connecting to 127.0.0.6:15002: dial tcp 127.0.0.1:0->127.0.0.6:15002: connect: connection refused
2021-07-20T05:30:18.112503Z error Error connecting to 127.0.0.6:15002: dial tcp 127.0.0.1:0->127.0.0.6:15002: connect: connection refused
...
2021-07-20T05:30:22.111676Z error validation timeout
istio-validation
初始化容器设置了一个本地虚拟服务器,该服务器侦听流量重定向目标入站/出站端口,并检查测试流量是否可以重定向到虚拟服务器。当 CNI 插件未正确设置 Pod 流量重定向时,istio-validation
初始化容器会阻止 Pod 启动,以防止流量绕过。要查看是否存在任何错误或意外的网络设置行为,请在istio-cni-node
中搜索 Pod ID。
CNI 插件出现故障的另一个症状是应用程序 Pod 在启动时不断被驱逐。这通常是由于插件未正确安装,因此无法设置 Pod 流量重定向。CNI 竞争修复逻辑认为 Pod 由于竞争条件而损坏,并不断驱逐 Pod。遇到此问题时,请检查 CNI DaemonSet 日志以获取有关插件为何无法正确安装的信息。