I admit, my K8S knowledge is not Jedi level, but I am having numerous issues migrating from 1.6 to 2.0. First off, there are a ton of misspellings as well as sections that are incorrectly labelled (i.e. after launching a workload, there are (2) Ports sections, though one is for ports and the other is for environment variables). Could not get Longhorn working for the life of me and NFS volumes seem to be hit or miss.
Launching Mongo replica sets has become nearly impossible when trying to use persistent storage and only some nodes can connect to them despite using their entire internal hostname!
There is no way to restart a cluster or workload from the interface and some instances take forever to spin up or delete, and I am running on the same hardware that has been running Rancher just fine for well over a year.
Also, I find that there is a huge lack of Rancher 2.0 documentation. Besides the quick start guide, which is quite minimal, there are no docs that I can find, only random SO entries with people asking for help.
If there is a better guide for Rancher 2.0 and docs to accompany it, could someone kindly point me in the right direction?
Despite this, I’m still excited by moving to Kubernetes and I see Rancher as a plus in the system as it makes it really easy to deploy.
But what I see is we really need to fully understand how Kubernetes works, not only because that’s what we now really use (i.e. we don’t use Rancher’s Cattle orchestration anymore) but also because Rancher does things to it in some ways…
As a mean of example, take the documentation from Traefik on running it in Kubernetes. Following the documentation step by step to the letter should give you a working Traefik… but it does not. Kubernetes starts no pod. Why?
Well now I have to really understand in full how Kubernetes works and what Rancher does to its basic functioning (i.e. what enhancements it does to it) so I can resolve why “nothing is happening”.
So I feel that while Rancher brings some simplicity in the deployment of Kubernetes, it also adds complexity because it modifies some of the default behavior and it’s not well documented.
I could also be totally wrong and Rancher maybe does not modify any behavior in anyway and does not affect anything and I just don’t understand enough Kubernetes… that may be also the problem… which goes back to my first point - now we need to learn Kubernetes, not so much Rancher.
I quickly fell in love with Rancher 1.x. I simply read the docs and had something working in 1 afternoon. A couple of tutorials later, and I had a very good working grasp of what was going on and how to make it work for our environment. I’ve been a huge advocate since then. Rancher 1.x is great!
Contrary to that experience, I have sunk many, many hours into 2.0 and I’m more confused than ever. Anything beyond the nginx example, and I hit dead-ends quickly.
For example, how do you define volumes? The docs describe some an interesting abstraction model. However, it’s confusing and doesn’t map to anything I can find in the GUI. How does one define and manage storage volumes? https://rancher.com/docs/rancher/v2.x/en/concepts/volumes-and-storage/
This is just one of many questions I have.
I know how new products are released and I trust this is just “v1”. I trust we will start seeing better docs and updates in the near future.
As for now, I don’t think Rancher 2.0 is ready for primetime. Not unless you want to spend endless hours reverse engineering and troubleshooting into the unknown.
So far what I did is use the GUI for viewing only. And I deployed all my prototypes using kubectl apply -f file.yaml. I was, anyway, planning to move to fully configuration file based deployment in Rancher 1.6 so as to keep the deployment units in Git.
True…but, from my POV, Rancher 2.x’s major value prop is in abstracting out the complications of Kubernetes. If I need to understand k8s to make everything work, I’m probably better served just running k8s…
Exactly. This is the reason that I started using Rancher in the first place, the interface abstracted all of the back end which allowed me to focus on my stack. Now Rancher seems to be something cobbled on top of Kubernetes and regardless of anything I have to learn it thoroughly so that I’m able to use it, then what’s the point of Rancher?
I remember reading somewhere that 2.0.x were for testing, and that the 2.x side of things weren’t going to be “production ready” until 2.1. 2.0 is more at your own risk usage. I could be wrong, I remember reading and/or hearing that.
As far as documentation, they’re working on it quite frequently. If you look at the rancher/docs repository, you’ll see a consistent set of commits every business day https://github.com/rancher/docs/commits/master.
Well, I had the same thought. I agree in many ways with you. I checked what it takes to run K8s (in my case on bare metal/vm on-prem) and I can’t say I found this very clear… With Rancher I was able to get a cluster up and running in a minute or two…
I’m not, by any mean, saying that the Rancher doc’s don’t need improvements either…
On May 2nd, I received an email with the subject line “Rancher 2.0 is GA – Ready for Production Deployment” - this does not seem to be the case; a ready for production release should be a fully working release that includes FULL documentation as well as a lack of mislabelling and misspellings. If it’s still in Beta, then that’s the tag it should have.
Either Rancher 2.0 is production ready or it is not. If it is not, then 2.0.X releases need to be marked as such until it’s actually ready.
Not trying to argue, only stating an observation. General availability isn’t the same thing as production ready in all cases. For a free product, it’s amazing work. I’ve found and submitted a couple PRs to them to fix things, anyone is able to. I’m not going to complain about free work… Especially when it actually does help with k8s, cluster deployments and management. Can you do more with CLI? of course, it’s always and will always be that way.
Then General availability and production-ready (email sent) are not the same thing. My only point, and I am also not trying to argue, is that Rancher used to be a very simple process to get a cluster of containers up and running now it seems they rushed too fast into kubernetes and made it very difficult to get up and running as quickly as Rancher devops are used to.
It’s most definitely a HUGE shift - that’s for sure! I think for those who are happy with Racher Cattle and don’t need the advanced power of Kubernetes, I don’t see any reasons to switch.
At least in its current form, for me Rancher adds to Kubernetes in providing a easy deploy package and the authentication/authorization platform with LDAP, etc.
But if you are looking for a point-and-click, easy to learn set up for small/medium operation, with only basic functionalities, then Rancher 1.6x version seems way more appropriate. I don’t remember where I read it but they are planning to support 1.6 for a while.
I don’t speak for Rancher - but I have been using Rancher since it’s very first month. I don’t know where they plan on going with 2.x branch - if they are planning to make it a total abstraction of K8s where you don’t need to know anything about the underlying platform or not.
My take however is that if you have any sizeable, serious operation, you should know all the parts of the stack because when things go haywire, you’re screwed and you have to get it working.
But all that said, to answer the question in the post’s title - I think it’s ready, if you don’t expect it to be a total abstraction of kubernetes.
In defense of Rancher 2, from someone who has never used Rancher 1, it did allow me to move off of Docker cloud before it shut down the orchestration service, as well as provided a primer on Kubernetes. That said, I agree with a lot of the criticism and have since moved to Kops. With default features like “kops runs the masters in an automatic replacement mode. Masters are run in auto-scaling groups, with the data on an EBS volume. If a master node is terminated, the ASG will launch a new master instance, and kops will mount the master volume and replace the master.”, if you are running on AWS, it’s hard to beat.
Actually, to be completely honest, I would run, not walk away from Rancher 2. For the forth time, for no discernible reason, it suddenly says “This cluster is currently Unavailable; areas that interact directly with it will not be available until the API is ready.” And, to quote a wise man, “bdbdbdbdb that’s all folks.”
I have been able to get the NFS mounts to work when I set each one up manually and they seem to be pretty solid. However I would like to setup the NFS-provisioner and find it difficult without some better documentation. I did manage to get splunk logging to work with the firehose way of just sending everything to the http forwarder. There just needs to be more options for filtering and configuring the product. Overall I like 2.0 better than 1.6 but its sparse right now and just needs a lot more work on a few core things.
I can do individual NFS shares, but they seem to work, but are writing files on the local node, not the NFS share. I am also getting “This cluster is currently Unavailable” very often, for no visible reason.
Got O’Reilly’s Kubernetes Cookbook, and working on learning K8S inside and out, which makes Rancher kind of pointless, since the majority of what I need to do will be done via kubectl.
I’m truly disappointed in Rancher, when I saw Production Ready, I assumed they had everything in place for one to get an instance up and running in short order, as was the case with 1.X, but this is not the case.
The product is unfinished, unpolished, and does not deliver on the promises setup by their previous versions. The lack of documentation for Rancher 2.0 is also disturbing.
Is there any chance to get someone from Rancher on this thread to communicate their intentions?
