我过往的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，可以不考虑和现有的兼容，另辟蹊径，该考虑哪些点呢?