前回まででmariadbとDjangoのPod作ったので、その続き。
運用スクリプト作った
起動と停止ぐらい手入力でもええかもしれんけど、やっぱり作っといたほうが楽やし。
Podに対する処理はそれぞれ作ってある。例として１つずつ置いとく。
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)
mysqlPodのログ確認
起動確認のために作った。
ここも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:34Podへのログイン
内容はこんな感じ。
ここのは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でアップグレード可能対象リストを表示させてみたら、もう更新対象がある。
いつまでやってもキリがないから、更新は月初に１回だけ。
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とか出てくるやろから今は練習。
やり方は手動部分が、
- minikubeで使える最新版の確認
- 新しいのがあったら、minikubeの中で使ってるpvのバックアップ
スクリプトにしとくのが、
- minikubeのクラスタ潰す
- minikubeのクラスタを最新バージョンで作る
- pv/pvcのapply
- configmapのapply
- serviceのapply
あとは、Pod単位のイメージをlinuxから持ってくるようにしたらええ。
それでクラスタ再起動させたらかなり手作業が減る。
手動部分はhyperkitの/dataをtar.gzで固めといたらええし、バージョンもminikube config defaults kubernetes-versionの１行目を見たらええから割愛。
そこでスクリプト作ってみたのがコレ。
## -------------------------------------------------------------------------
## 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 $?ログと混ぜて表示させとくけど、動かすとこんな感じ。
２分ぐらいで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で動かしてるから１つあればいいし、２つあるとどっちに書いたか忘れるからmacでは常時では動かさないことにした。
それでも、せっかく作ったのでここには書いとく。
jupyterのpv/pvc
１つ目は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を使用する２つ目はワークスペース用の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