K8s/Kubernetes：AWS 与 GCP 与 Azure

已发表: 2022-03-11

Kubernetes（通常风格化为“K8s”）在多年前赢得了容器编排工具的战斗。 尽管如此，今天仍然有很多方法可以实现 Kubernetes 并使其与各种基础设施和许多工具一起工作——其中一些工具比其他工具维护得更好。 不过，这方面最有趣的发展可能是顶级云提供商已决定发布他们自己的托管 Kubernetes 版本：

  • Microsoft Azure 提供 Azure Kubernetes 服务 (AKS)
  • AWS 提供 Amazon Elastic Kubernetes Service (EKS)
  • Google Cloud 提供 Google Kubernetes Engine (GKE)

从 DevOps 的角度来看，这些平台提供了什么？ 他们是否兑现了他们的承诺？ 他们的创建时间和其他基准比较如何？ 他们与各自平台的集成情况如何，尤其是他们的 CLI 工具？ 维护和与他们合作是什么感觉？ 下面，我们将深入探讨这些问题以及更多内容。

注意：对于希望在继续阅读之前解释 Kubernetes 集群概念的读者，Dmitriy Kononov 提供了出色的介绍。

AKS 与 EKS 与 GKE：广告功能

我们决定将每个托管 Kubernetes 版本可用的不同功能分组到孤岛中：

  • 全球概览
  • 联网
  • 可扩展性和性能
  • 安全和监控
  • 生态系统
  • 价钱

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

全球概览

服务方面AKS EKS GKE
发布年份2017 2018 2014
最新版本1.15.11（默认）- 1.18.2（预览版） 1.16.8（默认） 1.14.10（默认）- 1.16.9
特定组件oms 代理，隧道前沿aws-节点fluentd, fluentd-gcp-scaler, 事件导出器, l7-default-backend
Kubernetes 控制平面升级手动的手动的自动（默认）或手动
工人升级手动的是（使用托管节点组很容易） 是：自动和手动，可以微调
服务水平协议99.95% 有可用区，99.9% 没有EKS（主节点）为 99.9%，EC2（节点）为 99.99% 99.95% 区域内，99.5% 区域内
原生 Knative 支持不不否（但原生 Istio 安装）
Kubernetes 控制平面价格自由0.10 美元/小时0.10 美元/小时

Kubernetes 本身就是 Google 的项目，因此他们在 2014 年率先提出托管版本是有道理的。

在这里比较的三者中，Azure 紧随其后的是 AKS，并且已经有一段时间需要改进：如果您还记得几年前用于在 Azure 上配置 Kubernetes 的 acs-engine，您会欣赏微软在替换它方面所做的努力， aks引擎。

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

当然，在定价方面，事情总是在变化，谷歌决定以 0.10 美元/小时的价格加入 AWS，自 2020 年 6 月起生效。Azure 是这里的局外人，免费提供 AKS 服务，但目前尚不清楚如何可能会持续很长时间。

另一个主要区别在于集群的升级功能。 最自动化的升级在 GKE 中，默认情况下它们是打开的。 但是，AKS 与 EKS 在这里彼此相似，因为两者都需要手动请求才能升级主节点或工作节点。

联网

服务方面AKS EKS GKE
网络策略是：Azure 网络策略或 Calico 需要安装印花布是：通过 Calico 原生
负载均衡基本或标准 SKU 负载均衡器经典和网络负载均衡器容器原生负载均衡器
服务网格没有开箱即用AWS App Mesh（基于 Envoy） Istio（开箱即用，但测试版）
DNS 支持CoreDNS 自定义VPC 内的 CoreDNS + Route53 CoreDNS + 谷歌云 DNS

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

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

最佳选择：GKE

可扩展性和性能

服务方面AKS EKS GKE
裸机节点不是的不
每个集群的最大节点数1,000 1,000 5,000
高可用性集群不是的控制计划，跨 AZ 的工作人员手动是，通过区域集群，复制主节点和工作节点
自动缩放是，通过集群自动扩缩器是，通过集群自动扩缩器是，通过集群自动扩缩器
垂直 Pod 自动缩放器不是的是的
节点池是的是的是的
GPU 节点是的是的是的
本地通过 Azure ARC（测试版）提供不通过 Anthos GKE 进行 GKE On-Prem

在 GKE 与 AKS 与 EKS 的性能和可扩展性方面，GKE 似乎领先。 事实上，它支持最大数量的节点 (5,000)，并提供有关如何正确扩展集群的大量文档。 高可用性的所有功能都可用并且易于微调。 更重要的是，GKE 最近发布了 Anthos，这是一个围绕 GKE 及其功能创建生态系统的项目； 借助 Anthos，您可以在本地部署 GKE。

不过，AWS 确实有一个关键优势：它是唯一允许裸机节点运行 Kubernetes 集群的优势。

截至 2020 年 6 月，AKS 缺乏主服务器的高可用性，这是需要考虑的一个重要方面。 但是，与往常一样，这种情况很快就会改变。

最佳选择：GKE

安全和监控

服务方面AKS EKS GKE
应用机密加密不是的，可以通过 AWS KMS 是的，可以通过 Cloud KMS
遵守HIPAA、SOC、ISO、PCI DSS HIPAA、SOC、ISO、PCI DSS HIPAA、SOC、ISO、PCI DSS
RBAC 是的是的，并且与 IAM 紧密集成是的
监控Azure Monitor 容器运行状况功能连接到 Cloudwatch 的 Kubernetes 控制平面监控，节点的 Container Insights Metrics Kubernetes Engine 监控和与 Prometheus 的集成

在合规性方面，所有三个云提供商都是等效的。 但是，在安全性方面，EKS 和 GKE 通过其嵌入式密钥管理服务提供了另一层安全性。

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

Azure 提供了自己的容器监控系统，该系统最初是为基本的非 Kubernetes 容器生态系统而设计的。 截至 2020 年 6 月，他们以预览模式添加了对某些 Kubernetes 特定指标和资源（集群运行状况、部署）的监控。

AWS 直接在 Cloudwatch 中为控制平面提供轻量级监控。 要监控工作人员，您可以使用通过可以安装在集群中的特定 CloudWatch 代理提供的 Kubernetes Container Insights Metrics。

最佳选择：GKE

生态系统

服务方面AKS EKS GKE
市场Azure 市场（但没有明确的 AKS 集成） AWS Marketplace（250 多个应用程序） 谷歌市场（90 多个应用程序）
基础架构即代码 (IaC) 支持地形模块
Ansible 模块		地形模块
Ansible 模块		地形模块
Ansible 模块
文档弱但完整而强大的社区（2,000 多个 Stack Overflow 帖子） 不是很彻底但很强大的社区（1,500+ Stack Overflow 帖子） 广泛的官方文档和非常强大的社区（4,000+ Stack Overflow 帖子）
CLI 支持完全的完整，加上特殊的单独工具eksctl （如下所述） 完全的

在生态系统方面，这三个提供商具有不同的优势和资产。 AKS 现在围绕其平台拥有非常完整的文档，并且在 Stack Overflow 上的帖子方面排名第二。 EKS 在 Stack Overflow 上的帖子数量最少，但受益于 AWS Marketplace 的优势。 GKE 作为最古老的平台，在 Stack Overflow 上拥有最多的帖子，在其市场上拥有相当数量的应用程序，但也拥有最全面的文档。

最佳选择：GKE 和 EKS

价钱

服务方面AKS EKS GKE
免费使用上限价值 170 美元不符合免费套餐的条件价值 300 美元
Kubernetes 控制平面成本自由0.10 美元/小时0.10 美元/小时（2020 年 6 月）
降价（Spot 实例/抢占式节点） 是的是的是的
一个月的示例价格342 美元
3 个 D2 节点		300 美元
3 个 t3.large 节点		190 美元
3 个 n1-standard-2 节点

就整体价格而言，即使 GKE 为任何集群实施 0.10 美元/小时的价格点，它仍然是迄今为止最便宜的云。 这要归功于谷歌特有的东西——持续使用折扣，只要按需资源的每月使用量达到某个最低限度，就会应用这些折扣。

需要注意的是，示例价格行没有考虑到云提供商可以收取的 Kubernetes 集群的流量。

AWS 不允许使用他们的免费套餐来测试 EKS 集群的原因是 EKS 需要比 tX.micro 层更大的机器，而且 EKS 每小时定价不在免费套餐中。

尽管如此，使用每个云提供商的现货/可抢占节点以适当的负载测试这些托管 Kubernetes 选项中的任何一个仍然是经济的——这种策略很容易在最终价格上节省 80% 到 90%。 （当然，不建议在此类机器上运行有状态的生产负载！）

广告功能和 Google 的优势

在线查看不同的广告功能时，托管 Kubernetes 版本上市的时间与功能数量之间似乎存在相关性。 如前所述，谷歌一直是 Kubernetes 项目的发起者，这似乎是一个不可否认的优势，从而与自己的云平台更好、更强地集成。

但是AKS和EKS随着它们的成熟也不容小觑； 两者都可以利用其独特的功能。 例如，AWS 是唯一拥有裸机节点集成的公司，并且在其市场上拥有最多的应用程序。

既然每个 Kubernetes 产品的广告功能已经很清楚了，让我们通过一些动手测试来进行更深入的研究。

Kubernetes：AWS 与 GCP 与 Azure 的实践

广告是一回事，但在服务生产负载方面，不同平台如何比较？ 作为一名云工程师，我知道在执行基础设施即代码时需要多长时间来生成和关闭集群的重要性。 但我也想探索每个 CLI 的可能性，并评论每个云提供商如何轻松（或不）生成集群。

集群创建用户体验

AKS

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

EKS

在 EKS 与 AKS 上，集群创建肯定更复杂。 首先，默认情况下，AWS 需要先访问 IAM，以便为 Kubernetes 控制平面创建一个新角色并将工程师分配给它。 还需要注意的是，这个集群创建不包括节点的创建，所以当我平均测量 11 分钟时，这只是用于创建主节点。 节点组创建是管理员的另一个步骤，再次需要一个具有三个必要策略的工作人员角色，这些策略要通过 IAM 控制面板制定。

GKE

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

是时候产生一个集群了

服务方面AKS EKS GKE
尺寸3 个节点 (Ds2-v2)，每个节点有 2 个 vCPU，7 GB RAM 3 个节点 t3.large 3 个节点 n1-standard-2
时间 (m:ss) 完整集群的平均 5:45 主节点 11:06 加上节点组 2:40（全集群总共 13:46） 完整集群的平均 2:42

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

在这些测试中，GKE 始终保持领先，生成时间始终低于三分钟。

Kubernetes：AWS 与 GCP 与 Azure CLI 概述

并非所有 CLI 都是一样的，但在这种情况下，所有三个 CLI 实际上都是更大 CLI 的模块。 使用每个云提供商的 CLI 工具链启动和运行是什么感觉？

AKS CLI（通过az ）

安装az tooling 和 AKS 模块（通过az aks install-cli ）后，工程师需要授权 CLI 与项目的 Azure 帐户进行通信。 这是通过简单的az aks get-credentials --resource-group myResourceGroup --name myAKSCluster获取凭据以更新本地 kubeconfig 文件的问题。

同样，要创建集群： az aks create --resource-group myResourceGroup --name myAKSCluster

EKS CLI（通过aws或eksctl ）

在 AWS 上，我们找到了一种不同的方法——有两种不同的官方 CLI 工具来管理 EKS 集群。 与往常一样， aws可以连接到 AWS 资源，尤其是集群。 可以通过以下方式将凭证获取到本地 kubeconfig： aws eks update-kubeconfig --name cluster-test 。

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

通过eksctl创建集群就像eksctl create cluster一样简单，不需要其他参数。

GKE CLI（通过gcloud ）

对于 GKE，步骤非常相似：安装gcloud ，然后通过gcloud init进行身份验证。 来自那里的可能性：工程师可以创建、删除、描述、获取凭据、调整大小、更新或升级集群，或列出集群。

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

AKS 与 EKS 与 GKE：试驾结果

在实践中，我们可以看到 GKE 无疑是启动基本集群的最快方式，无论是在控制台简单性还是集群生成时间方面。 UX 方面，集群旁边有连接按钮，这也使得连接到集群最直接。

在 CLI 工具方面，三个云提供商实现了类似的功能； 但是，我们可以强调 Weaveworks 为 EKS 提供的额外工具。 eksctl是您在现有 AWS 基础设施之上实施基础设施即代码并将其他服务与 EKS 相结合的完美工具。

托管 Kubernetes 产品向前发展：AWS 与 GCP 与 Azure

对于那些刚开始接触 Kubernetes 的人来说，我的首选实现是 GKE，因为它是最直接的。 它易于设置，具有简单快速的生成 UX，并且很好地集成到了 Google Cloud Platform 生态系统中。

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

最后，AKS 自创建以来取得了长足的进步。 工具和功能的平等可能不会花很长时间，同时在过程中留有创新空间。 与任何托管 Kubernetes 产品一样，对于那些已经在父平台上的产品，集成将是一个卖点。

一旦一个团队选择了 Kubernetes 云提供商，看看其他团队的经验，尤其是失败的经验可能会很有趣。 这些事后分析反映了现实世界的案例——始终是开发自己的尖端最佳实践的良好起点。 我期待您的评论！

相关： Kubernetes 服务网格比较