使用Knative提供无服务器服务的简单案例

有很多关于无服务器的讨论，所以我们先问一下：什么是无服务器计算？ CNCF定义：

“ 无服务器计算是指理念构建和运行的应用程序是不需要服务器管理。它描述了一个更细粒度的部署模型，其中捆绑为一个或多个功能的应用程序上载到平台，然后执行，缩放和计费，以响应当前所需的确切需求 “

让我们剖析定义，看看什么是理想的无服务器平台：

1. 构建和运行应用程序

一个运行和编排应用程序的平台，即Kubernetes，它是您的新应用程序服务器。

2. 没有服务器管理

没有专用的应用程序服务器，所有应用程序都通过Kubernetes Deployments和Services进行容器化和部署。

3. 根据确切的需求执行，缩放和计费

从零开始然后缩小到零的能力是Kubernetes通过其ReplicationSet的自然特征。

Kubernetes目前无法为无服务器平台提供的功能之一是更精细的部署模型。但是通过Knative Serving，Kubernetes终于拥有了运行无服务器工作负载所需的功能。

使用Istio的Knative Serving为我们的服务提供部署模型，以便作为无服务器工作负载运行。

让我们开始介绍如何在Kubernetes上部署我们的第一个无服务器应用程序。对于这个博客，我将使用 OKD ，这是Kubernetes的社区发行版，为红帽 OpenShift提供支持。 要在本地运行OKD，我们可以使用 minishift ，一个可用于开发目的的单节点OKD集群。

这些 说明 将详细介绍如何在minishift上安装和配置Knative Serving。

应用概述

我们将构建的演示应用程序是使用Spring Boot构建的greeter应用程序。您可以在GitHub 存储库中 找到该应用程序的源代码。

Git使用以下命令克隆资源：

git clone https://github.com/kameshsampath/knative-serving-blogs

此博客中显示的示例的所有源都位于源存储库根目录中的“part-1”目录中。

为方便起见，我们将在本文的其余部分将目录称为$ PROJECT_HOME 。

Containerize应用程序

在我们将此应用程序转换为无服务器服务之前，我们需要对应用程序进行容器化。

要能够连接到OKD群集的 Docker 守护程序，请运行以下命令：

(minishift docker-env) &&

要构建greeter应用程序的应用程序容器镜像，请运行以下命令：

./mvnw -DskipTests clean compile jib:dockerBuild

此应用程序使用 jib ，一种将 Java 应用程序构建为容器镜像的工具。

成功运行上述命令后，执行docker images | grep dev.local / greeter 应该列出我们刚刚构建的一个镜像。

部署无服务器服务

运行：

kubectl apply -f service.yaml -n myprojectoc get -n myproject pods -w

我们将触发我们的第一个无服务器服务的部署，可以使用该命令查看pod状态：

oc get -n myproject pods -w

成功的服务部署应该创建像“greeter-00001-deployment”这样的Kubernetes部署！

一旦所有pod都启动（通常需要几分钟），我们就可以运行脚本$ {PROJECT_HOME} /bin/call_greeter.sh

会看到响应：“Java :: Knative on OpenShift”。

恭喜！您现在已经在Kubernetes上推出了您的第一个无服务器应用程序！

总结

现在，解释刚刚发生的事情。让我们首先了解Knative-Serving的主要构建块，使您的传统基于服务器的Spring Boot应用程序成为现代无服务器应用程序。这些构建块中的每一个都是 定制资源定义（CRD） ，它是作为Knative-Serving的一部分定义和部署的：

1.配置（configuration.serving.knative.dev ）

该配置是无服务器应用程序的核心，通过标记部署的最新版本，或将其固定到一个已知版本，有助于定义所需的状态。这也有助于应用程序通过保持代码和配置分离来遵循十二因子App方法的原则。

2.修订版（revision.serving.knative.dev ）

修订思路类似：通过配置上改变的服务命名，类似于git的commit。修订历史由Knative-Serving维护，这有助于在任何指定的时间点部署所需的修订版本。遵循十二因子App方法，每个配置更改都会触发新修订的创建。

3.路由

路由通过DNS名称定义了网络端点，可让客户消费服务。同一服务可能有太多路由。使用Service部署服务时，会创建与配置匹配的默认路由，100％的流量路由到配置的修订版。

路由配置是通过“knative-serving”命名空间中的ConfigMap “config-domain”定义的，ConfigMap定义了可用作路由域的可能域名。

kubectl -n knative-serving get cm config-domain -o yaml | yq r - data

所有路由都通过“knative-ingressgateway”访问，路由的默认DNS名称将是[servicename].[namespace].[domain value from config-domain]，比如：

greeter.solutions.example.com

4.服务Service（service.serving.knative.dev ）

在部署无服务器工作负载时，我们通常需要创建和部署上述所有资源。但是使用Service还可以自动创建其他资源对象，从而管理无服务器工作负载的整个生命周期。

现在我们已经探索了更细粒度的Knative Serving部署模型以及它如何帮助部署无服务器服务。为了更好地理解它与我们的演示应用程序，我们将开始看到核心资源文件“service.yaml”：

kind: Service
metadata:
name: greeter
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: dev.local/greeter:0.0.1

此Service创建一个名为“greeter” 的service.serving.knative.dev 服务，该服务将最新版本作为其无服务器工作负载的一部分运行。

该配置定义了“revisionTemplate”，用于定义将部署和提供请求的容器镜像。“revisionTemplate”是configuration.serving.knative.dev 中非常重要的元素，它允许Knative-Serving在“revisionTemplate”中的任何内容发生变化时自动滚动新版本，例如向容器添加环境变量或更改镜像名称等等.

要查看它的实际操作，可以使用名为“MESSAGE_PREFIX”的额外环境变量更新“service.yaml”：

kind: Service
metadata:
name: greeter
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: dev.local/greeter:0.0.1
env:
- name: MESSAGE_PREFIX
value: Hello

再次部署greeter服务:

kubectl apply -f service.yaml

导致新的修订版如“greeter-00002”将被创建，并且将推出新的Kubernetes部署，如“greeter-00002-deployment”。

可以使用命令kubectl get revisions.serving.knative.dev 检查可用的修订版本。

通过$ {PROJECT_HOME} /bin/call_greeter.sh 调用服务，会查看到“Hello，Java :: Knative on OpenShift”之类的响应。