2. Kubernetes HPA基础：Pod水平自动伸缩的工作原理、Metrics Server部署
好，咱们进入正题。这一章聊的是HPA——Pod水平自动伸缩。说白了，就是让Kubernetes根据负载情况，自动帮你加Pod或者减Pod。我刚开始接触这个功能时，觉得它挺神奇的，后来自己搭了一遍才发现，核心逻辑其实不复杂。
2.1 HPA到底在干什么？
HPA的全称是Horizontal Pod Autoscaler。它监控Pod的CPU、内存这些指标，然后根据你设定的阈值，自动调整Deployment或StatefulSet的副本数。
举个例子。你有个Web服务，平时流量不大，3个Pod就够了。突然搞了个促销活动，流量暴涨。HPA检测到CPU使用率超过80%，就会自动把Pod加到10个。等活动结束，流量降下来，它再把Pod缩回3个。
嗯，这里要注意：HPA只管“水平”伸缩，也就是加机器或减机器。它不管“垂直”伸缩，比如给Pod加CPU、加内存。那是VPA干的事，咱们后面会讲。
核心要点：HPA通过不断计算“期望副本数”，然后调用Kubernetes API去更新Deployment的replicas字段。整个过程是自动的，不需要人工干预。
2.2 HPA的工作原理
HPA的工作流程，我习惯把它拆成三步：
- 采集指标：HPA通过Metrics Server获取Pod的CPU、内存等资源使用数据。
- 计算期望副本数：根据当前指标值和目标值，算出一个期望的Pod数量。
- 调整副本数：调用API更新Deployment，让实际副本数向期望值靠拢。
计算公式其实很简单：
期望副本数 = 当前副本数 × (当前指标值 / 目标指标值)举个例子。你设的目标CPU使用率是50%。当前有3个Pod，每个Pod的CPU使用率分别是60%、70%、80%。那平均使用率就是(60+70+80)/3=70%。
期望副本数 = 3 × (70% / 50%) = 4.2，向上取整就是5个。
HPA会每隔15秒（默认）执行一次这个计算。如果算出来的结果和当前副本数不一样，它就触发伸缩操作。
我的经验：HPA有个冷却机制。伸缩操作完成后，它会等一段时间再执行下一次计算。默认是扩容3分钟，缩容5分钟。我曾经遇到过因为没配冷却时间，导致Pod频繁震荡的情况——刚扩容完又缩容，缩完又扩容，那叫一个酸爽。
2.3 Metrics Server：HPA的数据来源
HPA要干活，得有数据支撑。这个数据来源就是Metrics Server。
Metrics Server是Kubernetes的一个插件。它从每个Node上的kubelet收集资源使用数据，然后通过Metrics API暴露出来。HPA就是通过这个API拿到Pod的CPU、内存使用情况的。
你想想看，如果没有Metrics Server，HPA就是个瞎子，啥也干不了。所以部署HPA之前，第一步就是装Metrics Server。
注意：Metrics Server只保存最近1-2分钟的数据。它不做长期存储，也不做历史趋势分析。如果你需要更复杂的监控和告警，得用Prometheus那套方案。
2.4 部署Metrics Server
部署Metrics Server其实不复杂。我一般用官方提供的YAML文件直接安装。
第一步，下载部署文件：
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml第二步，修改一下配置。因为很多Kubernetes集群（特别是自建的）用的证书是自签名的，Metrics Server默认会验证kubelet的证书。如果不关掉验证，它会报错。
找到Deployment部分，在args里加上这个参数：
--kubelet-insecure-tls完整的args看起来像这样：
spec:
template:
spec:
containers:
- args:
- --kubelet-insecure-tls
- --cert-dir=/tmp
- --secure-port=4443
image: registry.k8s.io/metrics-server/metrics-server:v0.6.4第三步，部署到集群：
kubectl apply -f components.yaml部署完成后，等个几十秒，检查一下是否正常运行：
kubectl get pods -n kube-system | grep metrics-server如果状态是Running，那就说明装好了。你可以试试这个命令：
kubectl top nodes能看到每个Node的CPU和内存使用情况，就说明Metrics Server在正常工作。
避坑指南：我曾经在某个生产环境部署Metrics Server时，发现Pod一直CrashLoopBackOff。查了半天，发现是集群的CNI网络插件限制了Pod的DNS解析。Metrics Server启动时需要解析kubelet的地址，结果解析不了。解决办法是在args里加上--kubelet-preferred-address-types=InternalIP，让它直接用IP地址通信。
2.5 验证Metrics Server是否正常工作
部署完Metrics Server，我习惯做三件事来验证：
- 查看节点资源：
kubectl top nodes，能看到所有节点的CPU和内存使用率。 - 查看Pod资源：
kubectl top pods -n <namespace>，能看到每个Pod的资源使用情况。 - 检查API是否可用：
kubectl get --raw /apis/metrics.k8s.io/v1beta1，如果能返回JSON数据，说明Metrics API正常工作。
这三步都过了，Metrics Server就算部署成功了。接下来就可以配置HPA了。
2.6 小结
这一章咱们聊了HPA的基本原理和Metrics Server的部署。说白了，HPA就是个自动扩缩容的控制器，Metrics Server就是它的眼睛。没有Metrics Server，HPA啥也干不了。
下一章我会带你实战配置一个HPA，看看它到底怎么用。到时候咱们会写一个完整的YAML文件，然后压测看看效果。嗯，那个环节挺有意思的，你可以亲眼看到Pod数量随着负载变化而自动调整。