本文转载自微信公众号「twt企业IT社区」，作者twt社区 。转载本文请联系twt企业IT社区公众号。
优化首先需要建立起一个目标，到底优化要达到一个什么样的目标，期望满足什么样的需求，解决业务增加过程中发生的什么问题。监控平台的建立是为Kubernetes集群及运行的业务系统得出系统的真实性能，有了现有系统当前的真实性能就可以设定合理的优化指标，基本基线指标才能合理评估当前Kubernetes容器及业务系统的性能。本文介绍了如何建立有效的监控平台。
1. 监控平台建设
所有的优化指标都是建立在对系统的充分了解上的，常规基于Kubernetes的监控方案有以下大概有3种，我们就采用比较主流的方案，也降低部署成本和后期集成复杂度。
主流也是我们选取的方案是Prometheus +Grafana +cAdvisor +(要部署：Prometheus-operator, met-ric-server)，通过Prometheus提供相关数据，Prometheus定期获取数据并用Grafana展示，异常告警使用AlertManager进行告警。实际部署过程中实施也可以考虑使用Kube-prometheus项目(参见注释1)整体部署节省大量工作，以下是官方架构图，涉及到组件如下:
- Prometheus Operator
- Prometheus
- Alertmanager
- Prometheus node-exporter
- Prometheus Adapter for KubernetesMetrics APIs
- kube-state-metrics
- Grafana
上图中的Service和ServiceMonitor都是Kubernetes的资源，一个ServiceMonitor可以通过labelSelector的方式去匹配一类Service，Prometheus也可以通过labelSelector去匹配多个ServiceMonitor。
主要监控范围分为：资源监控，性能监控，任务监控，事件告警监控等，因为本篇主要讲的是性能优化，所以侧重点放在性能监控上，但是优化是全方位的工作所以也会涉及到资源，健康度，事件，日志等，另外就针对每种监控类型的告警管理。
*注释1：项目地址如下，就部署方式可参见项目介绍在此就不赘述：
https://github.com/coreos/kube-prometheus
2.数据采集
各维度的数据采集主要通过以下方式：
- 部署cAdvisor(参见注释2)采集容器相关的性能指标数据，并通过metrics接口用Prometheus抓取;
- 也可根据需求可将各种监控，日志采集的Agent部署在独立的容器中，跟随Pod 中的容器一起启动监督采集各种数据，具体可根据实际需求;
- 通过Prometheus-node-exporter采集主机的性能指标数据，并通过暴露的metrics接口用Prometheus抓取
- 通过exporter采集应用的网络性能(Http、Tcp等)数据，并通过暴露的metrics接口用Prometheus抓取
- 通过kube-state-metrics采集k8S资源对象的状态指标数据，并通过暴露的metrics接口用Prometheus抓取
- 通过etcd、kubelet、kube-apiserver、kube-controller-manager、kube-scheduler自身暴露的metrics获取节点上与k8S集群相关的一些特征指标数据。
node-exporter：负责采集主机的信息和操作系统的信息，以容器的方式运行在监控主机上。
cAdvisor：负责采集容器的信息，以容器的方式运行在监控主机上。
3. 资源监控說明
资源监控主要分为这几大类：如：CPU，内存，网络，磁盘等信息的监控(其它还有对GPU等监控)，另外就是对各种组件服务的资源使用情况，自定义告警阈值等(简单的告警获可以沿用内部已有的，复杂的告警指标需自己根据集群和业务特征通过获取参数进行计算或撰写PromQL获取)，建立全方位的监控指标(主要监控指标项可参见Kube-prometheus部署后的相关信息，在此就不赘述)，主要监控项如下;
- 容器 CPU，Mem，Disk, Network等资源占用等情况;
- Node、Pod相关的性能指标数据;
- 容器内进程自己主动暴露的各项指标数据;
- 各个组件的性能指标涉及组件如：ECTD,API Server, Controller Manager, Scheduler, Kubelet等;
主要的监控指标，是依据Google提出的四个指标：延迟(Latency)、流量(Traffic)、错误数(Errors)、饱和度(Saturation)。实际操作中可以使用USE或RED(详见注释3和4)方法作为衡量方法，USE用于资源，RED用于服务，它们在不同的监控场景有不同维度描述，相结合能够描述大部分监控场景指标，合理的使用以下监控指标，有助用户判断当前K8S集群的实际运行情况，可根据指标变化反复优化各个参数和服务，使其达到更加的状态，更详细的监控指标信息，可参见Kube-prometheus相关监控信息。
4.1 Cadvisor指标采集
cAdvisor(详见参考1)提供的Container指标最终是底层Linux cgroup提供的。就像Node指标一样，但是我们最关心的是CPU/内存/网络/磁盘。
1.CPU(利用率)
对于Container CPU利用率，K8S提供了每个容器的多个指标：
#过去10秒容器CPU的平均负载
container_cpu_load_average_10s
#累计用户消耗CPU时间(即不在内核中花费的时间)
container_cpu_user_seconds_total
#累计系统CPU消耗的时间(即在内核中花费的时间)
container_cpu_system_seconds_total
#累计CPU消耗时间
container_cpu_usage_seconds_total
#容器的CPU份额
container_spec_cpu_quota
#容器的CPU配额
container_spec_cpu_shares
#查询展示每个容器正在使用的CPU
sum(
rate(container_cpu_usage_seconds_total [5m]))
by(container_name)
# 过去10秒内容器CPU的平均负载值
container_cpu_load_average_10s{container="",id="/",image="",name="",namespace="",pod=""}
#累计系统CPU消耗时间
sum(rate(container_cpu_usage_seconds_total{name=~".+"}[1m])) by (name) * 100
#全部容器的CPU使用率总和，将各个CPU使用率进行累加后相除
sum(rate(container_cpu_usage_seconds_total{container_name="webapp",pod_name="webapp-rc-rxli1"}[1m])) / (sum(container_spec_cpu_quota{container_name="webapp",pod_name="webapp-rc-rxli1"}/100000))
2.CPU(饱和度)
sum(
rate(container_cpu_cfs_throttled_seconds_total[5m]))
by (container_name)
3.内存
cAdvisor中提供的内存指标是从可参见官方网站，以下是内存指标(如无特殊说明均以字节位单位)：
#高速缓存(Cache)的使用量
container_memory_cache
# RSS内存，即常驻内存集，是分配给进程使用实际物理内存，而不是磁盘上缓存的虚拟内存。RSS内存包括所有分配的栈内存和堆内存，以及加载到物理内存中的共享库占用的内存空间，但不包括进入交换分区的内存
container_memory_rss
#容器虚拟内存使用量。虚拟内存(swap)指的是用磁盘来模拟内存使用。当物理内存快要使用完或者达到一定比例，就可以把部分不用的内存数据交换到硬盘保存，需要使用时再调入物理内存
container_memory_swap
#当前内存使用情况，包括所有使用的内存，不管是否被访问 (包括 cache, rss, swap等)
container_memory_usage_bytes
#最大内存使用量
container_memory_max_usage_bytes
#当前内存工作集(working set)使用量
container_memory_working_set_bytes
#内存使用次数达到限制
container_memory_failcnt
#内存分配失败的累积数量
container_memory_failures_total
#内存分配失败次数
container_memory_failcnt
4.内存(利用率)
通过PromQL特定条件查询容器内job内存使用情况:
container_memory_usage_bytes{instance="10.10.2.200:3002",job="panamax", name="PMX_UI"}18
kubelet 通过container_memory_working_set_bytes 来判断是否OOM， 所以用 working set来评价容器内存使用量更合理，以下查询中我们需要通过过滤“POD”容器，它是此容器的父级cgroup，将跟踪pod中所有容器的统计信息。
sum(container_memory_working_set_bytes {name!～“ POD”})by name
5.内存(饱和度)
OOM的异常获取没有直接的指标项，因为OOM后Container会被杀掉，可以使用如下查询来变通获取，这里使用label_join组合了 kube-state-metrics 的指标：
sum(container_memory_working_set_bytes) by (container_name) / sum(label_join(kube_pod_con-tainer_resource_limits_memory_bytes,"container_name", "", "container")) by (container_name)
6.磁盘(利用率)
在处理磁盘I/O时，我们通过查找和读写来跟踪所有磁盘利用率，Cadvisor有以下指标可以做位基本指标：
#容器磁盘执行I/O的累计秒数
container_fs_io_time_seconds_total
#容器磁盘累计加权I/O时间
container_fs_io_time_weighted_seconds_total
#查询容器文件系统读取速率(字节/秒)
sum(rate(container_fs_writes_bytes_total{image!=""}[1m]))without (device)
#查询容器文件系统写入速率(字节/秒)
sum(rate(container_fs_writes_bytes_total{image!=""}[1m]))without (device)
最基本的磁盘I/O利用率是读/写的字节数, 对这些结果求和，以获得每个容器的总体磁盘I/O利用率：
sum(rate(container_fs_reads_bytes_total[5m])) by (container_name,device)
7.网络(利用率)
容器的网络利用率，可以选择以字节为单位还是以数据包为单位。网络的指标有些不同，因为所有网络请求都在Pod级别上进行，而不是在容器上进行以下的查询将按pod名称显示每个pod的网络利用率：
#接收时丢包累计计数
container_network_receive_bytes_total
#发送时丢包的累计计数
container_network_transmit_packets_dropped_total
#接收字节(1m)
sum(rate(container_network_receive_bytes_total{id="/"}[1m])) by (id)
#上传字节(1m)
sum(rate(container_network_transmit_bytes_total{id="/"}[1m])) by (id)
8.网络(饱和度)
在无法得知准确的网络带宽是多少的情况下，网络的饱和度无法明确定义，可以考虑使用丢弃的数据包代替，表示当前已经饱和，参见以下参数：
#接收时丢包累计计数
container_network_receive_packets_dropped_total
#发送时丢包的累计计数
container_network_transmit_packets_dropped_total
*注释3：
在对于cAdvisor 容器资源，USE方法指标相对简单如下：
Utilization：利用率
Saturation：饱和度
Error：错误
*注释4：
USE 方法的定义：
Resource：所有服务器功能组件(CPU，Disk，Services等)
Utilization：资源忙于服务工作的平均时间
Saturation：需要排队无法提供服务的时间
Errors：错误事件的计数
RED 方法的解释：
Rate：每秒的请求数。
Errors：失败的那些请求的数量。
参考 1：
更详细关于cAdvisor的参数信息大家可以一下地址获取,也可以自己组合更加适用于自己集群的监控指标：
https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md
参考2：
关于Node_exporter，大家有兴趣可以参考Prometheus项目中关于Node_exporter里面说明如下：
https://github.com/prometheus/node_exporter
5. 事件告警监控
监控Event 转换过程种的变化信息，以下只是部份告警信息，Kube-Prometheus项目中有大部分告警指标，也可以从第三方导入相关告警事件：
#存在执行失败的Job:
kube_job_status_failed{job=”kubernetes-service-endpoints”,k8s_app=”kube-state-metrics”}==1
#集群节点状态错误:
kube_node_status_condition{condition=”Ready”,status!=”true”}==1
#集群节点内存或磁盘资源短缺:
kube_node_status_condition{condition=~”OutOfDisk|MemoryPressure|DiskPressure”,status!=”false”}==1
#集群中存在失败的PVC：
kube_persistentvolumeclaim_status_phase{phase=”Failed”}==1
#集群中存在启动失败的Pod：
kube_pod_status_phase{phase=~”Failed|Unknown”}==1
#最近30分钟内有Pod容器重启:
changes(kube_pod_container_status_restarts[30m])>0
6. 日志监控
日志也是K8S集群和容器/应用服务的很重要的数据来源，日志中也能获取各种指标和信息，主流的方式采用常驻的Agent采集日志信息，将相关发送到Kafka集群最后写入ES，也通过Grafana进行统一展示各项指标。
6.1 日志采集
- 一种方式将各个容器的日志都写入宿主机的磁盘，容器挂载宿主机本地Volume,采用Agent(Filebeat或Fluentd )采集这个部署在宿主机上所有容器转存的日志，发送到远端ES集群进行加工处理;
- 另一种是对于业务组(或者说Pod)采集容器内部日志，系统/业务日志可以存储在独立的Volume中，可以采用Sidecar模式独立部署日志采集容器，来对进行日志采集，对于DaemonSet和Sidecar这两种日志采集模式，大家可以根据实际需要选择部署;
- 通过部署在每个Node上的Agent进行日志采集，Agent会把数据汇集到Logstash Server集群，再由Logstash加工清洗完成后发送到Kafka集群，再将数据存储到Elasticsearch，后期可通过Grafana或者Kibana做展现，这也是比较主流的一个做法。
主要需要采集的各种日志分为以下场景：
1.主机系统内核日志采集：
- 一方面是主机系统内核日志，主机内核日志可以协助开发/运维进行一些常见的问题分析诊断，如：Linux Kernel Panic涉及的(Attempted to kill the idle task，Attempted to kill init，killing interrupt handler)其它致命异常，这些情况要求导致其发生的程序或任务关闭，通常异常可能是任何意想不到的情况;
- 另一方面是各种Driver 驱动异常，比如：Driver内核对象出现异常或者说使用GPU的一些场景，各种硬件的驱动异常可能是比较常见的错误;
- 再就是文件系统异常，一些特定场景(如：虚机化，特定文件格式)，实际上是会经常出现问题的。在这些出现问题后，开发者是没有太好的办法来去进行监控和诊断的。这一部分，其实是可以主机内核日志里面来查看到一些异常。
K8S集群中各种组件是集群非常重要的部份，既有内部组件也有外部的如：API Server, Controller-man-ger，Kubelet , ECTD等， 它们会产生大量日志可用于各种错误分析和性能优化，也能帮助用户很好分析K8S集群各个组件资源使用情况分析，异常情况分析;还有各种第三方插件的日志(尤其是一些厂商贡献的网络插件或算法)，也是优化分析的重点;
3.业务日志采集：
业务日志分析也是优化的很重要的环节，业务系统自身的特性(如：web类，微服务类，API 接口类，基础组件类)都需要日志来分析，结合后面的资源预测和业务部署章节能否更好把握业务特性，创建合理的发布配置和Pod配置，根据日志分析业务访问量，活动周期，业务峰值，调用关系等优化整个过程。