Kubernetes(通常被称为“k8”)赢得了容器编排工具之战的胜利 years ago. Nevertheless, 现在仍然有很多方法可以实现Kubernetes，并使其与各种基础设施一起工作, 还有许多工具——有些维护得比其他的好. 也许是这方面最有趣的进展, though, 顶级云提供商已经决定发布他们自己的托管Kubernetes版本:

• 微软Azure提供Azure Kubernetes服务(AKS)
• AWS提供Amazon Elastic Kubernetes服务(EKS)
• Google Cloud提供Google Kubernetes引擎(GKE)

从DevOps的角度来看，这些平台提供了什么? 他们遵守承诺了吗? 它们的创建时间和其他基准比较如何? 它们与各自的平台(尤其是CLI工具)集成得如何? 和他们一起维护和工作是什么感觉? 下面，我们将深入研究这些问题，甚至更多.

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

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

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

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

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

Global Overview

Kubernetes本身就是谷歌的项目, 因此，他们在2014年首先提出托管版本是有道理的.

这三者的比较, Azure的下一个版本是AKS，它需要一些时间来改进:如果你还记得acs引擎的话, 它在几年前被用于在Azure上配置Kubernetes, 你会感激微软为其替代品所做的努力, aks-engine.

AWS是最后一个推出自己版本的公司, EKS, 所以它有时会在功能方面显得落后, 但他们正在迎头赶上.

在定价方面, of course, 事物总是在移动, 谷歌决定以0美元的价格加入AWS.每小时10美元，2020年6月生效. Azure是免费提供AKS服务的局外人, 但目前还不清楚这种情况会持续多久.

另一个主要区别在于集群的升级特性. 最自动化的升级是在GKE中，它们在默认情况下是打开的. However, AKS vs. EKS在这里是相似的, 从某种意义上说，两者都需要手动请求才能升级主节点或工作节点.

Networking

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

这里发现的主要区别是基于服务网格的附加价值. AKS不支持任何开箱即用的服务网格(尽管工程师可以手动安装Istio). AWS已经开发了自己的服务网格，称为App mesh. 最后，谷歌发布了自己的集成 Istio (尽管仍处于测试阶段)，客户可以在创建集群时直接添加.

Best bet: GKE

可伸缩性和性能

关于GKE vs. AKS vs. 在性能和可伸缩性方面，GKE似乎处于领先地位. Indeed, 支持最大节点数(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对主服务器缺乏高可用性, 哪个是需要考虑的重要方面. 但是，一如既往，这种情况可能很快就会改变.

Best bet: GKE

安全与监控

在遵从性方面，这三家云提供商是相同的. However, 在安全方面, EKS和GKE通过其嵌入式密钥管理服务提供了另一层安全性.

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

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

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

Best bet: GKE

Ecosystem

就生态系统而言，这三家供应商拥有不同的优势和资产. AKS现在有非常完整的关于其平台的文档，在Stack Overflow上排名第二. EKS在堆栈溢出上的帖子数量最少, 而是受益于AWS市场的优势. GKE, 作为最古老的平台, Stack Overflow上的帖子最多, 它的市场上也有相当数量的应用程序, 也是最全面的文档.

最好的赌注:GKE和EKS

Pricing

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

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

AWS不允许使用其免费层来测试EKS集群的原因是EKS需要比tX更大的机器.微层，而EKS的小时定价不属于免费层.

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

广告功能和谷歌的优势

当在网上看到不同的广告功能时, 托管版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是唯一一个具有裸机节点集成的, 它还拥有其市场上最多的应用程序.

现在，每个Kubernetes产品的广告特性都很清楚了, 让我们通过一些实际测试进行更深入的研究.

Kubernetes: AWS vs. GCP vs. Azure实践

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

创建集群用户体验

AKS

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

EKS

在EKS上创建集群肯定比在linux上创建集群更复杂. AKS. First of all, and by default, AWS需要首先访问IAM，为Kubernetes控制平面创建一个新角色，并将工程师分配给该角色. 还需要注意的是，此集群创建不包括节点的创建, 所以当我测量平均11分钟时, 这只适用于大师的创作. 创建节点组是管理员的另一个步骤, 再次需要通过IAM控制面板为具有三个必要策略的工人创建一个角色.

GKE

对我来说，在GKE上手动创建集群的体验是最愉快的. 在Google Cloud Console中找到Kubernetes Engine后，单击创建集群. 不同类别的设置出现在左边的菜单中. Google将使用易于修改的默认节点池预填充新集群. 最后但并非最不重要的是，GKE具有最快的集群生成时间，这将我们带到下一个表.

是时候产生一个集群了

我在同一地区(AKS的法兰克福和西欧)进行了这些测试，以消除这种差异对产卵时间的可能影响. 我还尝试为集群选择相同大小的节点:三个节点, 每个都有两个vcpu和7或8 GB的内存, 一个标准的大小，在Kubernetes上运行一个小的负载并开始试验. 我将每个集群创建三次以计算平均值.

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

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

并不是所有的cli都是一样的, 但是在这种情况下, 这三个CLI实际上都是一个更大的CLI的模块. 使用每个云提供商的CLI工具链是什么感觉呢?

AKS CLI (via az)

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

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

EKS CLI (via aws or eksctl)

On AWS, 我们找到了一种不同的方法——有两种不同的官方CLI工具来管理EKS集群. As always, aws 可以连接到AWS资源，特别是集群吗. 获取凭据到本地kubecconfig可以通过以下方式完成: update- kubecconfig——name cluster-test.

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

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

GKE CLI (via gcloud)

对于GKE，步骤非常相似:安装 gcloud，然后通过 gcloud init. 由此带来的可能性:工程师可以创造, delete, describe, 获取证书, resize, update, 或者升级集群, 或者列出簇.

用于创建集群的语法 gcloud 很简单: gcloud容器集群创建myGCloudCluster——num-nodes=1

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

In practice, 我们可以看到，GKE无疑是启动基本集群最快的方法, 在控制台的简单性和集群的刷出时间方面. UX-wise, 使用集群旁边的连接按钮, 使连接到集群成为最简单的方式, too.

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

管理的Kubernetes产品向前迈进:AWS vs. GCP vs. Azure

对于那些刚开始使用Kubernetes的人, 我的首选实现是GKE, 因为这是最直接的. 这很容易设置, 它有一个简单而快速的刷出用户体验, 它很好地融入了谷歌云平台生态系统.

尽管AWS是最后一个加入竞争的, 它有一些不可否认的优点, 例如裸机节点，以及它与拥有最大心智份额的提供商集成的简单事实.

最后，AKS自创立以来已经取得了很大的进步. 工具和功能的一致性可能不会花很长时间，同时在创新的过程中留下空间. 与任何托管Kubernetes产品一样, 对于那些已经在母平台上的人, 整合将是一个卖点.

一旦团队选择了Kubernetes云提供商, 看看其他团队的经验可能会很有趣, 特别的失败. 这些尸体解剖后 对现实世界案例的反映——总是一个发展自己的前沿最佳实践的良好起点吗. 我期待你的评论!