混合IT将思维方式从云优先转变为云最佳

和Systemd给系统启动带来的好处类似，这让系统可以尽可能地并行执行生命周期操作，但也仅此而已。而且由于工作流程是显式的，它还可以扩展。你的集群是否存在这种情况：在每个Pod上都有企业定制的操作，且必须在某个生命周期阶段内执行的?可以定义一个新的中间target，使其依赖于于正确的前置或后置条件，然后将控制循环挂接(hook)到这里接收回调。编排系统将确保控制循环在生命周期的各阶段发挥作用。

请注意，这还解决了诸如Istio之类的存在奇葩问题。在Istio中，它们必须注入一些额外的开发者提供的定义才能起作用。没必要!提供对应的控制循环介入到生命周期管理中，并根据实际需要在进行调整。只要你可以向系统表示，在生命周期中某个特定阶段需要执行操作的，就无需考虑通过向运维人员提供额外的资源对象去操作。

这部分内容很长，但想表达的意思很简短。这和Kubernetes的原来的API machinery大相径庭，因此需要大量新的设计工作才能实现。最突出的变化，控制循环不再只是简单地观察集群对象的状态并做出修正，还必须等待编排器(Orchestrator)完成对特定对象的调用，当这些对象达到符合预期的状态时，控制循环再进一步响应。你现在可以通过注解和约定，将其在Kubernetes实现上。但除非对工作机制的细枝末节的都了解得一清二楚，否则就可观察性和可调试性来说，没什么帮助。

有趣的是，Kubernetes已经有其中一些想法的原型实现：Initializers和Finalizers 。它们分别是生命周期两个不同阶段里执行预操作的钩子。它使您可以将控制循环挂接到两个硬编码的“target”上。他们将控制循环分为三个部分：初始，“默认”和终结。虽然是硬编码，这是显式工作流程图的雏形。我打算把这个设计推广到更一般的情况。

显式的字段归属

承接上一部分设计的适度扩展：使资源对象的每个字段都被特定的控制循环显式拥有。该循环是唯一允许写入该字段的循环。如果未定义所有者，则该字段可被集群运维人员写入，但运维人员不能写其他任何内容。这是由API machinery(而非约定)强制执行的。

这已经是大多数情况，但还是存在字段所有权模糊不清的时候。这导致两个问题：如果字段错误，则很难弄清谁负责;而且一不小心就会进入到两个控制器修改一个字段的情况，陷入循环。

后者是MetalLB存在的大麻烦，它与其他一些负载均衡器实现方式发生了冲突。不应该出现这样的情况。Orchestrator应该拒绝MetalLB添加到集群中，因为与LB相关的字段将有两个所有者。

可能需要留个后门，让用户处理一个字段有多个归属者的情况。但简单起见，我在这里先不考虑，然后看看设计是不是经得起考验。除非有充分证明支持，否则共享所有权就是一个会带来潜在隐患的设计。

如果你还要求控制循环显式注册读取的字段(并把那些没有注册的字段剥离出来——不准作弊)，这也可以让你做一些有意义的事情，比如证明系统收敛(没有读->写->读的循环)，或是帮你照出拖慢系统响应速度的调用环节。

有且只有IPv6

我对Kubernetes网络部分非常熟悉，它是我最想全盘推倒重来的一个部分。有很多原因造成了网络模块发展成今天这个局面，我并不是想说Kubernetes网络设计得一无是处。但网络不在我的编排体系里。这部分内容很长，请带点耐心。

首先，让我们先彻底抛开Kubernetes现有的网络。覆盖网络，Service， CNI，kube-proxy，网络插件，这些统统都不要了。

(顺便提一句，为什么网络插件是不应该出现K8s理想的设计中的。目前，已经有不少企业开始兜售他们的网络插件了，你最好不要相信他们能保持客观中立，让我来列出反驳他们的理由。无论是自然界还是软件界，所有生态系统的第一要务都是确保其继续存在。你不能要求一个生态系统自我进化到灭亡，你必须从外部触发灭亡。)

回到正题，现在一切归零了。我们有容器，它们需要互相通信，和外部通信。那该做什么?

让我们赋予每个Pod一个IPv6地址。是的，只有一个IPv6地址。它们从哪里来?这里要求局域网支持IPv6(假定具备这样的条件，毕竟我们的设计要面向未来)，IP地址就从这来。你几乎都不需要做IP地址冲突检测，2^64足够大，随机生成的IP地址基本上就满足需求了。我们需要一个机制，好让每个节点上之间能互相发现，这样就可以找到其他 Pod 在哪个节点上。这应该不难实现，这么做的理由很简单：对集群网络内的其他部分而言，一个 Pod 看起来就像是在运行其中的某个节点。

（编辑：伊春站长网）

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