人们听到“微服务”时，常常想到Kubernetes，这是一种声明式容器编排系统。由于具有声明性，Kubernetes将微服务视作实体，这在故障排除方面带来了一些难题。不妨看看为什么在Kubernetes环境下为微服务排除故障可能具有挑战性，以及一些相应的最佳实践。
想了解为什么为微服务排除故障可能具有挑战性，不妨看一个例子。
如果您在Kubernetes中有一个应用程序，就可以将它部署为pod，利用Kubernetes对其进行扩展。该实体是您可以监控的pod。若使用微服务，您不应该监控pod;相反，应该监控服务。所以您可能拥有整体式工作负载(部署为pod的单个容器)并对其进行监控，但如果您的服务由几个不同的pod组成，就需要了解这些pod之间的相互关系，才能明白服务是如何运行的，以及进行监控，如果不这么做，您认为的事件可能不是真正的事件(即可能对服务的运作并不重要)。
说到监控微服务，您需要在服务层面、而不是在pod层面进行监控。如果您尝试在pod层面进行监控，将与编排系统发生冲突，并且可能出岔子。
1、为微服务排除故障时常见问题的根源
为微服务排除故障时，网络、基础架构和应用程序等问题都很常见。
网络
网络层面的问题最难调试。如果问题出在网络上，您需要查看套接字层统计信息。底层网络拥有将A点连接到B点的套接字，因此您需要在网络层面查看往返时间，看看数据包是否在传输、是否存在路由问题等。
基础架构
pod重新启动时，基础架构问题会显露出来(Kubernetes中的崩溃循环)。发生这种情况的原因有很多。比如说，如果您的服务中有一个pod无法访问Kubernetes数据存储，Kubernetes会重新启动它。您需要跟踪支持该服务的那些pod的状态。如果您看到数次或频繁的pod重新启动，这就成了问题。
另一个常见的基础架构问题是Kubernetes API服务器过载，需要很长的时间才能响应。每当需要执行某个操作，pod都要与API服务器通信——因此，如果API服务器过载，这就成了问题。
第三个基础架构问题与域名系统(DNS)有关。在Kubernetes中，您的服务由名称来标识，名称则由DNS服务器来解析。如果这些解析很慢，您会开始看到问题。
应用程序
有几个常见的应用程序问题可能导致重新启动和错误。比如说，如果您的服务负载均衡未起作用，比如说由于您的URL发生了变化或者负载均衡系统没有执行正确的操作，就可能会导致某一个pod过载，从而导致它重新启动。
如果您的URL构建不正确，您会收到响应代码“404页面未找到”。如果服务器过载，您会收到500错误。这些是应用程序问题，只不过表现为基础架构问题。
2、微服务故障排除方面的最佳实践
以下是有效识别和排除微服务问题的两个最佳实践。
在服务层面聚合数据
您需要使用一款工具来提供在服务层面聚合的数据(即日志)，以便可以查看出现了多少次pod重新启动和错误代码等。这与当今大多数DevOps工程师使用的方法不同;在后一种方法中，每次pod重新启动都是单独的警报，导致工程师陷入到可能只是正常操作或Kubernetes自我纠正的警报中。
一些DevOps工程师可能想知道是否可以使用服务网格来聚合数据。虽然服务网格内置了可观察性工具，但您要小心：由于涉及大量数据，许多服务网格会采样数据;它们为您提供了原始数据，并提供了标签，以便您自行聚合数据。您真正需要的是一种工具，为您仅提供服务所需的数据以及服务层面的报告机制。
使用机器学习
在试图识别和解决微服务问题时，您需要监控属于服务的每个pod在如何运行。这意味着监控延迟、进程重启次数和网络连接错误等度量指标。有两种方法可以做到这一点：
- 设置阈值——比如说，如果有20多个错误，就设置警报。在像Kubernetes这样的动态系统中，这种方法有点原始，尤其是在使用微服务的情况下。
- 确立基准——使用机器学习来研究度量指标随时间的推移而如何变化，构建机器学习模型，以预测该指标在未来有怎样的表现。如果指标偏离基准，您会收到一则警报，指明哪些参数导致机器学习算法认为存在问题。
- 我建议别尝试设置阈值——你会被大量警报所淹没，这会导致警报疲劳。相反，应使用机器学习。久而久之，机器学习算法可以在问题出现之前发出警报。
参考：https://www.kubernetes.org.cn/9812.html
