我们的应用程序包含大约20个模块 . 每个模块都包含一个（Helm）图表，其中包含多个部署，服务和作业 . 其中一些作业被定义为Helm预安装和升级前挂钩 . 总共可能有大约120个yaml文件，最终导致大约50个正在运行的pod .
在开发过程中，我们使用Docker 18.09.0-ce-beta1和Kubernetes 1.10.3运行Docker for Windows版本2.0.0.0-beta-1-win75 . 为了简化我们的Kubernetes yaml文件的管理，我们使用Helm 2.11.0 . Docker for Windows配置为使用2个CPU核心（4个）和8GB RAM（24GB） .
When creating the application environment for the first time, it takes more that 20 minutes to become available. This seems far to slow; we are probably making an important mistake somewhere. We have tried to improve the (re)start time, but to no avail. Any help or insights to improve the situation would be greatly appreciated.
我们的启动脚本的简化版本：
#!/bin/bash
# Start some infrastructure
helm upgrade --force --install modules/infrastructure/chart
# Start ~20 modules in parallel
helm upgrade --force --install modules/module01/chart &
[...]
helm upgrade --force --install modules/module20/chart &
await_modules()
稍后再次执行相同的启动脚本以“重启”应用程序仍需要大约5分钟 . 据我所知，Kubernetes根本不会修改未更改的对象 . Helm只运行大约40个钩子 .
使用 docker run 手动运行单个挂钩很快（约3秒） . 通过Helm和Kubernetes运行相同的钩子需要15秒或更长时间 .
我们发现并尝试过的一些内容如下所示 .
Linux登台环境
我们的暂存环境包括Ubuntu和本机Docker . Kubernetes通过minikube安装 --vm-driver none .
与我们的本地开发环境相反，登台环境通过（已弃用的） gitRepo 卷检索应用程序代码，几乎用于每个部署和作业 . 可以理解，这似乎只会使问题恶化 . 首次启动环境需要25分钟，重启大约需要20分钟 .
我们尝试使用sidecar容器替换 gitRepo 卷，该容器将应用程序代码检索为TAR . 虽然我们没有修改整个应用程序，但初始测试表明这并不比 gitRepo 卷快得多 .
使用可在部署和作业之间共享代码的替代类型的卷可能会改善这种情况 . 但是，我们宁愿不引入更多复杂性，因此我们还没有进一步探索这一途径 .
Docker运行时间
通过 docker run alpine echo "test" 执行一个空的高山容器大约需要2秒钟 . 这似乎是Windows上安装的开销 . 同样的命令在我们的Linux登台环境中花费的时间少于0.5秒 .
Docker卷共享
大多数容器 - 包括钩子 - 通过 hostPath 与主机共享代码 . 命令 docker run -v <host path>:<container path> alpine echo "test" 需要3秒才能运行 . 使用卷似乎可以大约1秒钟增加运行时间 .
并行或顺序
在启动脚本中顺序执行命令不会缩短启动时间 . 它也没有急剧恶化 .
IO绑定？
Windows taskmanager指示执行启动脚本时IO为100％ . 我们的钩子和应用程序代码根本不是IO密集型的 . 所以IO负载似乎来自Docker，Kubernetes或Helm . 我们试图找到瓶颈，但无法查明原因 .
通过ramdisk减少IO
为了测试IO进一步绑定的前提，我们在Linux登台环境中将 /var/lib/docker 与ramdisk交换 . 使用此配置启动应用程序的速度并不快 .
1 回答
要将Kubernetes与Docker进行比较，您需要考虑Kubernetes将在最后一步运行或多或少相同的Docker命令 . 在此之前，很多事情都在发生 . 身份验证和授权过程，在etcd中创建对象，为调度它们的pod配置正确的节点以及配置存储等等 . Helm本身也会根据图表的大小增加流程的开销 .
我建议阅读One year using Kubernetes in production: Lessons learned . 作者通过切换到Kubernetes以及开销差异来解释他们取得了什么成果：