Rancher with cattle vs Rancher with Kubernetes vs Standalone Kubernetes Rancher with cattle vs Rancher with Kubernetes vs Standalone Kubernetes kubernetes kubernetes

Rancher with cattle vs Rancher with Kubernetes vs Standalone Kubernetes


There is now a very good answer to this. Rancher just moved 100% into Kubernetes by announcing Rancher 2.0: http://rancher.com/announcing-rancher-2-0/. It does not use Cattle anymore.


After 1+ year of using Rancher + Cattle and Kubernetes in production simultaneously, I can share some personal observations, but first let me share some thoughts on Kubernetes vs Rancher + Cattle:

  1. Kubernetes is astonishingly flexible and designed to be extendable. There are two pillars on which Kubernetes cluster stands - kube-apiserver as a main unit and etcd as a storage. Other basic components are vital for a cluster, but they were designed to use kube-apiserver's API as any Kubernetes extension should. You can design your cluster the way you need, use different network providers, authentication/authorization services, volume providers and substitute almost every component in cluster - and if configured correctly your extended Kubernetes cluster will be more stable than basic Cattle cluster in almost any case, not speaking of Cattle extensions.
  2. Kubernetes has a lot of useful out-of-the-box features for persisting your data, keeping your data secret and control access to it. This is important part, rancher-nfs is quite fragile, moreover, NFS-storage is the only more or less stable option you have in Cattle to keep volumes, not mentioning local storage.
  3. Kubernetes is an overkill for non-frequent deployments and development in a small team. No doubts, Cattle has been created as a simple clone of Kubernetes and has inherited its basic concepts of namespaces, pods, scheduling, etc., yet making it very easy to deploy and maintain a cluster, making it useful for developers with no understanding of containerisation and networking. Due to its simplicity it became pretty unusable for heavy and dynamically changing production projects.
  4. Kubernetes community is growing fast, being supported by cloud providers and by uncountable number of open-source project and startups, so it's wiser to learn Kubernetes than Cattle, which is one foot in grave now.
  5. And finally - Cattle is unstable, very unstable. Especially if you plan to use it with bare metal. Believe me, you don't want to use Cattle in production.

And speaking about Rancher + Kubernetes tied together - it's a very nice combination, Rancher web UI makes Kubernetes concepts simpler in a good way, cluster maintenance and provisioning become much easier, but there's always some "buts": Rancher 2.0 is very unstable, too, bugs make it unusable for production now. Can't say anything about Rancher 1.x + Kubernetes.


In our experience,Cattle is just a toy. It's just suit for development or some small environment. If you used Cattle in PROD, you will know what I say.

But Rancher is far more concise and simple than k8s.

So I'm looking forward to the Rancher 2.0,

Rancher 2.0 is a complete container management platform built on Kubernetes