Spring Boot应用程序的“本地服务”

我有机会尝试使用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-service
  namespace: 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