总结: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

你可能感兴趣的:(K8S,kubernetes,docker,容器)