Repository navigation
Rolling update for Talos nodes #20
Description
Activity
I think we need to introduce a new resource to track the process of updates:
apiVersion: cozystack.io/v1alpha1 kind: TalosNode metadata: name: srv1 ownerReferences: - apiVersion: v1 kind: Node name: srv1 uid: d7ba2238-d45a-4edc-a348-aa5157afc730 spec: image: ghcr.io/aenix-io/cozystack/installer:v0.0.2 suspend: false status: image: ghcr.io/aenix-io/cozystack/installer:v0.0.2 lastAppliedPatchHash: 01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b
talos updater controller should take the folowing arguments:
--image=ghcr.io/aenix-io/cozystack/installer:v0.0.2 --preserve=false --patch-file=common-node-parameters.yamlWhen new version of cozystack installed, it will update talos-updater to run with new arguments, then it should go and update all the nodes in a cluster one-by-one.
common-node-parameters.yaml contain parameters that must be applied as merge patch, example:
machine: kubelet: nodeIP: validSubnets: - 192.168.100.0/24 kernel: modules: - name: openvswitch - name: drbd parameters: - usermode_helper=disabled - name: zfs install: image: ghcr.io/aenix-io/cozystack/talos:v1.6.4 files: - content: | [plugins] [plugins."io.containerd.grpc.v1.cri"] device_ownership_from_security_context = true path: /etc/cri/conf.d/20-customization.part op: create cluster: network: cni: name: none podSubnets: - 10.244.0.0/16 serviceSubnets: - 10.96.0.0/16 allowSchedulingOnControlPlanes: true controllerManager: extraArgs: bind-address: 0.0.0.0 scheduler: extraArgs: bind-address: 0.0.0.0 proxy: disabled: true discovery: enabled: false etcd: advertisedSubnets: - 192.168.100.0/24
Only one node per cluster allowed for upgrade in time
Triage notes: Good idea, we want it, but maybe in 25Q4 or 26Q1. Rather complex task; requires knowledge of Go and Talos. Now users just update Talos themselves when it's required.
- added 4 commits that reference this issue
on Sep 25, 2025 Hi, Andrei Kvapil (@kvaps). I'm Dosu, and I'm helping the cozystack team manage their backlog and am marking this issue as stale.
Issue Summary:
- You proposed a rolling update mechanism for Talos nodes using a new TalosNode resource and a reconciliation controller.
- The goal is to upgrade nodes one-by-one with patch files, updating images and configurations via Kubernetes resources.
- The current method requires manual Talos node updates.
- Maintainer NickVolynkin acknowledged the value but noted this is a complex feature planned for late 2025 or early 2026.
- No resolution or implementation has occurred yet.
Next Steps:
- Please let me know if this issue is still relevant to the latest version of the cozystack repository by commenting here.
- If I don’t hear from you within 7 days, I will automatically close this issue.
Thanks for your understanding and contribution!
- added a commit that references this issue
on Sep 25, 2026
During cluster setup user have to upload
secrets.yamlandcluster.confinto Kubernetes. eg:This will start a reconcilation controller, which checks all the nodes in a cluster, and performs their rolling update:
During the upgrade talos config on the node should also be updated to contain the new image.
In talos-bootstrap script we usually do that immediately before the update operation.