本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes:监控指南
容器技术正席卷基础设施领域。虽然容器解决了或简化了基础设施管理流程,但它们也带来了编排方面的显著复杂性。这就是Kubernetes发挥作用的地方。就像指挥家指挥乐团一样,Kubernetes 负责监督我们的容器集合——自动启动、停止、创建和销毁它们,以确保我们的应用程序平稳运行。
Kubernetes 通过创建像Pod和Service这样的抽象层,极大地简化了容器化基础设施的管理。我们不再需要担心应用程序在哪里运行,或者它们是否有足够的资源正常工作。但这并不能改变一个事实:为了确保良好的性能,我们需要监控我们的应用程序、运行它们的容器以及Kubernetes本身。
重新思考Kubernetes时代的监控
正如容器彻底改变了我们对在虚拟机上运行服务的看法一样,Kubernetes 也改变了我们与容器交互的方式。好消息是,通过适当的监控,Kubernetes 固有的抽象层提供了基础设施的全面视图,即使容器和应用程序在不断移动。但 Kubernetes 监控要求我们重新思考和调整我们的策略,因为它在几个方面与监控传统主机(如虚拟机或物理机)不同。
标签变得至关重要
由于容器及其编排完全由 Kubernetes 管理,标签现在是我们与 Pod 和容器交互的唯一方式。这就是为什么它们对于监控绝对至关重要,因为所有指标和事件都将使用基础设施不同层级的标签进行切片和分析。使用逻辑且易于理解的模式定义您的标签至关重要,这样您的指标才能尽可能有用。
现在需要监控的组件更多了
在传统的以主机为中心的基础设施中,我们习惯于只监控两层:应用程序和运行它们的主机。现在,容器位于中间,Kubernetes 本身也需要监控,因此有四个不同的组件需要监控并从中收集指标。
应用程序不断移动
Kubernetes 根据调度策略动态调度应用程序,因此您不总是知道应用程序在哪里运行。但它们仍然需要被监控。这就是为什么使用具有服务发现功能的监控系统或工具是必不可少的。它将自动调整指标收集以适应移动的容器,从而使应用程序能够不间断地持续监控。
为分布式集群做好准备
Kubernetes 能够将容器化应用程序分布到多个数据中心以及潜在的不同云提供商。这意味着必须在所有这些不同来源之间收集和聚合指标。
有关 Kubernetes 固有的所有这些新监控挑战以及如何克服它们的更多详细信息,我们最近发布了一份深入的 Kubernetes 监控指南。本系列的第一部分介绍了如何使您的监控策略适应 Kubernetes 时代。
要监控的指标
无论您使用Heapster数据还是与 Kubernetes 及其不同 API 集成的监控工具,都有几种关键类型的指标需要密切跟踪
- 运行中的 Pod 及其部署
- 常用的资源指标,例如 CPU、内存使用情况和磁盘 I/O
- 容器原生指标
- 应用程序指标,为此,您的监控工具中的服务发现功能至关重要
所有这些指标都应使用 Kubernetes 标签进行聚合,并与来自 Kubernetes 和容器技术的事件相关联。
我们关于 Kubernetes 监控系列的第二部分将指导您完成所有需要收集和跟踪的数据。
收集这些指标
无论您是想通过结合 Heapster、存储后端和图形工具来跟踪这些关键性能指标,还是通过将监控工具与您的基础设施的不同组件集成来跟踪,关于 Kubernetes 指标收集的第三部分都能为您提供帮助。
扬帆起航!
使用 Kubernetes 极大地简化了容器管理。但这要求我们从几个方面重新思考我们的监控策略,并确保从不同组件获得的所有关键指标都得到正确收集、聚合和跟踪。我们希望我们的监控指南能帮助您有效地监控您的 Kubernetes 集群。欢迎反馈和建议。
- 在 GitHub 上参与 Kubernetes 项目
- 在 Stack Overflow 上提问(或回答问题)
- 在 Slack 上与社区联系
- 在 Twitter 上关注我们 @Kubernetesio 获取最新更新