创建Google Container Engine集群后，Container Engine将创建一个Compute Engine管理的实例组来管理创建的实例。这些实例来自Google Compute引擎，这意味着它们是虚拟机。
但是我们在doc页面中读到:“VM重量很重且不可移植。新方法是基于操作系统级虚拟化而不是硬件虚拟化部署容器”不是矛盾吗？如果我错了纠正我。
我们之所以使用容器，是因为与VM相比，它们的运行速度非常快(无论是在启动时还是在执行任务方面)，而且它们还节省了大量空间。因此，如果我们有一个最多可支持4个容器的节点(vm)，我们的客户可以迅速吃掉4个容器，但是超过这个数目，gcloud autoscaler将需要吃一个新节点(vm)来支持即将到来的容器，这会产生一些任务延迟。
在物理机器上启动容器是不可能的吗？
您对运行关键时间执行任务有何建议？
最佳答案
肯定有可能在物理机上启动容器。实际上，根据Borg paper(其设计对Container Engine / Kubernetes的影响很大)，这是Google自己的基础架构中的规范:
Each task maps to a set of Linux processes running in a container on a machine [62]. The vast majority of the Borg workload does not run inside virtual machines (VMs), because we don’t want to pay the cost of virtualization. Also, the system was designed at a time when we had a considerable investment in processors with no virtualization support in hardware.
由于容器引擎托管在GCP内，因此使用VM来促进动态配置。但是，与计划在其上的容器的生存期相比，这些VM的生存期很长。可以在这些VM的上/下计划容器的容器，然后作业完成。但是，在升级或调整群集大小时，VM将被拆除。
关于google-app-engine - 有关Google容器集群内使用的节点的困惑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/36094638/