Comments on: Spring Boot SSL Hot Reload on Kubernetes https://piotrminkowski.com/2024/02/19/spring-boot-ssl-hot-reload-on-kubernetes/ Java, Spring, Kotlin, microservices, Kubernetes, containers Wed, 10 Jul 2024 12:06:58 +0000 hourly 1 https://wordpress.org/?v=6.9.1 By: maciej https://piotrminkowski.com/2024/02/19/spring-boot-ssl-hot-reload-on-kubernetes/#comment-2453 Wed, 10 Jul 2024 12:06:58 +0000 https://piotrminkowski.com/?p=14995#comment-2453 In reply to Tom.

2 workarounds I figured out:
– write custom file watcher that compares file digests and copy to another directory observed by spring
– configure spring to watch ..data instead like: file:${CERT_VOLUME}/..data/tls.crt

]]> By: maciej https://piotrminkowski.com/2024/02/19/spring-boot-ssl-hot-reload-on-kubernetes/#comment-2452 Tue, 09 Jul 2024 14:08:02 +0000 https://piotrminkowski.com/?p=14995#comment-2452 In reply to Tom.

I found the same issue in our AKS cluster v1.27.9 and in minikube.

]]> By: piotr.minkowski https://piotrminkowski.com/2024/02/19/spring-boot-ssl-hot-reload-on-kubernetes/#comment-2450 Tue, 09 Jul 2024 06:48:57 +0000 https://piotrminkowski.com/?p=14995#comment-2450 In reply to Tom.

It may depends on the testing environment. What k8s dist you were using in your tests?

]]> By: Tom https://piotrminkowski.com/2024/02/19/spring-boot-ssl-hot-reload-on-kubernetes/#comment-2439 Sun, 30 Jun 2024 12:50:54 +0000 https://piotrminkowski.com/?p=14995#comment-2439 Hi Piotr,

thanks for that inspiring article. I was experimenting a bit with this approach but got stuck at the point how K8s is mounting the secret files. When I change or adjust the secret within K8s this is does not reflect to the symbolic link of the mount point. For instance:

lrwxrwxrwx 1 root root 21 Jun 29 09:54 secret.p12 -> ..data/secret.p12
drwxr-xr-x 1 root root 4096 Jun 29 09:54 ..
lrwxrwxrwx 1 root root 32 Jun 29 10:05 ..data -> ..2024_06_29_10_05_40.2447402240
drwxr-xr-x 2 root root 60 Jun 29 10:05 ..2024_06_29_10_05_40.2447402240
drwxrwxrwt 3 root root 100 Jun 29 10:05 .

On can see, that K8s updated the target of the link (10:05) but the link itself, which the Spring application/FileWatcher is observing, does remain untouched and therefore the FileWatcher is never going to be trigger. I observed the same behavior with deleting and recreating of the secret. I could only trigger the mechanism when I rename the .p12 file in the secret and rename it back. Under this scenario K8s is modifying the link (because it needs to be renamed) and then the FileWatcher does fire. But that is not an option. So I was wondering if I missed an important point in your article that could explain that behavior or what I’m doing wrong.

]]>