Checkpoint Lab — Kubernetes and OpenShift Deployment Patterns

1. Checkpoint charter and exact assumptions

Build one evidence packet around released chart 2026.4.1 and Community Build 26.9.0.129388. Mandatory execution stops at Helm render/lint; an actual cluster is optional. Record Helm and kubectl client versions, chart release/tag, Community Build number, supported platform matrix (1.32–1.35; OpenShift 4.17–4.20), namespace name, values-file checksum, and whether any cluster was used.

2. Write predictions before rendering

1. With persistence.enabled=true, the rendered manifest should contain a PVC; changing a Pod does not delete the database.
2. With initSysctl.enabled=false and initFs.enabled=false, restricted-namespace intent shifts node/sysctl and filesystem preparation to platform administrators.
3. With ingress.enabled=false, no public edge object should be rendered; Service remains internal.
4. With OpenShift.enabled=true, security-context output should adapt to supported OpenShift/SCC behavior.
5. Changing the JDBC host to localhost changes only database addressing; it must not be diagnosed by deleting PVCs or weakening Pod Security.

3. Create a guarded evidence workspace

mkdir -p sq-ch05-checkpoint/evidence
cd sq-ch05-checkpoint
helm version > evidence/helm-version.txt
kubectl version --client > evidence/kubectl-client-version.txt 2>&1 || true
helm repo add sonarqube https://SonarSource.github.io/helm-chart-sonarqube
helm repo update
helm pull sonarqube/sonarqube --version {chart_version} --untar --untardir ./chart

4. Create the edition-aware Kubernetes values file

# values-k8s.yaml
community:
  enabled: true
  buildNumber: "26.9.0.129388"
monitoringPasscode: "FAKE_CHECKPOINT_ONLY"
initSysctl:
  enabled: false
initFs:
  enabled: false
persistence:
  enabled: true
  size: 5Gi
  accessMode: ReadWriteOnce
service:
  type: ClusterIP
ingress:
  enabled: false
resources:
  requests:
    cpu: 400m
    memory: 2048M
  limits:
    cpu: 800m
    memory: 6144M

Do not add a real DB password. For production-shaped DB evidence, use a second fragment with only jdbcOverwrite endpoint/username and Secret name/key references.

5. Lint and render the Kubernetes variant

helm show chart sonarqube/sonarqube --version 2026.4.1 > evidence/chart.yaml
helm show values sonarqube/sonarqube --version 2026.4.1 > evidence/default-values.yaml

helm lint ./chart/sonarqube -f values-k8s.yaml   > evidence/lint-k8s.txt
helm template sq-ch05 sonarqube/sonarqube --version 2026.4.1   --namespace sq-ch05-checkpoint -f values-k8s.yaml   > evidence/render-k8s.yaml

Verify chart/app identity, PVC presence, ClusterIP Service, probes/resources, restricted application container security and absence of a public Ingress.

6. Render and compare the OpenShift variant

helm template sq-ch05-os sonarqube/sonarqube --version 2026.4.1   --namespace sq-ch05-checkpoint   -f values-k8s.yaml   --set OpenShift.enabled=true   --set OpenShift.createSCC=false   > evidence/render-openshift.yaml

Write a comparison note covering UID/GID/security-context differences, disabled helper behavior, optional Route support, and why a custom privileged SCC is not the default solution.

7. Add production-shaped external DB evidence without a real DB

# values-db-contract.yaml
jdbcOverwrite:
  enabled: true
  jdbcUrl: "jdbc:postgresql://sq-db.example.invalid:5432/sonar"
  jdbcUsername: "sonar_checkpoint"
  jdbcSecretName: "sq-checkpoint-db-secret"
  jdbcSecretPasswordKey: "password"

Render with both values files. Verify the password remains a Secret reference and the invalid hostname makes accidental execution impossible. State explicitly that a real production deployment requires a supported reachable DB and tested backup/restore.

8. Inject one reversible JDBC addressing fault

Create values-db-broken.yaml by changing only the JDBC URL to jdbc:postgresql://localhost:5432/sonar. Render it and save the diff.

helm template sq-ch05-broken sonarqube/sonarqube --version 2026.4.1   --namespace sq-ch05-checkpoint   -f values-k8s.yaml -f values-db-broken.yaml   > evidence/render-broken.yaml

diff -u evidence/render-db-contract.yaml evidence/render-broken.yaml   > evidence/broken-vs-correct.diff || true

Diagnosis: localhost would address the SonarQube Pod itself. The correct repair is the DB Service/FQDN, not PVC deletion, restart loops, TLS disablement, policy changes, or a new project key.

9. Optional bounded deployment and readiness evidence

If a disposable local cluster is available, deploy only after verifying current context, namespace emptiness and memory headroom. Prefer a test-only H2 deployment for execution simplicity and state clearly that it does not validate production persistence/database design.

kubectl config current-context
kubectl create namespace sq-ch05-checkpoint
helm upgrade --install sq-ch05 sonarqube/sonarqube --version 2026.4.1   -n sq-ch05-checkpoint   --set community.enabled=true   --set community.buildNumber=26.9.0.129388   --set monitoringPasscode=FAKE_CHECKPOINT_ONLY

kubectl -n sq-ch05-checkpoint get pod,pvc,svc -o wide
kubectl -n sq-ch05-checkpoint get events --sort-by=.lastTimestamp
kubectl -n sq-ch05-checkpoint logs -l app=sonarqube --all-containers=true --tail=300

10. Required evidence packet

• chart version, chart metadata and Community Build number;
• Helm/kubectl client versions and optional cluster context/platform version;
• values files with fake/non-secret data only plus checksums;
• Kubernetes and OpenShift rendered manifests;
• PVC/StorageClass intent and reclaim/backup assumptions;
• database endpoint and Secret-reference contract;
• Service/edge-routing/TLS design note;
• security-context and node-prerequisite note;
• resource/probe settings and sizing limitation;
• broken-vs-correct render diff and causal diagnosis;
• optional Pod/events/log/readiness evidence;
• upgrade/rollback note including database backup requirement;
• edition note explaining why DCE is separate/commercial.

11. Verification checklist

• No real token/password/private endpoint appears in the packet.
• Exactly one released chart version and one explicit Community Build number are recorded.
• Rendered Community Build uses community.enabled=true, not a commercial edition.
• Persistence choice and DB durability are described separately.
• Restricted/OpenShift security decisions do not depend on blanket privilege.
• No public LoadBalancer/NodePort/Ingress/Route is required by the lab.
• First-failure evidence is preserved before repair.
• Rollback is not described as an unsupported SonarQube downgrade.

12. Guarded cleanup and rollback record

Render-only work needs no cluster cleanup; archive the evidence directory. If you deployed to the optional local namespace:

helm -n sq-ch05-checkpoint get values sq-ch05 --all > evidence/installed-values.yaml
helm -n sq-ch05-checkpoint get manifest sq-ch05 > evidence/installed-manifest.yaml
helm -n sq-ch05-checkpoint history sq-ch05 > evidence/helm-history.txt
kubectl -n sq-ch05-checkpoint get all,pvc -o wide > evidence/pre-cleanup-inventory.txt

helm uninstall sq-ch05 -n sq-ch05-checkpoint
# Confirm the namespace name and that it contains only checkpoint resources:
kubectl get namespace sq-ch05-checkpoint
kubectl delete namespace sq-ch05-checkpoint

Do not delete StorageClasses, ingress/Gateway controllers, SCCs, CRDs, external databases or cluster-wide security policies as lab cleanup.

13. What the checkpoint proves—and does not prove

It proves that you can build an edition-aware, version-pinned, reviewable Kubernetes/OpenShift deployment specification; reason about storage/security/database/routing/resource ownership; preserve first-failure evidence; and identify a deliberate DB-addressing fault.

It does not prove production capacity, HA, disaster recovery, database restore, external TLS, IdP integration, scanner throughput, CI gating, plugin compatibility, Data Center behavior, or zero-downtime upgrade. Those require later course chapters and controlled production-like environments.

14. Chapter contribution to a governed operating model

Chapter 05 adds an orchestrator-layer deployment record: chart/app identity, platform compatibility, namespace and security policy, storage and database ownership, resource/probe behavior, Service/edge contract, first-failure evidence, and upgrade/rollback inputs. Chapter 06 can now focus on SonarQube projects, keys, permissions and onboarding without pretending deployment state is invisible.

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.