配置错误的网格往往不会大声失败,流量只是没有按你的预期路由,或者某个 Pod 从未获得你以为它会有的 sidecar。istioctl 有专门的命令来处理这类问题:在它们引起令人困惑的症状之前就捕获它们。本指南涵盖值得例行运行的那些。

istioctl analyze:在问题咬人之前发现配置问题

istioctl analyze
istioctl analyze -n my-namespace
istioctl analyze -A

analyze 检查你集群实际的 Istio 配置,而不仅仅是你即将应用的文件,并报告真实的问题:你明明打算启用注入、但没有为其打标签的命名空间,引用了不存在主机的 VirtualService,两个资源之间冲突的配置。不带命名空间参数运行时,检查当前上下文的默认命名空间;用 -n 检查特定命名空间,用 -A 检查集群中的每个命名空间。请在任何配置变更之后都养成运行它的习惯,而不仅仅是在明显出问题的时候;它经常能在问题变成症状之前就将其捕获。

istioctl validate:在应用之前检查文件

istioctl validate -f my-virtualservice.yaml

analyze 检查的是已经在集群中生效的内容,而 validate 则在你应用清单之前检查它,捕获 schema 错误和无效的字段值。在对任何与 Istio 相关的内容执行 kubectl apply 之前,把它作为常规步骤运行,这与对普通 Kubernetes 资源运行 kubectl apply --dry-run 是同样的反射动作。

istioctl proxy-status:每个 sidecar 都同步了吗?

istioctl proxy-status

这会列出 istiod 知道的每个 sidecar,以及每个 sidecar 是拥有最新配置(SYNCED)还是落后了(STALE,或显示错误)。当你刚应用的路由变更似乎没有在某个特定 Pod 上生效时,卡在 STALE 的 sidecar 往往就是真正的解释,在断定配置本身有误之前值得先检查。

istioctl proxy-config:这个 sidecar 实际在运行什么?

要直接深入某个 Pod 的 Envoy 配置,而不是靠行为去猜:

istioctl proxy-config routes <pod-name> -n <namespace>
istioctl proxy-config clusters <pod-name> -n <namespace>
istioctl proxy-config listeners <pod-name> -n <namespace>

这与本资料库中 Envoy 指南关于检查运行配置的底层思路相同,只是通过 Istio 自己的包装器,而不是直接使用 Envoy 的原始管理 API。

app 标签:容易漏掉,会悄悄破坏可视化

有一个特定的陷阱常见到值得单独指出。Istio(以及构建在它之上的工具,如下一篇指南介绍的 Kiali)依赖你的 Deployment 和 Service 上的 app 标签,来构建对哪些工作负载与哪些通信的准确描绘:

metadata:
  labels:
    app: reviews

省略它,不会有任何东西大声报错:Pod 仍会部署,sidecar 仍会注入,流量仍会流动。悄悄停止工作的是任何依赖该标签来识别工作负载的东西:Kiali 的服务图无法正确渲染连接,而某些以 app 为键的流量管理和遥测功能行为变得不可预测。如果网格在其他方面看起来健康,但它的可观测性工具显示的是令人困惑或不完整的画面,那么底层 Deployment 和 Service 上缺少 app 标签,是首先值得检查的事情之一,恰恰因为这种失败模式没有任何错误信息指向原因。

值得养成的合理习惯

在任何配置变更之后运行 istioctl analyze,在应用任何新内容之前运行 istioctl validate,并且每当某个变更似乎在某个特定位置没有生效时运行 istioctl proxy-status。这些都不能捕获一切,Istio 的配置面很大,但合在一起,它们能捕获那些既常见、又让人仅靠盯着 YAML 去调试而感到乏味的错误。