先月M4のmacminiに切り替えた。intelやなくてM4になって爆速を期待して買った。
macの仮想化のベースをvmwareからUTMに切り替えて、sequoiaはめっちゃ速くなった。
次はx86のubuntu24の中で維持してるdockerのxrdp／django／mariadbのコンテナをM4のmacminiで動かしたい。
自分の勘違いもあって時間はかかったけど、実現はできたのでそのメモ。
結論
右から順に、GCEってあるgoogle cloudに本番データ置いてる。
GCE(google cloud)で稼働させてるdockerコンテナのデータをlocal ubuntu24でも利用しつつ、sequoiaに持ってくる。
macminiはフロントとして使う環境やから、utmで仮想化したsequoia動かしてて、今回はubuntu追加した。
x86エミュレートさせたubuntu24の中で、ctrで動くmicrok8s使ってkubernetes環境を作る。
⭐️印が今回作った箇所。
+-macmini sequoia--------------+ +-local ubuntu24 linux--------+ +-GCE ubuntu24 linux----------+
| +-utm----------------------+ | | +-docker---------+ +-vmdk-+ | | +-docker---------+ +--pv--+ |
| | +-sequoia-------------+ | | | | +-container-+ | | data | | | | +-container-+ | | data | |
| | | vscode/cyberduck | | | | | | Django | | | d1 | | | | | Django | | | d1 | |
| | | office/brew/rdp | | | | | +-----------+ | +------+ | | | +-----------+ | +------+ |
| | +---------------------+ | | | | +-container-+ | | | | | | +-container-+ | | | |
| | +-ubuntu24 x86⭐️------+ | | | | | mariadb | | | d2 | | | | | mariadb | | | d2 | |
| | | ctr microk8s | | | | | +-----------+ | +------+ | | | +-----------+ | +------+ |
| | |+-container-+ | | | | | +-container-+ | | | | | | +-container-+ | | | |
| | ||kubernetes | | | | <- | | | xrdp-ubu24| | | d3 | | <- | | | xrdp-ubu24| | | d3 | |
| | |+-----------+ | | | <- | | +-----------+ | +------+ | <- | | +-----------+ | +------+ |
| | |+-container-+ +/data+| | | <- | | | | <- | | +-container-+ | |
| | ||Django | | d1 || | | | | | | | | | gitlab | | |
| | |+-----------+ +-----+| | | | | | | | | +-----------+ | |
| | |+-container-+ | || | | | | +-container-+ | +------+ | | | +-container-+ | +------+ |
| | ||mariadb | | d2 || | | | | | https | | | d4 | | | | | https | | | d4 | |
| | |+-----------+ +-----+| | | | | +-----------+ | +------+ | | | +-----------+ | +------+ |
| | |+-container-+ | || | | | +----------------+ | | +----------------+ |
| | ||xrdp-ubu24 | | d3 || | | +-----------------------------+ +-----------------------------+
| | |+-----------+ +-----+| | |
| | |+-container-+ +-----+| | |
| | ||https | | d4 || | |
| | |+-----------+ +-----+| | |
| | +---------------------+ | |
| +--------------------------+ |
| |
| +-music----------+ |
| | 8400(37GB) | |
| +----------------+ |
+------------------------------+M4にx86をエミュレートさせて動かしたとき、local ubuntu24の中で動くxrdpコンテナに比べたら、114Mbpsって見えるからインターネット利用は８分の１程度の速度、ブラウザ利用の速度はintel版のminikube/microk8sと同じかそれ以下のもっさりした動きになった。
設定に問題あるんかもしれんけど、utmの裏方で動いてるqemuのエミュレートが残念な性能。
大昔、g3のmacbookでintel solaris動かしたときのような遅さ。
こんな遅いんやったら、M4のmacの中でkubernetes使うのやめよかなぁ。
構成変更考えながら、まだまだコンテナ仮想化での挑戦は続く。
やったこと
試行錯誤したから２週間ぐらいはかかった。
macmini M4のmicrok8sではarm64やで
最初、macmini本体にmicrok8s入れて入れクラスタ作りかけたら、なんじゃこりゃって箇所に気づいた。
nari@nariMac-mini script % sudo ls -lha /var/root/Library/Application\ Support/multipassd/qemu/vault/instances/microk8s-vm
Password:
total 5841000
drwxr-xr-x 4 root wheel 128B 11 19 07:20 .
drwxr-xr-x 3 root wheel 96B 11 19 07:20 ..
-rw-r--r-- 1 root wheel 52K 11 19 07:20 cloud-init-config.iso
-rw-r--r-- 1 root wheel 2.8G 11 19 07:26 ubuntu-24.04-server-cloudimg-arm64.img ⭐️おいおい、x86のは作れんのか
nari@nariMac-mini script % macminiの中でmicroks8/multipass動かしてイメージファイルの置き場確認するとarm64版になってる。
普通の人はこれでエエんかもしれんけど、これやとintel環境のdockerイメージ持ってきたら動かんやん。
ぬぬぬ、どないしよう。
macのmicrok8sとmultipassやめ。
utmでx86のubuntu24作ってその中にmicrok8s入れてノード稼働させる。
macminiの中のkubectlの向き先を、utmの中のubuntu24にして使えばええ。
って、これやったらlocal ubuntu24と同じようなスペックで、windows環境のVMでmicrok8sが動くノード作ったほうが性能出るぞ。
それでも、M4の中でx86エミュレートのubuntu作ったるねん。
x86のubuntu24作るで
M4でx86のubuntu24の仮想マシン作る。
UTMでどんなふうに作るのか例を探したら、M1のmacで解説されてる方がおられたので参考にさせてもらった。
作者さんありがとう。
マシンのタイプとネットワークインターフェースの種類を変えたら性能上がることあるんかなぁ。調整しながら使ってく。
だいたいの設定
multipassやったら勝手にやってくれるんやけど、UTM使うから自分でノード作らなアカンのよ。
重たいGUI要らんし、CUIだけでええ。設定項目画面で見ながら軽く考えた。
アーキテクチャ:x86_64エミュレート
マシン:StandardPC(Q35+ICH9,2009)(alias of pc-q35-7.2)(q35)
システム:CPU6コア、マルチコアを強制
メモリ:10GB
ディスク:64GB
入力:USB無効
共有:クリップボード共有無効、ディレクトリ共有モードVirtFS
共有ディレクトリ:/Users/nari/Documents/personal/microk8s (microk8s)
ネットワーク:ブリッジ、InterlGigabitEthernet(e1000)UTMの実際の設定
kubernetes動かすためのlinuxを用意してく。
x86エミュレートさせる。マルチコア強制しても不安定にはならんかったけどな。
USBなんかいらん。
macminiの中のフォルダを共有させるのはVirtFSってモード使うらしい。スクリプトとか永続化領域で使うデータとかを共有させとく。
cuiで使うからディスプレイカードとか適当。
ネットワークは共有やなくてブリッジにして宅内LANのIPアドレス割り当てる。後で名前解決設定をDNSに入れる。
scsiのほうが性能出るんかな。ディスクはIDEでデフォルトのまま。最初間違ったから31.65GBやなくて60GBに後で変更した。
OSインストール
インストールはubuntu serverのisoイメージダウンロード用意しといて、それを一時的に１つ目のディスクに追加してから普通にインストールする。
手動でサブネットの設定するときのテキスト忘れそうやからメモっとく。255.255.255.0っていう書き方やないねん。
hostname:kubelinux
IP: 192.168.1.119
subnet: 192.168.1.0/24
GW: 192.168.1.1
dns: 172.16.17.15,8.8.8.8あと、lvmがディスクの中でフル利用してくれんからサイズもめいっぱい使うように変更した。
fstabにマウント設定書き足す
macminiにmicrok8sで使うスクリプトとか、ctrへインポートするdockerイメージの置き場領域作ってあって、これをkubelinuxにマウントして使わせる。
UTMのフォルダ共有をマウントする方法を解説されている方がおられた。
作者さんありがとう。
最初にUTMの共有ディレクトリを手動でマウントするときはこんなことする。仮想マシン作り直したらコレ打たなアカン。
sudo mkdir /microk8s
sudo chown nari:nari /microk8s
sudo mount -t 9p -o trans=virtio share /microk8s -oversion=9p2000.Lマウント手動なんて毎回やってられんから、/etc/fstabに書き足しておくとaptでモジュールの付け外しとか、クラスタの作成やりやすくなる。
share /microk8s 9p trans=virtio,version=9p2000.L,rw,_netdev,nofail 0 0ssh接続する設定を作っといて、macminiのutmで動くVMのOS起動させて、最終的にssh接続したときはこんな感じ。
おお、ちゃんとマウントもできとるで。
間違えてdns設定にもGWのIPアドレスが入ってしもとるけど、最初の２つで名前解決できるやろし、起動時間も２３秒やし、まぁええか。
性能向上は、別でまた挑戦すっかな。
mac内で使うmicrok8s(x86エミュレート)のubuntu24の細かい設定
考える時はこのへんの設定をいつも見て、手動でやったのはこんな内容。
起動時間の目安確認
OSインストールした直後とか、あまりにも遅い時とかに確認する。
３０秒以内やったら自分はOKにしてる。
systemd-analyzeタイムゾーン設定
Pod動かすためのノードやから日本語は要らんけど、時間表記はUTCやとログ読むとき困る。
sudo timedatectl set-timezone Asia/Tokyoクラウドの中で、たまにUTCでログ表記やってるの見かける。昔のIISもそうやったなぁ。今もそうなんかなぁ。
あれ９時間のオフセット読み替えなアカンから、めっちゃ疲れるからやめて欲しい。
CUIログイン設定
１回だけGUI起動試そうとしたけど、うまいこと使えんかった。
cuiログインに戻す時はこうした。
sudo systemctl set-default multi-user キーボード関連の設定
sshするからほぼ要らんけどGUIから戻す時に使った。
sudo dpkg-reconfigure keyboard-configurationaptモジュール
使わんものもあるからモジュールをaptで外す。
microk8sはsnap使ってクラスタ作るときに使う。
最初考えたのはこんなん。
apt-get -y install ubuntu-desktop ⭐️１回だけやってみたけど重いしやめた
apt -y install language-pack-ja-base language-pack-ja ⭐️日本語いらんからやめた
apt remove byobu/noble ⭐️こっから下のthnderbirdまではGUIやと入るけどCUIでは入らんからエラー出ても無視
apt remove remmina*
apt remove rhythmbox*
apt remove thunderbird*
apt remove cups* ⭐️印刷とか要らんやろ
apt remove printer-driver*
apt remove modemmanager* ⭐️モデム・ppp・スキャナ・usb・wifiなんか要らん
apt remove ppp*
apt remove pptp* sane-* usb-* wireless-*
apt autoremove
apt install nmon ⭐️コア数確認に使う
apt install net-tools ⭐️nslookupとかネットワーク確認に使うエイリアス
rootユーザの.bashrcはこのへんのを下地にしてこう書いた。
alias dff='df -h | grep -v "dev/loop" | grep -v tmpfs'
alias tree="pwd;find . | sort | sed '1d;s/^\.//;s/\/\([^/]*\)$/|--/;s/\/[^/|]*/| /g'"
alias sc='cd /microk8s/script'
alias m8='cd /microk8s'
alias dc='cd /data'
## 配下の.DS_Storeと._xxx を削除
function removegomi () {
find . \( -name '.DS_Store' -or -name '._*' \) -delete -print;
}
alias rmgomi=removegomi
PATH=/microk8s/script:$PATH:$HOME/bin
export PATHscって打つとスクリプトのフォルダにいってくれて、m8って打つとkubernetesのマニフェストが入ってるフォルダにいってくれる。
macminiの中からの共有で/microk8sを使わせてるから、miとかvs codeとかで編集しつつ、仮想マシンの中で使える。
宅内DNS登録
クラスタ作る前に、宅内dnsにmicrok8sが動くubuntuホストの名前を定義した。
仮想ホストは作り替えることあるけど、役割は同じやから名前引きできるようにしとく。
先に作ったutmの設定名を、そのままホスト名にしてるから、fqdn名をdnsに追加登録。
ルータはyamahaのrtxシリーズで、設定ファイルに書き足して反映しとくと宅内でDNSの役割してくれて名前引きができる。
ip host kubelinux.intra.gavann-it.com 192.168.1.119こうしとくと、macからもwindowsからも名前引きできる。
nari@nariMac-mini ~ % nslookup kubelinux.intra.gavann-it.com
Server: 172.16.17.15
Address: 172.16.17.15#53
Name: kubelinux.intra.gavann-it.com
Address: 192.168.1.119
nari@nariMac-mini ~ % UTMの中のubuntuでも引ける。
nari@kubelinux:~$ nslookup kubelinux.intra.gavann-it.com
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: kubelinux.intra.gavann-it.com
Address: 192.168.1.119
** server can't find kubelinux.intra.gavann-it.com: NXDOMAIN
nari@kubelinux:~$ local ubuntu24のdockerコンテナからも同じような結果が戻る。
nari@clubu24:~$ nslookup kubelinux.intra.gavann-it.com
Server: 127.0.0.11
Address: 127.0.0.11#53
Non-authoritative answer:
Name: kubelinux.intra.gavann-it.com
Address: 192.168.1.119
** server can't find kubelinux.intra.gavann-it.com: NXDOMAIN
nari@clubu24:~$ windowsからやとこうなる。
C:\Users\nari>nslookup kubelinux.intra.gavann-it.com
サーバー: UnKnown
Address: 172.16.17.15
名前: kubelinux.intra.gavann-it.com
Address: 192.168.1.119
C:\Users\nari>こうしとくとクラスタの外側から参照できる。
ただし、kubernetesのpodからどうしてもこの宅内DNSの名前引きできんかったんよ。
なんでなんやろなぁ。そのうち何かに気づけたらええんやけど・・・。
クラスタ作成
macの中でmicrok8s使ってたとき、クラスタ作成っていうとqemuのノードごと作ってくれてた。
今回のUTMの裏でもqemuが動いてるっぽいんやけど、microk8sはubuntuのsnapって仕組みを使う。
aptと共存できるんやなぁ。
パッケージ管理のためにあるみたいなんやけど、snapでmicrok8sの管理することでノード作ったり潰したりできるみたい。
そのままコマンドライン打つのは面倒なので、状態確認・作る・動かす・止める・潰すのスクリプトをminikube/microk8sを通じて用意した。
nari@kubelinux:/microk8s/script$ ls -l
total 28
-rwxr-xr-x 1 501 dialout 2641 Dec 5 07:45 300_kubeClusterRecreate.sh ⭐️潰して作り直し
-rwxr-xr-x 1 501 dialout 989 Nov 29 06:37 301_kubeStop.sh ⭐️停止
-rwxr-xr-x 1 501 dialout 997 Nov 29 06:38 302_kubeStart.sh ⭐️起動
-rwx------ 1 501 dialout 618 Dec 6 05:35 305_allForwardingStop.sh ⭐️Podのフォワード停止
-rwx------ 1 501 dialout 943 Dec 6 06:16 306_allForwardingStart.sh ⭐️Podのフォワード開始
-rwxr-xr-x 1 501 dialout 1757 Dec 6 05:24 onlchk ⭐️状態確認
nari@kubelinux:/microk8s/script$ 機能概要や使えるバージョンの一覧
概要だけやなく有効なkubernetesのバージョンが確認できるのな。
snap info microk8s | more使えるchannel(バージョン)の一覧は、サイズが書いてある箇所をgrepで引っ掛けたら、なんとなく見える。
nari@kubelinux:~$ snap info microk8s | grep MB | head -10
1.31/stable: v1.31.3 2024-12-03 (7449) 168MB classic
1.31/candidate: v1.31.3 2024-11-25 (7449) 168MB classic
1.31/beta: v1.31.3 2024-11-25 (7449) 168MB classic
1.31/edge: v1.31.4 2024-12-10 (7514) 168MB classic
latest/stable: v1.31.3 2024-12-04 (7449) 168MB classic
latest/candidate: v1.31.3 2024-11-22 (7447) 168MB classic
latest/beta: v1.31.3 2024-11-22 (7447) 168MB classic
latest/edge: v1.32.0 2024-12-12 (7548) 171MB classic
1.32-strict/stable: v1.32.0 2024-12-12 (7549) 171MB -
1.32-strict/candidate: v1.32.0 2024-12-12 (7549) 171MB -
nari@kubelinux:~$ お、12月中旬やから1.32のクラスタ使えるようになるかも。
右端にclassicって書いてへんけど、そのうち足してくれるやろな。
クラスタ作る
ubuntu24でmicrok8sをアンインストール／インストールすることで構成できる。
sudo snap remove microk8s
rm -fR ~/.kube
sudo snap install microk8s --channel=1.31-strict --classic引数の中のchannelって箇所でバージョン指定、classicは慣用句みたいなもんか。
kubernetesはノードを複数使うのが普通なんやけど、ローカルで使う時は１つでええ。
nginxのマスターノード・ワーカーノードみたいな感じでノード管理できる。
linuxのはmicrok8s add-nodeいるんかと思ったら、やらんでも動く。
一般ユーザで使うためのおまじない
一般ユーザをグループ追加。
sudo usermod -a -G snap_microk8s $USER
sudo chown -R $USER ~/.kube世間一般では、rootにsudoしたとき「このユーザを使う意味とその重さを理解しなさい」ってバナーみたいなの表示させる企業もあるんやけどね。
UTMの中の仮想マシンは割り切って使っててrootしか使わんから、あんまりいらん。
クラスタ潰して作り直しのスクリプト
なんでかわからんけどUTMの共有フォルダに置いたマニフェストがうまく読めんことがあったから、いったんノードの中にコピーしてから使うようにしてる。
最初コピー先を/tmpってやってもアカンかったから/root使うことにした。
## -------------------------------------------------------------------------
## Script Name : 300_kubeClusterRecreate.sh
## Created by : T.Naritomi
## on : 2023.08.26
## Updated by : 2024.11.28
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : change driver hyperkit -> qemu2 , minikube -> microk8s
## -------------------------------------------------------------------------
## ---define----------------------------------------------------------------
EXEC_HOME=/microk8s/script # Execute Home directory
KUBE_HOME=/microk8s # kubernetes Home directory
LOG_FILE=/microk8s/log/kube.log # Log file
GVIS_VER=1.31/stable ⭐️新しいの出たら書き換える
GVIS_USER=nari
## ---detail----------------------------------------------------------------
read -p "--- kube Data save ready ? ---(y/N):" yn
case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac
read -p "--- kube Recreate cluster ready ? ---(y/N):" yn
case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac
echo '---Recreate start---' >> ${LOG_FILE}
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
echo ${LOG_FILE}
snap remove microk8s >> ${LOG_FILE}
rm -fR ~/.kube
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
snap install microk8s --channel=${GVIS_VER} --classic >> ${LOG_FILE} ⭐️これだけでええ
## usermod -a -G snap_microk8s ${GVIS_USER}
## chown -R ${GVIS_USER} /home/${GVIS_USER}/.kube
mkdir -p /data
chmod 777 /data ⭐️これ忘れたらPodから永続化領域使えん
microk8s enable registry --size 30Gi >> ${LOG_FILE} ⭐️dockerイメージ入れるctrのイメージ置き場はサイズ指定しとかな入らん
microk8s enable hostpath-storage >> ${LOG_FILE}
microk8s enable host-access >> ${LOG_FILE}
echo -------- kubernetes cluster created -------- >> ${LOG_FILE}
cp ${KUBE_HOME}/*.yaml /root/ ⭐️UTMから共有してる/microk8sのフォルダがなぜかそのまま使えんことあったから、コピーして使うことにした
sync ; sync ; sync
sleep 10
microk8s kubectl apply -f /root/gvis-PersistentVol-mariadb.yaml
microk8s kubectl apply -f /root/gvis-PersistentVol-mariadbconf.yaml
microk8s kubectl apply -f /root/gvis-PersistentVol-sv_django-ssl_certs.yaml
microk8s kubectl apply -f /root/gvis-PersistentVol-sv_django-uwsgi-nginx.yaml
microk8s kubectl apply -f /root/gvis-PersistentVol-ubun.yaml
microk8s kubectl apply -f /root/mariadb-txt-configmap.yaml
microk8s kubectl apply -f /root/sv-django-service.yaml
microk8s kubectl apply -f /root/sv-https-portal-service.yaml
microk8s kubectl apply -f /root/sv-mariadb-service.yaml
rm -f /root/*.yaml
echo -------- `date +%F_%T` -------- >> ${LOG_FILE}
microk8s kubectl get nodes
microk8s dashboard-proxy &
exit $?当たり前やけど、クラスタ作ったら普通に使える。
macminiからクラスタへ接続
自分のフロントエンドはmacなんやから、kubectlからのkubernetesクラスタの向き先をUTMの中の仮想マシンに向ける。
mac側にkubectl入れる。
brew install kubernetes-cligoogle cloudのGKE(Google Kubernetes Engine)でクラスタをmacのkubectlで操作したことあったけど、gcloudの初期設定の裏側で同じようなことやってるんかもな。
この1年ほどで気づいたんやけど、kubernetesのクラスタバージョンが上がるとき前触れがあって、kubectl-clientのバージョンが１週間前ぐらいに上がる。
######## upgrade ########
==> Upgrading 1 outdated package:
kubernetes-cli 1.31.4 -> 1.32.0 ⭐️新しいのでてるやん！！ もうすぐクラスタ作り替えやな！！
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/manifests/1.32.0
############################################################################################# 100.0%
==> Fetching kubernetes-cli
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/blobs/sha256:83f41dddaff07d9a1b81536
############################################################################################# 100.0%
==> Upgrading kubernetes-cli
1.31.4 -> 1.32.0
==> Pouring kubernetes-cli--1.32.0.arm64_sequoia.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
/opt/homebrew/share/zsh/site-functions
==> Summary
🍺 /opt/homebrew/Cellar/kubernetes-cli/1.32.0: 255 files, 60.7MB
==> Running `brew cleanup kubernetes-cli`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /opt/homebrew/Cellar/kubernetes-cli/1.31.4... (237 files, 60.2MB)
Removing: /Users/nari/Library/Caches/Homebrew/kubernetes-cli_bottle_manifest--1.31.4... (7.2KB)
Removing: /Users/nari/Library/Caches/Homebrew/kubernetes-cli--1.31.4... (17.2MB)kubectlのクラスタ向き先設定を解説してくれる方がおられた。
作者さんありがとう。
当たり前のことやけど、クラスタ作り直したら向き先設定の中にある認証情報は変わるから設定しなおしせなアカン。
こっち向いてちょ
miocrok8sの認証情報を確認すると、画面に文字列いっぱい流れてく。
sudo microk8s.kubectl config view --raw流れてく内容を書き換えてmac側で保存する。
宅内DNSの名前やなくてIPアドレス書いて向き先設定する。
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: xxxxxxx(いっぱい文字出る)xxxxxxx
server: https://192.168.1.119:16443 ⭐️ここのIPアドレスを書き換える
name: microk8s-cluster-x86
contexts:
- context:
cluster: microk8s-cluster-x86
user: admin
name: microk8s-x86
current-context: microk8s-x86
kind: Config
preferences: {}
users:
- name: admin
user:
client-certificate-data: xxxxxxx(いっぱい文字出る)xxxxxxx
client-key-data: xxxxxxx(いっぱい文字出る)xxxxxxxmac側のホームディレクトリに.kubeってフォルダがあって、保存したらこうなる。
コピーして作ったけど、たぶんアクセス権600にしとかなアカンのやろな。
nari@nariMac-mini .kube % ls -l
total 56
drwxr-x--- 4 nari staff 128 6 23 06:54 cache
-rw------- 1 nari staff 5466 11 29 05:23 config ⭐️書き換えて作った
-rw------- 1 nari staff 5466 11 19 07:21 config.arm64 ⭐️macにmicrok8s作ったときのが残ってたので一旦退避
nari@nariMac-mini .kube % 向き先確認
mac側でconfigファイルを指定してubuntu24のmicrok8sから情報取れるか確認。
nari@nariMac-mini .kube % kubectl --kubeconfig=${HOME}/.kube/config get all
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 23h
service/sv-django ClusterIP 10.152.183.181 <none> 38080/TCP 23h
service/sv-https-portal ClusterIP 10.152.183.85 <none> 30080/TCP,30443/TCP 23h
service/sv-mariadb ClusterIP 10.152.183.137 <none> 13306/TCP 23h
nari@nariMac-mini .kube % 特に指定なしで、接続先一覧と現在の接続先を確認する。おお、いけとるやん。
nari@nariMac-mini ~ % kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* microk8s-x86 microk8s-cluster-x86 admin
nari@nariMac-mini ~ % kubectl config current-context
microk8s-x86
nari@nariMac-mini ~ % ubuntu24側のmicrok8sの中の情報が見れるか確認。
nari@nariMac-mini .kube % kubectl get nodes,services
NAME STATUS ROLES AGE VERSION
node/kubelinux Ready <none> 23h v1.31.2
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.152.183.1 <none> 443/TCP 23h
service/sv-django ClusterIP 10.152.183.181 <none> 38080/TCP 23h
service/sv-https-portal ClusterIP 10.152.183.85 <none> 30080/TCP,30443/TCP 23h
service/sv-mariadb ClusterIP 10.152.183.137 <none> 13306/TCP 23h
nari@nariMac-mini .kube % macminiのmicroks8向けの領域にdockerイメージをインポート
macはunixやから、windows側からteratermマクロ書いて処理してく。
dockerイメージとかデータは更新頻繁にやるから、手動でなんかやってられへん。
動かす材料になるのはdockerイメージとpodの永続化領域データをmacminiへ流し込んでくあたりのメモ。
前に流し込んでたのはintelのmacやから、ホスト名をkubelinuxに変更して微調整しながら使う。
teratermのマクロは書くと長くなるし、内容は細かいから割愛。
scpコピーしてくとこんな感じで転送してくれる。
コピー終わったらdockerイメージをgunzipする。
共有フォルダから直接読み込みできんかったから、いったん/rootにdockerイメージ置くことにした。
後で使うxrdpコンテナのための永続化領域を先にコピーしてアクセス権に777をつけた後、ctrのイメージ置き場にdockerイメージ流し込む。
イメージ流し込むのはけっこう重いし２０分ぐらいはかかる。UTMで振り分けたメモリ使い切りよるなぁ。
dockerイメージをctrにロードしたらこうなる。
ちゃんと入ってるやん。
永続化領域のコピー
mariadbのconf.dの定義が見えんかったことがあった。
なんでや、なんでやって考えて、書くの忘れてたことに気づいた。
chmod 777 /dataたったこれだけやけど、mariadbへのパラメータ渡せてないと、blob列に入れたpdf/jpegのロードがちゃんと動かん。
ダンプからの戻しでblob列のデータが大きいから、max_allowed_packetがきいてないとinsertのsqlでエラーになることに注意。
pv作り直してデータ流し込んでく。
mariadbのPodのロギング見たらこうなってる。１回目の起動で初期化が動くのに４０秒ぐらいかかってた。
ダンプデータはmariadbの中に２つデータベースあって、1.3GBぐらいずつある。
ダンプのロードのとき、ディスクへの書き込み完了が２０秒ぐらいかかってたことあったから、sleep入れてる。
データベースのパラメータが反映できて、ちゃんと流し込みができると、show databasesしたときに一覧が見えてくれる。
さらにレコードが入ってるのがカウントできる。
最後にPodを再作成すると、dockerコンテナに比べたら処理が遅い。
ブラウザでkubenetesのコンソール見てたら削除には２０秒以上かかることがあったし、再作成もPendingがRunningになるのに１０秒はかかる感じ。
PodにHostAliases
djangoのPodの中にあるsettigs.pyを更新。ちゃんと名前解決できるホスト名使う。
GV_CONST_HOST = 'kubelinux.intra.gavann-it.com' ⭐️宅内dnsに登録した名前使う
GV_CONST_HOST_LCL_HTTP = "http://" + GV_CONST_HOST
GV_CONST_HOST_LCL_HTTPS = "https://" + GV_CONST_HOST
GV_CONST_DOCKER_HTTPS_PORT = "30443"
GV_CONST_DOCKER_HTTP_PORT = "38080"
:
:(中略)
:
ALLOWED_HOSTS = [GV_CONST_HOST,'localhost','sv-django']
:
:(中略)
:
# django4からホスト名だけの記述は許されず「http/https」をつけることになった
# 参考URL
# https://docs.djangoproject.com/ja/4.0/releases/4.0/
CSRF_TRUSTED_ORIGINS = [
GV_CONST_HOST_LCL_HTTPS + ':' + GV_CONST_DOCKER_HTTPS_PORT,
GV_CONST_HOST_LCL_HTTP + ':' + GV_CONST_DOCKER_HTTP_PORT,
]
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 60
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
CSRF_COOKIE_SECURE = True
SECURE_HSTS_PRELOAD = Truemariadbだけやなく、djangoのPodも永続化領域流し込みながら動作確認。
djangoのPodはhttpsのPodをリバプロにしてこれも動いてくれた。
そしたら、インターネットには出れるけど宅内dnsがPodから見えてへんことに気づいた。
もー、腹立つ。
djangoのpodにある/var/log/supervisor/にあったログもPod作り直して解決してたらエラーログ捨ててしもてた。
UTMの仮想マシンから宅内DNS見えてるんやけど、kubernetesの中のDNSサービスに伝わらんのか。
ubuntu系のPodからネットワーク接続試すときはこうする。
apt install dnsutils
nslookup kubelinux.intra.gavann-it.comPodからmariadb接続試すときはこうしてた。名前解決できんから、connectあたりから後が入力できん。
apt install mariadb-client
mariadb -unari -pXXXXXXXXXX -hkubelinux.intra.gavann-it.com -P13306
connect nariDB_1st ;
show databases ;
SHOW VARIABLES LIKE 'max_allowed_packet';
SHOW tables ;
SELECT count(*) FROM GVIS_keihi ;intel-macのminikube/microk8sでは問題にならんかったんやけど、これはツラい。
Podから参照する名前をdjangoのsettings.pyに書かんと、データベース読み込みとかできんし、webアクセスの許可設定とcsrf対策の記述が通らん。
kubernetesのDNSに宅内DNS指定する方法あるんかもしれんけど、すぐには見つけられんかった。
しゃぁない、マニフェストにホスト名書くか。
kubernetesのマニフェストをdeploymentからpodに変更
HostAliasesはこんな感じで書くらしい。
hostAliases:
- ip: "192.168.1.118"
hostnames:
- "nafslinux.intra.gavann-it.com"
- ip: "192.168.1.119"
hostnames:
- "kubelinux.intra.gavann-it.com"ドキュメント読んで気づいたんやけど、Podのマニフェストに書いてある。
自分のはdeploymentで書いてる。
やってみたけどdeploymentに書いてapplyしたらエラーになるから、Podに書き換えた。
えー、これ全部のPodに書くの面倒やー。
kubernetesのDNSに任意の名前とIP書けるんかもしれんけどなぁ。とりあえず書くか。
pod用のマニフェスト作り直す
永続化領域とサービスとconfigmapのマニフェストは全部そのまま使えたけど、Pod用のはkind:deploymentって使ってたから、kind:Podに書き換え。
インデントとか注意しながら地味に書き換えた。
xrdpのpod
apiVersion: v1
kind: Pod
metadata:
name: cl-ubun
labels:
app: cl-ubun
spec:
containers:
- env:
image: save-xrdpubu:gvis-saved
name: cl-ubun
ports:
- containerPort: 3389
resources: {}
volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
- name: ubun-persistent-storage1
mountPath: /gvis
hostAliases:
- ip: "192.168.1.118"
hostnames:
- "nafslinux.intra.gavann-it.com"
- ip: "192.168.1.119"
hostnames:
- "kubelinux.intra.gavann-it.com"
hostname: clubu
restartPolicy: Always
volumes:
- name: ubun-persistent-storage1
persistentVolumeClaim:
claimName: gvis-pv-ubun-claim
# name=gvis-pv-ubun-claimを使って、マウントできるPVを探すmariadbのpod
apiVersion: v1
kind: Pod
metadata:
name: sv-mariadb
labels:
app: sv-mariadb
spec:
containers:
- env:
- name: MARIADB_DATABASE
valueFrom:
configMapKeyRef:
key: MARIADB_DATABASE
name: sv-mariadb-txt
- name: MARIADB_PASSWORD
valueFrom:
configMapKeyRef:
key: MARIADB_PASSWORD
name: sv-mariadb-txt
- name: MARIADB_ROOT_PASSWORD
valueFrom:
configMapKeyRef:
key: MARIADB_ROOT_PASSWORD
name: sv-mariadb-txt
- name: MARIADB_USER
valueFrom:
configMapKeyRef:
key: MARIADB_USER
name: sv-mariadb-txt
- name: TZ
valueFrom:
configMapKeyRef:
key: TZ
name: sv-mariadb-txt
image: mariadb:11.4-noble
name: sv-mariadb
ports:
- containerPort: 3306
resources: {}
volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
- name: mariadb-persistent-storage1
mountPath: /var/lib/mysql
- name: mariadb-persistent-storage2
mountPath: /etc/mysql/conf.d
hostAliases:
- ip: "192.168.1.118"
hostnames:
- "nafslinux.intra.gavann-it.com"
- ip: "192.168.1.119"
hostnames:
- "kubelinux.intra.gavann-it.com"
hostname: svmariadb
restartPolicy: Always
volumes:
- name: mariadb-persistent-storage1
persistentVolumeClaim:
claimName: gvis-pv-mariadb-claim
# name=gvis-pv-mariadb-claimを使って、マウントできるPVを探す
- name: mariadb-persistent-storage2
persistentVolumeClaim:
claimName: gvis-pv-mariadbconf-claim
# name=gvis-pv-mariadbconf-claimを使って、マウントできるPVを探すdjangoのpod
apiVersion: v1
kind: Pod
metadata:
name: sv-django
labels:
app: sv-django
spec:
containers:
- image: save-django:gvis-saved
name: sv-django
ports:
- containerPort: 8080
resources: {}
volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
- name: django-persistent-storage
mountPath: /code/app
hostAliases:
- ip: "192.168.1.118"
hostnames:
- "nafslinux.intra.gavann-it.com"
- ip: "192.168.1.119"
hostnames:
- "kubelinux.intra.gavann-it.com"
hostname: sv-django
restartPolicy: Always
volumes:
- name: django-persistent-storage
persistentVolumeClaim:
claimName: gvis-pv-django-uwsgi-nginx-claim
# name=gvis-pv-django-uwsgi-nginx-claimを使って、マウントできるPVを探すhttpsのpod
apiVersion: v1
kind: Pod
metadata:
labels:
app: sv-https-portal
name: sv-https-portal
spec:
containers:
- env:
- name: DOMAINS
value: kubelinux.intra.gavann-it.com -> http://sv-django:38080
- name: STAGE
value: local
- name: CLIENT_MAX_BODY_SIZE
value: 20M
image: steveltn/https-portal:1
name: sv-https-portal
ports:
- containerPort: 80
- containerPort: 443
resources: {}
volumeMounts:
- name: https-portal-persistent-storage
mountPath: /var/lib/https-portal
hostAliases:
- ip: "192.168.1.118"
hostnames:
- "nafslinux.intra.gavann-it.com"
- ip: "192.168.1.119"
hostnames:
- "kubelinux.intra.gavann-it.com"
restartPolicy: Always
volumes:
- name: https-portal-persistent-storage
persistentVolumeClaim:
claimName: gvis-pv-django-sslcerts-claim
# name=gvis-pv-django-sslcerts-claimを使って、マウントできるPVを探すPodマニフェストを反映
４つのPodを順番に起動するスクリプトを使ってる。
x86はM4の中で動くのがどうしても遅いから、Podの起動も遅い。
DBのPodが起動して３０秒ぐらい待たせてから他のPod起動させんと、DjangoのPodからデータベースの接続エラーが出る。
## -------------------------------------------------------------------------
## Script Name : 304_allPodStart.sh
## Created by : T.Naritomi
## on : 2023.07.10
## Updated by : 2024.07.13
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : change driver hyperkit -> qemu2 , minikube -> microk8s
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
EXEC_HOME=/Users/nari/Documents/personal/script # Execute Home directory
/bin/sh ${EXEC_HOME}/411_ReCreateDBpod.sh
/bin/sh ${EXEC_HOME}/413_ReCreateXRDPpod.sh
sleep 30 ⭐️これ要る
/bin/sh ${EXEC_HOME}/414_ReCreateDjangoPod.sh
/bin/sh ${EXEC_HOME}/415_ReCreateHTTPSpod.sh
exit $?Pod作る
１つだけPod再作成するとこんな感じ。pendingは１０秒ぐらいしたらrunningになる。
nari@nariMac-mini script % cat 413_ReCreateXRDPpod.sh
#!/bin/sh
## -------------------------------------------------------------------------
## Script Name : 413_ReCreateXRDPpod.sh
## Created by : T.Naritomi
## on : 2023.06.28
## Updated by : 2024.12.2
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : minikube -> microk8s
## -------------------------------------------------------------------------
KB_HOME=/Users/nari/Documents/personal/microk8s
## ---detail----------------------------------------------------------------
kubectl get pod
## kubectl delete -f ${KB_HOME}/cl-ubun-deployment.yaml
## kubectl apply -f ${KB_HOME}/cl-ubun-deployment.yaml
kubectl delete -f ${KB_HOME}/cl-ubun-pod.yaml
kubectl apply -f ${KB_HOME}/cl-ubun-pod.yaml
kubectl get pod
exit
nari@nariMac-mini script % sh ./413_ReCreateXRDPpod.sh
NAME READY STATUS RESTARTS AGE
cl-ubun 1/1 Running 0 44s
sv-django 1/1 Running 0 5m18s
sv-https-portal 1/1 Running 0 4m16s
sv-mariadb 1/1 Running 0 6m
pod "cl-ubun" deleted
pod/cl-ubun created
NAME READY STATUS RESTARTS AGE
cl-ubun 0/1 Pending 0 0s
sv-django 1/1 Running 0 5m21s
sv-https-portal 1/1 Running 0 4m19s
sv-mariadb 1/1 Running 0 6m3s
nari@nariMac-mini script % ちゃんと動いたらkubernetesのwebコンソールでもPod状態が見える。
フォワーディング
kubectlでのクラスタ操作はmacminiからやってるけど、フォワーディングはmicrok8sが動いてるノードでやる必要がある。
root@kubelinux:/microk8s/script# ls
300_kubeClusterRecreate.sh 302_kubeStart.sh 306_allForwardingStart.sh onlchk
301_kubeStop.sh 305_allForwardingStop.sh 810_aptUpdate.sh
root@kubelinux:/microk8s/script# uname -n
kubelinux
root@kubelinux:/microk8s/script# cat 306_allForwardingStart.sh
## -------------------------------------------------------------------------
## Script Name : 306_allForwardingStart.sh
## Created by : T.Naritomi
## on : 2024.12.2
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments :
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
microk8s kubectl port-forward --address 0.0.0.0 `microk8s kubectl get pod | grep mariadb | awk '{print $1}'` 13306:3306 &
microk8s kubectl port-forward --address 0.0.0.0 `microk8s kubectl get pod | grep cl-ubun | awk '{print $1}'` 33389:3389 &
microk8s kubectl port-forward --address 0.0.0.0 `microk8s kubectl get pod | grep sv-django | awk '{print $1}'` 38080:8080 &
microk8s kubectl port-forward --address 0.0.0.0 `microk8s kubectl get pod | grep sv-https | awk '{print $1}'` 30443:443 &
exit $?
root@kubelinux:/microk8s/script# sh ./306_allForwardingStart.sh
root@kubelinux:/microk8s/script# Forwarding from 0.0.0.0:38080 -> 8080
Forwarding from 0.0.0.0:13306 -> 3306
Forwarding from 0.0.0.0:33389 -> 3389
Forwarding from 0.0.0.0:30443 -> 443
root@kubelinux:/microk8s/script# フォワーディングの停止はこうする。
root@kubelinux:/microk8s/script# cat 305_allForwardingStop.sh
## -------------------------------------------------------------------------
## Script Name : 305_allForwardingStop.sh
## Created by : T.Naritomi
## on : 2024.12.2
## Updated by :
## on :
## Parameters :
## Return Code : 0=Normal End
## Comments : change driver hyperkit -> qemu2 , minikube -> microk8s
## -------------------------------------------------------------------------
## ---detail----------------------------------------------------------------
## stop port forward
ps -ef | grep kubectl | grep port-forward | grep -v dashboard | awk {'print $2'} | xargs kill -9
exit $?
root@kubelinux:/microk8s/script# x86とarm64の維持
環境を維持する理由。
intelマシンを使う理由はwindowsとかoffice使って業務したり、steamでゲームするため。
mac使うのは漢字talkの頃からユーザインターフェースが好きなのと、vscodeでの書きごととかdjangoの処理書いたり維持するため(スティーブさんお隠れになってからは、ごちゃごちゃとデザインが悪化してる気がする・・・)。
お金と時間を考えると、intelのwindowsだけあればええ。
せやけどmacを維持するのは好奇心と勉強欲を満たすためでもある。
linuxの仮想マシンの上でdocker使ってるコンテナよりも、M4にx86エミュレートさせた上でのkubernetesのPodは格段に動きが重い。
google cloudの中では、dockerfileだけではセットアップ完了ができず、手動での設定が必要なxrdpコンテナのdockerイメージをlocal linuxでも使ってる。
手動での設定ってのは、vscodeの起動オプションをショートカットに仕込むとか、ブラウザのフォント指定やセキュリティ設定とか、smb接続の認証情報のこと。
手動設定が入ったdockerイメージはx86で動くバイナリで、これをmicrok8sのctrへロードして使いたい。
業務でmacのクライアントPC使ってるとき、GKE/EKSのkubernetesのターゲットノードがx86やったら、ここに書いたような方法でテストする必要があるかも。
macminiの中でx86のエミュレートを維持するのやめてarm64のコンテナ運用に変えよかなぁ。
しばらく考えて次の挑戦考えよっと。
