GUI apps with built-in Kubernetes

You install one app, check a box in settings, and a minute later you have a cluster. That's how desktop packages work. You pay for it with a limited choice of Kubernetes version, no multi-node in most options, and sometimes money.

Why

kind, k3d, and minikube from earlier lessons install separately from Docker and are run with commands. A desktop app brings everything at once: a container runtime, a virtual machine underneath it, and a cluster that turns on with a button. You often already have one of these installed for Docker, and the cluster in it turns out to be the shortest path.

The apps differ a lot. One supports several nodes, another doesn't. One is free for any company, another requires a subscription starting at three people. A wrong pick here is expensive: moving from one app to another means a new cluster from scratch.

Concepts

Provisioner — the mechanism an app uses to create the cluster. Docker Desktop has two: kubeadm and kind. The other apps use k3s or someone else's tools.

Context — an entry in kubeconfig that kubectl uses to reach the cluster (see the kubectl lesson). Each app adds its own context: docker-desktop, rancher-desktop, colima, kind-<name>. The name of the active context tells you whose cluster you're working in right now.

Multi-node — a cluster with more than one node. You need it to check how Pods spread across nodes and what happens when a node disappears.

Below are five options. Four of them build the cluster themselves, the fifth just draws buttons on top of other people's tools.

Docker Desktop

Version 4.94.0 from 2026-10-05. It has two different cluster creation mechanisms inside, and that's the main thing to know about it.

	kubeadm	kind
Multi-node	no	yes
Kubernetes version choice	no	yes
Creation time	~1 min	~30 s
Image storage	Docker image store	containerd only
Known incompatibility	Enhanced Container Isolation	Docker image store

Starting with version 4.65.0, new clusters default to the kind provisioner. On the kubeadm path you can't set the Kubernetes version: the last documented update there was k8s v1.36.1 in Docker Desktop 4.80.0.

The cluster doesn't upgrade along with the app. You update Docker Desktop, and the cluster stays on the old Kubernetes version. The only way to change the version on the kubeadm path is Reset cluster, meaning tear it down and recreate it. The context in kubeconfig is called docker-desktop.

Requirements differ by OS. macOS needs the current release or one of the two previous major releases and at least 4 GB RAM. Windows needs 10 version 22H2 or 11 version 23H2 and up, the Pro, Enterprise, or Education edition, 8 GB RAM, and WSL2 2.1.5 or later, or Hyper-V. Linux supports Ubuntu, Debian, RHEL, and Fedora, x86-64 only, with KVM. The virtual machine takes 50% of the host's memory by default.

Ports work fine: a Service of type LoadBalancer automatically gets EXTERNAL-IP: localhost, handled by vpnkit-controller.

Ingress, though, doesn't come out of the box. Docker Desktop ships the cloud-provider-kind image at v0.7.0 (updated in 4.90.0), and Ingress support only landed upstream in v0.9.0. On "plain" Docker Desktop you'll have to install an Ingress controller yourself.

The StorageClass on the kind path is called standard. For the kubeadm path, the class name and provisioner aren't named in the official docs, so you can't count on a specific name ahead of time.

Since version 4.90.0 there's also a cloud cluster through Docker Offload: it doesn't run on your laptop, and this lesson doesn't count it as local development.

License

Docker Subscription Service Agreement, paragraph 3.2, 2026-08-26 edition. The app is free for non-commercial open source and for a commercial organization with both fewer than 250 employees and less than $10,000,000 in annual revenue. Crossing either threshold requires a subscription. Government organizations always pay, there's no threshold for them.

Plans: Personal $0, Pro $11 a month, Team $16, Business $24.

Gotchas

Docker's own known issues say some images have no ARM64 build. The --platform linux/amd64 flag is flaky, and inotify doesn't work at all under QEMU emulation. That breaks anything that watches for file changes.

Rancher Desktop

Version 1.24.0 from 2026-07-29, a SUSE project, Apache 2.0 license. No thresholds on employees or revenue.

It runs k3s inside, and you pick the Kubernetes version from a list. The v1.24.0 tag offers 154 versions, from v1.25.3+k3s1 to v1.36.2+k3s1, with 1.36.2 marked stable. Upgrading the version keeps workloads, but downgrading removes them. This is exactly the case where "let me just try rolling back" costs you running Deployments.

winget install -e --id suse.RancherDesktop
choco install rancher-desktop
brew install --cask rancher      # not officially supported by the project

rdctl start --kubernetes-version 1.36.2
rdctl set --kubernetes-enabled=false
rdctl shutdown
rdctl reset --factory

Requirements: macOS 13 and up, Windows 11 or Server 2025, Linux x86_64 with /dev/kvm. 8 GB RAM and 4 cores recommended. The virtualization backend is WSL2 on Windows, VZ on macOS 14+, otherwise QEMU. VM defaults: 2 CPU, min(6, RAM/4) GB of memory on macOS and Linux, 2 GB on Windows.

No multi-node. The docs' own wording: "single cluster with single node setup". The workaround is running k3d on top, but those clusters are no longer managed from the GUI.

Ports are handled by k3s's ServiceLB plus automatic forwarding from the virtual machine to the host, added in version 1.9. Ports 1024 and below need administrator access.

Ingress works out of the box: Traefik is enabled and holds ports 80 and 443. You turn it off with a checkbox in Preferences → Kubernetes. The StorageClass is called local-path, and it's the default. The context in kubeconfig is called rancher-desktop.

1.24.0 ships with docker 29.6.2, docker-compose 5.3.1, helm 4.2.3, nerdctl 2.2.2, and trivy 0.72.0.

Gotchas. Auto-update was broken in 1.23.0 and 1.23.1, fixed only in 1.24.0. If you're on an older version, you'll have to update by hand. Windows 10 isn't in the list of supported systems. The rancher cask in Homebrew conflicts with docker-desktop.

OrbStack

macOS only. Version v2.2.3 from 2026-08-07, Kubernetes 1.35. You can't choose the Kubernetes version, it's tied to the app version.

The vendor doesn't state outright what's inside. An indirect clue: the Istio docs require /var/lib/rancher/k3s/… paths, which points to k3s, but you can't state this as fact.

Requirements: macOS 14.0 and up, Apple Silicon and Intel. The developers don't publish a minimum RAM, only the default memory limit is known: no more than 8 GB.

brew install --cask orbstack
orb start k8s
orb stop k8s
orb delete k8s

No multi-node, the docs themselves point you to kind or k3d for that.

Network access here is the best in this whole review. Verbatim: "All Kubernetes service types are accessible directly from Mac, so port forwarding is not needed". LoadBalancer and Ingress are served on the wildcard domain *.k8s.orb.local, NodePort opens as curl -I localhost:32042, and ClusterIP, even Pod IP, pings straight from the Mac. No kubectl port-forward, no tunnels.

That said, there's no Ingress controller in the box: "No Ingress controller is installed by default". The nice routing is there, but nothing handles Ingress objects until you install a controller yourself.

The StorageClass isn't officially documented.

License

Proprietary, and stricter than Docker Desktop's. The free plan covers only personal, non-commercial use. Pro costs $8 per user a month or $96 a year, with a 30-day trial.

By the wording of the terms of use, a freelancer, a commercial organization, a non-profit, a government organization, or anyone earning more than $10,000 a year in connection with using the product all owe payment. There's no "up to 250 employees" threshold at all here: a three-person non-profit already pays. Non-commercial educational use doesn't need a license.

Gotchas

The main one: NetworkPolicy was silently not enforced up through v2.2.3, whose changelog lists "Fixed network policies not being enforced". On 2.2.2 and below, you apply a policy, kubectl get networkpolicy shows it as created, and traffic keeps flowing anyway. For learning, this is the worst kind of bug: you study network policies and draw the wrong conclusion about how they work.

The second small thing is about locally built images. If the image has no tag, or a floating latest-style tag, Kubernetes defaults to imagePullPolicy: Always and goes to the registry every time, where that image doesn't exist. Give local images an exact tag, or set imagePullPolicy: IfNotPresent.

There are no performance measurements for the current version. The vendor's "0.1% CPU idle" and "starts in seconds" are marketing phrases with no published methodology.

colima

Version v0.10.3 from 2026-06-04, MIT license, virtualization layer is Lima. Runs on macOS 13 and up (Intel and ARM) and on Linux. The cluster runs k3s at v1.35.0+k3s1, changeable with a flag.

brew install colima
colima start --kubernetes
colima start --kubernetes --kubernetes-version v1.35.0+k3s1 --cpu 4 --memory 8
colima stop
colima delete

VM defaults: 2 CPU, 2 GiB RAM, 100 GiB disk. The VM type is vz on macOS 13+, otherwise qemu.

The --arch, --vm-type, --mount-type, and --runtime flags are locked in when the virtual machine is created. The only way to change them afterward is colima delete, meaning recreating it.

No multi-node, the FAQ points you to minikube, kind, or k3d.

Lima forwards ports automatically, NodePort is reachable as localhost:<nodePort>. A separate IP for the virtual machine turns on with the colima start --network-address flag, macOS only. A subtlety: with --network-address on, Kubernetes running, and ingress not disabled, colima deliberately stops forwarding 80 and 443, so Traefik doesn't grab those ports on the host. In that mode you have to connect to the virtual machine's IP.

Ingress is off by default: --disable=traefik is baked into the config. servicelb, though, stays on. The local-path StorageClass is present and default. The project doesn't state this directly, but you can see it in the code. The context is called colima, and colima-<name> for extra profiles.

Gotchas. The nastiest one is described in open issue #1627: colima merges its context into the first file from the $KUBECONFIG variable. If a working kubeconfig from a production cluster comes first there, colima will write into it. Keep a separate file, or check the order in $KUBECONFIG beforehand.

Then there's open bug #1452 "Rosetta x86 mmap() causes SIGSEGV", last updated 2026-08-28, meaning running x86 images through Rosetta can crash. Issue #1170, worded "OS reboot almost always breaks Colima". And #711: colima doesn't inherit the system DNS, which hurts under a VPN.

Podman Desktop

Version v1.30.4 from 2026-10-05. Runs on Windows (x64 and arm64), macOS (universal), and Linux (Flatpak and tar.gz).

winget install -e --id RedHat.Podman-Desktop
brew install --cask podman-desktop
flatpak install flathub io.podman_desktop.PodmanDesktop

Podman Desktop doesn't create a cluster of its own. It brings up a Podman machine and provides extensions that drive kind and minikube. It's a GUI on top of other people's tools, there's no separate Kubernetes implementation in it.

The workflow with kind: install the kind CLI, on Windows switch Podman to rootful mode (this is mandatory specifically on Windows), then Settings → Resources → Kind → Create new. The context shows up under the name kind-<name>.

The Podman machine gets 2 CPU and 2 GB of memory by default, for a working kind cluster give it 4 GB or more.

Who it fits: people on Windows or macOS who don't want to install Docker Desktop because of its license, and anyone who wants a GUI on top of kind.

Who fits what

App	Multi-node	Kubernetes version	Ingress out of the box	License
Docker Desktop	kind path only	selectable on the kind path, not on kubeadm	no	paid from 250 employees or $10M revenue
Rancher Desktop	no	from a list of k3s versions	Traefik enabled	Apache 2.0
OrbStack	no	tied to the app version	no	$8 a month, free for personal use only
colima	no	with the --kubernetes-version flag	Traefik disabled	MIT
Podman Desktop	same as kind	same as kind	same as kind	doesn't create its own cluster

Windows, and an organization that clears Docker's thresholds (fewer than 250 employees and less than $10M revenue): Docker Desktop, the shortest path.

Don't want to count employees and revenue at all? Take Rancher Desktop. Apache 2.0, choice of k3s version, Traefik included. The price: no multi-node, and Windows 11 at minimum.

macOS, need direct network access to Pods and Services without forwarding ports, willing to pay $8 a month, or strictly personal use: OrbStack. Check the version, NetworkPolicy doesn't work on anything below v2.2.3.

macOS or Linux, want minimalism and a command line with no GUI: colima. You'll have to turn on Ingress yourself.

Want a GUI but need a standard kind cluster: Podman Desktop.

None of the desktop options give you multi-node, except Docker Desktop's kind path and kind through Podman Desktop. For several nodes, go straight to kind, k3d, or minikube.

Common mistakes

Updated the app and expect a new Kubernetes. In Docker Desktop the cluster stays on the old version, on the kubeadm path you have to recreate it. Check the node version: kubectl get nodes.

Rolled back the k3s version in Rancher Desktop. A downgrade removes workloads. Save your manifests to files before rolling back.

Testing NetworkPolicy on old OrbStack. Before v2.2.3, policies get created but not enforced. Check orb version first, draw conclusions after.

Started colima with a working $KUBECONFIG. The colima context lands in the first file in the list. Check echo $KUBECONFIG before colima start --kubernetes.

Working in the wrong cluster. On a laptop with two apps it's easy to apply a manifest to the wrong place. Check kubectl config current-context before making changes.

Expecting Ingress out of the box. It only works right away in Rancher Desktop (Traefik). In Docker Desktop, OrbStack, and colima the controller is installed separately.

What you'll need for the tasks

• Lab 1 (optional, needs one of the apps): turn on the cluster in your app and check it against this lesson's sections using the output of kubectl config current-context, kubectl get nodes, kubectl get storageclass, kubectl get ingressclass.
• Lab 2 (no lab environment, just needs bash): pick an app to fit your team's constraints. The "Who fits what" table and each app's "License" and "Gotchas" sections will come in handy.