一、背景:

1、Kubernetes集群规横大、动态变化快,而目容器化应用部署和服务治理机制的普及,传统的其础设施监控方式已经无法满足Kubernetes集群的监控需求

2、需要使用专门针对Kubernetes集群设计的监控工具来监控集群的状态和服务质量

Prometheus则是目前Kubernetes集群中最常用的监控具之-,它可以过Kubernete AP中的 metrics-Server 获取 kubernetes 集的增标教据,从而现对Kubernetes集群的应用层面监控,以及其于它们的水平自动伸缩对象 HorizontalPodAutoscaler

二、Metrics-server

资源指标管道 Metrics APLL Kubernetes

Metrics Server 是一个专门用来收集 ubernetes 该心资源指标(metrics)的工具,它定时从所有节点的 kubelet 里采集信息,但是对集群的整体性能影响极小,每个节点只大约会占用1m的CPU和2MB 的内存,所以性价比非常高

Metrics Server 工作原理:

          基于Prometheus的HPA自动伸缩_Prometheus

图中从右到左的架构组件包括以下内容:

。cAdvisor:用于收集、服合和公开 Kubelet 中包会的容器指标的守护程序

。kubelet:用于管理容资源的节点代理,可以使用 /metrics/resource 和 /stats kubeletAPI端点访问资源指标

。SummaryAPI: kubelet 提供的API,用于发现和检索可通过 /stats 端点获得的每个节点的汇总统计信息

。metics-server: 集群件组件,用于收集和聚从每个 kubele 中提的资源指,AP1 服务提供 Metrics AP1 以供HPA、VPA和 kubect1 top 命令使用、Metrics Server 是 Metrics API的参考实现

.Metrics API: Kubernetes AP 支持访问用于工作负就自动缩放的 PU 和内存。要在你的集群中进行这项工作,你需要一个提供 Metrics AP 的 API扩展服务

2.1、Metrics-server部署配置

Metrics Server 的项目网址( https://github.com/kuberneles-sigs/metrics-server)

$wget https://github.com/kubernetes-siqs/metrics*server/releases/latest/download/components.yam && MV components.yami
metrics-server .yaml
  • 1.
  • 2.

          基于Prometheus的HPA自动伸缩_Pod_02

vim metrics-server.yaml
kaf metrics-server.yaml
kubectl top node
kubectl top pod
  • 1.
  • 2.
  • 3.
  • 4.

Metrics Server 默认使用 TLS 协议,要验证证书才能与 kubelet 实现安全通信,而我们的内网环境里没有这个必要.默认镜像源非国内,如有下载失败的小伙伴,更改镜像为如下阿里云提供的即可:

registry.aliyuncs.com/google_containers/metrics-server :v0.6.1
  • 1.

部署:

$ kubect1 apply -f metrics-server.yaml
  • 1.

测试验证:

$ kubect1 top node
$ kubect1 top pod -n kube-system
  • 1.
  • 2.
三、HorizontalPodAutoscaler

HorizontalPodAutosaler (HPA是Kubernetes中的一个控制,用于动态河整Pd本的款量,HPA可以根据Metrics server博供的指标(如CPU使用率、内存、使用率等)或内部指标(如每秒的请求数)来自动调整POd的副本数量,以确保应用租序具有足够的资源,并且不会浪费资源,HPA是Kubernetes扩展程序中非常常用的部分,特别是在负载高峰期自动扩展应用程序时。

3.1、使用HorizontalPodAutoscaler

创建一个Nginx应用,定义 Deployment和Service,作为自动伸缩的目标对象

          基于Prometheus的HPA自动伸缩_Pod_03

注意在它的 spec 里一定要用resoures 字段写清楚资源配额,否则 HorintalpodAutoscaler 会无法获取Pod 的指标,也就无法实现自动

接下来我们要用命令 kubect1 autoscale 创理一个HorizontalPodAutoscaler 的样板YAML文件,它有三个参数:

。min,Pod 数量的最小值,也就是缩容的下限

。max,Pod 数量的最大值,也就是扩容的上限

。cpu.percent,CPU 使用率指标,当大于这个值时扩容,小于这个值时缩容

现在我们就来为刚才的 Nginx 应用建 HorizontalPodAutocaler,指定 Pod 数量最少 2个,最多8个,CPU 使用率指标设置的小一点,5%,方便我们观察扩容现象:

$ kubect1 autoscale deploy ngx-hpa-dep --min=2 --max=8 --cpu-percent=5 --dry-run=client -0 yam1 > nginx-demo-hpa.yaml
  • 1.

YAML描述文件:

apiversion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: ngx-hpa
spec:
maxReplicas;8
minReplicas:2
scaleTargetRef:
apiversion: apps/vl
kind: Deployment
name: ngx-hpa-dep
targetCPUutiTizationpercentage:5
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.

通过 kubect] apply创建这个 HorizontalPodAutoscaler后,它会发现 Deployment 里的实例只有1个,不符合 min 定义的下限的要求,就先扩容到2个

          基于Prometheus的HPA自动伸缩_Pod_04

3.2、测试验证

下面我们来给 Nginx加上压力流量,运行一个测试 Pod,使用的境像是httpd:alpine,它里面有 HTTP 能测试工具 ab Apache Bench):

kubect] run test -it --image=httpd:alpine -- sh
  • 1.

然后我们向Nginx发送-百万个请求持续1分钟,再用 kubect1 get hpa 来观察 HorizontalPodAutoscaler 的运行状况:

$ ab "c 10 -t 60 -n 1000000 'http://ngx-hpa-svc/
  • 1.

Metrics Server 大约每15秒采集-次数据,所以HorizontalpodAutoscaler 的自动化扩容和缩容也是按照这个时间点来逐步处理的

当它发现目标的 CPU 便用率超过了预定的 5% 后,就会以2 的倍数开始扩容,一直到数量上限,然后持续监控一段时间;

如果 CPU 使用率回落,就会再缩容到最小值(默认会等待五分钟如果负载没有上去,就会缩小到最低水平,防止抖动),

          基于Prometheus的HPA自动伸缩_Server_05

四、总结

1、Metrics Server 是Kubernetes中的一个组件,它可以将集群中的散布的资源使用情况教据收集并聚合起来,收集的数据包括节点的CPU和内存使用情况

2、通过AP提供给 Kubernetes 中的其它组件如HPA)使用Metrcs Srver 可以帮集管理员和用程开发者更好的了解集群中资源的使用情况,并根规这些数现做出合现的决策,例如调整Pod副本数、扩展集群等。

3、Metrics Server 对于Kubernetes中的资源管现和应用积席扩展非常重要