Skip to content

Automatically remove flannel and kube-proxy #2

Description

@kvaps

Talos automatically setups flannel and kube-proxy, and even if you switch config to:

cluster:
  network:
    cni:
      name: none
  proxy:
    disabled: true

it will not automatically remove it. User have to run:

kubectl delete -n kube-system ds kube-flannel
kubectl delete -n kube-system  ds kube-proxy

Let's think how we can automate it

Activity

  1. gecube commented on Jan 26, 2024

    @gecube
    Collaborator

    Hi!

    Where is the talos config stored? Is it in cluster object or just rather a file somewhere?

  2. gecube commented on Jan 26, 2024

    @gecube
    Collaborator

    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-proxy
    
  3. kvaps commented on Jan 29, 2024

    @kvaps
    MemberAuthor

    Where 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

  4. added
    upstream-issueRequires resolving an issue in an upstream project
    and removed
    kind/bugCategorizes issue or PR as related to a bug
    on Mar 25, 2025
  5. NickVolynkin commented on Mar 28, 2025

    @NickVolynkin
    Contributor

    We discussed it and decided to try fixing it upstream. Before doing that we should make a reproducible example.

  6. lllamnyp commented on Apr 14, 2025

    @lllamnyp
    Member

    We need to check that the problem persists and if so, file an issue in upstream.

  7. lllamnyp commented on Apr 24, 2025

    @lllamnyp
    Member

    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==none is 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.

  8. dosubot commented on Oct 20, 2025

    @dosubot

    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!

  9. added
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    on Oct 20, 2025
  10. removed
    lifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale
    on Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

upstream-issueRequires resolving an issue in an upstream project

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions