SUSE recently announced Rancher Desktop 1.0.0 for managing containers locally. It includes the latest K3S version (v1.23.3 at the time of writing) by default, but also provides the ability to pick and choose a version of K3S. The container runtime is containerd by default, although dockerd (moby) is provided as another option.
InfoQ caught up with Matthew Farina, software architect at SUSE, regarding Rancher Desktop 1.0.0.
He talks about the challenges of Kubernetes and container management on the desktop and how it influenced the design and evolution of the Rancher Desktop. He also adds technical details of the product and its overlaps vis-à-vis Docker Desktop.
InfoQ: What’s the background and motivation for Rancher Desktop? Can you talk about its recent evolution from 0.6, 0.7 to 1.0.0?
Matthew Farina: At SUSE, we want to make the experience simple and easy for developing and preparing applications to run in Kubernetes. When we first looked at the current landscape for running Kubernetes locally, we found two challenges. First, many different versions of Kubernetes are used in production. With the changes in each minor release of Kubernetes, the version you use matters. Second, running Kubernetes locally can take a bit of knowledge.
Those who are focused on applications often don’t have the time to learn about running local Kubernetes. Spending a lot of time to run Kubernetes takes away from time on their applications, which reduces velocity. Rob Pike, one of the creators of Go and UTF-8, once noted that “Simplicity is the art of hiding complexity.” We wanted to create a desktop app that would simplify the experience of running Kubernetes by hiding the complexity of running it and making the controls to configure Kubernetes more discoverable.
Making the controls to configure Kubernetes more discoverable is what led us to develop a graphical user interface. Discovering your options in a GUI is easier than at the command line.
Dealing with multiple versions is more complicated than just being able to locally run the same version of Kubernetes as you do in production. This is because of the way Kubernetes changes between minor releases, and therefore it’s useful to test how your applications handle Kubernetes being upgraded. I’ve personally run into challenges when a Kubernetes upgrade caused my application to become unstable or stop working. One of the aspects we built into Rancher Desktop is the ability to change version to a newer version and have it upgrade the environment while keeping your workloads. This can help you test how their applications handle Kubernetes being upgraded.
Once people started running Rancher Desktop, we learned more about their needs when preparing applications to run in Kubernetes. One of those was the need to build, run, and try out their containers without pushing them to or pulling them from a registry. To do all of this without a registry, while making them available to Kubernetes, meant the same container runtime Kubernetes is using needs to be used to build and run the containers outside of it. This led to us incorporating more tools and we ended up with nerdctl, a subproject of containerd.
While using nerdctl we learned that there were gaps between it and the Docker CLI. The nerdctl developers are doing a great job closing the gap between it and the Docker CLI but there is still a gap. To fill that gap, we provided the option to use dockerd, provided from the Moby project, along with the Docker CLI. Users now have a choice between nerdctl and the Docker CLI when using Rancher Desktop.
A second area of growth is in the platforms Rancher Desktop is available for. It all started on macOS using the Intel architecture. From there we added support for Windows, Linux, and Apple Silicon. Each of these environments has their own nuances and differences. For example, on Windows we use the Windows Subsystem for Linux. This enables Rancher Desktop to provide Kubernetes to even Windows Home users without any additional software needing to be installed.
InfoQ: The obvious next question: how does this compare to the Docker Desktop? Is Rancher Desktop meant to supplant Docker desktop?
Farina: When we started the development of Rancher Desktop, our goal wasn’t aimed at creating a candidate to supplant Docker Desktop. Instead, we focused on improving the experience of running Kubernetes locally and Docker Desktop focuses on containerizing applications. And, Docker has spent years working on Docker Desktop to make it great at containerizing applications.
As we added container features to build, push, and pull images and run containers to Rancher Desktop to support Kubernetes app developers, Rancher Desktop started to overlap with Docker Desktop in terms of capabilities.
InfoQ: As the name implies, is this tool only for the Desktop? Or, does it also help in multi-cloud Kubernetes deployment, given Rancher’s multi-cloud history?
Farina: Rancher Desktop provides local Kubernetes and container management. It’s designed to complement Rancher, which enables you to manage multiple Kubernetes clusters across any infrastructure. With Rancher Desktop you can locally develop, prepare, and test your workloads and applications that you will run in your test and production clusters. Rancher Desktop is for those who develop and prepare applications to run in Kubernetes.
InfoQ: From the GitHub repository, this tool is primarily written in typescript. Why TypeScript when many of the newer infrastructure tools are being written in Go? Can you provide some inner workings details?
Farina: From the beginning, we knew we wanted Rancher Desktop to be cross platform and have a simple and easy to use user interface. The most popular open source tool to build cross platform user interfaces is Electron which leads you to write in JavaScript or a language that transpiles to it.
JavaScript was the origin language Rancher Desktop was written in. Over time we realized we wanted some of the benefits TypeScript offered, such as type safety, and made the transition.
From Electron, subprocesses are run that include code written in other languages such as Go. These parts of the code include agents to ensure port forwarding from the virtual machine to the host works, that tools such as nerdctl on the host can communicate into the virtual machine where Kubernetes and the container runtime are running, and more. Then there are the open-source projects Rancher Desktop is built upon. These include projects like k3s and lima that are written in Go.
InfoQ: What’s the future and roadmap for Rancher Desktop? Anything else to add?
Farina: SUSE will continue with active development of Rancher Desktop and we have some exciting features in development, including user interface improvements for Kubernetes users in the future.
The top-level project provides more information on the project and the docs provide additional details, including usage of nerdctl which is the Docker-compatible CLI for containerd.