华为云云原生钻石集训营第九课：Kubernetes运维管理详解（下）

课程目标：

1.了解集群监控基本方法

2.了解常见集群组件故障排错分析方法

3.了解华为云CIE集群监控方案架构

1.集群可观测性详解

2.常见集群故障排错分析

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

上一节课我们了解了应用在k8s生产环境中的最佳实践，包括应用更新与回滚，应用健康检查,弹性伸缩等特性。

本次课程将会带领大家深入理解K8S集群监控的最佳实践，帮助大家构建稳定、可靠的云原生应用服务。

1.集群可观测性详解

云原生应用特点：

应用架构:

1.从单体应用向微服务过渡

2.应用架构过渡为松耦合系统

3.应用版本迭代更快、周期更短

基础设施层:

1.容器化、应用自身快、轻、微

2.Kubernetes成为运行容器的默认平台

3.laaS、PaaS平台底层来承载Kubernetes平台

软件生命周期:

1. 服务通过DevOps流水线持续部署

2.服务变更低成本和低风险

3.呈现高频率和全自动变更

K8S与云原生应用监控挑战

K8S架构复杂性:K8S架构包括控制节点和工作节点。各自包含一组相互通信的组件，比如kube-apiserver,etcd, kubelet等,

微服务架构:应用从单体到微服务架构的转变，导致应用数量激增，相互依赖关系复杂，出现了问题之后，如何快速定位到发生问题的根本原因.

动态性:应用的迭代更新更加便捷迅速，POD、Service等资源随时可能会销毁或重建，需要监控系统具备动态发现k8s资源的能力。

成本:微服务的规模和动态性使得监控数据规模和收集的成本大幅度提高。

云原生可观测性

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

Metrics:收集并存储海量指标，通过指标阈值等手段实现告警通知，从而告知有没有问题发生。

Traces:通过告警指标发现问题后，依据调用追踪分析，进一步明确是什么问题。

Logs:明确了问题发生的对象或者位置后，通过日志分析等手段实现为什么问题会发生，即找到问题的根因。

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

指标监控与prometheus

指标监控:

指标(Metrics)是在许多个连续的时间周期里度量的KPI数值。

比如我们常常谈到的一个应用在过去十分钟、半小时内的CPU、内存占用率等。

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

系统指标:集群CPU使用率、磁盘使用率以及网络宽带情况等等。

应用指标:QPS、出错率、平均延时等。

业务指标:用户会话、订单数量和营业额等。

Prometheus简介:

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

目前，Prometheus已经成为云原生监控领域的事实标准。

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

Prometheus架构

prometheus的主要特点:

自定义多维数据模型(时序列数据由metric名和一组key/value标签组成)。

非常高效的存储，平均一个采样数据占~3.5 bytes左右，320万的时间序列，每30秒采样，保存60天，消耗磁盘大概228G。

在多维度上灵活且强大的查询语言(promQL)，支持sum,rate,max,min等大量的计算函数。

不依赖分布式存储，支持单节点工作。

基于pull方式采集时序数据。

可以通过push gateway进行时序列数据推送(pushing)。

可以通过服务发现或者静态配置去获取要采集的target。

社区支持大量的第三方exporter和client库。

基于Prometheus-operator集群监控

prometheus-operator:本质是一组CRD和controller的实现，prometheus operator提供如下几类CRD:

Prometheus:声明式创建和管理Prometheus Server实例;

ServiceMonitor:负责声明式的管理监控配置;

PrometheusRule:负责声明式的管理告警配置;

Alertmanager:声明式的创建和管理Alertmanager实例。

简言之，Prometheus Operator能够帮助用户自动化的创建以及管理Prometheus Server以及其相应的配置。

集群事件监控

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

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

集群日志监控(fluentd +ELK)

日志在K8S里面主要分为四个大的场景:

1.主机内核的日志:比如文件系统异常，kernelpanic,或者〇OM日志等。

2.Runtime日志:比较常见的是Docker的一些日志，我们可以通过docker的日志来排查类似像Pod Hang这一系列的问题。

3.核心组件日志:在K8s 里面核心组件包含了etcd,apiserver、kube-scheduler、controller-manger、kubelet 等等一系列的组件。这些组件的日志可以帮我们来看到整个K8s集群管控面是否有一些异常。

4.应用日志:可以通过应用的日志来查看业务层的一个状态。比如说可以看业务层有没有500的请求?有没有一些panic?有没有一些异常的错误访问?那这些其实都可以通过应用日志来进行查看的。

拓扑与调用链

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

CNCF 提出了分布式追踪的标准OpenTracing，它提供用户厂商中立的API，并提供Go、Java、JavaScript、Python、Ruby、PHP、Objective-C、C+＋和C#这多种语言的库。

同时CNCF中还有个端到端的支持OpenTracingAPI的分布式追踪项目Jaeger。

2.常见集群故障排错分析

集群常见问题排障

k8s常用排错方法:

查看Kubernetes对象的当前运行时信息，特别是与对象关联的Event事件。这些事件记录了相关主题、发生时间、最近发生时间、发生次数及事件原因等，对排查故障非常有价值。

对于服务、容器方面的问题，可能需要深入容器内部进行故障诊断，此时可以通过查看容器的运行日志来定位具体问题。

对于某些复杂问题，例如Pod调度这种全局性的问题，可能需要结合集群中每个节点上的Kubernetes服务日志来排查。比如搜集Master上的kube-apiserver、kube-schedule、kube-controler-manager服务日志，以及各个Node上的kubelet、kube-proxy服务日志，通过综合判断各种信息来定位问题。

常见K8S问题举例:

1.无法下载镜像

2. POD持续重启

3.通过Service无法访问

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