为什么kubernetes源代码比其他容器协调器大一个数量级？
考虑到dokku ， dcos ， deis ， flynn ，docker swarm等其他编排工具.Kubernetes在代码行方面并不在他们的附近，平均来说，这些工具大约有10万到20万行代码。
直觉上感到奇怪的是，pipe理容器即检查健康状况，上下缩放容器，杀死容器，重新启动容器等等。不必包含2.4M +代码行 （这是整个操作系统的规模代码库），我觉得还有更多的东西。
与其他协调解决scheme相比，Kubernetes有什么不同？
我没有维护超过5-6台服务器的任何知识。 请解释它为什么这么大， 什么function在其中扮演重要angular色 。
首先也是最重要的 ：不要被代码中的行数所迷惑，大部分是vendor文件夹中不包含核心逻辑（ 实用程序，客户端库，gRPC，etcd等）的依赖关系 。
原始LoC分析与cloc
对于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模式，因为这包括更多的function，如卷，networking和插件，这些库不包括在这些库中）。 我们不包括像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 ）的一半（无论你是否重视依赖性，这是主观的）。
Kubernetes包含什么使它如此之大？
大部分膨胀来自支持各种云提供商的图书馆，以减轻其平台上的引导或通过插件支持特定的function（卷等）。 它也有很多 例子来排除行数。 一个公平的LoC估计需要排除大量不必要的文档和示例目录。
与Docker Swarm ， Nomad或Dokku相比，它的function也更加丰富 。 它支持高级networkingscheme，内置负载平衡，包括PetSets ， 群集联合 ，卷插件或其他项目不支持的其他function。
它支持多个容器引擎 ，所以它不是专门运行docker容器，但可能运行其他引擎（如rkt ）。
许多核心逻辑涉及到与其他组件的交互：键值存储，客户端库，插件等，它们远远超出了简单的场景。
分布式系统是非常艰难的 ，而Kubernetes似乎支持大多数集装箱行业的主要参与者的工具，而没有妥协（其他解决scheme正在做出这样的妥协）。 因此，该项目的核心任务（大规模部署集装箱）可能会出现人为膨胀和过大的情况。 实际上，这些统计数据并不令人惊讶。
主要思想
将Kubernetes与Docker或Dokku进行比较并不合适。 该项目的范围要大得多，它包含更多的function，因为它不限于Docker系列的工具。
虽然Docker的许多function分散在多个库中，但Kubernetes往往将所有内容都放在其核心存储库下（这大大增加了线数，但也解释了该项目的受欢迎程度）。
考虑到这一点，LoC统计并不令人惊讶。
除了@abronan给出的理由之外，Kubernetes代码库还包含大量的重复和生成的文件，这些文件将人为地增加代码的大小。 代码“实际工作”的实际大小要小得多。
例如，看看暂存目录 。 这个目录是500,000 LOC，但没有任何内容是原始代码; 它全部从Kubernetes回购的其他地方复制并重新排列。 这人为地膨胀了总LOC。
Swagger API也是一些自动生成的文件，用于描述OpenAPI格式的Kubernetes API。 以下是我find这些文件的一些地方：
-
kubernetes / API /
-
kubernets /联合会/的API /招摇规格
-
kubernetes /联合会/的API / OpenAPI的规格
这些文件一起占了约116,000 LOC，他们所做的只是描述OpenAPI格式的Kubernetes API！
这些只是OpenAPI定义文件 – 支持OpenAPI所需的LOC总数可能要高得多。 例如，我发现了一个约12,000个LOC文件和一个约13,000个与支持Swagger / OpenAPI相关的LOC文件 。 我相信还有更多的文件与这个function相关。
重点是在后台进行实际繁重的代码可能只是使Kubernetes成为可维护和可扩展项目所需的支持代码的一小部分。