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

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