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