误将被黑商店的列表泄露了

可修改的Pod

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

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

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

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

版本管理

来继续讨论Pod的设计：既然它现在是可变的了，那么我接下来考虑的事情自然而然就是Pod回滚。为此，让我们保留Pod旧版本的定义，如此一来“回滚到特定旧版本”就轻而易举了。

现在，Pod更新流程如下：编写文件更新Pod定义，并进行更新以符合预期定义。更新出错?回滚上一个版本，流程结束。

上述流程的好处是：无需依赖所谓的GitOps，即可轻松了解到集群中应用的版本迭代。如无必要就不用引入GitOps，尽管它有不少优点。如果，你只希望解决一个很基本的“集群发生了什么变化?”的问题，仅仅使用集群中的数据就够了。

其中还涉及到更多设计细节。尤其是我想将外部更改(用户提交Pod的变更)与系统变更(Kubernetes内部触发的Pod定义变更)这两者区分开。我还没有考虑清楚如何对这两种变更的历史信息进行编码，并使得运维人员和其他系统组件都可以获取到这些变更。也许可以设计成完全通用的，“修改人”在提交新版本时会标识自己。然后用户可以指定特定修改人(或排除特定修改人)以查询某类变更(类似于标签查询的工作原理)。同样的，这里还需要更多的设计考量，我确定的是我想要一个具有版本管理特性的Pod对象，可以查询它的历史版本记录。

最后，还需要考虑垃圾回收。具体说就是，对每个Pod的更改应该可以很好地进行增量压缩。默认设置是保留所有变更内容，积累到一定数据量后，在此基础上进行一次压缩。保留所有变更内容也会对系统产生一定压力，但可避免“因频繁提交更改”而给系统的其它部分带来影响。这里用户要注意，为方便聚合，应该进行次数更少同时更有意义的变更，而不是每次改动一个字段进而产生一系列版本。

一旦有了历史版本这个功能后，我们还可以整一些其它的小功能。例如，节点可以将最近的若干个版本的容器镜像保留在节点上，从而使回滚更快。原来的垃圾回收超过一定期限就触发，有了历史版本记录，可以更精确地保留需要的版本数。概括而言，所有编排软件都将旧版本用作各种资源对象的GC roots，以加快回滚速度。回滚是避免服务中断的基本方式，这是非常有价值的事情。

用PinnedDeployment替换Deployment

这是部分内容比较简短，主要是受Vallery启发。他的PinnedDeployment设计非常让人惊叹。PinnedDeployment使运维人员可以通过跟踪两个版本的Deployment状态来控制应用发布。这是由SRE设计的部署对象。设计人员非常清楚SRE在部署中的关注的焦点。我个人很喜欢这个设计。

这可以和上面的可版本管理、可原地更新的Pod结合得非常好，真想不到还有什么可以添加的了。它非常清晰的解释了多个Pod时的工作流程。要从Kubernetes各项约束中脱离来适应这一个全新的流程，可能需要做些调整，但是大体设计是非常不错的。

显式的编排流程

我认为Kubernetes的“API machinery”机制最大问题是编排，即一系列独立控制循环的松散集合所构成工作流程。从表面上看，这似乎是一个好主意：你有好几十个微小的控制循环，每个控制循环只负责一个小功能。当它们被整合到一个集群时，它们彼此互相协作以调谐资源对象状态并收敛至符合预期的最终状态。所以这其中有何问题?

问题就在于出现错误时几乎不可能去进行调试。 Kubernetes中典型的出错，就是用户将变更提交给集群，然后反复刷新以等待资源对象符合预期，如果迟迟没有符合……那么，来问题了。 Kubernetes分辨不出“对象已符合预期”和“控制循环被中断并阻塞了其他事物”之间的区别。你或许希望有问题的控制循环会发布它所管理对象的一些事件来帮你排错，但总的来说它们发挥不了多少作用。

（编辑：伊春站长网）

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