この記事では WSL2 で動かしている minikube をアップデートする方法の一例を紹介します。なお、以下の環境を前提に解説します。
- WSL2 の OS は Fedora38
- minikube v1.29.0
目次
minikube バージョンの確認
現在の minikube バージョンとアップデート後のバージョンは minikube update-check
コマンドで確認します。
$ minikube update-check
CurrentVersion: v1.29.0
LatestVersion: v1.31.2
最新の minikube RPM パッケージを取得
minikube 公式ドキュメントを参照しながら最新の minikube RPM パッケージファイルを取得します。この作業は任意のディレクトリで作業してください。ダウンロードした RPM ファイルはインストール後に削除することが可能です。
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
最新の RPM ファイルをダウンロードしたら rpm コマンドで minikube パッケージをアップデートします。
sudo rpm -Uvh minikube-latest.x86_64.rpm
正常に更新されると以下のように minikube の RPM が最新になります。
$ sudo rpm -Uvh minikube-latest.x86_64.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing...
1:minikube-1.31.2-0 ################################# [ 50%]
Cleaning up / removing...
2:minikube-1.29.0-0 ################################# [100%]
$ minikube update-check
CurrentVersion: v1.31.2
LatestVersion: v1.31.2
$ rpm -q minikube
minikube-1.31.2-0.x86_64
$
RPM は更新できても minikube 起動時にエラーが出る
手元の環境では RPM ファイルは問題なく更新できたものの、minikube 起動時に次のようなエラーが出ました。このエラーをどのように解消したか共有したいと思います。はじめに E1002 として出ている Error downloading kic artifacts: not yet implemented, see issue #8426
は後ほど解説したいと思います。ここでは、Error: unable to start container "10a9e9588768c0c...
のエラーの方に言及します。
$ minikube start
😄 minikube v1.31.2 on Fedora 38 (amd64)
🆕 Kubernetes 1.27.4 is now available. If you would like to upgrade, specify: --kubernetes-version=v1.27.4
✨ Using the podman driver based on existing profile
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
E1002 13:59:02.418425 199 cache.go:190] Error downloading kic artifacts: not yet implemented, see issue #8426
🔄 Restarting existing podman container for "minikube" ...
🤦 StartHost failed, but will try again: driver start: start: sudo -n podman start --cgroup-manager cgroupfs minikube: exit status 125
stdout:
stderr:
Error: unable to start container "10a9e9588768c0c03dd0e32b9ca14718aa01b05ae4080667b20dcbc8453d2a4c": plugin type="bridge" failed (add): cni plugin bridge failed: failed to allocate for range 0: requested IP address 192.168.49.2 is not available in range set 192.168.49.1-192.168.49.254
🔄 Restarting existing podman container for "minikube" ...
😿 Failed to start podman container. Running "minikube delete" may fix it: driver start: start: sudo -n podman start --cgroup-manager cgroupfs minikube: exit status 125
stdout:
stderr:
time="2023-10-02T13:59:14+09:00" level=warning msg="Failed to load cached network config: network minikube not found in CNI cache, falling back to loading network minikube from disk"
time="2023-10-02T13:59:14+09:00" level=warning msg="1 error occurred:\\n\\t* plugin type=\\"bridge\\" failed (delete): cni plugin bridge failed: running [/usr/sbin/iptables -t nat -D POSTROUTING -s 192.168.49.2 -j CNI-f447c3e414def9331e92f3a5 -m comment --comment name: \\"minikube\\" id: \\"10a9e9588768c0c03dd0e32b9ca14718aa01b05ae4080667b20dcbc8453d2a4c\\" --wait]: exit status 2: iptables v1.8.9 (legacy): Couldn't load target `CNI-f447c3e414def9331e92f3a5':No such file or directory\\n\\nTry `iptables -h' or 'iptables --help' for more information.\\n\\n\\n"
Error: unable to start container "10a9e9588768c0c03dd0e32b9ca14718aa01b05ae4080667b20dcbc8453d2a4c": plugin type="bridge" failed (add): cni plugin bridge failed: failed to set bridge addr: could not set bridge's mac: invalid argument
❌ Exiting due to GUEST_PROVISION: error provisioning guest: Failed to start host: driver start
: start: sudo -n podman start --cgroup-manager cgroupfs minikube: exit status 125
stdout:
stderr:
time="2023-10-02T13:59:14+09:00" level=warning msg="Failed to load cached network config: network minikube not found in CNI cache, falling back to loading network minikube from disk"
time="2023-10-02T13:59:14+09:00" level=warning msg="1 error occurred:\\n\\t* plugin type=\\"bridge\\" failed (delete): cni plugin bridge failed: running [/usr/sbin/iptables -t nat -D POSTROUTING -s 192.168.49.2 -j CNI-f447c3e414def9331e92f3a5 -m comment --comment name: \\"minikube\\" id: \\"10a9e9588768c0c03dd0e32b9ca14718aa01b05ae4080667b20dcbc8453d2a4c\\" --wait]: exit status 2: iptables v1.8.9 (legacy): Couldn't load target `CNI-f447c3e414def9331e92f3a5':No such file or directory\\n\\nTry `iptables -h' or 'iptables --help' for more information.\\n\\n\\n"
Error: unable to start container "10a9e9588768c0c03dd0e32b9ca14718aa01b05ae4080667b20dcbc8453d2a4c": plugin type="bridge" failed (add): cni plugin bridge failed: failed to set bridge addr: could not set bridge's mac: invalid argument
╭───────────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ 😿 If the above advice does not help, please let us know: │
│ 👉 <https://github.com/kubernetes/minikube/issues/new/choose> │
│ │
│ Please run `minikube logs --file=logs.txt` and attach logs.txt to the GitHub issue. │
│ │
╰───────────────────────────────────────────────────────────────────────────────────────────╯
$
Error: unable to start container をどのように解消したか
エラーが出た時は直ぐにどうすれば良いかわかりませでしたが、エラー出力を丁寧に読むと問題解決のヒントが次のように書かれていました。
Failed to start podman container. Running "minikube delete" may fix it:
出力のとおり、minikube delete を実行すれば問題が解消する可能性があるようです。しかし、minikube delete コマンドの help を確認すると、このコマンド実行によってローカル kubernetes クラスター内の VM やその関連ファイルが全て削除されるとありました。
$ minikube delete --help | head -n 2
Deletes a local Kubernetes cluster. This command deletes the VM, and removes all
associated files.
$
結論から共有すると下記の minikube delete を実行して問題は解消したのですが、minikube delete を実行して良いか否かは各環境の状況に応じて判断してください。もし、これまで構築してきた kubernetes クラスターを削除したくない場合は、helm や IaC ツールなどを利用して任意の kubernetes クラスター上に環境を再現できるように対策を検討してください。私の環境は helm で任意の kubernetes クラスター上に Pod 環境を再現できる状況であったため、minikube delete を実行しました。これによって minikube が起動するようになりました。
$ minikube delete
🔥 Deleting "minikube" in podman ...
🔥 Deleting container "minikube" ...
🔥 Removing /home/user/.minikube/machines/minikube ...
💀 Removed all traces of the "minikube" cluster.
$
minikube は起動するようになったがまだエラー(E1002)が出る…
実は minikube をアップデートする前から minikube 起動時にいつも E1002 14:04:22.582779 1416 cache.go:190] Error downloading kic artifacts: not yet implemented, see issue #8426
のエラーが出ていたのですが、アップデートをしたついでにエラー内容を詳しくみてみました。
$ minikube start
😄 minikube v1.31.2 on Fedora 38 (amd64)
✨ Automatically selected the podman driver. Other choices: ssh, none
📌 Using Podman driver with root privileges
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
💾 Downloading Kubernetes v1.27.4 preload ...
> preloaded-images-k8s-v18-v1...: 393.21 MiB / 393.21 MiB 100.00% 14.41 M
> gcr.io/k8s-minikube/kicbase...: 447.62 MiB / 447.62 MiB 100.00% 15.91 M
E1002 14:04:22.582779 1416 cache.go:190] Error downloading kic artifacts: not yet implemented, see issue #8426
🔥 Creating podman container (CPUs=2, Memory=5400MB) ...
🐳 Preparing Kubernetes v1.27.4 on Docker 24.0.4 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔗 Configuring bridge CNI (Container Networking Interface) ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
❗ /usr/local/bin/kubectl is version 1.25.0, which may have incompatibilities with Kubernetes 1.27.4.
▪ Want kubectl v1.27.4? Try 'minikube kubectl -- get pods -A'
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
$
E1002 のエラー発生条件について該当ソースコードをみると、minikube の VM ドライバーに podman ドライバーを使っていると出るようです。このエラーについて minikube logs --file=logs.txt
で取得したログを確認してみると次のように出力されていました。
E1002 12:03:21.582779 1416 cache.go:190] Error downloading kic artifacts: not yet implemented, see issue #8426
I1002 12:03:21.582799 1416 cache.go:195] Successfully downloaded all kic artifacts
kic artifacts のダウンロードで Error となり、次の行ではダウンロードに成功しているとあります。また、ソースコードをみると waitDownloadKicBaseImage() という関数の “Successfully downloaded all kic artifacts” という出力処理まで通っていることがログとの照合でわかります。
kic (Kubernetes in Container) は名前のとおり、コンテナーで Kubernetes を動かす minikube のバックエンド機能を示しています。このケースにおいては、上記の E1002 エラーが出ても minikube 自体は問題なく使えており、 waitDownloadKicBaseImage() 関数処理も問題なく通っていることから、結果論として問題ない(このケースにおける E1002 エラーは無視できる)のではないかなと個人的に考えています。
長くなりましたが、WSL2 の minikube アップデートに関する共有事項は以上です。ここまでお読みいただきありがとうございました。