Rancher as container on its own host?

With the new topology, where Rancher 2.0 uses etc’d as database, what are recommendations for setting up an HA cluster?

Do I need to deploy Rancher to 3 separate machines, or can I move Rancher containers onto their own managed hosts?

Are there any best practices already?

1 Like

Continuing the discussion from Minimal Cluster:

HA setup is coming soon (next week?), but not implemented as of beta3.

@ 19:10 in April 2018 Online Meetup Managing Workloads on Kubernetes with Rancher 2.0

“Since we launched beta, I think the number one question we get right now is, “What’s the HA setup?” …We have it basically there, but we’re still packaging it. Rancher server is basically a service that runs on top of Kubernetes. So the way you do an HA setup is you have to deploy Rancher server in a Kubernetes cluster–which sounds a little bit like “Inception” because you’re deploying a cluster management inside of an existing cluster… What we’re doing is packaging up RKE with Rancher server so you can easily point to 3 servers and it will set up those 3 servers as a tiny Kubernetes cluster, and it will be fully HA. That’s what I’m working on over the next week or so to get HA out there. It should be a pretty simple setup… I’m sure there will be more questions, but the answer is we have it working but we’re still packaging it up.”

Another conversations starts around 1:36:35:

Shannon: "I’ve seen this multiple times so I think there’s maybe a little confusion on this one… People have asked, “Where does Rancher store its state? What happens if Rancher goes down?”

Darren: "What Rancher technically is is an application that runs on Kubernetes as like Kubernetes controllers. Technically, the way it works is Rancher talks to Kubernetes and creates custom resources in Kubernetes and stores its state in Kubernetes. There’s two modes of how that works. If you do docker run, you’re running etcd inside that container and we’re actually running a fully embedded version of Kubernetes inside the one process… It’s all embedded inside of that one process, and it’s saving its state to /var/lib/rancher… so it’s saving its state to the local disk… So if you want to upgrade you can just do --volumes-from or bind mount /var/lib/rancher to some place on disk and that will save your state. So that’s one approach.

The other approach is you just deploy Rancher into a Kubernetes cluster… Rancher will recognize that it’s running inside of Kubernetes, and then it will use that Kubernetes cluster to persist its state. Its state will go into the cluster’s etcd… That’s actually how we’re doing HA deployments."