这两个因素，使Kubernetes变得如此复杂
发布时间：2022-03-02 00:36:22 所属栏目：云计算 来源：互联网
导读：Anthropic在Kubernetes内运行我们的大部分系统，因此我对该工具积累了更多的经验，对其也更加熟悉。虽然在它真的很棒，但我也确实经历了（大家会普遍经历的）其复杂性和调试的超高难度。 1、为什么Kubernetes这么难? Anthropic在Kubernetes内运行我们的大部
|
Anthropic在Kubernetes内运行我们的大部分系统，因此我对该工具积累了更多的经验，对其也更加熟悉。虽然在它真的很棒，但我也确实经历了（大家会普遍经历的）其复杂性和调试的超高难度。 1、为什么Kubernetes这么难? Anthropic在Kubernetes内运行我们的大部分系统，因此我对该工具积累了更多的经验，对其也更加熟悉。虽然在它真的很棒，但我也确实经历了(大家会普遍经历的)其复杂性和调试的超高难度。 虽然在学习新系统时，这些感觉相当普遍，但Kubernetes确实比我使用过的其他一些系统感觉更大、更可怕、更棘手。在学习并使用它的过程中，我试图理解为什么它看起来是这样的，以及哪些设计决策和权衡导致它成为现在这样。这篇文章尝试写出两种特定的想法，并会解释为什么与Kubernetes一起工作有时会感到棘手。 2、Kubernetes是一个集群操作系统 大家很容易将Kubernetes视为部署容器化应用程序或一些类似功能描述的系统。虽然这可能是一个有用的视角，但我认为将Kubernetes视为通用集群操作系统内核会更合理。这两者之间有何区别? 传统操作系统的工作是使用一台计算机及其所有附属硬件，并公开程序可用于访问该硬件的接口。虽然确切的细节各不相同，但通常这个界面有以下几个目标： 1)资源共享——我们希望将一台物理计算机的资源细分到多个程序中，以便在某种程度上相互隔离。 2)可移植性——我们希望在某种程度上抽象底层硬件的精确细节，以便同一程序可以在不同的硬件上运行，而无需修改或仅进行小幅修改。 3)通用性——当我们想出新型硬件或将新硬件插入计算机时，我们希望能够以增量的方式将这些硬件放入我们的抽象和接口中，建议不要大幅更改任何接口或破坏任何不使用该硬件的现有软件。 4)整体性——与通用性相关，我们希望操作系统调解对硬件的所有访问：软件几乎不可能完全绕过操作系统内核。软件可以使用操作系统内核设置与硬件的直接连接，以便未来的交互直接发生(例如设置内存映射的命令管道)，但初始分配和配置仍在操作系统的保护下。 5)性能——与“直接编写一个专用软件，它直接运行在硬件上，并且对硬件有独占的直接访问权”相比，我们希望为拥有这种抽象支付可接受的小性能成本。在某些情况下，我们希望通过提供I/O调度器或缓存层等优化，在实践中实现比此类系统更高的性能。 虽然“编程的便捷性”通常是一个额外的目标，但在实践中，它往往因为上述担忧而被忽视。操作系统内核通常围绕上述目标进行设计，然后编写用户空间库，将低级、通用、高性能的接口封装到更易于使用的抽象中。操作系统开发人员更关心“在我的操作系统上运行nginx有多快”，而不是“nginx端口到我的操作系统的代码能短多少行?” 我认为Kubernetes在一个非常相似的设计空间中运行;然而，它的目标不是抽象单个计算机，而是抽象整个数据中心或云，或其中的很大一部分。 当然，还有另一个视角： 许多用户认为Kubernetes本质上是“Heroku”，也就是说，Kubernetes本质上是一个部署应用程序的平台，抽象了大多数传统的底层操作系统和分布式系统的细节。 Kubernetes认为自己解决了更接近“CloudFormation”的问题——在某种意义上，它希望足以定义您的整个基础设施—它也试图以比底层云提供商或硬件通用的方式做到这一点。 3、Kubernetes中的所有内容都是一个控制循环 大家可以想象一个十分必要的“集群操作系统”，上文中，它暴露了“分5个CPU的计算能力”或“创建新的虚拟网络”等原语，这些原语反过来又支持系统内部抽象中的配置更改或对EC2 API(或其他底层云提供商)的调用。 Kubernetes作为核心设计决策，并不是这样工作的。相反，Kubernetes做出了核心设计决策，即所有配置都是声明性的，所有配置都是通过作为控制回路的“操作员”实现的：他们不断将所需的配置与现实状态进行比较，然后试图采取行动使现实与所需的状态保持一致。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
