Troubleshooting the Istio CNI plugin

本页介绍如何解决 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 插件安装的信息，和 race condition repairing。

监控

CNI DaemonSet generates metrics，可用于监视 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 守护进程日志进行诊断。您还可以通过 istio_cni_install_ready 指标跟踪 CNI 安装准备情况。

Race 条件修复

Istio CNI DaemonSet 默认启用 race condition mitigation，这将驱逐在 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 持续出现 init 错误，请检查 init 容器 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 init 容器设置一个本地虚拟服务器，该服务器监听流量重定向目标入/出端口，并检查测试流量是否可以重定向到虚拟服务器。当 CNI 插件未正确设置 Pod 流量重定向时， istio-validation init 容器阻止 Pod 启动，以防止流量绕过。要查看是否有任何错误或意外的网络设置行为，在 istio-cni-node 中搜索 Pod ID。

CNI 插件出现故障的另一个症状是，在启动时，应用程序 Pod 不断被逐出。这通常是因为插件没有正确安装，因此无法设置 Pod 流量重定向。 CNI race repair logic 认为 Pod 由于竞争条件而损坏，并连续逐出 Pod。遇到此问题时，请检查 CNI DaemonSet 日志，以获取有关无法正确安装插件的信息。