minikubeを利用6-クラスタのバージョンアップ

前回まででdjangoアプリの色合い変更まで作ったので、その続き。

2023年6月にはkubernetesのバージョンは1.27が出てたけど、minikubeで使えるクラスタは1.26やった。
7月3週目ぐらいにbrewの更新見てたら1.27が使えるようになってた。

kubernetesの親バージョンリリースがあったら、minikubeには1ヶ月後にリリースがあるんかなぁ。

その後、何回かminikubeのバージョン上げた。

  1. 2024年5月中にminikube v1.33.1、Docker 26.0.2 で Kubernetes v1.30.0
  2. 2024年4月末にminikube v1.33.0、Docker 26.0.1 で Kubernetes v1.30.0
  3. 2023年11月にminikube v1.32.0、Docker 24.0.7 で Kubernetes v1.28.3
  4. 2023年8月にminikube v1.31.2、Docker 24.0.4 で Kubernetes v1.28.0-rc.1

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ってどんなんやろ」ってやり始めて3週間、その中で作ったものが一瞬で吹っ飛ぶのは心が折れる。
これを書いているときは、macごとフルバックアップして1回バージョンアップ練習やってるから別になんともない。

クラスタを作り直すってのは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してみた。
cpu4コアで、メモリだいたい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とか使うとき、ビルドは運用サーバでやったほうがええ。

理由はこんな感じ。

  1. ローカルPCにdocker/rancher/WSLとか色々入れて業務できたらラッキーやけど、大きな企業がお客さんのときは何でもインストールしてええわけやなくて制限がいっぱいある。
  2. そもそもプロキシあることがほとんどで、トラフィック混んでたらビルド途中でdockerhub見えんとか普通に発生するから、クラウドの中の運用サーバ使うのが確実(許可設定つけなアカンけど)。
  3. 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.74kB

dockerイメージできてるか確認。
ちゃんとできとるなぁ。

$ 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って入れとく。

gvis-minikubeVerup

djangoのアプリが見えてる。
ポートフォワードしてるから、macだけじゃなくて他のwindowsホストからも見えてるしdjangoのバージョンも維持できてデータベース参照もできてる。

gvis-minikubeVerup

djangoのmatplotlib使ったグラフ表示やフォントの日本語表示もできてるし、データベースのレコード参照でもエラー出てない。

gvis-minikubeVerup

クラスタ潰すところから、40分ぐらい。
1から作り直すけど、バージョンアップはここまで。

クラスタ更新(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で定期更新動かしたら3日前ぐらいに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のマクロ使って動かしてる。

gvis-minikubeVerup

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 % 

起動確認

クラスタいっかい停止してから、もう1回起動する。
ここでは最新のログ置いとく。

nari@gvis-mac log % tail -f  300_minikube.log 
-------- 2024-05-16_04:08:30 --------
😄  Darwin 14.4.1 上の minikube v1.33.1
✨  既存のプロファイルを元に、hyperkit ドライバーを使用します
👍  Starting "minikube" primary control-plane node in "minikube" cluster
🔄  「minikube」のために既存の hyperkit VM を再起動しています...
🐳  Docker 26.0.2 で Kubernetes v1.30.0 を準備しています...
🔗  bridge CNI (コンテナーネットワークインターフェース) を設定中です...
🔎  Kubernetes コンポーネントを検証しています...
📁  マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
    ▪ docker.io/kubernetesui/dashboard:v2.7.0 イメージを使用しています
    ▪ docker.io/kubernetesui/metrics-scraper:v1.0.8 イメージを使用しています
    ▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
💡  Some dashboard features require the metrics-server addon. To enable all features please run:

    minikube addons enable metrics-server

🌟  有効なアドオン: default-storageclass, storage-provisioner, dashboard
🏄  終了しました!kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました

はい、できたー。

gvis-minikubeVerup

m4のmacmini出てきたらhyperkit使わなくなるから、この設定での実施は今回が最後になるんかなぁ。

2024年の秋はどうなるんやろ。

タイトルとURLをコピーしました