我有機會嘗試使用Knative的 Serving功能來部署Spring Boot應用程序，而這篇文章只是記錄了示例和我采用的方法。

我對Knative的內部知識還不夠了解，無法就此方法是否比基于部署 + 服務 +基于入口的方法更好。

一項很棒的功能是Knative Serving中的自動縮放功能，該功能基于負載，增加/減少了Pod的數量，這是處理請求的“部署”的一部分。

樣品細節

我的整個樣本都可以在這里找到 ，并且大部分是基于Knative Serving文檔中可用的Java樣本開發的。 我將Knative與minikube環境一起使用來嘗試示例。

部署到Kubernetes / Knative

假設已經設置了具有Istio和Knative的Kubernetes環境，則運行該應用程序的方法是通過以下方式部署Kubernetes清單：

apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata:name: sample-boot-knative-servicenamespace: default spec:runLatest:configuration:revisionTemplate:spec:container:image: bijukunjummen/sample-boot-knative-app:0.0.1-SNAPSHOT

圖像“ bijukunjummen / sample-boot-knative-app：0.0.1-SNAPSHOT”可通過Dockerhub公開獲得，因此該示例應立即可用。

應用此清單：

kubectl apply -f service.yml

應該向Kubernetes注冊一個Knative服務服務資源，該Knative服務服務資源管理其他Knative資源（配置，修訂，路由）的生命周期，可以使用以下命令查看其詳細信息，如果有任何錯誤，則應顯示詳細信息在輸出中：

kubectl get services.serving.knative.dev sample-boot-knative-service -o yaml

測試中

假設Knative服務服務的部署是干凈的，首先看到的是該應用程序沒有顯示Pod！

如果我現在要向應用程序發出請求，這是通過Knative管理的路由層完成的，那么可以使用以下bash腳本在minikube環境中檢索該請求：

export GATEWAY_URL=$(echo $(minikube ip):$(kubectl get svc knative-ingressgateway -n istio-system -o 'jsonpath={.spec.ports[?(@.port==80)].nodePort}')) export APP_DOMAIN=$(kubectl get services.serving.knative.dev sample-boot-knative-service -o="jsonpath={.status.domain}")

并使用CUrl調用應用的端點：

curl -X "POST" "http://${GATEWAY_URL}/messages" \-H "Accept: application/json" \-H "Content-Type: application/json" \-H "Host: ${APP_DOMAIN}" \-d $'{"id": "1","payload": "one","delay": "300" }'

或httpie

http http://${GATEWAY_URL}/messages Host:"${APP_DOMAIN}" id=1 payload=test delay=100

應該神奇地使用自動縮放器組件開始旋轉Pod來處理請求：

第一次請求花費了將近17秒才能完成，這是旋轉一個Pod所花費的時間，但是隨后的請求很快。

現在，為了顯示自動縮放器的真正功能，我運行了一個帶有50個用戶負載的小型負載測試，并且根據需要按比例放大和縮小了Pod。

結論

我可以看到Knative的承諾，即在Kubernetes環境中使用相當簡單的清單定義了自動管理資源后，讓開發人員專注于代碼和邏輯。

翻譯自: https://www.javacodegeeks.com/2018/07/knative-serving-spring-boot-applications.html

總結

以上是生活随笔為你收集整理的Spring Boot应用程序的“本地服务”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。