使用适用于 亚马逊云科技 本地区域的 Amazon EKS 管理边缘感知服务网格

简介

在之前的一篇文章《在 亚马逊云科技 W avelength 上 部署地理分布式 Amazon EKS 集群》 中 ，我们介绍了如何将亚马逊弹性 Kubernetes 服务 (Amaz on EKS ) 集群扩展到更接近最终用户的 5G 网络连接应用程序中。但是，这种使用自我管理节点组的确切模式也适用于 亚马逊云科技 Local Z ones ，这是一种将 亚马逊云科技 计算和存储带到大都市中心的基础设施解决方案。 在 亚马逊云科技 Wav elength 和 亚马逊云科技 本地区域 ，我们客户的集体反馈之一是简化东西向流量通信，无论客户选择何种节点。

为了在边缘的 Amazon EKS 的基础上再接再厉，这篇文章提供了这种多边部署模式的参考实现，以及如何使用服务网格技术来抽象边缘本身的复杂性。这篇文章演示了如何将 Amazon EKS 集群的数据平面（横跨 亚马逊云科技 本地区域、亚马逊云科技 波长区域和父 亚马逊云科技 区域）与服务网格一起使用，以简化边缘感知路由。

边缘的中心辐射网络

随着 亚马逊云科技 本地区域和 亚马逊云科技 波长区域的共同出现，对于可以引入低延迟访问的地理区域，开发人员比以往任何时候都有更多的选择。尽管波长区域直接嵌入在电信提供商的 5G 网络和本地区域可以访问互联网，但这两种 亚马逊云科技 边缘计算服务都具有阻止区域间 VPC 连接的关键网络特征。亚马逊云科技 Wavelength 和 亚马逊云科技 Local Zones 在中心辐射架构中运行，所有分支只能在其区域内通信或返回集线器（即父区域）。这给希望大规模利用低延迟地理分布式应用程序的开发人员带来了挑战。

为了举例说明这一挑战，假设部署在三个本地区域的两层应用程序可能会遇到以下情况：

• 来自本地区域 3 中的 Web 服务的流量可能会寻求连接到 应用程序 。在集群中，Kubernetes 域名系统 DNS 可能会看到五个与该服务对应的 Pod，跨三个本地区域 (LZ) 和两个可用区 (AZ)。
• 虽然 DNS 可以将这些流量定向到在本地区域 3 中运行的 应用程序 Pod，从而实现最低的延迟，但 DNS 也可以尝试将这些流量定向到本地区域 1 或本地区域 2 上的 应用程序 容器，这将导致终端节点无法访问。或者，DNS 可以尝试将流量引导到 亚马逊云科技 区域中的 应用程序 Pod（例如 AZ1 或 AZ2）。尽管这是可能的，但流量通过 服务链接 从本地区域穿越到父 亚马逊云科技 区域会产生延迟损失。

因此， 工作负载布局 对于具有低延迟要求的应用程序非常重要，可以确保根据客户要求将所有延迟敏感型组件调度到每个边缘区域。为了说明地理分布环境中工作负载布局的影响，可以考虑一家汽车公司的架构，这些公司希望缩短基于机器学习的工作流程的延迟，以实现自动行人检测或车辆与任何事物 (V2X) 连接。也许两层 Web 应用程序由应用程序编程接口 (API) 代理和机器学习推理服务组成，每个地理位置都分布在每个可用的 AZ 和 LZ 上，为给定 亚马逊云科技 区域内的车辆创建统一、低延迟的访问权限。

除了工作负载布局外，流量路由也是同样重要的设计考虑因素。如今，寻求部署上述相同的两层 Web 应用程序的客户可能需要 10 个清单文件：每个服务实例一个，以确保将每种资源适当安排到正确的边缘位置或可用区。其次，开发团队需要专门的配置文件，这些文件可以确定地将每项服务指向下一个逻辑服务（例如，“将 流量从本地区域 2 中的 API 服务 直接指向本地区域 2 中的 ML 推理服务 ”）。

客户要求使用可以为集群引入边缘感知的 Kubernetes 原生参考模式。这种边缘感知可以理解这种独特的中心辐射式设计，而无需开发人员重新架构整个应用程序。

作为其中一种解决方案，我们将演示服务网格解决方案如何在不对应用程序本身进行任何更改的情况下控制横跨任意数量的本地区域或波长区域的东西向流量。

解决方案概述

为了说明更真实的微服务环境，可以考虑HashiCorp的电子商务演示应用程序 HashiCups 的参考架构。

• 前端 ：这是我们将在每个可用区和本地区域中公开的一项服务。这意味着，如果有两个本地区域和两个可用区域，我们将需要至少四个副本。
• 公共 API 和产品 API ：就像前端服务一样，我们可能希望为每个节点安排至少一个副本以实现高可用性。
• Postgres ：对于数据库本身，我们可能只偶尔需要数据源，因此，我们可以使用主副本和单个只读副本保留在该区域。

那么，我们怎样才能轻松地安排工作负载并确保例如，本地区域 1 中的 product-api 服务永远不会路由到本地区域 2 中的公共 API 服务呢？

命名空间控制和基于区域的路由

既然选择了所需的部署，Kubernetes 怎么能确保不尝试跨LZ流量？

一种方法是 Kubernetes 命名空间和节点选择器。命名空间为您的部署创建逻辑隔离，允许 DNS 解析通过服务名（例如 public-api）本地路由服务，而无需完全限定域名 (FQDN)，例如 public-api.my-namespace.svc.cluster.local，因为未指定命名空间的 DNS 查询仅限于 Pod 的命名空间。如果所有四个微服务都位于一个命名空间内，这是一个很好的解决方案。在我们的架构中，如果我们有 3 个命名空间（区域命名空间、边缘 1 命名空间、边缘 2 命名空间），每个命名空间都有四个微服务的副本，则所有路由都可以由 Kubernetes DNS (CoreDNS) 本地处理。

其次，我们通过在该地区内部署单一 postgres 来介绍复杂性。举个例子，这种方法是不可行的。当 product-api pod 试图连接到引用与命名空间无关的 FQDN（例如，postgres 而不是 postgres.namespace.svc.cluster.local）的 postgres 数据时，它会连接到 CoreDNS 寻求解析 postgres，但由于该命名空间中不存在这样的 postgres 工作负载。在这类情况下，需要额外的路由叠加层来管理基于给定服务或命名空间的复杂规则和场景。

边缘的服务网格

而开发人员可以在亚马逊 EKS 中使用各种服务网格技术，例如 亚马逊云科技 App Mesh 或 HashiCor p Consul。 HashiCorp Consul 是一款用于自动化网络配置、发现服务和启用安全连接的解决方案。您可以使用 HashiCorp Consul 的服务网格来确保在任何给定时刻将流量正确路由到相应的可用区、本地区域或波长。

通过将 Kubernetes 命名空间镜像到 Consul 命名空间，每项服务都会路由到同一 Consul 命名空间中其最近的上游服务，你可以借鉴现有的本机 Kubernetes 优势（90% 以上的路由决策），同时添加额外的兴趣路由。

apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
  name: postgres
spec:
  redirect:
    service: postgres
    namespace: demo-app-region

在此示例配置中，定义了一个 ServiceResolver，它将所有发往 postgres 的流量专门路由到 “演示应用程序区域” 命名空间中可用的服务。相同的配置清单无需对每个命名空间进行调整，因此旨在扩展到任意数量的本地区域。这样，服务解析器允许 Consul 命名空间解析为父区域中的共享服务。

边缘故障转移到区域

如果本地区域中的节点重新启动、应用程序部署错误或人为配置错误，如果计划到边缘的其中一项服务（例如 product-api）暂时消失，会发生什么？

当然，如果你访问你的应用程序，你会看到一个错误，因为如果当前命名空间中不可用，Kubernetes 没有原生的、确定性的方法来故障转移到另一个命名空间（和拓扑）中的 product-api 副本。这里发生的事情是，要么 Kubernetes 对另一个命名空间中的产品 api 副本一无所知，要么会将你循环到另一个本地区域中的副本，但该副本已被封锁。

这就是 HashiCorp Consul 提供的 customResourceDefinition (CRD) ServiceResolver 回归的地方。让我们用以下内容创建一个名为 failover-resolver.yaml 的文件：

cat > postgres-resolver.yaml <<EOF
apiVersion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
  name: product-api
spec:
  failover:
    "*":
      service: product-api
      namespace: demo-app-region
EOF

kubectl apply -f failover-resolver.yaml -n edge1-namespace

通过配置此故障转移规则，当本地区域中的 product-api 服务不可用时，服务网格会明确将流量路由到 亚马逊云科技 区域命名空间中的 product-api 服务。实际上，这些变化与 边缘无关 。创建清单后，您可以根据需要多次应用该清单，进行动态故障转移。请记住，这关乎最坏的情况。在大多数情况下，这种附加配置甚至不会被使用，因为给定本地区域中的公共 api 服务连接到同一个本地区域内的产品 api 服务。

结论

在这篇文章中，我们展示了如何将部署在多个 亚马逊云科技 本地区域的 Amazon EKS 集群与服务网格一起使用，以简化边缘感知路由。尽管 Consul Service Mesh 解决了地理分布式中心辐射架构的关键路由限制，但地理分布式部署仍然存在明显的客户痛点。在 Kubernetes 中，可以轻松地为给定服务部署任意数量的副本，但本机不支持边缘感知副本。如今，开发人员有责任为每项服务创建和维护污点、亲和力和容忍度，随着局部区域和波长区域数量的增加，这种负担非常繁重。

这种Consul集成的直接结果是，可以向开发人员更有力的理由说明为什么可以从一开始就开发边缘应用程序，并且在任何给定时刻都 至少 有 两个边缘区域。通过抽象网络本身的复杂性，开发人员可以专注于构建应用程序，同时我们可以减少在网络边缘进行无差别的繁重工作。

通过将边缘感知引入边缘应用程序，我们可以通过以下方式将 亚马逊云科技 架构完善的框架扩展到边缘：

• 边缘感知增强了可靠性： 通过在运营商网络（例如，亚马逊云科技 Wavelength）或地铁边缘（例如，亚马逊云科技 本地区域）中引入增量故障域，客户 可以在何处 或 如何 创建故障转移策略方面有更多选择
• 边缘感知增强了安全态势： 随着公共互联网的增量或累积跳数减少（尤其是从终端设备到云的南北流量），客户工作负载的安全态势也会增加
• 边缘感知可提高性能效率： 除了以边缘感知方式（即在微服务环境中，哪些服务必须存在于边缘与区域）调度工作负载外，还可以通过边缘感知方式对集群间流量（即东西向流量）进行路由，以找到最低延迟路径

要了解有关 亚马逊云科技 边缘计算环境边缘感知的更多信息，请访问使用 Consul 架构地理分布式移动边缘应用程序 或在 GitHub 上使用 Consul 的 演示应用程序 。