前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >限制进程ID改进Kubernetes 1.14的稳定性

限制进程ID改进Kubernetes 1.14的稳定性

作者头像
CNCF
发布2019-12-04 11:04:17
4810
发布2019-12-04 11:04:17
举报
文章被收录于专栏:CNCF

作者:Derek Carr

你有没有看过有人吃了超过公平分享的饼干?也就是一个人进来,抓住了半打新鲜出炉的巧克力,然后像Cookie Monster一样,惊呼“Om nom nom nom”。

在一些罕见的工作负载中,Kubernetes集群内部也发生了类似的情况。对于每个Pod和节点,所有应用程序共享有限数量的进程ID(PID)。虽然任何一个进程或pod都很少会获取所有PID,但由于这种类型的行为,一些用户会经历资源匮乏。因此,在Kubernetes 1.14中,我们引入了一项增强功能,以降低单个pod垄断所有可用PID的风险。

你可以给我一些PID吗?

在这里,我们谈论的是某些贪婪的容器。在理想之外,失控过程会不时发生,特别是在进行测试的集群中。以及,会有一些非生产的活动在运行。

在这种情况下,节点内可能会出现fork炸弹。随着资源逐渐消失,被一些不断产生类似僵尸的进程所接管,而且不断产生child进程,其他合法的工作量开始受到这种浪费所冲击。这可能导致同一个pod上的其他进程缺乏所需的PID。它还可能导致有趣的副作用,因为节点可能会失败,该pod的副本被安排到一台新机器上,这流程会在整个集群中重复。

解决问题

因此,在Kubernetes 1.14中,我们添加了一个功能,允许配置kubelet,以限制pod可以使用的PID数量。如果该机器支持32,768个PID和100个pod,可以为每个pod提供300个PID的预算,以防止完全耗尽PID。如果管理员想要类似于cpu或内存,过度使用PID,那么他们也可能会有一些额外的风险。无论哪种方式,没有一个pod可以整倒一个机器。这通常可以防止简单的fork炸弹接管你的集群。

此更改允许管理员从别的pod保护一个pod,但不能确保计算机上的所有pod会保护节点,以及节点代理程序本身是否会崩溃。因此,我们在此版本中以alpha形式引入了一个功能,可以从节点代理程序(kubelet,运行时等)中分离跑在pod上的最终用户工作负载的PID。管理员能够保留特定数量的PID,并确保它们永远不会被该机器上的pod使用 - 类似于当前预留CPU或内存的方式。一旦从alpha版本升级到beta版本,然后在未来版本的Kubernetes中保持稳定,我们就可以防范容易匮乏的Linux资源。

开始在Kubernetes 1.14使用。

参与其中

如果您对此功能有反馈意见或有兴趣参与设计和开发,请加入Node Special Interest Group。

https://github.com/kubernetes/community/tree/master/sig-node

关于作者

Derek Carr是Red Hat的高级首席软件工程师。他是Kubernetes的贡献者,也是Kubernetes社区指导委员会的成员。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-04-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 CNCF 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档