若是重新设计Kubernetes

落笔前，我想强调几点：

• 这不是一个完全成形的设计。其中某些想法可能根本无法落地，或者需要进行大量的重构。很多章节的内容都是想到哪写到哪。
• 这些观点不单纯是我一个人的想法。有些是我原创的，更多的是集体思考，交流碰撞后的产物，就像Kubernetes社区中的许多设计一样。我知道至少Vallery和Maisem Ali不止一次地启发了我的思考，还有更多我说不出名字的。如果你觉得文中有些想法很不错，那请把它当成是集体努力的结果。如果你不太认同其中一些看法，那把它当成是我个人的小小失误吧。
• 文中的一些观点是非常极端激进的。我只是尝试把脑海的一些设计表达出来，一吐为快。

设计原则

我过往的Kubernetes实践经验来自两个截然不同的地方：一个是为裸金属机集群维护MetalLB;另一个是在GKE SRE中运维大型的集群即服务(clusters-as-a-service)。这两个经历都让我觉得，Kubernetes相当复杂，要达到目前市面上宣传的效果，往往需要做大量的前置工作，而大多数跃跃欲试的用户对此都没有充分的准备。

维护MetalLB的经历告诉我，想构建与Kubernetes集成的健壮性优异的软件十分困难。我认为MetalLB稳定性堪称优秀，但是Kubernetes还是非常容易使它出现配置错误的情况，而调试起来也相当费劲。 GKE SRE的运维经历则教会我，即使是最出色的Kubernetes专家也无法不出差错地运维大规模Kubernetes集群(尽管GKE SRE借助一些工具能做得非常出色)。

Kubernetes可以类比成编排软件中的C ++。功能强大，特性完备，看上去似乎挺简单，但你会不停踩坑，直到你投入大量时间和精力，去弄清它的所有原理为止。即便如此，Kubernetes的配置和部署方式方法众多，生态还在不停发展，以至于很难让人觉得可以停下脚步歇口气了。

按照这个类比，我理想的参照物是Go。如果Kubernetes是C ++，那么编排系统中Go会是什么样的呢?极度简洁，特点突出，缓慢而谨慎地拓展新特性，你可以在不到一周的时间里上手，然后就能用它去完成你的工作。

接下来，我们就遵循上面这些原则开始了。重新设计一个Kubernetes，可以不考虑和现有的兼容，另辟蹊径，该考虑哪些点呢?

可修改的Pod

在Kubernetes中，大部分(但不是全部)Pod在创建后是不可变的。如果你想直接修改一个Pod，不行。得重新创建一个再删掉旧的。这与Kubernetes中的大多数资源对象的处理方式不同，在Kubernetes中的大多数对象都是可变的，并且当预期状态出现变化时，可以优雅地将实际状态协调到与预期一致。

因此，我不想让Pod成为一个例外。我打算将它设计成完全可读写，并让它拥有像其它资源对象一样的调谐逻辑。

对此我第一时间想到的方案是原地重启。如果Pod的调度约束和需求资源前后没有改变，猜一下如何实现? 发出SIGTERM信号终止runc，使用不同的参数重新启动runc，就已完成重启。这样一来，Pod有点像从前的systemd服务，必要时还可以在不同机器之间漂移。

请注意，这不需要在运行时层面操作可变性。如果用户更改了Pod定义，仍然可以先终止容器并使用新配置重新启动容器。 Pod仍会保留在原节点上预留的资源，因此从概念上讲，它等效于systemctl restart blah.service。你也可以尝试在并在运行时层级上来执行Pod的更新操作，但其实没有必要这样做。不这么做的主要好处是将调度、Pod生命周期及运行时生命周期管理解耦。

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!