4个需要避免的常见Kubernetes监控陷阱
Kubernetes现在似乎已经成了管理和部署基于微服务和容器的应用的事实标准了,而且我们也很容易理解。要知道,Kubernetes是由CNCF支持,目前是最大的开源社区。它是DevOps友好的,它提供了混合云的优势。大家为什么不喜爱它呢?
但在最近的一项调查中,69%的受访者表示虽然Kubernetes是他们使用容器架构的首选,但是部署和管理Kubernetes却没有那么轻松。尽管Kubernetes相当灵活,但在操作工作流程上还是比较复杂,对应用程序性能管理(APM)必须进行有效管理才能发挥出Kubernetes所承诺的好处来。
重新考虑下你的Kubernetes监控策略
最近的一项CNCF调查显示,38%的受访者认为监控是其应用Kubernetes最大的的挑战之一,随着企业规模的增长,这个比例甚至达到了46%。那么,现代IT领导者如何在优化性能的同时又能简化Kubernetes监控,从而提高效率呢?
对于目前的Kubernetes监控手段而言,由于缺乏端到端可视性以及面临着容易出错的迁移,其实是存在不足的。以下就是监控Kubernetes时我们可能遇到的四个常见挑战以及如何解决这些挑战的建议。
挑战1:缺乏端到端的可视性
在Kubernetes传统监控中,最常见挑战之一就是缺乏对客户触点和分布式应用的端到端可视性。
结果,IT团队对最终用户体验以及应用程序性能如何影响业务的KPI毫不知情,也就无法知道哪些地方需要修复或者改进。
为了解决这个问题,使用基于正常性能的Kubernetes监控解决方案非常重要,并且,通过机器学习的强大功能,可以在出现问题时智能地向IT团队发出警报。
挑战2:告警风暴
虽然全面了解所有的应用问题看起来是个不错的选择,但是当多个问题同时出现时,它可能会迅速失控并且变成了工作的阻力。毕竟,您真的需要每次工作完成时或者在新的容器就位时被提醒一下吗?
如果没有对报警进行优先级分类,IT团队通常必须对每个问题的根本原因进行响应和归类- 这将导致糟糕的用户体验和收入损失。
强大的Kubernetes监控解决方案可以帮助您识别和解决确切的潜在问题,从代码行、单台设备、Kubernetes服务一直到单个容器。
挑战3:故障排除
应用停机的成本是十分惊人的 ,要知道,关键应用程序故障带来的损失可能高达每小时100万美元。时间就是金钱,IT团队在查找故障的根本原因的时候就不应该浪费时间。
我们所面临的问题是,现在大量监控工具缺乏在Kubernetes环境下进行自动化排障分析的能力,这就使故障排除成为耗时的噩梦,导致了高MTTR和减少停机时间。
为避免这种情况,请确保您的Kubernetes监控方案能够通过比较迁移前后的用户体验,提供对应用程序依赖性和验证迁移成功性的可视化能力。
挑战4:迁移至Kubernetes的易错性
将传统应用程序迁移到Kubernetes可能容易出错而且十分耗时。将现有的整体应用迁移到部署在Kubernetes上的微服务架构的这些公司缺乏对Kubernetes环境的可视化管理,是无法得知每个微服务或传统应用程序间是如何实时交互的。
借助通过统一平台提供集成化安装和统一监控的这种解决方案,IT团队就可以充分利用其现有的技能,流程和工具了。
在Kubernetes上提供完美的应用性能
使用Kubernetes在分布式多云环境中部署和运行应用程序的方式已经越来越流行,而且也没有放缓的迹象。但对于在Kubernetes上运行传统或微服务的应用厂家来说,传统监控方法是存在着明显的缺点的。
因此,各组织必须重新考虑他们在Kubernetes中的监控手段,用来简化复杂的企业工作流程,提高效率并提高生产力。通过对整个Kubernetes栈和Kubernetes编排应用的端到端的统一可视化,IT团队可以提供完美的应用体验,并确保他们的Kubernetes投资能够带来更好的收入。
本文转自DockOne-4个需要避免的常见Kubernetes监控陷阱
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
生产环境 VS 开发环境,关于Kubernetes的四大认识误区
最近我们澄清了一些大家在进行Kubernetes实验的时候所见到的常见的误解。其中最大的一个误解就是:在生产环境中运行Kubernetes和开发测试环境并无两样。 答案:是不一样的。 Avi Network公司的联合创始人兼首席技术官Ranga Rajagopalan认为:“对于Kubernetes,容器和微服务来说,实验环境和生产环境有巨大的不同。简单的运行和安全、可靠的运行是不一样的”。 Ranga Rajagopalan的意见中有一个重要的论点:上述问题不仅仅只是存在于Kubernetes,同样也存在于容器和微服务。部署容器相对简单;而在生产环境运维和缩放容器(包括容器化的微服务)是问题复杂的原因。 容器和容器的编排工具通常都是成套出现的。New Stack公司之前进行了一项调查,调查发现当组织为了解决运维所面对的挑战,去寻找更强大的技术的时候,容器反过来推动了Kubernetes的普及。虽然也有其他的工具,Kubernetes还是快速成为了编排工具和选择的代名词。像Rajagopalan说的那样,在沙箱里运行Kubernetes和在生产环境中运行Kubernetes有巨大的不同...
- 下一篇
什么是Kubernetes?科普文
在过去几年,整个行业逐渐转向开发更小更专业的程序。 越来越多的企业把原先庞大稳定的巨型系统拆分成解耦的独立的组件。 这个方向是正确的。 微型服务有以下几个优点: 快速部署:因为你可以快速的创建并且发布一个小型服务 更容易迭代:因为可以独立的为每个服务添加新功能 更加灵活:就算单个服务(组件)不能使用,其他的服务仍能正常运行。 从产品和开发的角度来说,微服务更完美。 那么这种文化转变是怎样影响基础设施的呢? 管理大规模的基础设施 当你只需要管理几个应用程序时,一切都很简单,你甚至可以用手指算出它们的个数,并且你有足够的时间专注与应用的发布和运维。 在大公司中,管理数百个应用虽然要求很高,但仍是可以做到的。 将会有几个团队专门用于开发,打包,以及发布应用。 另一方面,开发微服务将会带来新的挑战。 对于每个应用,你可能会在重构的时候,将一个应用拆分成四个组件(服务),那么你至少需要四倍的时间去开发,打包,发布这些微服务。 我们常常看到,一个小型服务由多种组件构成,例如前端应用,后台API,一个授权服务器,一个管理应用程序等等。实际上,当你开发了多个微服务,并且这些服务相互交互,你将会看到你的...
相关文章
文章评论
共有0条评论来说两句吧...