为什么 kubernetes 源代码比其他容器编排器大一个数量级？
Why is kubernetes source code an order of magnitude larger than other container orchestrators?
考虑其他编排工具，如 dokku, dcos, deis, flynn、docker swarm 等。Kubernetes 在代码行数方面远不及它们，这些工具平均在 100k-200k 左右代码行。
直觉上管理容器感觉很奇怪，即检查运行状况、放大和缩小容器、杀死它们、重新启动它们等等。不必包含 2.4M+ 行代码（这是整个操作系统代码库的规模），我觉得它还有更多的东西。
与其他编排解决方案相比，Kubernetes 有何不同之处使其如此庞大？
我对维护超过 5-6 台服务器一无所知。请解释为什么它这么大，哪些功能在其中发挥了重要作用。
首要：不要被代码行数误导，大部分是vendor文件夹里的依赖，不占对于核心逻辑（实用程序、客户端库、gRPC、etcd、 等）。
使用 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（而不是 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
-----------------------------------------------------------------------------------
Please note that these are very raw estimations, using cloc. This might be worth a deeper analysis.
粗略看来，项目占问题中提到的LoC（~1250K LoC）的一半（是否重视依赖，这是主观的）。
Kubernetes 中包含什么使其如此庞大？
大多数 膨胀 来自支持各种云提供商的库，以简化其平台上的引导或通过插件支持特定功能（卷等）。它还有一个 Lot of Examples 可以从行数中排除。一个公平的 LoC 估计需要排除大量不必要的文档和示例目录。
与 Docker Swarm、Nomad[=70 相比，功能更丰富 =] 或 Dokku 举几个例子。它支持高级网络方案，内置负载平衡，包括 PetSets, Cluster Federation、卷插件或其他项目尚不支持的其他功能。
它支持多个容器引擎，因此它不只是运行宁docker个容器，而且可能运行其他引擎（例如作为 rkt).
许多核心逻辑涉及与其他组件的交互：Key-Value 存储、客户端库、插件等，这远远超出了简单的场景。
分布式系统是出了名的难，而 Kubernetes 似乎毫不妥协地支持容器行业主要参与者的大部分工具（其他解决方案正在做出这种妥协）。因此，该项目可能看起来人为 臃肿 并且对于其核心任务（大规模部署容器）来说太大了。事实上，这些统计数据并不令人惊讶。
核心思想
将 Kubernetes 与 Docker 或 Dokku 进行比较并不是很合适。该项目的范围要大得多，它包含更多的功能，因为它不仅限于 Docker 系列工具。
虽然 Docker 的许多功能分散在多个库中，但 Kubernetes 倾向于将所有内容都放在其核心存储库中（这大大增加了行数，但也解释了该项目的受欢迎程度）。
考虑到这一点，LoC 统计数据并不令人惊讶。
除了@abronan 给出的原因外，Kubernetes 代码库包含大量重复和生成的文件，这些文件会人为地增加代码大小。执行“实际工作”的代码的实际大小要小得多。
例如，看看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 and a ~13,000 LOC file。我敢肯定还有很多与此功能相关的文件。
关键是，在幕后执行实际繁重工作的代码可能只是使 Kubernetes 成为可维护和可扩展项目所需的支持代码的一小部分。
考虑其他编排工具，如 dokku, dcos, deis, flynn、docker swarm 等。Kubernetes 在代码行数方面远不及它们，这些工具平均在 100k-200k 左右代码行。
直觉上管理容器感觉很奇怪，即检查运行状况、放大和缩小容器、杀死它们、重新启动它们等等。不必包含 2.4M+ 行代码（这是整个操作系统代码库的规模），我觉得它还有更多的东西。
与其他编排解决方案相比，Kubernetes 有何不同之处使其如此庞大？
我对维护超过 5-6 台服务器一无所知。请解释为什么它这么大，哪些功能在其中发挥了重要作用。
首要：不要被代码行数误导，大部分是vendor文件夹里的依赖，不占对于核心逻辑（实用程序、客户端库、gRPC、etcd、 等）。
使用 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（而不是 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
-----------------------------------------------------------------------------------
Please note that these are very raw estimations, using cloc. This might be worth a deeper analysis.
粗略看来，项目占问题中提到的LoC（~1250K LoC）的一半（是否重视依赖，这是主观的）。
Kubernetes 中包含什么使其如此庞大？
大多数 膨胀 来自支持各种云提供商的库，以简化其平台上的引导或通过插件支持特定功能（卷等）。它还有一个 Lot of Examples 可以从行数中排除。一个公平的 LoC 估计需要排除大量不必要的文档和示例目录。
与 Docker Swarm、Nomad[=70 相比，功能更丰富 =] 或 Dokku 举几个例子。它支持高级网络方案，内置负载平衡，包括 PetSets, Cluster Federation、卷插件或其他项目尚不支持的其他功能。
它支持多个容器引擎，因此它不只是运行宁docker个容器，而且可能运行其他引擎（例如作为 rkt).
许多核心逻辑涉及与其他组件的交互：Key-Value 存储、客户端库、插件等，这远远超出了简单的场景。
分布式系统是出了名的难，而 Kubernetes 似乎毫不妥协地支持容器行业主要参与者的大部分工具（其他解决方案正在做出这种妥协）。因此，该项目可能看起来人为 臃肿 并且对于其核心任务（大规模部署容器）来说太大了。事实上，这些统计数据并不令人惊讶。
核心思想
将 Kubernetes 与 Docker 或 Dokku 进行比较并不是很合适。该项目的范围要大得多，它包含更多的功能，因为它不仅限于 Docker 系列工具。
虽然 Docker 的许多功能分散在多个库中，但 Kubernetes 倾向于将所有内容都放在其核心存储库中（这大大增加了行数，但也解释了该项目的受欢迎程度）。
考虑到这一点，LoC 统计数据并不令人惊讶。
除了@abronan 给出的原因外，Kubernetes 代码库包含大量重复和生成的文件，这些文件会人为地增加代码大小。执行“实际工作”的代码的实际大小要小得多。
例如，看看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 and a ~13,000 LOC file。我敢肯定还有很多与此功能相关的文件。
关键是，在幕后执行实际繁重工作的代码可能只是使 Kubernetes 成为可维护和可扩展项目所需的支持代码的一小部分。