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

18-10-12 banq
              

有很多关于无服务器的讨论,所以我们先问一下:什么是无服务器计算? 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”之类的响应。

Knative: Serving your Serverless Services – Red Ha