We’re running SonarQube in Kubernetes and would like to use managed services of our Cloud provider as much as possible for stateful data, i. e. a managed PostgreSQL server and a managed Elasticsearch cluster.
Effectively, I’d like to only run stateless parts of SonarQube in Kubernetes and let the Cloud provider take care of “the hard stuff”, i. e. stateful databases.
Are you facing some specific problems with the way Elasticsearch is currently handled by SonarQube in Kubernetes?
Or does your request comes from a wish to rationalize the way you operate all your services?
It’s the latter: We want our pods in the Kubernetes cluster to be stateless and keep all databases out of the Kubernetes cluster (i. e. use the hosted services offered by our cloud platform).
With Elasticsearch “living” inside the same container as SonarQube itself, it could potentially be corrupted if the container is being stopped (for whatever reason). Even if Elasticsearch is not the system of record in this case, it would be one thing less to worry about when using the SonarQube Helm chart and running SonarQube in Kubernetes.
We would like to run SonarQube on our GCP Autopilot (a managed Kubernetes cluster) cluster. Which does not allow privileged Pods.
However, these are required to change (most) Linux Kernel settings. Elasticsearch requires a change of the vm.max_map_count setting. Which basically blocks running Elasticsearch on a GCP Autopilot cluster. Which in turn blocks running SonarQube on there, since it has Elasticsearch built in.