如何调试 Istio 网络配置？

以下我会告诉大家，每次我为 Istio 的设置调试时所按照的步骤，而且进行这些步骤其实无需有部署的经验。我常常都在 Istio 上犯了简单又愚蠢的错误，所以制作了一份清单，可以让我更迅速地找出问题所在。不多说，马上进入我平常调试的步骤吧。

1. 在句法逻辑上有没有错误呢？

•“istioctl analyze” 会准确地替你解析并验证配置当中的句法。

2. 它有设定到状态吗？

• 查找 istiod 设定的警告或错误，或者用 istioctl analyze 也能找到（可使用两种不同方法，一是将它导向你的实时集群处运行，实质上跟 istiod 相同；或者在本地运行，只是这样的验证能力有限）。•istioctl analyze 会进行很多常常漏掉的引用检查，例如，它会检查你在 VirtualService 用的主机名称是否与跟它绑定的 Gateway 相同。说实话，Istio 上的错误百分之九十九都是配置上的小错，istioctl analyze 固然能找出不少，但也无法全部抓获。所以下一步我们会从基础开始，由下而上检查起。

3. 名称正确吗？资源是放在对的命名空间里吗？

• 自从 Istio 1.4 版本，几乎所有资源都是根据命名空间控制范围的，包括像 VirtualService、EnvoyFilter、Gateway 和 ServiceEntry 等的网络配置。确保这些配置与你正在作业的服务处于同一个命名空间当中。• 这点非常重要，因为选择器是以命名空间为准的。其中一个常见配置错误就是在应用的命名空间（例如在 default）中发布针对 istio: ingressgateway 选择器的 VirtualService，用来将 VirtualService 绑定到 istio-system 命名空间中的 istio-ingressgateway 部署。这种做法只有当你的 VirtualService 同时在 istio-system 命名空间中才会有效。• 或者，在从应用的命名空间中汇入 VirtualService 的 istio-system 命名空间中，写入一个 Sidecar 资源。但一般情况下不建议这么做，只须于每个需要入口的应用中，部署一组 Envoy 入口就可以了。

4. 资源选择器正确吗？

• 检查你部署中的 pod，确保它们有正确的、一字不差的标签。• 正如上面所说，紧记资源选择器必须绑定到发布资源的命名空间。

到了这步，配置基本上都确保准确了，那接下来就看看运行时间系统如何处理配置吧。

你可以使用实验指令 istioclt describe 来大量自动进行这种分析。不过由于它还在实验阶段，我们并没有将它收录作为主要的调试方式，等到它的稳定性有所提升时，我们将会着墨更多。不过由于这个方法实在是非常容易操作，所以我们也在下面详细讲解。但 istioclt describe 更好的原因是，只有对 Envoy 有深入了解或者对 Envoy 文档有做过详细调研（这本来就是个好习惯）的人，才会觉得这些方法非常容易操作。

5. Envoy 有接受（ACK）这个配置吗？

•istioctl proxy-status pod_name -n pod_namespace• 我们必须确保所有配置的状态都是 SYNCED，否则就代表出错。如果发现错误，我们应该检查 Pilot 日志 —— 详情请跳到 #8。• 如果 Envoy 真的有 ACK 这个配置，请确保它在 Envoy 中有准确的呈现出来。

6. 这个配置在 Envoy 中有如预期般地表现出来吗？

•istioctl proxy-config type podname -n namespace 是我们的主要工具• 它的运作原理是透过从 Envoy 管理员终端收集数据（大多都在 /config_dump ），不过那里有海量的有用信息。- 我们需要基于我们写入的配置，寻找不同种类的 Envoy 配置。一般来说︰•VirtualService HTTP 规则在 Envoy 中呈现为路由。•istioctl proxy-config routes pod_name -n pod_namespace• 其他 VirtualService 规则（hostname 或 TCP 规则）也可以在监听器中呈现出来。• 当评估 VirtualServices 时，你应该找出在 Envoy 配置中出现的 hostname（在 Listener 或 Route 其中一处），就像你刚刚写入的一样，亦需设有 Route（例如当你有 50-50 对半的流量分配时）。•Gateway 应呈现为监听器• 找出跟你的 Gateway 端口绑定的监听器，而且 hostname 应该要与 Gateway 中的服务器相符。•DestinationRules 应呈现为集群。•ServiceEntries 应呈现为集群。

记得除非主机设有 ServiceEntry，否则 DestinationRules 是不会出现的。

•EnvoyFilters 会在你向 Istio 指定的位置出现。通常错误的 EnvoyFilter 会呈现为一个拒绝配置的 Envoy（亦即没有上述的 SYNCED 状态），这时候你就要检查 istiod（Pilot）日志，来查询 Envoy 因拒绝配置而产生的错误。•Sidecar 决定配置使用的范围，所以你一般只需要看上面的配置是否存在，就能知道 Sidecar 是否被正确使用。

7. istiod（Pilot）会在日志上记录错误吗？

如果你想看看 Pilot 有没有在日志上记录配置当中某个部份的错误，可以在检查前快速地把它删除再重新建立，就能确保它们会被记录到日志上。

• 如果配置完全没有在 Envoy 中出现 —— 代表 Envoy 没有 ACK 到它，或者它是 EnvoyFilter 配置 —— 那么可能配置是无效的（因为 Istio 无法在 EnvoyFilter 中验证配置的语法是否有效），或是它在 Envoy 配置中处于错误的位置。• 不论是上述两者中哪个情况，Envoy 都会拒绝无效配置，然后 Pilot 会记录该次错误，你一般可以搜寻你资源的名称去查找该错误。• 到这里，你需要判断配置无效的原因，到底是来自于你写入的配置的问题，还是 Pilot 所产生的错误。• 不论是哪种情况，请向我们报告当机的问题，让我们在 istioctl analyze 上进行额外检查，避免将来再发生同样错误。

Zack Butcher^[1] 是 Tetrate 的创始工程师，也是 @IstioMesh 的核心贡献者和 Istio: Up and Running^[2] 的联合作者。Tetrate 专注于开源以及提供服务与产品，帮助企业更轻松地投入使用 Istio 和 Envoy。如有任何有关服务网格的问题，欢迎发送电邮到 learn@tetrate.io^[3]。

引用链接

[1] Zack Butcher: https://www.tetrate.io/blog/author/zack/
[2] Istio: Up and Running: http://shop.oreilly.com/product/0636920203940.do
[3] learn@tetrate.io: mailto:learn@tetrate.io

加入云原生社区 Istio SIG

扫描下面的二维码加入云原生社区 Istio SIG， 与 Istio 专家共同交流。

点击下方“阅读原文”查看更多

↓↓↓