HPA
EKS Auto Mode中的disruption
Disruption可能发生在诸如节点缩减以降低集群成本（如装箱优化）或达到其最大生命周期等情况下。这可能会影响这些节点上运行的Pod。EKS Auto mote在底层使用Karpenter来优化节点扩展并有效管理这些中断。
Karpenter通过三个关键机制管理节点disruption：过期、漂移检测和整合，其中后者是本节的重点，因为它与自动扩展更相关。
整合
整合(Consolidation)通过持续监控集群中节点和Pod的利用率来工作。当节点变得利用率不足或空闲时，Karpenter启动整合过程以优化集群资源。这涉及移除没有活跃工作负载的节点，在现有容量允许的情况下有效地将Pod打包到现有节点上，并通过小心地驱逐和重新调度Pod来执行优雅的节点排空，从而在整个整合过程中保持应用程序的可用性。
下面我们可以看到EKS Auto Mode创建和管理的general-purpose NodePool中disruption的配置：
➤ 获取NodePool配置：
kubectl get nodepools general-purpose -o yaml
这应该显示以下输出：
WhenEmptyOrUnderutilized配置属性确保Karpenter将考虑所有节点进行整合，并在发现节点为空或利用率不足且可以移除或替换以降低成本时尝试移除或替换节点。expireAfter设置为自定义值，使节点在336小时（14天）后自动终止。budget配置块控制Karpenter可以缩减节点的速度。
HPA
我们将探索HPA如何根据观察到的指标自动扩展Kubernetes中的Pod。HPA由资源定义和控制器组成，其中控制器定期检查资源利用率（如CPU、内存或自定义指标）与用户定义的目标进行比较，并相应地调整副本数量。
Metrics Server组件是必需的，用于从集群收集和聚合资源使用数据，并为HPA提供做出扩展决策所需的指标。
安装Metrics Server
要在EKS Auto mode中启用HPA，安装Metrics Server是必不可少的。AWS通过社区附加组件 提供了Metrics Server的简化安装过程，以简化部署和管理。默认创建的时候就已经安装：
以下命令将显示我们集群中节点和UI组件Pod的资源利用率：
kubectl top node
kubectl top pods -l app.kubernetes.io/name=ui
结果应类似于以下内容：
先将之前scale到12个pod的UI降到3个：
kubectl scale deployment ui --replicas=3
配置HPA
目前集群中没有启用水平Pod自动扩展的资源，可以通过执行以下命令进行验证：
kubectl get hpa --all-namespaces
预期输出：
No resources found
配置HPA：
kubectl autoscale deployment ui --cpu-percent=60 --min=3 --max=10
结果应类似于以下内容：
HPA资源将始终运行至少3个副本，并在平均CPU利用率达到60%时扩展到最多10个副本。
使用以下命令查看HPA资源：
kubectl get hpa
预期输出应类似于此：
生成负载
为了观察HPA根据我们配置的策略进行扩展，我们需要在应用程序上生成一些负载。我们将通过使用hey 调用ui主页来实现这一点。
下面的命令将在集群中运行负载生成器作为一个Pod，具有：
- 10个并发运行的工作线程
- 每秒发送5个查询
- 最长运行60分钟
部署load-generator：
kubectl run load-generator \
--image=williamyeh/hey:latest \
--restart=Never -- -c 10 -q 10 -z 3m http://ui/utility/stress/100000
现在我们的应用程序正在接收请求，我们可以观察HPA资源以跟踪其进展。
➤ 执行以下命令：
kubectl get hpa ui --watch
输出应类似于：
可以在上面的输出中看到CPU利用率如何随着负载逐渐增长，并导致HPA添加更多UI组件的副本以适应该负载。
如果我们对自动扩展行为感到满意，使用Ctrl+C结束观察，并按如下方式停止负载生成器：
kubectl delete pod load-generator