创建Google容器引擎群集后，Container Engine会创建一个Compute Engine托管实例组来管理创建的实例。这些实例来自Google Compute引擎，这意味着它们是虚拟机。
但我们在doc页面中读到：＆＃34; VM是重量级的，不可移植的。新方法是基于操作系统级虚拟化而不是硬件虚拟化来部署容器。不是矛盾吗？如果我错了，请纠正我。 我们使用容器因为它们与VM相比非常快（无论是在启动时还是执行任务），并且它们节省了大量的空间存储。因此，如果我们有一个节点（vm）可以支持最多4个容器，我们的客户可以快速午餐4个容器，但超过这个数量，gcloud autoscaler将需要在新节点（vm）午餐以支持即将到来的容器，这会产生一些任务延迟。
是否无法在物理机器上启动容器？
您建议如何运行关键时间执行任务？
答案 0 :(得分：3)
绝对可以在物理机器上启动容器。实际上，根据Borg paper（其设计对Container Engine / Kubernetes的影响很大），这是Google自身基础架构的标准：
每个任务映射到一个容器上运行的一组Linux进程 机器[62]。绝大多数Borg工作负载都没有运行 内部虚拟机（VM），因为我们不想支付成本 虚拟化。此外，该系统是在我们拥有的时候设计的 对没有虚拟化支持的处理器进行大量投资 在硬件中。
由于Container Engine托管在GCP中，因此VM用于促进动态配置。但是，与计划在其上的容器的生命周期相比，这些VM的使用寿命很长。可以在这些VM上安排容器的容器，并且可以完成作业。但是，在升级或重新调整群集时，VM会被拆除。
答案 1 :(得分：1)
Kubernetes可以安装在虚拟机和物理机上（有multiple getting started guides for bare metal）。谷歌的云平台仅提供虚拟机即服务，这就是为什么谷歌容器引擎建立在虚拟机之上的原因。