在什么情况下更适合使用Google Container Engine而不是App Engine Flexible?
它们是不同的东西。App Engine Flexible专注于应用程序开发 - 也就是说,你有一个应用程序并希望由Google部署和管理。另一方面,Kubernetes更多地关注拥有自己的基础设施。显然,您也可以在Kubernetes中部署应用程序,但由于它是您“自己”的基础设施,所以您需要直接管理如何使两者以及应用程序行为(创建服务、创建可扩展性策略、RBAC、安全策略等)。
从这个意义上说,Kubernetes更灵活,您可以实现更多。但是,作为开发人员,您可能根本不关心基础架构,只想确保您的应用程序能够正常工作和扩展。对于这种类型的用户,App Engine Flexible更适合。
如果您希望管理完整的容器基础架构(更适合SRE配置文件),那么Kubernetes就是您的选择。
但这并不意味着App Engine就不强大了。我曾经使用过App Engine(标准和灵活环境)开发过复杂应用程序,为数十万(现在可能是百万级别)的用户提供服务,我们从来没有考虑过将其迁移出GAE。我的意思是,如果它可以处理Pokemon Go的流量,那么它肯定也能处理您的应用程序。
性能方面,有人在这里进行了比较。总结结果如下 -
两种服务之间的一个重要差异是,App Engine Flex更加偏向于Google的自动化控制,而Kubernetes Engine则需要客户更多的监督。Kubernetes Engine正在快速发展,并添加了更强大的自动化功能。
一个微妙的区别是,Flex使用容器作为手段。通常,Flex的用户可以忽略容器被使用的事实,因为这是在幕后完成的。Kubernetes Engine - 顾名思义 - 基于容器,并明确设计为一种工具,以便于管理基于容器构建的服务。对于Flex,一个服务始终是相同类型的n个容器。对于Kubernetes Engine,一个服务由m个pod组成,而这些pod本身可能包含p个容器。
- 将App Engine Flex部署迁移到GKE是可行的
- 在这种情况下,Flex比GKE实现了更大的吞吐量。
- 增加的速度似乎是由App Engine能够快速发出自动扩展事件的快速性所致;GKE会在现有节点集群内迅速缩放pod,但稍微慢一些来扩展节点数。
- App Engine和GKE共享基本的GCP资源,包括HTTP/S负载均衡器服务和管理基础设施组自动扩展。
- 对于相同的负载,使用相同的VM大小(1 vCPU和1GB RAM):App Engine Flex在6个实例VM上(每个VM 1个实例)扩展为6个容器;GKE在3个VM(50%)上扩展为10个Pod(每个Pod 1个容器)。