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

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

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

kubernetesの親バージョンリリースがあったら、minikubeには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すっからかんになる

GKEのクラスタやったら、podとかpvcを維持しながらクラスタのバージョン上げれたはず。

minikubeにminikube versionupとかはない。

バージョン上げるにはminikube deleteってやって、いっかい削除せなアカンらしい。
どこかにpodとか維持しながらバージョン上げる方法あるのかもしれんけど、見つけられんかった。

やってみると、minikube deleteはhyperkitを丸ごと吹っ飛ばす。
dockerイメージも消えてなくなる。
地味にビルドしてたとしたら、けっこう悲しいことやね。
残酷やなぁ。

自分は別の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ある。あ、GiBやから6000MBっていうことやね。

使ってるメモリ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から持ってくる

前に書いたこの方法で、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から作り直すけど、バージョンアップはここまで。

コメント

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