总结：K8S可观测

一、介绍

Kubernetes 系统的可观测性方案包括指标、日志、链路追踪、K8s Event 事件、NPD 框架等方式。

https://new.qq.com/rain/a/20210605A02GBV00

二、指标（Metrics）

Prometheus 是业界指标类数据采集方案的事实标准，是开源的系统监测和报警框架。

Prometheus 具有以下特性：

• 多维的数据模型（基于时间序列的 Key、Value 键值对）

• 灵活的查询和聚合语言 PromQL

• 通过基于 HTTP 的 Pull模型采集或利用 Pushgateway实现 Push 模式

• 可通过动态服务发现或静态配置发现目标机器

• 支持多种图表和数据大盘

Prometheus 可以周期性采集组件暴露在 HTTP(s) 端点的/metrics 下面的指标数据，并存储到 TSDB，实现基于 PromQL 的查询和聚合功能。

https://blog.csdn.net/w2009211777/article/details/123822132

三、K8S指标：容器基础资源指标

采集源为 kubelet 内置的 cAdvisor，提供容器内存、CPU、网络、文件系统等相关的指标，指标样例包括：

容器当前内存使用字节数 container_memory_usage_bytes；

容器网络接收字节数 container_network_receive_bytes_total；

容器网络发送字节数 container_network_transmit_bytes_total，等等。

四、K8S指标：节点资源指标

采集源为 node_exporter，提供节点系统和硬件相关的指标，指标样例包括：节点总内存 node_memory_MemTotal_bytes，节点文件系统空间 node_filesystem_size_bytes，节点网络接口 ID node_network_iface_id，等等。基于该类指标，可以统计节点的 CPU/内存/磁盘使用率等节点级别指标。

针对node_exporter，我们是单独部署了一个prometheus采集，专门给管理员他们看的，业务部关系node

五、K8S指标：资源指标

采集源为 kube-state-metrics，基于 Kubernetes API 对象生成指标，提供 K8s 集群资源指标，例如 Node、ConfigMap、Deployment、DaemonSet 等类型。以 Node 类型指标为例，包括节点 Ready 状态指标 kube_node_status_condition、节点信息kube_node_info 等等。

六、K8S指标：组件指标

1、Kubernetes 系统组件指标

例如 kube-controller-manager, kube-apiserver，kube-scheduler, kubelet，kube-proxy、coredns 等。

2、Kubernetes 运维组件指标。

可观测类包括 blackbox_operator, 实现对用户自定义的探活规则定义；gpu_exporter，实现对 GPU 资源的透出能力。

3、Kubernetes 业务应用指标。

包括具体的业务Pod在/metrics 路径透出的指标，以便外部进行查询和聚合。

除了上述指标，K8s 提供了通过 API 方式对外透出指标的监测接口标准，具体包括 Resource Metrics，Custom Metrics 和 External Metrics 三类。

十、Pod异常排查

1、Pod 状态异常

就绪失败，即 Pod 一直无法到达 Ready 状态，无法接收请求进行业务处理，常见的根因如下：

• 资源不足，无法调度（Pending），即集群的 Node 没有预留资源能够满足 Pod 的 Request 资源。

• 镜像拉取失败（ ImagePullBackoff ），镜像的仓库地址，tag 出现问题。

• 磁盘挂载失败（Pending），容器挂载的 PVC 没有 bound。

• Liveless probe 探针失败，频繁重启。

• Readiness probe 探针失败，无法达到 Ready 状态。

• postStart 执行失败，一直无法进入运行状态。

• 运行时程序崩溃（ CrashLoopBackOff ），频繁重启。

• 配置错误，比如挂载的 Volume 不存在（RunContainerError）。

2、容器频繁重启

报告期内出现 Pod 频繁重启现象，常见的根因如下：

• 程序异常退出，比如非法地址访问，比如进入了程序需要退出的条件等。

• 容器内存使用量超过内存 Limit 量，被 OOMKilled。

3、Pod 相关服务状态异常

具体体现在 Pod 服务的请求错误率变高或者请求处理 P95 响应时间高等，常见的根因如下：

• 请求量突增，程序自身可能触发流控或者其他异常处理，导致请求处理失败率提升；

• 自身代码处理错误，请求量没有变化，可能是上线新的功能有 bug；

• 不可压缩资源不足（磁盘，内存），请求处理包含磁盘的写操作，资源不足出现失败；外部依赖服务报错，请求处理需要调用下游服务，他们报错引发请求处理失败。

• 外部依赖服务响应时间高，请求处理需要调用下游服务，他们的响应时间高会导致请求处理慢。

4、Pod 内存使用率过高

Pod 容器出现内存 OOM，Pod 频繁重启，常见的根因如下：

• 自身代码内存泄露；

• Pod 内存 Request 值偏低，如果该值偏低的情况下配置 HPA，会频繁触发扩容，同时具有被驱逐的风险。

• Pod 内存 Limit 值偏低，容器内存使用量超过 Limit 值会被 OOMKilled 掉。

5、Pod CPU使用率过高

Pod 的整体 CPU 使用率一直维持在超过 80% 的状态，常见的根因如下：

• 自身代码效率不足，业务处理的时间复杂度太高，需要找到热点方法进行优化；

• Pod CPU Request 值偏低，如果该值偏低的情况下配置 HPA，会频发触发扩容，同时具有被驱逐的风险。

https://new.qq.com/rain/a/20210605A02GBV00