Kubernetes:监控指南 kubernetes 监控

【摘要】本文讨论了 Kubernetes 对运维监控的改变，以及我们应该如何合理得监控一个由 Kubernetes 编排的容器化基础设施。

容器技术正在风靡基础设施世界，但是容器在解决或者说简化基础设施管理的过程中，也明显得增加了编排的复杂度。这就是 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，一些关键类型的度量都需要密切跟踪。

1. 运行中的 Pod 以及对应的 deployment。

2. 常用的资源维度，比如 CPU，内存使用率，以及磁盘 I/O。

3. 容器原生的维度。

4. 监控工具中服务发现特性所需要用到的基本的应用维度。

所有这些维度都需要使用 Kubernetes labels 来聚合，并使用来自 Kubernetes 以及容器技术的事件来关联。

Kubernetes 监控系类的第二部分指导你如何搜集和追踪所有这些你需要的数据。

• 搜集度量数据

不论你是想要通过组合Heapster（一个存储后端）和图形工具来追踪这些关键性能维度，还是使用你自己的设备的不同组件来集成监控工具，关于 Kubernetes 度量搜集的第三部分内容，你都有必要看一下。

• 出发吧！

使用 Kubernetes 彻底简化了容器的管理。但是他要求我们在多方面重新思考我们的监控策略，并且确保所有来自不同组件的这些关键维度都能被合理地搜集、聚合及追踪。我们希望我们的监控指南能帮你有效监控你的 Kubernetes 集群。回馈和建议不胜欢迎。