|
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 监控的一些典型用例： 通过监控集群，您可以全面了解整个平台的运行状况和容量。具体的用例如下： 集群资源使用情况：集群基础架构充分利用了吗？还是产能过剩？ 项目和团队分摊资源：每个项目或团队的资源使用量是多少？ 节点可用性和运行状况：是否有足够的节点可用于复制我们的应用程序？我们会耗尽资源吗？ 查看诸如命名空间、deployment、副本集或 DaemonSet 之类的 Kubernetes constructs，我们可以了解应用程序是否已正确部署。例如： Pod 丢失（Missing）和失败：Pod 是否在我们的应用程序中运行？多少 Pod 快死亡了？ 正在运行的实例与所需的实例：每个 Service 实际准备了多少个实例？我们需要多少个？ 请求和限制的 Pod 资源使用情况：是否设置了 CPU 和内存的请求和限制？它们的实际作用是什么？ 归根结底，应用的监控才是最重要的。下面是应用监控的一部分： 应用程序可用性：应用程序是否响应？ 应用程序运行状况和性能：我们有多少个请求？多少响应能力或延迟时间？我们有没有出错？ 下篇我们将分享一些Kubernetes监控的有效工具。 文章部分素材源自：K8sMeetup社区 |
|
|
