考虑其他编排工具，例如dokku，dcos，deis，flynn，docker swarm等。就代码行而言，Kubernetes并不在他们附近，平均而言这些工具是大约100k-200k行代码。
直观地说，管理容器即检查健康状况，上下扩展容器，杀死它们，重新启动它们等等感觉很奇怪。不必包含 2.4M +代码行 （这是整个操作系统代码库的规模），我觉得还有更多的东西。
与其他业务流程解决方案相比，Kubernetes有什么不同呢？
我不知道维护超过5-6台服务器。请解释为什么它如此之大，哪些功能在其中扮演重要角色。
答案 0 :(得分：11)
首先：不要被代码中的行数误导，大多数都是vendor文件夹中不考虑核心逻辑的依赖项（ 实用程序，客户端库，gRPC，等等，等。）。
为了解决问题，对于 Kubernetes ：
$ cloc kubernetes --exclude-dir=vendor,_vendor,build,examples,docs,Godeps,translations
7072 text files.
6728 unique files.
1710 files ignored.
github.com/AlDanial/cloc v 1.70 T=38.72 s (138.7 files/s, 39904.3 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
Go 4485 115492 139041 1043546
JSON 94 5 0 118729
HTML 7 509 1 29358
Bourne Shell 322 5887 10884 27492
YAML 244 374 508 10434
JavaScript 17 1550 2271 9910
Markdown 75 1468 0 5111
Protocol Buffers 43 2715 8933 4346
CSS 3 0 5 1402
make 45 346 868 976
Python 11 202 305 958
Bourne Again Shell 13 127 213 655
sed 6 5 41 152
XML 3 0 0 88
Groovy 1 2 0 16
--------------------------------------------------------------------------------
SUM: 5369 128682 163070 1253173
--------------------------------------------------------------------------------
对于 Docker （而不是Swarm或Swarm模式，因为这包括更多功能，如卷，网络和插件，这些功能未包含在这些存储库中）。我们不包括 Machine ， Compose ， libnetwork 等项目，所以实际上整个docker平台可能包含更多的LoC：
$ cloc docker --exclude-dir=vendor,_vendor,build,docs
2165 text files.
2144 unique files.
255 files ignored.
github.com/AlDanial/cloc v 1.70 T=8.96 s (213.8 files/s, 30254.0 lines/s)
-----------------------------------------------------------------------------------
Language files blank comment code
-----------------------------------------------------------------------------------
Go 1618 33538 21691 178383
Markdown 148 3167 0 11265
YAML 6 216 117 7851
Bourne Again Shell 66 838 611 5702
Bourne Shell 46 768 612 3795
JSON 10 24 0 1347
PowerShell 2 87 120 292
make 4 60 22 183
C 8 27 12 179
Windows Resource File 3 10 3 32
Windows Message File 1 7 0 32
vim script 2 9 5 18
Assembly 1 0 0 7
-----------------------------------------------------------------------------------
SUM: 1915 38751 23193 209086
-----------------------------------------------------------------------------------
请注意，使用 cloc 这些是非常原始的估算值。这可能值得深入分析。
粗略地说，似乎该项目占问题中提到的LoC（ ~1250K LoC ）的一半（无论您是否重视依赖关系，这是主观的）。
大多数膨胀来自支持各种云提供商的库，以简化其平台上的引导或通过插件支持特定功能（卷等）。它还有一个 Lot Examples来排除行数。公平的LoC估计需要排除许多不必要的文档和示例目录。
与 Docker Swarm ， Nomad 或 Dokku 相比， 功能更强大引用了一些。它支持高级网络方案，内置负载平衡，包括PetSets，Cluster Federation，卷插件或其他项目尚不支持的其他功能。它支持多个容器引擎，因此它不是专门运行docker容器，而是可能运行其他引擎（例如 rkt ）。
许多核心逻辑涉及与其他组件的交互：键值存储，客户端库，插件等，它们远远超出了简单的场景。
分布式系统非常难以， Kubernetes 似乎支持容器行业主要参与者的大部分工具而不妥协（其他解决方案正在做出这样的妥协） ）。因此，该项目可以人为地看起来臃肿，而且对于其核心任务来说太大了（大规模部署容器）。实际上，这些统计数据并不令人惊讶。
将 Kubernetes 与 Docker 或 Dokku 进行比较并不合适。该项目的范围要大得多，它包含更多功能，因为它不仅限于Docker系列工具。
虽然Docker的许多功能分散在多个库中，但Kubernetes倾向于将所有内容都放在其核心存储库中（这大大增加了行数，但也解释了项目的受欢迎程度）。
考虑到这一点，LoC统计数据并不令人惊讶。
答案 1 :(得分：4)
除了@abronan给出的理由之外，Kubernetes代码库包含大量重复和生成的文件，这些文件会人为地增加代码大小。实际工作的代码的实际大小＆＃34;要小得多。
例如，请查看staging directory。这个目录是500,000 LOC，但没有原始代码;它全部从Kubernetes仓库的其他地方复制并重新排列。这会人为地膨胀整个LOC。
还有像Swagger API生成这样的东西，它们是自动生成的文件，以OpenAPI格式描述Kubernetes API。以下是我找到这些文件的地方：
这些文件共计~116,000 LOC，他们所做的就是用OpenAPI格式描述Kubernetes API！
这些只是OpenAPI定义文件 - 支持OpenAPI所需的LOC总数可能要高得多。例如，我找到了与支持Swagger / OpenAPI相关的〜12,000 LOC file和~13,000 LOC file。我确信还有更多与此功能相关的文件。
重点是，在幕后进行实际繁重工作的代码可能只是使Kubernetes成为可维护和可扩展项目所需的支持代码的一小部分。