1 - 监控告警指标列表
监控 & 告警指标列表
目前 TKEStack 提供了以下维度的监控指标，所有指标均为统计周期内的平均值。
监控
集群监控指标
| 指标 | 单位 | 说明 |
|---|---|---|
| CPU 利用率 | % | 集群整体的 CPU 利用率 |
| 内存利用率 | % | 集群整体的内存利用率 |
节点监控指标
| 指标 | 单位 | 说明 |
|---|---|---|
| Pod 重启次数 | 次 | 节点内所有 Pod 的重启次数之和 |
| 异常状态 | - | 节点的状态，正常或异常 |
| CPU 利用率 | % | 节点内所有 Pod 的 CPU 使用量占节点总量之比 |
| 内存利用率 | % | 节点内所有 Pod 的内存使用量占节点总量之比 |
| 内网入带宽 | bps | 节点内所有 Pod 的内网入方向带宽之和 |
| 内网出带宽 | bps | 节点内所有 Pod 的内网出方向带宽之和 |
| 外网入带宽 | bps | 节点内所有 Pod 的外网入方向带宽之和 |
| 外网出带宽 | bps | 节点内所有 Pod 的外网出方向带宽之和 |
| TCP 连接数 | 个 | 节点保持的 TCP 连接数 |
工作负载监控指标
| 指标 | 单位 | 说明 |
|---|---|---|
| Pod 重启次数 | 次 | 工作负载内所有 Pod 的重启次数之和 |
| CPU 使用量 | 核 | 工作负载内所有 Pod 的 CPU 使用量 |
| CPU 利用率（占集群） | % | 工作负载内所有 Pod 的 CPU 使用量占集群总量之比 |
| 内存使用量 | B | 工作负载内所有 Pod 的内存使用量 |
| 内存利用率（占集群） | % | 工作负载内所有 Pod 的内存使用量占集群总量之比 |
| 网络入带宽 | bps | 工作负载内所有 Pod 的入方向带宽之和 |
| 网络出带宽 | bps | 工作负载内所有 Pod 的出方向带宽之和 |
| 网络入流量 | B | 工作负载内所有 Pod 的入方向流量之和 |
| 网络出流量 | B | 工作负载内所有 Pod 的出方向流量之和 |
| 网络入包量 | 个/s | 工作负载内所有 Pod 的入方向包数之和 |
| 网络出包量 | 个/s | 工作负载内所有 Pod 的出方向包数之和 |
Pod 监控指标
| 指标 | 单位 | 说明 |
|---|---|---|
| 异常状态 | - | Pod 的状态，正常或异常 |
| CPU 使用量 | 核 | Pod 的 CPU 使用量 |
| CPU 利用率（占节点） | % | Pod 的 CPU 使用量占节点总量之比 |
| CPU 利用率（占 Request） | % | Pod 的 CPU 使用量和设置的 Request 值之比 |
| CPU 利用率（占 Limit） | % | Pod 的 CPU 使用量和设置的 Limit 值之比 |
| 内存使用量 | B | Pod 的内存使用量，含缓存 |
| 内存使用量（不包含 Cache） | B | Pod 内所有 Container 的真实内存使用量（不含缓存） |
| 内存利用率（占节点） | % | Pod 的内存使用量占节点总量之比 |
| 内存利用率（占节点，不包含 Cache） | % | Pod 内所有 Container 的真实内存使用量（不含缓存）占节点总量之比 |
| 内存利用率（占 Request） | % | Pod 的内存使用量和设置的 Request 值之比 |
| 内存利用率（占 Request，不包含Cache） | % | Pod 内所有 Container 的真实内存使用量（不含缓存）和设置的 Request 值之比 |
| 内存利用率（占 Limit） | % | Pod 的内存使用量和设置的 Limit 值之比 |
| 内存利用率（占 Limit，不包含 Cache） | % | Pod 内所有 Container 的真实内存使用量（不含缓存）和设置的 Limit 值之比 |
| 网络入带宽 | bps | Pod 的入方向带宽之和 |
| 网络出带宽 | bps | Pod 的出方向带宽之和 |
| 网络入流量 | B | Pod 的入方向流量之和 |
| 网络出流量 | B | Pod 的出方向流量之和 |
| 网络入包量 | 个/s | Pod 的入方向包数之和 |
| 网络出包量 | 个/s | Pod 的出方向包数之和 |
Container 监控指标
| 指标 | 单位 | 说明 |
|---|---|---|
| CPU 使用量 | 核 | Container 的 CPU 使用量 |
| CPU 利用率（占节点） | % | Container 的 CPU 使用量占节点总量之比 |
| CPU 利用率（占 Request） | % | Container 的 CPU 使用量和设置的 Request 值之比 |
| CPU 利用率（占 Limit） | % | Container 的 CPU 使用量和设置的 Limit 值之比 |
| 内存使用量 | B | Container 的内存使用量，含缓存 |
| 内存使用量（不包含 Cache） | B | Container 的真实内存使用量（不含缓存） |
| 内存利用率（占节点） | % | Container 的内存使用量占节点总量之比 |
| 内存利用率（占节点，不包含 Cache） | % | Container 的真实内存使用量（不含缓存）占节点总量之比 |
| 内存利用率（占 Request） | % | Container 的内存使用量和设置的 Request 值之比 |
| 内存利用率（占 Request，不包含 Cache） | % | Container 的真实内存使用量（不含缓存）和设置的 Request 值之比 |
| 内存利用率（占 Limit） | % | Container 的内存使用量和设置的 Limit 值之比 |
| 内存利用率（占 Limit，不包含 Cache） | % | Container 的真实内存使用量（不含缓存）和设置的 Limit 值之比 |
| 块设备读带宽 | B/s | Container 从硬盘读取数据的吞吐量 |
| 块设备写带宽 | B/s | Container 把数据写入硬盘的吞吐量 |
| 块设备读 IOPS | 次/s | Container 从硬盘读取数据的 IO 次数 |
| 块设备写 IOPS | 次/s | Container 把数据写入硬盘的 IO 次数 |
告警
目前容器服务提供了以下维度的告警指标，所有指标均为统计周期内的平均值。
集群告警指标
| 指标 | 单位 | 说明 |
|---|---|---|
| CPU 利用率 | % | 集群整体的 CPU 利用率 |
| 内存利用率 | % | 集群整体的内存利用率 |
| CPU 分配率 | % | 集群所有容器设置的 CPU Request 之和与集群总可分配 CPU 之比 |
| 内存分配率 | % | 集群所有容器设置的内存 Request 之和与集群总可分配内存之比 |
| Apiserver 正常 | - | Apiserver 状态，默认 False 时告警，仅独立集群支持该指标 |
| ETCD 正常 | - | ETCD 状态，默认 False 时告警，仅独立集群支持该指标 |
| Scheduler 正常 | - | Scheduler 状态，默认 False 时告警，仅独立集群支持该指标 |
| Controll Manager 正常 | - | Controll Manager 状态，默认 False 时告警，仅独立集群支持该指标 |
节点告警指标
| 指标 | 单位 | 说明 |
|---|---|---|
| CPU 利用率 | % | 节点内所有 Pod 的 CPU 使用量占节点总量之比 |
| 内存利用率 | % | 节点内所有 Pod 的内存使用量占节点总量之比 |
| 节点上 Pod 重启次数 | 次 | 节点内所有 Pod 重启次数之和 |
| Node Ready | - | 节点状态，默认 False 时告警 |
Pod 告警指标
| 指标 | 单位 | 说明 |
|---|---|---|
| CPU 利用率（占节点） | % | Pod 的 CPU 使用量占节点总量之比 |
| 内存利用率（占节点） | % | Pod 的内存使用量占节点总量之比 |
| 实际内存利用率（占节点，不包含 Cache） | % | Pod 内所有 Container 的真实内存使用量（不含缓存）占节点总量之比 |
| CPU 利用率（占 Limit） | % | Pod 的CPU使用量和设置的 Limit 值之比 |
| 内存利用率（占 Limit） | % | Pod 的内存使用量和设置的 Limit 值之比 |
| 实际内存利用率（占 Limit，不包含 Cache） | % | Pod 内所有 Container 的真实内存使用量（不含缓存）和设置的 Limit 值之比 |
| Pod 重启次数 | 次 | Pod 的重启次数 |
| Pod Ready | - | Pod 的状态，默认 False 时告警 |
| CPU 使用量 | 核 | Pod 的 CPU 使用量 |
| 内存使用量 | MB | Pod 的内存使用量，含缓存 |
| 实际内存使用量 | MB | Pod 内所有 Container 的真实内存使用量之和，不含缓存 |
2 - 平台使用常见问题
此处为平台使用常见问题，在使用 TKEStack 过程中，欢迎在 issue 上提出自己的问题，最好配上相关的信息和截图，以便我们更好定位问题所在，每个 issue 我们都会认真对待。
APIServer 的 Real 和 Advertise
Real：表示 Master 节点 APIServer
Advertise：表示高可用 VIP 的 APIServer、或者是各大云厂商托管集群的 APIServer 地址
global 集群没出现
参考：清除浏览器缓存
field is immuable
参考：表示已有同名对象，例如已有同名 Service，需要手动删除 Service，或者换个名字
控制台无法编辑节点 Taint
在部署负载时，有时会出现下图中的事件，表示节点被 Taint
原因：通过 TKEStack 部署的集群里 Master 节点默认带污点（taint），是为了防止业务 Pod 运行在 Master 节点上，此时如果平台有问题的话，业务也会挂掉。但在测试环境中，节点有限的情况下，可以适当删除节点的 taint，但在控制台上没办法删掉，只能在命令行删除
node(s) had tiant
解决方法和上图一样，删除或注释节点中的 taint
镜像仓库镜像上传问题
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Error response from daemon: Get https://defult.registry.tke.com/v2/: dial tcp: lookup defult.registry.tke.com on 183.60.83.19:53: no such host
很可能是因为 Registry container 没有启动
kubectl get pod -n tke | grep tke-registry
事件持久化插件无法点击完成来添加
原因：在页面下方要添加用于持久化的 ES 地址和索引
注意：当前只支持未开启 用户登录认证 的 ES 集群
业务管理界面没有找到想要的业务
因为当前用户不是该业务的成员，需要为该业务添加成员用户
业务的 NS 只能选择一个集群
业务下的每个命名空间只能选取一个集群，因为是在这个集群下面新建的这个命名空间
数据卷 以主机路径为例
主机路径为节点上的一个地址
注意：主机路径指的是 Pod 所在主机的路径
下图2和3中的 testv 相当于一个标签，用于指定不同的挂载类型，本例为主机路径
4中的目录为容器中的目录，会在容器的根目录中创建一个 hahaha 的文件夹
最后一个框为路径/hahaha下面的路径,可不填
使用数据卷的效果：主机上的主机路径和容器上的hahaha文件夹中的内容完全一致
kube-state-metrics 和 metric-server 的区别
metric-server
TKEStack 的 Global 集群和新建的独立集群会默认安装名为 metric-server 的负载，是一个容器资源监控和性能分析工具。只是显示数据，并不提供数据存储服务，类似 cAdvisor（默认集成在 kubelet 中）、heapster（已被 metric-server 替代），可以利用 metric-server 提供的数据实现 HPA
kube-state-metrics
使用 TKEStack 为集群安装 Prometheus 监控组件时会安装名为 kube-state-metrics 的负载，用于为 Prometheus 提供监控数据。kube-state-metrics 基于 client-go 开发的服务，监听 Kubernetes APIServer，并将 Kubernetes 的结构化信息转换为 metrics，它不关注单个 Kubernetes 组件的运行状况，而是关注内部各种对象（例如 Deployment、Node、Pod）的运行状况。
kube-state-metrics 和 metric-server 一样，只是简单提供一个 metrics 数据，并不会存储这些指标数据，所以我们可以使用 Prometheus 来抓取这些数据然后存储
kube-state-metrics-service.yaml 中有 prometheus.io/scrape: ‘true’ 标识，因此会将 metrics 暴露给Prometheus，而 Prometheus 会在 kubernetes-service-endpoints 这个 job 下自动发现 kube-state-metrics，并开始拉取 metrics，无需其他配置。
使用 kube-state-metrics 后的常用场景有：
- 存在执行失败的 Job: kube_job_status_failed{job=“kubernetes-service-endpoints”,k8s_app=“kube-state-metrics”}==1
- 集群节点状态错误: kube_node_status_condition{condition=“Ready”,status!=“true”}==1
- 集群中存在启动失败的 Pod：kube_pod_status_phase{phase=~“Failed|Unknown”}==1
- 最近30分钟内有 Pod 容器重启: changes(kube_pod_container_status_restarts[30m])>0
- 配合报警可以更好地监控集群的运行
区别
- kube-state-metrics 主要关注的是业务相关的一些元数据，针对是是 k8s 集群内资源对象数据，比如 Deployment、Pod、副本状态等
- metrics-server 主要关注的是资源度量 API 的实现，比如 CPU、文件描述符、内存、请求延时等指标
- metric-server（或 heapster）是从 api-server 中获取 CPU、内存使用率这种监控指标，并把他们发送给存储后端，如 InfluxDB 或云厂商，他当前的核心作用是：为 HPA 等组件提供决策指标支持
- kube-state-metrics关注于获取 k8s 各种资源的最新状态，如 Deployment 或者 DaemonSet，之所以没有把 kube-state-metrics 纳入到 metric-server 的能力中，是因为他们的关注点本质上是不一样的。 metric-server 仅仅是获取、格式化现有数据，写入特定的存储，实质上是一个监控系统。而 kube-state-metrics 是将 k8s 的运行状况在内存中做了个快照，并且获取新的指标，但他没有能力导出这些指标
- 换个角度讲，kube-state-metrics 本身是 metric-server 的一种数据来源，虽然现在没有这么做
- 另外，像 Prometheus 这种监控系统，并不会去用 metric-server 中的数据，他都是自己做指标收集、集成的（Prometheus 包含了 metric-server的能力），但 Prometheus 可以监控 metric-server本 身组件的监控状态并适时报警，这里的监控就可以通过 kube-state-metrics 来实现，如 metric-server 的 Pod 的运行状态