Kubernetes and OpenShift Deployment Patterns: Configuration, Design Patterns, and Trade-Offs

1. Carry forward the Chapter 04 state model

Containers taught us that runtime objects are replaceable while database, storage, secrets, network and host prerequisites remain distinct. Kubernetes multiplies those boundaries: scheduling can move the Pod; storage is abstracted behind claims/classes; routing is split into Services and edge APIs; and security policy can reject a Pod before SonarQube starts. The correct design question is therefore “who owns each state and failure domain?”

2. Decision table: deployment pattern choices

3. Helm versus raw manifests

Helm provides parameterized, maintained templates tied to SonarQube release assumptions. That is valuable, but Helm should not become an opaque deployment oracle. Store reviewed values, pin chart versions, render diffs, and inspect generated security/storage/network objects. Raw manifests can increase direct control but transfer compatibility maintenance to you: probes, security contexts, image tags, environment keys and upgrade semantics all become your responsibility.

4. Kubernetes versus OpenShift security constraints

Generic Kubernetes supports Pod Security admission levels; OpenShift adds SCC policy. The maintained chart has an explicit OpenShift.enabled path and advises OpenShift.createSCC=false. In both cases, the least-privilege design is to keep application containers restricted and move node-level sysctl and broken-filesystem ownership remediation to cluster/storage administration rather than escalating the application workload.

5. External database versus test-only H2

For production, SonarSource requires/strongly recommends your own supported database. The current Helm chart no longer bundles a PostgreSQL dependency; H2 is a test convenience, not a durable production platform. External DB design adds legitimate complexity—TLS, credentials, DNS, connection limits, backup, restore, maintenance and latency—but those are exactly the controls required for durable state.

Store the database password in a Secret and reference its name/key. Do not put database passwords in committed values.yaml, Helm command history, screenshots, or CI logs.

6. PVC and StorageClass design

A PVC says “give this workload storage with these properties.” It does not tell you whether the backing system is zonal, replicated, snapshot-capable, encrypted, expandable, low-latency, or recoverable after cluster loss. Those properties belong to the StorageClass and provider.

• Prefer a supported block/file storage backend appropriate to SonarQube search/index requirements.
• Understand reclaim policy before deleting a namespace/release.
• Use existingClaim only when ownership and lifecycle are explicit.
• Avoid hostPath for portable production state.
• Keep database backup independent from PVC snapshots.

7. Internal Service versus external routing and TLS

Use ClusterIP as the default internal service boundary. For production external access, decide who owns the edge controller, DNS, certificate issuance/rotation, request-size/timeouts, headers, client IP handling and TLS termination. Current SonarSource guidance no longer treats a bundled ingress-nginx dependency as the recommended production answer; Gateway API is the modern direction, while an Ingress resource may still target a controller your platform team operates.

OpenShift Route is a platform-specific edge abstraction. Route TLS termination mode must be selected deliberately; do not publish port 9000 directly simply because a Service exists.

8. Resources, probes, and scheduling are coupled

The current chart defaults around a 2Gi memory request and 6Gi memory limit for the single-node offerings, but sizing depends on edition, project volume, analysis throughput and JVM configuration. Memory is non-compressible: an optimistic low request can schedule a Pod onto a node that cannot sustain it, while a hard limit can OOM-kill the process.

Liveness and readiness probes are not performance SLOs. Readiness controls routing; liveness may cause restarts. If a slow startup or overloaded database causes probe failures, changing probes blindly may hide the root cause rather than fix capacity.

9. Single-node chart versus Data Center Edition

Community Build, Developer and Enterprise use the sonarqube chart. Data Center Edition uses sonarqube-dce and separates application/search nodes with additional cluster configuration and secrets. DCE is commercial and outside the mandatory lab. Do not infer DCE availability or licensing from the fact that its chart source is public.

High availability also depends on external database, load balancing, storage/network topology, node spread and operational procedures—not merely replica count.

10. Upgrade design: chart version, app version, DB and rollback

A Kubernetes rollback is not automatically a SonarQube downgrade. SonarQube database migrations and supported upgrade paths matter. Before an upgrade: read the SonarQube upgrade path, back up the database, verify chart/app/plugin compatibility, retain previous values/rendered manifests, and plan the /setup migration step where required. An unsupported application downgrade can be destructive even if helm rollback can restore old YAML.

11. Worked scenario: choose a production-shaped pattern

Scenario: one internal engineering organization runs a supported OpenShift release, already has a managed PostgreSQL service, restricted SCCv2, enterprise certificate automation, and a platform-managed Gateway/Route layer. A strong design uses the maintained SonarQube chart in OpenShift mode, external PostgreSQL credentials via Secret reference, persistent search storage from an approved StorageClass, no custom SCC, no bundled ingress controller, explicit CPU/memory, and database-first backup/upgrade governance.

The same organization should not choose DCE unless its scale/availability requirements and commercial license justify the separate topology.

Knowledge check

Official references and version notes

• SonarQube Community Build — Kubernetes/OpenShift introduction — installation flow and platform boundary.
• Before you start — Kubernetes/OpenShift — resource, database, restricted-namespace, and production prerequisites.
• Customizing the Helm chart — OpenShift, security contexts, persistence, JDBC, ingress and TLS guidance.
• Installing the Helm chart — current Community Build install parameters and OpenShift example.
• Official SonarQube Helm chart repository — maintained chart source, values, changelog, and releases.
• SonarQube chart 2026.4.1 release — pinned released chart artifact used in this chapter.
• SonarQube chart README — edition, compatibility, Pod Security, resources, persistence, JDBC, OpenShift and upgrade guidance.
• SonarQube Data Center Helm chart — commercial Data Center topology and separate chart boundary.
• SonarQube Community Build releases — current Community Build release identity.
• Kubernetes Pod Security Standards — restricted/baseline/privileged namespace security model.
• Kubernetes Persistent Volumes — PVC, StorageClass and access-mode ownership.
• Kubernetes Gateway API — modern external-routing API discussed as a production option.