Deploy a SonarQube cluster on Kubernetes
This page applies to deploying SonarQube Data Center Edition on Kubernetes. For information on deploying Community, Developer, and Enterprise editions of SonarQube on Kubernetes, see this documentation.
You can find the SonarQube DCE Helm chart on GitHub.
Your feedback is welcome at our community forum.
When you want to operate SonarQube on Kubernetes, consider the following recommendations.
The SonarQube helm chart should only be used with the latest version of SonarQube and a supported version of Kubernetes. There is a dedicated helm chart for the LTS version of SonarQube that follows the same patch policy as the application, while also being compatible with the supported versions of Kubernetes.
Here is the list of containers that are compatible with the Pod Security levels:
- SQ application containers
- SQ init containers.
- PostgreSQL containers.
This is achieved by setting this
SecurityContext as default on most containers:
Based on that, one can run the SQ helm chart in a full restricted namespace, by deactivating the
initFs.enabled parameters, which require root access.
For more information, see the production-use-case or take a look at the
We try to provide a good default with the Helm chart, but there are some points to consider while working with SonarQube on Kubernetes. Please read the following sections carefully to make the correct decisions for your environment.
Currently only Helm 3 is supported.
To install the Helm chart from Helm repository, you can use the following commands:
helm upgrade --install -n sonarqube-dce sonarqube-dce --set line allows you to customize the Helm chart values.
SonarQube comes with a bundled Elasticsearch and, as Elasticsearch is stateful, so is SonarQube. For Data Center Edition (DCE) clusters, it makes sense to persist the Elasticsearch data because the cluster will survive the loss of any single search node without index corruption. By default, persistency is enabled for the DCE, and managed with the Helm chart.
Enabling persistency decreases the project reload time so that accessing project data is much faster. Although there is no need to change the default value in DCE, you can manage persistency with the following parameter in the
Disabling persistency would result in a longer startup time until SonarQube is fully available which can be a very large factor considering the downtime for the index rebuild on DCE clusters.
To make the SonarQube service accessible from outside of your cluster, you most likely need an ingress. Creating a new ingress is also covered by the Helm chart. See the following section for help with creating one.
The SonarSource Helm chart has an optional dependency to the NGINX-ingress helm chart. If you already have NGINX-ingress present in your cluster, you can use it.
If you want to install NGINX as well, add the following to your
We recommend using the
ingress-class NGINX with a body size of at least 8MB. This can be achieved with the following changes to your
You can monitor your SonarQube cluster using SonarQube's native integration with Prometheus. Through this integration, you can ensure your cluster is running properly and know if you need to take action to prevent future issues.
Prometheus monitors your SonarQube cluster by collecting metrics from the
/api/monitoring/metrics endpoint. Results are returned in OpenMetrics text format. See Prometheus' documentation on Exposition formats for more information on the OpenMetrics text format.
Monitoring through this endpoint requires authentication. You can access the endpoint following ways:
Authorization:Bearer xxxxheader: You can use a bearer token during database upgrade and when SonarQube is fully operational. Define the bearer token in the
sonar.propertiesfile using the
X-Sonar-Passcode: xxxxxheader: You can use
X-Sonar-passcodeduring database upgrade and when SonarQube is fully operational. Define
sonar.propertiesfile using the
- username:password and JWT token: When SonarQube is fully operational, system admins logged in with local or delegated authentication can access the endpoint.
You can also expose the JMX metrics to Prometheus with the help of the Prometheus JMX exporter.
To use this option, set the following values in your
This downloads the Prometheus JMX exporter agent and adds it to the startup options of SonarQube. With this default configuration, the JMX metrics will be exposed on /metrics for Prometheus to scrape.
The config scope here defines a configuration that is understandable by the Prometheus JMX exporter. For more information, please Prometheus' documentation on the JMX exporter.
You can collect metrics on application nodes using PodMonitor for Prometheus. Search node monitoring is not currently supported. To monitor applications nodes, define PodMonitor as follows:
SonarQube prints all logs in plain-text to stdout/stderr. It can print logs as JSON-String if the variable
logging.jsonOutput is set to
true. This will enable log collection tools like Loki to do post processing on the information that are provided by the application.
With JSON Logging enabled, you can define a LogQL Query like this to filter only logs with the severity "ERROR" and display the Name of the Pod as well as the Message:
Since SonarQube 8.9, you can enable basic security for the Search Cluster in SonarQube. To benefit from this additional layer of security on Kubernetes as well, you need to provide a PKCS#11 Container with the required certificates to our Helm chart. The required secret can be created like this:
This documentation only contains the most important Helm chart customizations. See the Customize the chart before installing documentation and the Helm chart README for more possibilities on customizing the Helm chart.
Currently, there is a known limitation when working on AKS that resonates around the use of Azure Fileshare. We recommend using another storage class for persistency on AKS.
See Upgrading instructions > Upgrading from the Helm chart in Upgrade guide.
© 2008-2023, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution-NonCommercial 3.0 United States License. SONARQUBE is a trademark of SonarSource SA. All other trademarks and copyrights are the property of their respective owners.