Introduction

When minikube behaves differently from what you expect on macOS, the first thing to verify is the driver behind the active profile. HyperKit was a common backend on Intel Macs, but minikube can also run through Docker, QEMU, or other drivers, so checking the actual profile matters more than assuming the default.

Ask Minikube Which Driver the Profile Uses

The most direct command is minikube profile list. It shows the known profiles and the driver associated with each one.

minikube profile list

On a machine using HyperKit, you should see hyperkit in the driver column for the relevant profile. This is the best starting point because it reflects minikube's own metadata rather than an inference from system processes.

If you use multiple profiles, pay attention to which one is active. It is possible for one profile to use Docker and another to use HyperKit on the same machine.

Check the Configured Default Driver

Minikube also stores a default driver setting. You can inspect it with the config command.

minikube config get driver

This tells you what driver minikube is configured to use for future starts or profile creation. It does not guarantee that an existing profile is currently using that driver. Profiles persist their own state, so the profile listing is more authoritative than the default config.

Confirm with Process Inspection

If you want an extra signal from the operating system, inspect running processes.

ps aux | grep '[h]yperkit'

If minikube is running through HyperKit, you should usually see a hyperkit process. The bracketed grep pattern avoids matching the grep command itself. Process inspection is useful, but it should remain a secondary check because stale processes or unrelated tools can make the output harder to interpret.

Inspect the Node from Minikube Itself

Another practical check is to inspect the current node or query minikube for status details.

minikube status
minikube ssh -- 'uname -a'

These commands do not directly print hyperkit, but they help confirm that the target profile is the one you think is running and that the cluster is reachable. When combined with profile list, they give you a more reliable diagnostic path than a single command alone.

Know When HyperKit Is Expected

HyperKit is mostly relevant on Intel-based Macs. On Apple Silicon systems, other drivers are often the normal choice. That means a missing HyperKit process is not automatically a problem; it may simply mean the machine is using a different supported backend.

The important question is whether the active driver matches your intended setup. If you are reading older setup notes written for Intel hardware, confirm that they still apply to the machine you are troubleshooting.

Recreate the Profile if the Driver Is Wrong

Changing the default driver does not migrate an existing profile. If the profile was created with the wrong backend, the usual fix is to recreate it with the driver you want.

minikube delete
minikube start --driver=hyperkit

Use this carefully if you have local cluster state you care about. Deleting the profile removes that state, so export or recreate anything important first.

Common Pitfalls

A common mistake is checking only minikube config get driver and assuming it reflects the current profile. That command describes the default configuration, not necessarily the backend of a previously created profile.

Another mistake is relying only on ps output. A running hyperkit process is a helpful clue, but minikube's profile metadata is usually clearer and less ambiguous.

Teams also forget that hardware matters. A guide that assumes HyperKit can be misleading on a system where another driver is the recommended or supported choice.

Summary

• Use minikube profile list as the primary way to confirm the active driver.
• Treat minikube config get driver as the default setting, not as proof about an existing profile.
• Use ps aux | grep '[h]yperkit' only as secondary confirmation.
• Check that the expected driver makes sense for the machine architecture.
• Recreate the profile if you need to move an existing cluster to HyperKit.