作者：Brendan Creane 编译：沈建苗

人们听到“微服务”时，常常想到Kubernetes，这是一种声明式容器编排系统。由于具有声明性，Kubernetes将微服务视作实体，这在故障排除方面带来了一些难题。不妨看看为什么在Kubernetes环境下为微服务排除故障可能具有挑战性，以及一些相应的佳实践。

想了解为什么为微服务排除故障可能具有挑战性，不妨看一个例子。

如果您在Kubernetes中有一个应用程序，就可以将它部署为pod，利用Kubernetes对其进行扩展。该实体是您可以监控的pod。若使用微服务，您不应该监控pod；相反，应该监控服务。所以您可能拥有整体式工作负载（部署为pod的单个容器）并对其进行监控，但如果您的服务由几个不同的pod组成，就需要了解这些pod之间的相互关系，才能明白服务是如何运行的，以及进行监控，如果不这么做，您认为的事件可能不是真正的事件（即可能对服务的运作并不重要）。

说到监控微服务，您需要在服务层面、而不是在pod层面进行监控。如果您尝试在pod层面进行监控，将与编排系统发生冲突，并且可能出岔子。

为微服务排除故障时

常见问题的根源

为微服务排除故障时，网络、基础架构和应用程序等问题都很常见。

网络

网络层面的问题难调试。如果问题出在网络上，您需要查看套接字层统计信息。底层网络拥有将A点连接到B点的套接字，因此您需要在网络层面查看往返时间，看看数据包是否在传输、是否存在路由问题等。

基础架构

pod重新启动时，基础架构问题会显露出来（Kubernetes中的崩溃循环）。发生这种情况的原因有很多。比如说，如果您的服务中有一个pod无法访问Kubernetes数据存储，Kubernetes会重新启动它。您需要跟踪支持该服务的那些pod的状态。如果您看到数次或频繁的pod重新启动，这就成了问题。

另一个常见的基础架构问题是Kubernetes API服务器过载，需要很长的时间才能响应。每当需要执行某个操作，pod都要与API服务器通信——因此，如果API服务器过载，这就成了问题。

第三个基础架构问题与域名系统（DNS）有关。在Kubernetes中，您的服务由名称来标识，名称则由DNS服务器来解析。如果这些解析很慢，您会开始看到问题。

应用程序

有几个常见的应用程序问题可能导致重新启动和错误。比如说，如果您的服务负载均衡未起作用，比如说由于您的URL发生了变化或者负载均衡系统没有执行正确的操作，就可能会导致某一个pod过载，从而导致它重新启动。

如果您的URL构建不正确，您会收到响应代码“404页面未找到”。如果服务器过载，您会收到500错误。这些是应用程序问题，只不过表现为基础架构问题。

微服务故障排除方面的佳实践

以下是有效识别和排除微服务问题的两个佳实践。

1. 在服务层面聚合数据

您需要使用一款工具来提供在服务层面聚合的数据（即日志），以便可以查看出现了多少次pod重新启动和错误代码等。这与当今大多数DevOps工程师使用的方法不同；在后一种方法中，每次pod重新启动都是单独的警报，导致工程师陷入到可能只是正常操作或Kubernetes自我纠正的警报中。

一些DevOps工程师可能想知道是否可以使用服务网格来聚合数据。虽然服务网格内置了可观察性工具，但您要小心：由于涉及大量数据，许多服务网格会采样数据；它们为您提供了原始数据，并提供了标签，以便您自行聚合数据。您真正需要的是一种工具，为您仅提供服务所需的数据以及服务层面的报告机制。

2.使用机器学习

在试图识别和解决微服务问题时，您需要监控属于服务的每个pod在如何运行。这意味着监控延迟、进程重启次数和网络连接错误等度量指标。有两种方法可以做到这一点：

设置阈值——比如说，如果有20多个错误，就设置警报。在像Kubernetes这样的动态系统中，这种方法有点原始，尤其是在使用微服务的情况下。

确立基准——使用机器学习来研究度量指标随时间的推移而如何变化，构建机器学习模型，以预测该指标在未来有怎样的表现。如果指标偏离基准，您会收到一则警报，指明哪些参数导致机器学习算法认为存在问题。

我建议别尝试设置阈值——你会被大量警报所淹没，这会导致警报疲劳。相反，应使用机器学习。久而久之，机器学习算法可以在问题出现之前发出警报。

参考：https://www.kubernetes.org.cn/9812.html