为什么kubernetes源代码比其他容器编排器大一个数量级？

Question

考虑到其他编配工具，如杜库、dcos、deis、弗林、码头群等。就代码行而言，Kubernetes并不接近它们，平均而言，这些工具大约是100 k-200 k代码行。

直觉上感到奇怪的是，管理容器，即检查容器的健康状况，上下缩放容器，杀死它们，重新启动它们等等。不需要包含2.4M+代码行(这是整个操作系统代码库的规模)，我觉得它还有更多的东西。

与其他使其如此庞大的编排解决方案相比，Kubernetes有什么不同？

我没有任何知识来维护超过5-6台服务器。请解释为什么它这么大，什么功能在其中起着很大的作用。

Answer 1

首先也是最重要的：不要被代码中的行数误导，大部分是vendor文件夹中不考虑核心逻辑的依赖项(实用程序、客户端库、gRPC等)。

用cloc进行原始LoC分析

对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 (而不是群集或群集模式，因为它包含了更多的特性，如卷、网络和插件，这些都不包括在这些存储库中)。我们不包括像机器、撰写、like这样的项目，因此实际上整个对接平台可能包含更多的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 of 示例，可以从行计数中剔除。公平的LoC估计需要排除大量不必要的文档和示例目录。

它也是功能更丰富的比码头群，游牧或Dokku的几个例子。它支持高级网络场景，具有负载平衡内置，包括PetSets、集群联合会、卷插件或其他其他项目还不支持的特性。

它支持多个容器引擎，因此它不仅可以运行码头容器，还可以运行其他引擎(例如rkt)。

许多核心逻辑涉及到与其他组件的交互:键值存储、客户端库、插件等等，这远远超出了简单的场景。

分布式系统是出了名的困难，Kubernetes似乎不妥协地支持容器行业的关键参与者提供的大多数工具(其他解决方案正在做出这样的妥协)。因此，这个项目看起来像是人为的臃肿的，对于它的核心任务来说太大了(按比例部署容器)。事实上，这些统计数字并不令人惊讶。

关键思想

把库伯奈特和道克或杜库进行比较是不合适的。该项目的范围要大得多，而且它包含了更多的特性，因为它不局限于Docker系列的工具。

虽然Docker有很多特性分散在多个库中，但是Kubernetes的核心存储库中有所有的东西(这大大增加了行数，但也解释了项目的流行程度)。

考虑到这一点，LoC的统计数据并不那么令人惊讶。

Answer 2

除了@abronan给出的原因外，Kubernetes代码库还包含大量复制和生成的文件，这将人为地增加代码大小。执行“实际工作”的代码的实际大小要小得多。

例如，看看分期目录。这个目录是500,000 LOC，但是没有原始代码；它都是从Kubernetes回购和重新排列的其他地方复制的。这人为地膨胀了整个LOC。

还有一些东西，比如Swagger生成，它们是自动生成的文件，以OpenAPI格式描述Kubernetes。以下是一些我发现这些文件的地方：

• kubernetes/api/
• Kubernetes/federation/apis/swagger-spec
• kubernetes/federation/apis/openapi-spec

这些文件共占116000 LOC，它们所做的就是用OpenAPI格式描述Kubernetes！

这些只是OpenAPI定义文件--支持OpenAPI所需的LOC总数可能要高得多。例如，我发现了一个~12,000 LOC文件和一个与支持Swagger/OpenAPI相关的~13,000 LOC文件。我相信还有更多与此特性相关的文件。

关键是，在幕后执行实际繁重工作的代码可能是使Kubernetes成为一个可维护和可伸缩项目所需的支持代码的一小部分。