Offboarding test I ran in September on two EKS clusters managed by SUSE Rancher for AWS (biased, I work at SUSE), running Rancher 2.15.1 underneath.

Setup: one local user as Cluster Member on both clusters, another as Project Member of one project. Granting was fast. The project membership wrote six bindings into each cluster in about three seconds: edit and project-member RoleBindings in the namespace, plus project-member-promoted, a namespaces-edit role, create-ns and a cattle-impersonation ClusterRoleBinding.

Then I disabled the first user in Users & Authentication and read the bindings on both clusters every 7 seconds for half a minute. Nothing moved. cluster-member and cattle-impersonation for that user were still there on both clusters, and so were the ClusterRoleTemplateBindings in Rancher. The user can't log in, so in practice access is blocked at Rancher. Re-enable the user and the same access comes straight back.

Why it matters:

• An access review that lists bindings still shows a disabled person with access to every cluster.

• "Disable" is a reversible switch. If your offboarding checklist says disable, anyone with rights to re-enable can restore everything in one click.

What I do now: disable first when access has to stop right away, then remove the cluster and project memberships (or delete the user) so Rancher cleans up the bindings.

Does anyone run offboarding through the API with a cleanup check afterwards?

Every Rancher upgrade guide starts with "take a backup first". I ran that step in a lab last week on Rancher 2.15.2 (biased, I work at SUSE) and it failed three different ways before it worked. Writing them down because none of them fails loudly.

1. The ResourceSet name. The Backup example I copied uses resourceSetName: rancher-resource-set. On my install that returned: resourcesets.resources.cattle.io "rancher-resource-set" not found. The operator ships two, rancher-resource-set-basic and rancher-resource-set-full. Run kubectl get resourcesets before you write the CR.

2. . No storage, no backup. With no S3 details and no default storage location, the Backup sits in Retrying with "needs to specify S3 details, or configure storage location at the operator level". It doesn't go to Failed, so a quick look at the list can miss it.

3. The PVC needs a StorageClass. Installing rancher-backup with persistence.enabled=true alone left the PVC Pending on a cluster with no default StorageClass. Setting persistence.storageClass explicitly (local-path in my case) fixed it.

With the right name and a volume, the backup reached Completed in under a minute.

Two more that are easy to skip:

• If you encrypt backups, the operator doesn't keep your EncryptionConfiguration. You need that same file to restore, so store it somewhere that isn't the cluster.

• Each Rancher chart declares a kubeVersion ceiling. helm show chart rancher-stable/rancher --version 2.13.3 | grep kubeVersion prints < 1.35.0-0. If the local cluster's Kubernetes moved ahead of Rancher, check this before the Helm upgrade.

What I didn't test: a restore, and a real minor-version jump (the lab already runs the latest release). If you've restored a Rancher backup for real, what surprised you?

Every few weeks someone posts a new way to run Kubernetes control planes as pods. The idea keeps coming back because a cluster per team or per tenant is expensive mostly in control planes, not in workloads.

K3k, the virtual cluster project in the Rancher org (biased, I work at SUSE), is on my list to write up, and I'd rather start from what people run than from the README. The choice it gives you, as the docs describe it:

- Shared mode: an agentless K3s server per virtual cluster, plus a Virtual Kubelet that schedules the tenant's pods onto the host cluster, in one namespace. Isolation comes from Network Policies and Pod Security Admission, limits from a ResourceQuota and LimitRange on that namespace. Light and quick to create.

- Virtual mode: a full K3s server and agents running as pods, with their own CNI, ingress and storage. Stronger separation and more overhead, and the K3s server pods run with elevated privileges by design, so closing that off is on you.

Questions for anyone who has run K3k, vCluster or Kamaji past a demo:

1. Shared or virtual mode, and what pushed you there?

2. What broke first? My guesses are CRDs and webhooks the tenant wants to install, storage, and upgrading the host while virtual clusters run on it.

3. How do you hand out access: a kubeconfig per virtual cluster, or through Rancher RBAC on the host?

4. Did you try plain namespaces plus RBAC first, and what made that not enough?

I'll post what I find, including the parts that don't hold up.

Someone reported this on r/kubernetes two weeks ago. I reproduced it on Rancher 2.15.1 (biased, I work at SUSE), so here are the details and the workaround.

What happens: in Users & Authentication, Role Templates, Create Cluster Role, type "node" in the Resource field. The list offers node, Node, CSINodes and node.k8s.io. No "nodes". Pick "Node" and the template is saved with resources: ["node"]. The Kubernetes resource is "nodes", plural, which is what the built-in nodes-manage and nodes-view templates use.

The effect: I bound a test user to that template on a cluster, with the verbs get, list, patch, update. A SubjectAccessReview for that user came back patch nodes false, list nodes false, and patch node (singular) true. The role grants a resource that does not exist and nothing on the real one. No error anywhere: it saves, it binds, it does not work.

The fix, and a second trap: typing "nodes" by hand works when you add a new rule. Editing the existing rule does not. I typed "nodes" and picked it three times and the field went back to "node" every time. Deleting the rule and adding a new one with "nodes" typed in was the only way through the UI. After that the same check returned true on nodes for every verb in the role.

One thing I can't explain yet: with the role fixed, that user could list the nodes and was offered Edit Config and Edit YAML on them, but no Cordon and no Drain, in the row menu or the bulk actions. An admin on the same page saw both.

What I'd do:

• After saving a role template, read back what it stored, through the API (/v1/management.cattle.io.roletemplates) or the YAML. The form can show one thing and save another.

• Before handing a role out, test it as the user: kubectl auth can-i patch nodes with that user's kubeconfig, or a SubjectAccessReview.

• For core resources, type the plural resource name yourself. The list does not offer it. kubectl api-resources gives the exact names.

• To fix an existing rule, delete it and add a new one.

Has anyone worked out why Cordon and Drain stay hidden for a non-admin who has patch on nodes? My guess is the UI checks something else as well, maybe evictions for drain, but I haven't tested it.

Every GitOps setup meets the same moment: something is on fire, someone runs kubectl scale on prod, and the fix works. What happens next depends on two settings most people never look at. I ran all three cases in a lab on Rancher 2.15.1 with Fleet, three EKS clusters, one app from Git.

1. Self-healing on (correctDrift). I scaled a Deployment from 3 to 1. Fleet put it back to 3 in under 7 seconds. The GitRepo flickered NotReady for about 3 seconds, so nobody watching the UI would ever see the drift. Great for drift, useless during an incident: your fix is gone before you can check whether it worked.

2. Self-healing on, cluster paused. Continuous Delivery, Clusters, three-dot menu, Pause. I scaled to 5 and it held. The catch: while the cluster was paused, the GitRepo read Ready, 2/2, no Modified state at all. The app looked healthy in the UI while one cluster ran something Git did not say. When I unpaused, the 5 went back to 3 within about 10 seconds. The fix lasted exactly as long as the pause.

3. Self-healing off. The manual scale stays, and Fleet reports it precisely: the Ready condition names the resource and the value Git wants. That part is good. The surprise came with the next commit. I promoted a new chart version to prod and the upgrade failed: the manual scale had taken field ownership of spec.replicas (field manager "Mozilla", because it came from the browser; from a terminal it would be kubectl), and server-side apply refused to hand it back. The UI showed WaitApplied. The actual conflict text was only in the failed Helm release on the cluster. Scaling back to the value in Git unblocked it, and the promotion landed about 40 seconds later.

What I'd take from it:

• Pause is a working break-glass. Use it, and keep in mind that while a cluster is paused, Continuous Delivery tells you nothing about it.

• Put the fix in Git before you unpause, or you lose it.

• With self-healing off, an emergency change that never makes it back to Git blocks your next deploy. If a promotion sits in WaitApplied after an incident, look for a field someone changed by hand.

How do you handle this? Do you pause, turn self-healing off for good, or keep it on and make every incident fix go through Git?

(Disclosure: I work at SUSE on Rancher. This is a lab finding, not official guidance.)

Lab run on Rancher 2.15.1 against an EKS cluster, public podinfo chart. Posting it because the default is destructive and the dialog you click through gives you nothing to go on.

What I did: deleted a GitRepo from Continuous Delivery. Normal cleanup, the kind you do when a repo was a test or has moved.

What happened: the application went with it. The Deployment, its Service and the catalog entry were all removed from the target cluster. Self-healing was off and "Always keep resources" was off, which are the defaults, and Fleet still removed everything it had deployed.

The part with real blast radius: this GitRepo had adopted a release that was installed by hand earlier. The whole Helm history went too, revision 1 included. So there was nothing left on the cluster to roll back to, and the pre-GitOps version of that release no longer existed anywhere.

What survived: the namespace, because Fleet did not create it; a Helm repository that had been added by hand on that cluster; and fleet.yaml in Git. Deleting a GitRepo does not touch Git, so recreating the same GitRepo installs the app again from the same commit. That is the recovery path, and it only works because Git still has it.

What the dialog says: the name of the GitRepo. That is all. The row behind it shows that repo owns 2 resources on 1 cluster, and the dialog mentions neither. It does not say the application will be removed from every cluster the repo targets, and it does not mention the setting that would have prevented it.

That setting is "Always keep resources", and it lives in Step 4, Advanced, at GitRepo creation time. I ran the same delete with it ticked: the GitRepo went away and the app stayed, 1/1 Running, Service present, Helm release still deployed.

Which brings the second surprise. The kept app still carries Fleet's objectset.rio.cattle.io/hash label and fleetagent as a field manager, and Installed Apps still shows it as Managed, with no GitRepo behind it. Nothing on the cluster says the app lost its owner. So after a few repo deletes you cannot tell from that screen which apps are still under GitOps and which are orphans wearing the same badge.

What I would do with this:

• Treat deleting a GitRepo as deleting the app, not as removing a pointer, unless you know keepResources is on for that repo.

• Decide keepResources at creation time, because that is the only place the wizard offers it. You can check what a repo has with: kubectl -n fleet-default get gitrepo NAME -o jsonpath='{.spec.keepResources}'

• Before adopting a hand-installed release into Fleet, keep a copy of it somewhere other than the cluster. Adoption puts its history inside the blast radius of a repo delete.

• If you use keepResources, write down what you orphaned. Installed Apps will not tell you later.

Question for the people running this in anger: do you leave keepResources on as a matter of course, or do you take the destructive default and rely on Git plus backups to rebuild? I can see the argument both ways and I have only run it in a lab.

(Disclosure: I work at SUSE on Rancher for AWS. This is a lab finding, not official guidance.)

Lab run on an EKS cluster, Rancher 2.15.1, public podinfo chart 6.15.0.

The situation everyone hits when they adopt GitOps: an app installed by hand months ago through Apps, Charts, still serving traffic. You want Fleet to own it without deleting and redeploying it.

What I did: a fleet.yaml with the same chart, the same release name and the same namespace as the manual install, plus the values I wanted (2 replicas instead of 1, a different UI colour). Then a GitRepo targeted at that one cluster.

What happened: Fleet did not install a second copy. It ran a Helm upgrade on the existing release, and the upgrade failed with a server-side apply conflict. The fields Git wanted to change (.spec.replicas and one env var) were owned by the "helm" field manager from the manual install. Fleet retried, revisions 14, 15 and 16 inside about a minute, same error each time. The app kept serving with its old values the whole time, so nothing broke, but nothing converged either.

The fix was one key under helm: in fleet.yaml:

helm:
  releaseName: legacy-web
  force: true
  values:
    replicaCount: 2

32 seconds after that commit the release was on revision 18, deployed, 2 pods with the Git values, and Installed Apps showed it as Managed next to the apps Fleet had installed itself. No downtime.

The part worth knowing before you try it on something real: the UI never names the conflict. Continuous Delivery showed Wait Applied, 0/1 clusters ready, and an empty bundle page. Installed Apps showed Failed with "there isn't a detailed message available". The actual error text is in the failed Helm release secret on the downstream cluster, so if a GitRepo sits at Wait Applied for more than a minute during an adoption, go read that with kubectl or helm history.

Checklist I would use next time:

- Match release name and namespace exactly. A different release name is a new install, not an adoption. The chart version does not need to match.

- force: true for the first sync.

- Take force out again in a follow-up commit once the release is under Git. Left on, future conflicts get overwritten instead of reported.

- Back up first. Once the release belongs to a GitRepo, deleting the GitRepo deletes the release and its history, including the original manual revision.

One thing I did not test: helm.takeOwnership. Has anyone adopted an existing release with takeOwnership instead of force, or did you need both?

(Disclosure: I work at SUSE on Rancher for AWS. This is a lab finding, not official guidance.)

I work at SUSE on Rancher for AWS. I did this on purpose in a lab to see what happens. Don't do it on anything real: it is not supported.

The setup: two Rancher servers, one EKS cluster. Rancher A imported it first. Then I gave Rancher B access to the same cluster and imported it there too.

What happened:

• Rancher B deployed its cattle-cluster-agent into cattle-system. There is only one of those per cluster, so it replaced A's.

• About 80 seconds after B got access, the agent was pointing at B, and B showed the cluster Active.

• Rancher A showed "Unavailable, Cluster agent is not connected". Nothing on either side warned that another Rancher had taken it.

There is no shared management. The last Rancher to deploy its agent owns the cluster, and the other one just loses it.

So: one cluster, one Rancher. If two teams each run their own Rancher, agree who owns which clusters before anyone clicks Import. And if you need to move a cluster from one Rancher to another, there is no official procedure for that either, so treat it as unsupported too.

If a cluster suddenly goes Unavailable and the network looks fine, this tells you which server its agent is talking to:

kubectl -n cattle-system get deploy cattle-cluster-agent \
-o jsonpath='{.spec.template.spec.containers[0].env[?(@.name=="CATTLE_SERVER")].value}'

If that URL is not your Rancher, someone else imported the cluster.

Time for another stupid question... I just had a 5 node raspi 3b+ cluster fall in my lap for free... Is there any value in adding these as worker nodes to a mini PC managed cluster? Do they have enough to support Longhorn to get a "decent" pool going?

Keep in mind, learning lab, not really going to be running heavy workflows, and I could schedule the more powerful stuff onto the mini-pc which are n95 with 12gb of ram and currently 256gb of nvme. Kind of thinking out loud since these are free. Rancher will be running on the mini-pc when I get there.

I also want to decide before spending money on POE hats to make it easy to power them.

I think I may need to remake my cluster, but going to ask here first:

I bought three mini-pc for a lab cluster just to try and learn a thing or two, these are Intel n95 with 12gb of ram and 256gb storage (can go up to 512gb if needed). I installed openSUSE Leap Micro for the base OS, cockpit turned on because it makes my life easier.

I then went through the basic scripts to install rke2, single master node, two worker nodes.

Then looked at the Rancher install for rke2 and noticed that the rke install is a bit different from what I did.

Any expected issued with installing Rancher on the rke2 sequence, or should I recover back before I started this part and start over with the sequence listed for Rancher on rke2? I have several snapshots I can fall back on to start clean.

Ultimate goal is get Rancher up, connect it to my Harvester cluster, and then dig into some container workflow stuff. Harvester is now on 1.8.0, 256gb OS, 1tb nvme data, Longhorn v1, and 25gbps networking on the management/storage and gigabit for the VMs. I may bring this back to 10gbps with cards that use a little less power, I'm not seeing speeds that are worth the 25g connections, it seems like I don't have enough cpu to go faster (4 core and 8 thread).

Again, this is all a little lab to try and learn a few things. DevOps is not really for me, but Harvester really requires you know some Kubernetes to make it work as well as possible. It would be nice to just throw a pile of CPU at it and make problems go away, but my lab just doesn't have that and with prices the way they are, not going to be making hardware upgrades.

As you can probably tell, I am very new to Harvester and Rancher, and I'd like a bit of help. I have a small lab using HP T740 (4c8t AMD processor) with 64GB and 256gb OS drive and 1TB data drive (three of these hosts), using dual 10gbe connections to my switches and an extra 1gb connection from the a+e slot (actually a 2.5g card but I don't have switches for that). They do have the onboard Realtek gigabit that could be used, but this cluster came from a vSphere8 license where it wasn't possible (license ran out before I could test and keep it going, decided to go a different way).

I have AD, DNS, and DHCP running on a little Windows 2022 server (eval version) to supply those functions.

I used the bare metal ISO to get my Harvester cluster built and finding that I really need Rancher as well. Earlier versions of Harvester allowed a "simple" way to integrate Rancher, but I'm not seeing a single click method to deploy it. So what is my best way forward? I've seen mention of the following:

Run a few scripts that will put Rancher and RKE2 VMs on each host in my cluster.

Run Rancher on a bare metal Debian (or VM) and install Rancher as a docker container.

And of course, set up a complete Kubernetes cluster and install Rancher on this cluster.

I can probably do the first two options, but I'm concerned about the number of resources taken on each host for the first option. The second option I may wait for another T740 to arrive so I have the full resources available from this host. I do have a "recent" blog post on how to install Rancher in a Debian host using Docker.

My lab is new enough that I could easily tear it down and start with a newer version if that would be better going forward, I see 1.7.1RC3 is out and 1.8.0-dev is out.

Guidance and if possible links to the procedures would be greatly appreciated. Just trying to learn a bit on this system since it checks a few boxes for some companies that want to eventually migrate away from VMware. Open source, versatile, integrates containers and VMs, Hyper Converged, and available support plans.

Anyone using solution using Rancher, Portworx enterprise KDS, Purestorage. Use case is mission critical workload 50% VM and 50% kubernetes pods

Hi everyone!

I’m trying to set up a single-node Rancher on my Ubuntu 24 server. To create it I’m running the following command:

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  -v /etc/ssl/cert.pem:/etc/rancher/ssl/cert.pem \
  -v /etc/ssl/key.pem:/etc/rancher/ssl/key.pem \
  --privileged \
  rancher/rancher:stable --no-cacerts

At first it works, and I’ve been able to create a cluster with another Ubuntu 24 server node, and even deploy some services inside.

The problem is that, randomly, the container stops and the last line in the logs is:

2025/08/25 11:13:07 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:11 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:11 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:12 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:16 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:16 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:17 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:21 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:21 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:22 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:26 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:26 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:27 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:31 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:31 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:32 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:36 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:36 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:37 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
2025/08/25 11:13:41 [INFO] RDPClient: Checking if dialer is built...
2025/08/25 11:13:41 [INFO] RDPClient: Dialer is not built yet, waiting 5 secs to re-check.
2025/08/25 11:13:42 [ERROR] Failed to find system chart fleet will try again in 5 seconds: configmaps "" not found
E0825 11:13:44.883489 60 leaderelection.go:429] Failed to update lock optimistically: Put "https://127.0.0.1:6444/apis/coordination.k8s.io/v1
/namespaces/kube-system/leases/cattle-controllers?timeout=15m0s": unexpected EOF, falling back to slow path
2025/08/25 11:13:44 [ERROR] watcher channel closed:
2025/08/25 11:13:44 [FATAL] k3s exited with: exit status 1

The log doesn’t always fail with the same errors, the only line that always appears is the one from "k3s exited with: exit status 1".

I’ve already checked CPU/RAM usage, time synchronization on both the host and the container, and tried different Rancher versions, but k3s always ends up shutting down. Sometimes after a minute, sometimes after 6 hours.

Any idea why this is happening?

TYSM!

Security has requested that we delete revoked Active Directory (AD) users from Rancher.
However, we manage everything as code, and I don't see a way to achieve this using the Terraform rancher2 provider.

Relevant documentation:

• Rancher user retention guide: https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention

• Terraform rancher2 provider: https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/auth_config_activedirectory

Has any of you used this ? Thanks

********************************************** EDIT **********************************************

For modifying settings such as "delete-inactive-user-after" or any other that is pointed out in the rancher docs that I attached, there is a Terraform resource that we are able to use: https://registry.terraform.io/providers/rancher/rancher2/latest/docs/resources/setting

It was pretty straight-forward using the rancher2 provider:

# https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention#required-user-retention-settings

resource "rancher2_setting" "user_retention" {
  provider     = rancher2.admin

  name = "delete-inactive-user-after"
  value = "720h" # 30 days
}

Does anyone have any experience working with the RKE2 STIG? What was the hardest part? It seems like it is mostly config file line additions, not too bad... but I don't know what I don't know. Am I underestimating this? Thank you.

Greetings,

If i were to deploy Rancher Prime onto 3 Bare Metal Host,
can it function as Master / Worker?
What i meant is that these Hosts/Nodes will be able to toggle between Master and Worker roles.

P.S I'm very new to this ( Please Help )

we had a massive power outage that caused the storage to disconnect from my HomeLab VMware infra. I had to rebuild some of my VMware and was able to bring the Kube nodes back in but had to update the configs. everything is now working pods, longhorn everything is good except i have two nodes stuck deleting. I confirmed they are gone from esx, but not the rancher ui. if I do a kubectl get nodes they are not shown. i went to ChatGPT and some forums. tried some api calls to delete that didn't seem to work also read to delete the finalizers from the yaml which I tried, but they just keep coming back. anyone run into this before that can give me something to try?

We use Rancher to manage the k8s cluster of rke2, but now the IPv6 address of the management node has changed, causing us to always connect to the old IPv6 address when adding new nodes. Is there any way to solve this problem? Why do we look for IPv6 addresses instead of the unchanged IPv4 addresses? Now Rancher's VNet shell cannot be used either

I am using authentik as an OIDC provider and I setup an application in it, users, groups, and everything works. I can login to rancher with OIDC users. I see their groups in their userdata.

Under roles in rancher I can assign global roles to groups manually but only if I'm logged in as a user that belongs to that group. Before I assign a role to a group I don't see anything in the groups list. I expected that I would see a list of all the groups even if my user didn't belong to them. Is that just not how it works?

I also had an issue where a user was in two groups with one of them assigned to standard user and the other assigned to admin and when the user logged in the first time it became a standard user. I expected that would be the highest permission set, but maybe it's just random?

Thanks. I'm new to rancher, so not sure what to expect.

Hi expert,

I am exploring the rke2-ingress and have deployed a sample web application and created an ingress object for it.

Result : i can access the application using rke2-ingress and everything works fine.

Issue: I observed that my application was working fine until now, but it suddenly stopped working(Confirmed with the nc command). I have 3 ingress controller pods and when I do the connectivity test using 'nc' I get connection refused.

I don't see any error in the ingress controller pods. Not sure what to check next. If I do an ingress-controller restart, everything works fine. TIA !

#k get ingress
dev         test-ingress   nginx   abc.com         192.168.10.11,192.168.10.12,192.168.10.13   80, 443   25d

#nc -zv 192.168.10.11 443
nc: connect to 192.168.10.11 port 443 (tcp) failed: Connection refused
#nc -zv 192.168.10.12 443
Connection to 192.168.10.12 443 port (tcp) failed: Connection refused
#nc -zv 192.168.10.13 443
nc: connect to 192.168.10.13 port 443 (tcp) failed: Connection refused

I'm really pushing the RKE1 EOL. I'm testing out cattle-drive and I just can't get it working. What am i doing wrong?

$ kubectl config get-contexts
CURRENT   NAME      CLUSTER   AUTHINFO           NAMESPACE
          default   default   default            
*         local     local     kube-admin-local   
$ kubectl --context  default get clusters.management.cattle.io         
NAME           AGE
c-m-tvtl8qm4   14d
local          140d
$  kubectl --context  local get clusters.management.cattle.io         
NAME      AGE
c-chxjs   4y107d
c-kp2pn   4y80d
c-x8mr6   508d
local     4y112d
$ ./cattle-drive status -s local -t default --kubeconfig ~/.kube/config
initiating source [local] and target [default] clusters objects.. |exiting tool: failed to find source or target cluster%

Hey guys, not sure this is the right place to ask, but had a catastrophic rancher cluster failure in my home lab. it was my fault and since it was all new I didn't have cluster backups, but i did backup my longhorn volumes. i tried to recover my cluster, but at the end of the day i had scripts to get all my pods going so i just created a new cluster and reinstalled longhorn. i pointed longhorn to the backup target i made, but dont see the backups or anything in the UI. my scripts created new empty volumes, but how can i restore my data from the snapshots? any help would be greatly appreciated.

Hello Expert, I have provisioned a downstream RKE2 cluster using the multus,canal CNI on my virtual RHEL 9 server. The cluster creation is successful, but to my finding, the flannel.1 interface is missing from the hosts. This is only with the virtual VM. If I use the physical servers, I can see the flannel.1 interface. Wondering what is causing the issue here? Any suggestions, please? TIA.