基于Custom Metrics API的CoreDns水平扩展

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于Custom Metrics API的CoreDns水平扩展相关的知识,希望对你有一定的参考价值。

参考技术A 从Kubernetes 1.8开始,Kubernetes通过Metrics API提供资源使用指标,例如容器CPU和内存使用。这些度量可以由用户直接访问,例如通过使用kubectl top命令,或者由群集中的控制器(例如Horizo​​ntal Pod Autoscaler)使用来进行决策。

通过Metrics API,您可以获得给定节点或给定pod当前使用的资源量。此API不存储Metrics Value,因此例如在10分钟前获取给定节点使用的资源量是不可能的。

API与任何其他API没有区别:

API在 k8s.io/metrics 存储库中定义。您可以在那里找到有关API的更多信息。

Metrics Server 实现了Metrics API。

Metrics Server 是集群范围资源使用数据的聚合器。 从 Kubernetes 1.8 开始,它作为一个 Deployment 对象默认部署在由 kube-up.sh 脚本创建的集群中。 如果你使用了其他的 Kubernetes 安装方法,您可以使用 Kubernetes 1.7+ (请参阅下面的详细信息) 中引入的 deployment yamls 文件来部署。

Metrics Server 从每个节点上的 Kubelet 公开的 Summary API 中采集指标信息。

通过在主 API server 中注册的 Metrics Server Kubernetes 聚合器 来采集指标信息, 这是在 Kubernetes 1.7 中引入的。在 设计文档 中可以了解到有关 Metrics Server 的更多信息。

custom-metrics-apiserver 该 API 允许消费者访问通过任意指标描述的 Kubernetes 资源。如果你想实现这个 API Service,这是一个用来实现 Kubernetes 自定义指标的框架。

Horizo​​ntal Pod Autoscaler根据观察到的CPU利用率(或者,通过 Custom Metrics API 支持,根据其他一些应用程序提供的指标)自动调整复制控制器,部署或副本集中的pod数 。请注意,Horizo​​ntal Pod Autoscaling不适用于无法缩放的对象,例如DaemonSet。

Horizo​​ntal Pod Autoscaler实现为Kubernetes API资源和控制器。资源确定控制器的行为。控制器会定期调整复制控制器或部署中的副本数,以使观察到的平均CPU利用率与用户指定的目标相匹配。

Horizo​​ntal Pod Autoscaler实现为循环监测,其周期由控制器管理器的 --horizontal-pod-autoscaler-sync-period 标志控制(默认值为15秒)。

在每个期间,控制器管理器根据每个Horizo​​ntalPodAutoscaler定义中指定的度量查询资源利用率。控制器管理器从资源指标API(针对每个窗格资源指标)或自定义指标API(针对所有其他指标)获取指标。

请注意,如果某些pod的容器没有设置相关的资源请求,则不会定义pod的CPU利用率,并且autoscaler不会对该度量标准采取任何操作。有关自动调节算法如何工作的更多信息,请参阅下面的 算法详细信息 部分。

所述Horizo​​ntalPodAutoscaler通常由一系列的API聚集(的获取度量 metrics.k8s.io , custom.metrics.k8s.io 和 external.metrics.k8s.io )。该 metrics.k8s.io API通常是通过Metrics Server,其需要单独启动提供。有关说明,请参阅 metrics-server 。Horizo​​ntalPodAutoscaler还可以直接从Heapster( 从Kubernetes 1.11开始,不推荐从Heapster获取指标。 )获取指标。

安装官方文档 metrics server yaml
创建 metrics-server pod

生成 metrics.k8s.io/v1beta1

安装 custom metrics apiserver 提供的 metrics 来扩展 Kubernetes 自定义指标 API

CoreDns 作为Kubernetes 1.11版本之后的默认dns插件之后,本身9153端口提供 /metrics 接口

这次我就利用 coredns_dns_request_count_totalserver, zone, proto, family Prometheus adapter(即 custom-metrics-apiserver)删除了 _total 后缀并将该指标标记为 coredns_dns_request_count

从Custom Metrics API 获取每秒的总查询次数:

m 表示 毫 ,例如, 911m 表示 911 毫次/每秒

创建一个 HPA,如果请求数超过每秒 1000 次将扩大 coredns 副本数:

不是所有的应用都可以适用依靠 CPU 和Memory指标做弹性伸缩来满足系统的负载,大多数 Web 应用的后端都需要基于每秒的请求数量 QPS 进行弹性伸缩来处理突发流量。而一些 ETL 应用程序,可以通过设置 Job 队列长度超过某个阈值来触发弹性伸缩工作pod。
通过 Prometheus 来监控应用程序并暴露出用于弹性伸缩的指标 /metric ,可以微调应用程序以更好地处理突发事件,从而确保其高可用性。

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
https://github.com/coredns/coredns/tree/master/plugin/metrics
https://github.com/kubernetes-incubator/metrics-server
https://github.com/DirectXMan12/k8s-prometheus-adapter
https://github.com/coreos/prometheus-operator

ebpf_exporter - Prometheus exporter for custom eBPF metrics

Prometheus exporter for custom eBPF metrics. Motivation of this exporter is to allow you to write eBPF code and export metrics that are not otherwise accessible from the Linux kernel.

https://github.com/cloudflare/ebpf_exporter

以上是关于基于Custom Metrics API的CoreDns水平扩展的主要内容,如果未能解决你的问题,请参考以下文章

ebpf_exporter - Prometheus exporter for custom eBPF metrics

基于metric server的自动伸缩hpa

Spring Boot ClassNotFoundException org.springframework.core.metrics.ApplicationStartup

解决 java.lang.NoClassDefFoundError: org/springframework/core/metrics/ApplicationStartup

.Net Core 2.*+ InfluxDB+Grafana+App Metrics实时性能监控

metrics-core-2.2.0.jar的maven依赖怎么写