Kubernetes 集群监控详解

介绍

Kubernetes 在 Github 上拥有超过 4 万颗星，7 万以上的 commits，以及像 Google 这样的主要贡献者。Kubernetes 可以说已经快速地接管了容器生态系统，成为了容器编排平台中的真正领头羊。

理解 Kubernetes 和它的 Abstractions

在基础设施层，Kubernetes 集群好比是一组扮演特定角色的物理或虚拟机器。其中扮演 Master 角色的机器作为全部操作的大脑，并由运行在节点上的编排容器控制。

• Master 组件管理 pod 的生命周期，pod 是 Kubernetes 集群中部署的基本单元。pod 完成周期，Controller 会创建一个新的。如果我们向上或向下（增加减少）Pod 副本的数量，Controller 会相应的创建和销毁 pod 来满足请求。Master 角色包含了下面组件：

• kube-apiserver – 为其他 master 组件提供 APIs

• etcd – 具有一致性且高可用的 key/value 存储，用于存储所有内部集群数据

• kube-scheduler – 使用 pod 规范中的信息来确定运行 pod 的节点

• kube-controller-manager – 负责节点管理（检测节点是否失败）、pod 复制和端点创建

• cloud-controller-manager – 运行与底层云提供商交互的 controller

• Node 组件是 Kubernetes 中的 worker 机器，由 Master 来管理。一个节点可能表示未一个虚拟机（VM）或者物理机，而 Kubernetes 都可以在它们上面运行。每个节点都包含了运行 pods 所需要的组件：

• kubelet:处理 Master 和运行它的节点之间的所有通信。它在使用 container runtime 时提供接口来部署和监视容器。

• kube-proxy:维护主机上的网络规则，处理在 pods、host 和外部世界之间包的传输。

• container runtime:负责在 host 上运行容器。虽然 Kubernetes 支持来自 rkt、runc 以及其他各式的 container runtime，当下最流行的引擎还是 Docker。

从逻辑层面来看，Kubernetes 部署由各种组件组成，每个组件在集群中提供的服务都有特定的目的。

• Pods 是 Kubernetes 部署时的基本单元。一个 pod 由一个或者多个共享相同网络命名空间和 IP 地址的容器组成。最佳实践推荐我们为每个应用程序创建一个 pod，这样你就可以分别扩展和控制它们。

• Services 设置在 pods 集合之前，给它们提供一致的 IP 地址以及一套策略用来控制对它们的访问。Service 所针对的 pod 集合通常由 label selector（标签选择器）决定。这样在升级或者蓝/绿部署期间很容易就让 Service 指向不同的 pod 集合。

• ReplicaSets 由部署控制，并确保运行该部署所需要的 pods 数量。

• Namespaces 为诸如 pods 和 services 资源定义了一个逻辑命名空间。它们允许资源使用相同的名称，而单个命名空间中的资源名称必须唯一。Rancher 使用命名空间和机遇角色的访问控制，为命名空间和其中运行的资源之间提供安全隔离。

• Metadata 根据容器的部署特性来标记容器。

监控 Kubernetes

多个服务和命名空间可以跨基础设施分布。就像上面所说，每个服务都是由 pods 组成，而 pod 可以包含一个或多个容器。有了如此多的移动部件，即便是监控一个小型的 Kubernetes 集群也会带来挑战。为了高效地监控它，这就需要深入了解应用程序体系结构和功能。

Kubernetes 提供了用于监控集群的工具：

• Probes 能积极地监控容器的健康状态。如果 Probe 检测到容器不健康，那么它就会重启容器。

• cAdvisor 是一个开源代理，它监控资源的使用情况并分析容器的性能。cAdvisor 最初由 Google 创建，现在已经和 Kubelet 集成。它能够收集、聚合、处理和导出在给定节点上运行的所有勇气的度量指标，比如 CPU、内存、文件和网络的使用情况。

• kubernetes dashboard（仪表板）是一个附加组件，它能提供集群上运行的资源的概述信息。此外还提供了非常基本的方法来部署这些资源并和它们交互。

Kubernetes 由从故障中自动回复的强大能力。如果进程发生崩溃，它可以重新启动 pods，如果节点出现错误，它能重新分配 pods。然而，尽管有如此能力，还是会有不能解决问题的情况。为了检测到这些情况，我们还需要额外的监控。

监控的层次

基础设施

服务器级别的问题会在工作负载中出现，因此所有集群都应该监控底层服务器组件

监控什么

• CPU 利用率。监控 CPU 既能显示系统和用户的开销，也能显示 iowait。挡在云中或者任何网络存储中运行集群时，iowait 会提示存储读写（i/o 过程）的瓶颈等待时间。超额订阅的存储框架会影响性能。

• 内存使用情况。监控内存可以显示出有多少内存在使用，以及有多少可用内存，可用内存可以是空闲内存，也可以是缓存。出现内存限制的系统会开始进行交换（swap），交换会迅速降低性能。

• 磁盘压力。如果系统正在运行诸如 etcd 或者任何数据存储这样的写入密集型服务时，如果磁盘空间耗尽，那将是灾难性的问题。不能写入数据会出现崩溃，而这种崩溃会转化为真实世界的损失。有了像 LVM 这样的技术，就能很容易地根据需要增加磁盘空间，但是尽管如此还是要监控它。

• 网络带宽。在当今千兆接口的时代，似乎带宽永远都不会耗尽。然而，仅仅是出现一些异常的服务、数据泄漏、系统损坏或者 DOS 攻击，就可能耗尽所有的带宽导致停机。如果了解自己的正常数据使用情况和应用程序的模式，就能有效降低成本，有助于规划容量。

• Pod 资源。如果能知道 pod 需要什么资源的话，Kubernetes 调度器就能最大化发挥作用。它可以确保在可用的节点上放置 pod。在设计网络时，为了避免剩余节点无法运行所有所需的资源的情况，需要预先考虑有多少节点可能会失败。使用云自动伸缩组之类的服务可以快速恢复，但要确保其余节点在失败节点恢复回来之前，能够处理增加的负载。

Kubernetes 服务

组成 Kubernetes Master 或者 Worker 的所有组件（包括 etcd）都对应用程序的健康运行至关重要。如果其中任何一个出现失败，监控系统就需要检测失败，修复它并且发送警告。

内部服务

最后一层是 Kubernetes 资源本身。Kubernetes 公开了关于资源的度量，我们还可以直接监控应用程序。虽然 Kubernetes 会尽力维持理想的状态，但如果它无能为力的话，我们就需要一种由人类干预和解决问题的方法了。

用 Rancher 来监控

除了管理运行在任何提供者上、任何位置的 Kubernetes 集群外，Rancher 还会监控这些集群中运行的资源，并在资源超过定义的阈值时发送警报。

现在已经有许多关于如何部署 Rancher 的教程。如果你还没有正在运行的集群，请先在这里暂停，进入我们的快速上手指南：https://rancher.com/quick-start/。等到集群正在运行了再返回到这里开始监控。

集群概述可以让你了解正在使用的资源和 Kubernetes 组件的状态。在我们的例子中，我们使用了 78%的 CPU、26%的 RAM 和 11%的最大 pod 数量。

点击 Nodes 选项卡，你可以看到关于运行在集群上每个节点的附加信息，点击具体节点时，可以看到关于该成员的健康状况。

Workloads 选项卡显示了运行在集群上的 pods。如果你还没有任何运行的 pod，先发布一个运行 nginx 镜像的工作负载，把它扩展成多个副本。

当需要选择工作负载名称时，Rancher 会弹出一个显示有关该工作负载的信息页面。在页面顶部，它展示了每个 pod 所运行的节点，pod 的 IP 地址以及它们的状态。点击任何一个 pod 会看到更多内容，现在我们看到了关于该 pod 的详细信息。右上角的汉堡菜单图标能让我们和 pod 交互，通过该图标，我们可以执行 shell、查看日志或者删除 pod。

Other 选项卡展示了不同 Kubernetes 资源的信息，包括 ingress 或 LoadBalancer 类型的服务的 Load Balancing，其他服务类型的 Service Discovery 以及在集群中配置卷的 Volumes。

使用 Prometheus 监控

Rancher UI 中可以看到的信息对故障排除非常有帮助，不过这并不是在集群生命周期的每一时刻积极追踪集群状态的最佳方法。我们将使用 Prometheus，它是 Kubernetes 公司的一个兄弟项目，由 Cloud Native Computing Foundation 负责维护和运营。我们还将使用到 Grafana 工具，它能把时间序列数据转换成漂亮的图形和仪表板显示。

Prometheus 是一个用来监控系统和生成警报的开源应用程序。从服务器到应用程序、数据库、甚至单个进程，它几乎可以监控任何东西。在 Prometheus 的词表中，它监控 targets，目标的每个单位称为 metric。检索关于目标信息的行为称为 scraping（抓取）。Prometheus 将在指定的时间间隔内采集目标，并把信息存储在时间序列数据库中。Prometheus 拥有自己的脚本语言 PromQL。

Grafana 也是开源的，可以作为 Web 应用程序运行。虽然它经常和 Prometheus 一起使用，但也支持后端数据存储，如 fluxDB、Graphite、Elasticsearch 等等。Grafana 可以很容易地创建图形，并且把它们合并称仪表板，而这些仪表板由一个强大的身份验证和授权层保护，它们还可以和其他仪表板进行共享而不需要访问服务器本身。Grafana 在其对象定义中大量使用 JSON，这样它的图形和仪表板都非常容易移植，并且版本控制非常方便。

在 Rancher 的应用程序目录中已经同时包含了 Prometheus 和 Grafana，我们只需点击几下鼠标就能部署它们了。

安装 Prometheus 和 Grafana

访问集群的 Catalog Apps 页面，搜索 Prometheus。安装它的同时还会安装 Grafana 和 AlertManager。对本文来说，所有内容都使用默认值就可以了，但如果考虑到生产部署，请阅读 Detailed Descriptions 下的信息，看看图表中有多少配置可供使用。

单击 Launch，Rancher 将把应用程序部署到集群中，几分钟之后，你就能看到 prometheus 命名空间下所有工作负载处于 Active 状态。

默认情况下使用了 xip.io 设置 Layer7 ingress，我们可以在 Load Balancing 选项卡上看到它，单击链接打开 Grafana 仪表板。

Prometheus 的安装还在 Grafana 中部署了几个仪表板，因此我们可以马上看到关于集群的信息，查看它的性能。

总结

Kubernetes 能尽可能保持应用程序的运行，但这并不说明我们就不需要了解应用程序运行的情况。当你开始使用 Kubernetes 工作时，还需要去部署监控系统，帮助你了解情况并作出决策。

Prometheus 和 Grafana 将帮助你完成这一项工作，如果你使用了 Rancher，那部署这两个应用程序只需要短短几分钟。而在即将发布的 Rancher 2.2 中，配备了完全集成的 Prometheus 和 Grafana，增强所有 Kubernetes 集群的可见性，同时确保不同项目与用户之间的隔离。Rancher 也因此成为唯一一个在多集群、多租户环境中支持 Prometheus 的解决方案。

使用 Prometheus 监控 Rancher 管理的 Kubernetes 环境，只需要两个步骤：

1. 选择集群

2. 一键启动监控

你可以在此了解如何更加简单快速地在多 Kubernetes 集群和多租户环境中使用 Prometheus 监控！