前言

《云原生王者之路集训营》是华为云云原生团队精心打磨的云原生学习技术公开课，分为黄金、钻石、王者三个阶段，帮助广大技术爱好者快速掌握云原生相关技能。本课程为黄金课程的第九课，由华为云容器洞察引擎CIE团队高级工程师 Roc主讲，带领大家深入理解K8S集群监控的最佳实践，帮助大家构建稳定、可靠的云原生应用服务。

目标学员：计算机、软件工程等专业的大学生，涉及Kubernetes、Istio等技术的应用开发者，其他的云原生技术兴趣爱好。学完本课程后，您将能够：了解集群监控基本方法；了解常见集群组件故障排错分析方法；了解华为云CIE集群监控方案架构。

上一节课我们了解了应用在k8s生产环境中的最佳实践，包括应用更新与回滚,应用健康检查弹性伸缩等特性。本次课程将会带领大家深入理解K8S集群监控的最佳实践，帮助大家构建稳定、可靠的云原生应用服务。

一 集群可观测性详解

1.1 云原生应用的特点

首先要明白云原生要具备云的天然基因，天生就是云的一部分。云原生不是为云而生，而是天生就是云，生而是云，所以它具有云的特性：通过网络访问、远端部署执行、可扩展弹性伸缩、共享、按需使用自助服务、高可用、可远程监控计费审计、标准化交付与位置无关等。

1. 应用架构:
   1. 从单体应用向微服务过渡
   2. 应用架构过渡为松耦合系统
   3. 应用版本迭代更快、 周期更短
2. 基础设施层:
   
   • 容器化、应用自身快、轻、微
   • Kubernetes 成为运行容器的默认平台
   • laaS、PaaS 平台底层来承载Kubernetes平台

     3. 软件生命周期:

1. 1. 服务通过DevOps流水线持续部署
   2. 服务变更低成本和低风险
   3. 呈现高频率和全自动变更

1.2 K8S与云原生应用监控挑战

虽然云原生为企业数字化带来了非常多的好处，但同时针对K8S与云原生应用的监控也带来了诸多挑战。

1. K8S架构复杂性: K8S架构包括控制节点和工作节点，各自包含一组相互通信的组件，比如kube-apiserver, etcd, kubelet等。
2. 微服务架构:应用从单体到微服务架构的转变，导致应用数量激增，相互依赖关系复杂，出现了问题之后,如何快速定位到发生问题的根本原因。
3. 动态性:应用的迭代更新更加便捷迅速，POD、Service等资源随时可能会销毁或重建，需要监控系统具备动态发现k8s资源的能力。
4. 成本:微服务的规模和动态性使得监控数据规模和收集的成本大幅度提高。

1.3 云原生可观测性

为了应对云原生监控的挑战，社区引入了可观测性这一理念。 可观测性系统主要基于Metrics、Traces、 Logs三大数据类型构建。

• Metrics:收集并存储海量指标，通过指标阈值等手段实现告警通知,从而告知有没有问题发生。
• Traces:通过告警指标发现问题后，依据调用追踪分析，进一步明确是什么问题。
• Logs:明确了问题发生的对象或者位置后，通过日志分析等手段实现为什么问题会发生，即找到问题的根因。

围绕着这三种数据类型，开源社区构建了多种多样的开源产品，像Prometheus, Cortex, node-problem-detector, Fluentd, ELK, Loki,Jaeger等。

1.4 指标监控与prometheus

1.4.1 指标监控

指标(Metrics) 是在许多个连续的时间周期里度量的KPI数值。比如我们常常谈到的一个应用在过去十分钟、半小时内的CPU、内存占用率等。

一般情况下可以将指标进行如下分类:

• 系统指标:集群CPU使用率、磁盘使用率以及网络宽带情况等等。
• 应用指标: QPS、 出错率、平均延时等。
• 业务指标:用户会话、订单数量和营业额等。

常见的开源指标监控系统有Zabbix、Prometheus等; 还有一些商业监控产品，比如sysdig. dynatrace等。

1.4.2 Prometheus简介

Prometheus受启发于Google的Brogmon监控系统(相似的Kubernetes是从Google的Brog系统演变而来)， 从2012年开始由前Google前工程师在Soundcloud以开源软件的形式进行研发,并且于2015年早期对外发布早期版本。201 6年5月继Kubernetes之后成为第二个正式加入CNCF基金会的项目。目前，Prometheus已经成为云原生监控领域的事实标准。

在kubernetes容器管理系统中，通常会搭配prometheus进行监控，同时也支持多种exporter采集数据，还支持pushgateway进行数据上报，Prometheus性能足够支撑上万台规模的集群。

1.5 prometheus的主要特点

监控工具prometheus具备完整的监控体系，其特点如下：

• 自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)。
• 非常高效的存储，平均一个采样数据占~3.5 bytes左右，320万的时间序列，每30秒采样，保存60天，消耗磁盘大概228G。
• 在多维度上灵活且强大的查询语言(promQL),支持sum, rate,max，min等大量的计算 函数。
• 不依赖分布式存储，支持单节点工作。
• 基于pull方式采集时序数据。
• 可以通过push gateway进行时序列数据推送(pushing)。
• 可以通过服务发现或者静态配置去获取要采集的target。
• 社区支持大量的第三方exporter和client库。

1.6 基于prometheus-operator集群监控

• prometheus-operator: 本质是一组CRD和controller的实现,prometheus operator提供如下几类CRD:
• Prometheus:声明式创建和管理Prometheus Server实例;
• ServiceMonitor:负责声明式的管理监控配置;
• PrometheusRule:负责声明式的管理告警配置;
• Alertmanager:声明式的创建和管理Alertmanager实例；
• Prometheus Operator能够帮助用户自动化的创建以及管理Prometheus Server以及其相应的配置。

prometheus-operator为了实现更方便的监控K8s中各类资源，利用watch机制关注自定义CRDs，通过prometheus来从不同的资源中pull拉去监控指标，通过Alertmanager来发送告警，通过Grafana来实现可视化。

1.7 K8S集群监控指标解析

K8s集群监控指标主要分为四个维度，从容器的基础资源例如container_cpu_usage_seconds_total来获取容器的各类运行指标；

K8s资源指标主要监控K8s中各类资源的运行状态；K8s服务组件指标主要包含K8s核心组件的各类运行指标，通过这类指标可以监控K8s整个集群的运行状态；Pod业务埋点指标，根据业务场景自定义指标，比如地订单数量，交易失败次数等，来反馈业务运行状态。

1.8 基于Grafana指标可视化

grafana是用于可视化大型测量数据的开源程序，他提供了强大和优雅的方式去创建、共享、浏览数据。dashboard中显示了你不同metric数据源中的数据。

Grafana是一个开源的，拥有丰富dashboard和图表编辑的指标分析平台，和Kibana不同的是Grafana专注于时序类图表分析，而且支持多种数据源，如Graphite、InfluxDB、Elasticsearch、Mysql、K8s、Zabbix等。

容器内存使用率

1.9 集群事件监控

k8s的Event事件是一种资源对象， 用于展示集群内发生的情况，k8s系统中的各个组件会将运行时发生的各种事件上报给apiserver。可以通过kubectl get event或kubectl describe pod podName命令显示事件，查看k8s集群中发生了哪些事件。

apiserver会将Event事件存在etcd集群中，为避免磁盘空间被填满，故强制执行保留策略:在最后一次的事件发生后， 删除1小时之前发生的事件。

通过监控集群状态，能更深层次的了解业务具体发生了什么类型的事件，从而对症下药，提升问题解决效率。

1.10 NodeProblemDetector (NPD)

节点问题检测器(Node Problem Detector, NPD)是-个守护程序，用于监视和报告节点的健康状况。

可以将NPD以DaemonSet运行。NPD从各种守护进程收集节点问题，并以NodeCondition和Event的形式报告给APIServer。

通过NPD，可以有效监控Node节点各类指标，从而更全方位的保障集群稳定性，预见一些资源问题风险，及时规避。

1.11 集群日志监控(fluentd+ELK)

针对K8s集群中业务日志监控，在K8S里面主要分为四个大的场景:

1. 主机内核的日志:比如文件系统异常，kernelpanic,或者OOM日志等。
2. Runtime日志:比较常见的是Docker的一些日志，我们可以通过docker的日志来排查类似像Pod Hang这一系列的问题。
3. 核心组件日志:在K8s里面核心组件包含了etcd,apiserver、kube-scheduler、 controller-manger、kubelet等等一系列的组件。 这些组件的日志可以帮我们来看到整个K8s集群管控面是否有一些异常。
4. 应用日志:可以通过应用的日志来查看业务层的一个状态。比如说可以看业务层有没有500的请求?有没有一些 panic?有没有一些异常的错误访问?那这些其实都可以通过应用日志来进行查看的。

 

1.12 拓扑与调用链

当我将单体应用拆成多个微服务之后,如何监控服务之间的依赖关系和调用链，以判断应用在哪个服务环节出了问题,哪些地方可以优化?这就需要用到分布式追踪(Distributed Tracing)。

CNCF提出了分布式追踪的标准OpenTracing,它提供用户厂商中立的API,并提供Go、Java、JavaScript、Python、 Ruby、 PHP、Objective-C、C++和C#这多种语言的库。同时CNCF中还有个端到端的支持OpenTracingAPI的分布式追踪项目Jaeger。

 

二 集群常见问题排障

2.1 k8s常用排错方法:

1. 查看Kubernetes对象的当前运行时信息，特别是与对象关联的Event事件。这些事件记录了相关主题、发生时间、最近发生间、发生次数及事件原因等，对排查故障非常有价值。
2. 对于服务、容器方面的问题，可能需要深入容器内部进行故障诊断，此时可以通过查看容器的运行日志来定位具体问题。
3. 对于某些复杂问题，例如Pod调度这种全局性的问题，可能需要结合集群中每个节点上的Kubernetes服务日志来排查。比如搜集Master.上的kube-apiserver、kube-schedule、 kube-controler-manager服务日志，以及各个Node.上的kubelet.kube-proxy服务日志，通过综合判断各种信息来定位问题。

2.2 常见K8S问题举例

1. 无法下载镜像：需要定位镜像是否存储，或者是否为K8s网络与镜像仓库无法联通，或者是私有镜像权限问题等；
2. POD持续重启 ：查看业务是否运行异常，或是配置的存活性探针异常。
3. 通过Service无法访问：查看业务POD是否正常，lable选择器是否匹配到对应业务POD，端口是否正常等。

2.3 实战案例

可以看到nginx 应用启动异常

使用华为云提供的cloud shell工具

通过命令行定位问题，首先查看pod状态，看到有三个pod运行异常

查看pod事件发现是pod的Liveness检测失败，返回状态码为404，找不到文件。

查看Liveness配置为/test

通过CCE集群对资源文件进行修正，修改/test为/。

可以看到此刻POD以及恢复正常。

三 华为云CIE集群监控方案架构详解

3.1 华为云容器洞察引擎(CIE) 架构解析

容器洞察引擎（Container Insight Engine，简称CIE）是以应用为中心、开箱即用的新一代云原生容器运维平台，实时监控应用及资源，采集各项指标及事件等数据分析应用健康状态，提供告警能力以及全面、清晰、多维度数据可视化能力，兼容主流开源组件，并提供快捷故障定位及一键监控诊断的能力。

架构特点:

1. 全面兼容云原生技术

• 基于原生K8s + Prometheus的监控架构体系,增强了开箱即用的能力。
• 从容应对容器生命周期动态变化、海量指标的挑战。

     2. 以应用为中心，聚焦业务指标

• 聚焦应用Golden Signal (RPS, Error, Duration) 等,并适时关联资源指标。

    3. Everything in One Place,快捷排障

• 应用全景视图和资源映射，可以无缝关联告警、事件、日志等信息。
• 分布式调用链和依赖拓扑，应对服务网格化，支持快速排障。

    4. 一键诊断,主动预测预警

• 键式集群业务诊断，关键指标主动预测，提前预警。

 

3.2 集中统一的告警、事件管理和日志分析

1. 集中告警/事件/日志:具备多集群告警、事件、日志统一管理能力;
2. 告警通知灵活:支持基于PromQL表达式的阈值告警,支持K8s事件转告警能力，告警可通过邮件，短信、webhook等通道及时通知给用户;
3. 统一日志存储:支持多种日志存储方式，支持日志浏览、统计聚合;支持日志关键词告警;

3.3 快速故障定位

• 资源模型统一建模：告警、日志、指标、事件运维数据对应的资源信息拉通统一， 同一个资源ID关联一片相关运维数据。
• 运维信息ALL in One：

• • 在告警、资源视图、巡检报告中提供-键式TroubleShooting入口，-键萃取资源故障相关信息。
  • 图形化资源关系视图，提供集群、节点、Pod实例、容器全景资源视图，实现故障渲染，提升故障发现效率。
  • 提供定期巡检，一键巡检并展示巡检报告，让用户时刻感知集群状态。
• 全链路应用调用分析：

• • 借力ASM lstio, 提供全链路应用拓扑，结合MCP实现集群内和跨集群的应用拓扑展示。
  • 非侵入试Agent埋点能力，实现基于业务的SLA指标监控。

总结

可观测性是云原生场景必不可少的一环，关系到云原生实践能否在生产环境顺利实施。可观测性技术实施具有技术栈多样，场景复杂，数据规模大等特点，这给人们云原生实践带来了很大的障碍。开源社区针对这个问题，着手构建统一的云原生可观测性技术与规范；各大云厂商与监控服务提供商也都看到了需求和机遇，陆续推出云原生可观测性相关的产品或功能。

目前，云原生可观测性还在发展初期，很多产品都在探索阶段，还有很多问题亟待解决。未来人们对可观测性的需求只会越来越高，华为云CIE紧跟社区最新标准与方案，在监控运维上，强调数据关联分析和无缝衔接，用户无需到各个页面频繁跳转，在一个地方就可以对问题进行集中分析和诊断，实现一键式故障分析，大大缩短问题定位定界的时间。

 

本文整理自华为云社区【内容共创】活动第14期。

https://bbs.huaweicloud.com/blogs/336904

任务19.华为云云原生钻石课程09：Kubernetes运维管理详解（下）