Before you start deploying SonarQube Community Build on Kubernetes and Openshift | Documentation

Installation requirements

The SonarQube Community Build Helm chart comes with default values for CPU and memory requests and limits. Depending on your system, you may have to adjust them. 

For information about the database requirements, see Database requirements.

See the Helm chart documentation for information about the supported Kubernetes and Openshift versions.

Helm version 3 must be used.

Production use case

In a production use case:

• Ensure that the SonarQube Community Build Helm chart runs in a full restricted namespace (see Ensuring a restricted security level in Customizing the Helm chart).
• Use your own Ingress controllers.
  Ingress controllers are critical Kubernetes components, we advise users to install their own.
• Use your own database.

For more information, see the production use case guidelines in the Helm chart documentation, which we strongly recommend following.

Known limitations

As SonarQube Community Build is intended to be run anywhere, there are some drawbacks that are currently known when operating in Kubernetes. This list is not comprehensive, but something to keep in mind and points for us to improve on.

Readiness and startup delays

When persistence is disabled, SonarQube Community Build startup takes significantly longer as the Elasticsearch indexes need to be rebuilt. As this delay depends on the amount of data in your SonarQube Community Build instance, the values for the startup/readiness and liveness probes need to be adjusted to your environment. We also recommend looking at the default limits for the SonarQube Community Build deployment, as the amount of CPU available to SonarQube Community Build also impacts the startup time.

Problems with Azure Fileshare PVC

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 persistence on AKS.