实战：HPA(Pod 水平自动伸缩)-2021.11.23

目录
@[toc]
实验环境
实验软件
1、基础知识
- 1.HPA 控制器
- 2.Metrics Server
- - a.聚合 API
- 3.什么是`vpa`
2、实战演示
- :cupid:**实战演示1**：安装`metrics-server`
- - 安装前须知
  - :round_pushpin:step1：下载仓库官方metrics server安装的资源清单
  - :round_pushpin:step2：修改 `components.yaml` 的镜像地址
  - :round_pushpin:step3：部署并查看pod日志
  - :round_pushpin:step4：添加一个`--kubelet-insecure-tls`参数跳过证书校验
  - :round_pushpin:step5：再次部署并查看
  - :round_pushpin:step6：验证效果
- :cupid:实战演示2：测试HPA(默认是CPU的hpa)
- - :round_pushpin:step1：创建一个Nginx pod资源清单文件
  - :round_pushpin:step2：部署并查看
  - :round_pushpin:step3：创建一个 `HPA` 资源对象
  - :round_pushpin:step4：发现一些fail信息并排查
  - :round_pushpin:step5：资源清单文件里添加requests资源重新部署并查看
  - :round_pushpin:step6：我们来创建一个pod模拟增大负载进行测试
  - :round_pushpin:step7：我们来关掉 busybox 来减少负载
- :cupid:实战演示3：测试HPA（内存的hpa）
- - :round_pushpin:step1：创建资源清单文件
  - :round_pushpin:step2：直接部署
  - :round_pushpin: step3：创建一个基于内存的 HPA 资源对象
  - :round_pushpin: step4：直接创建上面的资源对象即可
  - :round_pushpin: step5：进行压测
3、注意事项
- 1.cpu压测方法
- 2.内存压测方法
- 3.ConfigMap的写法
关于我
最后

![image-20211123103644534](https://bucket-hg.oss-cn-shanghai.aliyuncs.com/img/image-20211123103644534.png)

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点k8s version：v1.22.2containerd://1.5.5

实验软件

链接：https://pan.baidu.com/s/1I2oQvi2GC1g5J0vxOBooqg
提取码：59mi
–来自百度网盘超级会员V6的分享

1、基础知识

1.HPA 控制器

在前面的学习中我们使用了一个 kubectl scale 命令可以来实现 Pod 的扩缩容功能，但是这个是完全手动操作的，要应对线上的各种复杂情况，**我们需要能够做到自动化去感知业务，来自动进行扩缩容。**为此，Kubernetes 也为我们提供了这样的一个资源对象：Horizontal Pod Autoscaling（Pod 水平自动伸缩），简称 HPA，HPA 通过监控分析一些控制器控制的所有 Pod 的负载变化情况来确定是否需要调整 Pod 的副本数量，这是 HPA 最基本的原理：

我们可以简单的通过 kubectl autoscale 命令来创建一个 HPA 资源对象，HPA Controller 默认30s轮询一次（可通过 kube-controller-manager 的--horizontal-pod-autoscaler-sync-period 参数进行设置），查询指定的资源中的 Pod 资源使用率，并且与创建时设定的值和指标做对比，从而实现自动伸缩的功能。

2.Metrics Server

在 HPA 的第一个版本中，我们需要 Heapster(目前这个已经废弃了) 提供 CPU 和内存指标，在 HPA v2 过后就需要安装 Metrcis Server 了，Metrics Server 可以通过标准的 Kubernetes API 把监控数据暴露出来，有了 Metrics Server 之后，我们就完全可以通过标准的 Kubernetes API 来访问我们想要获取的监控数据了：

https://10.96.0.1/apis/metrics.k8s.io/v1beta1/namespaces/<namespace-name>/pods/<pod-name>

比如当我们访问上面的 API 的时候，我们就可以获取到该 Pod 的资源数据，**这些数据其实是来自于 kubelet 的 Summary API 采集而来的。**不过需要说明的是我们这里可以通过标准的 API 来获取资源监控数据，并不是因为 Metrics Server 就是 APIServer 的一部分，而是通过 Kubernetes 提供的 Aggregator(聚合器) 汇聚插件来实现的，是独立于 APIServer 之外运行的。

a.聚合 API

Aggregator 允许开发人员编写一个自己的服务，把这个服务注册到 Kubernetes 的 APIServer 里面去，这样我们就可以像原生的 APIServer 提供的 API 使用自己的 API 了，我们把自己的服务运行在 Kubernetes 集群里面，然后 Kubernetes 的 Aggregator 通过 Service 名称就可以转发到我们自己写的 Service 里面去了。这样这个聚合层就带来了很多好处：

增加了 API 的扩展性：开发人员可以编写自己的 API 服务来暴露他们想要的 API。
丰富了 API：核心 kubernetes 团队阻止了很多新的 API 提案，通过允许开发人员将他们的 API 作为单独的服务公开，这样就无须社区繁杂的审查了。
开发分阶段实验性 API：新的 API 可以在单独的聚合服务中开发，当它稳定之后，在合并会 APIServer 就很容易了。
确保新 API 遵循 Kubernetes 约定：如果没有这里提出的机制，社区成员可能会被迫推出自己的东西，这样很可能造成社区成员和社区约定不一致。

3.什么是`vpa`

hpa：水平自动扩缩容

vpa：垂直自动扩缩容，我始终在一个pod里面，假设我的memory limits是100Mi，但是现在已经用到了98Mi，如果再大的话就oom了，此时vpa会在垂直方向上提升你的memory limits的大小。这种vpa比较适合一些资源消耗比较大的应用，例如es，你给大了资源浪费，给小了，又不够。所以vpa就派上用场了。当然，vpa不像hpa默认集成在k8s里面的，需要你自己去配置的。

另外：vpa会涉及一些CRD的operator里的一些知识。

[root@master1 ~]#vim hpa-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: hpa-demo
spec:selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxports:- containerPort: 80resources:requests:memory: 50Micpu: 50mlimits:memory: 100Micpu: 100m

2、实战演示