Prometheus基于k8s的动态服务发现实战

Promethues通过K8s的apiservice目前可以支持5种服务发现模式，分别是：Node、Service、Pod、Endpoints、Ingress。我们可以通过对配置文件prometheusyml添加以下内容实现k8s中信息的获取。

在连接k8s之后，有些指标会自动生成一些标签，有时候我们可能会需要重命名这些标签，可能会丢弃一部分无用的标签，还可能会通过这些标签过滤出我们需要监控的资源，因此在job_name子属性中，还有一个叫做relabel_configs的配置，这个配置可以使我们通过一些正则表达式，来满足我们对标签的各种自定义。

relabel_configs的常用配置：

我们以POD资源为例，看下有哪些自动生成source_labels（更多资源请参考官网： >容器编排就是有关管理容器生命周期的全部工作，特别是在大型动态环境中。 软件团队使用容器编排来控制和自动化许多任务：

•运行中的Kubernetes集群包含节点代理（kubelet）和集群控制平面（AKA主节点），集群状态由分布式存储系统（etcd）支持

除了核心组件，还有一些推荐的插件，其中有的已经成为CNCF中的托管项目：

Controller Manager 用于实现 Kubernetes 集群故障检测和恢复的自动化工作。Controller Manager 主要负责执行以下各种控制器：

Kubelet 「节点上的 Pod 管家」

Proxy「负载均衡、路由转发」

Kubectl 「集群管理命令行工具集」

客户端访问 ——> service1 ——> Pod1 ——> service2 ——>Pod2

所有的Pod之前的访问都是由其service来代理的，当Pod间知道相应的Pod的IP后，就会直接进行通信，可以理解为DNS的作用。

• Pod - 一组容器

• 标签 - 用于识别Pods的标签

• Kubelet - 容器代理

• kube-proxy - Pod的负载平衡器

• etcd - 元数据服务

• cAdvisor - 容器顾问提供者资源使用/性能统计

• Replication Controller - 管理Pod的复制

• Scheduler- 调度工作节点中的Pod

• API Server - Kubernetes API服务器

管理Pod | 复制集

处理复制和推出 | 部署

提供自我修复功能 | 守护程序集

使用个Pod模板制作真实的Pods | 工作

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

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

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

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

Metrics Server 实现了Metrics API。

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

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

通过在主 API server 中注册的 Metrics Server Kubernetes 聚合器 来采集指标信息， 这是在 Kubernetes 17 中引入的。在 设计文档 中可以了解到有关 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聚集（的获取度量 metricsk8sio ， custommetricsk8sio 和 externalmetricsk8sio ）。该 metricsk8sio API通常是通过Metrics Server，其需要单独启动提供。有关说明，请参阅 metrics-server 。Horizo​​ntalPodAutoscaler还可以直接从Heapster（ 从Kubernetes 111开始，不推荐从Heapster获取指标。 ）获取指标。
安装官方文档 metrics server yaml
创建 metrics-server pod
生成 metricsk8sio/v1beta1
安装 custom metrics apiserver 提供的 metrics 来扩展 Kubernetes 自定义指标 API
CoreDns 作为Kubernetes 111版本之后的默认dns插件之后，本身9153端口提供 /metrics 接口

这次我就利用 coredns_dns_request_count_total{server, zone, proto, family} Prometheus adapter（即 custom-metrics-apiserver）删除了 _total 后缀并将该指标标记为 coredns_dns_request_count

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

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

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

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

>