How To Manage Production-Grade Kubernetes Clusters With Rancher

[@DevOpsToolkit]

What do you think about the new Rancher? IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), KZbin tends to delete comments that contain links. Please do not use them in your comments.

[@denonciz]

"hey, again: Happy thoughts" just killed me 😂😂😂

[@jufherrera]

Don't forget about unified authentication across on-prem/cloud/managed clusters. That can be a real nightmare if you have to deal with security on each cluster. Rancher can centralize auth and integrate with the most comon auth providers and protocols. That way you can build a true multicluster Auth & RBAC model that no other vendor is offering right now.

[@DevOpsToolkit]

You're right. Unified RBAC is good with Rancher, even though it might be annoying to have to go through Rancher instead directly to k8s (at least that's how it was before). That being said, I feel that's less of an issue now than it was before. With GitOps tools like Argo CD, Flux, and, the very own, Rancher Fleet, it's easy to have the same resources, including authentication, applied across any number of clusters. On the other hand, Rancher's target audience is likely not going for those types of tools in which case RBAC is truly awesome. Now, if Rancher continues down the GitOps path with Fleet, RBAC will be slowly moving towards Git instead of Kubernetes clusters.

[@shinebayar]

Very good analysis towards the end of the video. Indeed it would be awesome if Rancher could be defined as GitOps from the beginning. Until there we have quite a lot manual processes to automate. Rancher UI is probably the most impressive of all. Openshift is great, but hey $$. Most importantly Rancher handles the AuthN & AuthZ on itself which is the best part of it.

[@mareimorsy3182]

HPA is not part of service discovery for sure, however I can relate that when scaling occurs it requires a service discovery :D

[@gunnarsinn3868]

Your review is awesome and spot on on the strategic direction of rancher. Hope that the next improvements come soon. I would love to see a detailed review how to IMPORT purely DECLARATIVE an existing cluster. I did not manage that step without running cli api commands to get tokens which somewhat break the pure declarative approach. I also expected to have a way to deploy the cattle-cluster-agent via a helm chart or similar on the import target clusters, but could also not find that (only copy of yamls with API token from WEB UI). Reason for importance of IMPORT is still that clusters are deployed not yet centrally. It would be great if the cluster import could happen completely declarative. Last but not least I tried to play with k3d clusters. Using the generic provider leaves some gaps here. A provider for k3d k3s cluster would also be awesome to be very autonomous on local playgrounds. GREAT VIDEO! I am excited about ranchers strategic direction (hopefully: gitops for infrastructure and apps manageable via UI or concurrent declarative approach).

[@DevOpsToolkit]

You're right. Rancher is still not where it should be, but the direction is promising. The good news (for users, not SUSE/Rancher), is that the competition pressure is increasing so we'll see whether Rancher will manage to stay on top.

[@holgerwinkelmann6219]

It does Cluster API partly, just for Maschine Controllers. Quite similar to Gardener, which is using Maschine Controller as well

[@amarnathmansali2687]

This is the exact video I was looking for thanks DOT ❤

[@DevOpsToolkit]

Thanks

[@chris0628]

Useful stuff starts after @5:20 mins of yapping

[@jackievirgo6907]

Rancher still seems 2 versions behind k8s. With how AWS supports k8s versions are people updating rancher / k8s often? How does that work?

[@xnpwakdn6116]

Great video! Looking forward for RKEv1 VS RKEv2 videos

[@holgerwinkelmann6219]

Thanks for the hint to the new video ;) ❤

[@christianibiri]

I love your channel, it rocks!

[@andelmanlev]

Latest is always the best both for kubernetes versions and your container images tags 💪

[@srikantt]

Do you have a comparison between ArgoCD with Kustomize and Rancher Fleet for GitOps?

[@DevOpsToolkit]

I am planning to compare Argo CD, Flux, and Rancher Fleet. I am not yet sure when it'll be done though.

[@marvinlnnx]

Hi, Thanks for your great contents on DevOps topics, I have to deploy the services on premises, cloud is not an option, it is for a Telecom sector, so do you have any suggestion for me ? for instance should I go with Rancher ? if so Open-Source one or enterprise ? or is there any cloud solution is available for Telecom ? (Core Services)

[@DevOpsToolkit]

I would probably start with Cluster API in that situation.

[@marvinlnnx]

@@DevOpsToolkit I didn't get your point ! what do you mean by using cluster api please ?

[@DevOpsToolkit]

@marvinlnnx ClusterAPI is a Kubernetes SIG project that allows you to manage kubernetes clusters almost anywhere.

[@jackievirgo6907]

Ok so I have my Rancher cluster. I run into RBAC issues with my first new cluster create from Rancher (an EKS cluster). Reach out to the community in slack in rancher-users workspace. Crickets. Reach out in Kubernetes slack in the rancher channel. Crickets. So there is seemingly a community but they seem very quiet overall. I am struggling to figure out why I have to create RBAC rules on a cluster Rancher is creating. I understand it in the context of importing an existing cluster but I have yet to have a successful deploy from Rancher because of this. It's a bummer a cluster just stays in error because of RBAC even though the cluster successfully exists.

[@DevOpsToolkit]

If you're managing EKS clusters, you might be better of adopting one of the Infrastructure-as-code tools than going through the UI. Rancher is a better fit for on-prem self-managed solutions. If you need some kind of a dashboard as a UI, there are plenty of dashboards for Kubernets. What I'm trying to say is "use IaC to manage resources and UIs to observe the state".

[@jackievirgo6907]

@@DevOpsToolkit Yeah I ended up just deploying with TF as I needed to work on testing tools not troubleshooting Rancher. We will have many on-prem clusters to manage so Rancher seemed like solid tool to use for cluster management.

[@DevOpsToolkit]

@jackievirgo6907 i think it is the other way around. The more clusters you have, the more beneficial IaC tools are when compared to GUIs.

[@scottamolinari]

Thanks for the video "upgrade" of your rating. Is offering an API for the remote control of Rancher also something the competition offers and what would you consider to be decent competition to Rancher?

[@DevOpsToolkit]

There are other tools offering API access. The direct competition would be Tanzu and OoenShift.

[@m19mesoto]

LoL, that much love from your videos as usual.

[@admun]

Rancher was nice, and I use it at home... but it is so unstable to me; I am basically still stuck in 2.6.2, 2.6.3, even patch1 still crashed in my setup. And 2.6.2 crashed every other day or so. Ok, I am running it from docker.... which is not supported, but it works since 2.0 until now.

[@user-mt6lk8ld7w]

What exactly do you not like about RKE 1? What is your preferred software for quick cluster setup? Kubeadm? RKE? Kubespray?

[@DevOpsToolkit]

To begin with, it uses Docker not only as the container engine but also to launch other RKE core components. It's been years since it was known that Docker is not a good fit for k8s, quite a while since deprecation was announced, and now it's officially gone while there is still no RKE version without it (experimental does not count). That alone is enough. To be fair, I did not complain about RKE1 few years ago. All I'm saying is that time was not kind to it and Rancher took too much time to address the issues through RKE2 which is still experimental.

[@shady4tv]

@@DevOpsToolkit just for the sake of clarity - RKE2 is not experimental it has stable releases and is being developed in parallel with RKE. In rancher RKE2 downstream provisioning is experimental but not for much longer ;)

[@DevOpsToolkit]

@@shady4tv You're right. I did not express myself well. I meant RKE2 within the context of Rancher, not as standalone. From what I saw and experienced, RKE2 alone is awesome but not many use it without Rancher. My complaints about Rancher are mostly focused on 1) RKE1 (in the context of today, not when it was created), 2) Rancher taking a lot of time to bring in RKE2 (at least a year, if not more), 3) Rancher not working with hosted k8s (making it "on-prem only" type of solution). 1) and 3) are solved and 2) is around the corner. Once that's in, Rancher needs to think about what makes it "special" since most of competition has similar solutions as Rancher with the exception of RBAC (which will have to change with GitOps, but that's a separate subject). That's where Fleet comes in. It's what makes Rancher "special" and different from competition. Still in very early stages, and others are already working on something very similar. CAPI is changing the game and enabling everyone to use tools like Argo CD and Flux for managing their clusters. The only thing really missing is to use Git as storage against which Web UIs are operating and keep communication with the cluster mostly for read-only operations. End users will not notice the difference, but ops/SREs/DevOps/whatever-we-call-each-other-today will get what they need. That's the edge Rancher has today. But it needs to be fast since that's the same direction others are going.

[@olafradicke1492]

Thanks Viktor for the new video! The biggest competitor of SUSE (the new owner of Rancher) is the Red Hat/IBM and its product OpenShift. Which do you think is the better choice, in the enterprise on-premise environment?

[@DevOpsToolkit]

OpenShift dominates the market for on-prem k8s clusters and its scope is much bigger than Rancher's scope. The same is true for the price. I think that OpenShift is better if you want to commit to RHEL/IBM ecosystem. Rancher, on the other hand, is a good choice if you are looking for something that is lighter (both in resources and required skills) and closer to "vanilla" Kubernetes. Rancher is free and I think that their revenue comes almost exclusively from support contracts (I might be wrong on that one). I think that there is a free OpenShift version but, if there is, I don't think that many use it except as a limited trial. From my (limited) experience, OpenShift tends to be the most common choice in enterprises who want to start with a commercial option right away while Rancher tends to be the choice for those who prefer free with the option to pay later (e.g., support). All that being said, I see that I did not give you a straight answer and I'm about to say something that I am trying never to say because I hate when others say it. But, in this case, it's really "it depends".

[@fenarRH]

@@DevOpsToolkit There is a free version for developers, I tried add resources here but utube constantly deleting my comment.

[@DevOpsToolkit]

@@fenarRH You mean www.okd.io? While I give RHEL full credit for dominating on-prem commercial market, I cannot say the same for the free version. That's where the situation is reversed.

[@fenarRH]

@@DevOpsToolkit not okd, I mean real ocp access with developer account, sent you pm on linkedin.

[@shinebayar]

Openshift open source is literally nonexistent, It's expensive Enterprise grade solution. I know they do advertise OKD, but once you're ready to commit you know what I'm talking about. On the other side Rancher is fully open source. But one thing I dislike about Rancher is they try to push their services as much as possible and almost try to hide their open source version.

[@stockrt]

What about app deployment? Maybe you could talk about Kubevela someday. Cheers and thanks for the great content.

[@DevOpsToolkit]

Something like kzbin.info/www/bejne/aHSlpmmphLmnrc0 ?

[@SubaniPrasad]

Hi Viktor, Can you make a video on AWS ACK Controllers ?

[@DevOpsToolkit]

Good idea. Adding it to my TODO list... :)

[@AlbertoVillacorta396]

I've not taken a deep dive. But have you checked it's ability to generate an audit log for regulated environments? ie who made what change in what environment/workload?

[@DevOpsToolkit]

I did not bother checking that since I believe that such requirements should not be handled through ClickOps. The best way to keep an always-up-to-date audit log is to keep everything in Git and apply GitOps processes on everything. In that case, I'd use Rancher in "read-only" mode as a tool to observe what's going on but manage everything through declarative manifests stored in Git.

[@gdevelek]

OK, so when octant gives you terminal access it's horrible and unsafe, but when Rancher does the same it's "awesome"??

[@DevOpsToolkit]

That's not true. I did say that having terminal access from Octant is a good thing. I might not have shown much enthusiasm for it given that, at that time, I did not like Octant in general, but I did say that having terminal access is a good thing. Bear in mind that the video about Octant reflects how I saw it at the time. Today, it might be much better (or worse). I haven't used it since then. Also, I do not transmit marketing messages from companies. All the videos represent my personal views which might or might not coincide with how others see them.

[@javisartdesign]

Does it actually make sense to compare Rancher vs OpenShift ?

[@DevOpsToolkit]

I guess it depends whether by OpenShift you mean OpenShift or all the RH ecosystem around it. Typically, companies get Ansible to manage their infra, OpenShift as the k8s flavor, etc. If we're talking strictly OpenShift, it is closer to RKE, than Rancher.

[@chaunguyentrung8139]

Hi, I'm stucking in choosing a tool for managing multiple k8s clusters for production. Rancher seems to be a good choice for me. But I don't know if Rancher provides us a good solution for some cases as upgrading the k8s cluster version, backing up the cluster, setting up HA cluster, ... With some cases like that, do you think it's a good choice? Tks

[@DevOpsToolkit]

Is it self-managed or managed k8s (e.g., AWS EKS)?

[@chaunguyentrung8139]

@@DevOpsToolkit Hi, it's a self-managed K8s

[@DevOpsToolkit]

@@chaunguyentrung8139 In that case, Rancher is a very good choice if you prefer managing clusters through a UI. If you'd like to manage it as code, you might want to check ClusterAPI (kzbin.info/www/bejne/bqq4dYiej5uUodE) and see whether it supports underlying tech you're using.

[@chaunguyentrung8139]

@@DevOpsToolkit Thanks :D, I see Rancher it has creating features, but I'm not sure whether to use kubespary for creating and just use Rancher for managing purpose or use Rancher for everything?

[@DevOpsToolkit]

@@chaunguyentrung8139 If you're already using Rancher for managing, I'd use it for creating as well.

[@max1cp]

No nomad review on the channel? How does Rancher compare to Nomad?

[@DevOpsToolkit]

I do not think rancher and nomad are in the same category. Nomad can be compared with Kubernetes, Docker Swarm, and Mesos. I'll add Nomad to my TODO list for upcoming videos.

[@max1cp]

@@DevOpsToolkit Interesting. The reason why I was watching this video is because I thought that Rancher is basically simplifying the Kubernetes setup/installation. While docker swarm is mostly dead and nomad was another alternative.

[@DevOpsToolkit]

@@max1cp You're right. Rancher is used for managing Kubernetes clusters. Nomad, however, is not managing Kubernetes clusters. Instead, it is a replacement (alternative) for Kubernetes itself. Docker Swarm and Mesos are indeed dead. Nomad still lives but it's market share is insignificant compared to Kubernetes.

[@max1cp]

@@DevOpsToolkit I appreciate your replies. This is basically what I am interested in. I feel like my choices are Nomad or Rancher. The obvious pro of Rancher is actually using Kubernetes. But Nomad has its own upsides.

[@DevOpsToolkit]

@@max1cp Nomad does indeed have its own upsides, but is not supported by other products. There is a high chance that whichever third-party app you choose to use is supporting Kubernetes, but is not supporting Nomad. In some cases, you will be able to make it work in Nomad and will only loose a bit of time while in others it will simply not work. That is especially true for Kubernetes-native solutions like, for example Argo. Those will not work in Nomad.

[@julianomoraisbarbosa]

#til #tks

[@fenarRH]

Very cute. If you want something mature and more capable check out advanced cluster management operator (aka acm) lol . Also what happened to openstack with Suse? And how can you say similar not going to happen with k8s when something new comes in town?

[@DevOpsToolkit]

I fully agree about "what happened with X with SUSE", but the same could be said for IBM as well. The truth is that both Rancher and RedHat were purchased as an attempt for infusing their new parent companies with "fresh blood" and change their images. Neither parent company is well seen today and both purchased companies that are liked.

[@fenarRH]

@@DevOpsToolkit IBM and RH are still separate bodies for business, operation and development and hence all the customer investments done with osp, ansible, satellite and now with ocp , acm , acs (aka stackrox) are solid parts of product portfolio.

[@DevOpsToolkit]

@@fenarRH That is indeed true. They are very different. Rancher is a tiny company purchased by a company (SUSE) that is probably smaller than RHEL alone. It makes perfect sense for IBM to keep RHEL separate (for now). RHEL was a company with a lot of business before it was purchased by IBM. Rancher, on the other hand, did not have much business to talk about. In any case, you're right. Still, if I would be advocating for RHEL, I would avoid mentioning parent companies, no matter how much they are tied (or not tied) to child companies. That way, I'd avoid IBM being mentioned :) Also, the separation between RHEL and IBM will not last. IBM did not buy it with the intention to keep it as a separate business. It bought it to save itself. They will merge at some point and the question is only whether IBM will eat RHEL or RHEL will take over IBM (one bite at a time). I vote for the latter.

[@fenarRH]

@@DevOpsToolkit time will tell for sure, if you see what happened to VMW after EMC after Dell merger yet became independent again as spin off as last point.

[@corwaincyrus5]

First!

[@svsilence]

2nd chance lul truth "rancher gave money for advertisement... "

[@DevOpsToolkit]

Rancher did not give any money nor I interacted with anyone from Rancher unless you count me hearing comments from other people working with Rancher folks how they don't want my name mentioned because of my previous video. That being said, there are a few companies that did sponsor a few other videos but, even in those cases, there is a simple rule: "I will say what I will say. No company cat influence the content of the videos on this channel, no matter whether they offer money, whether I work with them, or I have friends working in those companies." Now, guess why there are not many companies willing to sponsor a channel known not to be very kind to tooling and essentially says "even if you sponsor the channel, I will still call out b*llsh*t."

[@svsilence]

@@DevOpsToolkit :D welcome to social media