Repository navigation
Automatically remove flannel and kube-proxy #2
Description
Activity
Hi!
Where is the talos config stored? Is it in cluster object or just rather a file somewhere?
right now I see the option only to add some extra manifest to talos config with the job that will trigger every time the config is re-applied and in this job to make a check if we need to do extra steps like
kubectl delete -n kube-system ds kube-flannel kubectl delete -n kube-system ds kube-proxyWhere is the talos config stored? Is it in cluster object or just rather a file somewhere?
It's stored in talos api for every node, I think we would need to write special talos-controller, which would reconcile all configs with the Kubernetes
- addedkind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bug
on Mar 25, 2025 - addedupstream-issueRequires resolving an issue in an upstream projectRequires resolving an issue in an upstream projectand removedkind/bugCategorizes issue or PR as related to a bugCategorizes issue or PR as related to a bug
on Mar 25, 2025 NickVolynkin commented
on Mar 28, 2025 ContributorMore actionsWe discussed it and decided to try fixing it upstream. Before doing that we should make a reproducible example.
We need to check that the problem persists and if so, file an issue in upstream.
Talos is mostly behaving as intended. It appears that the backend for this is from kubeadm. Since this snippet
cluster: network: cni: name: none proxy: disabled: true
is part of a bootstrap config, it was never intended to be "re-applied", so Talos does not and probably cannot track which objects are related to an application of this configuration and which daemonset should be deleted when a configuration with
cluster.cni.name==noneis applied: was the previous cni flannel or calico? The configuration is declarative, state is not tracked, so there is no way to know the "before".We should make it abundantly clear in the documentation that if the user has an already running kubernetes cluster, perhaps bootstrapped with Talos, they should delete any existing CNI and get rid of kube-proxy, before proceeding to install cozystack.
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 automating the removal of flannel and kube-proxy daemonsets in Talos when CNI and proxy are disabled in the config, as manual deletion is currently required.
- George Gaál (@gecube) suggested adding a job in the Talos config for cleanup, but you noted the config is stored per node in the Talos API, possibly requiring a special controller.
- Maintainers Nick Volynkin (@NickVolynkin) and Timofei Larkin (@lllamnyp) clarified that Talos config is bootstrap-only and does not track state changes, so manual removal is recommended.
- They plan to verify the issue upstream if it continues to persist.
Next Steps:
- Please confirm if this issue is still relevant with the latest version of cozystack and Talos by commenting here.
- If no further activity occurs, I will automatically close this issue in 7 days.
Thanks for your understanding and contribution!
- addedlifecycle/staleDenotes an issue or PR has remained open with no activity and has become staleDenotes an issue or PR has remained open with no activity and has become stale
on Oct 20, 2025 - removedlifecycle/staleDenotes an issue or PR has remained open with no activity and has become staleDenotes an issue or PR has remained open with no activity and has become stale
on Oct 27, 2025 - added a commit that references this issue
on Nov 4, 2025 - added a commit that references this issue
on May 5, 2026 - added a commit that references this issue
on May 27, 2026 - added a commit that references this issue
on Jul 6, 2026
Talos automatically setups flannel and kube-proxy, and even if you switch config to:
it will not automatically remove it. User have to run:
Let's think how we can automate it