Serverless遇上ServiceMesh，是珠联璧合还是流于形式？

作者：ANDRÉS MARTÍNEZ

翻译：江水

原文：Serverless Service Mesh With Kubeless And Istio

在过去的几个月中，你可能已经听说过 service mesh。service mesh 简单来说就是一个基础设施组件，可以快速可靠的连接多个微服务。这种架构提出了一种非常有趣的方法，适用于在云原生场景中设计新的应用程序。在本文中，我们将演示如何使用 Kubeless：一个跑在 Kubernetes 上的 serverless 框架，以及 Istio：一个提供网络连接，管理和安全控制的开源平台 Kubernetes 服务，你可以花几分钟轻松地部署你的第一个 service mesh。

在 Bitnami，我们开发了 Kubeless：一个 serverless 平台，可以让你轻松在 Kubernetes 集群上运行微服务。如果这是你第一次听说 Kubeless，你想了解更多的基本知识，可以看我之前的帖子, 或者访问 Kubeless. io 官网。

除了 Kubeless，Istio 是一个为微服务提供网络资源的开源平台。Istio 允许你以一种简单的方式管理、监控和安全控制你的微服务。

作为开发者，你可能知道，在群集中维护具有不同版本和授权策略的服务可能很困难，而且容易出错。必须仔细管理所有服务之间的所有可能的路由。

结合 Kubeless 和 Istio 创建 service mesh 可以大大节约发布与网络管理的成本。Kubeless 只需要你输入一个发布命令就可以让 Istio 用过配置文件管理你的请求路由和策略。在本文中，我将通过如下命令演示：

配置环境以部署 service mesh。

从应用程序部署多个serverless 函数。

路由用户请求以显示服务的不同版本。

保护应用程序的部分在不被授权的情况下不能访问。

1. 目标架构

为了演示 Kubeless 和 Istio，我将部署一个应用程序，将模拟管理一个cold room。请参见建议架构的示意图：

应用将由三组不同的服务组形成：

测量和报告 room 温度的服务叫温度计服务（被称作 temp），我会部署两个不同版本的服务。版本 v2 还将报告 room 的温度。

一个恒温器服务，会根据 room 的温度，增加或减少系统的输出。此服务将受到保护，只有控制服务才能访问它。

控制服务会从温度计服务中检索温度并将结果发送到恒温器服务。在一个纯粹的 service mesh 架构中，这个组件是不必要的，因为恒温器服务会直接从温度计服务接收温度。在任何情况下，做这个例子都一些复杂并有趣, 我会包括它。

2. 准备环境

对于本练习，我将使用 Google 云平台 (GCP) 中的 Kubernetes 集群，使用谷歌 Kubernetes 引擎 (GKE)。如果你没有 GCP 帐户，或者你更喜欢在本地部署，则可以使用 Minikube 完成此练习。

在 GKE 上部署集群，我会用 Google Cloud SDK 的 gcloud 工具。如果你要用 GKE 完成此操作，请确保安装如下工具：

我将启用 alpha 功能（30天后将群集标记为删除），因为这是使用 autoinjection 功能所必需的。Autoinjection 可以是我们不必在部署服务的时候手动插入 Istio 详细信息。除此之外，为了确保我不会耗尽资源，我将使用5节点。

我现在将部署 Istio。我使用的是最新版本的。下面是要执行的命令：

注意:如果你在 Linux 或 Windows 系统中遵循本指南，请使用不同的压缩。如果你在创建 ClusterRoleBinding 时遇到问题，可以按照本指南进行。

让我们在这个新的集群中部署 Kubeless。如果你遵循本指南，则必须执行在 GKE 中部署 Kubeless 并安装 Kubeless CLI 工具的步骤。

此时需要在群集中部署 Kubeless 和 Istio：

3. 部署 service mesh

是部署应用程序服务的时候了。本指南中使用的所有文件都可在此 Github 仓库中获得。你可以克隆存储库，以使这些文件在本地可用：

让我们部署两个版本的温度计服务，将返回 room 的温度：

请注意，我设置 labelversion=v1和version=v2，所以我可以区分他们的版本。我也设置 labelapp=temp，使这两个函数有一个共同的 label。

除了这些部署之外，我还将创建一个服务，用于使用单个端点访问这两个函数：

最后，我将创建恒温器服务和控制功能：

几秒钟后，就可使用 kubeless CLI 访问这些服务:

请注意，有时当调用控制函数时，它会返回湿度，但其他的则不会。它取决于内部调用的 temp 服务（上文提到过 温度计服务）的版本。

4. 使服务适应 Istio

Kubeless 自动创建访问包含函数服务的函数所需的所有资源。但是，为了使用 Istio，服务端口的 name 属性必须是一个众所周知的值。因此，我必须更改在端口列表中的当前值。我可以通过编辑当前服务来更改它：

现在所有的服务都已更新，我需要重新启动函数 pod。这是因为 pod 会在 initContainer 中注册他们的信息。initContainer 只在启动一个 pod 时执行，因此，要正确地注册服务信息，我需要重新启动所有的 pod：

几分钟后，pod 再次运行，并在 Istio 正确注册。

5. 请求负载均衡

在这一步中，我将使用 Istio 提供的请求路由配置。这允许我管理不同版本的临时服务的请求。我将部署一个非常简单的规则，将90% 的请求重定向到 v1of 服务的版本，另外10% 个版本 v2。此功能在测试新功能或使用 a/b 测试时非常有用，因为它允许你在不影响所有用户的功能的情况下运行同一服务的多个版本：

route-rule-10-v2.yaml:

现在，如果我多次执行 kubeless 函数调用控制命令，它将只打印几次湿度。你可以更改这些数字（例如，将所有流量重定向到 v2 版本），并在调用 controlservice 时查看更改。

6. 基本访问控制

对于本练习，我将限制对恒温器服务的访问。这只是一个例子，所以我将使用基本的访问控制。请注意，如果我使用 TLS 身份验证部署 Istio，我可以使用服务帐户并配置安全访问控制，但为了简单起见，我不会在这里做。

通常，恒温器服务只能通过控制服务来访问。为了确保这一点，我将部署以下清单:

deny-rule.yaml:

我所做的是阻止任何不是来自恒温器服务的控制功能的请求（除非请求是 Kubernetes 使用的 /healthz 路径, 以检查服务是否活着）。

我们可以通过执行以下操作来确保规则的工作：

请注意，此规则不保护恒温器服务不受群集用户的控制，并具有创建 pod 的权限。这些用户中的任何一个都可以创建一个 label 是 function=control 的 pod，它将能够访问恒温器服务。为了正确地保护此服务，我应该使用安全访问控制，并指派一个 serviceAccountName（其他用户不能使用）到 controldeployment。

7. 准备好了么？

我刚刚介绍了 Kubeless 和 Istio 的一些基本功能，但是现在你应该可以使用这两种工具来启动 service mesh 了。下一步是使用服务帐户并设置具有安全访问控制的群集。这样我就可以为这些功能提供更严密的安全性。

除此之外，还有很多功能可以处理，例如，添加监控和指标，自定义路由，自动扩缩容...想浏览更多信息，请看 Istio 和 Kubeless 的网站和文档。

原文地址：https://engineering.bitnami.com/articles/serverless-service-mesh-with-kubeless-and-istio.html