Rancher 2.0 GA | Hacker News Reader

Rancher 2.0 GA

rancher.com

154 pointsbithavoc25 comments

We use Rancher 1.6 at my job and it has been widely and rapidly adopted by all of our development teams.

All of our processes are containerized now, even going as far as moving off license restricted (e.g. SSIS) software to open source alternatives to unify our process.

It's been mostly painfree, occasionally there are bugs in Rancher but nothing has been a show stopper.

What did you use in place of SSIS?

Everybody who wants to run Rancher with zero initial setup can use our managed Kubernetes/Rancher service which we launched today: https://www.KubeBox.com

We are still in closed beta but if you are interested, please sign up and we will activate your account asap.

Personally, I think Rancher 2.0 is a fantastic add-on to any Kubernetes cluster for managing projects, users, groups, permissions and workloads and I would like to congratulate Rancher to their release.

Tried for an hour to use this version, here's some things that I struggled with:

- PersistantVolumeClaims: I tried to launch a Postgresql workload and didn't get a warning that I should configure EBS before

- I tried installing rancher on my machine and later found out that the nodes need to reach rancher

- I configured Pipeline with Github but I cannot find any ressource about what to do next, I assume that it is a CI service but it's not explicit

Thanks for your feedback. I ran into #2 myself when trying to add a DigitalOcean node to a Rancher server running on my laptop. We will address these issues ASAP, at least make the failure scenario more obvious.

I choose Rancher 1.x for a large project at my last place, it allowed Researchers to run their algorithms wrapped up in containers. From the start Rancher was the perfect solution that checked all the boxes: really easy to use web interface, LDAP Authentication, automatic deployment of hosts, easy to wrap up deployments into catalog items. But after a few months it was just so unbelievably buggy due to the products maturity.

It's good to see they have got their focus right with version 2.

Thanks for using Rancher 1.x, which definitely went through growing pains. The latest Rancher 1.x release, 1.6.17, is actually quite mature and solid. But as much as we like 1.6, the container industry is very different now from the days we built 1.x. With Kubernetes available everywhere, we no longer need to write our own orchestration engine and worry about networking and storage integration, we can focus on things Rancher does well, as you pointed out, things like the web interface, authentication, node (host) management, and the catalog.

I've been using it with Cattle for more than a year now, I've saved thousands of dollars in PaaS bills thanks for my little Rancher cluster. I just setup a new Rancher 2.0 cluster controlplane and dashboard in Scaleway Paris with a Worker in Digital Ocean NY. I'm starting to migrate all my apps from the 1.6 to the new cluster. I haven't tried the new CI/CD thing, but it looked great in the training sessions.

Heavy rancher user here for managing Kubernetes clusters, the Rancher team has been an absolute dream to work with, fast to fix issues, and have created a super solid product. Very excited for the migration to 2.x from 1.x (:

As a heavy user of Rancher 1.6 this is amazing news!

The only gripe I have is the api is not as functional as 1.6, It's lacking features such as upgrading a pod. Other than that it's looking better than ever.

Folks sometimes underestimate how much work it takes to build a platform. So I deeply mean this: congratulations.

If I only have GKE clusters, what does Rancher mainly offer on top of that?

i.e. do i need an abstraction layer over my orchestrator?

Somewhat reminiscent of the early 2000's fad to abstract over databases when in reality folks never 'swap out the db' on real projects.

At Rancher we don't really want to introduce another level of abstraction on top of Kubernetes. You are right there's no value in doing that. Kubernetes is already the orchestration standard that most people are willing to use and most infrastructure vendors are willing to support. Rancher just tries to make it easier to manage lots of Kubernetes clusters.

"fad to abstract over databases"

cough Is it not called an ORM?

Some can be used for that, but it's not their main purpose. Not all ORMs are database-independent (the one we use uses postgres-specific features), and conversely, if you just need independence you're probably better off using something lighter.

(Rancher employee)

A few of the top of my head...

- UI for managing all the major resources (that isn't read-only or "insert large properly-formatted yaml file here")

- Access control integration to other systems like AD

- Grouping multiple namespaces into "Projects" and doing RBAC and Secret definition/assignment at that level instead of duplicating yourself for every namespace

- You only have GKE clusters today but if tomorrow you want something on Amazon or your company acquires a team with existing stuff in Azure you can still have one place to manage it

I have been using Rancher for almost two years now on dedicated servers. Never had any major problems and thanks to it I have saved hundreds of thousands of $.

We've been trying the Rancher as our kubernetes management interface, looks promising but we're still in a very early stage of usage.

I love the concept of Rancher for someone working in Corporate Atmosphere - where I have to install everything on the companies infrastructure and all the GKE, Fargate and Azure Kubernetes is not allowed... But the people at Rancher failed to recognize that they need to support clustering without any manual intervention to actual click through their UI to achieve clusters - give me an automated joining of clusters method - if you want me to adopt Rancher.

(Rancher employee) I'm not sure what you're asking for but the UI is l00% static client-side code. Everything it does can by definition be automated through the API.

Getting the command to import a cluster is ~5 calls from a brand new server container.. Login with admin/admin, set a better password, set the server-url, create a cluster and get the registration token/command for it.

Does Rancher now support Rook for PVC?

Would love to know if there's a clean / simple integration for something like Rook or OpenEBS. IIRC, I saw a few folks had Rook set up manually on a Rancher-based cluster in the tech preview or beta 2.0 days...

Having a simple way to run your own block storage that could withstand node failures / network issues would be fantastic.

I had some time to play with it and managed to setup rook, but I was unable to use it with any of the catalog apps. Ingress didn't seem to work either - what's the point having apps if you can't access them ;) Actually nothing worked in Rancher except its dashboard. I can't understand what's the point of this project is now, as you can have better results with original Kubernetes dashboard and there everything works. I feel very disappointed :(

Congrats guys!!

Reply on news.ycombinator.com