- PeiHongbing2023-01-03 来自广东问题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 仍然会被驱逐。展开
作者回复: 非常正确！
3 
Amosヾ2023-01-02 来自广东老师，我有个疑问：metrics server显示的内存一般是含有cache的，linux内核会定时回收这部分资源，所以HPA更想通过no cache内存或working set内存进行，这里又较好的方案吗？作者回复: Metrics 对资源的计算确实有延迟。在生产实践上，你可以借助 KEDA 来实现自己的 HPA 策略，比如从 Prometheus 读取 Metrics 来进行伸缩，或者其他事件来驱动 HPA，这也是一个不错的技术选型。
3
大圈2023-03-17 来自北京老师，对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 还可以在流量波谷的时候减小副本数，提高资源利用率。
1- zangchao2023-01-29 来自天津老师，想请教下，K8s有什么方法控制I/O这块，目前我们的集群节点Load过高后，会导致整个节点的服务请求503，这方面有推荐的实践方法么？
作者回复: Load 过高是 CPU 内存吗？还是磁盘 I/O？如果是 CPU 和内存，增加节点就好。如果是 I/O 跟不上，把节点的磁盘换成 SSD 高性能磁盘。
1 
李多2023-01-08 来自广东老师好，我有一个问题。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。
共 2 条评论1
凡达2023-01-31 来自北京老师，压力减少后，缩容是怎么处理的？作者回复: K8s 会自动缩容。
GAC·DU2023-01-04 来自广东老师，averageUtilization值没算明白，以内存为例，这个平均利用率是通过每个Pod的使用内存除以limit值吗？作者回复: Pod 的总平均使用率，也就是所有 Pod 的实际使用量与请求 request 资源比例的平均值。
êｗěｎ2023-01-02 来自广东或者大家都是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内存怪吓人的作者回复: 哈哈，谢谢，继续加油～