Azure、AWS、Google，三大云厂商k8s服务大PK

如果您是企业开发/运维人员，或是IT爱好者，那您一定对Kubernetes —— k8s服务有所耳闻。

一句话概括k8s， 它是一个能对容器化应用进行自动化部署、弹性伸缩和管理的开源容器平台。

自2013年Docker兴起，Mesos起势，到现在这一拥有舵手logo的Kubernetes一统容器天下，k8s在IT汪洋中开辟了一条新的航道，它的目标不仅仅是成为一个编排系统，更是提供了一个规范和框架去描述集群的架构，去维持服务的状态，去构建云原生应用——k8s基本上是一种可以部署任何复杂应用的平台服务。

eBay和16年开始火爆全球的Pokémon Go便是基于k8s的，Twitter正在从Mesos迁到k8s，还有京东(OpenStack转k8s)，蚂蚁金服，中国联通，网易(网易团队报告说，Kubernetes已将研发效率提高了100％以上，部署效率提高了280％)。

容器服务为企业带来的架构优化、效率提升和成本降低是显而易见的，也因此逐渐成为了今天不少企业IT架构的转型方向。

概括来说，k8s包括但不限于以下几点好处:

当然，k8s不可能适用于所有场景。

简单的CMS，企业内部OA等，需要k8s吗？或许没必要。

开源软件，语言框架都是工具，如何取舍需根据具体需求。若企业具备应用现代化，云原生化能力，想改造业务模型和软件架构，那结合k8s的确可以帮助到企业进行应用数字化转型。

目前各主流云厂商均有托管式k8s服务，那在全员上云的今天，特别是有出海上云需求的企业，如何选择合适的云厂商托管式k8s服务呢？

这里我们就选时下三大云厂商的k8s服务，Google GKE，Microsoft AKS和Amazon EKS做下横向对比。

首先声明下，一些大家没什么区别或区别不大的特性，比如容器健康检查，可持续存储，Addons ，GPU支持性(均支持)等没有在表里列出。

我们从几个方面做对比，首先看看一些基本信息↓

表1，GKE,AKS,EKS基本信息对比

作为k8s之父，Google目前仍是k8s服务的王者是毋庸置疑的，毕竟比AKS和EKS多发展了3~4年，先发优势和积极的体系贡献是不可忽视的。

从版本上看，GitHub上的开源k8s在10月16刚发布了1.16.2的版本， Google GKE现在已能在rapid channel测试和验证1.15.4了，Global Azure也已经可以预览1.15.4，进度相仿；而AWS目前停留在稳定版1.14.7。

同时，微软AKS支持k8s的区域是最多的，多达29个，其中还包括中国区的两个，而另两家则没有国内支持。

这个不难理解，毕竟Azure本身支持的地区就是所有云厂商里最多的——多达54个。花费上看，GKE着实便宜，而AWS EKS竟然还要对control panel收费。

接下来看看集群管理方面的对比↓

表2，GKE,AKS,EKS集群管理对比

可以很直观地看出Amazon EKS在这部分没啥能突出的地方。

使用过AWS EKS的人都会发现，创建集群实在是很麻烦，步数很多，其实不仅仅k8s部分，AWS连打通两个虚拟网络都会比Azure多n 步(n>3)。

创建一个集群微软和谷歌都只要一条命令，不会花很久，而AWS竟然需要20分钟。SLA方面，谷歌最强，当之无愧。

值得注意的是，微软是这三家唯一能通过Azure Policy实现Cluster Governance策略管理的。实际上，Azure Policy 可以用来管理云端资产的合规性，这个资产当然也包括AKS。

另外微软AKS实现弯道超车的一点是可以通过Azure Dev Spaces，可以在AKS 中测试并迭代开发你的整个微服务应用程序，而无需复制或模拟依赖项。 

Azure Dev Spaces 降低了在共享 AKS 集群中与团队进行协作的负担和复杂性， 它还允许直接在 AKS 中运行和调试容器，帮助实现快速迭代。

最后，让我们看看容器注册表 (Container Registry)，或者称为容器托管。

表3，容器托管对比

从容器托管服务方面看，三家目前均不支持自动化的漏洞扫描，但是手动扫描是没问题的。

容器托管方面，Azure明显更有优势。相比谷歌和EKS，AKS使用签名进行部署时的映像验证，映像格式也比另两家多了Helm，可以使用 Azure 容器注册表作为应用程序图表的 Helm 存储库，使用 Helm的话，应用程序定义为存储在 Helm 图表存储库中的图表。 这些图表定义配置和依赖项，并可在整个应用程序生命周期内进行版本控制，也包括异地复制功能。

谷歌的容器注册表竟然不支持异地复制，令人诧异。而且只有微软AKS支持从Docker file直接创建容器映像。

总的来说，谷歌在k8s的总体地位仍在保持，但微软AKS在一些地方已经实现了弯道超车，比如aci的集成和serverless。

特别AKS运行的平台——Azure本身结合了微软自带的企业属性，生态非常完整，比如用Azure AD结合 RBAC对 Kubernetes 资源访问实现精细控制，能轻松将 Kubernetes 与受 SLA 支持的 Azure 服务（如 Cosmos DB）进行集成，另外Azure备份，监控，安全等方面也完善了开源软件运用在企业环境中使用痛点，提出了解决方案并呈现给用户，且作为一家平台与生产力公司，微软正全面拥抱开源，并不断加大对开发者支持的力度，回馈给社会。

而相较之下，AWS的EKS整体表现平平，作为云厂商里唯一对control plane收费的厂商，其本身并未对k8s的一些特性做到极致。

事实上AWS花了很长时间才接受Kubernetes，可能是因为从AWS的角度来看，他们已经拥有ECS（它使得大规模管理容器变得容易），但慢慢才发现自家的ECS无法战胜k8s，因此只好也做起了自己的k8s服务。

不过，作为老牌云厂商，EKS绝对不会太差。AWS对开源态度看似一般，实际上AWS的开源策略是直接和开源厂商竞争，比如推出了自己的Linux和RedHat竞争，推出了自己的Elastic Search发行版和Elastic公司竞争。

而微软则不同，微软是与开源厂商合作推出新的产品，比如Azure RedHat OpenShift就是和红帽合作的服务，HD Insight是和Cloudera合作。

正如Kubernetes 开源项目联合创始人、微软杰出工程师 Brendan Burns 所说：“我们正迎来一个智能云与智能边缘的时代，这为全球各地的开发者带来了以创新方式开发云原生应用的更广阔的发展机遇。”

希望本篇不算详尽的k8s服务对比，能给对此感兴趣朋友们提供一些参考。