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

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