内容简介：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，一些关键类型的度量都需要密切跟踪。
- 运行中的 Pod 以及对应的 deployment。
- 常用的资源维度，比如 CPU，内存使用率，以及磁盘 I/O。
- 容器原生的 维度 。
- 监控工具中服务发现特性所需要用到的基本的应用维度。
所有这些维度都需要使用 Kubernetes labels 来聚合，并使用来自 Kubernetes 以及容器技术的事件来关联。
Kubernetes 监控系类的 第二部分 指导你如何搜集和追踪所有这些你需要的数据。
搜集度量数据
不论你是想要通过组合Heapster（一个存储后端）和图形工具来追踪这些关键性能维度，还是使用你自己的设备的不同组件来集成监控工具，关于 Kubernetes 度量搜集的 第三部分 内容，你都有必要看一下。
出发吧！
使用 Kubernetes 彻底简化了容器的管理。但是他要求我们在多方面重新思考我们的监控策略，并且确保所有来自不同组件的这些关键维度都能被合理地搜集、聚合及追踪。我们希望我们的监控指南能帮你有效监控你的 Kubernetes 集群。 回馈和建议 不胜欢迎。
原文链接： Kubernetes : a monitoring guide （翻译：池剑锋）
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
