rancher和k8s接口地址,Kubernetes监控体系,cAdvisor和kube-state-metrics 与 metrics-server

本文主要是介绍rancher和k8s接口地址,Kubernetes监控体系,cAdvisor和kube-state-metrics 与 metrics-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 监控架构将变成下图的样子

  1. 核心流程(黑色部分):这是 Kubernetes 正常工作所需要的核心度量,从 Kubelet、cAdvisor 等获取度量数据,再由 metrics-server 提供给 Dashboard、HPA 控制器等使用。
  2. 监控流程(蓝色部分):基于核心度量构建的监控流程,比如 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 主要用于监测 node,pod 等的 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) 会将请求转发到 adapter,adapter 作为 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:创建高可用的 Prometheus
  • Highly 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-metrics
  • prometheus
  • alertmanager
  • grafana
  • k8s-prometheus-adapter
  • node-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.html
  • https://prometheus.io/
  • https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/
  • https://www.cnblogs.com/chenqionghe/p/10494868.html
  • https://www.qikqiak.com/post/k8s-operator-101/
  • https://kubernetes.io/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
  • https://segmentfault.com/a/1190000017875641
  • https://segmentfault.com/a/1190000038888544
  • https://yasongxu.gitbook.io/
  • https://mp.weixin.qq.com/s/p4FAFKHi8we4mrD7OIk7IQ
  • https://kubernetes.feisky.xyz/apps/index/operator
  • https://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监控架构 - 知乎

 

访问证书申请过程:通过curl访问k8s集群获取证书或token的方式-CSDN博客 

  •  访问具体一个node节点不是通过api-server统一入口访问的

1)TOKEN方式

[root@k8s-node02 ~]# curl https://172.16.10.59:10250/metrics -k -H "Authorization: Bearer $TOKEN"

 2)证书方式

[root@k8s-node02 ~]# curl -k --cert ./client-cert.cert --key ./client-key.key --cacert ./ca.pem  https://172.16.10.59:10250/metrics

  • 通过api-server统一入口访问的

1)证书方式

整体api入口
[root@k8s-node02 ~]# curl -k --cert ./client-cert.cert --key ./client-key.key --cacert ./ca.pem  https://172.16.10.59:6443/指标信息
[root@k8s-node02 ~]# curl -k --cert ./client-cert.cert --key ./client-key.key --cacert ./ca.pem  https://172.16.10.59:6443/api/v1/nodes/172.16.10.59/proxy/metrics
和指定节点
[root@k8s-node02 ~]# curl https://172.16.10.59:10250/metrics -k -H "Authorization: Bearer $TOKEN"效果一样的信息,只不过一个是统一入口一个是固定一个节点执行。不管哪种方式都需要证书或token

2)TOKEN方式 

[root@k8s-node02 ~]# curl -k -H "Authorization: Bearer $TOKEN" https://172.16.10.59:6443/api/v1/nodes/172.16.10.59/proxy/metrics

这篇关于rancher和k8s接口地址,Kubernetes监控体系,cAdvisor和kube-state-metrics 与 metrics-server的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/636533

相关文章

python使用watchdog实现文件资源监控

《python使用watchdog实现文件资源监控》watchdog支持跨平台文件资源监控,可以检测指定文件夹下文件及文件夹变动,下面我们来看看Python如何使用watchdog实现文件资源监控吧... python文件监控库watchdogs简介随着Python在各种应用领域中的广泛使用,其生态环境也

SQL Server数据库磁盘满了的解决办法

《SQLServer数据库磁盘满了的解决办法》系统再正常运行,我还在操作中,突然发现接口报错,后续所有接口都报错了,一查日志发现说是数据库磁盘满了,所以本文记录了SQLServer数据库磁盘满了的解... 目录问题解决方法删除数据库日志设置数据库日志大小问题今http://www.chinasem.cn天发

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因?

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台,是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力,在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术,能够处理多种视频流格式,并以多种格式(RTMP、RTSP、HTTP-FLV、WebS

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动,这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升:减少抖动,提高图像的清晰度和细节表现力,使得监控画面更加真实可信。 - 细节增强:在低光条件下,抖

常用的jdk下载地址

jdk下载地址 安装方式可以看之前的博客: mac安装jdk oracle 版本:https://www.oracle.com/java/technologies/downloads/ Eclipse Temurin版本:https://adoptium.net/zh-CN/temurin/releases/ 阿里版本: github:https://github.com/

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注,收藏不迷路💖 Kubernetes的PodSecurityPolicy(PSP)是一个关键的安全特性,它在Pod创建之前实施安全策略,确保P

90、k8s之secret+configMap

一、secret配置管理 配置管理: 加密配置:保存密码,token,其他敏感信息的k8s资源 应用配置:我们需要定制化的给应用进行配置,我们需要把定制好的配置文件同步到pod当中容器 1.1、加密配置: secret: [root@master01 ~]# kubectl get secrets ##查看加密配置[root@master01 ~]# kubectl get se

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP

什么是Kubernetes PodSecurityPolicy?

@TOC 💖The Begin💖点点关注,收藏不迷路💖 1、什么是PodSecurityPolicy? PodSecurityPolicy(PSP)是Kubernetes中的一个安全特性,用于在Pod创建前进行安全策略检查,限制Pod的资源使用、运行权限等,提升集群安全性。 2、为什么需要它? 默认情况下,Kubernetes允许用户自由创建Pod,可能带来安全风险。

webapp地址

F:\LSP\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps