大家好，我是来自阿里巴巴云的李黄东。今天，我将分享Kubernetes监视公开类的第二个内容：如何发现Kubernetes中的异常服务和工作量。
该共享由三个部分组成：
1. Kubernetes异常定位具有疼痛点；
2.对于这些疼痛点，Kubernetes监视了如何更快，更准确和更全面的发现；
3.网络性能监控和中间件监控的典型案例分析。
在当前的Internet体系结构中，越来越多的公司采用诸如Microservices + Kubernetes之类的体系结构。这样的结构具有以下特征：
这三个疼痛点总结为三个方面：成本，效率和经验。在对这些痛点的响应中，让我们一起查看Kubernetes监视的数据系统，以了解如何更好地解决成本的三个主要问题，效率，经验。
下面的金塔代表了从顶部的密度或详细信息级别，以下信息越详细。协议和多语言方式，例如HTTP，MySQL和Redis。协议数据将进一步分析为简单地理解请求，并响应详细信息。
上一层是指标，指标主要是黄金指标，网络和库伯涅特系统中的指标。在它们的票据中，基于EBPF收集了黄金指示器和网络指标，因此它们没有入侵和支持各种协议。有了黄金指示器，我们可以知道该服务是否异常，是否慢以及是否影响用户。主要用于监视网络是否正常。Kubernetes系统中的指标是指原始的Kubernetes监视系统的cadvisor/metricserver/node offorter/npd指示器。
下一层是一个事件，事件直接告诉我们发生了什么。也许我们遇到的最多的是POD重新启动和图像的故障。我们不断存储Kubernetes事件并将其保存一段时间以促进定位问题。然后以事件的形式支持您的检查和健康检查。
顶层是警报。警报是监视系统的最后一个环。当我们发现某些特定异常可能会损害业务时，我们需要提醒指标和事件。警报当前支持Promql，智能警报支持智能算法来检测历史数据，以便找到潜在的异常事件。警报的配置支持动态阈值，并且通过调整灵敏度以避免编写死亡阈值来配置警报。在跟踪，指示器，事件和警报中，我们使用拓扑图将这些数据与Kubernetes实体相关联。每个节点都对应于Kubernetes Entity中的服务和工作负载。拓扑图，我们就像获取一张地图以快速识别拓扑图中的异常，进一步分析异常，并分析上游，下游，依赖性，以及依赖性和下游，依赖性以及影响力。
接下来，我们谈论Kubernetes异常服务和工作量的最佳实践。
首先，首先有指标。该指标可以反映服务的监视状态。我们应该尽可能多地收集各种指标，越好，越大，不限于黄金指标，使用指标，kubernetes本地指标，等于使根本原因我们必须具有跟踪数据。在多语言，多协议的情况下，我们必须考虑收集这些痕迹的成本，并尽可能地支持尽可能多的语言和更多的语言。最后，该事件进行了汇总和连接，以形成拓扑图，以进行体系结构感知分析以及上游和下游分析。
通过对这三种方法的分析，服务和工作量的异常通常会暴露出来，但我们不应停止进步的步骤。下次添加此异常。然后，我们必须再次回来。对于与警报相对应的这种异常配置，自动托管。
我们使用一些特定方案详细介绍：
（1）网络性能监视
网络性能监视以重新传输为例。重新传输的含义意味着发件人认为已经发生了包装现象，并发出了这些数据包。以图中的传输过程为例：
未观察到代码和日志。在这种情况下，很难找到原因。为了快速找到此问题，我们需要一组网络性能指标来提供定位基础，包括以下指标，P50，P95，P99指标来表示延迟，然后我们需要流量，重新传输，RTT，数据包丢失和其他指标为特征性条件。
以High为例：首先，我们看到拓扑的一面是红色的，红色判断的逻辑是基于延迟和错误。当您找到这个红色的一侧时，单击上面的边缘。相应的金指示灯。
单击底部底部左侧的此按钮，您可以查看当前服务的网络数据列表。我们可以遵循平均响应时间，重新传输，RTT排名。您可以看到第一个服务呼叫被延迟了。与此同时，我还看到它更高，它比其他服务高得多。这实际上是通过工具注射的错误，看起来更明显。经过此分析后，我们知道这可能是一个网络问题，我们可以进一步调查。经验丰富的开发通常包含在线指标，服务名称，IP和域名，以在互联网中找到同事进行调查，而不仅仅是告诉另一方该服务非常缓慢，因此对方的了解太少，并且不会积极地进行。进行调查，因为其他人不知道从哪里开始。当我们提供相关数据时，另一方将有参考，它将进一步促进它。
（2）DNS分析异常
第二个场景是DNS分析异常。DNS通常是协议通信的第一步。例如，HTTP请求是首先获取IP，即我们通常说的服务发现过程。第一步是问题，整个呼叫将直接失败。这是So值的钥匙，无法删除路径。Kubernetes群集中的所有DNS都遵循对核心的分析，因此它易于在核心上瓶颈。一旦出现问题，影响面也很大，并且整个集群可能无法可用。对于两个月前发生的一个活泼的例子，在著名的CDN Company Akamai中发生了DNS失败，这导致许多网站无法要访问Airbnb网站，事故持续了一个小时。
在Kubernetes群集中，DNS分析比较核心有三个场景：
这是Coredns的常见问题。您可以参考群集上是否存在类似问题：
接下来，让我们看一下Kubernetes Coredns可能出现问题的地方。首先，网络可能与核心之间的网络有问题。第二个是核心本身的问题，例如核心返回服务的错误代码，甚至是因为Corefile配置错误错误是错误的，因为导致返回值；第三点是与外部DNS通信，网络中断和性能问题；最后一个在外部DNS中不可用。
总结以下这些问题要检查的步骤：
首先，从客户端，首先查看请求内容和返回代码。如果返回，则错误代码描述是服务器的问题。如果这是一个缓慢的分析，则可以看到瀑布流的时间。
其次，看看网络是否正常，足以看到流量，重新传输，数据包丢失和RTT。
第三，检查服务器，查看流量，错误，延迟，饱和度的指标，并查看诸如CPU，内存，磁盘等的资源指标，还可以定位是否存在问题。
第四，以相同的方式查看外部DNS，我们可以通过请求跟踪，返回代码，网络流量，重新传输和其他指标来找到。
接下来，我们查看拓扑结构。首先，请参阅红线，该线表明有异常的DNS解析呼叫。单击此查看通话的金色指示器；单击以查看列表，弹出详细信息页面，然后检查请求详细信息。等待和下载三个进程，似乎指示器是正常的。接下来，我们单击以查看响应并发现响应是域名不存在。我将稍后在演示中显示，所以我不会在这里开始。
（3）完整的链接压力测试
第三个典型情况是全链接压力测试。对于这个场景的顶峰，这是场景的峰值的几倍。如何确保促销的稳定性，您需要验证系统的能力，系统稳定性评估并进行操作。能力计划和识别系统瓶颈。通常有几个步骤：首先进行预热，此时此时是否验证下降是否下降链接是正常的，逐渐添加流量直至峰值值，然后开始接触高度，即查看最大的TPS是可以支持的最大TPS，然后添加流量，然后这次交通主要是因为发现了最大的TP，并且强度的增加是破坏性的，因此该服务是否可以正常限制，那么在此过程中我们需要注意什么观点？
首先，对于我们的多语言和多协议微服务体系结构，例如Java，Golang，Python应用程序，这里有RPC，MySQL，Redis和Kafka应用程序层协议。IT用于验证系统的功能；对于系统的瓶颈和容量计划，我们需要使用指标来查看在各个流量水平下资源饱和的饱和，以确定是否是扩大容量的。对于复杂的体系结构，有一张全局图片的大图，可以帮助梳理上游和下游依赖和完整的链接体系结构，以确定爆炸警报。例如，CheckoutService这是一个关键服务。如果这一点出现，问题将产生很大的影响。
首先，各种语言和协议通信的黄金指标，通过查看列表来检查呼叫的详细信息
其次，单击节点详细信息以钻取使用资源指标，例如CPU，内存和其他使用资源指标
第三，整个拓扑图可以反映整个体系结构的形式。从全球架构的角度来看，可以将哪种服务识别为瓶颈，爆炸性半径的大小以及是否有必要进行高可用性。
（4）访问外部mysql
第四个场景是访问外部MySQL，首先查看访问外部MySQL的常见问题是什么：
接下来，查看拓扑图。中间的应用程序取决于外部MySQL服务。单击拓扑线，进一步查看金指示灯。单击查看列表以进一步查看请求和响应的详细信息。在同一时间，我们还可以查看网络性能指标。该表由当前拓扑中的网络数据根据源和目标进行分类。您可以查看请求的数量，错误数量，平均响应时间，插座的重新传输，套接字RTT，单击可以相应地对AboveArrows进行分类。
（5）多阶段体系结构
第五个典型案例是多镇定架构。多名家庭是指不同的租户，工作量，不同的团队和公共集群。通常，租户对应于名称空间，同时确保资源的逻辑隔离或物理隔离，它不会彼此影响，也不会彼此干扰。常见的情况是：企业的内部用户，团队对应于租户对应，并且以相同名称空间的网络不受限制，并且使用网络策略来控制不同命名空间之间的网络流量。第二个是SaaS提供商的多阶段体系结构。每个用户都对应一个名称空间，租户和平台都在不同的命名空间中。尽管Kubernetes的命名空间特征为多阶段的体系结构带来了便利，但它也带来了两个挑战：有许多挑战：许多名字空间，一个名字空间。查找信息变得非常麻烦，增加了管理成本和理解成本。第二，租户之间有交通隔离的要求。在更大的命名空间的情况下，通常不可能准确，全面地发现异常流量。第三个是对多协议和多语言的跟踪支持。管理非常痛苦，并且应用程序是多协议和多语言。为了支持痕迹，我们必须一一转换。
这是我们产品的首页。Kubernetes的实体分为一个名称空间，以支持查询以找到我想看到的群集。气泡图显示了相应的命名空间上的实体数量以及异常的实体数量。例如，框中的3个名称空间中有异常的豆荚。单击以进一步查看异常。主页页面是通过黄金索引对性能排序的概述，即场景的最高功能，以便可以快速查看哪个命名空间异常。
在拓扑映射中，如果有更多命名空间，您可以检查要通过过滤功能看到的命名空间，或快速地将您想通过搜索看到的名称空间放置。可以通过名称空间之间的界限来查看命名空间的流量，因此可以轻松查看从命名空间的哪些流量，是否有异常流动等等。
我们总结了上述场景的引入如下：
从这些情况下，进一步列出了常见案例：可用性检测，网络的健康检查，服务；观察保证升级中间件体系结构；新业务在线验证；服务性能优化；中间零件性能监控；方案选择；全链接压力测试等。
在上述介绍之后，我们总结了Kubernetes的产品价值，如下所示：
资料来源：阿里巴巴云