托管Kubernetes：AWS，Azure，Google Cloud

最新推荐文章于 2024-10-02 10:53:34 发布

cxt70571

最新推荐文章于 2024-10-02 10:53:34 发布

阅读量252

点赞数

文章标签：运维 ui 前端 ViewUI

Eric Johanson是AppDynamics的软件工程师。

毫无疑问，Kubernetes很热门。种种迹象表明，由Google创建的开源项目现在由CNCF（云原生计算基金会）负责管理，赢得了容器编排优势的战争。像Mesosphere和Docker Inc.这样的潜在竞争对手已经采用了Kubernetes，OpenShift和Cloud Foundry等领先的PaaS堆栈现在包括了它，并且所有主要的云供应商现在都支持它。

但这并不意味着所有Kubernetes产品都是相同或相等的。在本文中，我们将分解托管的Kubernetes的关键组件，并探索三个主要的云提供商中的每一个-Kubernetes的Amazon Elastic Container Service，Azure Kubernetes Service和Google Kubernetes Engine-在对平台的支持上有何不同。

[InfoWorld解释：什么是云原生？ 开发软件的现代方式。 | 入门： Azure云迁移指南。 •教程： Google Cloud入门。 | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

设置Kubernetes集群

在我们的测试中，所有三个服务都没有问题，无法建立集群。它们开始有所不同的地方是所需的步骤数。例如，Amazon EKS需要许多其他步骤来创建集群。但是，借助Microsoft的Azure Kubernetes服务和Google Kubernetes Engine，一些快速命令可以解决问题，并且群集可以在几分钟内启动并运行。您还必须为Amazon安装单独的软件包，例如heptio-authenticator，它可以使用AWS Identity and Access Management启用联合身份验证。

重要的是要注意，如果您正在使用不同的Kubernetes部署，则必须始终配置kubectl命令行工具。例如，我一直在与直接的Kubernetes以及几乎所有托管的Kubernetes提供商合作。这些服务中有很多都提供了一个命令，该命令实际上将kubeconfig上下文添加到当前文件中，从而使在不同提供程序的集群之间切换变得更加容易。对于Amazon EKS，这是一项手动任务，如果您需要按需快速创建和删除集群，那么这可能会浪费您的时间。

从设置的角度来看，Google Kubernetes Engine和Azure Kubernetes Service非常相似，但是Amazon EKS需要大量步骤。需要注意的重要一点是，亚马逊已经在采取措施加速集群创建。

比较Kubernetes仪表板

原生Kubernetes仪表板是一个简单的基于Web的UI，用于您可以使用的所有Kubernetes服务。它提供有关您的部署，Pod和服务的简单指标，并允许您管理集群。但是，虽然很高兴，但Kubernetes仪表板并不是必需的。从Kubernetes仪表板执行的所有操作都可以从命令行轻松完成。

使用Amazon EKS和Azure Kubernetes Service时，仪表板的使用非常简单。我能够在本地托管群集，在我的计算机上启动代理，然后导航到仪表板的localhost版本。但是Google Kubernetes Engine的仪表板是三者中最好的。坦白说，我对Google的用户界面感到非常惊讶。再说一次，Kubernetes是由Google创建的，所以也许这并不奇怪。

Google的UI确实看起来像是本地Kubernetes仪表板的升级版。它的行为始终如一，运行平稳，内容丰富，易于浏览。另一个优点是它可以立即使用，因此无需手动设置仪表板。 Azure Kubernetes Service也具有内置的仪表板，但是其导航不太直观，需要一些学习。

扩展Kubernetes集群

扩展是Kubernetes的一大优势，从命令行，仪表板或无需人工输入即可轻松实现。在我测试的三种Kubernetes产品中，Google Kubernetes Engine是唯一可以自动设置集群自动扩展的产品。 Kubernetes的主要好处是，如果资源不足，Kubernetes可以扩展Pod，如果利用率不足，则可以缩小节点并将其Pod移到其他节点的能力。因此，自动缩放非常适合运行短流程。

尽管Amazon EKS和Azure Kubernetes Service均声明其工作节点正在作为自动缩放组运行，但Kubernetes无法识别策略，这意味着您必须手动设置自动缩放器。虽然没有过多涉及配置，但是仍然需要进行设置和维护。您可以在主节点上有效地部署自动缩放器作为部署，然后配置其策略。较小的测试没有发现任何问题，但我可以从个人经验告诉您维护第三方服务是很危险的。您可以在Amazon上查看集群自动缩放器，在GitHub 上查看Azure集群的自动缩放器的手动设置文档。

Kubernetes集群的高可用性

可用性虽然很重要，但并不是Kubernetes的最有价值的组成部分。 Kubernetes具有与稳定和容错有关的常规实例可用性相同的优势。高可用性（HA）旨在消除群集中的单点故障。如果我具有HA群集，则应该可以丢失一些主节点。这是高可用性Kubernetes的基本定义。

但是，Kubernetes规模庞大，其中许多组件可能会崩溃。正如CNCF的Kubernetes自愿大使LucasKäldström在2017年KubeCon + CloudNativeCon北美展会上接受采访时所说：

以kube-dns为例。假设我们有一个普通的集群，它有多个主服务器，多个Etcd副本，但仍只运行一个kube-dns。因此，如果运行kube-dns的主服务器发生故障，您的集群将出现某种故障，因为现在突然所有服务发现查询都可能无法解决。因此，我们确实必须更深入地分析集群中的关键组件在哪里，然后尝试消除它们的单点故障。

受管Kubernetes提供商如何在高可用性方面堆叠？

Google Kubernetes Engine有两种模式可用：多区域和区域模式。区域群集和多区域群集之间的主要区别在于，区域群集创建三个主节点，而多区域群集仅创建一个主节点。因此，举例来说，如果您在美国东部地区运行一个区域集群，它将在美国东部-1、2和3上创建一个主集群。因为区域集群可用于整个区域，而不是一个区域内的单个区域。区域，如果单个区域出现故障，则不会影响Kubernetes控制平面和资源。

卢卡斯·卡尔德斯特伦（LucasKäldström）：

高可用性和多主机之间是有区别的。例如，如果您有三个主服务器，并且只有一个Nginx实例在与这些主服务器的前端负载平衡中，则您有一个多主服务器集群，但没有一个高可用性集群，因为您的Nginx可以随时关闭，并且运行良好。

Amazon EKS与Google Kubernetes Engine采用非常相似的方法。它还提供了跨多个区域的HA主节点和工作节点。

Azure Kubernetes服务是迄今为止唯一没有HA的提供商。可以使用工作节点为特定区域提供高可用性，但是这需要更多的精力，并且无法提供与HA主节点相同的弹性级别。

归根结底，选择哪个Kubernetes供应商的决定应归结于您的组织和产品的权衡。 Kubernetes特有的功能包含在不同的供应商中，在撰写本文时，大多数功能都在v1.10版本上。应该根据您的组织需求进行选择。

例如，我的团队对AWS的几乎所有服务进行了标准化：Amazon ECR上托管的Docker映像，Amazon EC2上的实例，AWS CodeCommit中的源代码，Amazon S3上的托管文件，等等。对我来说，使用Amazon EKS更有意义，因为标准化和自动化是我们构建和使用的软件的重点。

如果您的软件依赖多个供应商，则您可能对此并不在意。而且，如果您更专注于评估和实验，或者更关注自动缩放的重要性，而不必手动管理缩放，则应该使用Google Kubernetes Engine。如果您是Microsoft商店，并且想利用Azure的服务目录（使客户端能够为群集上运行的应用程序请求Azure服务），则可能应该选择Azure Kubernetes服务。

选择应始终归结为您要解决的业务用例，因为总会有复杂性。您是否认为管理整体应用程序或大型Docker Compose文件很痛苦？尝试管理数百个用于部署，pod，服务和守护程序集的YAML文件。

Eric Johanson是AppDynamics的软件工程师。 在加入AppDynamics之前，Eric在被Addepar收购之前在AltX担任工程和销售职位。

新技术论坛提供了一个以前所未有的深度和广度探索和讨论新兴企业技术的场所。 选择是主观的，是基于我们对InfoWorld读者认为最重要和最感兴趣的技术的选择。 InfoWorld不接受发布的营销担保，并保留编辑所有贡献内容的权利。 将所有查询发送到 newtechforum@infoworld.com 。