这是一个创建于 3040 天前的主题，其中的信息可能已经有所发展或是发生改变。
随着 K8S 的成熟，越来越多的公司选择在生产中运用容器，我们现在看的第一个改变方式就是 DevOps 团队如何监控的这个过程中的变化。我们客户之中有一个最近在日志中提到， Kubernetes 显著改变了他们将服务带到市场的方式。现在我们看到的这种变化波及到监视和故障诊断经过编排的 Kubernetes 环境。
在这些变化之中，有些是由移动到了容器之中引起，有些是由移动到微服务上引起，剩下的一些是由 Kubernetes 的性能引起。这些变化可以被总结为服务，弹性扩容和分布。
服务
Kubernetes 是一个理解应用的逻辑和物理优化的中央大脑。 Kubernetes 负责将复杂的容器配置任务编排到你的基础设施，并且将那些分布组件连接呈现为统一的服务。实质上， Kubernetes 创建物理资源利用和 pods 的逻辑集合之间的桥梁，服务组成了你理解的应用程序。
如果对 Kubernetes 是做什么的没有一个持续更新的理解的话，那么你的监测系统最好追踪并且只在底层资源问题提醒。为了理解 Services 和 pods 的定义，你的监测系统需要 1 ）可以从 Kubernetes API 动态摄取相关信息， 2 ）将逻辑组容器集合映射到逻辑的应用程序，以及 3 ）不断计算聚合应用程序、服务和基础设施指标，允许您整体监控您的服务。
弹性扩容
有了 1.2 ， Kubernetes 可以扩容到 1000 多个节点集群。此外， 这个系统惊人的动态复制控制可以根据需要在几秒内调节额外的容器。既然它关闭了容器，他们可能不是最初被创建的，而只是暂时的。
因此，之前遗留的警报方法需要改变。警报需要适应两个方面。一方面——就像我们在服务部分描述的那样——警报需要动态地聚合度量所有相关来源，不论这些来源是多久前的，来测量服务和 pod 的整体性能。第二方面——资源层面警告提示，比如像 CPU ，内存或者是网络利用率都需要在来去的时候被应用到单独的容器或者是应用程序中去。为了操作正常，这些警报提示需要自动设置为 Kubernetes 创建的容器。警报提示也可以应用于 Pod 、服务和任何跟你的应用程序有关系的标签。
分布
Kubernentes 集群联合（ aka Ubernetes ）使得分发应用程序在多个数据中心和多个与怒提供者更加容易。这令提升分布应用程序性能有显著的提升，避免云锁定，甚至还可以控制成本。
另一方面呢？是的，一些团队的监测方法需要改变。特别是，那些习惯于运用利用由他们的云提供的监测的人需要使用一个可以在云端监控，警报，故障排除的系统。最重要的是，这个系统可以在云端流利地收集相同的指标来合理的聚合信息。
监测， Kubernetes ，以及你的应用环境
服务，弹性扩容，以及分布是三个能够运用 Kubernetes1.2 来影响你的环境的变化，但是在未来给你好的影响。转移到容器驱动，以微服务为导向的混合云部署（呼，真的好多术语）就是是很多软件操作目标所导向的。为了成功的转变，组织也需要重新思考他们怎样获得这些新环境的可视化。容器在这里添加了一个挑战因为他们是黑盒；微服务添加了一个挑战因为他们要调整如何思考你的应用程序；编排工具帮助弹性扩容你的基础设施，并且有一些你需要的关键元数据在这个勇敢的新世界。
哦，对了，今天 Sysdig 正式支持 Kubernetes1.2 即买即用。为了使之简单，我们利用 Deamon 来确认每个你用 Kubernetes 创建的主机都是通过 Sysdig Cloud 来自动仪表化的。
（如果需要转载，请联系我们哦，尊重知识产权人人有责；）
目前尚无回复
Select Language