はじめに
nayaaaaです。
今回は、MinikubeってWSL2をノードとしてで直接動作させることって可能なんだっけ?というのとWSL2とWSLの仕様の違いを確認してきました。
そもそもなんで気になった?
Kubernetesの学習をしている際に、MinikubeをWSL2をノードとして扱って実行できるの?と思ったのがきっかけとなります。
MinikubeをWSL2上で実行する際に、--driver=docker
を指定して実行している記事が多くあるのですが、
「WSL2って仮想マシンとほぼ同じ仕様らしいし、WSL2をノードとして直接Minikubeを動作させられるはずだよなぁ」と考えてる中で、そもそもこのWSL2ってどう動作してるんだっけ?WSLと何が違うんだっけ?と気になったので調査しました。
WSLとWSL2の処理の違い
こちらにわかりやすく記事を書いている方がいました。
どうやら、WSLはLinuxカーネルへのシステムコールをLxCore.sys/Lxss.sys
というNTカーネルドライバでWindowsのシステムコールに変換して処理を行うということで、あくまでもLinuxのシステムコールをWindowのシステムコールに変換してWindowsカーネルに対して処理を要求できるようにしているらしいです。
一方でWSL2は、Hyper-Vを使用して軽量な仮想マシンを構築し、その内部でLinuxシステムコールをLinuxカーネルがそのまま処理しているようです。
MinikubeをWSL2上で実行できるか?
まず、driverの設定をnone
で指定してMinikubeをスタートしてみます。
$ sudo minikube start --driver=none
😄 minikube v1.35.0 on Ubuntu 24.04 (amd64)
▪ KUBECONFIG=/home/naya/.kube/config
✨ Using the none driver based on user configuration
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🤹 Running on localhost (CPUs=4, Memory=7946MB, Disk=1031018MB) ...
ℹ️ OS release is Ubuntu 24.04.2 LTS
🐳 Preparing Kubernetes v1.32.0 on Docker 28.0.1 ...
見ての通りなぜかDocker
が起動されています。
しかも以下のコマンドで確認してみるとRuntimeがdocker
になっています。
$ minikube profile list
|----------|-----------|---------|----------------|------|---------|--------|-------|----------------|--------------------|
| Profile | VM Driver | Runtime | IP | Port | Version | Status | Nodes | Active Profile | Active Kubecontext |
|----------|-----------|---------|----------------|------|---------|--------|-------|----------------|--------------------|
| minikube | none | docker | 172.28.250.216 | 8443 | v1.32.0 | OK | 1 | * | * |
|----------|-----------|---------|----------------|------|---------|--------|-------|----------------|--------------------|
MinikubeもDocker上で動作してるっぽい
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2b1c168cd1bd 6e38f40d628d "/storage-provisioner" 2 seconds ago Up 2 seconds k8s_storage-provisioner_storage-provisioner_kube-system_ab697b51-bbca-44cf-bc61-f3d9b5c51d7f_0
5add703ae1ed 040f9f8aac8c "/usr/local/bin/kube…" 3 seconds ago Up 2 seconds k8s_kube-proxy_kube-proxy-l6m2v_kube-system_69f4e99b-049a-434c-82e6-273cbbf2fdc3_0
95403e809c9d registry.k8s.io/pause:3.10 "/pause" 3 seconds ago Up 2 seconds k8s_POD_storage-provisioner_kube-system_ab697b51-bbca-44cf-bc61-f3d9b5c51d7f_0
f5867f353d3c registry.k8s.io/pause:3.10 "/pause" 3 seconds ago Up 3 seconds k8s_POD_kube-proxy-l6m2v_kube-system_69f4e99b-049a-434c-82e6-273cbbf2fdc3_0
b32f23c533d5 c69fa2e9cbf5 "/coredns -conf /etc…" 3 seconds ago Up 3 seconds k8s_coredns_coredns-668d6bf9bc-sqqfj_kube-system_94c57f6e-069a-4e79-a448-2b6e849e45fe_0
36c68931b33e registry.k8s.io/pause:3.10 "/pause" 3 seconds ago Up 3 seconds k8s_POD_coredns-668d6bf9bc-sqqfj_kube-system_94c57f6e-069a-4e79-a448-2b6e849e45fe_0
e37ad71f5d98 a9e7e6b294ba "etcd --advertise-cl…" 13 seconds ago Up 12 seconds k8s_etcd_etcd-desktop-sr0nd96_kube-system_77804b154eef090eba4b7d9c8eb20ab2_6
8ee497946ce5 8cab3d2a8bd0 "kube-controller-man…" 13 seconds ago Up 12 seconds k8s_kube-controller-manager_kube-controller-manager-desktop-sr0nd96_kube-system_47b67b6cc1fa09af2e78fde548d423ab_6
0a4a2f791a78 c2e17b8d0f4a "kube-apiserver --ad…" 13 seconds ago Up 12 seconds k8s_kube-apiserver_kube-apiserver-desktop-sr0nd96_kube-system_fc0066278209428349591629ed4bf2d8_6
db170af2cdb1 a389e107f4ff "kube-scheduler --au…" 13 seconds ago Up 12 seconds k8s_kube-scheduler_kube-scheduler-desktop-sr0nd96_kube-system_b12e76cd4bc2ad4d5cd8f2569fac67cd_6
ed5a02a2eff2 registry.k8s.io/pause:3.10 "/pause" 13 seconds ago Up 12 seconds k8s_POD_kube-scheduler-desktop-sr0nd96_kube-system_b12e76cd4bc2ad4d5cd8f2569fac67cd_0
50b8e00b032b registry.k8s.io/pause:3.10 "/pause" 13 seconds ago Up 12 seconds k8s_POD_kube-controller-manager-desktop-sr0nd96_kube-system_47b67b6cc1fa09af2e78fde548d423ab_0
1a6ce2e0f98c registry.k8s.io/pause:3.10 "/pause" 13 seconds ago Up 12 seconds k8s_POD_kube-apiserver-desktop-sr0nd96_kube-system_fc0066278209428349591629ed4bf2d8_0
d2cb71b8eea7 registry.k8s.io/pause:3.10 "/pause" 13 seconds ago Up 12 seconds k8s_POD_etcd-desktop-sr0nd96_kube-system_77804b154eef090eba4b7d9c8eb20ab2_0
そこで、明示的に他のコンテナランタイムを指定して実行してみます。
naya@DESKTOP-SR0ND96:~$ sudo minikube start --driver=none --container-runtime=containerd
😄 minikube v1.35.0 on Ubuntu 24.04 (amd64)
✨ Using the none driver based on user configuration
❗ Using the 'containerd' runtime with the 'none' driver is an untested configuration!
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🤹 Running on localhost (CPUs=4, Memory=7946MB, Disk=1031018MB) ...
ℹ️ OS release is Ubuntu 24.04.2 LTS
📦 Preparing Kubernetes v1.32.0 on containerd 1.7.25 ...```
すると、Kubernetesの準備中アイコンも変わったので少なくともDockerは使われていなそう。
ノードの確認をしてみる。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
desktop-sr0nd96 Ready control-plane 10m v1.32.0
Minikubeが実行されていますね~
続いてコンテナを作成できるのかnginxのコンテナを作成してみます。
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
$ docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
7cf63256a31a: Pull complete
bf9acace214a: Pull complete
513c3649bb14: Pull complete
d014f92d532d: Pull complete
9dd21ad5a4a6: Pull complete
943ea0f0c2e4: Pull complete
103f50cb3e9f: Pull complete
Digest: sha256:9d6b58feebd2dbd3c56ab5853333d627cc6e281011cfd6050fa4bcf2072c9496
Status: Downloaded newer image for nginx:latest
docker.io/library/nginx:latest
$ docker run -d nginx
395e7e77416866094b7c187e11069d0f14894dc9b4960222fdd1590160336060
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
395e7e774168 nginx "/docker-entrypoint.…" 4 seconds ago Up 4 seconds 80/tcp hungry_poincare
$ minikube stop
nginxコンテナが正常に作成できており、Minikubeもコンテナとしては作成されていないのを確認できました。
$ minikube start --driver=docker
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES 2/t
164c35e434ef gcr.io/k8s-minikube/kicbase:v0.0.46 "/usr/local/bin/entr…" 28 seconds ago Up 27 seconds 127.0.0.1:32768->22/tcp, 127.0.0.1:32769->2376/tcp, 127.0.0.1:32770->5000/tcp, 127.0.0.1:32771->8443/tcp, 127.0.0.1:32772->32443/tcp minikube
0ee127535a88 nginx "/docker-entrypoint.…" 2 minutes ago Up 2 minutes 80/tcp
jolly_rubin
よくある--driver=docker
で実行するパターンはこのようにコンテナとして実行されています。
これら2つを図にするとイメージとしては👇の感じなんですかね?
結果としてはMinikubeはWSL2上で直接動作させることができるけど、設定や必要なモジュールが多く、シンプルにコンテナ内で実行した方がよさそう。
実際に試してみた結果、Dockerコンテナ内部でMinikubeを動作させた方がお試しでKubernetesを使う分には手軽だと思います。「勉強として試してみるのはいいけど....」という感じですね〜。
まとめ
WSL2上でMinikubeを動作させるまでに、想像以上に多くのハマりポイントがあり、苦戦しました。
特に、必要なモジュールや設定が多く、手順が複雑になりがちなので、実用性はないと思うので気になったらやってみるぐらいの感覚でいいと思います。
Dockerを利用する方法のほうが簡単で安定するため、MinikubeをWSL2に直接インストールするメリットは少ないと思います。