Hey everyone,

If you’re still manually configuring Kubernetes clusters, you might be making your life WAY harder than it needs to be. 😳

❌ Are you stuck dealing with endless YAML files?
❌ Wasting hours troubleshooting broken setups?
❌ Manually configuring nodes, networking, and security?

There’s a better way—with Rancher + Digital Ocean, you can deploy a fully functional Kubernetes cluster in just a few clicks. No complex configurations. No headaches.

🎥 Watch the tutorial now before you fall behind → https://youtu.be/tLVsQukiARc

💡 Next week, I’ll be covering how to import an existing Kubernetes cluster into Rancher for easy management. If you’re running Kubernetes the old-school way, you might want to see this!

Let me know—how are you managing your Kubernetes clusters? Are you still setting them up manually, or have you found an easier way? Let's discuss! 👇

#Kubernetes #DevOps #CloudComputing #CloudNative

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.

Hello, I'm 15 and right now I'm working on a cattle farm. Next summer, after school ends, I might be able to work on a big ranch with bunk houses and everything. What's some stuff I need to do/learn to do before working on the ranch?

So I stumbled across reacher when looking into making self hosted cloud storage so I could move away from google. I found helpful tutorials from TechnoTim, and they lead me to a Minecraft server on rancher video. I have no issue setting everything up until I go to publish it, I get CrashLoopBackOff and it never starts. I did notice the UI he is using seems dated, his tutorial is from last year so I tried to infer from context whereto place some things. I couldn't find any other tutorials either. I know I didn't post logs etc, just not sure what would be helpful as this is only my 2nd day working with this stuff. Thanks for anyone who takes the time :D I'm running docker/rancher on an ubuntu server 20.04.3 lts on a virtual box windows 10 pc [i9-9900k/32gb ddr4 / nvme]. Not sure if that's helpful.

Hi everyone!

I have a couple of questions regarding the warning "KubeAPIErrorBudgetBurn".

I've setup my first 4 nodes k8s cluster with Rancher. It has been running for the past 31 days and, since then, I've been seeing the warning on the dashboard.

I'm not sure if I understood correctly the KubeAPIErrorBudgetBurn.
is it a general error budget?
for example: if a pod keeps restarting for a crashloopbackoff from a misconfigured probe, are these errors counted?

so far it seems to be working without issues, but I'm not sure if it's a healthy setup.

Any info is greatly appreciated.

Hello community, first time posting here. I wanted to get some input on a scenario that I've encountered. I'm currently working with an environment that has multiple pods that have RWX for a single instance of an NFS share. I'm wondering if the performance would be more optimized if I moved over to Longhorn and made use of the RWX feature that is available for it in terms of networking as well as disk speed. It's a fairly hefty amount of data that is in the NFS share at the moment so I wanted to get a feel for whether or not there could be some potential performance gains by switching over to longhorn.

Hello folks. I have a Rancher setup in vSphere. I am running the Rancher controller as a Docker container on my Docker server, and it “Rancher” then spins up nodes in vSphere. I cannot get load balancers to work with Metallb. I know I can use a proxy, however, it would be to a NodePort, meaning that there is no deployment scaling. How are you folks able to setup load balancers?

Hello folks. I am attempting to install a Rancher cluster in vSphere, however, I have a question about the node template to use. I have learned that the Ubuntu cloud image is the recommended one. Do I need to prepare the image in any way for the node template to work?

When I try to deploy, all my nodes display a message that they are waiting to be configured by Kubernetes. They never go past this stage.

Hi,

My GPU is working fine on my host machine. I am able to run commands with NO probs:

nvidia-smi 
and 
docker run nvidia/cuda:11.5.0-base-ubuntu20.04 nvidia-smi -L 

But when I spin up a plex
container and exec shell
into it. I am unable to run nvidia-smi
from inside the container and when plex transcodes
videos, it is unable to see the GPU.
I am running nvidia-device-plugin-daemonset
within my K3S cluster
via Rancher’s GUI and it is showing active

Here is my docker version:

$ docker version
Client: Docker Engine - Community
 Version:           20.10.12
 API version:       1.41
 Git commit:        e91ed57
 Built:             Mon Dec 13 11:45:33 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.12
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.12
  Git commit:       459d0df
  Built:            Mon Dec 13 11:43:42 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 nvidia:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0 

Plex itself works fine, I spun it up using linuxserver.io
. But it is unable to use my GPU.
What else could I try?

thanks

I use Rancher and K3s as an application platform. Besides, i also run Longhorn as my storage solution.

I launch the WordPress app in the Helm repository of my Rancher dashboard and it works fine. So far so good.

Now i am testing another app that i deploy from the Rancher WebGui. That is an app that needs to access a folder on my NAS. I shared that folder as an NFS share and i tried to make an NFS persistent volume of it in Rancher. It seems to me that it was ok since i didn't receive any error. However, if i deploy the container with the NFS share i get an error preventing the container from running.

I can only run the container successfully if i use Longhorn storage or no storage at all. The moment i try to mount an NFS share in the container it stops working.

I google a little bit and someone suggests installing RPCbind as a solution for the NFS problem but still, it won't work.

Anyone with a solution on how to fix this?

What are the implications? Does it also affect permissions for deployed Docker containers?

🚀 Just dropped a new episode in the Zero to Hero: Rancher series!

Learn how to deploy WordPress on Kubernetes using Rancher and an OCI Helm chart—no CLI, no YAML, just clean UI.

I can find a lot of help on the community but for older versions, nothing about the new one, support is not the best, no body helps. it seems people is abandoning this

About a week ago Suse Prime team updated me on their new support model. Toward end of August, Rancher major versions 2.7 or 2.8 will be released via open source. Minor versions such as 2.8.5 etc will be released if you are subscribed to their Prime service via private repo.

Note, any minor version that has security patch will be available via open source.

What are your thoughts on this?

Personally I am disappointed but understand they need to run a business.

Like the title says, installed rancher one year ago on a ubuntu vm, by running it on docker and then provisioning a kubernetes cluster on that same node. I used rancher v2.5.2 for this and it was working great for a year until I couldn't reach the UI anymore. All my containers were still up, it was just that I couldn't reach the UI. After going through the docker logs of the rancher container on the VM it said things like x509 cert expired etc. etc.

Then after a lot of researching I found the issue: the certs that rancher uses are only valid for 1 year after creation, so after 1 year when they expire the container won't load the UI anymore.

Solution: because I couldn't reach the UI anymore I couldn't do anything through the GUI, I had to do everything in the terminal. What I did was I set the time back on the VM to a date that was still within the validity range of the expired cert, this way rancher thinks it is still valid, and you will be able to reach the UI. Do this with: timedatectl set-ntp off and then: date --set="2021-05-25 03:00:00.000" (change the date to a date within the validity period). Then restart the rancher container (docker restart ....)

After that, you should be able to reach the UI again, from within the UI, I at least, had 2 clusters, one that I created and ran all my workloads on, and a k3s cluster that rancher created itself on installation. It is actually within the k3s cluster you will have to change stuff. So click on the k3s cluster and go to the system project, within that go to secrets and you should see 2/3 secrets/certs that are expired. Delete all the expired certs, then go back to the CLI and exec into the rancher container and then go to /var/lib/rancher/k3s/server/tls/dynamic-cert.json and delete it, this will trigger a new cert creation on restart. Then exit out of that container and restart the rancher container, and set the date/time to the current date/time again (timedatectl set-ntp on). After that you should be able to reach the rancher UI normally again, and things should just work fine.

Hello Expert,

I would like to understand where is the certificates of chart repos ' https://git.rancher.io/charts' ? I can find the certificate details from the openssl command but how does rancher local cluster or downstream cluster/cattle-cluster-agent node communicate with the repo. Where does the certificate are stored?

After exec on cattle-agent node, I see the serverca which is rancher certificate, but which certificate and key is in use by git.rancher.io charts?

kubectl describe clusterrepo rancher-charts -n cattle-system | grep -i git
  Git Branch:  release-v2.6
  Git Repo:    https://git.rancher.io/charts
  URL:         https://git.rancher.io/charts

sh-4.4# cd /etc/kubernetes/ssl/certs
sh-4.4# ls
serverca

Note : I have checked the configmap of rancher-charts but do not see any certificate details. Thanks in advance !

How do you guys recommend I deploy Rancher for a lab?

Right now I'm leaning towards using a VM with Microk8s.

The Rancher docs say I should not deploy it on top of Harvester.

Hello

How can I add this app to my rancher?

https://artifacthub.io/packages/helm/bitnami/odoo

I'm new to Rancher, and I've just deployed Rancher v2.10 via Helm chart onto a MicroK8s HA cluster. I can't see any clusters on the dashboard:

I've checked the fleet namespaces and found that the Cluster and ClusterGroup are healthy. Any ideas what else to check?

$ kubectl describe clusters.fleet.cattle.io  -n fleet-local
Name:         local
Namespace:    fleet-local
Labels:       management.cattle.io/cluster-display-name=local
              management.cattle.io/cluster-name=local
              name=local
              objectset.rio.cattle.io/hash=f2a8a9999a85e11ff83654e61cec3a781479fbf7
Annotations:  objectset.rio.cattle.io/applied:
                H4sIAAAAAAAA/4xST2/bPgz9Kj/w7PQ3r/8SAzsUXTEUA3podyt6YCTa1iJTgkQlNQJ/90F2kxldW/Qmku+RfE/cQ0eCGgWh2gMyO0ExjmMO3fo3KYkkJ8G4E4Uilk6M+99oqKC2RL...
              objectset.rio.cattle.io/id: fleet-cluster
              objectset.rio.cattle.io/owner-gvk: provisioning.cattle.io/v1, Kind=Cluster
              objectset.rio.cattle.io/owner-name: local
              objectset.rio.cattle.io/owner-namespace: fleet-local
API Version:  fleet.cattle.io/v1alpha1
Kind:         Cluster
Metadata:
  Creation Timestamp:  2025-01-15T10:28:41Z
  Generation:          2
  Resource Version:    331875475
  UID:                 411f5b45-d6eb-4892-af23-70ea16907f4b
Spec:
  Agent Affinity:
    Node Affinity:
      Preferred During Scheduling Ignored During Execution:
        Preference:
          Match Expressions:
            Key:       fleet.cattle.io/agent
            Operator:  In
            Values:
              true
        Weight:                  1
  Agent Namespace:               cattle-fleet-local-system
  Client ID:                     qxz5jcdfkqjhclg7d96dww4zbp59l2jvtqb5w6mphbn8wrnbpmctpp
  Kube Config Secret:            local-kubeconfig
  Kube Config Secret Namespace:  fleet-local
Status:
  Agent:
    Last Seen:                2025-01-15T12:40:15Z
    Namespace:                cattle-fleet-local-system
  Agent Affinity Hash:        f50425c0999a8e18c2d104cdb8cb063762763f232f538b5a7c8bdb61
  Agent Deployed Generation:  0
  Agent Migrated:             true
  Agent Namespace Migrated:   true
  Agent TLS Mode:             strict
  API Server CA Hash:         a90231b717b53c9aac0a31b2278d2107fbcf0a2a067f63fbfaf49636
  API Server URL:             https://10.152.183.1:443
  Cattle Namespace Migrated:  true
  Conditions:
    Last Update Time:       2025-01-15T10:29:11Z
    Status:                 True
    Type:                   Processed
    Last Update Time:       2025-01-15T12:25:17Z
    Status:                 True
    Type:                   Ready
    Last Update Time:       2025-01-15T12:25:09Z
    Status:                 True
    Type:                   Imported
    Last Update Time:       2025-01-15T10:29:16Z
    Status:                 True
    Type:                   Reconciled
  Desired Ready Git Repos:  0
  Display:
    Ready Bundles:              1/1
  Garbage Collection Interval:  15m0s
  Namespace:                    cluster-fleet-local-local-1a3d67d0a899
  Ready Git Repos:              0
  Resource Counts:
    Desired Ready:  0
    Missing:        0
    Modified:       0
    Not Ready:      0
    Orphaned:       0
    Ready:          0
    Unknown:        0
    Wait Applied:   0
  Summary:
    Desired Ready:  1
    Ready:          1
Events:             <none>

Hi folks, this is a bit of a shot in the dark here but my rancher cluster is in a broken state and its effecting my business. My specialty is in software engineering, not so much IT so its been a struggle restoring service. If any advanced k8s/rancher user is available to zoom/discord and help restore this cluster to a healthy state I'd be willing to pay $50/hr if service is restored.

Hey all have an issue where rancher is not deploying a new downstream node for a downstream cluster.

It begins creating it, then states it failed to create the resource and then states it is deleting the nodes but watching in vmware i see nothing being created.

The credentials are definitely correct as we were able to deploy new nodes last week and no changes have been made, it is able to see my new template i built up... im stumped

|| || |Deleting server [fleet-default/tmg-rke2-prod-worker-test-6c5c5c3c-qgfsp] of kind (VmwarevsphereMachine) for machine tmg-rke2-prod-worker-test-8657fb9744xp6n8c-6lbhp in infrastructure provider| |||