通过EKS、Fargate与Amazon Compute Savings Plans降低Pod单位使用成本

在Re:Invent 2019大会上，我们公布了可以在Amazon Elastic Kubernetes Service（Amazon EKS）上使用Amazon Fargate来部署Kubernetes Pod的全新功能。因为我们看到客户快速接受使用Kubernetes API的方式将Pod部署在用于运行容器的Amazon无服务器基础设服务施Fargate当中。这种全新实践帮助他们彻底摆脱了由Kubernetes集群维护工作带来的沉重负担，包括与之相关的管理、修复、安全、隔离与扩展等日常任务。

如果大家希望了解关于Amazon EKS与Fargate协同运作的更多详细信息，请参阅我在re:Invent大会上的分组讨论内容。

在此之前，Amazon Fargate虽然一直归属于Amazon Compute Savings Plan节约计划的范围之内，但只适用于运行在ECS上的任务上。今天，我们宣布在Fargate上运行的EKS Pod也将被纳入Amazon Compute Savings Plans之内。您可以参阅What’s New公告帖以了解更多详细信息。如果您已经激活了Compute Savings Plan，那么无需任何额外操作，系统会根据您的Saving Plan为Fargate Pod提供相应折扣。如果您还没有激活Compute Savings Plan，不妨首先阅读我们发布的Amazon Compute Savings Plan常见问题，逐步了解该如何让自己的运营体系获得价格优惠。只要客户承诺在一年或三年周期内保持稳定的计算资源使用量，即可节约最高52%的Fargate使用成本。

Compute Savings Plans面向的不仅仅限定于某一项特定技术。Compute Savings Plans灵活性极高，能够为您实际选用的多种计算服务提供价格优惠。例如，您可以选择EC2、Fargate或Lambda。如果选择Fargate，则可在ECS与EKS之间自由使用您所熟悉的编排方案。无论如何选择，Compute Savings Plans都将为您带来可观的价格折扣。

Compute Savings Plans是将EKS与Fargate结合起来，进而降低并优化成本的最直接、最具实效的方法之一。在今天的博文中，我们将概括并总结当Farget和传统EC2集群对比时需要考虑的一些点。

AMAZON Fargate使用成本详解

有时候，客户会将Fargate计算成本与EC2计算成本进行比较。这里我们举个简单的例子，在us-east-1区域内选择m5.large Linux按需实例（包含2个vCPU与8 GB内存）和同等配置的Fargate作为比较对象。截至目前，此EC2实例的运行成本为每小时0.096美元。而在同一区域中，Fargate的计算成本可通过以下公式计算得出：(0.04048美元x 2 vCPU)+(0.004445美元x 8GB)=0.08096+0.03556=0.11652美元/小时。

但需要强调的是，Fargate使用混合EC2实例类型集群，其性能可能与最新一代EC2实例（例如m5或c5家族）有所不同。因此，尽管以上示例体现的是Fargate成本仅比EC2高出20%的最理想状况，但考虑到实例之内的代际更迭，实际性价比结论可能还将受到影响。这里建议大家根据特定设置进行测试，并充分考虑自己的实际需求。我们一直在推动Fargate底层计算资源的更新，致力于帮助客户消除这种性能差异及资源不统一问题。

如前文所述，在Fargate上启动EKS Pod此前并不在Compute Savings Plans节约计划的范围之内。因此在考虑Compute Savings Plans给EC2实例带来的折扣之后，Fargate与EC2实例成本之间的差距将更加明显。但在此次公告中，我们将EKS/Fargate组合正式纳入Compute Savings Plans，这不仅缩小了Fargate与EC2实例之间的成本差距，同时也保证选择不同购买模式的客户都能享受到这一重要优惠。

另外需要强调的是，准确比较的前提应该是对整体情况的确切考量。在使用Fargate的情况下，我们不仅帮助客户承担起大量管理负担，同时也消除了传统虚拟机集群中常见的资源闲置或未能充分使用等问题。再有，AMAZON的基础设施规模极为庞大，由此带来的规模经济效应足以在同等配置条件下为客户带来远超本地基础设施的成本优势。这也是我们为数百万客户服务的同时，建立起的一种独特优势。

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部门可以构建起多租户集群，从根本上消除这个恼人的难题。

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

Fargate Pod的大小调整与资源节约

以上各个方面当然都很重要，而且对于Fargate的业务用例而言具有重要意义。但从核心角度出发，我们真正应该关心的是实际使用容量与您为之付费的容量之间到底存在怎样的差距。

例如，在尝试使用Fargate时，很多客户错误地将Fargate Pod容量与传统工作节点容量进行直接比较。前文已经提到，Pod容量属于容器能够全部使用的净容量，而工作节点容量则是您需要为之付费的CPU加内存的总容量——但其中只有一部分可被有效用于运行容器。

我们也提到过，在传统Kubernetes集群中，根据您的实际业务要求与运营成熟度，集群中往往有20%到50%的资源被长期闲置。通过使用Fargate，您可以自动将理论容量使用率提升至接近100%，借此大大改善资源浪费问题。

当然，上述结论的基本前提，在于假设您能够充分利用为Pod分配的全部容量。但很多客户最终也遇到过EKS Pod资源利用率仅为50%，却需要为全部容量付费的情况。这个时候，即使使用Fargate也不会带来比传统EC2实例更好的任何成本效益。正因为如此，我们才需要“合理调整Pod大小”，这不仅将直接决定您的实际运营效能，同时也是对Amazon Compute Savings Plans优惠政策的良好补充。

下面，我们详细聊聊如何正确调整Kubernetes容器的大小。

在传统Kubernetes集群之上，工作节点就是最基本的计算单元。这些基本单元定义了各Pod所能使用的总容量以及集群的整体运行成本。以此为基础，我们建议大家充分使用作为可选功能的Kubernetes请求限制选项。在容器之上设置CPU请求限制以及内存请求限制之后，相关设置将为容器定义虚拟资源沙箱。而如果不在Pod上设置这些参数，则所有Pod都将争用当前可用的集群总资源（特别是所处工作节点上的资源）。

在EKS/Fargate上，使用的则是另外一套完全不同的资源模型。由于集群中不存在工作节点，因此Pod本身的大小将直接决定必要的底层容量。要有效使用Fargate服务，就必须要正确对Pod大小做出设置。正因为如此，正确配置Pod才成为实现良好性能、避免资源浪费的必要前提。

您可以参阅此份说明文档中的对应部分，或者观看EKS/Fargate re:Invent突破性讲解，以了解在Fargate部署中设定Kubernetes容器大小的更多详细信息。总结来讲，其中的基本逻辑就是读取各个容器中的“请求”，而后应用这些资料中提出的资源分配方法。

另外，您所指定的Pod大小（通过显式请求实现）还应高度契合您的工作负载模式。在理想情况下，我们需要尽可能充分运用所指定的资源容量。而要保证这一点，大家必须持续监控Pod的资源利用率指标。您可以使用Datadog等工具（为EKS/Fargate提供开箱支持）监控各个Pod，也可以使用本文中推荐的Prometheus与Grafana实施监控。

请注意，运行在EKS/Fargate上的各Pod能够全面支持Kubernetes横向autoscaler与纵向autoscaler。开发人员可以使用前者根据工作负载增加及减少Pod数量，并使用后者提升或削减分配给特定Pod的资源总量。不过二者之间无法良好协同，因此如果您希望让Kubernetes自动调整各Pod的大小，只能根据实际资源消费模式二选其一。总之，我们的目标非常明确——尽可能将已分配资源的利用率提升至100%，一切措施都应为这项目标服务。

总结

在本文中，我们介绍了一项新功能，可帮助EKS客户在使用Fargate部署Kubernetes Pod时充分享受AmazonCompute Savings Plans带来的优惠政策。之前，只有通过Amazon ECS启动的Fargate任务才有资格享受AmazonCompute Savings Plans折扣。另外，我们还借此机会讨论了EKS/Fargate组合提出的价值主张，特别是如何运用无服务器方法显著降低业务体系的总体拥有成本（TCO）。

另外需要强调的是，Fargate并不是适用于一切应用场景的万灵药。在很多情况下，客户仍然有理由继续使用传统EC2实例，例如需要特定硬件支持（如GPU）或选择特定实例类型进行微调部署等。除此之外，使用Fargate进行EKS部署时还应关注其他一些注意事项以及一些可能不适合Farget的案例场景。