v1.3.3 (2026-05-07)

A patch release shipping a new opt-in PostgreSQL backup-recovery option and three managed-application fixes for Kafka and MongoDB external access. All changes are backports of PRs already merged to main.

Features and Improvements

• feat(postgres): add bootstrap.serverName parameter for backup recovery: Adds an optional bootstrap.serverName field to the postgres chart so CloudNativePG can recover from a backup whose Barman server_name (in backup.info) differs from the Kubernetes cluster name. Previously, recovery failed with no target backup found when the new cluster had a different name than the original — for example, restoring cloud backups into a cluster named grafana. When set, serverName is passed through to externalClusters and used to locate backups in S3; when omitted, behavior is unchanged and recovery continues to fall back to oldName. The same PR also clarifies the oldName and serverName field descriptions in values.yaml, the Go API types, the JSON schema, and the embedded CRD (@IvanHunters in [#2362], backport [#2588]).

Fixes

• fix(kafka): create LoadBalancer service when external flag is enabled: When external: true was set on the Kafka chart, two issues prevented the Strimzi-managed <release>-kafka-external-bootstrap LoadBalancer from being usable. First, the external listener was always present in the Kafka CR (rendered as type: internal when disabled) instead of being omitted entirely. Second, the dashboard role only granted access to the internal <release>-kafka-bootstrap ClusterIP, so the external bootstrap service was invisible to tenant users even when Strimzi had created it. The external listener is now added only when external: true, and the dashboard RBAC includes the external bootstrap service in that mode. Helm-unittest coverage was added for both external: true and external: false (@IvanHunters in [#2578], backport [#2592]).

• fix(kafka): bump default resourcesPreset to medium: Changes the default resourcesPreset for both kafka and zookeeper from small (1 CPU / 512Mi) to medium (1 CPU / 1Gi). Strimzi sets the JVM heap to 50% of the container limit for Kafka and 75% for ZooKeeper, leaving only ~256Mi / 128Mi of non-heap budget under the small preset. That budget is no longer sufficient on the current Strimzi 0.45 / Kafka 3.9 image baseline (Metaspace, code cache, direct buffers, JMX javaagent, embedded Jetty admin server, KRaft migration endpoints, thread stacks), so brokers and ZooKeeper pods on a fresh deployment hit cgroup OOM kills (exit 137) before the broker could connect to ZooKeeper, ending up in CrashLoopBackOff with lastState.terminated.reason: OOMKilled. The medium preset is the smallest preset that gives both Kafka (heap 512Mi + ~500Mi non-heap) and ZooKeeper (heap 768Mi + 256Mi non-heap) enough headroom to start cleanly. Existing deployments that explicitly set resourcesPreset are unaffected; the small preset is intentionally kept in the enum to preserve compatibility for deployments that pin it (@IvanHunters in [#2537], backport [#2589]).

• fix(mongodb): expose replica-set members per pod for external access: When external: true was set on a non-sharded MongoDB, Cozystack rendered a single LoadBalancer Service whose selector matched all replica-set members (app.kubernetes.io/replset: rs0). Round-robin balancing sent ~⅔ of writes to secondaries and they were rejected with MongoServerError: not primary, and drivers couldn't recover automatically because connecting through the LB returned the in-cluster DNS names of all members from isMaster, none of which resolve from outside the cluster. The hand-written external-svc.yaml (for replica-set mode) is now replaced with the Percona MongoDB operator's native replsets[].expose feature: the operator creates one LoadBalancer Service per pod (<release>-rs0-0, -1, -2) with statefulset.kubernetes.io/pod-name selectors, watches Service.status.loadBalancer.ingress for each pod, and rewrites the member host in rs.conf to the external IPs. External clients can now use a standard replica-set URI (mongodb://...:27017,...:27017,...:27017/?replicaSet=rs0) and the driver discovers the primary correctly from outside the cluster. Sharded mode is unchanged — the existing single LoadBalancer is preserved because it front-ends stateless mongos, which routes writes to the right shard primary itself. Fixes [#2514] (@myasnikovdaniil in [#2522], backport [#2590]).

Documentation

• [website] Add vGPU setup guide for GPU sharing between VMs: Adds a practical guide for running VMs with NVIDIA vGPU on Cozystack alongside the existing GPU passthrough page, covering the SR-IOV vGPU path used by current data-centre GPUs (L4, L40, L40S, B100) on the vGPU 20.x driver branch. The guide walks through building the proprietary vGPU Manager container image, deploying the GPU Operator vgpu variant via the Package CR, assigning vGPU profiles to SR-IOV VFs through current_vgpu_type, configuring DLS licensing via ClientConfigToken, patching the KubeVirt CR with permittedHostDevices.pciHostDevices, and a sample VirtualMachine using a CDI DataVolume to avoid the 2.4 GiB containerDisk root overflow during in-VM driver install. Includes a vGPU profile reference table for L40S with the Q/A/B suffix taxonomy and an explicit note that Talos is not recommended for vGPU (passthrough on Talos is unaffected) (@lexfrei in cozystack/website#467).

Contributors

Thanks to everyone who contributed to this patch release:

• @IvanHunters
• @lexfrei
• @myasnikovdaniil

Full Changelog: https://github.com/cozystack/cozystack/compare/v1.3.2...v1.3.3