Knative Functions with Spring Boot: Dosnt get up! Readiness Probe Failures?

236 views Asked by At

I have been working on Knative functions and am experiencing some issues while deploying it. The application is a simple Java Spring Boot application (the default application that will be crated with kn func create), deployed on a Minikube cluster using a pack.

The problem I'm facing is that after deploying the function to my cluster, the Spring Boot application starts up, and all initialization steps are completed successfully. However, just after the startup, it shuts down instantly without any error message.

While observing the pod events, I noticed several failures related to the readiness probe:

Warning Unhealthy pod/test1-00001-deployment-59667f6745-xnfvd Readiness probe failed: Get "http://10.244.0.117:8012/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Warning Unhealthy pod/test1-00001-deployment-59667f6745-xnfvd Readiness probe failed: HTTP probe failed with statuscode: 503
Warning Unhealthy pod/test1-00001-deployment-59667f6745-xnfvd Readiness probe failed: Get "http://10.244.0.117:8012/": dial tcp 10.244.0.117:8012: connect: connection refused

Notably, I've also tried manually building the image with pack and then deploying it using a Knative Serving manifest, and this works perfectly. The application starts and remains active as expected. This issue only occurs when deploying with kn func.

Additional information:

I've just discovered something interesting - when I build the function as a Cloud Native Image by setting BP_NATIVE_IMAGE = "true" in the func.yaml file, the application runs perfectly in the cluster with no issues at all. The immediate shutdown problem doesn't occur.

2

There are 2 answers

0
Danny Steinbrecher On BEST ANSWER

I finally had the chance to revisit this issue, and I'm glad to report that I've found a solution.

Solution:

The root cause of the problem was the insufficient resources (Memory and CPU) I had allocated for my minikube local cluster. This led to the abrupt termination of the application without any apparent errors.

To address this, you need to restart Minikube with appropriate resource values:

Copy code
minikube stop
minikube delete
minikube start --memory 8192 --cpus 2

Alternatively, you can set these values permanently in the Minikube configuration, ensuring it always starts with the specified resources:

Copy code
minikube config set memory 8192
minikube config set cpus 2

I hope this information helps someone else encountering a similar issue!

0
E. Anderson On

Readiness probes run from the start of the Pod's lifecycle, so it's not surprising to see some failures at startup.

Have you tested running the containers locally with the same requests and limits? IIRC, native compilation also greatly reduces the RAM footprint, especially at startup. If you have limits set on your container, it's possible that you're getting an OOM at startup.