我有机会尝试使用Knative的 Serving功能来部署Spring Boot应用程序,而这篇文章只是记录了示例和我采用的方法。
我对Knative的内部知识还不够了解,无法就此方法是否比基于部署 + 服务 +基于入口的方法更好。
一项很棒的功能是Knative Serving中的自动缩放功能,该功能基于负载,增加/减少了Pod的数量,这是处理请求的“部署”的一部分。
我的整个样本都可以在这里找到 ,并且大部分是基于Knative Serving文档中可用的Java样本开发的。 我将Knative与minikube环境一起使用来尝试示例。
假设已经设置了具有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