This message was deleted.
# k3s
a
This message was deleted.
h
Changing the cluster CNI after the cluster has been provisioned is not supported
Reference: https://www.suse.com/support/kb/doc/?id=000020904
h
Yikes. Any idea on ETA for that ability to be incorporated into k3s?
h
no idea if that is even on the table - you can look at and go thru the github page: https://github.com/k3s-io/k3s/issues maybe one of the k3s engineers can comment on your question...
h
Is there an open issue on the case?
h
you will have to search
h
Opened a new issue. More than welcome to support and contribute: github.com/k3s-io/k3s/issues/8100
c
We do not plan to add support for changing CNI on a cluster after it's been started. Like picking cluster CIDRs and other core networking choices, CNI should be decided upon before the cluster is created. While you might be able to hack at it and get it to work, it's not something we will support. Certainly it will not work without at least restarting k3s to disable flannel.
h
I understand. I’m willing to hack on it, any chance you can at least help me with directions? Anything else that needs to happen/change in addition to restarting k3s to disable flannel?
Also, from what I understand this is considered a Top Issue on the ref page (https://www.suse.com/support/kb/doc/?id=000020904). How come a Top Issue isn’t in the roadmap?
a
@hallowed-carpet-38238 you should have a look at Cilium 1.14. Migration to flannel with dual mode (you keep flannel while adding cilium, and migrate node by node). Disabling flannel in k3s can be the final step in the migration
h
@alert-policeman-61846 Thanks! Do you have a link to the guide? Another question, how do I reset k3s server (cp nodes) without breaking up the entire cluster? (I have 2 cp nodes, 3 etcd nodes and 4 worker nodes)
c
what do you mean by “reset”
h
restart is the more accurate word. I need to bring the server nodes down and restart them with flannel disabled
c
just restart the service
restarting the service won’t stop any currently running pods
but note that without a CNI, you won’t be able to start any new pods unless they use host network
h
Do i restart it with systemctl restart? If so, how do I add the --flannel-backend=none flag?
c
I would caution you against trying to deploy a custom CNI when you’re not even sure how to configure or restart k3s
but, if you want to do so, you can edit the systemd unit to add the flag, and then use systemctl to restart the service
h
Alright, will try
c
systemctl edit --full k3s
should get you in to an editor to add the flag to the server arguments
h
Would the right order of things be to first disable flannel via editing the k3s service and restarting it, then installing cilium (or other CNI)? I don’t mind a temp downtime/not being able to start new pods in the meantime between shutting down flannel and installing and provisioning cilium
c
I don’t know, like I said we don’t support it so I’ve never tried it.
if you’re worried about downtime, I would definitely run through the whole process on a test cluster first to see what problems you might run into.
h
That’s for sure. As I said I’m not worried about downtime since this is a staging cluster
h
creating a new cluster takes under 15-min this sounds like more work and then hopefully everything will work? just my 2-cents, you are the one who will have to support this unsupported setup.
h
You’re kinda right, I’m trying to avoid the migration
👍 1
🤞 1
Would restarting the service in the server nodes affect the other agent nodes? (worker and etcd) would they keep being connected to the cp?
a
my two cents would be with others that have suggest creating a new cluster and migrate the workload. Changing the CNI provider seems like a really bad idea. Especially considering how easy it to spin up new clusters. There are tools that can help with migration to a new cluster for instance backup tools like velero.
a