Session Expired on Localhost with Kubernetes

Hello everyone,

Currently I am working towards a Kubernetes solution for a Cuba application I am developing with a client. The end goal is deployment on Google Cloud Platform. However, before that I want to test my solution locally.

On Windows 10 I am using Docker on Desktop. It is very handy and it comes with its own Kubernetes single node cluster. It was easy to build my Docker image and easy to convert Mario Davids Cubarnetes solution (deployment.yml file). Using kubectl I can start the database and the application. Howerver I cannot subsequently login to the application.

Navigating with Chrome to http://localhost:8080/ I see the “log in” screen as it should be, but I also get the message “Cookies disabled” with a message beneath “This application requires cookies to function”. In short, the application runs as it should, but it is as though I am locked out.

Chrome log in screen

Clicking on this warning merely changes the warning to “Session Expired”. This is also what I see in Microsoft Edge.

Using Google as my friend I believe the problem may be Vaadin, the message certainly originates from Vaadin.

I have already tried everything imaginable with Chrome: changing settings, deleting cookies etc. I have also played around with the Gradle file of my Cuba project. Tried things with ‘cuba.trustedClientPermittedIpList’ which is currently set as follows.

'cuba.trustedClientPermittedIpList':', 172.*.*.*, 198.168.*.*'

I checked context.xml, web.xml but no luck. In the login page I can type in a username and password but the “Log in” bottom remains unresponsive. In the logs of the Cuba pod run by Kubernetes there is no indication of a problem.

Reverting to using IntelliJ to run the Cuba application reveals no problem. I am hoping someone on this forum has had a similar experience and managed to find a solution. Kubernetes is not much discussed on the forum so this may be a longshot.


I have questions regarding your configuration:

  1. Do you deploy web and core modules separately?
  2. If yes, do you scale web modules? If not, do you run two copies of the same application?
  3. For the scaled approach: do you have a load balancer?

Thanks Andrey for the reply,

At this moment I do not deploy the web and core modules separately. I also run just the one copy, though I also tried with HPA autoscaling. The Kubernetes service is of type LoadBalancer.

I tried out a few things regarding your questions. Running web and core separately does not affect the outcome, the application starts but I still get the cookies expired message on the login screen.

Yesterday I also tried to use Minikube and Kubernetes in Docker without a difference.

Today I will try out a few more things such as using Mario David’s project under the same circumstances. I hope that will tell us if it is project related or simply that running a local Kubernetes won’t work without additional configuration.




I tried my custom configuration and everything looks fine (see attach). The only difference is that I use Service kind, not LoadBalancer. I had a similar issue in the deployed scheme with an nginx as a load balancer but without a sticky session feature. I’ll try to use LoadBalancer in my example and return to you.

In the example, I use my own app image and push it to the local Docker registry. If you want to try the attached app, please update the kube-deploy.yml accordingly. (80.6 KB)

1 Like

Thanks for sharing that test project,

I noted your use of NodePort and tried it myself. Sadly, the problem remains with my solution. I then decided to test out your solution and try to discover differences.

However the log for kubetest show an error with connecting to the database, though later I do see that the init scripts are run. Opening localhost:30001 reveals an Jetty 404 error.

I performed the following steps after extracting kubetest:

  1. Load kubetest into IntelliJ and let it do its thing.
  2. Run buildDockerImage. Image kubetest is built and is of size 214 MB
  3. Made a slight alteration to kube-deploy.xml. Changed one line and added another:
    image: kubetest:latest
    imagePullPolicy: Never
  4. kubectl -f create kube-deploy.yaml to run the application on the local cluster

I have included the log file here log.txt (25.4 KB). I hope you can give a tip on how to resolve the issue.

Ooh, and what did you mean with “please update the kube-deploy.yml accordingly”?

Yep, it might happen due to a container start order, Java app starts faster than the DB. But in the end it’s all OK.

Use localhost:30001/kubetest

I meant exactly what you did in p.3 :slight_smile:

Aaah of course it is localhost:30001/kubetest. Where is that emoji with the hammer!

Yes, I got your test project working. I will have a look and see if I can update my own project accordingly.

1 Like

Andrey to bother you one more time.
What would your test solution look like with deploying web and core modules separate?


I had a similar issue when I created a deploy like shown in stage 4 section described in the documentation. Instead of Apache HTTP, I had nginx and there was no sticky-session option set up on nginx.

Therefore, requests could have been routed to any web module. Assume that my first request was served by the web module A and the next request was redirected to web module B. Since we do not cluster web modules due to a significant amount of memory consumed by a user session on a web module server, your session may seem expired because it didn’t exist on the web module B.

Have you been able to reproduce the issue? If yes, could you share the app I sent you with your kubernetes config?

I have solved my problem,

My Dockerfile had a very restrictive setting for Apache Tomcat, it required the use of SSL which is normally provided by a proxy on our current hosting solution.

    sed -i 's/<Connector/<Connector server="Apache" secure="true"/g' \
         ${CATALINA_HOME}/conf/server.xml && \

Removing the offending line solved the problem. I managed to discover the problem by converting your project ‘kubetest’ to separately use web and core. After the problem recurred I systematically moved through the Dockerfile to find something that might cause the problem.

I hereby consider this thread solved. In discussion with my client there might be a chance that our Docker and Kubernetes solution will become opensource, that way others may also use it and hopefully provide feedback.

Thanks for all the help Andrey!

That’s cool. Glad you managed to solve it. Good luck and looking forward to your solution in the opensource!