• 前提条件
  • 查看集群状态
    • 集群节点状态
    • 查看组件状态
    • 查看集群资源使用情况
  • 物理资源监控
    • 监控指标
      • CPU 利用率
      • 内存利用率
      • CPU 平均负载
      • 磁盘使用量
      • inode 使用率
      • 磁盘吞吐
      • IOPS
      • 网卡速率
      • 容器组运行状态
  • 节点用量排行
  • ETCD 监控
  • API Server 监控
  • 调度器监控

    KubeSphere 监控中心在 集群状态监控 提供了集群的 CPU、内存、网络和磁盘等相关指标的监控，并支持回看历史监控和节点用量排行。在控制台的 平台管理 → 监控中心 页面可查看集群状态的监控指标。

    前提条件

    已有集群管理员 (Cluster-admin) 账号，或当前用户的角色在权限列表中勾选了 查看监控管理。

    查看集群状态

    在左侧选择 集群状态，可以看到集群状态的监控页面，包括 集群节点状态、组件状态、集群资源使用情况 等三个部分。

    集群状态监控 - 图1

    集群节点状态

    集群节点状态显示当前所有节点在线状态，支持下钻到主机管理页面查看所有主机实时的资源使用情况，点击 节点在线状态 进入主机管理列表。

    例如以下列表的 192.168.0.55 节点，显然它的内存空间不足，点击进去查看该主机的详情页面。

    集群节点状态

    从节点详情页，当前主机的 CPU、内存、本地存储、容器组使用情况从监控反馈的饼图中即可一目了然。明细发现内存使用率已高达 93 %，这种情况可能需要对该主机采取措施，比如对其进行扩容或通过添加污点的方式禁止调度新的工作负载到当前主机。

    节点监控详情

    在主机详情页点击 监控 tab，可以查看该主机的 CPU 使用率、CPU 平均负载、内存使用率、磁盘使用率、inode 使用率、IOPS、磁盘吞吐、网卡速率。对于主机而言，除了 CPU、内存、磁盘等使用率、磁盘吞吐这类常用监控指标，inode 使用率和 CPU 平均负载的监控信息对于主机资源管理也是非常有帮助的。

    监控 tab

    查看组件状态

    KubeSphere 提供集群内各项服务组件的健康状态监控，若某些核心的服务组件出现异常，可能会导致系统不可用。查看当前集群服务组件的健康状态和运行时间，能够帮助用户监测集群的状况和及时定位问题。

    点击 组件状态 即可跳转到服务组件的详情页面，如下可以看到 Istio 有一个组件状态异常，其 Tab 显示黄色的异常状态。

    集群状态监控 - 图5

    查看集群资源使用情况

    集群资源的监控指标包括当前集群所有节点的 CPU、内存、磁盘等利用率和容器组使用数量变化，点击左边的饼状图即可切换指标。监控的时间间隔为 40 分钟，四项监控指标的纵坐标都会随时间动态变化。该监控图可以一览整个集群的资源消化状况，对于集群管理员而言，是需要密切关注这部分的监控指标的。当资源接近饱和状态时，可以通过增加节点或扩容磁盘、内存等操作，调节集群的负载能力。

    集群资源使用情况

    物理资源监控

    物理资源监控的数据能够帮助用户观察和建立资源和集群性能的正常标准，KubeSphere 支持查看集群 7 天以内的监控数据，包括 CPU 利用率、内存利用率、CPU 平均负载 (1 分钟 / 5 分钟 / 15 分钟)、inode 使用率、磁盘吞吐 (读/写)、IOPS (读/写)、网卡速率 (出/入)、容器组运行状态。KubeSphere 支持自定义时间范围和时间间隔来查看历史监控状况。以下分别简单介绍每一项监控指标的意义。

    历史监控

    监控指标

    CPU 利用率

    CPU 利用率 (%)，是对一个时间段内 CPU 使用状况的统计，通过这个指标可以看出在某一个时间段内 CPU 被占用的情况。在监控中若发现某个时间段内系统的 CPU 使用率飙高时，首先要定位到是哪个进程占用的 CPU 较高。比如对于 Java 应用来说，可能存在内存泄漏问题或代码存在死循环这类情况。

    CPU 利用率

    内存利用率

    内存是计算机中重要的部件之一，它是与 CPU 进行沟通的桥梁，因此内存的性能对计算机的影响非常大。程序运行时的数据加载、线程并发、I/O缓冲等都依赖于内存，可用内存的大小决定了程序是否能正常运行以及运行的性能，而内存利用率 (%) 可反映集群的内存利用状况和性能。

    内存利用率

    CPU 平均负载

    在说明其监控意义之前，先了解一下 CPU 平均负载的含义，它是单位时间内，系统处于可运行状态和不可中断状态的平均进程数，即平均活跃进程数，注意区别其与 CPU 使用率没有直接关系。那么平均负载为多少时是合理的？实际上，平均负载在理想状况下应该等于 CPU 个数，所以在判断平均负载大小时，先确定系统有几个 CPU。只有平均负载比 CPU 个数多时，就说明系统出现了过载。

    问题是，CPU 平均负载在下图中分为 1 分钟 / 5 分钟 / 15 分钟 三个数值，应该怎么看？

    通常情况下，三个时间都要看，通过分析系统负载的趋势，能更全面地了解目前的负载状况：

    • 如果 1 分钟 / 5 分钟 / 15 分钟 这三个时间的曲线在某个时间段内基本相似，说明集群的 CPU 负载比较稳定
    • 如果在某个时间段 (或时间点) 1 分钟的值远大于 15 分钟则说明最近 1 分钟的负载呈增加趋势，需要保持观察，一旦 1 分钟的值超过了 CPU 个数可能意味着系统出现过载，就需要进一步分析问题来源了
    • 反之，如果某时段或时刻 1 分钟的值远小于 15 分钟则说明最近 1 分钟内系统的负载在降低，而之前 15 分钟内已产生了很高的负载。

    CPU 平均负载

    磁盘使用量

    KubeSphere 的工作负载比如有状态副本集、守护进程集都依赖于持久化存储服务，并且其自身的一些组件和服务也都需要持久化存储提供支持，而这类后端存储就依赖于磁盘，比如块存储或网络共享存储。为磁盘使用量提供实时的监控环境是保持数据高可靠性的重要部分，因为在 Linux 系统的日常管理中，平台管理员可能会遇到因磁盘空间不足导致数据丢失，甚至系统崩溃等情况。所以，关注系统的磁盘使用情况，并确保文件系统不被占满或滥用是集群管理的重要任务。通过监控磁盘使用量的历史数据，即可预先了解磁盘的使用情况，如果发现磁盘使用量过高，可以通过清理不必要的镜像或容器，来节省磁盘空间。

    磁盘使用量

    inode 使用率

    每个文件都必须有一个 inode，用于储存文件的元信息，比如文件的创建者、创建日期，inode 也会消耗硬盘空间，大量的 cache 小文件也容易导致 inode 资源被使用耗尽。并且，有可能发生 inode 已经用光，但是硬盘还未存满的情况，此时就无法在硬盘上创建新文件。

    而 inode 使用率的监控恰好就可以预先发现上述提到的这类情况，帮助用户知道集群 inode 的使用情况，防止因 inode 耗尽使得集群无法正常工作，提示用户及时清理临时文件。

    inode 使用率

    磁盘吞吐

    磁盘监控是 Linux 系统管理中一个非常重要的组成部分，以上提过了磁盘利用率的监控，那么磁盘吞吐和 IOPS 的监控也是不可或缺的，便于集群管理员进行调整数据布局等管理活动以达到优化集群总体性能的目的。磁盘吞吐 (Throughput) 指磁盘传输数据流的速度，单位是 MB/s，传输数据为读出数据和写入数据的和。当传输大块不连续数据的数据，该指标有重要参考作用。

    磁盘吞吐

    IOPS

    IOPS 对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘 I/O, 磁盘的 IOPS 就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时，该指标有重要参考意义。

    IOPS

    网卡速率

    网卡速率是指网卡每秒钟接收或发送数据的能力，单位是 Mbps (兆位 / 秒)。

    网卡速率

    容器组运行状态

    容器组 (Pod) 运行状态支持筛选 运行中、异常中、已完成 三种状态的容器组总数量。已完成状态通常是任务 (Job) 或定时任务 (CronJob) 这类容器组，异常状态的容器组数量需要引起特别关注。

    容器组运行状态

    节点用量排行

    节点用量排行功能对于主机监控是非常实用的，支持按 CPU 使用率、CPU 平均负载、内存使用率、本地存储用量 (磁盘使用量)、inode 使用率、容器组用量 这一类指标进行排行，支持升序和降序排列。管理员通过按指标进行排序即可快速发现潜在问题或定位某台节点资源不足的情况。比如，按内存使用率降序排行，可以发现排行前两位的主机内存已经非常高了，管理员可以通过扩容内存、打上污点或其它手段来防止这两台主机因内存不足而不工作。

    节点用量排行

    ETCD 监控

    要想用好 ETCD ，特别是定位性能问题，ETCD 的监控必不可少，ETCD 服务原生提供了度量（metrics）接口，KubeSphere 监控系统对其原生的数据提供了很好的监控展示效果。

    监控指标 指标说明
    ETCD 节点 是否有 Leader：表示该成员是否有 Leader，如果成员没有 Leader，则完全不可用。 如果集群中的所有成员都没有任何 Leader，则整个集群完全不可用
    Leader 变更次数： 用于计算集群中的成员自开始以来所看到的 Leader 变更的数量。 频繁的 Leader 变更会显着影响 ETCD 的表现。 它还表明 Leader 不稳定，可能是由于网络连接问题或过度负载击中了 ETCD 集群
    库大小 ECTD 底层数据库的大小（以 MiB 为单位），目前展示的是 ETCD 各成员数据库大小平均值。
    客户端流量 包括发送给 grpc 客户端的总流量和收到 grpc 客户端的总流量，指标释义详见 etcd Network
    gRPC 流式消息 Server 端的 gRPC 流式消息接收速率和发送速率，该速率可以反映集群中是否有大规模数据的读和写操作，指标释义详见 go-grpc-prometheus
    WAL 日志同步时间 WAL 调用 fsync 的延迟，当 ETCD 在应用它们之前将其日志条目保留到磁盘时，将调用wal_fsync，指标释义详见 etcd Disk
    库同步时间 后端调用的提交延迟分布，当 ETCD 提交其最近更改到磁盘的增量快照时，将调用 backend_commit。注意，磁盘操作高延迟（WAL 日志同步时间或库同步时间较长）通常表示磁盘问题，它可能会导致高请求延迟或使集群不稳定，指标释义详见 etcd Disk
    Raft 提议 - 提议提交速率：记录已提交的共识提案的速率。如果集群健康，该指标应随时间增加。 ETCD 集群的几个健康成员可能同时拥有不同的总提议。单个成员与其 Leader 之间的持续大滞后表明成员缓慢或不健康。
    - 提议应用速率：记录所应用的共识提案总速率。 ETCD 服务器异步应用每个已提交的提议。提议提交速率和提议应用速率之间的差异通常应该很小（即使在高负载下也只有几千）。
    如果它们之间的差异继续上升，则表明 ETCD 服务器过载。 在使用大规模查询（如重范围查询或大型 txn 操作）时可能会发生这种情况。
    - 提议失败速率：失败提案总速率，通常与两个问题相关，与 Leader 选举相关的临时故障或由于集群中的仲裁丢失导致的更长停机时间。
    - 排队提议数：当前待处理提案的数量，上升的待定提案表明 Client 端负载较高或成员无法提交提案。
    目前，界面上展示的数据是 ETCD 各成员指标大小的平均值。提议相关参数释义详见 etcd Server。

    集群状态监控 - 图18

    API Server 监控

    API Server 作为 Kubernetes 集群中所有组件交互的枢纽，下表列出了 API Server 监控的主要指标。

    监控指标 指标说明
    请求延迟 按 HTTP 请求方法分类统计，资源请求响应的延迟（以毫秒为单位）
    每秒请求数 kube-apiserver 每秒接受请求数量

    集群状态监控 - 图19

    调度器监控

    Scheduler 监控新创建的 Pod 的 Kubernetes API，并确定新建的 Pod 应该运行在哪些节点。它根据可用数据做出此决策，包括收集的资源可用性以及 Pod 的资源需求。监控调度延迟的数据可确保您可以查看调度程序所面临的任何延迟。

    监控指标 指标说明
    调度次数 包括调度成功、错误、失败的次数
    调度速率(次/秒) 包括调度成功、错误、失败的调度速率
    调度延迟(毫秒) 端到端调度延迟，它是调度算法延迟和绑定延迟的总和

    集群状态监控 - 图20