转自@twt社区，作者：谢文博。

优化首先须要建设起一个指标，到底优化要达到一个什么样的指标，冀望满足什么样的需要，解决业务减少过程中产生的什么问题。监控平台的建设是为Kubernetes集群及运行的业务零碎得出零碎的真实性能，有了现有零碎以后的真实性能就能够设定正当的优化指标，根本基线指标能力正当评估以后Kubernetes容器及业务零碎的性能。本文介绍了如何建设无效的监控平台。

1. 监控平台建设

所有的优化指标都是建设在对系统的充沛理解上的，惯例基于Kubernetes的监控计划有以下大略有３种，咱们就采纳比拟支流的计划，也升高部署老本和前期集成复杂度。

支流也是咱们选取的计划是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集群相干的一些特色指标数据。
*正文2：node-exporter：负责采集主机的信息和操作系统的信息，以容器的形式运行在监控主机上。cAdvisor：负责采集容器的信息，以容器的形式运行在监控主机上。

3. 资源监控說明

资源监控次要分为这几大类：如：CPU，内存，网络，磁盘等信息的监控（其它还有对GPU等监控），另外就是对各种组件服务的资源应用状况，自定义告警阈值等（简略的告警获能够沿用外部已有的，简单的告警指标需本人依据集群和业务特色通过获取参数进行计算或撰写PromQL获取），建设全方位的监控指标（次要监控指标项可参见Kube-prometheus部署后的相干信息，在此就不赘述），次要监控项如下；

  • 容器 CPU，Mem，Disk, Network等资源占用等状况；
  • Node、Pod相干的性能指标数据；
  • 容器内过程本人被动裸露的各项指标数据；
  • 各个组件的性能指标波及组件如：ECTD,API Server, Controller Manager, Scheduler, Kubelet等；

4. 次要指标监控

次要的监控指标，是根据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做展示，这也是比拟支流的一个做法。

6.2 日志场景

次要须要采集的各种日志分为以下场景：

1．主机零碎内核日志采集：

  • 一方面是主机零碎内核日志，主机内核日志能够帮助开发/运维进行一些常见的问题剖析诊断，如：Linux Kernel Panic波及的（Attempted to kill the idle task，Attempted to kill init，killing interrupt handler）其它致命异样，这些状况要求导致其产生的程序或工作敞开，通常异样可能是任何意想不到的状况；
  • 另一方面是各种Driver 驱动异样，比方：Driver内核对象出现异常或者说应用GPU的一些场景，各种硬件的驱动异样可能是比拟常见的谬误；
  • 再就是文件系统异样，一些特定场景（如：虚机化，特定文件格式），实际上是会经常出现问题的。在这些呈现问题后，开发者是没有太好的方法来去进行监控和诊断的。这一部分，其实是能够主机内核日志外面来查看到一些异样。

2．组件日志采集：

K8S集群中各种组件是集群十分重要的部份，既有外部组件也有内部的如：API Server, Controller-man-ger，Kubelet , ECTD等， 它们会产生大量日志可用于各种谬误剖析和性能优化，也能帮忙用户很好剖析K8S集群各个组件资源应用状况剖析，异常情况剖析；还有各种第三方插件的日志（尤其是一些厂商奉献的网络插件或算法），也是优化剖析的重点；

3．业务日志采集：

业务日志剖析也是优化的很重要的环节，业务零碎本身的个性（如：web类，微服务类，API 接口类，根底组件类）都须要日志来剖析，联合前面的资源预测和业务部署章节是否更好把握业务个性，创立正当的公布配置和Pod配置，依据日志剖析业务访问量，流动周期，业务峰值，调用关系等优化整个过程。