Kubernetes 为什么kubelet启动容器的速度比docker cli慢？

我试图理解，为什么我在pod中的一个容器在由kubelet启动时比直接在GKE节点上通过docker cli启动时启动慢

这是kubelet日志。容器已启动，但在未就绪状态下保持23秒：

18:49:55.000 Container image "eu.gcr.io/proj/ns/myimage@sha256:fff668" already present on machine
18:49:55.000 Created container
18:49:56.000 Started container
18:49:56.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:49:58.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:00.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:02.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:04.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:06.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:08.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:10.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:12.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:14.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:16.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory
18:50:18.000 Readiness probe failed: cat: /tmp/healthy: No such file or directory

最后，容器实际上在23秒后启动。我知道这一点，因为它做的第一件事就是打印下面的日志行，然后为readinessProbe编写/tmp/health文件

18:50:18.000 17:50:18,572|MainThread|INFO|cli|Starting application 

但是，如以下命令所示，打印当前日期，然后使用docker cli启动容器（与上面运行kubelet的节点位于同一节点上），启动容器只需约1秒

mark@gke-cluster-3 ~ $ date ++%Y-%m-%d %H:%M:%S.%N; docker run -it eu.gcr.io/proj/ns/myimage@sha256:fff668
2017-11-25 16:37:01.188799045
2017-11-25 16:37:02,246|MainThread|INFO|cli|Starting application

---

这让我有点发疯了！任何关于是什么导致这种情况的想法都是受欢迎的：）

结果表明，这些容器启动缓慢的问题是启动期间Python解释器的CPU受到限制。我添加了一个bash脚本，它将在启动Python进程之前打印datetime，当改变容器可用的CPU资源时，问题变得非常清楚

cpu: 10m

2017-12-18 08:05:46,1513584346 starting script
2017-12-18 08:06:22,318|MainThread|INFO|cli|Application startup

cpu: 50m

2017-12-18 08:15:11,1513584911 starting script
2017-12-18 08:15:27,317|MainThread|INFO|cli|Application startup

cpu: 100m

2017-12-18 08:07:46,1513584466 starting script
2017-12-18 08:07:53,218|MainThread|INFO|cli|Application startup

cpu: 150m

2017-12-18 08:18:16,1513585096 starting script
2017-12-18 08:18:20,730|MainThread|INFO|cli|Application startup

cpu: 200m

2017-12-18 08:09:14,1513584554 starting script
2017-12-18 08:09:17,922|MainThread|INFO|cli|Application startup

---

这有点令人沮丧，因为应用程序在运行时消耗了大约10m的CPU。我将从这里研究模块导入和其他建议：

我肯定认为通过“kubectl”部署可能会增加一些开销，因为调度和其他附加过程必须通过主节点进行。尽管如此，按照这样一个简单的例子，我没有注意到任何区别。在描述POD或列出集群事件时，您是否获得任何其他信息？此阶段已经进行了调度。注意，我说的是

kubelet

而不是

kubectl

。在我使用kubernetes的经验中，我以前也从未注意到这一点，这就是为什么我对这个特定的容器如此困惑的原因。它可能与您的流程有关，与kubernetes环境变量相结合吗？你知道为什么显示

/tmp/health

需要20秒吗？顺便说一下，这看起来像是你的图像/设置的一个孤立案例。GKE/Kubernetes不需要这么长时间就可以启动一个容器。通常情况下，它在大多数情况下都可以与Docker媲美。@MarkNS嗯，是的，我打赌你能做到，尽管我自己没有做到。尝试使用一个单节点集群，SSH in，找到正确的kubelet标志（-v=10？）编辑kubelet的systemd单元文件systemctl[reload/restart]kubelet.service，请参阅journalctl as sudo。这是一个编程QA站点，与服务器无关。你去服务器故障。