1、传统弹性伸缩的困境
从传统意义上，弹性伸缩主要解决的问题是容量规划与实际负载的⽭盾
蓝⾊⽔位线表示集群资源容量随着负载的增加不断扩容，红⾊曲线表示集群资源实际负载变化。 弹性伸缩就是要解决当实际负载增⼤，⽽集群资源容量没来得及反应的问题。
1.1、Kubernetes中弹性伸缩存在的问题
常规的做法是给集群资源预留保障集群可⽤，通常20%左右。这种⽅式看似没什么问题，但放到 Kubernetes中，就会发现如下2个问题。
1.1.1. 机器规格不统⼀造成机器利⽤率百分⽐碎⽚化
在⼀个Kubernetes集群中，通常不只包含⼀种规格的机器，假设集群中存在4C8G与16C32G两种 规格的机器，对于10%的资源预留，这两种规格代表的意义是完全不同的。
特别是在缩容的场景下，为了保证缩容后集群稳定性，我们⼀般会⼀个节点⼀个节点从集群中摘除，那 么如何判断节点是否可以摘除其利⽤率百分⽐就是重要的指标。此时如果⼤规格机器有较低的利⽤率被 判断缩容，那么很有可能会造成节点缩容后，容器重新调度后的争抢。如果优先缩容⼩规格机器，则可 能造成缩容后资源的⼤量冗余。
1.1.2. 机器利⽤率不单纯依靠宿主机计算
在⼤部分⽣产环境中，资源利⽤率都不会保持⼀个⾼的⽔位，但从调度来讲，调度应该保持⼀个⽐ 较⾼的⽔位，这样才能保障集群稳定性，⼜不过多浪费资源。
1.2、弹性伸缩概念的延伸
不是所有的业务都存在峰值流量，越来越细分的业务形态带来更多成本节省和可⽤性之间的跳转。
1）. 在线负载型：微服务、⽹站、API
2）. 离线任务型：离线计算、机器学习
3）. 定时任务型：定时批量计算
不同类型的负载对于弹性伸缩的要求有所不同，在线负载对弹出时间敏感，离线任务对价格敏感，定时 任务对调度敏感
2、kubernetes 弹性伸缩布局
在 Kubernetes 的⽣态中，在多个维度、多个层次提供了不同的组件来满⾜不同的伸缩场景。
有三种弹性伸缩：
1）、CA（Cluster Autoscaler）：Node级别⾃动扩/缩容 cluster-autoscaler组件
2）、HPA（Horizontal Pod Autoscaler）：Pod个数⾃动扩/缩容
3）、VPA（Vertical Pod Autoscaler）：Pod配置⾃动扩/缩容，主要是CPU、内存 addon-resizer组件
如果在云上建议 HPA 结合 cluster-autoscaler 的⽅式进⾏集群的弹性伸缩管理。
3、Node ⾃动扩容/缩容
3.1、Cluster AutoScaler
扩容：Cluster AutoScaler 定期检测是否有充⾜的资源来调度新创建的 Pod，当资源不⾜时会调⽤ Cloud Provider 创建新的 Node。
缩容：Cluster AutoScaler 也会定期监测 Node 的资源使⽤情况，当⼀个 Node ⻓时间资源利⽤率都很 低时（低于 50%）⾃动将其所在虚拟机从云服务商中删除。此时，原来的 Pod 会⾃动调度到其他 Node 上⾯。
⽀持的云提供商：
阿⾥云：https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudpro vider/alicloud/README.md
AWS： https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovi der/aws/README.md
Azure： https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudpro vider/azure/README.md
3.2、Ansible扩容Node
⾃动化流程：
1. 触发新增Node
2. 调⽤Ansible脚本部署组件
3. 检查服务是否可⽤
4. 调⽤API将新Node加⼊集群或者启⽤Node⾃动加⼊
5. 观察新Node状态
6. 完成Node扩容，接收新Pod
扩容：
# cat hosts
...
[newnode]
192.168.31.71 node_name=k8s-node3
# ansible-playbook -i hosts add-node.yml -k
缩容
如果你想从Kubernetes集群中删除节点，正确流程如下：
1、获取节点列表
kubectl get node
2、设置不可调度
kubectl cordon $node_name
3、驱逐节点上的Pod
kubectl drain $node_name --ignore-daemonsets
4、移除节点
该节点上已经没有任何资源了，可以直接移除节点：
kubectl delete node $node_name
这样，我们平滑移除了⼀个 k8s 节点。
4、Pod⾃动扩容/缩容（HPA）
Horizontal Pod Autoscaler（HPA，Pod⽔平⾃动伸缩），根据资源利⽤率或者⾃定义指标⾃动调整 replication controller, deployment 或 replica set，实现部署的⾃动扩展和缩减，让部署的规模接近于 实际服务的负载。HPA不适于⽆法缩放的对象，例如DaemonSet。
4.1、HPA基本原理
Kubernetes 中的 Metrics Server 持续采集所有 Pod 副本的指标数据。HPA 控制器通过 Metrics Server的 API（Heapster 的 API 或聚合 API）获取这些数据，基于⽤户定义的扩缩容规则进⾏计算，得到⽬标Pod 副本数量。当⽬标 Pod 副本数量与当前副本数量不同时，HPA 控制器就向 Pod 的副本控制器（Deployment、RC 或 ReplicaSet）发起 scale 操作，调整 Pod 的副本数量，完成扩缩容操作。如图所示
在弹性伸缩中，冷却周期是不能逃避的⼀个话题， 由于评估的度量标准是动态特性，副本的数量可能会 不断波动。有时被称为颠簸， 所以在每次做出扩容缩容后，冷却时间是多少。
在 HPA 中，默认的扩容冷却周期是 3 分钟，缩容冷却周期是 5 分钟。
可以通过调整kube-controller-manager组件启动参数设置冷却时间：
--horizontal-pod-autoscaler-downscale-delay ：扩容冷却
--horizontal-pod-autoscaler-upscale-delay ：缩容冷却
4.2、HPA的演进历程
⽬前 HPA 已经⽀持了 autoscaling/v1、autoscaling/v2beta1和autoscaling/v2beta2 三个⼤版本 。
⽬前⼤多数⼈⽐较熟悉是autoscaling/v1，这个版本只⽀持CPU⼀个指标的弹性伸缩。
⽽autoscaling/v2beta1增加了⽀持⾃定义指标，autoscaling/v2beta2⼜额外增加了外部指标⽀持。 ⽽产⽣这些变化不得不提的是Kubernetes社区对监控与监控指标的认识与转变。从早期Heapster到 Metrics Server再到将指标边界进⾏划分，⼀直在丰富监控⽣态。
示例：
v1版本：
v2beta2版本：
5、基于CPU指标缩放
5.1、Kubernetes API Aggregation
在 Kubernetes 1.7 版本引⼊了聚合层，允许第三⽅应⽤程序通过将⾃⼰注册到kube-apiserver上，仍 然通过 API Server 的 HTTP URL 对新的 API 进⾏访问和操作。为了实现这个机制，Kubernetes 在 kube-apiserver 服务中引⼊了⼀个 API 聚合层（API Aggregation Layer），⽤于将扩展 API 的访问请 求转发到⽤户服务的功能。
当你访问 apis/metrics.k8s.io/v1beta1 的时候，实际上访问到的是⼀个叫作 kube-aggregator 的代 理。⽽ kube-apiserver，正是这个代理的⼀个后端；⽽ Metrics Server，则是另⼀个后端 。通过这种 ⽅式，我们就可以很⽅便地扩展 Kubernetes 的 API 了。
如果你使⽤kubeadm部署的，默认已开启。如果你使⽤⼆进制⽅式部署的话，需要在kube-APIServer 中添加启动参数，增加以下配置:
在设置完成重启 kube-apiserver 服务，就启⽤ API 聚合功能了。
5.2、部署 Metrics Server
Metrics Server是⼀个集群范围的资源使⽤情况的数据聚合器。作为⼀个应⽤部署在集群中。
Metric server从每个节点上Kubelet公开的摘要API收集指标。
Metrics server通过Kubernetes聚合器注册在Master APIServer中。
可通过Metrics API在Kubernetes中获得资源使⽤率指标，例如容器CPU和内存使⽤率。这些度量标准 既可以由⽤户直接访问（例如，通过使⽤ kubectl top 命令），也可以由集群中的控制器（例如， Horizontal Pod Autoscaler）⽤于进⾏决策。
测试：
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
kubectl top node
5.3、autoscaling/v1（CPU指标实践）
autoscaling/v1版本只⽀持CPU⼀个指标。
⾸先部署⼀个应⽤：
创建HPA策略：
scaleTargetRef：表示当前要伸缩对象是谁
targetCPUUtilizationPercentage：当整体的资源利⽤率超过50%的时候，会进⾏扩容。
开启压测：
10.0.0.147 为ClusterIP。
检查扩容状态：
# kubectl get hpa
# kubectl top pods
# kubectl get pods
关闭压测，过⼀会检查缩容状态。
⼯作流程：hpa -> apiserver -> kube aggregation -> metrics-server -> kubelet(cadvisor)
5.4、autoscaling/v2beta2（多指标）
为满⾜更多的需求， HPA 还有 autoscaling/v2beta1和 autoscaling/v2beta2两个版本。
这两个版本的区别是 autoscaling/v1beta1⽀持了 Resource Metrics（CPU）和 Custom Metrics（应 ⽤程序指标），⽽在 autoscaling/v2beta2的版本中额外增加了 External Metrics的⽀持。
# kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
与上⾯v1版本效果⼀样，只不过这⾥格式有所变化。
v2还⽀持其他另种类型的度量指标，：Pods和Object。
metrics中的type字段有四种类型的值：Object、Pods、Resource、External。
Resource：指的是当前伸缩对象下的pod的cpu和memory指标，只⽀持Utilization和
AverageValue类型的⽬标值。
Object：指的是指定k8s内部对象的指标，数据需要第三⽅adapter提供，只⽀持Value和
AverageValue类型的⽬标值。
Pods：指的是伸缩对象Pods的指标，数据需要第三⽅的adapter提供，只允许AverageValue类型的⽬标值。
External：指的是k8s外部的指标，数据同样需要第三⽅的adapter提供，只⽀持Value和
AverageValue类型的⽬标值
⼯作流程：hpa -> apiserver -> kube aggregation -> prometheus-adapter -> prometheus -> pods
6、基于Prometheus⾃定义指标缩放
资源指标只包含CPU、内存，⼀般来说也够了。但如果想根据⾃定义指标:如请求qps/5xx错误数来实现 HPA，就需要使⽤⾃定义指标了，⽬前⽐较成熟的实现是 Prometheus Custom Metrics。⾃定义指标 由Prometheus来提供，再利⽤k8s-prometheus-adpater聚合到apiserver，实现和核⼼指标（metricserver)同样的效果。
6.1、部署Prometheus
Prometheus（普罗⽶修斯）是⼀个最初在SoundCloud上构建的监控系统。⾃2012年成为社区开源项 ⽬，拥有⾮常活跃的开发⼈员和⽤户社区。为强调开源及独⽴维护，Prometheus于2016年加⼊云原⽣ 云计算基⾦会（CNCF），成为继Kubernetes之后的第⼆个托管项⽬。
Prometheus 特点：
1)、多维数据模型：由度量名称和键值对标识的时间序列数据
2）、PromSQL：⼀种灵活的查询语⾔，可以利⽤多维数据完成复杂的查询
3）、不依赖分布式存储，单个服务器节点可直接⼯作
4）、基于HTTP的pull⽅式采集时间序列数据
5）、推送时间序列数据通过PushGateway组件⽀持
6）、通过服务发现或静态配置发现⽬标
7）、多种图形模式及仪表盘⽀持（grafana）
Prometheus组成及架构：
Prometheus Server：收集指标和存储时间序列数据，并提供查询接⼝
ClientLibrary：客户端库
Push Gateway：短期存储指标数据。主要⽤于临时性的任务
Exporters：采集已有的第三⽅服务监控指标并暴露metrics
Alertmanager：告警
Web UI：简单的Web控制台
6.2、部署 Custom Metrics Adapter
但是prometheus采集到的metrics并不能直接给k8s⽤，因为两者数据格式不兼容，还需要另外⼀个组件(k8s-prometheus-adpater)，将prometheus的metrics 数据格式转换成k8s API接⼝能识别的格式，转换以后，因为是⾃定义API，所以还需要⽤Kubernetes aggregator在主APIServer中注册，以便直接通过/apis/来访问
https://github.com/DirectXMan12/k8s-prometheus-adapter
该 PrometheusAdapter 有⼀个稳定的Helm Charts，我们直接使⽤。
先准备下helm环境：
部署prometheus-adapter，指定prometheus地址：
6.3、基于QPS指标实践
部署⼀个应⽤：
该metrics-app暴露了⼀个Prometheus指标接⼝，可以通过访问service看到
创建HPA策略：
6.4、配置适配器收集特定的指标
当创建好HPA还没结束，因为适配器还不知道你要什么指标（http_requests_per_second），HPA也就 获取不到Pod提供指标。
ConfigMap在default名称空间中编辑prometheus-adapter ，并seriesQuery在该rules: 部分的顶部添 加⼀个新的：
该规则将http_requests在2分钟的间隔内收集该服务的所有Pod的平均速率。
测试API：
压测：
ab -n 100000 -c 100 http://10.1.181.193/metrics
查看HPA状态：
7、⼩结
1). 通过/metrics收集每个Pod的http_request_total指标；
2). prometheus将收集到的信息汇总；
3). APIServer定时从Prometheus查询，获取request_per_second的数据；
4). HPA定期向APIServer查询以判断是否符合配置的autoscaler规则；
5). 如果符合autoscaler规则，则修改Deployment的ReplicaSet副本数量进⾏伸缩
标签：伸缩,Kubernetes,弹性,指标,API,Pod,K8S,HPA From： https://www.cnblogs.com/hhjwqh/p/16710522.html