新闻速览Amazon Fargate 的价值与隐性运营成本2023/4/16 16:52:16

涓涓流水

Amazon Fargate的价值与隐性运营成本

使用托管服务的一大核心收益，在于客户能够将自己的时间与精力从差别性的繁重工作当中解放出来。Fargate同样提供这样的收益，可帮助客户摆脱基础设施运营及维护相关的烦恼，将更多精力集中在应用程序构建与业务成果现身上。

下面，我们将整理出一份粗略的全面清单，列出您选择使用Fargate等托管服务时需继续关注的传统问题。这些问题都有着相应的“拥有成本”，属于同“购置成本”并行存在的重要因素。

安全性

虽然容器技术在隔离与应用程序依赖项打包（即容器镜像）方面拥有着可比拟的价值，但其带来的运行时隔离与安全性保障能力却不及传统虚拟机。比较典型的就是“容器逃逸”问题，即恶意用户可能在控制主机之后，访问运行在同一主机上的所有其他容器。

大家当然可以使用各类技术缓解这些问题，包括创建单独的主机区域以运行高度敏感的工作负载、在容器配置当中强制要求只能以非root用户身份运行等等。在际使用中，一部分用户寄希望于Kubernetes提供的高级配置，包括使用污点与容忍机制，或者亲和与反亲和规则等。但这一切都会带来额外的复杂性，导致基础设施化水平下降或运营负担增加，比较终拉升运营成本。Fargate则通过为任何给定Pod分配专用的、大小合适的虚拟机，从根本上解决了这个问题。在任意时间点上，两个Pod都绝对不会同时运行在同一虚拟机之上。借助Fargate，您可以在享受容器技术打包与灵活性势的同时，继续保持虚拟机代码运行硬边界所带来的安全势。另外，运行在Fargate上的各Kubernetes Pod并不共享同一操作系统，因此容器逃逸问题将得到很好的控制。

此外，同样需要指出的是，Fargate临时存储会默认进行加密，用户需执行任何额外配置即可获得安全保障。

总体而言，Fargate推动了AMAZON责任分摊模型的普及。在使用Fargate的场景下，AMAZON负责承担与安全相关的运营任务，例如对用于运行各Pod的虚拟机操作系统进行更新等。这里建议大家参阅Amazon EKS安全比较佳践指南，其中详尽阐述了使用EC2与Fargate运行Kubernetes Pod时在安全性方面的一些差别。

合规性

在受到严格监管的行业中，客户往往需要投入大量时间以保证所运行的技术栈符合合规性要求。论是ISO合规性、HIPAA合规性、PCI合规性还是其他类型的合规要求，都会给客户的日常运营带来沉重负担，特别是合规性自证报告所带来的高昂人力与时间成本。而使用Amazon Fargate等托管服务的一项核心势，在于您可以将合规保障任务交由亚马逊云科技处理，因此只需要向审计人员提供特定服务的亚马逊云科技相关合规文档。另一种解决选项则是使用经典的计算资源（例如Amazon EC2），并投入额外的时间与资金以保证其设置符合要求（并正确加以记录）。截至本文撰稿时，大多数Fargate合规性认证已经适用于运行在Fargate之上的ECS例。我们也在努力将认证覆盖范围扩展到EKS/Fargate，请大家持续关注AMAZON合规性文档以了解比较新进展。

AMI管理

去年，我们正式推出了EKS托管节点组，旨在减轻Kubernetes工作节点所带来的管理负担。托管节点仍然运行在您的亚马逊云科技账户之内，并由您承担节点的保护与修复责任；尽管亚马逊云科技将为您提供经过更新的AMI（Amazon Machine Imagine）以替换各工作节点，借此简化运营流程。您仍将保留对这些例的root访问权限，而EKS则协助处理生命周期管理工作，因此这种新机制并不属于亚马逊云科技完全托管方案。与这种托管节点不同，在使用Fargate时，亚马逊云科技将包揽所有运营任务，您不必插手AMI或底层主机操作系统修复等事务。同样的，使用Fargate时亚马逊云科技将保证您的每一个新Pod都运行在经过完全修复及强化的基础设施之上。换言之，您需考虑应该在运行Pod的节点上使用哪种AMI。

这里需要强调的是，即使是在托管状态下，节点更新仍然需要通过滚动部署新的AMI来现。而这种操作方式会给Pod带来影响，因为Pod会在节点终止之前发送一条终止信号以撤出当前节点。对于纯横向扩展及状态应用程序来说，这项操作一般不会构成问题，但其他类型的应用程序，当基础设施经历滚动更新时，是有可能因此受到冲击的。对于一般每30天定期进行一波AMI轮替的金融机构而言，这种滚动部署有可能给日常运营带来额外负担。

通用K8s工作节点管理

除了AMI管理之外，结合前文所述，大家还需要考虑通用工作节点管理及其相应成本问题。在使用托管节点与自动规模伸缩组（ASG）时，虽然您的运营工作量将得到显著削减，但仍需要在例之上运行Kubernetes生态系统提供的多种工具以现适当的基础设施操作。以节点问题检测器为例，虽然其占用的资源不算很多，但在运营用于支持Pod的基础设施时，该检测器仍然会增加你的工作量。

使用Fargate，基础设施的管理工作将完全归于亚马逊云科技。基础设施将定期接收更新；在启动Pod时，亚马逊云科技会在全新虚拟机中预先部署全部比较新软件版本，以保证Pod始终在比较新技术栈内启动。

Cluster Autoscaler

Cluster Autoscaler(CA)是一款常用的Kubernetes插件，用于根据集群中所运行Pod的负载情况，对工作节点进行纵向规模伸缩调整。CA提供多种丰富功能，但也可能会令您的运营体系变得更加复杂。例如，用于确定何时向集群中添加节点、以及何时删除节点的整个配置，会极大影响到集群的运行成本。建议大家参阅CA常见问题解答以了解其中配置的丰富度与灵活性。此外，您也可以点击此处查看用于调整CA运行方式的受支持参数清单。

当CA确定应执行规模缩减操作时，大家同样需要考虑其对Pod运行造成的影响。运行在待扩展节点上的原有Pod将被逐出，并在其他节点上重新启动。这部分内容，请参阅常见问题解答部分。总之，根据相应Pod的际作用，这种情况有可能破坏业务的正常运转，且对不完全状态类应用的影响尤其明显。

使用Fargate，您将不再需要CA，因此上述问题也将不复存在。配合Fargate，每个容器都将在大小合适的虚拟机上启动并运行，且该虚拟机的生命周期与容器本身完全相同。由于不涉及节点，因此我们需执行任何集群扩展操作。

工作节点的大小调整与可用容量

您的Kubernetes Pod通常需要运行在一组EC2例之上，而这些例也决定了集群的总体容量。但是，选择合适的例大小并非易事。同样的，由于单一节点组仅支持单一例类型，因此只选择特定的例大小也有可能导致容量失衡。我们当然可以使用Cluster Autoscaler跨越多个不同节点组施管理，借此化资源容量；但这疑也会增加集群设置的复杂程度。使用Fargate，每个Pod都将运行在大小合适的虚拟机上，您只需要为Pod运行当中际消耗的资源量付费。例大小、类型或者例资源利用率，这一切从此与您关。

节点大小调整中的另一项重要工作，在于平衡Pod可支配容量与主机规定总容量之间的关系。如果您的工作节点拥有8 GB内存，那么其中只有一部分可用于运行际应用程序。例如，您需要为操作系统本体中运行的部分服务保留资源，为Kubelet保留资源，还需要为Kubernetes逐出操作的阈值触发器保留资源。总体而言，这些“系统预留”资源一般会占到主机总资源量的10%到30%。这里推荐另一篇说明文章，其中列出了部分系统预留容量示例。再有，如果需要从节点中逐出部分负载，大家还需要考虑如何对工作负载进行先级分类及排序。从这个角度来看，我们显然法简单将主机的总体容量数值除以单一Pod的资源需求量，由此粗暴计算出其上所能承载的Pod总数。即使不考虑这些“系统预留”，主机上同样有可能存在其他固有的效率低下因素。但在Fargate方面，除了Kubelet之外，所有资源都可供Fargate充分使用，且您只需要按Fargate的净使用资源付费。稍后我们将进一步讨论这个话题。

除了设计层面带来的系统预留资源量外，很多客户还倾向于人为对集群进行过度配置。这样做当然有其道理，包括通过Cluster Autoscaler的丰富功能选项对Pod进行速扩展，借此现更高的可用性。从本质上讲，这意味着提醒CA在未来添加或删除某些Pod时，可能需要随之调整集群大小。这种方式虽然带来了充分的灵活性，但同时也会引发额外的基础设施成本，导致大家为际上并未用到的容量（至少没有充分使用）付费。

成本追溯

相当一部分EKS客户使用的是多租户集群。因此，对于集中IT团队而言，必须能够在不同内部用户（即各集群租户）之间明确划分成本归属。但这里存在着严重的断层。EKS集群管理员使用的成本单位是作为工作节点的例类型，而EKS集群用户的成本单位则是其当前运行的一个个Pod。不少客户只能通过跟踪“谁用了什么”来现资源使用成本的规范化追溯。但出于种种原因，这种处理方式相当复杂且难以现。Kubernetes容器并非亚马逊云科技中的首类对象，因此我们法使用原生亚马逊云科技成本分配机制对容器开展追踪。

因此，客户经常会使用第方工具以跟踪资源使用情况，并据此生成成本追溯报告。但是，这些工具很难回答另一个同样重要的问题：谁该为未经际使用的资源付费如前所述，您的集群很可能从未以100%的利用率运行过。结合际经历，大多数集群可能长期处于利用率不足50%的状态。虽然一部分客户会投入大量时间与工程资源对这些集群进行调，但即使如此其资源利用率也几乎不可能超过80%。这些数字背后并特定的科学依据，主要源自我们与客户之间的交流与总结。根据以上的分歧，造成了一些问题，例如谁该为这部分20%或者50%的闲置资源买单我们能否将这些资源在现有租户之间重新分配或者说这部分支出应该被划归负责管理云支出的集中IT部门

使用EKS/Fargate，集中IT部门可以构建起多租户集群，从根本上消除这个恼人的难题。

换言之，他们可以将云账单中的成本与内部用户一一对应起来。