Upgrade Telark

Upgrade the Helm release in place, handle the releases that need extra steps, and reinstall when coming from chart 0.4 or older.

One chart version pins every Telark service and the CRDs. An upgrade is a helm upgrade of the same release, except from chart 0.4 or older, which needs a reinstall.

Before you upgrade

Read the changelog for every version between yours and the target.
Back up the snapshot and report volumes and the Telark custom resources. See Back up Telark.
Let any rollback in progress finish.

Upgrade

Pass every --set and -f flag you used at install. Helm does not remember them, and a flag you leave out returns to its default.

helm upgrade telark oci://ghcr.io/telark/charts/telark -n telark \
  --version <target-version> \
  <your install flags>

Do not use --reuse-values. It keeps old defaults that newer charts replace, such as the image registry and the reports volume settings.

The CRDs ship as templates of the bundled telark-crds subchart, so the upgrade updates them too. Deployments roll one pod at a time where they run two or more replicas; discovery's new leader takes over within one lease (15 seconds), and plans and rollbacks resume on it. Sessions are custom resources, so nobody is signed out.

Check the result

kubectl get pods -n telark
helm test telark -n telark

Every pod should be Ready and the test should pass. In the dashboard, protection plans should show the same phases as before, and a Force Sync on one application should complete.

Upgrades that need extra steps

To the chart with the security defaults. Passkey self-registration is off and the chart ships no admin, so pass --set 'app.auth.bootstrap.admins={you@example.com}'; the render fails without it. The CRD write guard now enforces, NetworkPolicies restrict ingress to the Telark APIs and NATS, and NATS moves from one shared user to a publisher (discovery) and a consumer (notifier), so NATS and both clients restart during the rollout. With an Ingress or Gateway, also set app.auth.passkey.id and app.auth.passkey.origin.

To the chart that adds plan reports. The exporter gains a second claim, telark-exporter-reports-pvc, with the same class and access mode as the snapshot claim. Without --reuse-values it binds on rollout.

To the chart that pulls from GHCR. Images move from Docker Hub to ghcr.io/telark/<service> with the same names and tags. Nodes behind an egress allowlist need ghcr.io and pkg-containers.githubusercontent.com.

From chart 0.2.1 or older, or when switching modes. Those releases run one exporter replica on a ReadWriteOnce claim, and Kubernetes cannot change a bound claim's access mode. The same applies when you switch between minimal and standard or performance, or toggle app.singleNode. Either:

add --set app.singleNode=true to keep the existing claim (one replica), or
move to two replicas on ReadWriteMany: uninstall, delete the telark-exporter-snapshots-pvc claim, and reinstall with --set app.persistence.storageClass=<rwx-class>. Snapshots are lost; copy /snapshots off the exporter pod first if you need them.

From chart 0.4 or older

Chart 0.5 moved every CRD to the single API group telark.io with new kinds, field names and the Kyverno label telark.io/protection-plan. There is no in-place migration.

What you lose: every Telark object. Custom roles, groups, categories, protection plans and settings must be re-created by hand. Everyone signs in again: passkey users re-enrol, and Google users are provisioned again on first sign-in but without their old role and group assignments.

Remove the old plans' Kyverno policies. The new discovery does not see the old label.
```
kubectl delete policies.kyverno.io -A -l telark.erpi/protection-plan
```

Optional: export the old objects for reference.

for r in applicationsasresources.erpi.telark protectionplans.erpi.telark globalconfigs.erpi.telark \
         usersasresources.erpi.telark groupsasresources.erpi.telark rolesasresources.erpi.telark \
         categoriesasclassifications.classification.telark; do
  kubectl get "$r" -n telark -o yaml > "old-$r.yaml"
done

Uninstall the release.
```
helm uninstall telark -n telark
```

Clear the cleanup finalizers, then delete the nine old CRDs and their objects.

for r in usersasresources.erpi.telark groupsasresources.erpi.telark rolesasresources.erpi.telark; do
  kubectl get "$r" -n telark -o name | xargs -r -I{} kubectl patch {} -n telark --type merge -p '{"metadata":{"finalizers":null}}'
done
kubectl delete crd \
  applicationsasresources.erpi.telark protectionplans.erpi.telark globalconfigs.erpi.telark \
  usersasresources.erpi.telark groupsasresources.erpi.telark rolesasresources.erpi.telark \
  userpasskeys.auth.telark usersessions.auth.telark \
  categoriesasclassifications.classification.telark

Install the new chart with your previous flags plus a bootstrap admin, as in Install Telark for production. With a GitOps render, also create the Secrets listed under GitOps (cluster-less renders).

Enrol the first admin:

kubectl exec -n telark deploy/telark-auth-service -- ./main break-glass --email you@example.com --enroll
# open https://<dashboard-host>/register?enroll=<token>

Send enrolment links to the other passkey users, and re-create roles, groups, categories and plans.

From now on, address Telark objects by their fully qualified or short names (kubectl get applications.telark.io -n telark, tapp, tplan, tuser). Argo CD's applications.argoproj.io answers to a plain kubectl get applications.

Roll back an upgrade

helm rollback telark -n telark

The Deployments return to the previous images and the CRDs to the previous definitions. The snapshot volume is not touched by an upgrade. A rollback across the 0.4 to 0.5 change does not bring the old objects back.