Is the beta version comming?


Hi Ranchers,

At my company we decided to use Rancher as the Kubernetes enabler, currently using the version 1.6 but we are very excited to use the version 2.0. We tried the preview version, aplha10, but all the features that we need is not available yet.

Considering the version alpha10 is more than a month older, there is any new alpha or maybe beta coming? I’ve watched the webminar about v2 and one of the founders said you was updating the repository 2 times a week, I dont’t know if it is the internal repository or Docker Hub repository.

I know, maybe, we are very excited about the v2, but it is because it will be almost, why not everything we want to manage new and/or running Kubernetes.



The plan with 2.0 has always been to release in Q1 next year (hopefully early Q1) and we are still on track for that. I’m the one that said we would be updating the release frequently. I should have known better to say anything. As soon as I publicly commit time frames we end up changing our approach. We decided to focus on a series of features that we can’t easily stream out. Here is where all the work is going right now. None of this is in a releasable form quite yet, but just wanted to let you know the progress. We will be talking about some of these things more in detail at our next meetup:

Cluster Health Monitoring: Aggregating the node conditions, node resources, component statuses of all your clusters to a simple dashboard

RBAC: Full management of k8s roles and bindings across all your clusters. Our RBAC approach introduces the concept of projects. More details to come about that.

Standalone Kubernetes Distro: This is basically the same Rancher (CNCF Certified) K8s distro that is in 1.6 but pulled out to be completely standalone and CLI/config file driven. This addresses a series of use cases that we will discuss at the meetup

kontainer-engine CLI: This is basically the “docker-machine” for k8s clusters. Specifically designed to be a CLI to spin up IaaS provided k8s clusters. In 1.6 we used docker-machine to launch VMs in the cloud. In 2.0 we will use kontainer-engine to spin up k8s clusters in the cloud

No more java: We decide to drop the last Java component and do it in go. This means less memory, faster startup, easier to grok code base, and one step closer to proper ARM support. This also makes the embedded installation below possible.

Support etcd as our primary Datastore: Historically we’ve always ran Rancher on MySQL. With the focus on k8s now users will have etcd running in there environments. We’d rather not require users to have two different databases (MySQL and etcd) so we’ve decided to move all our MySQL stuff to etcd. We can still support MySQL if people care (waiting to see what the demand is there).

Embedded Rancher Install: Rancher has always had it’s own database (MySQL and now etcd) and it’s own installation (docker run ... rancher/server) and then it would spin up clusters. For people looking for something even simpler, or maybe running on your desktop, Rancher will be able to deploy into an existing k8s cluster (like minikube) and just manage that one cluster. In that situation we will just use k8s CRDs for persistence and there is no additional database or external setup needed.

UI for all of this: More great UI as always.

And more…

I’m sorry we haven’t been able to get this all out in a release for public consumption. I really hope we have another alpha build in December and then in January we can start doing beta builds that will be more stable. (And yes I realize that I’m publicly stating a time frame right now which never works well for me in open source…)

Hang in there, 2.0 is going to be awesome.


One thing.

It is sometimes hard to justify the existance of Rancher to non-technical people, now that you are basically on top of it. Especially compared with the Azure and GCE (and probably AWS from next week on if you listen to rumors) one-stop-shop k8s solutions, where you can spin up a K8s cluster in < 5 minutes. Why should you still use / add / manage Rancher on top of it?

So I think it would be great to have a (big) “Why Rancher?” page which clearly lines out the advantages of Rancher vs. plain K8s, like “k8s limitation 1, 2, 3, … without rancher -> solved like that”.

Don’t know if that is just me, I just would find that helpful to direct people to (and to have a quick overview of the Rancher key selling points myself).

As for me, I am most curious about the coming Rancher K8s RBAC feature. Very much so :slight_smile:


I’m liking how this all sounds, except for etcd. I have had so many issues related to etcd while upgrading my Rancher k8s envs, i just don’t trust it. We really like the idea of MySQL, we have a high degree of comfort and support for it internally, we have none of that with etcd. We have several monitoring and reporting scripts that query the Rancher DB, I really don’t want to have to “convert” that to some etcd specific thing (if it’s even possible).

I’d say proceed with etcd, but as you noted, please allow MySQL as an available option for users to select, and continued support for Galera/Percona clusters would be much appreciated as well.




@ibuildthecloud thank you for all news about the v2.0. As the others users here mentioned and in other posts I think keeping MySQL as a legacy for a smooth transition could be great.
We have decided at my company to use Rancher as our multicloud manager for containers platform just because we are betting all of our expectations on the v2, but today is very hard to justify it without something more plausible, like access control, machine drivers, and so on… as preview I think the lastest alpha is OK, but for a real evaluation it is really too simple and we have more doubts on how it will work on the GA release. Your answers to this post have helped us to make a clear picture of what to expect.

Thank you and thanks for your great job doing this great tool.


Feedback for Rancher 2.0:

It is a little concerning to plug in my administrative IAM credentials for Amazon EC2. You might want to provide a simple copy/paste script to create an IAM policy and IAM user with the necessary permissions in order to deploy and configure hosts, and spit out the IAM credentials to the user.

Normally I would do this myself, but I don’t know which API calls Rancher is making to AWS, so I don’t want to create an overly restrictive IAM policy.


Will docker-compose be supported fully in racher2.0?


Do you have a working IAM policy for EC2 nodes? I’m having trouble setting up EBS storage class which requires nodes to have proper permissions.