minikubeを利用4-運用スクリプト作った

前回まででmariadbとDjangoのPod作ったので、その続き。

運用スクリプト作った

起動と停止ぐらい手入力でもええかもしれんけど、やっぱり作っといたほうが楽やし。
Podに対する処理はそれぞれ作ってある。例として1つずつ置いとく。

minikubeの停止

内容はこんな感じ。
10秒もかからない。

## -------------------------------------------------------------------------
## Script Name  : 301_minikubeStop.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

KB_HOME=/Users/nari/Documents/personal/minikube

echo ${LOG_FILE}
echo -------- `date +%F_%T_` -------- >> ${LOG_FILE}

minikube stop >> ${LOG_FILE}
minikube status

exit $?

minikubeの起動

内容はこんな感じ。
Mac側のフォルダをhypberkit側にマウントさせてて、その後でPodを全部作り直させてる。

何もせずともPod起動は自動でできるけど、DBを起動させてからでないとアプリがうまく動かない。
dockerの場合もdocker-composeに任せず、DBを起動させてからアプリを動かしてるしなぁ。

## -------------------------------------------------------------------------
## 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 $?

minikubeのクラスタ起動は30秒以上かかる。
Podは順序をきちっと守って再作成するから、さらに30秒ぐらい。
1分ぐらいで使える状態になるんやけど、dockerに比べたらkubernetesのほうがやっぱり時間かかる。

Podの再作成とポートフォワード

最初は作るつもりなかったけど、Podの起動順序を無理矢理に維持するために作った。
ここはmariadbのもの。

sleepつけてるのは、そのPodが起動するのに少し余裕持たせるため。
Djangoとjupyterlabはもうちょっと時間かかるから15秒ぐらいにしてる。

createはapplyってやったほうがええんかもしれんけど、deleteのペアはcreateかな。
Podは「Macのホスト名:ポート番号」で公開できる。

#!/bin/sh
## -------------------------------------------------------------------------
## Script Name  : 411_ReCreateDBpod.sh
##  Created by  : T.Naritomi
##          on  : 2023.06.20
##  Updated by  : 
##          on  :
##  Parameters  : 
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------

KB_HOME=/Users/nari/Documents/personal/minikube

## ---detail---------------------------------------------------------------- 

kubectl get pod

kubectl delete -f ${KB_HOME}/sv-mariadb1011-deployment.yaml
kubectl create -f ${KB_HOME}/sv-mariadb1011-deployment.yaml

sleep 10
kubectl port-forward --address 0.0.0.0 `kubectl get pod | grep mariadb | awk '{print $1}'` 13306:3306 &

kubectl get pod

exit

最後にポートフォワードさせてる。
これをやると、macのホスト名で名前引きして13306ポートにつなぐとmysql接続できる。

clubu22っていうxrdpのPodから接続させてみる。

nari@clubu22:~$ uname -n
clubu22
nari@clubu22:~$ mysql -unari -pXXXXXXXX --host=gvis-mac.intra.gavann-it.com --port=13306
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.5.5-10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log mariadb.org binary distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select @@hostname ; 
+---------------+
| @@hostname    |
+---------------+
| svmariadb1011 |
+---------------+
1 row in set (0.00 sec)

mysql

Podのログ確認

起動確認のために作った。
ここもmariadbのもの。

#!/bin/sh
## -------------------------------------------------------------------------
## Script Name  : 421_LoggingDBpod.sh
##  Created by  : T.Naritomi
##          on  : 2023.06.21
##  Updated by  : 
##          on  :
##  Parameters  : 
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------

## ---detail---------------------------------------------------------------- 

kubectl logs -f `kubectl get pod | grep mariadb | awk '{print $1}'`

exit

基礎確認でログ見るのとき、打鍵が多いと面倒になってしまうから、やっぱりこういうのこそ部品化して使うほうが楽。
動かすと普通のmariadbのログが見える。

もしデータ引っ越ししてpvc/pvがうまく使えなかったら、変なmariadb初期化とか動いたりするんやろなぁ。

nari@gvis-mac script % sh ./421_LoggingDBpod.sh 
2023-07-17 18:05:25+09:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.2+maria~ubu2204 started.
2023-07-17 18:05:25+09:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2023-07-17 18:05:25+09:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.11.2+maria~ubu2204 started.
2023-07-17 18:05:25+09:00 [Note] [Entrypoint]: MariaDB upgrade not required
mariadbd: Can't create file '/var/log/mariadb.log' (errno: 13 "Permission denied")
2023-07-17 18:05:25 0 [Note] Starting MariaDB 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log source revision cafba8761af55ae16cc69c9b53a341340a845b36 as process 1
2023-07-17 18:05:25 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-07-17 18:05:25 0 [Note] InnoDB: Number of transaction pools: 1
2023-07-17 18:05:25 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2023-07-17 18:05:25 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts)
2023-07-17 18:05:25 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required)
2023-07-17 18:05:25 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
2023-07-17 18:05:25 0 [Note] InnoDB: Initializing buffer pool, total size = 5.000GiB, chunk size = 80.000MiB
2023-07-17 18:05:25 0 [Note] InnoDB: Completed initialization of buffer pool
2023-07-17 18:05:25 0 [Note] InnoDB: File system buffers for log disabled (block size=4096 bytes)
2023-07-17 18:05:25 0 [Note] InnoDB: 128 rollback segments are active.
2023-07-17 18:05:25 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2023-07-17 18:05:25 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2023-07-17 18:05:25 0 [Note] InnoDB: log sequence number 2652928057; transaction id 3149
2023-07-17 18:05:25 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2023-07-17 18:05:25 0 [Note] Plugin 'FEEDBACK' is disabled.
2023-07-17 18:05:25 0 [ERROR] mariadbd: File '/var/log/mariadb_slow.log' not found (Errcode: 13 "Permission denied")
2023-07-17 18:05:25 0 [ERROR] Could not use /var/log/mariadb_slow.log for logging (error 13). Turning logging off for the whole duration of the MariaDB server process. To turn it on again: fix the cause, shutdown the MariaDB server and restart it.
2023-07-17 18:05:25 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2023-07-17 18:05:25 0 [Note] Server socket created on IP: '0.0.0.0'.
2023-07-17 18:05:25 0 [Note] Server socket created on IP: '::'.
2023-07-17 18:05:25 0 [Note] mariadbd: ready for connections.
Version: '10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2023-07-17 18:05:34 0 [Note] InnoDB: Buffer pool(s) load completed at 230717 18:05:34

Podへのログイン

内容はこんな感じ。
ここのはDjangoのもの。

#!/bin/sh
## -------------------------------------------------------------------------
## Script Name  : 403_LoginDjangoPod.sh
##  Created by  : T.Naritomi
##          on  : 2023.07.06
##  Updated by  : 
##          on  :
##  Parameters  : 
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------

## ---detail---------------------------------------------------------------- 

kubectl exec -it `kubectl get pod | grep sv-django | awk '{print $1}'` -- bash

exit

使うとこんな感じ。

先週更新したのに、pip3でアップグレード可能対象リストを表示させてみたら、もう更新対象がある。

いつまでやってもキリがないから、更新は月初に1回だけ。
linux側で更新したdockerイメージをsaveしてmac側にloadしたらええ。

nari@gvis-mac script % sh ./404_LoginDjangoPod.sh 
root@sv-django:/# cd /code/app
root@sv-django:/code/app# ls
gvisDjango3  gvisWebApp  manage.py  media  requirements.txt  templates  website
root@sv-django:/code/app# pip3 list -o
Package   Version Latest Type
--------- ------- ------ -----
fonttools 4.40.0  4.41.0 wheel
pip       23.1.2  23.2   wheel
zipp      3.16.0  3.16.2 wheel

[notice] A new release of pip is available: 23.1.2 -> 23.2
[notice] To update, run: python3 -m pip install --upgrade pip
root@sv-django:/code/app#

Podだけ削除

minikube停止するわけじゃなくて、Podだけ全部潰すスクリプトを作った。

djangoのバージョンアップとかmariadbの永続化領域にあるデータベースの内容を置き換えたりとかすると、なぜかポートフォワード途中だとPod間の通信がうまくいかない。

面倒なので、データベースの流し込みしたりdjangoのモジュールをpipでアップデートしたときは全部潰して、ポートフォワードもやりなおすことにした。

作ったのがコレ。
ポートフォワードはkubectlを「&」つきで動かしてるからプロセスとして生きてる。
これをpsで見つけ出させてkillさせて、あとはdeploymentを削除するだけ。

## -------------------------------------------------------------------------
## Script Name  : 304_allPodStop.sh
##  Created by  : T.Naritomi
##          on  : 2023.07.10
##  Updated by  :
##          on  :
##  Parameters  :
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------

KB_HOME=/Users/nari/Documents/personal/minikube

## stop port forward
ps -ef | grep kubectl | grep port-forward | awk {'print $2'} | xargs kill -9

kubectl delete -f ${KB_HOME}/sv-https-portal-deployment.yaml
kubectl delete -f ${KB_HOME}/sv-django-deployment.yaml
kubectl delete -f ${KB_HOME}/cl-ubun22-deployment.yaml
kubectl delete -f ${KB_HOME}/sv-mariadb1011-deployment.yaml

exit $?

Podだけ作成

Podを潰したら、もちろん作成するほうも必要。
これで元気にminikube使える。

## -------------------------------------------------------------------------
## Script Name  : 304_allPodStart.sh
##  Created by  : T.Naritomi
##          on  : 2023.07.10
##  Updated by  :
##          on  :
##  Parameters  :
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------

/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

exit $?

状態確認するスクリプトも作ったんやけど、それは別のページでね。

kubernetesクラスタのバージョンアップ

7月頃にminikubeとkubernetesで使えるクラスタとkubectlのバージョンが上がってたから手動で更新した。

けっこう面倒やったから、部分的にスクリプトにできんかなぁって考えた。
今はminikubeで使えるクラスタが1.28はrc版しかないけど、来月あたり1.28.1とか出てくるやろから今は練習。

やり方は手動部分が、

  1. minikubeで使える最新版の確認
  2. 新しいのがあったら、minikubeの中で使ってるpvのバックアップ

スクリプトにしとくのが、

  1. minikubeのクラスタ潰す
  2. minikubeのクラスタを最新バージョンで作る
  3. pv/pvcのapply
  4. configmapのapply
  5. serviceのapply

あとは、Pod単位のイメージをlinuxから持ってくるようにしたらええ。

それでクラスタ再起動させたらかなり手作業が減る。

手動部分はhyperkitの/dataをtar.gzで固めといたらええし、バージョンもminikube config defaults kubernetes-versionの1行目を見たらええから割愛。

そこでスクリプト作ってみたのがコレ。

## -------------------------------------------------------------------------
## Script Name  : 300_minikubeClusterRecreate.sh
##  Created by  : T.Naritomi
##          on  : 2023.08.26
##  Updated by  :
##          on  :
##  Parameters  :
##  Return Code : 0=Normal End
##     Comments :
## -------------------------------------------------------------------------
## ---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}'`  
⭐️最新バージョン番号を取ってくるけど、コメント化してNEWEST_VERにバージョン書いてもええ

GVIS_DRV=hyperkit ⭐️hyperkit使うねん
GVIS_CPU=4        ⭐️hyperkitに割り当てたいCPUの数を書いとく
GVIS_MEM=6000     ⭐️hyperkitに割り当てたいメモリサイズを書いとく
GVIS_DSK=50GB     ⭐️hyperkitに割り当てたいディスクサイズを書いとく

## ---detail----------------------------------------------------------------
echo '---newest version---'
echo ${NEWEST_VER}

read -p "--- minikube Data save ready ? ---(y/N):" yn           ⭐️手動でpvの保全したかどうか確認メッセージ
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}
/bin/sh ${EXEC_HOME}/301_minikubeStop.sh                        ⭐️minikubeとめる

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}
minikube config config view

echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
minikube config view >> ${LOG_FILE}                             ⭐️minikubeが使うhyperkitの設定確認
minikube delete >> ${LOG_FILE}                                  ⭐️minikubeの中のクラスタ潰す
minikube start --kubernetes-version ${NEWEST_VER} --mount --mount-string ${MINK_HOME}/:/minikubeMac >> ${LOG_FILE}
                                                                ⭐️最新バージョンでクラスタ作る
cat ${LOG_FILE}
sleep 20

kubectl config get-contexts
kubectl get pod -n kube-system 

⭐️こっからpv/pvc/service/configmapをapply

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-ubun22.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 &  ⭐️ブラウザでコンソール開いてpv/pvc/service/comfigmapを目視確認

exit $?

ログと混ぜて表示させとくけど、動かすとこんな感じ。
2分ぐらいでPodが動かせる状態のクラスタ作成が終わる。

nari@gvis-mac script % sh ./300_minikubeClusterRecreate.sh 
---newest version---
v1.28.0-rc.1
--- minikube Data save ready ? ---(y/N):y
--- minikube Recreate cluster ready ? ---(y/N):y
---Recreate start---
-------- 2023-08-26_04:53:14_ --------
✋  「minikube」ノードを停止しています...
🛑  1 台のノードが停止しました。
-------- 2023-08-26_04:53:20 --------
- cpus: 4
- disk-size: 50GB
- driver: hyperkit
- memory: 6000
❌  Multiple errors encountered:
🔥  hyperkit の「minikube」を削除しています...
💀  クラスター「minikube」の全てのトレースを削除しました。
😄  Darwin 13.4.1 上の minikube v1.31.2
✨  ユーザーの設定に基づいて hyperkit ドライバーを使用します
👍  minikube クラスター中のコントロールプレーンの minikube ノードを起動しています
🔥  hyperkit VM (CPUs=4, Memory=6000MB, Disk=51200MB) を作成しています...
🐳  Docker 24.0.4 で Kubernetes v1.28.0-rc.1 を準備しています...
    ▪ 証明書と鍵を作成しています...
    ▪ コントロールプレーンを起動しています...
    ▪ RBAC のルールを設定中です...
🔗  bridge CNI (コンテナーネットワークインターフェース) を設定中です...
📁  マウント /Users/nari/Documents/personal/minikube/:/minikubeMac を作成しています...
🔎  Kubernetes コンポーネントを検証しています...
    ▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🌟  有効なアドオン: default-storageclass, storage-provisioner
🏄  終了しました!kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
-------- 2023-08-26_04:54:41 --------
CURRENT   NAME       CLUSTER    AUTHINFO   NAMESPACE
*         minikube   minikube   minikube   default
NAME                               READY   STATUS    RESTARTS   AGE
coredns-5dd5756b68-w4hh9           1/1     Running   0          9s
etcd-minikube                      1/1     Running   0          21s
kube-apiserver-minikube            1/1     Running   0          21s
kube-controller-manager-minikube   1/1     Running   0          21s
kube-proxy-bsxlq                   1/1     Running   0          9s
kube-scheduler-minikube            1/1     Running   0          21s
storage-provisioner                1/1     Running   0          20s
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-ubun22 created
persistentvolumeclaim/gvis-pv-ubun22-claim created
configmap/sv-mariadb11-txt created
service/sv-django created
service/sv-https-portal created
service/sv-mariadb1011 created
nari@gvis-mac script % 🔌  ダッシュボードを有効化しています...
    ▪ docker.io/kubernetesui/dashboard:v2.7.0 イメージを使用しています
    ▪ docker.io/kubernetesui/metrics-scraper:v1.0.8 イメージを使用しています
💡  いくつかのダッシュボード機能は metrics-server アドオンを必要とします。全機能を有効にするためには、次のコマンドを実行します:

	minikube addons enable metrics-server	


🤔  ダッシュボードの状態を検証しています...
🚀  プロキシーを起動しています...
🤔  プロキシーの状態を検証しています...
🎉  デフォルトブラウザーで http://127.0.0.1:49644/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ を開いています...

nari@gvis-mac script %

これでバージョンアップが楽になるやん。
来月楽しみやわ。

jupyterのPod

pythonの勉強のためにも使ってるけど、日常的にはmacで書いたテキストを橋渡しするのに使ってる。
最初はkomposeの出力を流用して動かした。

dockerで動かしてるから1つあればいいし、2つあるとどっちに書いたか忘れるからmacでは常時では動かさないことにした。

それでも、せっかく作ったのでここには書いとく。

jupyterのpv/pvc

1つ目はpython3用のpvc/pv。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: gvis-pv-jupyter-py3 # PVの名前
  labels:
    type: local
spec:
  storageClassName: manual # PVCと一致させる必要がある
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce # 一つのノードからread/writeでマウントできるモード
  hostPath:
    path: "/data/gvis-pv-jupyter/py3/root_jupyter"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gvis-pv-jupyter-py3-claim # PVCの名前
spec:
  # storageClassName=manualのPVを探してマウントする
  storageClassName: manual 
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi # PVが持っている容量のうち5GiBを使用する

2つ目はワークスペース用のpvc/pv。

kind: PersistentVolume
apiVersion: v1
metadata:
  name: gvis-pv-jupyter-ws # PVの名前
  labels:
    type: local
spec:
  storageClassName: manual # PVCと一致させる必要がある
  capacity:
    storage: 15Gi
  accessModes:
    - ReadWriteOnce # 一つのノードからread/writeでマウントできるモード
  hostPath:
    path: "/data/gvis-pv-jupyter/workspace"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gvis-pv-jupyter-ws-claim # PVCの名前
spec:
  # storageClassName=manualのPVを探してマウントする
  storageClassName: manual 
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 15Gi # PVが持っている容量のうち15GiBを使用する

jupyterのdeployment

内容はこんな感じ。

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose convert --volumes hostPath
    kompose.version: 1.28.0 (HEAD)
  creationTimestamp: null
  labels:
    io.kompose.service: sv-jupyter
  name: sv-jupyter
spec:
  replicas: 1
  selector:
    matchLabels:
      io.kompose.service: sv-jupyter
  strategy:
    type: Recreate
  template:
    metadata:
      annotations:
        kompose.cmd: kompose convert --volumes hostPath
        kompose.version: 1.28.0 (HEAD)
      creationTimestamp: null
      labels:
        io.kompose.network/minikube-default: "true"
        io.kompose.service: sv-jupyter
    spec:
      containers:
        - command:
            - jupyter-lab
            - --allow-root
            - --ip=0.0.0.0
            - --port=8888
            - --no-browser
            - --NotebookApp.token=
            - --notebook-dir=/workspace
          image: save-jupyter:gvis-saved
          name: sv-jupyter
          ports:
            - containerPort: 8888
          resources: {}
          volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
            - name: jupyter-persistent-storage1
              mountPath: /root/.jupyter
            - name: jupyter-persistent-storage2
              mountPath: /workspace

      hostname: svjupyter
      restartPolicy: Always
      volumes:
      - name: jupyter-persistent-storage1
        persistentVolumeClaim:
          claimName: gvis-pv-jupyter-py3-claim
          # name=gvis-pv-mariadb1011-claimを使って、マウントできるPVを探す
      - name: jupyter-persistent-storage2
        persistentVolumeClaim:
          claimName: gvis-pv-jupyter-ws-claim
          # name=gvis-pv-mariadb1011conf-claimを使って、マウントできるPVを探す

jupyterのservice

内容はこんな感じ。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: sv-jupyter
  name: sv-jupyter
spec:
  type: ClusterIP
  ports:
    - name: "21088"
      port: 21088
      targetPort: 8888
  selector:
    app: sv-jupyter
タイトルとURLをコピーしました