I worked with Kubernetes on Azure Kubernetes Service around 2022, but I have not used it recently. I now have an opportunity to work with Kubernetes again, this time in an on-premises environment. The suggested setup is RKE2 with Rancher, though I have not used either product before.
I would like to know whether this is a sensible, commonly used approach today, especially for a team that wants open-source tools and a convenient GUI with as few CLI commands as possible. The infrastructure may be bare metal or VMware-based, so advice for both scenarios would be helpful. I would also appreciate any guidance on what Kubernetes concepts and operational issues I should refresh before getting started.
4 Answers
Before choosing a platform, rebuild a small lab cluster and review the basics: Deployments, Services, Ingress, persistent volume claims, storage classes, network policies, Helm, and cluster upgrades. On-premises Kubernetes feels similar to a managed service, but you become responsible for the parts the cloud provider normally handles, especially storage, load balancing, certificates, and node availability.
Focus less on memorizing every custom resource and more on troubleshooting with kubectl describe, events, logs, and resource status. AI can help explain concepts, but it should not be treated as the authority on the actual state of your cluster.
Operators are not automatically dangerous, but they add another control loop and can make failures harder to understand. Use established operators, review their permissions and backup behavior, and test them in a non-production cluster first.
A GUI can be convenient, but it should not be the main reason to choose a Kubernetes distribution. Most reliable automation is done with manifests, Helm, GitOps, or the CLI, and a large management UI can introduce extra resource usage and security exposure. Rancher is reasonable if centralized access and visibility are important, but make sure the team is still comfortable with basic kubectl commands and infrastructure-as-code.
For a short refresher, use a local Kubernetes option such as Minikube or a Docker-based cluster, then move to a small RKE2 or Talos test environment that resembles the eventual deployment.
RKE2 with Rancher is a solid and fairly practical choice for on-premises Kubernetes. RKE2 provides the cluster, while Rancher adds centralized authentication, RBAC, upgrades, cluster visibility, and a web interface. It can also manage multiple clusters and support GitOps workflows through Fleet.
For a budget-conscious environment, this gives you a capable open-source stack. Just remember that Rancher does not remove the need to understand Kubernetes fundamentals, and you will still need to plan for networking, load balancers, storage, ingress, certificates, backups, and upgrades.
That sounds close to what we need. We are trying to avoid expensive licensing, so an open-source setup would be preferable.
The best option depends heavily on whether the machines are bare metal or virtual machines. For a traditional, flexible installation, kubeadm or Kubespray with an appropriate CNI is worth considering. If you want a more opinionated and immutable operating system, Talos can be excellent on bare metal or VMware, but it is primarily managed through APIs and declarative configuration rather than a normal shell or GUI. That makes it powerful, but not necessarily the closest fit for your requirement of GUI-based administration.
That is useful advice. I have had some difficult experiences with custom resources before, so I will prioritize troubleshooting and the core Kubernetes objects.