作者: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社区指导委员会的成员。