前回まででdjangoアプリの色合い変更まで作ったので、その続き。
2023年6月にはkubernetesのバージョンは1.27が出てたけど、minikubeで使えるクラスタは1.26やった。
7月３週目ぐらいにbrewの更新見てたら1.27が使えるようになってた。
kubernetesの親バージョンリリースがあったら、minikubeには１ヶ月後にリリースがあるんかなぁ。
その後、2024年4月末に1.30に上げた。
brewで見てると定期的なアップデートがある
minikubeが使えるkubernetesのバージョンはコマンドラインで確認できる。
brewでkubectlやminikubeのバージョンが上がったのを見たので、もしかしてバージョンあげれるかもって使えるバージョンの確認やってみた。
nari@gvis-mac script % minikube config defaults kubernetes-version | more
* v1.27.3
* v1.27.2
* v1.27.1
* v1.27.0
* v1.27.0-rc.1
* v1.27.0-rc.0
* v1.27.0-beta.0
* v1.27.0-alpha.3
* v1.27.0-alpha.2
* v1.27.0-alpha.1
* v1.26.6
* v1.26.5
* v1.26.4
* v1.26.3
* v1.26.2
* v1.26.1
* v1.26.0
* v1.26.0-rc.1
* v1.26.0-rc.0
* v1.26.0-beta.0
* v1.26.0-alpha.3
* v1.26.0-alpha.2
* v1.26.0-alpha.1
* v1.25.11
:(中略)これ発見したときのkubectlのバージョンはこんな感じ。
先週まで1.26やったのが1.27になってるやん。
nari@gvis-mac script % kubectl version --client --output=yaml
clientVersion:
buildDate: "2023-07-19T12:14:48Z"
compiler: gc
gitCommit: fa3d7990104d7c1f16943a67f11b154b71f6a132
gitTreeState: clean
gitVersion: v1.27.4
goVersion: go1.20.6
major: "1"
minor: "27"
platform: darwin/amd64
kustomizeVersion: v5.0.1
nari@gvis-mac script % クラスタのバージョン上がるとhyperkitのdockerイメージすっからかんになる
GKEのクラスタやったら、podとかpvcを維持しながらクラスタのバージョン上げれたはず。
minikubeにminikube versionupとかはない。
どこかにpodとか維持しながらバージョン上げる方法あるのかもしれんけど、2023年には見つけられんかった。
やってみると、minikube deleteはhyperkitで動くクラスタを丸ごと吹っ飛ばす。
地味にビルドしてたとしたら、けっこう悲しいことやね。
残酷やなぁ。
自分は別のlinuxホストでdockerイメージを維持して、コンテナからときどきdocker saveして書き出して、それをdocker loadするのがええ。
このへんで維持してる。
永続化領域もきちっと維持するようにしたので、minikubeの中のクラスタバージョン上げてみた。
まずは永続化領域のバックアップ
minikubeはhyperkitのホストにある/dataのフォルダの中を維持してくれる。
それをtar.gzで固めて、親ホストのmac側にコピーしとく。
zip使ったらファイルやフォルダの所有権が崩れるからtar.gz使う。
djangoとかmariadbがあるからまずは保全する。そのままだと4GBぐらい、tar.gzすると半分の2GBぐらい。
gvis-pv-ubun22だけ維持したいから、ホンマは全部は要らんのやけどそのまま使えるんかどうかやってみる。
nari@gvis-mac script % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ ls
$
$
$ cd /data
$ ls
gvis-pv-django-sslcerts gvis-pv-mariadb1011 gvis-pv-ubun22
gvis-pv-django-uwsgi-nginx gvis-pv-mariadb1011conf
$
$ sudo du -shc *
52K gvis-pv-django-sslcerts
6.6M gvis-pv-django-uwsgi-nginx
3.9G gvis-pv-mariadb1011
1.8M gvis-pv-mariadb1011conf
212M gvis-pv-ubun22
4.1G total
$ mkdir 20230722data
mkdir: cannot create directory '20230722data': Permission denied
$ sudo mkdir 20230722data
$ sudo cp -pR ./gvis-pv* ./20230722data/
$ sudo tar czf 20230722data.tar.gz 20230722data/
$ ls -lh
total 2.1G
drwxr-xr-x 7 root root 4.0K Jul 21 22:17 20230722data
-rw-r--r-- 1 root root 2.1G Jul 21 22:20 20230722data.tar.gz
drwxr-xr-x 5 root root 4.0K Jul 18 21:41 gvis-pv-django-sslcerts
drwxrwxrwx 7 docker docker 4.0K Jul 21 21:39 gvis-pv-django-uwsgi-nginx
drwxr-xr-x 7 999 999 4.0K Jul 21 21:18 gvis-pv-mariadb1011
drwxr-xr-x 3 root root 4.0K Jul 18 21:03 gvis-pv-mariadb1011conf
drwxr-xr-x 5 root root 4.0K Jul 18 21:12 gvis-pv-ubun22
$ sudo mv 20230722data.tar.gz /minikubeMac/nariDockerDat/
$ exit
logout
nari@gvis-mac script % cd /Users/nari/Documents/personal/minikube
nari@gvis-mac minikube % ls -lh ./nariDockerDat/20230722data.tar.gz
-rw-r--r-- 1 nari staff 2.0G 7 22 07:20 ./nariDockerDat/20230722data.tar.gz
nari@gvis-mac minikube % 対象の/dataはsudoせなフォルダ作ったりtarしたりできんのね。
思い切ってminikubeのクラスタ作り直す
せっかく積み上げて作ったんやから、最初は勇気がいる。
「ホンマにpodとかpv/pvcが元に戻して使えるかなぁ」ってビビる。
「minikubeってどんなんやろ」ってやり始めて３週間、その中で作ったものが一瞬で吹っ飛ぶのは心が折れる。
これを書いているときは、macごとフルバックアップして１回バージョンアップ練習やってるから別になんともない。
クラスタを作り直すってのはhyperkitを一回消してしまうことらしいから、docker環境も吹っ飛ぶ。
dockerイメージ置き場はdocker system pruneしたらいくらか不要領域を消せるけど、よりいっそうキレイにしたいときとかにも効果があるかも。
mac側ではだいたいこんなことを実施する。
minikube stop ⭐️minikubeとめる
minikube status ⭐️とまったか確認
minikube delete ⭐️クラスタつぶす
minikube status ⭐️つぶれたか確認
minikube config view ⭐️今から作るhyperkitの設定確認
minikube start ⭐️クラスタ作る
minikube status ⭐️できたクラスタの確認やってみた。
minikubeをとめるところまで
ポートフォワードのプロセスが残ってるからか、stale pid:っていちいち表示される。
今から潰すから無視。
nari@gvis-mac script % minikube stop
❌ Multiple errors encountered:
stale pid: 6641
stale pid: 6641
stale pid: 7088
stale pid: 7088
stale pid: 7311
stale pid: 7311
stale pid: 7490
stale pid: 7490
stale pid: 2358
stale pid: 2358
stale pid: 10249
stale pid: 10249
stale pid: 11380
❗ mount プロセスを停止できません: multiple errors encountered while closing mount processes
✋ 「minikube」ノードを停止しています...
🛑 1 台のノードが停止しました。
nari@gvis-mac script % minikube status
minikube
type: Control Plane
host: Stopped
kubelet: Stopped
apiserver: Stopped
kubeconfig: Stopped
nari@gvis-mac script % クラスタつぶす
うっとうしいけどstale pid:ってまだまだ表示される。
そんなんどうでもええから無視。
クラスタはあっさり消えるし、プロファイルを抹消してくれるらしい。
nari@gvis-mac script % minikube delete
❌ Multiple errors encountered:
stale pid: 6641
stale pid: 6641
stale pid: 7088
stale pid: 7088
stale pid: 7311
stale pid: 7311
stale pid: 7490
stale pid: 7490
stale pid: 2358
stale pid: 2358
stale pid: 10249
stale pid: 10249
stale pid: 11380
stale pid: 11380
❌ マウントプロセスの強制終了に失敗しました: multiple errors encountered while closing mount processes
🔥 hyperkit の「minikube」を削除しています...
💀 クラスター「minikube」の全てのトレースを削除しました。
nari@gvis-mac script % minikube status
🤷 「minikube」プロファイルが見つかりません。全プロファイルを表示するために「minikube profile list」を実行してください。
👉 クラスターを起動するためには、「minikube start」を実行します
nari@gvis-mac script % hyperkitの設定確認とクラスタ作成
クラスタ潰しても、minikubeがhyperkitの仮想マシンを使うときの設定は吹っ飛ぶわけやないらしい。
nari@gvis-mac script % minikube config view
- cpus: 4
- disk-size: 100GB
- driver: hyperkit
- memory: 6000
nari@gvis-mac script % 最初の頃に設定した、CPU/ディスクサイズ/ドライバ/メモリの設定は残ってくれてる。
メモリ6GBとディスク100GBいるかなぁって一瞬考えたけど、余裕持たせとこ。
起動時にマウントポイントとか指定してるから、ここからは運用スクリプトに書いてる内容の一部を使う。
Podとかすっからかんの状態ができるはずやし、hypberkitの中の確認もしてみる。
nari@gvis-mac script % minikube start --mount --mount-string /Users/nari/Documents/personal/minikube/:/minikubeMac
😄 Darwin 13.4.1 上の minikube v1.31.1
▪ MINIKUBE_ACTIVE_DOCKERD=minikube
✨ ユーザーの設定に基づいて hyperkit ドライバーを使用します
👍 minikube クラスター中のコントロールプレーンの minikube ノードを起動しています
🔥 hyperkit VM (CPUs=4, Memory=6000MB, Disk=102400MB) を作成しています...
🐳 Docker 24.0.4 で Kubernetes v1.27.3 を準備しています...
▪ 証明書と鍵を作成しています...
▪ コントロールプレーンを起動しています...
▪ RBAC のルールを設定中です...
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🔎 Kubernetes コンポーネントを検証しています...
🌟 有効なアドオン: storage-provisioner, default-storageclass
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
nari@gvis-mac script % minikube status
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
docker-env: in-use
nari@gvis-mac script % すっからかんな状態ができてるはず。
hyperkitの中確認してみる。
cpuとかメモリ
topしてみた。
cpu４コアで、メモリだいたい6GBある。
使ってるメモリ26.8/5.7って左側が分母？？？
よーわからんけど、mac側のメモリも3GBぐらいしか増えてへんからよしとしましょ。
top - 23:04:52 up 8 min, 0 users, load average: 0.37, 0.30, 0.15
Tasks: 144 total, 1 running, 143 sleeping, 0 stopped, 0 zombie
%Cpu0 : 1.4/0.7 2[|| ]
%Cpu1 : 0.7/0.7 1[ ]
%Cpu2 : 0.7/1.4 2[|| ]
%Cpu3 : 0.7/0.7 1[|| ]
GiB Mem : 26.8/5.7 [ ]
GiB Swap: 0.0/0.0 [ ]
PID USER PR NI VIRT RES %CPU %MEM TIME+ S COMMAND
1 root 20 0 93.9m 9.7m 0.0 0.2 0:14.32 S /sbin/init noembed norestore base
165 root 20 0 18.1m 8.1m 0.0 0.1 0:00.29 S `- /usr/lib/systemd/systemd-journ+
188 root 20 0 11.3m 6.9m 0.0 0.1 0:00.28 S `- /usr/lib/systemd/systemd-udevd
198 systemd+ 20 0 11.0m 6.9m 0.0 0.1 0:00.20 S `- /usr/lib/systemd/systemd-netwo+
244 systemd+ 20 0 12.2m 8.8m 0.0 0.2 0:00.22 S `- /usr/lib/systemd/systemd-resol+
245 systemd+ 20 0 83.5m 6.1m 0.0 0.1 0:00.21 S `- /usr/lib/systemd/systemd-times+
256 root 20 0 2.8m 1.9m 0.0 0.0 0:00.00 S `- /usr/sbin/rpc.statd
259 root 20 0 2.3m 0.2m 0.0 0.0 0:00.00 S `- /usr/sbin/acpid --foreground -+
261 dbus 20 0 6.8m 3.7m 0.0 0.1 0:00.19 S `- /usr/bin/dbus-daemon --system +
268 root 20 0 3.6m 2.2m 0.0 0.0 0:00.00 S `- /sbin/agetty -o -p -- \u --noc+
281 root 20 0 3.6m 2.4m 0.0 0.0 0:00.01 S `- /sbin/agetty -o -p -- \u --kee+
283 root 20 0 9.9m 6.1m 0.0 0.1 0:00.24 S `- /usr/lib/systemd/systemd-logind
284 root 20 0 3.8m 2.2m 0.0 0.0 0:00.00 S `- /usr/sbin/rpcbind
289 root 20 0 2.9m 0.3m 0.0 0.0 0:00.00 S `- /usr/sbin/rpc.mountd
342 root 20 0 7.2m 5.3m 0.0 0.1 0:00.01 S `- sshd: /usr/sbin/sshd -D -e [li+
2629 root 20 0 8.0m 6.0m 0.0 0.1 0:00.00 S `- sshd: docker [priv]
2647 docker 20 0 8.2m 4.3m 0.0 0.1 0:00.00 S `- sshd: docker@notty
7767 root 20 0 8.2m 5.9m 0.0 0.1 0:00.00 S `- sshd: docker [priv]
7769 docker 20 0 8.2m 4.1m 0.0 0.1 0:00.00 S `- sshd: docker@pts/0
7770 docker 20 0 4.0m 3.5m 0.0 0.1 0:00.00 S `- -bash
7772 docker 20 0 5.8m 3.3m 0.7 0.1 0:00.04 R `- top
1177 root 20 0 737.1m 44.1m 1.3 0.8 0:05.27 S `- /usr/bin/cri-dockerd --contain+
1289 root 20 0 1976.2m 77.8m 0.0 1.3 0:05.30 S `- /usr/bin/dockerd -H tcp://0.0.+
1297 root 20 0 1548.1m 52.2m 0.0 0.9 0:00.89 S `- containerd --config /var/r+
1786 root 20 0 706.6m 11.5m 0.0 0.2 0:00.06 S `- /usr/bin/containerd-shim-runc-+
1892 65535 20 0 1.0m 0.0m 0.0 0.0 0:00.19 S `- /pause
1801 root 20 0 706.6m 12.6m 0.0 0.2 0:00.09 S `- /usr/bin/containerd-shim-runc-+
1883 65535 20 0 1.0m 0.0m 0.0 0.0 0:00.19 S `- /pause
1822 root 20 0 706.1m 11.5m 0.0 0.2 0:00.05 S `- /usr/bin/containerd-shim-runc-+
1901 65535 20 0 1.0m 0.0m 0.0 0.0 0:00.19 S `- /pause ディスク
100GiBほど確保して、OSが使う領域を差し引いで87GBあれば十分。
kubernetesのシステムがイメージとかコンテナ使ってるはずやから、1.1GB利用済みってことね。
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 5.1G 730M 4.4G 15% /
devtmpfs 2.7G 0 2.7G 0% /dev
tmpfs 2.9G 84K 2.9G 1% /dev/shm
tmpfs 1.2G 9.2M 1.2G 1% /run
tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup
tmpfs 2.9G 8.0K 2.9G 1% /tmp
/dev/vda1 87G 1.1G 81G 2% /mnt/vda1
$ dockerの状態
最初に使ったhyperkitのdockerは20が入ってたけど、24になってくれてる。
新しめのになってくれてよかった。
$ docker version
Client:
Version: 24.0.4
API version: 1.43
Go version: go1.20.5
Git commit: 3713ee1
Built: Fri Jul 7 14:49:50 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 24.0.4
API version: 1.43 (minimum version 1.12)
Go version: go1.20.5
Git commit: 4ffc614
Built: Fri Jul 7 14:51:12 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.7.2
GitCommit: 0cae528dd6cb557f7201036e9f43420650207b58
runc:
Version: 1.1.7
GitCommit: 860f061b76bb4fc671f0f9e900f7d80ff93d4eb7
docker-init:
Version: 0.19.0
GitCommit: de40ad0
$ イメージ置き場もキレイになってる。
kubernetesのdockerイメージだけが入ってる。
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.k8s.io/kube-apiserver v1.27.3 08a0c939e61b 5 weeks ago 121MB
registry.k8s.io/kube-scheduler v1.27.3 41697ceeb70b 5 weeks ago 58.4MB
registry.k8s.io/kube-proxy v1.27.3 5780543258cf 5 weeks ago 71.1MB
registry.k8s.io/kube-controller-manager v1.27.3 7cffc01dba0e 5 weeks ago 112MB
registry.k8s.io/coredns/coredns v1.10.1 ead0a4a53df8 5 months ago 53.6MB
registry.k8s.io/etcd 3.5.7-0 86b6af7dd652 5 months ago 296MB
registry.k8s.io/pause 3.9 e6f181688397 9 months ago 744kB
gcr.io/k8s-minikube/storage-provisioner v5 6e38f40d628d 2 years ago 31.5MB
$ hyperkitの中はこんなふうに作り直される
osの種類は前と一緒でBuildroot。
$ cat /etc/os-release
NAME=Buildroot
VERSION=2021.02.12-1-gf5d52c7-dirty
ID=buildroot
VERSION_ID=2021.02.12
PRETTY_NAME="Buildroot 2021.02.12"
$動いてるプロセスもあんまり変わらん。
$ pstree
systemd-+-acpid
|-2*[agetty]
|-3*[containerd-shim-+-pause]
| `-11*[{containerd-shim}]]
|-4*[containerd-shim-+-pause]
| `-10*[{containerd-shim}]]
|-containerd-shim-+-kube-scheduler---9*[{kube-scheduler}]
| `-10*[{containerd-shim}]
|-containerd-shim-+-kube-apiserver---9*[{kube-apiserver}]
| `-10*[{containerd-shim}]
|-containerd-shim-+-kube-controller---6*[{kube-controller}]
| `-11*[{containerd-shim}]
|-containerd-shim-+-etcd---10*[{etcd}]
| `-10*[{containerd-shim}]
|-containerd-shim-+-kube-proxy---6*[{kube-proxy}]
| `-10*[{containerd-shim}]
|-containerd-shim-+-coredns---8*[{coredns}]
| `-10*[{containerd-shim}]
|-containerd-shim-+-storage-provisi---5*[{storage-provisi}]
| `-10*[{containerd-shim}]
|-cri-dockerd---9*[{cri-dockerd}]
|-dbus-daemon
|-dockerd-+-containerd---11*[{containerd}]
| `-17*[{dockerd}]
|-kubelet---12*[{kubelet}]
|-rpc.mountd
|-rpc.statd
|-rpcbind
|-sshd-+-sshd---sshd
| `-sshd---sshd---bash---pstree
|-systemd-journal
|-systemd-logind
|-systemd-network
|-systemd-resolve
|-systemd-timesyn---{systemd-timesyn}
`-systemd-udevd
$ なんとなく初期状態がわかったから、次は自分の使いたいPodを入れてく。
ビルドじゃなくてlinuxホストのdockerから持ってくる
業務でGKEとかECSとか使うとき、ビルドは運用サーバでやったほうがええ。
理由はこんな感じ。
- ローカルPCにdocker/rancher/WSLとか色々入れて業務できたらラッキーやけど、大きな企業がお客さんのときは何でもインストールしてええわけやなくて制限がいっぱいある。
- そもそもプロキシあることがほとんどで、トラフィック混んでたらビルド途中でdockerhub見えんとか普通に発生するから、クラウドの中の運用サーバ使うのが確実(許可設定つけなアカンけど)。
- macでイメージ作れるようにする方法が面倒やったし、そこはkubernetes使う練習から少し外れる
※アホな話で、ビルドのタイムアウト60秒に伸ばしても、トラフィック混んでてエラーになったから、お客さんの定時過ぎてからビルドしたことあった。
運用サーバでビルドして、イメージ置き場のGAR/ECR使うから、hyperkitの中のdockerでビルドはやらん。
前に書いたこの方法で、linuxホストでビルドしたイメージをdocker save/loadする。
コマンドライン打つのが面倒なので、teratermのマクロ使ってる。
15分ほど待つだけで動き終わるし、めっちゃ楽。
scpでコピーしてきてからdockerイメージをロードしてる途中はこんな感じ。
あ、jupyterはminikubeで使わんことにしてたのに残ってる。
後で消しとこ。
nari@gvis-mac ~ % echo SCP finish
SCP finish
nari@gvis-mac ~ % min
nari@gvis-mac minikube % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ cd /minikubeMac/nariDockerDat/DockerImages/
$ gunzip save-jupyter.tar.gz
$ gunzip save-mariadb.tar.gz
$ gunzip save-xrdpubu22.tar.gz
$ gunzip save-django.tar.gz
$ docker load < ./save-jupyter.tar
d925e0fae4e6: Loading layer 129.3MB/129.3MB
d96e248f10e6: Loading layer 29.52MB/29.52MB
9c42af2c6418: Loading layer 156.6MB/156.6MB
f43725f97b9f: Loading layer 538.1MB/538.1MB
0007505dc811: Loading layer 19.05MB/19.05MB
137c4023273a: Loading layer 45.06MB/45.06MB
6e281c24915d: Loading layer 5.12kB/5.12kB
7590f3933b44: Loading layer 10.88MB/10.88MB
38f3dc367c74: Loading layer 31.74kB/31.74kBdockerイメージできてるか確認。
ちゃんとできとるなぁ。
$ docker images | grep gvis
save-django gvis-saved 48d6367dd551 12 days ago 1.19GB
save-xrdpubu22 gvis-saved f1f4f280af14 12 days ago 6.24GB
save-jupyter gvis-saved 9a2c8308335e 12 days ago 2.4GB
save-mariadb gvis-saved c3f5e6e660e5 12 days ago 518MB
$永続化領域も持ってくる
ここから手作業。
hyperkitの中で最初にtar.gzで固めた領域を展開して、pvc/pvをapplyしとく。
macからマウントした領域を使いながら、まずはtar.gzを展開する。
あ、minikube sshしてhyperkitに入ると、ホスト名はminikubeって見えるのね。
$ sudo su -
# uname -n
minikube
# cd /data
# ls -l
total 0
# cp -p /minikubeMac/nariDockerDat/20230722data.tar.gz ./
# tar xzf 20230722data.tar.gz
# ls -lh
total 2.1G
drwxr-xr-x 7 root root 4.0K Jul 21 22:17 20230722data
-rw-r--r-- 1 docker docker 2.1G Jul 21 22:20 20230722data.tar.gz
# mv 20230722data/* ./
# rmdir 20230722data
# rm 20230722data.tar.gz
# ls -l
total 20
drwxr-xr-x 5 root root 4096 Jul 18 21:41 gvis-pv-django-sslcerts
drwxrwxrwx 7 docker docker 4096 Jul 21 21:39 gvis-pv-django-uwsgi-nginx
drwxr-xr-x 7 999 999 4096 Jul 21 21:18 gvis-pv-mariadb1011
drwxr-xr-x 3 root root 4096 Jul 18 21:03 gvis-pv-mariadb1011conf
drwxr-xr-x 5 root root 4096 Jul 18 21:12 gvis-pv-ubun22
# rm -fR gvis-gv-django-sslcerts
#ここで自分が注意したのは、httpsのpodの永続化領域は復活させないこと。
理由は、オレオレの電子証明を作り直してくれるから。
あとは、djangoのソースにあるsetting.pyが、ちゃんとmariadbのpodを向いているようにするために、色合いや構成を変更するスクリプトを動かすこと。このへんで作った処理ね。
nari@gvis-mac script % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$
$ cd /minikubeMac/nariDockerDat/sv_django-uwsgi-nginx/
$ ls
20220614-oldDockerfile README.md minikubeCopy.sh requirements.txt uwsgi.ini
Dockerfile app nginx-app.conf supervisor-app.conf uwsgi_params
$ sh ./minikubeCopy.sh
$前に作ったpvc/pvを有効にする。
nari@gvis-mac minikube % cd /Users/nari/Documents/personal/minikube
nari@gvis-mac minikube % ls
README.md nariDockerDat
_old sv-django-deployment.yaml
cl-ubun22-deployment.yaml sv-django-service.yaml
gvis-PersistentVol-mariadb1011.yaml sv-https-portal-deployment.yaml
gvis-PersistentVol-mariadb1011conf.yaml sv-https-portal-service.yaml
gvis-PersistentVol-sv_django-ssl_certs.yaml sv-jupyter-deployment.yaml
gvis-PersistentVol-sv_django-uwsgi-nginx.yaml sv-jupyter-deployment.yaml.bak
gvis-PersistentVol-ubun22.yaml sv-mariadb1011-deployment.yaml
mariadb11-txt-configmap.yaml sv-mariadb1011-deployment.yaml.bak
minikube-default-networkpolicy.yaml sv-mariadb1011-service.yaml
nari@gvis-mac minikube % kubectl apply -f gvis-PersistentVol-mariadb1011.yaml
persistentvolume/gvis-pv-mariadb1011 created
persistentvolumeclaim/gvis-pv-mariadb1011-claim created
nari@gvis-mac minikube % kubectl apply -f gvis-PersistentVol-mariadb1011conf.yaml
persistentvolume/gvis-pv-mariadb1011conf created
persistentvolumeclaim/gvis-pv-mariadb1011conf-claim created
nari@gvis-mac minikube % kubectl apply -f gvis-PersistentVol-sv_django-ssl_certs.yaml
persistentvolume/gvis-pv-django-sslcerts created
persistentvolumeclaim/gvis-pv-django-sslcerts-claim created
nari@gvis-mac minikube % kubectl apply -f gvis-PersistentVol-sv_django-uwsgi-nginx.yaml
persistentvolume/gvis-pv-django-uwsgi-nginx created
persistentvolumeclaim/gvis-pv-django-uwsgi-nginx-claim created
nari@gvis-mac minikube % kubectl apply -f gvis-PersistentVol-ubun22.yaml
persistentvolume/gvis-pv-ubun22 created
persistentvolumeclaim/gvis-pv-ubun22-claim created
nari@gvis-mac minikube %それぞれのpodのserviceを有効にする。
GKEやったら、サービスに加えてLB有効にせなアカンけど、minikubeではポートフォワード使うからここまででええ。
nari@gvis-mac minikube % kubectl apply -f sv-django-service.yaml
service/sv-django created
nari@gvis-mac minikube % kubectl apply -f sv-https-portal-service.yaml
service/sv-https-portal created
nari@gvis-mac minikube % kubectl apply -f sv-mariadb1011-service.yaml
service/sv-mariadb1011 created
nari@gvis-mac minikube % mariadbが使うconfigmapも有効にする。
nari@gvis-mac minikube % kubectl apply -f mariadb11-txt-configmap.yaml
configmap/sv-mariadb11-txt created
nari@gvis-mac minikube %ここまできたら、deployment以外のリソースは定義終わり。
いったんminikube停止して、Podを起動順序つけて動かす運用スクリプト動かす。
動かすのはこんな処理でPodを全部作り直させる。
「xxx_Recreate_xxx.sh」の中で作り直しとポートフォワードやらせてる。
順番としてはDBのPod作りなおして、djangoアプリのPodを再作成してからhttpsのpodを作り直し。
djangoはDBが稼働してないとうまく動かんし、httpsは上位ポッドのdjangoが動いてないと起動でエラーが出る。
nari@gvis-mac script % cat 302_minikubeStart.sh
## -------------------------------------------------------------------------
## Script Name : 302_minikubeStart.sh
## Created by : T.Naritomi
## on : 2023.06.08
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
###LANG=C
EXEC_HOME=/Users/nari/Documents/personal/script # Execute Home directory
LOG_FILE=/Users/nari/Documents/personal/log/300_minikube.log # Log file
echo ${LOG_FILE}
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
minikube start --mount --mount-string /Users/nari/Documents/personal/minikube/:/minikubeMac >> ${LOG_FILE}
tail -25 ${LOG_FILE}
sleep 20
/bin/sh /Users/nari/Documents/personal/script/411_ReCreateDBpod.sh
/bin/sh /Users/nari/Documents/personal/script/413_ReCreateXRDPpod.sh
/bin/sh /Users/nari/Documents/personal/script/414_ReCreateDjangoPod.sh
/bin/sh /Users/nari/Documents/personal/script/415_ReCreateHTTPSpod.sh
kubectl config get-contexts
kubectl get pod -n kube-system
exit $?
nari@gvis-mac script % sh ./302_minikubeStart.sh 動かすとこうなる。minikubeがv1.31で、v1.27.3のkubernetesが動いてる。
nari@gvis-mac script % tail -f ../log/300_minikube.log
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
-------- 2023-07-22_08:48:04_ --------
✋ 「minikube」ノードを停止しています...
🛑 1 台のノードが停止しました。
-------- 2023-07-22_08:48:16 --------
😄 Darwin 13.4.1 上の minikube v1.31.1
✨ 既存のプロファイルを元に、hyperkit ドライバーを使用します
👍 minikube クラスター中のコントロールプレーンの minikube ノードを起動しています
🔄 「minikube」のために既存の hyperkit VM を再起動しています...
🐳 Docker 24.0.4 で Kubernetes v1.27.3 を準備しています...
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
🔎 Kubernetes コンポーネントを検証しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🌟 有効なアドオン: storage-provisioner, default-storageclass
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されましたminikube1.31.1で、v1.27.3のkubenetesクラスタが動き、mariadb10.11とDjango4のPodが稼働中〜。
次にPod復活の確認。minikube dashboard &ってやって、minikube addons enable metrics-serverって入れとく。
djangoのアプリが見えてる。
ポートフォワードしてるから、macだけじゃなくて他のwindowsホストからも見えてるしdjangoのバージョンも維持できてデータベース参照もできてる。
djangoのmatplotlib使ったグラフ表示やフォントの日本語表示もできてるし、データベースのレコード参照でもエラー出てない。
クラスタ潰すところから、40分ぐらい。
１から作り直すけど、バージョンアップはここまで。
クラスタ更新(minikube1.33でkubernetes1.30)
もちろんsonoma(14.4.1)でやってるのね。
nari@gvis-mac script % sw_vers
ProductName: macOS
ProductVersion: 14.4.1
BuildVersion: 23E224
nari@gvis-mac script % kubectlのバージョン確認
2024年4月末のアップデート。
brewで定期更新動かしたら３日前ぐらいにkubernetesが1.30に上がってたな。
nari@gvis-mac script % kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
nari@gvis-mac script % minikbeのバージョン確認
手動でbrew使ってバージョンアップしてたら、minikubeがバージョンアップしてた。
minikubeは1.32から1.33に上げてく。
######## update ########
==> Updating Homebrew...
Updated 1 tap (homebrew/core).
==> New Formulae
beancount-language-server descope
==> Outdated Formulae
minikube
You have 1 outdated formula installed.
You can upgrade it with brew upgrade
or list it with brew outdated.
######## upgrade ########
==> Upgrading 1 outdated package:
minikube 1.32.0 -> 1.33.0
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/manifests/1.33.0
############################################################################################# 100.0%
==> Fetching minikube
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/blobs/sha256:94a75755847ce76e9212b55232470
############################################################################################# 100.0%
==> Upgrading minikube
1.32.0 -> 1.33.0
==> Pouring minikube--1.33.0.sonoma.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
/usr/local/share/zsh/site-functions
==> Summary
🍺 /usr/local/Cellar/minikube/1.33.0: 9 files, 94.6MB
==> Running `brew cleanup minikube`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /usr/local/Cellar/minikube/1.32.0... (9 files, 90.5MB)
######## GVIS end ######## 2024-04-21_07:30:44
nari@gvis-mac script % 永続化領域(persistent volme)の保全
minikubeをバージョンアップすると「新しいの使えるで」ってメッセージ出てくるから、/dataを保全してからクラスタは潰して作り直すことにしてる。
普通にデータ領域をマウント起動して今ある永続化領域を保全やっとく。
まずはクラスタの起動。
nari@gvis-mac script % minikube start --mount --mount-string /Users/nari/Documents/personal/minikube/:/minikubeMac
😄 Darwin 14.4.1 上の minikube v1.33.0
🆕 Kubernetes 1.30.0 が利用可能です。アップグレードしたい場合、--kubernetes-version=v1.30.0 を指定してください
✨ 既存のプロファイルを元に、hyperkit ドライバーを使用します
💿 VM ブートイメージをダウンロードしています...
> minikube-v1.33.0-amd64.iso....: 65 B / 65 B [---------] 100.00% ? p/s 0s
> minikube-v1.33.0-amd64.iso: 314.16 MiB / 314.16 MiB 100.00% 37.08 MiB p
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🔄 「minikube」のために既存の hyperkit VM を再起動しています...
❗ イメージが現在の minikube バージョンでビルドされていません。minikube クラスターを削除後、最新のイメージを使用してクラスターを再作成することでこの問題を解決することができます。想定された minikube のバージョン: v1.32.0 -> 実際の minikube のバージョン: v1.33.0
🐳 Docker 24.0.7 で Kubernetes v1.28.3 を準備しています...\ Bad local forwarding specification '0:localhost:8443'
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
🔎 Kubernetes コンポーネントを検証しています...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
▪ docker.io/kubernetesui/dashboard:v2.7.0 イメージを使用しています
▪ docker.io/kubernetesui/metrics-scraper:v1.0.8 イメージを使用しています
▪ registry.k8s.io/metrics-server/metrics-server:v0.7.1 イメージを使用しています
💡 Some dashboard features require the metrics-server addon. To enable all features please run:
minikube addons enable metrics-server
🌟 有効なアドオン: storage-provisioner, default-storageclass, metrics-server, dashboard
❗ /usr/local/bin/kubectl のバージョンは 1.30.0 で、Kubernetes 1.28.3 と互換性がないかもしれません。
▪ kubectl v1.28.3 が必要ですか？ 'minikube kubectl -- get pods -A' を試してみてください
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
nari@gvis-mac script % 起動したらデータの保全ね。
4.2GB使ってる/dataの永続化領域をtar.gzにして半分ぐらい。
それをmacで/Users/nari/Documents/personal/minikube/としてhyperkitの/minikubeMacに共有してるからtar.gzを念の為逃がしとく。
nari@gvis-mac script %
nari@gvis-mac script % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ cd /data
$ ls
gvis-pv-django-sslcerts gvis-pv-mariadb1011 gvis-pv-ubun22
gvis-pv-django-uwsgi-nginx gvis-pv-mariadb1011conf
$ sudo du -shc *
52K gvis-pv-django-sslcerts
8.6M gvis-pv-django-uwsgi-nginx
3.9G gvis-pv-mariadb1011
1.8M gvis-pv-mariadb1011conf
267M gvis-pv-ubun22
4.2G total
$ sudo mkdir 20240421data
$ ls
20240421data gvis-pv-django-uwsgi-nginx gvis-pv-mariadb1011conf
gvis-pv-django-sslcerts gvis-pv-mariadb1011 gvis-pv-ubun22
$ sudo cp -pR ./gvis-pv-* ./20240421data/
$ sudo tar czf 20240421data.tar.gz 20240421data/
$ sudo mv ./20240421data.tar.gz /minikubeMac/nariDockerDat/
$ exit
logout
nari@gvis-mac script % cd /Users/nari/Documents/personal/minikube/nariDockerDat
nari@gvis-mac nariDockerDat % ls -lh ./20240421data.tar.gz
-rw-r--r-- 1 nari staff 2.1G 4 21 07:50 ./20240421data.tar.gz
nari@gvis-mac nariDockerDat % 古いkubernetesクラスタを潰して作り直す
クラスタ潰して作り直すからminikube stopしてminikube deleteしてから、念の為minikubeの設定確認ね。
nari@gvis-mac nariDockerDat % minikube config view
- disk-size: 50GB
- driver: hyperkit
- memory: 6000
- cpus: 4
nari@gvis-mac nariDockerDat % 普段のpodめっちゃゆっくり動くからcpuとメモリの数増やしたいけど、あんまり性能出えへんから今回はこのままにしとこか。
nari@gvis-mac nariDockerDat % minikube start --mount --mount-string /Users/nari/Documents/personal/minikube/:/minikubeMac
😄 Darwin 14.4.1 上の minikube v1.33.0
✨ ユーザーの設定に基づいて hyperkit ドライバーを使用します
👍 Starting "minikube" primary control-plane node in "minikube" cluster
💾 ロード済み Kubernetes v1.30.0 をダウンロードしています...
> preloaded-images-k8s-v18-v1...: 342.90 MiB / 342.90 MiB 100.00% 38.47 M
🔥 hyperkit VM (CPUs=4, Memory=6000MB, Disk=51200MB) を作成しています...
🐳 Docker 26.0.1 で Kubernetes v1.30.0 を準備しています...
▪ 証明書と鍵を作成しています...
▪ コントロールプレーンを起動しています...
▪ RBAC のルールを設定中です...
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
🔎 Kubernetes コンポーネントを検証しています...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🌟 有効なアドオン: storage-provisioner, default-storageclass
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
nari@gvis-mac nariDockerDat % 別にエラーとかも出てなさそうやね。
dockerも最近の26になってくれてるし、kubernetes1.30のイメージも入ってくれてる。
nari@gvis-mac nariDockerDat % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ docker version
Client:
Version: 26.0.1
API version: 1.45
Go version: go1.21.9
Git commit: d260a54
Built: Thu Apr 11 10:52:27 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 26.0.1
API version: 1.45 (minimum version 1.24)
Go version: go1.21.9
Git commit: 60b9add7
Built: Thu Apr 11 10:53:50 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: v1.7.15
GitCommit: 926c9586fe4a6236699318391cd44976a98e31f1
runc:
Version: 1.1.12
GitCommit: 51d5e94601ceffbbd85688df1c928ecccbfa4685
docker-init:
Version: 0.19.0
GitCommit: de40ad0
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.k8s.io/kube-apiserver v1.30.0 c42f13656d0b 3 days ago 117MB
registry.k8s.io/kube-scheduler v1.30.0 259c8277fcbb 3 days ago 62MB
registry.k8s.io/kube-controller-manager v1.30.0 c7aad43836fa 3 days ago 111MB
registry.k8s.io/kube-proxy v1.30.0 a0bf559e280c 3 days ago 84.7MB
registry.k8s.io/etcd 3.5.12-0 3861cfcd7c04 2 months ago 149MB
registry.k8s.io/coredns/coredns v1.11.1 cbb01a7bd410 8 months ago 59.8MB
registry.k8s.io/pause 3.9 e6f181688397 18 months ago 744kB
gcr.io/k8s-minikube/storage-provisioner v5 6e38f40d628d 3 years ago 31.5MB
$ 自分のPod用のイメージを持ってくる
自分のPod動きそうやからdockerイメージをlinux側から持ってきた。
dockerイメージはlinux側で固定の名前とタグ名で維持してtar.gz形式でファイルに維持してるから、それをwindows側からtera termのマクロ使って動かしてる。
teratermのscp終わったらgunzipしてロードする。
Last login: Sun Apr 21 07:30:13 2024
nari@gvis-mac ~ % rm -f /Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save*
zsh: no matches found: /Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save*
nari@gvis-mac ~ % ps -ef |grep -v grep |grep -c scp
2
nari@gvis-mac ~ %
nari@gvis-mac ~ % ps -ef |grep -v grep |grep -c scp
0
nari@gvis-mac ~ % echo SCP finish
SCP finish
nari@gvis-mac ~ % min
nari@gvis-mac minikube % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ cd /minikubeMac/nariDockerDat/DockerImages/
$ gunzip save-mariadb.tar.gz
$ gunzip save-xrdpubu22.tar.gz
$ gunzip save-django.tar.gz
$ docker load < ./save-mariadb.tar
dc0585a4b8b7: Loading layer [==================================================>] 80.35MB/80.35MB
512257c1e6ff: Loading layer
:(中略)
6e1f1f7ce830: Loading layer [==================================================>] 614.4kB/614.4kB
Loaded image: save-mariadb:gvis-saved
$ docker load < ./save-xrdpubu22.tar
5498e8c22f69: Loading layer [==================================================>] 80.41MB/80.41MB
:(中略)
f7a6e7c3fe16: Loading layer [==================================================>] 54.61MB/54.61MB
Loaded image: save-xrdpubu22:gvis-saved
$ docker load < ./save-django.tar
30e7249f6651: Loading layer [==================================================>] 84.04MB/84.04MB
:(中略)
08eb8a5b1b1a: Loading layer [==================================================>] 484.9kB/484.9kB
Loaded image: save-django:gvis-saved
$ rm -f ./save*
$バックアップした永続化領域の展開とpv/pvc/configmap/serviceの反映
さっきバックアップしといた永続化領域を新しいhyperkitのデータ置き場に入れる。
nari@gvis-mac minikube % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ sudo su -
#
# uname -n
minikube
# cd /data
# ls
# cp -p /minikubeMac/nariDockerDat/20240421data.tar.gz ./
# tar xzf 20240421data.tar.gz
# ls -lh
total 2.1G
drwxr-xr-x 7 root root 4.0K Apr 20 22:48 20240421data
-rw-r--r-- 1 docker docker 2.1G Apr 20 22:50 20240421data.tar.gz
# mv 20240421data/* ./
# rmdir 20240421data
# ls -l
total 2182764
-rw-r--r-- 1 docker docker 2235125086 Apr 20 22:50 20240421data.tar.gz
drwxr-xr-x 5 root root 4096 Mar 15 22:45 gvis-pv-django-sslcerts
drwxrwxrwx 7 docker docker 4096 Apr 15 21:37 gvis-pv-django-uwsgi-nginx
drwxr-xr-x 7 999 999 4096 Apr 19 23:05 gvis-pv-mariadb1011
drwxr-xr-x 3 root root 4096 Apr 16 22:05 gvis-pv-mariadb1011conf
drwxr-xr-x 5 docker docker 4096 Jul 18 2023 gvis-pv-ubun22
# rm -fR ./gvis-pv-django-sslcerts/*
# exit
logout
$ exit
logout
nari@gvis-mac minikube %永続化領域持ってくるだけやなく、pvとpvcのyaml定義をkubecto applyで反映させてconfigmapも入れとく。
このページで書いたkubectlのコマンドライン貼り付けてくだけやけど、地味に面倒くさい。
次やる時はスクリプト化しとこか。
entitlements.xmlって何に使うんやったか忘れた・・・。
思い出したら使うかな。
nari@gvis-mac minikube % ls
_old mariadb11-txt-configmap.yaml
cl-ubun22-deployment.yaml nariDockerDat
entitlements.xml old-minikube
gvis-PersistentVol-mariadb1011.yaml sv-django-deployment.yaml
gvis-PersistentVol-mariadb1011conf.yaml sv-django-service.yaml
gvis-PersistentVol-sv_django-ssl_certs.yaml sv-https-portal-deployment.yaml
gvis-PersistentVol-sv_django-uwsgi-nginx.yaml sv-https-portal-service.yaml
gvis-PersistentVol-ubun22.yaml sv-mariadb1011-deployment.yaml
gvis-pv-ubun22.tar.gz sv-mariadb1011-service.yaml
nari@gvis-mac minikube % 起動確認
クラスタいっかい停止してから、もう１回起動する。
nari@gvis-mac log % tail -f 300_minikube.log
-------- 2024-04-21_09:05:59 --------
😄 Darwin 14.4.1 上の minikube v1.33.0
✨ 既存のプロファイルを元に、hyperkit ドライバーを使用します
👍 Starting "minikube" primary control-plane node in "minikube" cluster
🔄 「minikube」のために既存の hyperkit VM を再起動しています...
🐳 Docker 26.0.1 で Kubernetes v1.30.0 を準備しています...
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
🔎 Kubernetes コンポーネントを検証しています...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🌟 有効なアドオン: storage-provisioner, default-storageclass
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されましたはい、できたー。
m4のmacmini出てきたらhyperkit使わなくなるから、この設定での実施は今回が最後になるんかなぁ。
2024年の秋はどうなるんやろ。
