【SaaS架构】SaaS镜头-场景之Amazon EKS SaaS

对于许多SaaS提供商来说，Amazon Elastic Kubernetes Service（Amazon EKS）的简介非常符合他们的微服务开发和架构目标。它提供了一种构建和部署多租户微服务的方法，可以帮助他们实现其灵活性、规模、成本和运营目标，而不需要完全改变开发工具和思维方式。丰富的Kubernetes工具和解决方案社区还为SaaS开发人员提供了一系列不同的选择，用于构建、管理、保护和操作其SaaS环境。

对于基于容器的环境，架构的大部分重点是如何成功地确保我们防止跨租户访问。虽然允许租户共享集装箱是一种诱惑，但这意味着租户可以接受软多租户的概念。然而，对于大多数SaaS环境，隔离需求需要更健壮的隔离实现。

这些隔离因素可能会对亚马逊EKS构建的架构模型产生重大影响。使用亚马逊EKS建立SaaS架构的一般指南是防止租户之间共享容器。虽然这增加了架构占地面积的复杂性，但它解决了确保我们创建了一个隔离模型以满足多租户客户的领域、法规遵从性和监管需求的基本需求。

让我们看一个示例架构，以了解SaaS Amazon EKS环境的基本元素。由于这个解决方案有很多移动的部分，让我们先来看看用于支持跨越所有租户的核心水平概念的共享服务（如图4所示）。

首先，您会注意到，我们拥有任何高度可用、高度可扩展的AWS架构的基础元素。该环境包括一个由三个可用区域组成的VPC。来自租户的入站流量路由由Amazon Route 53管理，该路由被配置为将传入的应用程序请求引导到NGINX入口控制器定义的端点。控制器在我们的AmazonEKS集群中启用所选路由，这对于您将在下面看到的多租户路由至关重要。

图4：Amazon EKS SaaS共享服务架构

AmazonEKS集群中运行的服务代表了一些常见服务的示例，这些服务通常是SaaS环境的一部分。注册用于协调新租户的入职。租户管理管理系统中所有租户的状态和属性，并将这些数据存储在AmazonDynamoDB表中。用户管理提供了添加、删除、启用、禁用和更新租户的基本操作。它管理的身份存储在Amazon Cognito中。还包括AWS CodePipeline，以表示用于为系统上的每个新租户提供服务的工具。

此架构仅代表SaaS环境的基本元素。我们现在需要看看将租户引入这一环境意味着什么。考虑到前面描述的隔离考虑，我们的AmazonEKS环境将为每个租户创建单独的命名空间，并保护这些命名空间，以确保我们拥有一个健壮的租户隔离模型。

图5：在Amazon EKS中部署租户环境

图5中的图表提供了SaaS架构中这些名称空间的视图。从表面上看，这个架构与之前的基线图非常相似。关键区别在于，我们将作为应用程序一部分的服务部署到了单独的命名空间中。在本例中，有两个租户具有不同的名称空间。在每项服务中，我们都部署了一些示例服务（订单和产品）。

每个租户名称空间都由上面显示的注册服务提供。这将使用连续交付服务（如AWS CodePipeline）启动创建命名空间、部署服务、创建租户资源（数据库等）和配置路由的管道。这就是入口控制器发挥作用的地方。每个配置的命名空间为该命名空间中的每个微服务创建一个单独的入口资源。这使租户流量能够路由到适当的租户命名空间。

虽然名称空间允许您在AmazonEKS集群中的租户资源之间有清晰的边界，但这些名称空间更多的是一种分组构造。仅使用命名空间无法确保租户负载免受跨租户访问。

为了增强AmazonEKS环境的隔离性，我们需要引入不同的安全构造，以限制在给定命名空间中运行的任何租户的访问。图6中的图表提供了控制每个租户体验的方法的高级说明。

图6：隔离租户资源

这里介绍了两种特定的构造。在命名空间级别，您将看到我们创建了单独的pod安全策略。这些是可以附加到策略的本地Kubernetes网络安全策略。在本例中，这些策略用于限制租户命名空间之间的网络流量。这表示一种粗粒度的方式，以防止一个租户访问另一个租户的计算资源。

除了保护命名空间之外，还必须确保命名空间中运行的服务访问的资源受到限制。在这个例子中，我们有两个隔离的例子。Order微服务使用每个租户的表模型（思洛存储器），并具有限制特定租户访问的IAM策略。Product微服务使用混合租户数据的池模型，并依赖于应用于每个项目的IAM策略来限制租户访问。