随着K8S的成熟，越来越多的公司选择在生产中运用容器，我们现在看的第一个改变方式就是DevOps团队如何监控的这个过程中的变化。我们客户之中有一个最近在日志中提到，Kubernetes显著改变了他们将服务带到市场的方式。现在我们看到的这种变化波及到监视和故障诊断经过编排的Kubernetes环境。
在这些变化之中，有些是由移动到了容器之中引起，有些是由移动到微服务上引起，剩下的一些是由Kubernetes的性能引起。这些变化可以被总结为服务，弹性扩容和分布。

1.服务

Kubernetes是一个理解应用的逻辑和物理优化的中央大脑。Kubernetes负责将复杂的容器配置任务编排到你的基础设施，并且将那些分布组件连接呈现为统一的服务。实质上，Kubernetes创建物理资源利用和pods的逻辑集合之间的桥梁，服务组成了你理解的应用程序。
如果对Kubernetes是做什么的没有一个持续更新的理解的话，那么你的监测系统最好追踪并且只在底层资源问题提醒。为了理解Services和pods的定义，你的监测系统需要1）可以从Kubernetes API动态摄取相关信息，2）将逻辑组容器集合映射到逻辑的应用程序，以及3）不断计算聚合应用程序、服务和基础设施指标，允许您整体监控您的服务。

2.弹性扩容

有了1.2，Kubernetes可以扩容到1000多个节点集群。此外，这个系统惊人的动态复制控制可以根据需要在几秒内调节额外的容器。既然它关闭了容器，他们可能不是最初被创建的，而只是暂时的。
因此，之前遗留的警报方法需要改变。警报需要适应两个方面。一方面——就像我们在服务部分描述的那样——警报需要动态地聚合度量所有相关来源，不论这些来源是多久前的，来测量服务和pod的整体性能。第二方面——资源层面警告提示，比如像CPU，内存或者是网络利用率都需要在来去的时候被应用到单独的容器或者是应用程序中去。为了操作正常，这些警报提示需要自动设置为Kubernetes创建的容器。警报提示也可以应用于Pod、服务和任何跟你的应用程序有关系的标签。

3.分布

Kubernentes集群联合（aka Ubernetes）使得分发应用程序在多个数据中心和多个与怒提供者更加容易。这令提升分布应用程序性能有显著的提升，避免云锁定，甚至还可以控制成本。
另一方面呢？是的，一些团队的监测方法需要改变。特别是，那些习惯于运用利用由他们的云提供的监测的人需要使用一个可以在云端监控，警报，故障排除的系统。最重要的是，这个系统可以在云端流利地收集相同的指标来合理的聚合信息。

监测，Kubernetes，以及你的应用环境

服务，弹性扩容，以及分布是三个能够运用Kubernetes1.2来影响你的环境的变化，但是在未来给你好的影响。转移到容器驱动，以微服务为导向的混合云部署（呼，真的好多术语）就是是很多软件操作目标所导向的。为了成功的转变，组织也需要重新思考他们怎样获得这些新环境的可视化。容器在这里添加了一个挑战因为他们是黑盒；微服务添加了一个挑战因为他们要调整如何思考你的应用程序；编排工具帮助弹性扩容你的基础设施，并且有一些你需要的关键元数据在这个勇敢的新世界。
哦，对了，今天Sysdig正式支持Kubernetes1.2即买即用。为了使之简单，我们利用Deamon来确认每个你用Kubernetes创建的主机都是通过Sysdig Cloud来自动仪表化的。点击这里阅读更多关于监测Kubernetes的博客，或者用你自己的环境试一试。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/mXeV0Qy4t5eyDW82ytX_VQ

创作场景

Kubernetes 改变监控的三种方式