docker - 通过 Helm 缓慢安装/升级(针对 Kubernetes)

Question

我们的应用程序由大约 20 个模块组成。每个模块都包含一个 (Helm) 图表，其中包含多个部署、服务和作业。其中一些作业被定义为 Helm 预安装和预升级 Hook 。总共可能有大约 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)。

首次创建应用程序环境时，需要超过 20 分钟才能可用。这似乎很慢；我们可能在某个地方犯了一个重要错误。我们试图改善(重新)开始时间，但无济于事。任何有助于改善这种情况的帮助或见解将不胜感激。

我们的启动脚本的简化版本:

#!/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 个钩子(Hook)。

使用 docker run 手动运行单个 Hook 很快(约 3 秒)。通过 Helm 和 Kubernetes 运行相同的钩子(Hook)通常需要 15 秒或更长时间。

下面列出了我们发现和尝试的一些事情。

Linux 暂存环境

我们的暂存环境由带有 native Docker 的 Ubuntu 组成。 Kubernetes 通过 minikube 安装，--vm-driver none .

与我们的本地开发环境相反，暂存环境通过(已弃用)gitRepo 检索应用程序代码。几乎每个部署和作业的容量。可以理解的是，这似乎只会使问题恶化。首次启动环境需要 25 多分钟，重新启动大约需要 20 分钟。

我们尝试替换 gitRepo带有一个 sidecar 容器的卷，该容器将应用程序代码作为 TAR 检索。虽然我们没有修改整个应用程序，但初步测试表明这并不比 gitRepo 快。体积。

这种情况可能可以通过另一种类型的卷来改善，该卷允许在部署和作业之间共享代码。不过，我们宁愿不引入更多的复杂性，所以我们没有进一步探索这条途径。

docker 运行时间

通过 docker run alpine echo "test" 执行单个空 alpine 容器大约需要 2 秒。这似乎是 Windows 上设置的开销。在我们的 Linux 暂存环境中，同样的命令只需要不到 0.5 秒的时间。

Docker 卷共享

大多数容器——包括钩子(Hook)——通过 hostPath 与主机共享代码。 .命令docker run -v <host path>:<container path> alpine echo "test"运行需要 3 秒。使用卷似乎增加了大约 1 秒的运行时间。

并行或顺序

启动脚本中命令的顺序执行不会缩短启动时间。它也没有急剧恶化。

IO绑定(bind)？

Windows 任务管理器在执行启动脚本时指示 IO 处于 100%。我们的钩子(Hook)和应用程序代码根本不是 IO 密集型的。所以 IO 负载似乎来自 Docker、Kubernetes 或 Helm。我们试图找到瓶颈，但无法查明原因。

通过ramdisk减少IO

为了进一步测试IO绑定(bind)的前提，我们交换了/var/lib/docker在我们的 Linux 暂存环境中使用 ramdisk。使用此配置启动应用程序并没有明显加快。

Answer 1

要将 Kubernetes 与 Docker 进行比较，您需要考虑到 Kubernetes 将在最后一步运行或多或少相同的 Docker 命令。在此之前，许多事情正在发生。
身份验证和授权过程，在 etcd 中创建对象，为 pod 定位正确的节点以调度它们并提供存储等等。
根据图表的大小，Helm 本身也会增加流程的开销。

我推荐阅读One year using Kubernetes in production: Lessons learned .作者解释了他们通过切换到 Kubernetes 所取得的成就以及开销的差异:

Cost calculation

Looking at costs, there are two sides to the story. To run Kubernetes, an etcd cluster is required, as well as a master node. While these are not necessarily expensive components to run, this overhead can be relatively expensive when it comes to very small deployments. For these types of deployments, it’s probably best to use a hosted solution such as Google's Container Service.

For larger deployments, it’s easy to save a lot on server costs. The overhead of running etcd and a master node aren’t significant in these deployments. Kubernetes makes it very easy to run many containers on the same hosts, making maximum use of the available resources. This reduces the number of required servers, which directly saves you money. When running Kubernetes sounds great, but the ops side of running such a cluster seems less attractive, there are a number of hosted services to look at, including Cloud RTI, which is what my team is working on.