This message was deleted.
# rancher-setup
a
This message was deleted.
p
It looks like I chose a newer kubernetes version when creating the cluster (insetad of 1.32.10)
h
I would normally stick to what support matrix shows in regards to RKE2 version and OS versions https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/rancher-v2-14-2/
p
Yes, I would too, but I'm using Debian and that's not official supported, as you know 🙂
I'm just trying to install the same version we have in production.
h
oh I see.. makes sense
p
I've recreated the cluster, but now I just get
Waiting for cluster agent to connect
and on the rancher pods:
Copy code
rancher-7fbb9dcc78-tn5jh rancher 2026/05/29 14:06:03 [ERROR] error syncing '_all_': handler user-controllers-controller: userControllersController: failed to set peers for key _all_: failed to start user controllers for cluster c-m-v64qjc9h: ClusterUnavailable 503: cluster not found, requeuing
I'm not sure how to debug this further. It's funny because this is literally much more difficult than installing kubernetes with kubeadm and then having everything on top of that.
Oh, I've had a look at the logs directly on the controlplane node (that I'm trying to make to join the cluster), and I get this:
Copy code
ERROR: The environment variable CATTLE_CA_CHECKSUM is set but there is no CA certificate configured at <https://rancher.example.com/v3/settings/cacerts>
h
is this when installing rke2 or rancher? and you recreated cluster using same node?
p
This is after trying to register a controlplane node to the cluster that I previously created in the rancher dashboard (which runs on a separate host on which I installed rancher).
👍 1
So I went to the control plane node itself (the one I'm trying to register, as I said), and looked at the pods status and came across this
h
okay so you're creating a downstream cluster from rancher ui
p
yes, exactly
But I have a hunch about why this might not work. 🙂
I thought I could get away with it. The problem is that I'm using the dns name that I've added in /etc/hosts, because it still points to a different cluster altogether (and there's not much I can do about it right now, but I do need to use that name) So this worked for the initial registration (the command which was run, of course, on the host directly), but this pod is definitely using coredns, which doesn't check /etc/hosts of the host itself. So it must be going to the other IP... eh
And, yes, I've just confirmed that with a tcpdump. Eh... I'll have to wait.
Funny, I've add a hosts directive in the coredns configmap and now it works.
And the worker node also joined automatically (there was no pod there that required accessing the management server directly, I guess)
Ah, I'm silly. The configmap will work for all nodes, of course, 'cause it's the same. I wondered why all the other nodes, including the control plane ones, worked without issues.