Kubernetes(通常被称为“k8”)赢得了容器编排工具之战的胜利 years ago. Nevertheless, 现在仍然有很多方法可以实现Kubernetes，并使其与各种基础设施一起工作, and many tools—some better maintained than others. Perhaps the most interesting development on that front, though, 顶级云提供商已经决定发布他们自己的托管Kubernetes版本:

• Microsoft Azure offers the Azure Kubernetes Service (AKS)
• AWS offers the Amazon Elastic Kubernetes Service (EKS)
• Google Cloud offers the Google Kubernetes Engine (GKE)

From a DevOps perspective, what do these platforms offer? 他们遵守承诺了吗? How do their creation time and other benchmarks compare? 它们与各自的平台(尤其是CLI工具)集成得如何? What’s it like maintaining and working with them? Below, we’ll delve into these questions, and more.

注意:对于希望在阅读之前了解Kubernetes集群概念的读者, 德米特里·科诺诺夫提出 精彩的介绍.

AKS vs. EKS vs. GKE:广告功能

我们决定对每个托管的可用特性进行分组 Kubernetes 版本到筒仓:

• Global Overview
• Networking
• 可伸缩性和性能
• 安全与监控
• Ecosystem
• Pricing

注意:随着云提供商定期更新其产品，这些详细信息可能会随时间变化.

Global Overview

Kubernetes itself was Google’s project, 因此，他们在2014年首先提出托管版本是有道理的.

这三者的比较, Azure的下一个版本是AKS，它需要一些时间来改进:如果你还记得acs引擎的话, 它在几年前被用于在Azure上配置Kubernetes, you will appreciate Microsoft’s effort on its replacement, aks-engine.

AWS was the last one to roll out its own version, EKS, so it sometimes can appear to be behind on the feature front, 但他们正在迎头赶上.

在定价方面, of course, 事物总是在移动, and Google decided to join AWS in its price point of $0.每小时10美元，2020年6月生效. Azure is the outsider here by giving out for free the AKS service, but it’s unclear how long that may last.

Another main difference lies in the upgrade feature of the cluster. 最自动化的升级是在GKE中，它们在默认情况下是打开的. However, AKS vs. EKS在这里是相似的, 从某种意义上说，两者都需要手动请求才能升级主节点或工作节点.

Networking

在网络方面，这三家云提供商彼此非常接近. 例如，它们都允许客户使用Calico实施网络策略. 关于负载均衡, 它们都使用自己的负载平衡器资源实现集成，并让工程师选择使用什么.

这里发现的主要区别是基于服务网格的附加价值. AKS不支持任何开箱即用的服务网格(尽管工程师可以手动安装Istio). AWS has developed its own service mesh called App Mesh. Finally, Google has released its own integration with Istio (尽管仍处于测试阶段)，客户可以在创建集群时直接添加.

Best bet: GKE

可伸缩性和性能

关于GKE vs. AKS vs. EKS performance and scalability, GKE seems to be ahead. Indeed, it supports the biggest number of nodes (5,000)，并提供了关于如何正确扩展集群的大量文档. 高可用性的所有特性都是可用的，并且很容易进行微调. What is more, GKE最近发布了Anthos, a project to create an ecosystem around GKE and its functionalities; with Anthos, 您可以在本地部署GKE.

AWS确实有一个关键优势, 虽然:它是唯一一个允许裸机节点运行Kubernetes集群的工具.

As of June 2020, AKS lacks high availability for the master, which is an important aspect to consider. 但是，一如既往，这种情况可能很快就会改变.

Best bet: GKE

安全与监控

In terms of compliance, all three cloud providers are equivalent. However, 在安全方面, EKS和GKE通过其嵌入式密钥管理服务提供了另一层安全性.

在监控方面，Azure和Google Cloud围绕Kubernetes提供了自己的监控生态系统. 值得注意的是，Google最近已经更新为使用Kubernetes Engine Monitoring, which is specifically designed for Kubernetes.

Azure provides its own container monitoring system, 它最初是为基本的, 非kubernetes容器生态系统. 他们增加了对一些kubernetes特定指标和资源(集群健康状况)的监控, 部署)-预览模式, as of June 2020.

AWS直接在Cloudwatch中为控制平面提供轻量级监控. 监控工人, 你可以使用Kubernetes Container Insights Metrics，这些指标是通过一个特定的CloudWatch代理提供的，你可以安装在集群中.

Best bet: GKE

Ecosystem

就生态系统而言，这三家供应商拥有不同的优势和资产. AKS现在有非常完整的关于其平台的文档，在Stack Overflow上排名第二. EKS has the least number of posts on Stack Overflow, but benefits from the strength of the AWS Marketplace. GKE, 作为最古老的平台, Stack Overflow上的帖子最多, and a decent number of apps on its marketplace, but also the most comprehensive documentation.

最好的赌注:GKE和EKS

Pricing

就整体价格而言，即使GKE实施了0美元的举措.对于任何集群来说，它仍然是迄今为止最便宜的云. 这要归功于谷歌的持续使用折扣, 当按需资源的月使用量达到一定的最小值时，应用哪一个.

值得注意的是，示例价格行并没有考虑到云提供商可以收费的Kubernetes集群的流量.

AWS不允许使用其免费层来测试EKS集群的原因是EKS需要比tX更大的机器.micro tier, and EKS hourly pricing is not in the free tier.

Nevertheless, 使用每个云提供商的现货/可抢占节点，在适当的负载下测试这些托管Kubernetes选项仍然是经济的——这种策略可以很容易地在最终价格上节省80%到90%. (当然，不建议在这样的机器上运行有状态的生产负载!)

Advertised Features and Google’s Advantage

When looking at the different advertised features online, 托管版Kubernetes在市场上存在的时间和功能的数量似乎是有关联的. As mentioned, Google作为Kubernetes项目的发起者似乎是一个不可否认的优势, 从而与自己的云平台实现更好、更强的集成.

But AKS and EKS are not to be underestimated as they mature; both can take advantage of their unique features. For example, AWS is the only one to have bare-metal node integration, 它还拥有其市场上最多的应用程序.

现在，每个Kubernetes产品的广告特性都很清楚了, let’s do a deeper dive with some hands-on tests.

Kubernetes: AWS vs. GCP vs. Azure in Practice

广告是一回事, 但是，在服务生产负载时，不同的平台是如何比较的呢? 作为一名云工程师, 我知道在实施基础设施即代码时，生成和关闭集群所需时间的重要性. 但是，我还想探索每种CLI的可能性，并评论每个云提供商使生成集群变得多么容易(或不容易).

创建集群用户体验

AKS

在AKS上，生成集群类似于在AWS上创建实例. 只要找到AKS菜单，然后浏览一系列不同的菜单. 配置经过验证后，就可以创建集群了，这个过程分为两步. 这很简单, 工程师可以使用默认设置轻松快速地启动集群.

EKS

Cluster creation is definitely more complex on EKS vs. AKS. First of all, and by default, AWS需要首先访问IAM，为Kubernetes控制平面创建一个新角色，并将工程师分配给该角色. 还需要注意的是，此集群创建不包括节点的创建, so when I measured 11 minutes on average, 这只适用于大师的创作. The node group creation is another step for the administrator, 再次需要通过IAM控制面板为具有三个必要策略的工人创建一个角色.

GKE

对我来说，在GKE上手动创建集群的体验是最愉快的. 在Google Cloud Console中找到Kubernetes Engine后，单击创建集群. Different categories of settings appear in a menu on the left. Google将使用易于修改的默认节点池预填充新集群. 最后但并非最不重要的是，GKE具有最快的集群生成时间，这将我们带到下一个表.

是时候产生一个集群了

我在同一地区(AKS的法兰克福和西欧)进行了这些测试，以消除这种差异对产卵时间的可能影响. 我还尝试为集群选择相同大小的节点:三个节点, each having two vCPUs and seven or eight GB of memory, 一个标准的大小，在Kubernetes上运行一个小的负载并开始试验. I created each cluster three times to compute an average.

在这些测试中，GKE始终保持领先优势，生成时间始终在3分钟以内.

Kubernetes: AWS vs. GCP vs. Azure CLI概述

并不是所有的cli都是一样的, but in this case, all three CLIs are actually modules of a larger CLI. 使用每个云提供商的CLI工具链是什么感觉呢?

AKS CLI (via az)

After installing az 模具，然后AKS模块(通过 Az打开install-cli)，工程师需要授权CLI与项目的Azure帐户进行通信. 这是一个通过简单的 获取凭证——资源组myResourceGroup——名称myAKSCluster.

类似地，创建一个集群: az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI (via aws or eksctl)

On AWS, 我们找到了一种不同的方法——有两种不同的官方CLI工具来管理EKS集群. As always, aws can connect to AWS resources, particularly clusters. Getting credentials into a local kubeconfig can be done via: aws eks update-kubeconfig --name cluster-test.

然而，工程师也可以使用 eksctl，由weaverworks开发，用Go语言编写，可以轻松创建和管理EKS集群. EKS为云工程师提供的一个主要好处是，他们可以将它与YAML配置文件结合起来创建基础设施即代码(IaC)，因为它与CloudFormation一起工作. 在将EKS集群集成到AWS上的大型基础设施中时，这绝对是需要考虑的资产.

通过以下方式创建集群 eksctl is as easy as 创建集群，不需要其他参数.

GKE CLI (via gcloud)

For GKE, the steps are very similar: Install gcloud，然后通过 gcloud init. The possibilities from there: Engineers can create, delete, describe, 获取证书, resize, update, 或者升级集群, or list clusters.

用于创建集群的语法 gcloud 很简单: gcloud container clusters create myGCloudCluster --num-nodes=1

AKS vs. EKS vs. GKE:试驾结果

In practice, 我们可以看到，GKE无疑是启动基本集群最快的方法, in terms of both console simplicity and cluster spawn time. UX-wise, with the connect button next to the cluster, making it the most straightforward to connect to a cluster, too.

在CLI工具方面, the three cloud providers have implemented similar functionalities; however, 我们可以把重点放在weaverworks为EKS提供的额外工具上. eksctl 是您在现有AWS基础设施之上实现基础设施即代码的完美工具吗, 将其他服务与EKS相结合.

Managed Kubernetes Offerings Forge Ahead: AWS vs. GCP vs. Azure

For those just starting in the world of Kubernetes, 我的首选实现是GKE, 因为这是最直接的. 这很容易设置, it has a simple and fast UX for spawning, and it’s well-integrated into the Google Cloud Platform ecosystem.

Even though AWS was the last to join the race, 它有一些不可否认的优点, 例如裸机节点，以及它与拥有最大心智份额的提供商集成的简单事实.

Finally, AKS has made great progress since its creation. 工具和功能的一致性可能不会花很长时间，同时在创新的过程中留下空间. And as with any managed Kubernetes offering, for those already on the parent platform, 整合将是一个卖点.

Once a team has chosen a Kubernetes cloud provider, it could be interesting to look at other teams’ experiences, 特别的失败. 这些尸体解剖后 对现实世界案例的反映——总是一个发展自己的前沿最佳实践的良好起点吗. 我期待你的评论!