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