11｜K8s 极简实战（六）：如何保障业务资源需求和自动弹性扩容？
kubernetes 的资源配额
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入介绍了在 Kubernetes 环境下如何有效管理资源，保障业务需求，并实现自动弹性扩容的方法。首先，作者详细讨论了 Kubernetes 的资源配额管理，包括资源请求（Request）和资源限制（Limit）的重要性和实际应用。其次，文章介绍了服务质量（QOS）的概念，以及未配置资源配额、Request 小于 Limit、Request 等于 Limit 三种情况对应的服务质量，为读者提供了实际的配置建议。最后，文章详细介绍了水平扩容（HPA）的原理和配置方法，以及基于 CPU 的扩容策略的实现。通过本文，读者可以快速了解在 Kubernetes 环境下如何保障业务对资源的需求，实现自动弹性扩容，对于在实际生产环境中应用 Kubernetes 的读者具有实际指导意义。文章还提供了基于内存的扩容策略的配置示例，并强调了为业务应用配置水平扩容策略的重要性。同时，通过思考题的设置，鼓励读者进行实验和思考，加深对资源配额和服务质量的理解。整体而言，本文内容丰富，涵盖了 Kubernetes 资源管理的多个方面，对于希望深入了解和应用 Kubernetes 的读者具有实际指导意义。
《云原生架构与 GitOps 实战》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
Amosヾ老师，我有个疑问：metrics server显示的内存一般是含有cache的，linux内核会定时回收这部分资源，所以HPA更想通过no cache内存或working set内存进行，这里又较好的方案吗？作者回复: Metrics 对资源的计算确实有延迟。在生产实践上，你可以借助 KEDA 来实现自己的 HPA 策略，比如从 Prometheus 读取 Metrics 来进行伸缩，或者其他事件来驱动 HPA，这也是一个不错的技术选型。
2023-01-02归属地：广东4- PeiHongbing问题1： a. Pod的状态为Pending，kubectl describe的Events信息如下： Warning FailedScheduling 30s default-scheduler 0/1 nodes are available: 1 Insufficient cpu, 1 Insufficient memory. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod. b. Pod状态为Running，kubectl describe的Events信息如下： Normal Scheduled 51s default-scheduler Successfully assigned test/backend-645d55c844-lfhzl to kind-control-plane Normal Pulling 51s kubelet Pulling image "lyzhang1999/backend:latest" Normal Pulled 49s kubelet Successfully pulled image "lyzhang1999/backend:latest" in 1.875569425s Normal Created 49s kubelet Created container flask-backend Normal Started 49s kubelet Started container flask-backend 问题2：node节点出现故障或者资源少于操作系统（组件）运行所需资源时，Guaranteed 优先级的 Pod 仍然会被驱逐。
作者回复: 非常正确！
2023-01-03归属地：广东3 
大圈老师，对HPA这块一直有一个问题挺困惑的，我看网上关于HPA讨论的都是基于原有node节点数量不变然后扩容pod数量的。 基于这种情况，然后我疑惑的是： A. 假如一个节点只运行一个java服务只起1个pod，再将pod的资源配额limit配置为节点CPU、内存的80～90%。 B. 假如一个节点只运行一个java服务只起1个pod，再将pod的资源配额limit配置为节点CPU、内存的40～45%。 那当业务高峰来临时，1、A的pod数量不变，B的pod数量+1，但是处理请求的能力，这两种情况好像并没有什么较大的区别。 问题来了，我理解的是这种所谓的HPA好像并不能解决什么实际问题？ 但如果是自动扩缩容node节点的话，在新增的node节点上扩容pod，或高峰过去后再减去之前新增的node节点，这样我认为是有实际意义的。 老师怎么看待或理解HPA这块的实际场景中的功能的呢？作者回复: 这个思考很棒。 如果单纯从资源上看，确实AB方案似乎没什么区别。但在实际场景，多实例的稳定性远远比单实例要好。主要两个方面。一是单点故障，二是多实例在高并发场景不容易因为请求堆积导致雪崩。 另外一个方面是 HPA 还可以在流量波谷的时候减小副本数，提高资源利用率。
2023-03-17归属地：北京1- zangchao老师，想请教下，K8s有什么方法控制I/O这块，目前我们的集群节点Load过高后，会导致整个节点的服务请求503，这方面有推荐的实践方法么？
作者回复: Load 过高是 CPU 内存吗？还是磁盘 I/O？如果是 CPU 和内存，增加节点就好。如果是 I/O 跟不上，把节点的磁盘换成 SSD 高性能磁盘。
2023-01-29归属地：天津1 
李多老师好，我有一个问题。K8s默认在Pod运行中不能改变资源配额，而使用VPA触发资源配额修改时，会kill掉Pod然后重启新的Pod。 所以我想请教下您，有没有什么方式能够实现在Pod运行中动态的修改request和limits资源配额，同时又不会导致Pod重建，避免影响业务呢。作者回复: 这个增强社区呼声很高，据我所知目前还无法实现，你可以关注这个提案：https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1287-in-place-update-pod-resources。 好消息是，这个提案目前已经有 PR 了，但还没有被合并：https://github.com/kubernetes/kubernetes/pull/102884，相信不久后会合并并发布。 最后，部分云厂商的托管 K8s 提供原地资源配额修改的能力，比如腾讯云：https://cloud.tencent.com/document/product/457/79697。
2023-01-08归属地：广东21
凡达老师，压力减少后，缩容是怎么处理的？作者回复: K8s 会自动缩容。
2023-01-31归属地：北京
GAC·DU老师，averageUtilization值没算明白，以内存为例，这个平均利用率是通过每个Pod的使用内存除以limit值吗？作者回复: Pod 的总平均使用率，也就是所有 Pod 的实际使用量与请求 request 资源比例的平均值。
2023-01-04归属地：广东
êｗěｎ或者大家都是Guaranteed ，那就按照优先级驱逐吗？作者回复: K8s 在驱逐 Pod 的时候会先给 Pod 排序，不同场景下排序的算法有差异。 比如在节点内存资源不足的场景下，是会参考优先级来驱逐 Pod 的。
2023-01-02归属地：广东- êｗěｎrequest超过宿主机pod直接pending 起不来了。event可以看到资源不足信息。 node offline ，Guaranteed pod也结束了
作者回复: 是的，在 Node 节点宕机的情况下，节点所有 Pod 都会被驱逐并在新的节点重建。
2023-01-02归属地：广东 
橙汁qos那部分，真是够透彻的 一看就能懂 不需要死记硬背，以前看还想着背下来 啥都没记住，这么一讲直接理解记住。hpa部分两个必要条件metric一般会有，但必须设置资源request还是第一次知道，学到了。关于最后的题目 用阿里云碰到过这种问题 你的资源请求request是不能超过宿主机总共的资源，不知道会不会有这方面的影响，一看32核cpu 64g内存怪吓人的作者回复: 哈哈，谢谢，继续加油～
2023-01-02归属地：广东
