做网站做网站,洛阳有建社网站的吗,宣武郑州阳网站建设,网站开发及建设赔偿条款为了能够提前发现kubernetes集群的问题以及方便快捷的查询容器的各类参数#xff0c;比如#xff0c;某个pod的内存使用异常高企 等等这样的异常状态#xff08;虽然kubernetes有自动重启或者驱逐等等保护措施#xff0c;但万一没有配置或者失效了呢#xff09;#xff0…为了能够提前发现kubernetes集群的问题以及方便快捷的查询容器的各类参数比如某个pod的内存使用异常高企 等等这样的异常状态虽然kubernetes有自动重启或者驱逐等等保护措施但万一没有配置或者失效了呢容器的内存使用量限制过去10秒容器CPU的平均负载等等容器的运行参数这些情况我们自然还是将kubernetes集群纳入到监控系统中好些毕竟能够发现问题和解决问题更加的优雅嘛。
因此我们需要能够有一个比较全面的监测容器运行的实时的监控系统版本答案当然就是Prometheus了。Prometheus监控系统可以多维度的方便的将我们需要的信息收集起来然后通过Grafana做一个华丽的展示。
那么对于容器这个对象来说我们要使用的收集器就是cAdvisor啦但cAdvisor这个收集器和node_exportermysqld_exporter 这些收集器不太一样它是集成在kubelet这个服务内的因此我们不需要额外的安装cAdvisor收集器也就是说不需要像node_exporter这样的系统信息收集器一样单独部署了只要kubernetes的节点上有运行kubelet这个服务就可以了。
下面就kubernetes集群的Prometheus专用于容器的实时信息收集器cAdvisor如何认识它如何部署它并集成到Prometheus内做一个详细的介绍。 一 cAdvisor的简介 cAdvisor是一个谷歌开发的容器监控工具它被内嵌到k8s中作为k8s的监控组件。cAdvisor对Node机器上的资源及容器进行实时监控和性能数据采集包括CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况由于cAdvisor是集成在Kubelet中的因此当kubelet启动时会自动启动cAdvisor即一个cAdvisor仅对一台Node机器进行监控。 当然也可以单独安装 cAdvisor 来监控只有docekr容器的机器而没有k8s集群环境的监控
二其它的用于收集容器信息的信息收集器 heapster和Metrics server以及kube-state-metrics都可用于提供容器信息但它们所提供的信息维度是不同的heapster已经被Metrics server所取代 了如果没记错的话应该是从k8s的1.16版本后放弃了heapster。
Metrics server作为新的容器信息收集器是从 api-server 中获取容器的 cpu、内存使用率这种监控指标并把他们发送给存储后端可以算作一个完整的监控系统。cAdvisor是专有的容器信息收集是一个专有工具的地位而kube-state-metrics是偏向于kubernetes集群内的资源对象例如deploymentStateFulSetdaemonset等等资源可以算作一个特定的数据源
三cAdvisor的初步使用
kubelet是kubernetes集群中真正维护容器状态负责主要的业务的一个关键组件。每个节点上都运行一个 kubelet 服务进程默认监听 10250 端口接收并执行 master 发来的指令管理 Pod 及 Pod 中的容器。kubernetes的节点IP10250端口就是kubelet的API。
几个重要的端口
A
10250kubelet APIkubelet server 与 apiserver 通信的端口定期请求 apiserver 获取自己所应当处理的任务通过该端口可以访问获取 node 资源以及状态。kubectl查看pod的日志和cmd命令都是通过kubelet端口10250访问。
10248端口是什么呢是kubelet的健康检查端口可以通过 kubelet 的启动参数 –healthz-port 和 –healthz-bind-address 来指定监听的地址和端口。
需要注意的是Kubernetes 1.11 版本以后kubelet 就移除了 10255 端口 metrics 接口又回到了 10250 端口中。
版本的kubernetes还有一个4194端口此端口是cAdvisor的web管理界面的端口可能是出于安全漏洞的考虑后续版本移除了此端口因此此端口在我这个版本内并没有开启。 BAPI的使用 既然都说了节点IP10250是kubelet的API了那么我们肯定可以从这个API里获取到一些信息了这些信息其实就是cAdvisor收集到的如何使用这个API呢这个API可是需要使用证书的https哦。因此计划建立一个sa通过sa的token来登陆这个API 1利用ServiceAccount访问API
利用ServiceAccount访问API
找一个具有cluster-admin权限的ServiceAccount其实每个集群内都很容易找到这样的sa但为了说明问题还是新建一个任意的具有最高权限的sa吧实际的生产中可不要这么搞哦。
新建一个sa
kubectl create ns monitor-sa #创建一个monitor-sa的名称空间
kubectl create serviceaccount monitor -n monitor-sa #创建一个sa账号
kubectl create clusterrolebinding monitor-clusterrolebinding -n monitor-sa --clusterrolecluster-admin --serviceaccountmonitor-sa:monitor查看secret
[rootnode3 ~]# k get secrets -n monitor-sa
NAME TYPE DATA AGE
default-token-fw7pq kubernetes.io/service-account-token 3 81s
monitor-token-tf48k kubernetes.io/service-account-token 3 81s获取登录用的token
[rootnode3 ~]# k describe secrets -n monitor-sa monitor-token-tf48k
使用10250这个API
将token保存到变量TOKEN里面然后下面的API调试接口命令里面引用
[rootnode3 ~]# TOKEN“”curl https://127.0.0.1:10250/metrics/cadvisor -k -H Authorization: Bearer $TOKENOK输出茫茫多稍微截一点吧剩下的就不贴了具体的含义后面在说吧
[rootnode3 ~]# curl https://127.0.0.1:10250/metrics/cadvisor -k -H Authorization: Bearer $TOKEN |less
将上面的命令改造一下使用kube-apiserver 的服务来访问kube-apiserver 的API接口
curl https://10.96.0.1/api/v1/nodes/node3/proxy/metrics -k -H Authorization: Bearer $TOKEN
[rootnode3 ~]# curl https://10.96.0.1/api/v1/nodes/node3/proxy/metrics -k -H Authorization: Bearer $TOKEN |less
OK以上是通过一个具有admin权限的serviceAccount账户直接连接cadvisor和kube-apiserver的API动态获得节点的podendpoint等等资源的各个维度的数据。
现在需要将这些集成到Prometheus server里了。 Kubernetes监控体系总结_kube-state-metrics 代替了cadvisor吗-CSDN博客
Docker 是一个开源的应用容器引擎让开发者可以打包他们的应用以及依赖包到一个可移植的容器中然后发布到任何流行的 Linux/Windows/Mac 机器上。容器镜像正成为一个新的标准化软件交付方式。为了能够获取到 Docker 容器的运行状态用户可以通过 Docker 的 stats 命令获取到当前主机上运行容器的统计信息可以查看容器的 CPU 利用率、内存使用量、网络 IO 总量以及磁盘 IO 总量等信息。
显然如果我们想对监控数据做存储以及可视化的展示那么 docker 的 stats 是不能满足的。
为了解决 docker stats 的问题存储、展示谷歌开源的 cadvisor 诞生了cadvisor 不仅可以搜集一台机器上所有运行的容器信息还提供基础查询界面和 http 接口方便其他组件如 Prometheus 进行数据抓取或者 cAdvisor influxDB grafana 搭配使用。cAdvisor 可以对节点机器上的资源及容器进行实时监控和性能数据采集包括 CPU 使用情况、内存使用情况、网络吞吐量及文件系统使用情况
监控原理
cAdvisor 使用 Go 语言开发利用 Linux 的 cgroups 获取容器的资源使用信息在 K8S 中集成在 Kubelet 里作为默认启动项官方标配。
Docker 是基于 Namespace、Cgroups 和联合文件系统实现的
Cgroups 不仅可以用于容器资源的限制还可以提供容器的资源使用率。不管用什么监控方案底层数据都来源于 Cgroups
Cgroups 的工作目录 /sys/fs/cgroup 下包含了 Cgroups 的所有内容。Cgroups 包含了很多子系统可以对 CPU内存PID磁盘 IO 等资源进行限制和监控。
Heapster Heapster 是容器集群监控和性能分析工具天然的支持 Kubernetes 和 CoreOS。
Heapster 首先从 K8S Master 获取集群中所有 Node 的信息然后通过这些 Node 上的 kubelet 获取有用数据而 kubelet 本身的数据则是从 cAdvisor 得到。所有获取到的数据都被推到 Heapster 配置的后端存储中并还支持数据的可视化。现在后端存储 可视化的方法如 InfluxDB grafana。
Heapster 可以收集 Node 节点上的 cAdvisor 数据还可以按照 kubernetes 的资源类型来集合资源比如 Pod、Namespace 域可以分别获取它们的 CPU、内存、网络和磁盘的 metric。默认的 metric 数据聚合时间间隔是 1 分钟。
注意 Kubernetes 1.11 不建议使用 Heapster就 SIG Instrumentation 而言这是为了转向新的 Kubernetes 监控模型的持续努力的一部分。仍使用 Heapster 进行自动扩展的集群应迁移到 metrics-server 和自定义指标 API。
kubernetes 集群资源监控之前可以通过 heapster 来获取数据在 1.11 开始开始逐渐废弃 heapster 了采用 metrics-server 来代替metrics-server 是集群的核心监控数据的聚合器它从 kubelet 公开的 Summary API 中采集指标信息metrics-server 是扩展的 APIServer依赖于 kube-aggregator因为我们需要在 APIServer 中开启相关参数。
Metrics Server 并不是 kube-apiserver 的一部分而是通过 Aggregator 这种插件机制在独立部署的情况下同 kube-apiserver 一起统一对外服务的。
Aggregator 通过聚合层扩展 Kubernetes API使用聚合层Aggregation Layer用户可以通过额外的 API 扩展 Kubernetes 而不局限于 Kubernetes 核心 API 提供的功能。这里的附加 API 可以是现成的解决方案比如 metrics server, 或者你自己开发的 API。聚合层不同于 定制资源Custom Resources。后者的目的是让 kube-apiserver 能够认识新的对象类别Kind。 聚合层聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前聚合层不做任何事情。要注册 API用户必须添加一个 APIService 对象用它来“申领” Kubernetes API 中的 URL 路径。自此以后聚合层将会把发给该 API 路径的所有内容例如 /apis/myextension.mycompany.io/v1/… 转发到已注册的 APIService。 APIService 的最常见实现方式是在集群中某 Pod 内运行 扩展 API 服务器。如果你在使用扩展 API 服务器来管理集群中的资源该扩展 API 服务器也被写成“extension-apiserver” 一般需要和一个或多个控制器一起使用。apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代码。 这里Aggregator APIServer 的工作原理可以用如下所示的一幅示意图来表示清楚 因为 k8s 的 api-server 将所有的数据持久化到了 etcd 中显然 k8s 本身不能处理这种频率的采集而且这种监控数据变化快且都是临时数据因此需要有一个组件单独处理他们于是 metric-server 的概念诞生了。
Metrics server 出现后新的 Kubernetes 监控架构将变成下图的样子
核心流程黑色部分这是 Kubernetes 正常工作所需要的核心度量从 Kubelet、cAdvisor 等获取度量数据再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。监控流程蓝色部分基于核心度量构建的监控流程比如 Prometheus 可以从 metrics-server 获取核心度量从其他数据源如 Node Exporter 等获取非核心度量再基于它们构建监控告警系统。 注意 metrics-sevrer 的数据存在内存中。 metrics-server 主要针对 node、pod 等的 cpu、网络、内存等系统指标的监控 kube-state-metrics 已经有了 cadvisor、heapster、metric-server几乎容器运行的所有指标都能拿到但是下面这种情况却无能为力
我调度了多少个 replicas现在可用的有几个多少个 Pod 是 running/stopped/terminated 状态Pod 重启了多少次我有多少 job 在运行中
而这些则是 kube-state-metrics 提供的内容它基于 client-go 开发轮询 Kubernetes API并将 Kubernetes 的结构化信息转换为 metrics。
kube-state-metrics 与 metrics-server 对比
我们服务在运行过程中我们想了解服务运行状态pod 有没有重启伸缩有没有成功pod 的状态是怎么样的等这时就需要 kube-state-metrics它主要关注 deployment,、node 、 pod 等内部对象的状态。而 metrics-server 主要用于监测 nodepod 等的 CPU内存网络等系统指标。
metric-server或 heapster是从 api-server 中获取 cpu、内存使用率这种监控指标并把他们发送给存储后端如 influxdb 或云厂商他当前的核心作用是为 HPA 等组件提供决策指标支持。kube-state-metrics 关注于获取 k8s 各种资源的最新状态如 deployment 或者 daemonset之所以没有把 kube-state-metrics 纳入到 metric-server 的能力中是因为他们的关注点本质上是不一样的。metric-server 仅仅是获取、格式化现有数据写入特定的存储实质上是一个监控系统。而 kube-state-metrics 是将 k8s 的运行状况在内存中做了个快照并且获取新的指标但他没有能力导出这些指标换个角度讲kube-state-metrics 本身是 metric-server 的一种数据来源虽然现在没有这么做。另外像 Prometheus 这种监控系统并不会去用 metric-server 中的数据他都是自己做指标收集、集成的Prometheus 包含了 metric-server 的能力但 Prometheus 可以监控 metric-server 本身组件的监控状态并适时报警这里的监控就可以通过 kube-state-metrics 来实现如 metric-serverpod 的运行状态。 custom-metrics-apiserver kubernetes 的监控指标分为两种
Core metrics核心指标从 Kubelet、cAdvisor 等获取度量数据再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。Custom Metrics自定义指标由 Prometheus Adapter 提供 API custom.metrics.k8s.io由此可支持任意 Prometheus 采集到的指标。
以下是官方 metrics 的项目介绍
Resource Metrics API核心 api Heapster Metrics Server
Custom Metrics API Prometheus Adapter Microsoft Azure Adapter Google Stackdriver Datadog Cluster Agent
核心指标只包含 node 和 pod 的 cpu、内存等一般来说核心指标作 HPA 已经足够但如果想根据自定义指标如请求 qps/5xx 错误数来实现 HPA就需要使用自定义指标了目前 Kubernetes 中自定义指标一般由 Prometheus 来提供再利用 k8s-prometheus-adpater 聚合到 apiserver实现和核心指标metric-server) 同样的效果。
HPA 请求 metrics 时kube-aggregator(apiservice 的 controller) 会将请求转发到 adapteradapter 作为 kubernentes 集群的 pod实现了 Kubernetes resource metrics API 和 custom metrics API它会根据配置的 rules 从 Prometheus 抓取并处理 metrics在处理如重命名 metrics 等完后将 metric 通过 custom metrics API 返回给 HPA。最后 HPA 通过获取的 metrics 的 value 对 Deployment/ReplicaSet 进行扩缩容。
adapter 作为 extension-apiserver即自己实现的 pod)充当了代理 kube-apiserver 请求 Prometheus 的功能。
adapter 作为 extension-apiserver即自己实现的 pod)充当了代理 kube-apiserver 请求 Prometheus 的功能 其实 k8s-prometheus-adapter 既包含自定义指标又包含核心指标即如果安装了 prometheus且指标都采集完整k8s-prometheus-adapter 可以替代 metrics server。
Prometheus 部署方案 prometheus operator
https://github.com/prometheus-operator/prometheus-operator
kube-prometheus
https://github.com/prometheus-operator/kube-prometheus
在集群外部署
https://www.qikqiak.com/post/monitor-external-k8s-on-prometheus/
kube-prometheus 既包含了 Operator又包含了 Prometheus 相关组件的部署及常用的 Prometheus 自定义监控具体包含下面的组件
The Prometheus Operator创建 CRD 自定义的资源对象Highly available Prometheus创建高可用的 PrometheusHighly available Alertmanager创建高可用的告警组件Prometheus node-exporter创建主机的监控组件Prometheus Adapter for Kubernetes Metrics APIs创建自定义监控的指标工具例如可以通过 nginx 的 request 来进行应用的自动伸缩kube-state-metrics监控 k8s 相关资源对象的状态指标Grafana进行图像展示
我们的做法 我们的做法其实跟 kube-prometheus 的思路差不多只不过我们没有用 Operator 是自己将以下这些组件的 yaml 文件用 helm 组织了起来而已
kube-state-metricsprometheusalertmanagergrafanak8s-prometheus-adapternode-exporter
当然 kube-prometheus 也有 helm charts 由 prometheus 社区提供https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack
这么干的原因是这样的灵活度是最高的虽然在第一次初始化创建这些脚本的时候麻烦了些。不过还有一个原因是我们当时部署整个基于 prometheus 的监控体系时kube-prometheus 这个项目还在早期没有引起我们的关注。如果在 2021 年年初或 2020 年年底的时候创建的话可能就会直接上了。
参考
https://blog.opskumu.com/cadvisor.htmlhttps://prometheus.io/https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/https://www.cnblogs.com/chenqionghe/p/10494868.htmlhttps://www.qikqiak.com/post/k8s-operator-101/https://kubernetes.io/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/https://segmentfault.com/a/1190000017875641https://segmentfault.com/a/1190000038888544https://yasongxu.gitbook.io/https://mp.weixin.qq.com/s/p4FAFKHi8we4mrD7OIk7IQhttps://kubernetes.feisky.xyz/apps/index/operatorhttps://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/operator/what-is-prometheus-operator
1.k8s原生api地址 k8s的REST 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 2.rancher看k8s接口地址
2.1看集群的api 2.2通过集群api查看id 2.3通过rancher看k8s的api地址 rancher的REST API: 总接口https://rancher.jettech.cn/k8s/clusters/c-wpz72/ node:https://rancher.jettech.cn/k8s/clusters/c-wpz72/apis/metrics.k8s.io/v1beta1/nodes pod:https://rancher.jettech.cn/k8s/clusters/c-wpz72/apis/metrics.k8s.io/v1beta1/pods 细说k8s监控架构 - 知乎
