如何提升Kubernetes可见性

NGINX | 2021年3月08日

编者：本文是一个由10篇文章组成的系列中的一篇：

还可免费下载包含本系列全部博客的电子书《推动Kubernetes从测试走向生产》。
采用微服务有助于加快数字体验的交付，但微服务架构也可能使这些体验更加脆弱。开发人员在快速推出新应用时，现有架构可能会增加服务中断和安全风险，还可能因低效的故障排除或修复本可避免的问题而浪费时间。在生产级Kubernetes系列的第2篇博客中，我们将探讨提供流量可见性的组件如何降低微服务环境的复杂性并提升安全性。

提升可见性，获取洞察

首先，我们来看几个定义：

可见性：能够看到或被看到的状态
洞察：对某个人或事物的深入理解

在StackRox 2020年开展的一项调查中，75%的Kubernetes用户认为可见性是“必备”能力。我们也认为可见性对Kubernetes至关重要，因为要了解部署了哪些内容可能尤其困难。然而，在F5的2021年《应用策略现状》（SOAS）调查中，95%的受访者表示，尽管他们拥有海量数据，却缺少所需的洞察，无法充分了解应用性能、安全性和可用性，以保护并持续改进其基础设施和业务。那么，洞察为何如此重要，又该如何获得洞察？

借助洞察，您可以：

通过检测漏洞和潜在攻击途径，增强安全性与合规性
抢先发现问题，减少服务中断和停机时间
通过查找应用问题的根本原因，提高故障排除效率
确认流量仅流向预期目的地
准确了解Kubernetes环境中正在运行的内容，以及这些内容是否已正确配置并得到妥善保护
根据延迟和历史性能数据，判断资源用量是否合理
根据以往的流量模式预测季节性需求
以响应时间衡量性能，跟踪性能是否符合服务级别协议（SLA），并在问题影响用户体验之前提供预警

要获得深入洞察，需要两类可观测性数据：实时数据和历史数据。实时数据可用于诊断当前问题的根源，而历史数据则有助于判断哪些情况属于“正常”，哪些属于异常。结合使用这两类可观测性数据，可以深入了解应用和Kubernetes的性能。

与其他技术投资一样，要从中获益，也需要制定相应策略。SOAS报告还指出，由于招聘和员工发展、战略和流程等组织因素，以及未能就数据的用途、使用时机和使用者达成共识，人们无法获得有价值的洞察。相关调查结果包括：

相关技能：技术专业人才短缺已是不争的事实，47%的受访者表示难以找到所需人才，也印证了这一点。
数据共享举措：仅12%的受访者已制定相关流程和策略，向业务决策者反馈数据，帮助他们了解采用（或未采用）韧性技术对业务的影响。
可观测性的用途：大多数受访者以被动方式使用遥测数据（即用于故障排除），仅有24%的受访者主动利用数据和洞察来监测潜在的性能下降，另有16%的受访者用于跟踪SLA表现。

本文余下部分将重点介绍洞察的技术层面。敬请关注后续有关战略、流程及其他主题的博客文章。

NGINX 如何提供帮助

我们知道，大多数Kubernetes部署已在使用监控工具，无需再增加一个。因此，我们为NGINX Plus API添加了检测功能，便于导出指标，并支持与常用工具集成，例如OpenTracing以及Grafana和Prometheus，帮助您全面了解集群内的性能状况。通过深度追踪，您可以有针对性地洞察应用性能和可用性，了解请求在微服务应用中的处理过程。

深入了解入站和出站（南北向）流量
NGINX Ingress Controller可帮助您深入了解进出Kubernetes集群的流量。您是否知道，有三种基于NGINX的常用Ingress控制器？它们并非都已达到生产就绪状态，选择不当可能会让微服务策略变得更加复杂，而非得到改进。我们的博客文章等等，我使用的是哪种适用于Kubernetes的NGINX Ingress Controller？对这些选项进行了比较，帮助您根据自身需求做出合适的选择。
深入了解东西向流量
NGINX Service Mesh可帮助深入了解容器化应用之间的流量。

继续阅读，了解我们如何帮助解决两个常见问题：

我的应用运行缓慢（或已宕机！）
我的集群或平台资源即将耗尽

如果想了解这项技术的实际应用，请观看这场由NGINX和Grafana专家参与的直播演示及问答活动。他们将演示如何实时监控关键的负载均衡和性能指标、将指标导出到Prometheus，以及创建Grafana仪表板来查看累计性能。

问题：我的应用运行缓慢（或已停机！）

是否怀疑遭到DDoS攻击？用户是否报告网站出现错误？只有准确定位问题所在，才能着手解决。

使用NGINX Ingress Controller进行实时监控
借助NGINX Plus，由实时活动监控仪表板NGINX Plus API提供支持的实时活动监控仪表板可显示数百项关键负载和性能指标。您可以查看精细到单个Pod级别的详细信息，从而快速、轻松地衡量应用响应时间并诊断问题根源。随着Kubernetes环境扩展，系统会自动为新增的每个NGINX Ingress Controller实例提供仪表板。例如，“HTTP上游”选项卡中的两列可让您即时了解应用和基础设施的状态：
- 请求数：如果每秒请求数（Req/s）低于该应用的正常水平（例如，正常水平为每秒40个请求，但当前仅为每秒5个请求），则Ingress Controller或应用可能配置有误。
- 响应时间：如果响应时间不超过10毫秒（ms），则表示运行状况良好。延迟达到30–40 ms或更高，表明上游应用存在问题。
NGINX Ingress Controller的Stub Status
使用NGINX Open Source时，NGINX Ingress Controller提供一个状态页面，用于报告8项基本指标。
NGINX Service Mesh中的OpenTracing
NGINX Service Mesh通过NGINX OpenTracing module支持OpenTracing。截至本文撰写时，该模块支持Datadog、LightStep、Jaeger和Zipkin。

问题：集群或平台资源即将耗尽

遇到HTTP错误？503和40x错误表示资源存在问题，而502错误则表示配置更改未生效。请使用历史数据诊断哪些资源可能即将耗尽。

使用NGINX Ingress Controller记录日志
诊断网络问题的第一步是查看NGINX Ingress Controller日志。其中，每条日志记录都标注了相关的Kubernetes服务，错误条目会指出关联的服务。日志包含通过Ingress Controller的所有流量的详细信息，包括时间戳、源IP地址和响应状态码。还可以将日志导出到Datadog、Grafana和Splunk等常用聚合平台。
Prometheus指标
NGINX Ingress Controller广受欢迎的功能之一，是其不断扩充的Prometheus指标列表，其中包括网络性能和Ingress Controller流量指标。借助NGINX Plus，NGINX Ingress Controller可导出指标，涵盖连接、缓存、由在内存区域中共享数据的NGINX工作进程组处理的HTTP和TCP/UDP流量、由后端服务器组处理的HTTP和TCP/UDP流量等。NGINX Service Mesh可部署Prometheus服务器，该服务器使用NGINX Plus API从NGINX Service Mesh边车和NGINX Ingress Controller Pod中抓取指标。如果希望使用现有的Prometheus部署，我们还提供了可添加到Prometheus配置文件中的抓取配置。
Grafana仪表板
我们为NGINX Ingress Controller和NGINX Service Mesh提供官方Grafana仪表板，用于直观呈现Prometheus Exporter公开的指标。用户看重这些数据的精细粒度，包括精确到毫秒的详细信息、逐日叠加对比和流量峰值。例如，NGINX Service Mesh仪表板可显示任一服务或Pod的流量以及受监控的活跃Pod数量，从而指示Pod是否已达到容量上限。