作者 | 丁广辉 责编 | 张红月
出品 | CSDN（ID：CSDNnews）
这几年云原生的热度久高不下 ， 许多大厂纷纷拥抱云原生 。 提到云原生 ， 不少开发者可能会想到Kubernetes ， 也称为K8s ， 是一个用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统 。 作为云原生的重要代表之一 ， 它真的很不错 。 但也有不少开发者抱怨Kubernetes太复杂了 。
近日 ， 在国外知名的技术论坛网站Hacker News上 ， 就有一位用户对Kubernetes为什么这么复杂做出了自己的见解 。
为什么Kubernetes这么复杂？
Kubernetes相比其他系统来说 ， 确实要更大 ， 更复杂 。 相信不少人在使用它的过程中都曾试图了解它为什么这样 。 该用户也是这样 ， 并将自己的理解写了出来 。
Kubernetes是一个集群操作系统
Kubernetes更像是一个通用的集群操作系统内核 。 传统操作系统的工作是将一台计算机及其所有相关硬件的接口暴露出来 ， 让应用程序可以访问这些接口 。 具体细节我们不明确 ， 但这些接口都有相应的设计目标 。

• 资源共享——将一台物理计算机的资源细分给多个程序 ， 使它们在某种程度上相互隔离；
• 可移植性——在一定程度上抽象出底层硬件的精确细节 ， 这样同一程序就可以在不同的硬件上运行而无需修改 ， 或者只需稍加修改；
• 通用性——当有新的硬件插入计算机时 ， 能够以渐进的方式将这些硬件纳入抽象和接口 ， 最好是在不大幅改变任何接口或破坏任何不使用该硬件的现有软件的情况下 。
• 整体性——与通用性相关 ， 操作系统能够调解对硬件的所有访问：软件应该很少或者不可能完全绕过操作系统的内核 。 软件可以使用操作系统内核来建立与硬件的直接连接 ， 从而使未来的交互直接发生（例如建立一个内存映射的命令管道） ， 但最初的分配和配置仍然在操作系统的监督之下 。
• 性能——与 "直接编写一个特殊用途的软件 ， 直接在硬件上运行 ， 并对硬件有独占的直接访问权（如unikernel）”相比 ， 希望拥有这种一个可接受的小的性能成本 。 在某些情况下 ， 通过提供像I/O调度器或缓存层这样的优化 ， 在实践中达到比这样的系统更高的性能 。

操作系统内核通常是围绕上述目标设计 ， 然后编写用户空间库 ， 将低级的、通用的、高性能的接口包装成更容易使用的抽象概念 。 操作系统开发者往往更关心的是怎么让应用运行的更快 ， 而不是应用在我的系统上运行时代码更少 。
Kubernetes与上述设计理念非常类似 ， 它的目标是抽象出一整个数据中心或云 。 这个观点有助于理解Kubernetes 。 它指出了Kubernetes为什么非常灵活 。 Kubernetes希望自己能拥有普遍性并获得更强大的功能 ， 它能够在任何类型的硬件或虚拟机实例上部署任何类型的应用程序 。 并且还不需要脱离Kubernetes的界面 。 不论它是否真的能实现这一目标 ， 这样的设计都很有意义 。
上述视角所解释的设计选择是Kubernetes的可插拔性和可配置性 。 一般来说 ， 在不付出奢侈的性能成本下 ， 做不到对所有人都适用的选择 。 在现代云环境中 ， 应用程序的类型和部署的硬件类型有很大不同 ， 尤其是要求可以在不同位置快速部署时 。 这也就意味着 ， 如果一个系统想让所有人都适用 ， 它就需要强大的快速配置性能 。 做到这一点确实会搭建出一个强大的系统 ， 但缺点就是它会变得非常复杂 。
许多用户认为Kubernetes本质上是一个“Heroku” ， 即作为一个部署应用程序的平台 ， 去抽象出大多数传统的底层操作系统和分布式系统的细节 。 Kubernetes认为自己解决的问题更接近于 "CloudFormation" ， 在这个意义上 ， 它希望足以定义整个基础设施 ， 它还试图以一种在底层云提供商或硬件上都通用的方式做到这一点 。