4 ms·
We're doing a sizable migration from Rancher 1.6 (which uses their internal orchestration system called "Cattle") to Rancher 2.x (which sits ontop of k8s). Ran
by seabrookmx 8y ago
We're doing a sizable migration from Rancher 1.6 (which uses their internal orchestration system called "Cattle") to Rancher 2.x (which sits ontop of k8s).
Rancher 2 definitely streamlines the setup of an on-premise cluster. We use AWS for 80% of our stuff and have in-house servers for the remaining 20%, so it allows us to have a single pane of glass for all of our workloads (the AWS stuff being an EKS cluster "imported" into Rancher).
As a company they definitely seem to follow the "move fast and break things" mantra though. We've seen quite a few boneheaded bugs in the API and CLI tool.. and the fact that 1.x -> 2.x has no real migration path other than "rewrite all your app configurations as helm charts and you'll be fine!" is kind of a bitter pill. In reality the networking and storage side of things is vastly different between Cattle and k8s.
We really felt the limitations of Cattle though, so I understand that this move is necessary. Had they not hopped on the k8s bandwagon we probably would have eventually without them. I guess it's just the price you pay for being an early adopter!
- V99 8y ago> and the fact that 1.x -> 2.x has no real migration path other than "rewrite all your app configurations as helm charts and you'll be fine!" is kind of a bitter pill. In reality the networking and storage side of things is vastly different between Cattle and k8s. We (rancher employee) didn't like it either, and tried, and probably over-promised, but as you said the reality is there is many things in Cattle that map to 0, 1, or 3 possible different ways of doing it in k8s. So there's no practical way to automatically migrate anything other than very trivial usage (which is both not hard, and there are existing docker-compose to k8s manifest conversion tools for).