Kubernetes Blog
·
通过API流式传输提升Kubernetes API服务器效率
💡
原文英文，约1100词，阅读约需4分钟。
📝
内容提要
Kubernetes 1.32引入流式API列表请求，显著提升了kube-apiserver的内存效率。传统列表请求会迅速耗尽内存，而流式请求通过逐个传输数据，保持恒定的内存开销。测试表明，启用后内存使用量从20GB降至约2GB，增强了系统稳定性，尤其在处理大量对象时。
🎯
关键要点
- Kubernetes 1.32引入流式API列表请求，显著提升了kube-apiserver的内存效率。
- 传统列表请求会迅速耗尽内存，而流式请求通过逐个传输数据，保持恒定的内存开销。
- 启用流式请求后，内存使用量从20GB降至约2GB，增强了系统稳定性。
- kube-apiserver在处理列表请求时，需先从数据库获取数据并进行反序列化，导致临时内存消耗大。
- API优先级和公平性无法有效保护内存，可能导致kube-apiserver因内存耗尽而崩溃。
- 流式请求通过watch缓存逐个传输数据，显著降低了临时内存使用。
- 在自动化性能测试中，启用watch列表功能后，kube-apiserver的内存消耗稳定在约2GB。
- 建议用户升级到Kubernetes 1.32，并使用watch列表以优化内存使用。
- kube-controller-manager在Kubernetes 1.32中默认启用该功能，未来将扩展到其他核心组件。
- 合成测试显示，仅需16个informers便可导致内存耗尽，强调了流式请求的重要性。
❓
延伸问答
Kubernetes 1.32的流式API列表请求有什么优势？
流式API列表请求显著降低了kube-apiserver的内存使用，从20GB降至约2GB，增强了系统稳定性。
传统的列表请求为何会导致内存耗尽？
传统列表请求需要在发送数据前将整个响应加载到内存中，导致临时内存消耗大，容易造成内存耗尽。
如何启用Kubernetes的流式请求功能？
用户需升级到Kubernetes 1.32，并在客户端代码中启用WatchListClient功能以使用流式请求。
流式请求是如何改善内存使用的？
流式请求通过逐个传输数据而非一次性返回整个集合，保持恒定的内存开销，显著降低临时内存使用。
Kubernetes 1.32中流式请求的默认启用情况如何？
在Kubernetes 1.32中，kube-controller-manager默认启用流式请求功能，未来将扩展到其他核心组件。
流式API列表请求对系统稳定性有什么影响？
流式API列表请求通过降低内存消耗，增强了系统在处理大量对象时的稳定性，减少了崩溃风险。
🏷️
标签
➡️
