Running minikube under multipass

[afbjorklund]

Our friends at Canonical have made a "workflow" for running minikube with multipass...

It will create an Ubuntu VM for you, install Docker Engine and then run minikube on it:

$ multipass launch minikube
Launched: minikube

$ multipass exec minikube -- minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

See https://github.com/canonical/multipass-workflows/blob/main/v1/minikube.yaml

(it is using the deb installation from https://docs.docker.com/engine/install/ubuntu/)

adduser ubuntu docker
...
sudo -u ubuntu minikube start --driver=docker

[afbjorklund]

This script would probably have been easier to do, if minikube hadn't been removed from the Ubuntu app store:

• Issue The minikube version in Snap Store is out-of-date #7977

Before:

        snap:
          commands:
          - snap install minikube

After:

        packages:
        - dpkg-dev

        runcmd:
        - wget https://storage.googleapis.com/minikube/releases/latest/minikube_latest_$( dpkg-architecture -q DEB_HOST_ARCH ).deb
        - apt-get install --yes --no-install-recommends -o Debug::pkgProblemResolver=yes ./minikube_latest_$( dpkg-architecture -q DEB_HOST_ARCH ).deb

[afbjorklund]

Currently multipass uses the docker-in-docker cluster, but it would also be possible to use docker directly.

minikube start --driver=docker --container-runtime=docker

minikube start --driver=none --container-runtime=docker

It also installs kubectl from snap on the VM, instead of using the client binary from minikube kubectl.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[petiepooo]

I think there may be a simpler solution. Multipass (v1.9.0) includes hyperkit under /Library/Application Support/com.canonical.multipass/bin. I tried creating a symlink for it in /usr/local/bin, and starting minikube, but it exits with the following failure:

$ minikube start
😄 minikube v1.25.2 on Darwin 10.14.6
✨ Automatically selected the hyperkit driver

💣 Exiting due to PROVIDER_HYPERKIT_ERROR: hyperkit version check failed:
parse date: parsing time "40cbd5" as "20060102": cannot parse "d5" as "2006"

Looking at https://github.com/moby/hyperkit/tags shows that v0.20210107 is a reference commit 40cbd5. Is that just a parsing issue, or is minikube expecting a hyperkit executable more current than that?

If minikube parses the version string differently and that check passes, would that simplify the workflow and get it working again?

[petiepooo]

it has been a couple of years since a version of hyperkit that doesn't work has been released, and it looks like they have since changed the way they print version information. Would it make sense to simply revert fcbf4d1 ?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.