校对：（才云）、（才云）
如果想要监控 Kubernetes，包括基础架构平台和正在运行的工作负载，传统的监控工具和流程可能还不够用。就目前而言，监控 Kubernetes 并不是件容易的事。
Kubernetes 已经席卷了整个容器生态系统，它充当着容器分布式部署的大脑，旨在使用跨主机集群分布的容器来管理面向服务的应用程序。Kubernetes 提供了用于应用程序部署、调度、更新、服务发现和扩展的机制，但是监控 Kubernetes 呢？
虽然 Kubernetes 可以极大地简化将应用程序在容器以及跨云的部署过程，但它会为日常任务、应用程序性能管理、服务可见性以及典型的“监控->警报->故障排除”工作流程增加了复杂性。
旧版监控工具从静态目标中收集指标，用于监控服务器和服务，这些工具过去工作良好，但现在无法正常工作。下面就是这些工具现在无法监控 Kubernetes 的原因：
为了简化应用程序部署，基础架构增加了新的复杂性层：动态配置的 IaaS、自动配置的配置管理工具以及编排平台（如 Kubernetes），它们都位于裸机或虚拟基础架构与支持应用程序的服务之间，因此在控制平面上监控 Kubernetes 安全也是工作的一部分。
除了增加基础架构的复杂性之外，微服务还被设计了新的应用程序，其中相互通信的组件数量也会按数量级增加。每个服务分布在多个实例中，并且容器可以根据需要在基础结构中移动。这就是监控 Kubernetes 编排状态对于了解 Kubernetes 执行工作至关重要的原因。我们要验证服务的所有实例都已启动并运行。
我们需要监控系统，这样能为高水平的服务目标发出警报，另外我们也要保留粒度以根据需要检查各个组件。当采用云原生架构时，它们带来了变化也带走了越来越多的小组件。这就影响了 Kubernetes 监控方法和工具。
随着指标数量的激增，传统的监控系统已无法跟上。虽然过去我们能知道每个服务组件有多少个实例以及它们位于何处，但现在情况已不再如此。现在指标通常具有一定的基数，Kubernetes 会有一些多维级别，例如集群、节点、命名空间、Service 等。许多标签的代表属性来自于微服务的逻辑、应用程序版本、API 端点、特定资源或操作等。
另外，容器不会永远运行下去。据一份容器使用情况报告显示，22％ 的容器寿命不超过 10 秒，54％ 的容器寿命不到 5 分钟。这会造成很大的变动，容器 ID、Pod 名称之类的标签始终在变化，这也是我们在处理新标签时却再也看不到它们的原因。
现在，我们如果将度量标准的名称、标签与实际值、时间戳一起使用，在短时间内，就将拥有成千上万个数据点，即使是在小型 Kubernetes 集群中，也将生成数十万个时间序列，如果是中型基础架构，可能就是数百万个。这就是为什么 Kubernetes 监控工具需要准备好扩展成千上万个指标。
容器的生命周期是短暂的，它一旦死亡，内部的所有东西都将消失，我们无法使用 SSH 或查看日志。容器非常适合操作，我们可以打包、隔离应用程序，在任何地方以一致的方式部署它们，但是同时，它们同样会成为难以排除故障的黑盒。监控工具可以通过系统调用跟踪从而提供详尽的可见性，这样我们可以查看容器内发生的每个进程、文件或网络连接，从而更快地对问题进行故障排除。
考虑到这些因素，我们可以更好地理解为什么监控 Kubernetes 与监控服务器、VM 甚至是云实例有很大不同。
Kubernetes 集群具有多个组件和层，在每个组件和层中，我们需要监控不同的故障点。以下是 Kubernetes 监控的一些典型用例：
通过监控集群，您可以全面了解整个平台的运行状况和容量。具体的用例如下：
- 集群资源使用情况：集群基础架构充分利用了吗？还是产能过剩？
- 项目和团队分摊资源：每个项目或团队的资源使用量是多少？
- 节点可用性和运行状况：是否有足够的节点可用于复制我们的应用程序？我们会耗尽资源吗？
- Pod 丢失（Missing）和失败：Pod 是否在我们的应用程序中运行？多少 Pod 快死亡了？
- 正在运行的实例与所需的实例：每个 Service 实际准备了多少个实例？我们需要多少个？
- 请求和限制的 Pod 资源使用情况：是否设置了 CPU 和内存的请求和限制？它们的实际作用是什么？
归根结底，应用的监控才是最重要的。下面是应用监控的一部分：
- 应用程序可用性：应用程序是否响应？
- 应用程序运行状况和性能：我们有多少个请求？多少响应能力或延迟时间？我们有没有出错？
与大多数平台一样，Kubernetes 具有一组基本工具，可以监控平台，包括基于物理基础架构之上的 Kubernetes 构造。由于 Kubernetes 具有可扩展性，它会添加其他组件以获得 Kubernetes 可见性。让我们来看一下 Kubernetes 监控设置的部分：
cAdvisor 是一个开源容器资源使用收集器。它专为容器而构建，支持本地 Docker 容器。cAdisor 会自动发现给定节点中的所有容器，并收集CPU、内存、文件系统和网络使用情况统计信息，不过它仅会收集基本资源利用率。仅当容器具有 X％CPU 利用率时，cAdvisor 才能告诉我们应用程序的实际性能。cAdvisor 本身并不提供任何长期存储或分析功能。
为了进一步处理这些数据，我们需要一些东西来整合整个集群中的数据。最受欢迎的选择是 Heapster。就像任何应用程序一样，Heapster 在集群中作为 Pod 运行。Heapster Pod 从 kubelet 获取有用数据，而 kubelet 本身的数据则是从 cAdvisor 得到，然后 Heapster 按窗格将信息分组，其中也包括相关标签。
Heapster 是一个收集者，而不是采集者，它只是让我们收集整个集群中的 cAdvisor 数据。我们需要将这些数据推送到可配置的后端进行存储和可视化。我们可以添加可视化层（例如 Grafana）查看数据。
Kubernetes 仪表板提供了一种简单的方式，让我们通过 Kubernetes 命名空间和工作量查看环境。它提供了一种一致的方式来可视化基本数据，包括基本的 CPU、内存数据。另外，我们还可以从仪表板进行管理并采取措施，不过这就涉及到了多租户集群上的安全问题，需要设置适当的 RBAC 特权。
- 现在计划了多少个副本？目前有多少可用？
- 有多少个 Pod 正在运行、已停止、已终止？
- 此 Pod 已重启多少次？
我们现在对在 Kubernetes 环境中构建合理的监控有了一定了解，虽然仍然没有详细的应用程序监控（例如：我的数据库服务的响应时间是多少？），但至少可以看到基础主机、Kubernetes 节点以及 Kubernetes 状态的一些监控。
Kubernetes 探针发挥了定期监控 Pod 的运行状况和可用性的重要作用。它可以让我们通过针对端点的请求和运行命令来任意定义“活动性”。以下是基于运行 cat 命令的 liveness 探针的简单示例：
Prometheus 是一个是开源的时间序列数据库，它和 Kubernetes 一样是 CNCF 项目。Prometheus 监控是围绕 Prometheus 服务器的整个监控堆栈，该服务器会收集并存储度量，另外还有用于仪表板的 Grafana。
尽管一开始使用 Prometheus 监控 Kubernetes 真的很简单，但是以后 DevOps 团队会很快意识到 Prometheus 也有一些使用障碍，例如规模、RBAC 以及一些团队合规性问题。
