考虑其他编排工具,如dokku,dcos,deis,flynn,docker swarm等.就代码行而言,Kubernetes并不在他们附近,平均而言,这些工具大约是100k-200k代码行.
直观地说,管理容器,即检查健康状况,上下扩展容器,杀死它们,重新启动它们等等,感觉很奇怪.不需要包含2.4M代码行(这是整个操作系统的规模)代码库),我觉得还有更多的东西.
与其他业务流程解决方案相比,Kubernetes有何不同之处?
我不知道维护超过5-6台服务器.请解释为什么它如此之大,哪些功能在其中发挥重要作用.
用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,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
-----------------------------------------------------------------------------------
@H_403_32@
Please note that these are very raw estimations,using cloc. This might be worth a deeper analysis.
粗略地说,似乎该项目占问题中提到的LoC(~1250K LoC)的一半(无论您是否重视依赖性,这是主观的).
什么包含在Kubernetes使它如此之大?
大多数膨胀来自支持各种云提供商的库,以简化其平台上的引导或通过插件支持特定功能(卷等).它还有很多Examples可以从计数中消失.公平的LoC估计需要排除许多不必要的文档和示例目录.
与Docker Swarm,Nomad或Dokku相比,它的功能也更为丰富.它支持高级网络方案,内置负载平衡,包括PetSets,Cluster Federation,卷插件或其他项目尚不支持的其他功能.
它支持多个容器引擎,因此它不是专门运行docker容器,而是可能运行其他引擎(例如rkt).
许多核心逻辑涉及与其他组件的交互:键值存储,插件等,它们远远超出了简单的场景.
众所周知,分布式系统非常困难,Kubernetes似乎支持容器行业主要参与者的大多数工具而不妥协(其他解决方案正在做出这样的妥协).因此,该项目可能看起来人为膨胀,而且对于其核心任务来说太大了(大规模部署容器).实际上,这些统计数据并不令人惊讶.
关键的想法
将Kubernetes与Docker或Dokku进行比较并不合适.该项目的范围要大得多,它包含更多功能,因为它不仅限于Docker系列工具.
虽然Docker的许多功能分散在多个库中,但Kubernetes倾向于将所有内容都放在其核心存储库中(这大大增加了行数,但也解释了项目的受欢迎程度).
考虑到这一点,LoC统计数据并不令人惊讶.