发布于: Jun 20, 2022
下面，我们将整理出一份粗略的全面清单，列出您选择使用 Fargate 等托管服务时无需继续关注的传统问题。这些问题都有着相应的“拥有成本”，属于同“购置成本”并行存在的重要因素。
去年，我们正式推出了 EKS 托管节点组，旨在减轻 Kubernetes 工作节点所带来的管理负担。托管节点仍然运行在您的亚马逊云科技账户之内，并由您承担节点的保护与修复责任；尽管亚马逊云科技将为您提供经过更新的 AMI（Amazon Machine Imagine）以替换各工作节点，借此简化运营流程。您仍将保留对这些实例的 root 访问权限，而 EKS 则协助处理生命周期管理工作，因此这种新机制并不属于亚马逊云科技完全托管方案。与这种托管节点不同，在使用 Fargate 时，亚马逊云科技将包揽所有运营任务，您不必插手AMI或底层主机操作系统修复等事务。同样的，使用 Fargate 时亚马逊云科技将保证您的每一个新 Pod 都运行在经过完全修复及强化的基础设施之上。换言之，您无需考虑应该在运行Pod的节点上使用哪种 AMI。
这里需要强调的是，即使是在托管状态下，节点更新仍然需要通过滚动部署新的 AMI 来实现。而这种操作方式会给Pod带来影响，因为 Pod 会在节点终止之前发送一条终止信号以撤出当前节点。对于纯横向扩展及无状态应用程序来说，这项操作一般不会构成问题，但其他类型的应用程序，当基础设施经历滚动更新时，是有可能因此受到冲击的。对于一般每 30 天定期进行一波 AMI 轮替的金融机构而言，这种滚动部署有可能给日常运营带来额外负担。
除了AMI 管理之外，结合前文所述，大家还需要考虑通用工作节点管理及其相应成本问题。在使用托管节点与自动规模伸缩组（ASG）时，虽然您的运营工作量将得到显著削减，但仍需要在实例之上运行Kubernetes生态系统提供的多种工具以实现适当的基础设施操作。以节点问题检测器为例，虽然其占用的资源不算很多，但在运营用于支持 Pod 的基础设施时，该检测器仍然会增加你的工作量。
使用 Fargate，基础设施的管理工作将完全归于亚马逊云科技。基础设施将定期接收更新；在启动 Pod 时，亚马逊云科技会在全新虚拟机中预先部署全部最新软件版本，以保证 Pod 始终在最新技术栈内启动。
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 部门可以构建起多租户集群，从根本上消除这个恼人的难题。
换言之，他们可以将云账单中的成本与内部用户一一对应起来。
相关文章