【翻译】Kubernetes是注定要失败的!

主机的未来是什么样子的？

如果西雅图上空的一个巨大的杀手级热穹顶不是一个标志，那么什么才是？但是谷歌、亚马逊和微软在听吗？他们的计划是什么，我们这些人如何融入其中？

在我们之前关于主机技术未来发展方向的文章中（一，二），我谈到了欧盟委员会，他们认为我们的行业有两个问题需要解决，以应对气候变化：硬件中的碳体现（我们需要使物理东西更持久）和直流电的使用（我们需要使用100%的零碳电）。

在这篇文章中，我将再次谈论这两个问题，并看看谷歌最近的一篇论文，关于他们如何希望在自己的DC中解决这些问题。值得关注的是谷歌，因为在过去的20年里，他们一直在高效DC运营领域处于领先地位。

但是，如果谷歌如此从事面向未来的IT，并且他们发明了Kubernetes，为什么我肯定它是注定要失败的？

喘口气吧

在我们深入了解细节之前，让我们退一步，总结一下谷歌到现在所面临的问题，而我们其他人在不到5年的时间里将会惊恐地盯着这个问题。

• 除非你在一个拥有非常可观的核电、地热或水力发电的国家，否则你将很难一直获得碳零电力。太阳并不总在外面，风也不总在吹。有储存的解决方案，但它们并不那么好。结果是大多数国家将有非常多的电力定价，它将必须是一个行为转变的成本差异，因为这将是重点。(资本主义确实有一些值得称道的特点，它们可能会被部署，但为此，你需要重要的商业动机）。
• 大公司已经设定了期望，即科技行业的公司将在2040年之前实现零碳排放（对于托管公司，2030年）。

这将是一个棘手的问题。谷歌对此有什么看法？

在Kubernetes之前

谷歌已经做了很长时间的可编程基础设施，以寻求超高效的数据中心。在谷歌DC中，工作负载被打包到机器上，在任何时候都尽可能多地使用其物理资源（CPU、带宽、网卡、磁盘空间或其他）。这有时被描述为最大限度地提高服务器密度。

谷歌在使用最先进的技术来实现这一目标方面处于领先地位。容器？协调器？集群调度器？谷歌使用它们已经有几十年了，你可以在这篇2013年的 论文中读到他们用内部管理系统（Borg）所做的事情（tl;dr 谷歌很擅长使用调度来获得对我们为气候所担心的两种资源的最佳利用：电力和硬件）。正如他们所说，"在时间和空间上转移执行灵活的工作负载可以减少对资源和电力的峰值需求。由于数据中心是根据电力和资源使用的峰值来规划的，较小的峰值会减少对更多容量的需求"。

Borg的一个简化版本作为Kubernetes开源了。

所有这些聪明的东西在十年前就疯狂地领先于其他人，但这还不足以实现他们目前的目标，即到2030年实现碳零（他们的运营完全没有碳排放）。要做到这一点，他们需要变得更加聪明。

公认的智慧是，你无法通过调度来解决绿色电力问题，以避免使用化石燃料的电力（即在无风的夜晚不运行你的计算工作）。原因是你有大量的碳投资体现在你的基础设施中，让它闲置也是一种主要的浪费形式。

那么，谷歌在做什么？

时间上的转移

谷歌集群调度的一个重要部分一直是对延迟敏感性的认识，即区分紧急和非紧急工作负载的能力。

例如，打开你的电子邮件是紧急的。如果你不得不等待太长时间，你会使用Outlook。然而，将你的视频上传到YouTube，这涉及到挂着它们被昂贵的转码，并不紧急。有时这需要10分钟，有时需要几个小时。用户可以忍受它。谷歌有一个很好的不同工作的组合，他们的集群调度器利用这种紧迫性的变化来更有效地利用他们的服务器。

超大规模的计算供应商并不是唯一这样做的人。这几乎是物理物流的一个老生常谈，如果客户对交货时间感到放松，事情就会变得更便宜。如果司机可以等待他们的货车加满油，他们就需要更少的行程，他们使用的汽油也更少。然而，即使在这种简单的情况下，也有一个交易--司机和面包车闲置，而客户则错过了更快得到他们的东西。每一个物流决定都取决于你选择优化的内容。

谷歌愿意推迟不太紧急的任务，以便更有效地使用他们的硬件资源，这通常是一个有效的方法，但推迟事情也有一个坏处。如果一小时后迈克尔-杰克逊又死了（有一些不太极端的需求波动的例子），互联网被流量淹没，而你没有任何空闲资源来执行你停放的任务，怎么办？你等待的时间越长，你可以得到更好的优化，但发生意外的事情并把一切都搞砸的几率就越大。

谷歌关于他们最新的物流调度方法的论文描述了 "延迟时间上灵活的工作负载''，但这是他们一直在做的事情，那么有什么新的？他们是否改变了他们的优化对象？

碳智能计算

对谷歌来说，有一件事发生了变化--如果没有足够的低碳强度电力来运行他们的机器，他们就会故意降低服务器的密度。该文件甚至明确提到了关闭机器的问题。

根据该文件，谷歌已经为其数据中心集群建立了新的碳感知能力预测模型（VCC）。这些使绿色电力的可用性成为直流电容量的限制--与缺乏CPU等硬件限制一样。这些模型同时考虑了无碳电力的可用性和需求的预测。也就是说，他们正在共同优化碳足迹和基础设施的效率（他们承认了碳的体现问题）。

好消息是，它成功了。至少在某些地方是这样。论文背后的团队发现，他们的碳意识调度的好处在不同的地方有很大的不同，这取决于当地负载的可预测性，关键是灵活（可推迟）任务的比例。

这正是你所期望的，所以听起来这个计划正在按照设计的方式工作。尽管如此，这些变化并不是改变世界的东西（1-2%的改进），但它们才刚刚开始。

哦，如果迈克尔-杰克逊真的再次死亡，他们计划关闭其预测系统，让系统尽其所能，实时处理当前的情况。你先看到这里，伙计们，流行明星的死亡对环境是不利的。

最终的游戏是什么？

谷歌的目标是在没有多少碳零电力可用的时候，积极减少利用率。万岁!除了有一个来自未充分利用的硬件的碳影响（体现碳）。讨厌!然而，他们似乎很清楚这就是他们需要达成的平衡。

我在想，他们是否在做其他事情来抵消硬件问题。他们是否通过承担更多的调度风险来提高其包装算法的有效性？这可能解释了为什么他们愿意承担效率上的损失。如果他们的工作负载预测模型得到改善，从而提高了他们的总体效率水平，他们就可以摆脱这种影响。我打赌这些模型已经有了--这是ML擅长的事情--而且我认为他们在论文中暗示了这一点。

我猜测他们的策略是让这些正负的利用率延迟相互抵消，其结果是他们硬件的碳体现问题没有恶化，但却减少了碳排放。这将是一个务实的方法。

Kubernetes的问题

那么，这一切与Kubernetes有什么关系，为什么我认为它注定会失败？

Kubernetes作为一个自我管理的协调器，从定义上来说，其范围有限。一家公司一般不会有那么多的任务种类。谷歌自己说："尽管在工作层面存在高度的不确定性，但谷歌在集群层面及以上的灵活资源使用和日常消耗已被证明在一天的预测范围内是相当可预测的。"你没有那么多不同的工作负载，所以你永远不会得到相同的效率水平。

你有什么办法来改善事情吗？我想你可以从你拥有的东西开始工作。把工作分成不灵活的和灵活的工作，这样你就可以更有效地使用调度器。在使用Kubernetes的任何适当规模的操作中，你最终会达到集群级别，虽然你在效率方面所能做的并不是谷歌的补丁，但总比没有好。

然而，即使你投入了所有的努力，并得到了一些体面的利用率数字，在这一点上你会遇到一个新的问题：你需要一个商业服务网。现在，这很糟糕。非常糟糕。像Istio这样的服务网格使用大量的层并产生大量的处理。

云供应商使用他们自己的定制服务网状结构的产品是有原因的--他们已经把它们写得很有效率。公众可用的服务网状结构太通用了，而且能耗很大。我们必须祈祷这种情况在不久的将来会改变，因为服务网状结构是一直开着的--它不是一个灵活的任务--所以它必须是低开销的，但现在的商业产品不是这样。如果Kubernetes需要一个服务网，而它的能源成本很高，那是不可能的。

觉醒吧，死期到了

西雅图2021年是一个警钟。我们可以继续按打盹按钮的次数是有限的，面对现实吧，我们已经达到了这个极限。我们的硬件寿命和零碳电这两个技术问题必须得到解决，而现在离你的政府让你做这件事的时间也不远了。

如果你没有一个计划，那就去做吧。快。我不想打断你，但Kubernetes在这里不是一个计划。现在，它是一个保证失败的计划。

如果你把赌注押在K8上，你将需要更有效的集群调度器和控制平面，你将不得不做一个彻底的工作来分解和标记你自己的任务。这是一个很大的工作，但Kubernetes是一个社区项目，所以你打算怎么做？