本文讲的是Kubernetes集群监控指南【编者的话】本文讨论了 Kubernetes 对运维监控的改变，以及我们应该如何合理得监控一个由 Kubernetes 编排的容器化基础设施。
【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。
容器技术正在风靡基础设施世界，但是容器在解决或者说简化基础设施管理的过程中，也明显得增加了编排的复杂度。这就是 Kubernetes 来解救我们的地方。正如指挥家指挥乐队一样，Kubernetes 监控容器集合：自动启动、停止、创建，以及删除容器，确保应用持续工作。
Kubernetes 通过创建抽象层，比如 pods 和 services，来简化容器化设施的管理。我们不再需要担心容器运行在哪里，或者它们是否有足够资源来运行。但是这仍然无法改变一个事实，即为了确保高性能，我们需要监控我们的应用，运行在其内的容器，以及 Kubernetes 本身。
Kubernetes 时代针对监控的重新思考
就像容器已经完全转变了我们思考如何在虚拟机上运行服务的方式，Kubernetes 也改变了我们和容器交互的方式。好消息是，只要有合适的监控，Kubernetes 固有的抽象层就会对你的设备提供综合视图，即使容器和应用在经常移动。但是 Kubernetes 的监控也要求我们重新思考和调整我们的策略，因为它和监控传统的主机比如虚机和物理机有好多方面的不同。
tags 和 labels 变得非常重要
容器及其编排完全由 Kubernetes 来管理之后，labels 成了当前我们和 pod 以及容器交互的唯一方式。这就是它们对监控绝对重要的原因，因为你的设备的跨不同层次抽象的所有的度量和事件都将使用 labels 来切片。用有逻辑且易于理解的方式来定义labels非常重要，这样你的度量才可能有用。
有更多组件需要监控
传统的以主机为中心的设施，我们习惯于在两个层次监控：应用以及运行它们的主机。现在由于容器处在中间层，以及 Kubernetes 本身也需要监控，因此有 4 个不同的组件需要监控并且搜集度量信息。
应用一直处于移动中
Kubernetes 基于调度策略动态调度应用，因此你不能总是知道应用运行在哪里。但是他们仍然需要被监控。这就是为什么在服务发现的时候，使用一个监控系统或者工具是有必要的。它将自动调整移动中的容器的度量搜集，因此应用可在不中断的情况下持续被监控。
为分布式集群做准备
Kubernetes 有能力跨多数据中心以及潜在的不同云提供商，分发容器应用。这意味着，度量必须从所有这些不同来源中搜集并聚合。
关于所有这些新的 Kubernetes 原生的监控挑战以及如何克服它们，我们最近发布了一篇文章：深入理解Kubernetes 监控。这系列文章的第一部分就提到了如何在 Kubernetes 时代调整你的监控策略。
监控维度
不论你是使用 Heapster 数据还是 Kubernetes 整合的监控工具及其 API，一些关键类型的度量都需要密切跟踪。
- 运行中的 Pod 以及对应的 deployment。
- 常用的资源维度，比如 CPU，内存使用率，以及磁盘 I/O。
- 容器原生的维度。
- 监控工具中服务发现特性所需要用到的基本的应用维度。
所有这些维度都需要使用 Kubernetes labels 来聚合，并使用来自 Kubernetes 以及容器技术的事件来关联。
Kubernetes 监控系类的第二部分指导你如何搜集和追踪所有这些你需要的数据。
搜集度量数据
不论你是想要通过组合Heapster（一个存储后端）和图形工具来追踪这些关键性能维度，还是使用你自己的设备的不同组件来集成监控工具，关于 Kubernetes 度量搜集的第三部分内容，你都有必要看一下。
出发吧！
使用 Kubernetes 彻底简化了容器的管理。但是他要求我们在多方面重新思考我们的监控策略，并且确保所有来自不同组件的这些关键维度都能被合理地搜集、聚合及追踪。我们希望我们的监控指南能帮你有效监控你的 Kubernetes 集群。回馈和建议不胜欢迎。
原文链接：Kubernetes : a monitoring guide （翻译：池剑锋）
原文发布时间为：2017-05-30
本文作者：池剑锋
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：Kubernetes集群监控指南
