Kubernetes监控方面要避免的四个常见陷阱

译文
作者：布迦迪编译 2018-11-15 08:07:33

开发

前端

云计算 虽然在最近一次调查中69%的受访者表示Kubernetes是容器编排方面的首选，但是部署和管理Kubernetes未必轻而易举。尽管Kubernetes具有灵活性，但是仍存在操作工作流程方面的复杂性――许多涉及应用性能管理(APM)，需要积极有效地应对，才能使Kubernetes实现承诺的好处。

【51CTO.com快译】Kubernetes(K8S)现在似乎是管理和部署基于微服务和容器的应用程序的事实上标准，不难理解个中原委。Kubernetes是***的开源社区，得到了云原生计算基金会(CNCF)的支持，对DevOps友好，还具有混合云的优势。为啥不爱呢?

[[249401]]

虽然在最近一次调查中69%的受访者表示Kubernetes是容器编排方面的***，但是部署和管理Kubernetes未必轻而易举。尽管Kubernetes具有灵活性，但是仍存在操作工作流程方面的复杂性――许多涉及应用性能管理(APM)，需要积极有效地应对，才能使Kubernetes实现承诺的好处。

重新思考你的Kubernetes监控策略

CNCF最近的一项调查显示，38%的受访者认为监控是采用Kubernetes面临的***挑战之一;企业规模扩大后，这个挑战变得更为艰巨。那么，现代IT***如何简化Kubernetes监控以提高效率，同时优化性能?

目前的Kubernetes监控方法因几个原因而不尽如人意，比如缺乏端到端可见性和容易出错的迁移。以下是你在监控Kubernetes时可能遇到的四个常见挑战和如何克服这些挑战的提示。

***个挑战：缺乏端到端可见性

传统Kubernetes监控的最常见挑战之一是缺乏端到端可见性，因而无法深入了解客户接触点和分布式应用程序。

因此，IT团队无法深入了解最终用户体验和应用程序性能如何影响公司的关键绩效指标(KPI)，因而无法知道修复或改进什么。

为了解决这个问题，使用这样的Kubernetes监控解决方案很重要：为正常的性能列出基准，并借助机器学习的强大功能，出现问题时可以智能化地向IT团队发出警报。

第二个挑战：警报风暴

虽然深入了解所有应用程序问题似乎是好事，但是多个问题同时出现时，可能会迅速失控、成为障碍。毕竟，每当工作完成或新容器启用时，你果真需要警报吗?

如果无法为警报确定优先级，IT团队通常不得不响应和排查每个问题的根本原因，这导致糟糕的用户体验和收入损失。

可靠的Kubernetes监控解决方案可以帮助你识别和解决具体的底层问题，深入到某一行代码、某个设备、Kubernetes服务甚至某一个容器。

第三个挑战：故障排查方面的难题

应用程序停运的代价可能很惨重，关键的应用程序故障每小时损失可能高达100万美元。时间就是金钱，IT团队在检查问题的根本原因时不该浪费时间。

问题是，今天的许多监控工具都无法在Kubernetes环境中执行自动化的根本原因分析，使故障排查成为耗费时间的棘手难题，常常导致平均修复时间(MTTR)很长、停机时间延长。

为了避免这种情况，确保你的Kubernetes监控解决方案能够深入了解应用程序的依赖项，并通过比较迁移前后的用户体验来验证迁移成效。

第四个挑战：迁移到Kubernetes容易出错

将传统应用程序迁移到Kubernetes可能容易出错，且很耗时间。一些公司将现有的整体式应用程序迁移到部署在Kubernetes上的微服务，但如果对Kubernetes环境缺乏可见性，就无法看到每个微服务或传统应用程序的实时交互情况。

借助可通过单一管理平台提供一步式安装和统一监控的解决方案，IT团队就可以充分利用现有的技能、流程和工具。

让Kubernetes提供***的应用程序性能

利用Kubernetes改变公司在分布式多云环境中部署和运行应用程序的方式已非常流行，而且丝毫没有减缓的迹象。但对于在Kubernetes上运行传统应用程序或基于微服务的应用程序的企业来说，传统监控方法的缺点显而易见。

因此，企业须重新考虑Kubernetes监控方法，以便简化复杂的企业工作流程、改善成本效率并提高生产力。如果对整个Kubernetes堆栈和Kubernetes编排的应用程序拥有端到端统一可视性，IT团队就能提供***的应用程序体验，并确保Kubernetes方面的投入带来更好的业务成果。

原文标题：4 Common Kubernetes-Monitoring Traps to Avoid，作者：Eric Johanson

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】