共计 7548 个字符，预计需要花费 19 分钟才能阅读完成。
转自 @twt 社区，作者：谢文博。
优化首先须要建设起一个指标，到底优化要达到一个什么样的指标，冀望满足什么样的需要，解决业务减少过程中产生的什么问题。监控平台的建设是为 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 集群相干的一些特色指标数据。
* 正文 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 配置，依据日志剖析业务访问量，流动周期，业务峰值，调用关系等优化整个过程。
