使用Knative提供無伺服器服務的簡單案例

有很多關於無伺服器的討論，所以我們先問一下：什麼是無伺服器計算？CNCF定義：

“ 無伺服器計算是指理念構建和執行的應用程式是不需要伺服器管理。它描述了一個更細粒度的部署模型，其中捆綁為一個或多個功能的應用程式上載到平臺，然後執行，縮放和計費，以響應當前所需的確切需求 “

讓我們剖析定義，看看什麼是理想的無伺服器平臺：

1. 構建和執行應用程式

一個執行和編排應用程式的平臺，即Kubernetes，它是您的新應用程式伺服器。

2. 沒有伺服器管理

沒有專用的應用程式伺服器，所有應用程式都通過Kubernetes Deployments和Services進行容器化和部署。

3. 根據確切的需求執行，縮放和計費

從零開始然後縮小到零的能力是Kubernetes通過其ReplicationSet的自然特徵。

Kubernetes目前無法為無伺服器平臺提供的功能之一是更精細的部署模型。但是通過Knative Serving，Kubernetes終於擁有了執行無伺服器工作負載所需的功能。

使用Istio的Knative Serving為我們的服務提供部署模型，以便作為無伺服器工作負載執行。

讓我們開始介紹如何在Kubernetes上部署我們的第一個無伺服器應用程式。對於這個部落格，我將使用ofollow,noindex" target="_blank">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”之類的響應。