Metrics API
介绍 Metrics-Server 之前, 必须要提一下 Metrics API 的概念
Metrics API 相比于之前的监控采集方式 (hepaster) 是一种新的思路, 官方希望核心指标的监控应该是稳定的, 版本可控的, 且可以直接被用户访问(例如通过使用 kubectl top 命令), 或由集群中的控制器使用(如 HPA), 和其他的 Kubernetes APIs 一样.
官方废弃 heapster 项目, 就是为了将核心资源监控作为一等公民对待, 即像 pod,service 那样直接通过 API-server 或者 client 直接访问, 不再是安装一个 hepater 来汇聚且由 heapster 单独管理.
假设每个 pod 和 node 我们收集 10 个指标, 从 k8s 的 1.6 开始, 支持 5000 节点, 每个节点 30 个 pod, 假设采集粒度为 1 分钟一次, 则:
10 x 5000 x 30 / 60 = 25000 平均每分钟 2 万多个采集指标
因为 k8s 的 API-server 将所有的数据持久化到了 etcd 中, 显然 k8s 本身不能处理这种频率的采集, 而且这种监控数据变化快且都是临时数据, 因此需要有一个组件单独处理他们, k8s 版本只存放部分在内存中, 于是 metric-server 的概念诞生了.
其实 hepaster 已经有暴露了 API, 但是用户和 Kubernetes 的其他组件必须通过 master proxy 的方式才能访问到, 且 heapster 的接口不像 API-server 一样, 有完整的鉴权以及 client 集成. 这个 API 现在还在 alpha 阶段(18 年 8 月), 希望能到 GA 阶段. 类 API-server 风格的写法: generic apiserver?
有了 Metrics Server 组件, 也采集到了该有的数据, 也暴露了 API, 但因为 API 要统一, 如何将请求到 API-server 的 / apis/metrics 请求转发给 Metrics Server 呢, 解决方案就是: kube-aggregator, 在 k8s 的 1.7 中已经完成, 之前 Metrics Server 一直没有面世, 就是耽误在了 kube-aggregator 这一步.
kube-aggregator(聚合 API)主要提供:
Provide an API for registering API servers.
Summarize discovery information from all the servers.
Proxy client requests to individual servers.
详细设计文档: 参考链接?
metric API 的使用:
Metrics API 只可以查询当前的度量数据, 并不保存历史数据
Metrics API URI 为 /apis/metrics.k8s.io/, 在 k8s.io/metrics 维护
必须部署 metrics-server 才能使用该 API,metrics-server 通过调用 Kubelet Summary API 获取数据
如:
- http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes
- ?
- http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
- ?
- http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>
- Metrics-Server
Metrics server 定时从 Kubelet 的 Summary API(类似 / ap1/v1/nodes/nodename/stats/summary)采集指标信息, 这些聚合过的数据将存储在内存中, 且以 metric-API 的形式暴露出去.
Metrics server 复用了 API-server 的库来实现自己的功能, 比如鉴权, 版本等, 为了实现将数据存放在内存中吗, 去掉了默认的 etcd 存储, 引入了内存存储(即实现 Storage interface). 因为存放在内存中, 因此监控数据是没有持久化的, 可以通过第三方存储来拓展, 这个和 heapster 是一致的.
Metrics server 出现后, 新的? Kubernetes 监控架构将变成上图的样子
核心流程(黑色部分): 这是 Kubernetes 正常工作所需要的核心度量, 从 Kubelet,cAdvisor 等获取度量数据, 再由 metrics-server 提供给 Dashboard,HPA 控制器等使用.
监控流程 (蓝色部分): 基于核心度量构建的监控流程, 比如 Prometheus 可以从 metrics-server 获取核心度量, 从其他数据源(如 Node Exporter 等) 获取非核心度量, 再基于它们构建监控告警系统.
官方地址: https://github.com/kubernetes-incubator/metrics-server
部署
- mkdir metrics;cd metics
- Git clone https://github.com/kubernetes-incubator/metrics-server.git
- cd metrics-server/deploy/1.8+/
修改 metrics-server-deployment.YAML, 红色部分.
- ---
- apiVersion: v1
- kind: ServiceAccount
- metadata:
- name: metrics-server
- namespace: kube-system
- ---
- apiVersion: extensions/v1beta1
- kind: Deployment
- metadata:
- name: metrics-server
- namespace: kube-system
- labels:
- k8s-App: metrics-server
- spec:
- selector:
- matchLabels:
- k8s-App: metrics-server
- template:
- metadata:
- name: metrics-server
- labels:
- k8s-App: metrics-server
- spec:
- serviceAccountName: metrics-server
- volumes:
- # mount in tmp so we can safely use from-scratch images and/or read-only containers
- - name: tmp-dir
- emptyDir: {}
- containers:
- - name: metrics-server
- image: k8s.gcr.io/metrics-server-amd64:v0.3.3
- command:
- - /metrics-server
- - --metric-resolution=30s
- - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
- - --kubelet-insecure-tls
- imagePullPolicy: Always
- volumeMounts:
- - name: tmp-dir
- mountPath: /tmp
创建
- [[email protected] 1.8+]# kubectl apply -f .
- clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader unchanged
- clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator unchanged
- rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader unchanged
- apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io unchanged
- serviceaccount/metrics-server unchanged
- deployment.extensions/metrics-server configured
等待一会就可以看下集群的资源使用情况了!
来源: http://www.bubuko.com/infodetail-3104124.html