2023年はGKEから派生して、ローカルmacの中でminikube使い始めた。
先月までのminikubeのクラスタは、hyperkitの中で独自のlinuxが動いて、dockerコンテナとしてkubernetesのコントロールプレーンが動いてた。
2024年6月ぐらいからhyperkitが非推奨になったので、脱却してqemuを使い始める。
今年の下期にm4のmacmini仕入れて使いたいから、qemuで練習始めたる。
minikubeのドライバ指定と、qemu2用のサービス指定
最初にminikubeアンインストールしてhyperkitの入ってた領域も潰した。
もう１回minikubeインストールしてqemuを仮想マシン指定して使い始める。
minikubeのサイトに指定の方法が書いてある。
qemu
QEMU driver
minikube.sigs.k8s.io
名前はqemuってあるけど、実際はqemu2をドライバに指定する。
前に一回やってみたけど深くは調べずにあきらめた。
nari@gvis-mac script % minikube config set driver qemu2 よー見たら、socket_vmnetってのを使わなアカンらしい。
え、これrootで動かさなあかんのか。
そういえば、ubuntu24をqemuでbridgeネットワーク使って動かすときには、特権いるみたいなこと書いてるところあったっけ。
ログ捨てたけど、これやっとかんとディスクのマウントがうまくいかんかったし、「トンネリングにいるで」ってある。
とりあえずbrewでインストールやっとく。
brew install socket_vmnet
brew tap homebrew/servicesせっかくスクリプト化してんのにパスワード打たなアカンのかぁ。
この時点でhyperkitのほうがええなぁ。
クラスタ作り替えのスクリプト
普段はクラスタのバージョンあげるためのスクリプトを作って用意してる。
このへんで手動でやってることをまとめた処理。
それを少しいじって、qemuでのクラスタを用意する。
処理の後半でpv/configmap/serviceの定義もやってる。
## -------------------------------------------------------------------------
## Script Name : 300_minikubeClusterRecreate.sh
## Created by : T.Naritomi
## on : 2023.08.26
## Updated by : 2024.06.23
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : change driver hyperkit -> qemu2
## -------------------------------------------------------------------------
## ---define----------------------------------------------------------------
EXEC_HOME=/Users/nari/Documents/personal/script # Execute Home directory
MINK_HOME=/Users/nari/Documents/personal/minikube # minikube Home directory
LOG_FILE=/Users/nari/Documents/personal/log/300_minikube.log # Log file
NEWEST_VER=`minikube config defaults kubernetes-version | head -1 | awk '{ print $2}'`
GVIS_CPU=4
GVIS_MEM=6000
GVIS_DSK=90GB ⭐️50GBにしてたのを、qcow2でどうなるかやってみたかったから容量増やした
GVIS_DRV=qemu2 ⭐️書き換えた
## ---detail----------------------------------------------------------------
echo '---newest version---'
echo ${NEWEST_VER}
read -p "--- minikube Data save ready ? ---(y/N):" yn
case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac
read -p "--- minikube Recreate cluster ready ? ---(y/N):" yn
case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac
echo '---Recreate start---'
rm -f ${LOG_FILE}
echo ${LOG_FILE}
minikube delete --purge --all ⭐️クラスタ完全削除
## add socket_vmnet because use qemu2
HOMEBREW=$(which brew) && sudo ${HOMEBREW} services restart socket_vmnet ⭐️sudoせなアカン残念な行、再実行することあるからrestart指定
minikube config set cpus ${GVIS_CPU}
minikube config set memory ${GVIS_MEM}
minikube config set disk-size ${GVIS_DSK}
minikube config set driver ${GVIS_DRV}
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
minikube config view >> ${LOG_FILE}
minikube delete >> ${LOG_FILE}
minikube start --kubernetes-version ${NEWEST_VER} \
--driver=${GVIS_DRV} \
--network socket_vmnet >> ${LOG_FILE}
## --mount --mount-string ${MINK_HOME}/:/minikubeMac >> ${LOG_FILE} ⭐️マウントしたらクラスタ落ちることあるからやめとく
cat ${LOG_FILE}
sleep 20 ⭐️kubernetesクラスタが安定するまでちょっと一息、こっから下のapplyしてる箇所で永続化領域作ったり他の定義も作ってもらいましょ
kubectl config get-contexts
kubectl get pod -n kube-system
kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-mariadb1011.yaml
kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-mariadb1011conf.yaml
kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-sv_django-ssl_certs.yaml
kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-sv_django-uwsgi-nginx.yaml
kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-ubun.yaml
kubectl apply -f ${MINK_HOME}/mariadb11-txt-configmap.yaml
kubectl apply -f ${MINK_HOME}/sv-django-service.yaml
kubectl apply -f ${MINK_HOME}/sv-https-portal-service.yaml
kubectl apply -f ${MINK_HOME}/sv-mariadb1011-service.yaml
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
minikube dashboard &
sleep 300 ⭐️何度かやって必要って思った
ls -lh ~/.minikube/machines/minikube ⭐️目で見て確認
## minikube cp ${MINK_HOME}/nariDockerDat/gvis-pv-ubun.tar.gz /data/ ⭐️ここでコピー処理するとクラスタ停止してまう
exit $?qemuでminikube発進
マシンを作ってる途中のファイルを確認してみる。
行ってみろやー！！！
nari@gvis-mac script % sh ./300_minikubeClusterRecreate.sh
---newest version---
v1.30.0
--- minikube Data save ready ? ---(y/N):y
--- minikube Recreate cluster ready ? ---(y/N):y
---Recreate start---
/Users/nari/Documents/personal/log/300_minikube.log
🔥 qemu2 の「minikube」を削除しています...
💀 クラスター「minikube」の全てのトレースを削除しました。
🔥 全てのプロファイルの削除に成功しました
💀 [/Users/nari/.minikube] にある minikube ディレクトリーの削除に成功しました
Password:
Stopping `socket_vmnet`... (might take a while)
==> Successfully stopped `socket_vmnet` (label: homebrew.mxcl.socket_vmnet)
Warning: Taking root:admin ownership of some socket_vmnet paths:
/usr/local/Cellar/socket_vmnet/1.1.4/bin
/usr/local/Cellar/socket_vmnet/1.1.4/bin/socket_vmnet
/usr/local/opt/socket_vmnet
/usr/local/opt/socket_vmnet/bin
This will require manual removal of these paths using `sudo rm` on
brew upgrade/reinstall/uninstall.
==> Successfully started `socket_vmnet` (label: homebrew.mxcl.socket_vmnet)
❗ これらの変更は minikube delete の後に minikube start を実行すると反映されます
❗ これらの変更は minikube delete の後に minikube start を実行すると反映されます
❗ これらの変更は minikube delete の後に minikube start を実行すると反映されます
❗ これらの変更は minikube delete の後に minikube start を実行すると反映されます
🙄 「minikube」プロファイルは存在しませんが、それでも続行します。ここまで来たら数分待たされる。
Dockerはバージョンが26なんやな。
-------- 2024-06-30_05:46:23 --------
- cpus: 4
- disk-size: 90GB
- driver: qemu2
- memory: 6000
💀 クラスター「minikube」の全てのトレースを削除しました。
😄 Darwin 14.5 上の minikube v1.33.1
✨ ユーザーの設定に基づいて qemu2 ドライバーを使用します
💿 VM ブートイメージをダウンロードしています...
👍 Starting "minikube" primary control-plane node in "minikube" cluster
💾 ロード済み Kubernetes v1.30.0 をダウンロードしています...
🔥 qemu2 VM (CPUs=4, Memory=6000MB, Disk=92160MB) を作成しています...
🐳 Docker 26.0.2 で Kubernetes v1.30.0 を準備しています...
▪ 証明書と鍵を作成しています...
▪ コントロールプレーンを起動しています...
▪ RBAC のルールを設定中です...
🔗 bridge CNI (コンテナーネットワークインターフェース) を設定中です...
📁 マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
🔎 Kubernetes コンポーネントを検証しています...
▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🌟 有効なアドオン: storage-provisioner, default-storageclass
🏄 終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* minikube minikube minikube default
NAME READY STATUS RESTARTS AGE
coredns-7db6d8ff4d-v8wfv 1/1 Running 0 9s
etcd-minikube 1/1 Running 0 23s
kube-apiserver-minikube 1/1 Running 0 23s
kube-controller-manager-minikube 1/1 Running 0 23s
kube-proxy-76fhk 1/1 Running 0 9s
kube-scheduler-minikube 1/1 Running 0 23s
storage-provisioner 1/1 Running 0 21s
persistentvolume/gvis-pv-mariadb1011 created
persistentvolumeclaim/gvis-pv-mariadb1011-claim created
persistentvolume/gvis-pv-mariadb1011conf created
persistentvolumeclaim/gvis-pv-mariadb1011conf-claim created
persistentvolume/gvis-pv-django-sslcerts created
persistentvolumeclaim/gvis-pv-django-sslcerts-claim created
persistentvolume/gvis-pv-django-uwsgi-nginx created
persistentvolumeclaim/gvis-pv-django-uwsgi-nginx-claim created
persistentvolume/gvis-pv-ubun created
persistentvolumeclaim/gvis-pv-ubun-claim created
configmap/sv-mariadb11-txt created
service/sv-django created
service/sv-https-portal created
service/sv-mariadb1011 created
🔌 ダッシュボードを有効化しています...
▪ docker.io/kubernetesui/dashboard:v2.7.0 イメージを使用しています
▪ docker.io/kubernetesui/metrics-scraper:v1.0.8 イメージを使用しています
💡 Some dashboard features require the metrics-server addon. To enable all features please run:
minikube addons enable metrics-server
🤔 ダッシュボードの状態を検証しています...
🚀 プロキシーを起動しています...
🤔 プロキシーの状態を検証しています...
🎉 デフォルトブラウザーで http://127.0.0.1:49287/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ を開いています...
total 22828280
-rw------- 1 nari staff 314M 6 30 05:46 boot2docker.iso
-rw------- 1 nari staff 3.2K 6 30 05:48 config.json
-rw-r--r-- 1 nari staff 11G 6 30 05:54 disk.qcow2
-rw-r--r-- 1 nari staff 4.5K 6 30 05:46 disk.qcow2.raw
-rw------- 1 nari staff 1.6K 6 30 05:46 id_rsa
-rw------- 1 nari staff 381B 6 30 05:46 id_rsa.pub
srwxr-x--- 1 nari staff 0B 6 30 05:46 monitor
-rw------- 1 nari staff 5B 6 30 05:46 qemu.pidダッシュボード見たらconfigmapできとる。
pvもできとる。
サービスもできてるやん。
qemuのqcow2ファイルのサイズが増えないのを必ず待つ。
nari@gvis-mac ~ % ls -l .minikube/machines/minikube
total 27153656
-rw------- 1 nari staff 329418752 6 30 06:24 boot2docker.iso
-rw------- 1 nari staff 3226 6 30 06:26 config.json
-rw-r--r-- 1 nari staff 13566738432 6 30 06:32 disk.qcow2
-rw-r--r-- 1 nari staff 4608 6 30 06:24 disk.qcow2.raw
-rw------- 1 nari staff 1679 6 30 06:24 id_rsa
-rw------- 1 nari staff 381 6 30 06:24 id_rsa.pub
srwxr-x--- 1 nari staff 0 6 30 06:24 monitor
-rw------- 1 nari staff 5 6 30 06:24 qemu.pid
nari@gvis-mac ~ %
nari@gvis-mac ~ %
nari@gvis-mac ~ % ls -l .minikube/machines/minikube
total 27645176
-rw------- 1 nari staff 329418752 6 30 06:24 boot2docker.iso
-rw------- 1 nari staff 3226 6 30 06:26 config.json
-rw-r--r-- 1 nari staff 13810073600 6 30 06:32 disk.qcow2 ⭐️まだサイズ増えとる
-rw-r--r-- 1 nari staff 4608 6 30 06:24 disk.qcow2.raw
-rw------- 1 nari staff 1679 6 30 06:24 id_rsa
-rw------- 1 nari staff 381 6 30 06:24 id_rsa.pub
srwxr-x--- 1 nari staff 0 6 30 06:24 monitor
-rw------- 1 nari staff 5 6 30 06:24 qemu.pid
nari@gvis-mac ~ %
nari@gvis-mac ~ %
nari@gvis-mac ~ % ls -l .minikube/machines/minikube
total 27645176
-rw------- 1 nari staff 329418752 6 30 06:24 boot2docker.iso
-rw------- 1 nari staff 3226 6 30 06:26 config.json
-rw-r--r-- 1 nari staff 13810073600 6 30 06:32 disk.qcow2 ⭐️サイズ増えるの止まった
-rw-r--r-- 1 nari staff 4608 6 30 06:24 disk.qcow2.raw
-rw------- 1 nari staff 1679 6 30 06:24 id_rsa
-rw------- 1 nari staff 381 6 30 06:24 id_rsa.pub
srwxr-x--- 1 nari staff 0 6 30 06:24 monitor
-rw------- 1 nari staff 5 6 30 06:24 qemu.pid
nari@gvis-mac ~ % qemuの仮想マシンが入ったフォルダ
qemuの仮想マシンは、クラスタ作り直すとフォルダごと再作成される。
クラスタ稼働したてのqemuのqcow2ファイルはこんな状態。
まだkubernetesの本体入っただけやのにもう13GB使ってるな。
nari@gvis-mac script % ls -lh ~/.minikube/machines/minikube
total 27710712
-rw------- 1 nari staff 314M 6 26 01:50 boot2docker.iso
-rw------- 1 nari staff 3.2K 6 26 01:52 config.json
-rw-r--r-- 1 nari staff 13G 6 26 02:02 disk.qcow2
-rw-r--r-- 1 nari staff 4.5K 6 26 01:50 disk.qcow2.raw
-rw------- 1 nari staff 1.6K 6 26 01:50 id_rsa
-rw------- 1 nari staff 381B 6 26 01:50 id_rsa.pub
srwxr-x--- 1 nari staff 0B 6 26 01:50 monitor
-rw------- 1 nari staff 5B 6 26 01:50 qemu.pid
nari@gvis-mac script % クラスタをdocker起動させて使うためのisoファイルもそこにあるんやね。
何度かクラスタ作り直してる間に気づいたんやけど、このqcow2のファイルは、クラスタ作った直後4GBぐらいに見えてることがある。
その後５分ぐらいかけて太っていって、13GBになる。
これを待たずにdockerイメージやら永続化領域のデータ流し込みすると、ほぼ100%クラスタ止まるから注意。
めっちゃ残念やけど、mountオプションつけた状態やとqcow2ファイルが育つのを待ってもクラスタ止まる。
もしクラスタ停止発生しても、podは起動せずにクラスタだけ起動して、１つずつpod起動して確認してったらええ。
プロセスはこんな感じで呼ばれて動いてた。
nari@gvis-mac ~ % ps -efww | grep qemu
501 3355 1 0 1:50AM ?? 9:38.40 qemu-system-x86_64 -cpu max -display none -accel hvf -m 6000 -smp 4 -boot d -cdrom /Users/nari/.minikube/machines/minikube/boot2docker.iso -qmp unix:/Users/nari/.minikube/machines/minikube/monitor,server,nowait -pidfile /Users/nari/.minikube/machines/minikube/qemu.pid -device virtio-net-pci,netdev=net0,mac=06:7c:4a:f6:90:4a -netdev socket,id=net0,fd=3 -daemonize /Users/nari/.minikube/machines/minikube/disk.qcow2
501 3628 3397 0 2:04AM ttys001 0:00.00 grep qemu
nari@gvis-mac ~ % psするとき--efwwってやったら動いてるプロセスの引数見える。
linuxでもmacでもおんなじ。
なるほど、練習でunbuntu24の仮想マシン作ったときにオプションわかりにくかったけど、コア数の指定とかそんな感じで書くんや。
マウントしたデータ領域見えてるか確認できたら、いったん正常終了や。
nari@gvis-mac ~ % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ sudo su -
# uname -n
minikube
# df -h | grep -v var
Filesystem Size Used Avail Use% Mounted on
tmpfs 5.1G 804M 4.3G 16% /
devtmpfs 2.7G 0 2.7G 0% /dev
tmpfs 2.9G 84K 2.9G 1% /dev/shm
tmpfs 1.2G 9.6M 1.2G 1% /run
tmpfs 2.9G 8.0K 2.9G 1% /tmp
/dev/sda1 79G 1.2G 73G 2% /mnt/sda1
# ls /minikubeMac/
_old mariadb11-txt-configmap.yaml
cl-ubun-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-ubun.yaml sv-mariadb1011-deployment.yaml
gvis-pv-ubun22.tar.gz sv-mariadb1011-service.yaml
# ls /minikubeMac/nariDockerDat/
DockerImages _old cl_ubun22 cl_ubun24 sv_django-uwsgi-nginx sv_mariadb11conf
# macで共有した/minikubeMacの中見えててOK。
後でちょっとハマる。
永続化領域にデータ入れてく
hyperkitのときと同じで、qemuでも/dataってフォルダが使える。
永続化領域にxrdpコンテナのデータ流し込む。
nari@gvis-mac ~ % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$
$
$ ls -l /data
total 4
drwx------ 4 root root 4096 Jun 22 22:52 cl_ubun24
$ sudo su -
# cp -pR /minikubeMac/nariDockerDat/cl_ubun24 /data/gvis-pv-ubun
# ここで、いったん作業区切って翌日に作業しようとしたらクラスタが止まってしもた。
🤷 The control-plane node minikube host is not running: state=Stoppedなんやねん、気合いが足らんのとちゃうか。
コピー対象は200MBぐらいで、うまく行くこともあったけど、ヘバりよる。
５回に１回ぐらい止まることがあった。
dockerイメージ持ってくる – qemuで共有領域のコピーしたらクラスタ落ちるからmountオプションやめ
ローカルlinuxの母艦はubuntu24に最近切り替えた。
xrdpのdockerイメージも24に切り替えた。
teratermのスクリプト動かして20分ぐらい放置したら終わる。
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-xrdpubu24.tar.gz
$ gunzip save-django.tar.gz
$ docker load < ./save-mariadb.tar
0b9c994b0484: Loading layer [==================================================>] 80.41MB/80.41MB
b3ce81adf04d: Loading layer [==================================================>] 338.4kB/338.4kB
b136ad05b25b: Loading layer [==================================================>] 16.23MB/16.23MB
:(中略)
c162393e0f1b: Loading layer [==================================================>] 135.2kB/135.2kB
Loaded image: save-mariadb:gvis-saved
$ docker load < ./save-xrdpubu24.tar
42d3f8788282: Loading layer [==================================================>] 78.74MB/78.74MB
6e0145864048: Loading layer [==================================================>] 36.52MB/36.52MB
c0765b327fee: Loading layer [==================================================>] 3.009MB/3.009MB
:(中略)
638fcaaae50a: Loading layer [==================================================>] 822.4MB/822.4MB
Loaded image: save-xrdpubu24:gvis-saved
$ docker load < ./save-django.tar
30e7249f6651: Loading layer [==================================================>] 84.04MB/84.04MB
0e5209a3d7d4: Loading layer [==================================================>] 3.407MB/3.407MB
:(中略)
eca5e7d1d600: Loading layer [==================================================>] 9.416MB/9.416MB
75a528010e53: Loading layer [==================================================>] 391.2kB/391.2kB
Loaded image: save-django:gvis-saved
$ rm -f ./save*
$
$ docker images | grep saved
save-django gvis-saved 8228570f4105 About an hour ago 1.04GB
save-mariadb gvis-saved 026ce2341281 About an hour ago 401MB
save-xrdpubu24 gvis-saved 32163d594004 2 weeks ago 5.14GB
$ここまでたどり着くのにminikube sshしたときと同じエラーメッセージが５回ほど出て、６回目でやっとイメージ保存できた。
ただし、コピーうまいこと行ってへんみたいで、dokcer loadしたイメージをpod稼働させたら、意味不明の起動エラーでクラッシュしよる。
なんやねんqemu、ちゃんとコピーせえよ。
ディスクの読み書きで負荷かけたらこのメッセージ出るんかなぁ。
🤷 The control-plane node minikube host is not running: state=Stoppedこんな高確率でクラスタ落ちるんやったら、コンテナに共有してるmacのフォルダ使い方考え直して、別のやり方に変える。
docker cpと同じ感じのminikube cpでどやさ
コンテナに共有してるmacのフォルダをコンテナで処理してクラスタ落ちるから、コンテナの中に寄せて処理するようにしたらええ。
qemuのqcow2はデカくなってまうけど、コンテナの中の/dataを処理させたらクラスタ落ちたりせんのとちゃうか。
あんまり使ったことないけど、docker cpってあったよな。
minikubeやったらminikube cpってのがあるみたい。
minikubeのページ確認してみた。
cp
Copy the specified file into minikube
minikube.sigs.k8s.io
え！？ ファイルしかコピーできんかったっけ？
フォルダごとはアカンのかいな？
面倒くさいなぁ。
teratermマクロ使ってdockerイメージを流し込む処理を更新した。
コピーのやり方変える
前は１つのteratermマクロでscp転送してhyperkitから見えるmacの共有領域に置いたdockerイメージをgunzip/docker loadするよう書いてた。
クラスタが止まってまうのはこのへん。
wait "%"
sendln 'minikube ssh'
wait "$"
sendln 'cd /minikubeMac/nariDockerDat/DockerImages/'
wait "$"
sendln 'gunzip save-mariadb.tar.gz'
wait "$"
sendln 'gunzip save-xrdpubu24.tar.gz'
wait "$"
sendln 'gunzip save-django.tar.gz'
wait "$"
sendln 'docker load < ./save-mariadb.tar' ⭐️ここでクラスタ落ちることあるねん
wait "$"
sendln 'docker load < ./save-xrdpubu24.tar' ⭐️ここでクラスタ落ちることあるねん
wait "$"
sendln 'docker load < ./save-django.tar' ⭐️ここでクラスタ落ちることあるねん書き換えた後はteratermマクロを3分割して確認しながら動かした。
- scpしてgunzipする
- macでqemuの永続化領域に
minikube cpする - minikubeの中で
docker load
１つ目は前と同じやし割愛。
２つ目はmacからコピーさせる。
wait "%"
sendln 'cd /Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages'
wait "%"
sendln 'minikube cp ./save-mariadb.tar /data/ ' ⭐️３０秒ぐらいかかる
wait "%"
sendln 'minikube cp ./save-xrdpubu24.tar /data/ ' ⭐️５分ぐらいかかる
wait "%"
sendln 'minikube cp ./save-django.tar /data/ ' ⭐️１分ぐらいかかる３つ目はこうなった。
めっちゃゆっくり動くけど、クラスタの中の永続化領域からのディスクI/Oは遅い。
wait "%"
sendln 'minikube ssh'
wait "$"
sendln 'cd /data '
wait "$"
sendln 'docker load < ./save-mariadb.tar ; sync ' ⭐️クラスタ落ちへん
wait "$"
sendln 'docker load < ./save-xrdpubu24.tar ; sync ' ⭐️クラスタ落ちへん
wait "$"
sendln 'docker load < ./save-django.tar ; sync ' ⭐️クラスタ落ちへん５回処理してみて、いっぺんもクラスタ落ちへんようになった。
nari@gvis-mac ~ % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
save-django gvis-saved 8228570f4105 2 days ago 1.04GB ⭐️入っとる！
save-mariadb gvis-saved 026ce2341281 2 days ago 401MB ⭐️入っとる！
save-xrdpubu24 gvis-saved 32163d594004 2 weeks ago 5.14GB ⭐️入っとる！
registry.k8s.io/kube-apiserver v1.30.0 c42f13656d0b 2 months ago 117MB
registry.k8s.io/kube-scheduler v1.30.0 259c8277fcbb 2 months ago 62MB
registry.k8s.io/kube-controller-manager v1.30.0 c7aad43836fa 2 months ago 111MB
registry.k8s.io/kube-proxy v1.30.0 a0bf559e280c 2 months ago 84.7MB
registry.k8s.io/etcd 3.5.12-0 3861cfcd7c04 4 months ago 149MB
registry.k8s.io/coredns/coredns v1.11.1 cbb01a7bd410 10 months ago 59.8MB
registry.k8s.io/pause 3.9 e6f181688397 20 months ago 744kB
kubernetesui/dashboard <none> 07655ddf2eeb 21 months ago 246MB
kubernetesui/metrics-scraper <none> 115053965e86 2 years ago 43.8MB
gcr.io/k8s-minikube/storage-provisioner v5 6e38f40d628d 3 years ago 31.5MB
$mariadbのリストアで使うsqlもminikube cp使う
このへんでやってる処理も更新。
設定ファイルのgvis.confと、データベース領域２つ分のリカバリスクリプト・ダンプ結果の合計５つをコピーさせるように変更した。
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/gvis.cnf /data/gvis-pv-mariadb1011conf/ '
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/fullback/2_fullRecover.sh /data/gvis-pv-mariadb1011conf/nari/fullback/ '
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/fullback/4_nariDB_DjangoRecover.sh /data/gvis-pv-mariadb1011conf/nari/fullback/ '
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_1st.sql /data/gvis-pv-mariadb1011conf/nari/ '
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_Django.sql /data/gvis-pv-mariadb1011conf/nari/ 'teratermのマクロ動かしたらこうなる。
nari@gvis-mac ~ % sc
nari@gvis-mac script % min
nari@gvis-mac minikube % kubectl delete -f sv-mariadb1011-deployment.yaml ⭐️まだpod動いてへんからエラーになってOK
Error from server (NotFound): error when deleting "sv-mariadb1011-deployment.yaml": deployments.apps "sv-mariadb1011" not found
nari@gvis-mac minikube % kubectl delete -f gvis-PersistentVol-mariadb1011conf.yaml
persistentvolume "gvis-pv-mariadb1011conf" deleted
persistentvolumeclaim "gvis-pv-mariadb1011conf-claim" deleted
nari@gvis-mac minikube % kubectl delete -f gvis-PersistentVol-mariadb1011.yaml
persistentvolume "gvis-pv-mariadb1011" deleted
persistentvolumeclaim "gvis-pv-mariadb1011-claim" deleted
nari@gvis-mac minikube % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ sudo su -
# cd /data
# rm -fR ./gvis-pv-mariadb1011 ; rm -fR ./gvis-pv-mariadb1011conf ; sync ; sync
# mkdir gvis-pv-mariadb1011conf ; mkdir gvis-pv-mariadb1011conf/nari ; mkdir gvis-pv-mariadb1011conf/nari/fullback ; mkdir gvis-pv-mariadb1011
# exit
logout
$ exit
logout
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/gvis.cnf /data/gvis-pv-mariadb1011conf/
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/fullback/2_fullRecover.sh /data/gvis-pv-mariadb1011conf/nari/fullback/
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/fullback/4_nariDB_DjangoRecover.sh /data/gvis-pv-mariadb1011conf/nari/fullback/
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_1st.sql /data/gvis-pv-mariadb1011conf/nari/
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_Django.sql /data/gvis-pv-mariadb1011conf/nari/
nari@gvis-mac minikube % kubectl create -f gvis-PersistentVol-mariadb1011conf.yaml
persistentvolume/gvis-pv-mariadb1011conf created
persistentvolumeclaim/gvis-pv-mariadb1011conf-claim created
nari@gvis-mac minikube % kubectl create -f gvis-PersistentVol-mariadb1011.yaml
persistentvolume/gvis-pv-mariadb1011 created
persistentvolumeclaim/gvis-pv-mariadb1011-claim created
nari@gvis-mac minikube % kubectl create -f sv-mariadb1011-deployment.yaml
deployment.apps/sv-mariadb1011 created
nari@gvis-mac minikube % sync ; sleep 10 ; sync
nari@gvis-mac minikube % kubectl exec -it `kubectl get pod | grep mariadb | awk '{print $1}'` -- bash ⭐️podにログインさせる
root@svmariadb1011:/# sync ; sleep 10 ; sync
root@svmariadb1011:/# /bin/sh /etc/mysql/conf.d/nari/fullback/2_fullRecover.sh ⭐️本番DBのリストア
root@svmariadb1011:/# /bin/sh /etc/mysql/conf.d/nari/fullback/4_nariDB_DjangoRecover.sh ⭐️テストDBのリストア
root@svmariadb1011:/# mysql -unari -pXXXXXXXXXX
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 5
Server version: 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log mariadb.org binary distribution
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show variables like 'max_allowed_packet' ;
+--------------------+------------+
| Variable_name | Value |
+--------------------+------------+
| max_allowed_packet | 1073741824 | ⭐️minikube cpした内容が反映できとる！
+--------------------+------------+
1 row in set (0.002 sec)
MariaDB [(none)]> show databases ;
+--------------------+
| Database |
+--------------------+
| information_schema |
| nariDB_1st | ⭐️本番DBある！
| nariDB_Django | ⭐️テストDBある！
+--------------------+
3 rows in set (0.000 sec)
MariaDB [(none)]> use nariDB_1st ;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
select count(*) from GVIS_keihi ;
exit
Database changed
MariaDB [nariDB_1st]> select count(*) from GVIS_keihi ;
+----------+
| count(*) |
+----------+
| 11197 | ⭐️業務データ入っとる！
+----------+
1 row in set (0.003 sec)
MariaDB [nariDB_1st]> exit
Bye
root@svmariadb1011:/# rm /etc/mysql/conf.d/nari/FullBackup_nariDB_1st.sql ⭐️リストアのダンプファイル不要やし消す
root@svmariadb1011:/# rm /etc/mysql/conf.d/nari/FullBackup_nariDB_Django.sql ⭐️リストアのダンプファイル不要やし消す
root@svmariadb1011:/# exit
exit
nari@gvis-mac minikube % sc
nari@gvis-mac script % sh ./411_ReCreateDBpod.sh ⭐️podを再作成する！
NAME READY STATUS RESTARTS AGE
sv-mariadb1011-55685c8874-dkg45 1/1 Running 0 106s
Warning: resource deployments/sv-mariadb1011 is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
deployment.apps/sv-mariadb1011 configured
NAME READY STATUS RESTARTS AGE
sv-mariadb1011-55685c8874-dkg45 1/1 Running 0 118s
nari@gvis-mac script % rm -f /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_1st.sql
nari@gvis-mac script % rm -f /Users/nari/Documents/personal/minikube/nariDockerDat/sv_mariadb11conf/nari/FullBackup_nariDB_Django.sql
nari@gvis-mac script % Forwarding from 0.0.0.0:13306 -> 3306あとはa5sqlでデータ確認してOK。
アプリケーション(django)も流し込む
mariadbほどサイズ大きくないからteratermマクロ実行はすぐ終わる。
wait "nari@gvis-mac"
sendln 'minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_django-uwsgi-nginx.tar.gz /data/ '動かすとこうなる。
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 ~ % cd /Users/nari/Documents/personal/minikube/nariDockerDat
nari@gvis-mac nariDockerDat % rm -fR ./sv_django-uwsgi-nginx
tar xzf sv_django-uwsgi-nginx.tar.gz
nari@gvis-mac nariDockerDat % tar xzf sv_django-uwsgi-nginx.tar.gz
min
nari@gvis-mac nariDockerDat % min
nari@gvis-mac minikube % kubectl delete -f sv-django-deployment.yaml ⭐️まだpod動いてへんからエラーになってOK
kubectl delete -f gvis-PersistentVol-sv_django-uwsgi-nginx.yaml
Error from server (NotFound): error when deleting "sv-django-deployment.yaml": deployments.apps "sv-django" not found
nari@gvis-mac minikube % kubectl delete -f gvis-PersistentVol-sv_django-uwsgi-nginx.yaml
minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_django-uwsgi-nginx.tar.gz /data/
persistentvolume "gvis-pv-django-uwsgi-nginx" deleted
persistentvolumeclaim "gvis-pv-django-uwsgi-nginx-claim" deleted
nari@gvis-mac minikube % minikube cp /Users/nari/Documents/personal/minikube/nariDockerDat/sv_django-uwsgi-nginx.tar.gz /data/
minikube ssh
nari@gvis-mac minikube % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ sudo su -
# cd /data
# rm -fR ./gvis-pv-django-uwsgi-nginx ; sync ; sync
# tar xzf sv_django-uwsgi-nginx.tar.gz
# mv ./sv_django-uwsgi-nginx/app ./gvis-pv-django-uwsgi-nginx
# rm -fR ./sv_django-uwsgi-nginx
# /bin/sh /minikubeMac/nariDockerDat/sv_django-uwsgi-nginx/minikubeCopy.sh ⭐️minikube用のcssコピーできててOK
# exit
logout
$ exit
logout
nari@gvis-mac minikube % min
nari@gvis-mac minikube % kubectl create -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 create -f sv-django-deployment.yaml
deployment.apps/sv-django created
nari@gvis-mac minikube % sleep 10
nari@gvis-mac minikube % kubectl exec -it `kubectl get pod | grep sv-django | awk '{print $1}'` -- bash
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@sv-django:/# pip3 list -o
Package Version Latest Type
------------------ ------- ------ -----
importlib_metadata 7.1.0 8.0.0 wheel
numpy 1.26.4 2.0.0 wheel
packaging 24.0 24.1 wheel
pip 24.0 24.1 wheel
setuptools 70.0.0 70.1.1 wheel
typing_extensions 4.12.1 4.12.2 wheel
[notice] A new release of pip is available: 24.0 -> 24.1
[notice] To update, run: pip install --upgrade pip
root@sv-django:/# exit
exit
nari@gvis-mac minikube % rm -f /Users/nari/Documents/personal/minikube/nariDockerDat/sv_django-uwsgi-nginx.tar.gz
nari@gvis-mac minikube %ありゃ、pip3の更新あるやん。
あとで母艦のアップデートしとこ。
qemuでminikube使える確認
kubernetesっていちいちコマンドライン長いから運用スクリプト用意して使ってる。
このへんの処理使ってpodを全停止・全起動。
稼働状態確認してみる。
nari@gvis-mac script % onlchk
-------minikube status -------
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
-------minikube check -------
CurrentVersion: v1.33.1
LatestVersion: v1.33.1
---- kubernetes verCheck -----
* v1.30.0
* v1.30.0-rc.2
* v1.30.0-rc.1
-------kubectl version -------
clientVersion:
gitVersion: v1.30.2
serverVersion:
gitVersion: v1.30.0
----kubectl po/svc status ----
NAME READY STATUS RESTARTS AGE
pod/cl-ubun-5f56c7544f-l9649 1/1 Running 0 6m52s
pod/sv-django-5fcb4bf44f-rq7zr 1/1 Running 0 6m41s
pod/sv-https-portal-74b6b984c8-mpd8s 1/1 Running 0 6m26s
pod/sv-mariadb1011-55685c8874-jspmp 1/1 Running 0 7m3s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 137m
service/sv-django ClusterIP 10.98.34.171 <none> 38080/TCP 137m
service/sv-https-portal ClusterIP 10.98.112.58 <none> 30080/TCP,30443/TCP 137m
service/sv-mariadb1011 ClusterIP 10.99.137.64 <none> 13306/TCP 137m
-------kubectl PV -------
NAME CAPACITY ACCESS RECLAIM
gvis-pv-django-sslcerts 1Gi RWO Bound
gvis-pv-django-uwsgi-nginx 1Gi RWO Bound
gvis-pv-mariadb1011 20Gi RWO Bound
gvis-pv-mariadb1011conf 5Gi RWO Bound
gvis-pv-ubun 10Gi RWO Bound
-------kubectl forward -------
port-forward --address 0.0.0.0 sv-mariadb1011-55685c8874-jspmp 13306:3306
port-forward --address 0.0.0.0 cl-ubun-5f56c7544f-l9649 33389:3389
port-forward --address 0.0.0.0 sv-django-5fcb4bf44f-rq7zr 38080:8080
port-forward --address 0.0.0.0 sv-https-portal-74b6b984c8-mpd8s 30443:443
nari@gvis-mac script % kubernetesクラスタが1.30でちゃんとpod稼働できてるやん。
ええ感じ。
xrdp動いてるkubernetesのpodに接続してみる。
mariadbのpodにあるデータベース読みながら、djangoのwebアプリから見えててOKなんやけど、めっちゃ動きが重い。
speedtestで下り169Mbpsってなんやねん。
qemuは共有領域の読み書きイマイチな上、ブリッジ接続のI/Oもアカンっぽいけど、m4-macminiに引っ越したら改善されること祈る。
ここまででhyperkitから脱却はできたな。
年末にmacminiの新版出たら引っ越して同じことやってみっか。
容量どんな感じ？
minikubeの仮想マシン内は19GB強使ってるように見える。
nari@gvis-mac ~ % minikube ssh
_ _
_ _ ( ) ( )
___ ___ (_) ___ (_)| |/') _ _ | |_ __
/' _ ` _ `\| |/' _ `\| || , < ( ) ( )| '_`\ /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )( ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)
$ df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 5.1G 804M 4.3G 16% /
devtmpfs 2.7G 0 2.7G 0% /dev
tmpfs 2.9G 84K 2.9G 1% /dev/shm
tmpfs 1.2G 11M 1.2G 1% /run
tmpfs 2.9G 8.0K 2.9G 1% /tmp
/dev/sda1 79G 19G 56G 25% /mnt/sda1
$ qemuのqcow2イメージは38GB使ってる。minikubeの中のノードのディスク消費の倍使う？
nari@gvis-mac ~ % ls -lh ~/.minikube/machines/minikube
total 79418616
-rw------- 1 nari staff 314M 6 26 01:50 boot2docker.iso
-rw------- 1 nari staff 3.2K 6 26 01:52 config.json
-rw-r--r-- 1 nari staff 38G 6 26 04:36 disk.qcow2
-rw-r--r-- 1 nari staff 4.5K 6 26 01:50 disk.qcow2.raw
-rw------- 1 nari staff 1.6K 6 26 01:50 id_rsa
-rw------- 1 nari staff 381B 6 26 01:50 id_rsa.pub
srwxr-x--- 1 nari staff 0B 6 26 01:50 monitor
-rw------- 1 nari staff 5B 6 26 01:50 qemu.pid
nari@gvis-mac ~ %qcow2よりもっと効率いいディスクイメージとかあったらええんやけどなぁ。
minikubeでqemu使う時に指定できたりするんかな。
しばらく様子見。
クラスタ落ちることしばしば
１週間ほどして何度かクラスタ作りかえてたら、１０回に９回ぐらいの頻度でminikube cpしたときにクラスタが落ちるようになった・・・。
ひどいときは、クラスタ停止しておいて翌朝にクラスタ起動したら、podが動き出した途端に固まる。
クラスタ停止する前にはいったん全pod削除せえってか？
mariadbに負荷かけてクラスタ固まったら、普通にクラスタ起動しなおすときpodも起動しようとするから詰んでるやん。
m1チップでx86動かせても、x86でx86はアカンのか？？？
m4のminimac仕入れたらまたやってみっかな。
