Kubernetes 服务发现 Cadvisor监控容器资源使用率_富士康质检员张全蛋的博客

相关文章推荐

坚韧的南瓜 · Prometheus ...· 1 周前 ·

机灵的乌冬面 · K8S的更新、回滚、伸缩_failedget ...· 5 天前 ·

坏坏的煎饼果子 · ServletOutputStream转Fi ...· 2 月前 ·

怕老婆的柠檬 · Perl ...· 7 月前 ·

长情的火锅 · java - Collectors ...· 11 月前 ·

风流倜傥的熊猫 · 请问DigitalMicrograph软件如 ...· 1 年前 ·

健壮的李子 · CMake Error: ...· 1 年前 ·

前面我们和大家介绍过了在 Prometheus 中用静态的方式来监控 Kubernetes 集群中的普通应用，但是如果针对集群中众多的资源对象都采用静态的方式来进行配置的话显然是不现实的，所以同样我们需要使用到 Prometheus 提供的其他类型的服务发现机制。

说到容器监控我们自然会想到 cAdvisor ， 我们前面也说过 cAdvisor 已经内置在了 kubelet 组件之中，所以我们不需要单独去安装。

cAdvisor 的数据路径为 /api/v1/nodes/<node>/proxy/metrics。

同样我们这里使用 node 的服务发现模式，因为每一个节点下面都有 kubelet ，自然都有 cAdvisor 采集到的数据指标，配置如下：

- job_name: 'kubernetes-cadvisor'
  kubernetes_sd_configs:
  - role: node
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  relabel_configs:
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+)
  - target_label: __address__
    replacement: kubernetes.default.svc:443
  - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
- action: labelmap 匹配到下面正则表达式的标签会被保留  
  - action: labelmap
    regex: __meta_kubernetes_node_label_(.+) 
  - target_label: __address__
    replacement: kubernetes.default.svc:443
 - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor 
上面的配置和我们之前配置 node-exporter 的时候几乎是一样的，区别是我们这里使用了 https 的协议，另外需要注意的是配置了 ca.cart 和 token 这两个文件，这两个文件是 Pod 启动后自动注入进来的，通过这两个文件我们可以在 Pod 中访问 apiserver，比如我们这里的__address__不在是 nodeip 了，而是 kubernetes 在集群中的服务地址，然后加上__metrics_path__的访问路径：/api/v1/nodes/${1}/proxy/metrics/cadvisor，现在同样更新下配置，然后查看 Targets 路径：  
[root@master prometheus]# curl 10.233.0.1:443/api/v1/nodes/192.168.100.5/proxy/metrics/cadvisor
Client sent an HTTP request to an HTTPS server. 
然后我们可以切换到 Graph 路径下面查询容器相关数据，比如我们这里来查询集群中所有 Pod 的 CPU 使用情况，这里用的数据指标是 container_cpu_usage_seconds_total，然后去除一些无效的数据，查询1分钟内的数据，由于查询到的数据都是容器相关的，最好要安装 Pod 来进行聚合，对应的promQL语句如下： 
sum by (pod_name)(rate(container_cpu_usage_seconds_total{image!="", pod_name!=""}[1m] ))
----------------------------------------------------------------------------------------------------------------------------- 
说到容器监控我们自然会想到 cAdvisor，我们前面也说过 cAdvisor 已经内置在了 kubelet 组件之中，所以我们不需要单独去安装，cAdvisor 的数据路径为 /api/v1/nodes/<node>/proxy/metrics，但是我们不推荐使用这种方式，因为这种方式是通过 APIServer 去代理访问的，对于大规模的集群会对 APIServer 造成很大的压力，所以我们可以直接通过访问 kubelet 的 /metrics/cadvisor 这个端点来获取 cAdvisor 的数据，同样我们这里使用 node 的服务发现模式，因为每一个节点下面都有 kubelet，自然都有 cAdvisor 采集到的数据指标，配置如下： 
- job_name: "cadvisor"
  kubernetes_sd_configs:
    - role: node
  scheme: https
  tls_config:
    ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    insecure_skip_verify: true
  bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
  relabel_configs:
    - action: labelmap
      regex: __meta_kubernetes_node_label_(.+)
    - replacement: /metrics/cadvisor # <nodeip>/metrics -> <nodeip>/metrics/cadvisor
      target_label: __metrics_path__
  # 下面的方式不推荐使用
  # - target_label: __address__
  #   replacement: kubernetes.default.svc:443
  # - target_label: __metrics_path__
  #   replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor 
上面的配置和我们之前配置 node-exporter 的时候几乎是一样的，区别是我们这里使用了 https 的协议，另外需要注意的是配置了 ca.cart 和 token 这两个文件，这两个文件是 Prometheus 的 Pod 启动后自动注入进来的，然后加上 __metrics_path__ 的访问路径 /metrics/cadvisor，现在同样更新下配置，然后查看 Targets 路径：  
我们可以切换到 Graph 路径下面查询容器相关数据，比如我们这里来查询集群中所有 Pod 的 CPU 使用情况，kubelet 中的 cAdvisor 采集的指标和含义，可以查看 Monitoring cAdvisor with Prometheus 说明，比如其中有一项： 
container_cpu_usage_seconds_total   Counter     Cumulative cpu time consumed    seconds
container_cpu_usage_seconds_total 是容器累计使用的 CPU 时间，用它除以 CPU 的总时间，就可以得到容器的 CPU 使用率了。 
首先计算容器的 CPU 占用时间，由于节点上的 CPU 有多个，所以需要将容器在每个 CPU 上占用的时间累加起来，Pod 在 1m 内累积使用的 CPU 时间为：(根据 pod 和 namespace 进行分组查询) 
sum(rate(container_cpu_usage_seconds_total{image!="",pod!=""}[1m])) by (namespace, pod)
然后计算 CPU 的总时间，这里的 CPU 数量是容器分配到的 CPU 数量，container_spec_cpu_quota 这个指标就是容器的 CPU 配额，它的值是容器指定的 CPU 个数 * 100000，所以 Pod 在 1s 内 CPU 的总时间为：Pod 的 CPU 核数 * 1s： 
sum(container_spec_cpu_quota{image!="", pod!=""}) by(namespace, pod) / 100000
 由于 container_spec_cpu_quota 是容器的 CPU 配额，所以只有配置了 resource-limit CPU 的 Pod 才可以获得该指标数据。 
将上面这两个语句的结果相除，就得到了容器的 CPU 使用率： 
(sum(rate(container_cpu_usage_seconds_total{image!="",pod!=""}[1m])) by (namespace, pod))
(sum(container_spec_cpu_quota{image!="", pod!=""}) by(namespace, pod) / 100000) * 100
在 promethues 里面执行上面的 promQL 语句可以得到下面的结果： 
Pod 内存使用率的计算就简单多了，不过我们也要想了解几个和 Pod 内存使用率相关的指标： 
整体来说 container_memory_max_usage_bytes > container_memory_usage_bytes >= container_memory_working_set_bytes > container_memory_rss，从上面的指标描述来看似乎 container_memory_usage_bytes 指标可以更容易用来跟踪内存使用率，但是该指标还包括在内存压力下可能被驱逐的缓存（比如文件系统缓存），更好的指标是使用 container_memory_working_set_bytes，因为 kubelet 也是根据该指标来判断是否 OOM 的，所以用 working set 指标来评估内存使用率更加科学，对应的 PromQL 语句如下所示： 
sum(container_memory_working_set_bytes{image!=""}) by(namespace, pod) / sum(container_spec_memory_limit_bytes{image!=""}) by(namespace, pod) * 100 != +inf
在 Promethues 里面执行上面的 promQL 语句可以得到下面的结果： 
如果只是一键替换，那么不需要源标签source_labels和正则表达式regex  
  - target_label: __address__
    replacement: kubernetes.default.svc:443
 如果需要从源标签里面取值，那么就需要source_labels和正则表达式regex  
  - source_labels: [__meta_kubernetes_node_name]
    regex: (.+)
    target_label: __metrics_path__
    replacement: /api/v1/nodes/${1}/proxy/metrics/cadvisor
                    前面我们和大家介绍过了在 Prometheus 中用静态的方式来监控 Kubernetes 集群中的普通应用，但是如果针对集群中众多的资源对象都采用静态的方式来进行配置的话显然是不现实的，所以同样我们需要使用到 Prometheus 提供的其他类型的服务发现机制。容器监控说到容器监控我们自然会想到cAdvisor，我们前面也说过cAdvisor已经内置在了 kubelet 组件之中，所以我们不需要单独去安装。cAdvisor的数据路径为/api/v1/nodes/&lt;node&gt;/.
				近年来Docker容器作为一种轻量级虚拟化技术革新了整个IT领域软件开发部署流程，如何高效自动管理容器和相关的计算、存储等资源，将容器技术真正落地上线，则需要一套强大容器编排服务，当前大红大紫的Kubernetes已经被公认为这个领域的领导者。Google基于内部Borg十多年大规模集群管理经验在2014年亲自倾心打造了Kubernetes这个开源项目，欲倚之与AWS在云计算2.0时代一争高下，即便如此，Kubernetes的定位主要是面向私有云市场，它最典型的部署模式是在GCE或AWS平台上基于云主机、云网络、云硬盘及负载均衡等技术给用户单独部署一整套Kubernetes容器管理集群，其本质
				运营容器化的基础设施带来了一系列新的挑战。我们需要增强容器、评估API端点的性能以及识别出基础设施中的有害部分。Istio服务网格可在不修改代码的情况下实现API增强，并且不会带来服务延迟。这篇文章将介绍如何全面了解Kubernetes基础设施以及如何在基于容器的基础设施中使用Istio服务网格。Istio是用于Kubernetes的服务网格，负责处理服务之间的通信，就像网络路由软件处理TCP/IP流量那样。除了Kubernetes之外，Istio还可以与基于Docker和Consul的服务发生交互。它与已经存在了一段时间的LinkerD有点相似。Istio是由来自谷歌、IBM、思科和Lyf
				cAdvisor是谷歌开源的一个容器监控工具，该工具提供了webUI和REST API两种方式来展示数据，从而可以帮助管理者了解主机以及容器的资源使用情况和性能数据。
cAdvisor集成到了kubelet组件内，因此可以在kube集群中每个启动了kubelet的节点使用cAdvisor来查看该节点的运行数据。cAdvisor对外提供web服务的默认端口为4194，rest API服务端口默认为