minikubeを利用1-基本設定からxrdp動くPodまで

本利用しているのとは別枠で試験利用してたGCPの300ドルお試し期間が終わった。

kubernetesの環境をローカルで作ってもう少しできないかなって考えたら、minikubeって選択肢があることに気づいた。

ubuntuのvmにdocker環境作って動かしてるけど、intelのmacでコンテナ仮想化ってどうやるんやろ。

勉強のためにやってみた。

目標

まずは目標設定。イメージ湧かせましょ。

コンテナ仮想化ってのは、そもそもdockerとかcontainerdとか使う。

自分が本利用してるGCPでは、主にubuntuにdocker入れて使ってる。普段使いのドキュメントやgitもここで維持。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


+-GCE ubuntu22 linux----------+
| +-docker---------+ +--pv--+ |
| |  +-container-+ | | data | |
| |  | Django    | | |  d1  | |
| |  +-----------+ | +------+ | 
| |  +-container-+ | |      | |
| |  | mariadb   | | |  d2  | |
| |  +-----------+ | +------+ |
| |  +-container-+ | |      | |
| |  | xrdp-ubu22| | |  d3  | |
| |  +-----------+ | +------+ |
| |  +-container-+ |          |
| |  | gitlab    | |          |
| |  +-----------+ |          |
| +----------------+          |
+-----------------------------+

永続化領域のバックアップが楽にできるよう、GCEでVMホスト動かして、そのバックアップをローカルlinuxに持ってきたら即座に同じ処理が動いてる。 pv(persistent volume)をgoogle cloudからtar.gzでgoogle drive経由で抜き出して、ローカルlinuxでコピーを利用運用している。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


+-local ubuntu22 linux--------+
| +-docker---------+ +-vmdk-+ |
| |  +-container-+ | | data | |
| |  | Django    | | |  d1  | |
| |  +-----------+ | +------+ | 
| |  +-container-+ | |      | |
| |  | mariadb   | | |  d2  | |
| |  +-----------+ | +------+ |
| |  +-container-+ | |      | |
| |  | xrdp-ubu22| | |  d3  | |
| |  +-----------+ | +------+ |
| +----------------+          |
+-----------------------------+

linuxの技術やから、macではコンテナ稼働ホンマはできんはず。

けど、windowsやったらwsl使ってrancher使うと内側でlinuxが動いて、さらにその中でコンテナが動く。 rancherはwindowsで練習したしなぁ。あんまり面白なかったのは、中で動いてるubuntuの挙動がイマイチおかしかったから。

macも同じような仕組みがあって、rancherじゃなくてもhyperkit使ってminikube動かすと内側でlinuxが動いて、さらにその中でコンテナが動く。

minikube入れたらkubectlのコマンドラインの練習できる。 docker psってmacでコマンドライン叩くと、kubernetesで動くコントロールプレーンの名前っぽいコンテナが出てくる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


+-mac-----------------------------+
| +-minikube--------------------+ |
| |                             | |
| +-----------------------------+ |
| +-hyperkit--------------------+ |
| |  +-container--------------+ | |
| |  |kubernetes              | | |
| |  | kube-api               | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | etcd                   | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | kube-scheduler         | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | kube-controller-manager| | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | kube-proxy             | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | core-dns               | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | storage-provisioner    | | |
| |  +------------------------+ | |
| |  +-container--------------+ | |
| |  | dashboard-metrics      | | |
| |  +------------------------+ | |
| +-----------------------------+ |
+---------------------------------+

kubernetesはノードを複数確保して、その中でコンテナを動かす。やったことないし面白そうやん。

minikubeはhyperkitのホストをノードとして確保して、その中でコンテナを動かすんやけど、kubernetesのコントロールプレーンもコンテナで動く。

minikube dashboardって打つとダッシュボードがブラウザで見えてくれる。

kubernetesのコントロールプレーンはちゃんと解説があるけど、イマイチわかりにくいというか、スッと頭に入ってこん。

Kubernetesのコンポーネント | Kubernetes

kubernetes.io

ときどきこのサイト眺めるか。

よーし、ここに普段使いの自分のコンテナ動かせる環境やってみる。

構築

hyperkit入れる

macの内部でlinux動かす。 brewで一発で入る。昔のunixから比べたら、絵文字の入ったハデなログやなぁ。

hyperkit | minikube

minikube.sigs.k8s.io

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43



nari@gvisMac13 ~ % brew install hyperkit

Running `brew update --auto-update`...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> New Formulae
boolector                libzen                   roblox-ts                rye

You have 1 outdated formula installed.

==> Fetching dependencies for hyperkit: libev
==> Fetching libev
==> Downloading https://ghcr.io/v2/homebrew/core/libev/manifests/4.33
############################################################################################# 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/libev/blobs/sha256:6d0945ebe1bd085e597fedeee3fbcfba
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:6d0945ebe1bd085
############################################################################################# 100.0%
==> Fetching hyperkit
==> Downloading https://ghcr.io/v2/homebrew/core/hyperkit/manifests/0.20210107
############################################################################################# 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/hyperkit/blobs/sha256:3b67078315551718bc3c752b943b9
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:3b6707831555171
############################################################################################# 100.0%
==> Installing dependencies for hyperkit: libev
==> Installing hyperkit dependency: libev
==> Pouring libev--4.33.ventura.bottle.tar.gz
🍺  /usr/local/Cellar/libev/4.33: 12 files, 483.4KB
==> Installing hyperkit
==> Pouring hyperkit--0.20210107.ventura.bottle.tar.gz
🍺  /usr/local/Cellar/hyperkit/0.20210107: 5 files, 4.7MB
==> Running `brew cleanup hyperkit`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
nari@gvisMac13 ~ % which hyperkit
/usr/local/bin/hyperkit
nari@gvisMac13 ~ % hyperkit -v 
hyperkit: 0.20210107

Homepage: https://github.com/docker/hyperkit
License: BSD

nari@gvisMac13 ~ % 

hypberkitの確認

こんな感じで動いてる。

OSの種類

ホスト名がminikubeでbuildrootって種類のlinuxが動いてるんやなぁ。 2年前の2021って見えるからちょっと古い。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


nari@gvis-mac script % minikube ssh 
                         _             _            
            _         _ ( )           ( )           
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __  
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ uname -n 
minikube
$ cat /etc/os-release 
NAME=Buildroot
VERSION=2021.02.12-1-gf97079d-dirty
ID=buildroot
VERSION_ID=2021.02.12
PRETTY_NAME="Buildroot 2021.02.12"
$ 

dockerってユーザでdocker使える

もうちょっと確認してみる。一般ユーザでv20のdockerが使えるみたい。 v20はちょっと古いけど、minikubeとして使えてるんやったらええか。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


$ whoami 
docker
$ which docker 
/usr/bin/docker
$ docker version 
Client:
 Version:           20.10.23
 API version:       1.41
 Go version:        go1.18.10
 Git commit:        7155243
 Built:             Thu Jan 19 17:30:35 2023
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.23
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.10
  Git commit:       6051f14
  Built:            Thu Jan 19 17:36:08 2023
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.0
  GitCommit:        1fbd70374134b891f97ce19c70b6e50c7b9f4e0d
 runc:
  Version:          1.1.5
  GitCommit:        f19387a6bec4944c770f7668ab51c4348d9c2f38
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
$ 

動いてるプロセス

プロセスとして動いてるのはこんなん出てきた。仕組みはよー知らんけど、頑張って動いてるみたい。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


$ pstree 
systemd-+-acpid
        |-2*[agetty]
        |-12*[containerd-shim-+-pause]
        |                     `-10*[{containerd-shim}]]
        |-containerd-shim-+-kube-apiserver---9*[{kube-apiserver}]
        |                 `-11*[{containerd-shim}]
        |-containerd-shim-+-kube-controller---6*[{kube-controller}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-kube-scheduler---8*[{kube-scheduler}]
        |                 `-11*[{containerd-shim}]
        |-containerd-shim-+-etcd---9*[{etcd}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-kube-proxy---6*[{kube-proxy}]
        |                 `-11*[{containerd-shim}]
        |-containerd-shim-+-storage-provisi---6*[{storage-provisi}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-metrics-server---10*[{metrics-server}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-dashboard---6*[{dashboard}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-coredns---9*[{coredns}]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-metrics-sidecar---7*[{metrics-sidecar}]
        |                 `-11*[{containerd-shim}]
        |-2*[containerd-shim-+-pause]
        |                    `-11*[{containerd-shim}]]
        |-containerd-shim-+-mariadbd---7*[{mariadbd}]
        |                 `-11*[{containerd-shim}]
        |-containerd-shim-+-xrdp---xrdp-sesman
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-supervisord-+-nginx---4*[nginx]
        |                 |             `-uwsgi---4*[uwsgi]
        |                 `-10*[{containerd-shim}]
        |-containerd-shim-+-s6-svscan-+-2*[s6-supervise]
        |                 |           |-s6-supervise---sh-+-inotifywait
        |                 |           |                   `-sh
        |                 |           |-s6-supervise---sh---cron
        |                 |           `-s6-supervise---sh---nginx---nginx
        |                 `-11*[{containerd-shim}]
        |-cri-dockerd-+-socat
        |             `-11*[{cri-dockerd}]
        |-dbus-daemon
        |-dockerd-+-containerd---12*[{containerd}]
        |         `-36*[{dockerd}]
        |-kubelet---14*[{kubelet}]
        |-rpc.mountd
        |-rpc.statd
        |-rpcbind
        |-sshd-+-2*[sshd---sshd]
        |      `-sshd---sshd---bash---pstree
        |-systemd-journal
        |-systemd-logind
        |-systemd-network
        |-systemd-resolve
        |-systemd-timesyn---{systemd-timesyn}
        `-systemd-udevd
$ 

使い込むリソース

リソースは、この次に設定するminikubeのconfig設定で指定する。まずはディスク。あ、これはminikube入れて普段使う４つのPod起動した後に確認しているから、初期状態はもうちょっと消費が少ないかも。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


$ df -h 
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           5.1G  718M  4.4G  14% /
devtmpfs        2.7G     0  2.7G   0% /dev
tmpfs           2.9G   84K  2.9G   1% /dev/shm
tmpfs           1.2G   11M  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   19G   64G  23% /mnt/vda1
$ 

次にメモリとCPU。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


top - 21:55:46 up 39 min,  0 users,  load average: 0.29, 0.28, 0.28
Tasks: 199 total,   1 running, 198 sleeping,   0 stopped,   0 zombie
%Cpu0  :   0.0/0.7     1[|                                                                        ]
%Cpu1  :   1.4/0.7     2[||                                                                       ]
%Cpu2  :   2.1/1.4     3[|||                                                                      ]
%Cpu3  :   0.7/2.1     3[|||                                                                      ]
GiB Mem : 57.5/5.7      [                                                                         ]
GiB Swap:  0.0/0.0      [                                                                         ]

    PID USER      PR  NI    VIRT    RES  %CPU  %MEM     TIME+ S COMMAND                            
      1 root      20   0   94.3m  10.0m   0.0   0.2   0:19.10 S /sbin/init noembed norestore base  
    166 root      20   0   18.3m  10.6m   0.0   0.2   0:00.72 S  `- /usr/lib/systemd/systemd-journ+
    187 root      20   0   11.1m   6.6m   0.0   0.1   0:00.50 S  `- /usr/lib/systemd/systemd-udevd 
    194 systemd+  20   0   11.0m   6.9m   0.0   0.1   0:00.34 S  `- /usr/lib/systemd/systemd-netwo+
    236 systemd+  20   0   12.2m   8.8m   0.0   0.2   0:00.32 S  `- /usr/lib/systemd/systemd-resol+
    237 systemd+  20   0   83.5m   6.2m   0.0   0.1   0:00.29 S  `- /usr/lib/systemd/systemd-times+
    248 root      20   0    2.8m   2.0m   0.0   0.0   0:00.00 S  `- /usr/sbin/rpc.statd            
    252 root      20   0    2.3m   0.2m   0.0   0.0   0:00.00 S  `- /usr/sbin/acpid --foreground -+
    254 dbus      20   0    6.8m   3.9m   0.0   0.1   0:00.22 S  `- /usr/bin/dbus-daemon --system +
    260 root      20   0    3.6m   2.4m   0.0   0.0   0:00.00 S  `- /sbin/agetty -o -p -- \u --noc+
    271 root      20   0    3.6m   2.3m   0.0   0.0   0:00.00 S  `- /sbin/agetty -o -p -- \u --kee+
    278 root      20   0    9.9m   5.9m   0.0   0.1   0:00.85 S  `- /usr/lib/systemd/systemd-logind
    279 root      20   0    3.8m   2.2m   0.0   0.0   0:00.00 S  `- /usr/sbin/rpcbind              
    290 root      20   0    2.9m   0.3m   0.0   0.0   0:00.00 S  `- /usr/sbin/rpc.mountd           
    331 root      20   0    7.2m   5.2m   0.0   0.1   0:00.01 S  `- sshd: /usr/sbin/sshd -D -e [li+
   2226 root      20   0    8.0m   5.9m   0.0   0.1   0:00.01 S      `- sshd: docker [priv]        
   2240 docker    20   0    8.2m   4.2m   0.0   0.1   0:00.00 S          `- sshd: docker@notty     
   9328 root      20   0    8.0m   5.9m   0.0   0.1   0:00.00 S      `- sshd: docker [priv]        
   9330 docker    20   0    8.2m   4.0m   0.0   0.1   0:00.00 S          `- sshd: docker@notty     
  15970 root      20   0    8.2m   6.0m   0.0   0.1   0:00.00 S      `- sshd: docker [priv]        
  15972 docker    20   0    8.2m   4.1m   0.0   0.1   0:00.13 S          `- sshd: docker@pts/0     
  15973 docker    20   0    4.1m   3.4m   0.0   0.1   0:00.02 S              `- -bash              
  57377 docker    20   0    5.9m   3.6m   0.0   0.1   0:00.25 R                  `- top            
    868 root      20   0 3011.3m  77.7m   2.6   1.3   1:04.38 S  `- /usr/bin/dockerd -H tcp://0.0.+
    875 root      20   0 1620.2m  56.7m   0.0   1.0   0:16.98 S      `- containerd --config /var/r+
   1092 root      20   0  737.6m  48.8m   2.6   0.8   0:49.45 S  `- /usr/bin/cri-dockerd --contain+
   7172 root      20   0    6.4m   3.2m   0.0   0.1   0:00.04 S      `- /usr/bin/socat - TCP4:loca+
   1341 root      20   0 1824.8m 106.3m   3.3   1.8   1:18.70 S  `- /var/lib/minikube/binaries/v1.+
   1610 root      20   0  706.6m  12.9m   0.0   0.2   0:00.27 S  `- /usr/bin/containerd-shim-runc-+
   1688 65535     20   0    1.0m   0.0m   0.0   0.0   0:00.18 S      `- /pause

minikube入れる

これもbrew使って一発で入る。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


nari@gvisMac13 script % brew install minikube
==> Fetching dependencies for minikube: kubernetes-cli
==> Fetching kubernetes-cli
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/manifests/1.27.2
############################################################################################# 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/blobs/sha256:46038d7527fea8a314a9e94
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:46038d7527fea8a
############################################################################################# 100.0%
==> Fetching minikube
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/manifests/1.30.1
############################################################################################# 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/minikube/blobs/sha256:0a74440415ff5881db92af6c85aa1
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:0a74440415ff588
############################################################################################# 100.0%
==> Installing dependencies for minikube: kubernetes-cli
==> Installing minikube dependency: kubernetes-cli
==> Pouring kubernetes-cli--1.27.2.ventura.bottle.tar.gz
🍺  /usr/local/Cellar/kubernetes-cli/1.27.2: 230 files, 59.2MB
==> Installing minikube
==> Pouring minikube--1.30.1.ventura.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
==> Summary
🍺  /usr/local/Cellar/minikube/1.30.1: 9 files, 81.1MB
==> Running `brew cleanup minikube`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Caveats
==> minikube
zsh completions have been installed to:
  /usr/local/share/zsh/site-functions
nari@gvisMac13 script % which minikube
/usr/local/bin/minikube
nari@gvisMac13 script % 

minikube設定してく

hyperkitに割り当てるcpuとメモリを指定できるらしいからやっとく。

最初にディスクのサイズ指定忘れた。そしたら20GBぐらいしか確保してくれんかったから、hyperkitの中でmariadbのPod作った後、ディスクの容量不足になってもた。

ディスク領域不足になると、docker build -t xxx:xxx -f Dockerfile .とかビルドするときにわけわかめなエラーが出てディスクが足りんことに気づいた。ちゃんとディスクも考えとかなアカン。

最終的にはビルドをここではせんようにしたから、50GBぐらいにしといてええかも。

minikubeの初期設定

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


nari@gvisMac13 script % minikube config view 
nari@gvisMac13 script % minikube config set cpus 4
❗  これらの変更は minikube delete の後に minikube start を実行すると反映されます
nari@gvisMac13 script % minikube config set memory 6000
❗  これらの変更は minikube delete の後に minikube start を実行すると反映されます
nari@gvisMac13 script % minikube config set disk-size 100GB
❗  これらの変更は minikube delete の後に minikube start を実行すると反映されます
nari@gvisMac13 script % minikube config set driver hyperkit
❗  これらの変更は minikube delete の後に minikube start を実行すると反映されます
nari@gvisMac13 script % minikube config view 
- cpus: 4
- disk-size: 100GB
- driver: hyperkit
- memory: 6000
nari@gvisMac13 script % 

minikubeでクラスタ作る。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


nari@gvisMac13 script % minikube start 
😄  Darwin 13.4 上の minikube v1.30.1
✨  ユーザーの設定に基づいて hyperkit ドライバーを使用します
👍  minikube クラスター中のコントロールプレーンの minikube ノードを起動しています
🔥  hyperkit VM (CPUs=4, Memory=6000MB, Disk=20000MB) を作成しています...
🐳  Docker 20.10.23 で Kubernetes v1.26.3 を準備しています...
    ▪ 証明書と鍵を作成しています...
    ▪ コントロールプレーンを起動しています...
    ▪ RBAC のルールを設定中です...
🔗  bridge CNI (コンテナーネットワークインターフェース) を設定中です...
    ▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🔎  Kubernetes コンポーネントを検証しています...
🌟  有効なアドオン: storage-provisioner, default-storageclass
🏄  終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
nari@gvisMac13 script % 

minikubeの設定確認

kubectlでコンテキストを確認。あ、この前gkeのお試ししたときのコンテキストが残ってた。もう潰したから後で消しとこ。

1
2
3
4
5
6


nari@gvisMac13 script % kubectl config get-contexts 
CURRENT   NAME                                          CLUSTER                                       AUTHINFO                                      NAMESPACE
          gke_fourth-elixir-383118_us-central1-a_blog   gke_fourth-elixir-383118_us-central1-a_blog   gke_fourth-elixir-383118_us-central1-a_blog   
          gke_fourth-elixir-383118_us-central1-c_blog   gke_fourth-elixir-383118_us-central1-c_blog   gke_fourth-elixir-383118_us-central1-c_blog   
*         minikube                                      minikube                                      minikube                                      default
nari@gvisMac13 script % 

kubectlでPodを確認。クラスタ作ったとこなんやから、そらなんもないわな。

1
2


nari@gvisMac13 script % kubectl get po
No resources found in default namespace.

minikubeのシステムPodを確認。昔に本読んだときにdns/etc/proxyとかシステムPodの話読んだことあったな。こうやって動いてるんやなぁ。

起動直後、コマンドラインの結果見てると、STATUSがエラーになってる。リソースとか起動順序とかあるんやろな。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


nari@gvisMac13 script % kubectl get pod -n kube-system 
NAME                               READY   STATUS    RESTARTS        AGE
coredns-787d4945fb-pflhh           0/1     Error     1               84m
etcd-minikube                      0/1     Running   2 (2m50s ago)   85m
kube-apiserver-minikube            1/1     Running   1 (8m59s ago)   85m
kube-controller-manager-minikube   0/1     Running   2 (2m50s ago)   85m
kube-proxy-dv6r4                   0/1     Error     1               84m
kube-scheduler-minikube            1/1     Running   1 (10m ago)     85m
storage-provisioner                0/1     Error     1               85m
nari@gvisMac13 script % 

そのうち健気にRunningになる。自律的にステータスを正常にしてくれるってのはこういうことなんかな。ある意味とても粘着質なシステムで、めっちゃネバって起動してくる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


nari@gvisMac13 script % kubectl get pod -n kube-system 
NAME                               READY   STATUS    RESTARTS        AGE
coredns-787d4945fb-pflhh           1/1     Running   2 (119s ago)    86m
etcd-minikube                      1/1     Running   2 (4m22s ago)   86m
kube-apiserver-minikube            1/1     Running   2 (119s ago)    86m
kube-controller-manager-minikube   1/1     Running   2 (4m22s ago)   86m
kube-proxy-dv6r4                   1/1     Running   2 (4m22s ago)   86m
kube-scheduler-minikube            1/1     Running   2 (4m22s ago)   86m
storage-provisioner                1/1     Running   3 (63s ago)     86m
nari@gvisMac13 script % 

minikubeの停止。普通にとまる。

1
2
3
4


nari@gvisMac13 script % minikube stop 
✋  「minikube」ノードを停止しています...
🛑  1 台のノードが停止しました。
nari@gvisMac13 script % 

minikubeのバージョン確認

brewがなんとかしてくれるんかな。最初はminikubeのバージョンをkubernetesのバージョンと勘違いしてた。

1
2
3
4


nari@gvisMac13 minikube % minikube version 
minikube version: v1.30.1
commit: 08896fd1dc362c097c925146c4a0d0dac715ace0
nari@gvisMac13 minikube % 

minikubeで使えるバージョンの確認。

1
2
3
4


nari@gvisMac13 minikube % minikube update-check 
CurrentVersion: v1.30.1
LatestVersion: v1.30.1
nari@gvisMac13 minikube % 

kubernetesのバージョンリリースも公開されているから、気づいたらアップデートするかな。アップデートしたら、クラスタとか作り直しになって全部消えるんかなぁ。

Releases | Kubernetes

kubernetes.io

GoogleのGKE関連リリース予定に追随してく必要があったかなぁ。

GKE リリーススケジュール | Google Kubernetes Engine (GKE) | Google Cloud

cloud.google.com

使ったことないけど、AWSのkubernetes(EKS)にもリリース予定ってのがあるらしい。

EKS の Kubernetes バージョンライフサイクルを理解する - Amazon EKS

docs.aws.amazon.com

minikubeの中のkubernetesクラスタバージョン確認

minikubeでkubernetesバージョン指定しての起動。 2023年6月は1.27.2が最新らしい。今作ったクラスタいったん潰して作ってみた。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


nari@gvisMac13 script % minikube start --kubernetes-version v1.27.2
😄  Darwin 13.4 上の minikube v1.30.1
    ▪ MINIKUBE_ACTIVE_DOCKERD=minikube
❗  指定された Kubernetes バージョン 1.27.2 はサポートされた最新バージョン v1.27.0-rc.0 より新しいです。詳細は `minikube config defaults kubernetes-version` を使用してください。
✨  ユーザーの設定に基づいて hyperkit ドライバーを使用します
👍  minikube クラスター中のコントロールプレーンの minikube ノードを起動しています
💾  ロード済み Kubernetes v1.27.2 をダウンロードしています...
    > preloaded-images-k8s-v18-v1...:  393.16 MiB / 393.16 MiB  100.00% 30.22 M
🔥  hyperkit VM (CPUs=4, Memory=6000MB, Disk=20000MB) を作成しています...
🐳  Docker 20.10.23 で Kubernetes v1.27.2 を準備しています...
    ▪ 証明書と鍵を作成しています...
    ▪ コントロールプレーンを起動しています...
    ▪ RBAC のルールを設定中です...
🔗  bridge CNI (コンテナーネットワークインターフェース) を設定中です...
    ▪ gcr.io/k8s-minikube/storage-provisioner:v5 イメージを使用しています
🔎  Kubernetes コンポーネントを検証しています...
🌟  有効なアドオン: storage-provisioner, default-storageclass
🏄  終了しました！kubectl がデフォルトで「minikube」クラスターと「default」ネームスペースを使用するよう設定されました
nari@gvisMac13 script % 

んんん？　1.27.2の指定アカンの？

途中に書いてあるminikube config defaults kubernetes-versionを試してみる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


nari@gvisMac13 script % minikube config defaults kubernetes-version
* 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.5
:(中略)
* v1.16.14
* v1.16.13
nari@gvisMac13 script %

なんやねん、alpha/betaとrc.0しかあらへん。しゃーないから1.26.5使うかぁ。

docker psするとなんとなく見えるんやけど、minikubeのシステムPodはコンテナ。

minikubeの上げ下げしたり、特にクラスタのバージョン切り替えると、exited状態のコンテナがいっぱいできる。気持ち悪いからdocker system pruneでときどきガサっと消す。

最終的には４つのPodを稼働させるようにしたんやけど、dockerイメージやらデータベースとかでディスクが50GBぐらい増えた。別ホストで動かしてるlinuxのdocker-ceは９つのコンテナ動かして40GBぐらい使ってるから、minikubeのほうがディスク使い込み多い感じ。

ディスクのコストはminikubeのほうが高くつく気がする。

macに入れたkubectlのバージョン確認

クライアント側はbrewがバージョン管理してくれる。サーバ側はminikubeのコマンドラインで指定した1.26.5が見える。 json以外にyamlが指定できる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


nari@gvisMac13 script % which kubectl
/usr/local/bin/kubectl
nari@gvisMac13 script % kubectl version --output=json
{
  "clientVersion": {
    "major": "1",
    "minor": "27",
    "gitVersion": "v1.27.2",
    "gitCommit": "7f6f68fdabc4df88cfea2dcf9a19b2b830f1e647",
    "gitTreeState": "clean",
    "buildDate": "2023-05-17T14:13:27Z",
    "goVersion": "go1.20.4",
    "compiler": "gc",
    "platform": "darwin/amd64"
  },
  "kustomizeVersion": "v5.0.1",
  "serverVersion": {
    "major": "1",
    "minor": "26",
    "gitVersion": "v1.26.5",
    "gitCommit": "890a139214b4de1f01543d15003b5bda71aae9c7",
    "gitTreeState": "clean",
    "buildDate": "2023-05-17T14:08:49Z",
    "goVersion": "go1.19.9",
    "compiler": "gc",
    "platform": "linux/amd64"
  }
}
nari@gvisMac13 script % 

やってて思い出した。 kubectlってよー考えたら、kubenetesのクラスタのマイナーバージョンの１つ差までしか扱えんはず。

Install and Set Up kubectl on macOS | Kubernetes

kubernetes.io

ページの最初のほうに書いてあるやん。

You must use a kubectl version that is within one minor version difference of your cluster.

バージョン1.27のkubectlやから、1.26/1.27/1.28のクラスタを使わなアカン。

安定版のkubectlバージョン確認してみる。

storage.googleapis.com

2023年6月の時点ではv1.27.2って書いてあった。このへんの意識忘れそうやな。

予定はこのへんに書いてある。毎月リリースあるねんな。

Patch Releases | Kubernetes

kubernetes.io

minikube dashboardでブラウザに状態表示させる

裏側でコンテナ起動してるんやろなぁ。

これ動かすとブラウザが起動してコマンドライン戻ってこん。 minikube dashboard &ってコマンドライン戻るようにして普段は使う。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


nari@gvisMac13 script % minikube dashboard
🔌  ダッシュボードを有効化しています...
    ▪ docker.io/kubernetesui/metrics-scraper:v1.0.8 イメージを使用しています
    ▪ docker.io/kubernetesui/dashboard:v2.7.0 イメージを使用しています
💡  いくつかのダッシュボード機能は metrics-server アドオンを必要とします。全機能を有効にするためには、次のコマンドを実行します:

	minikube addons enable metrics-server	


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

先にxrdp使えるPod作る

一番最初にubuntuのPod作った。

apt-getでvi入れてみて動くのはわかったけど、次の日に続きをやろうと思ったら、docker imageから読み直して起動するからインストールしたviが吹っ飛んでた。 minikubeは本体も含めてPodをイメージから全部作り直すから、当たり前っちゃ当たり前。

docker commitしてイメージ書き換えたらええんやけど、他にも色々動作確認のためにapt-getしたかったから、思い切ってxrdpで接続できるPodを先に用意することにした。最初は地味にapt-getしてみたけど手間もcpuも時間もかかるから、ローカルlinuxのホストにあるdockerイメージをsaveして、minikube側のイメージ置き場にloadするようにした。

ubuntuはアップデート多いし、apt-getしてモジュールを最新に維持してるのはローカルlinux側で全部やってる。同じことをminikube側のPodでやらずに済む。

ローカルlinuxホストからxrdpのdockerイメージを持ってくる

xrdpのコンテナはローカルlinuxホストのubuntu22でxrdpできるようにコンテナを作ってある。

Dockerでubuntu22のリモートデスクトップ接続できるコンテナ | ギャバンITサービス

gavann-it.com

このコンテナをminikube環境に作れば、他のPodと疎通して使えるはず。ローカルLANのdnsでも名前引きできるから、ファイルサーバも見えるしもちろんインターネットも使えるから、google driveとかも見える。

ping/traceroute/mysqlとか使いたいから、ローカルlinuxのイメージ置き場のxrdpコンテナにはいろいろ入ってる。 minikubeの中のk8sでポッドの間で通信させるときの動作確認に使う。

docker saveする

一番大きなイメージのgvis-ubu22を持ってくるようにする。 4.21GBはデカいけどlibreofficeとか入ってるからしゃぁないな。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


nari@nafslinux-ubu22:/gvis/script$ docker images 
REPOSITORY              TAG          IMAGE ID       CREATED        SIZE
gvis-ubu22              22gvis       d5adaeccf522   5 weeks ago    4.21GB
docker-sv_jupyter       latest       e61364c20d0d   6 weeks ago    2.39GB
mariadb                 1011         6ecdf17c5041   3 months ago   401MB
redhat                  9gvis        c2b62fa45060   4 months ago   1.89GB
redhat                  8gvis        fcd55437f494   4 months ago   1.29GB
ubu                     22gvis       ef0ea8ffe7e1   4 months ago   1.2GB
sv_django               4            37a493125043   4 months ago   954MB
steveltn/https-portal   1            52ea65ae915a   5 months ago   348MB
osixia/phpldapadmin     latest       dbb580facde3   2 years ago    309MB
osixia/openldap         latest       31d1d6e16394   2 years ago    257MB
mariadb                 10.5.7       1b3986d60f13   2 years ago    414MB
nari@nafslinux-ubu22:/gvis/script$ 

xrdp以外にmariadbとjupyterもイメージ取り出すよう小さくスクリプト書いとく。これで定期的に取り出して、minikube側に取り込んで使う。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


GV_IM01=save-mariadb
GV_IM02=save-xrdpubu22
GV_IM03=save-jupyter
GV_IM04=save-django

GV_TAG=gvis-saved
GV_SAVEDIR=/docker/DockerImages/

docker rmi ${GV_IM01}:${GV_TAG}
docker rmi ${GV_IM02}:${GV_TAG}
docker rmi ${GV_IM03}:${GV_TAG}
docker rmi ${GV_IM04}:${GV_TAG}

docker commit `docker ps --format "table {{.Names}}" | grep mariadb`   ${GV_IM01}:${GV_TAG} 
docker commit `docker ps --format "table {{.Names}}" | grep ubu22gvis` ${GV_IM02}:${GV_TAG} 
docker commit `docker ps --format "table {{.Names}}" | grep jupyter`   ${GV_IM03}:${GV_TAG}
docker commit `docker ps --format "table {{.Names}}" | grep django`    ${GV_IM04}:${GV_TAG}

docker save ${GV_IM01}:${GV_TAG} | gzip > ${GV_SAVEDIR}${GV_IM01}.tar.gz 
docker save ${GV_IM02}:${GV_TAG} | gzip > ${GV_SAVEDIR}${GV_IM02}.tar.gz 
docker save ${GV_IM03}:${GV_TAG} | gzip > ${GV_SAVEDIR}${GV_IM03}.tar.gz 
docker save ${GV_IM04}:${GV_TAG} | gzip > ${GV_SAVEDIR}${GV_IM04}.tar.gz 


ls -lh ${GV_SAVEDIR}

exit

イメージをファイルに書き出すとき、普通にやるとtarファイルができてくる。

tarはtape archiveの略やったと思うんやけど、なんでtarするだけやねん。後の方でdocker saveした結果はgzipさせてる。

最初はgzipしてへんかったけど、gz作るように書き換えた。 saveした結果はこんな感じでtarなしのと見比べるとこんな感じ。2〜3倍サイズが変わるやん。

1
2
3
4
5
6
7
8
9


nari@nafslinux-ubu22:/docker/nariDockerDat/cl_nari/DockerImages$ ls -lh
合計 12G
-rw------- 1 nari docker 2.3G  6月 28 05:11 save-jupyter.tar
-rw-r--r-- 1 nari docker 812M  7月  3 06:42 save-jupyter.tar.gz
-rw------- 1 nari docker 389M  6月 28 05:09 save-mariadb.tar
-rw-r--r-- 1 nari docker 115M  7月  3 06:36 save-mariadb.tar.gz
-rw------- 1 nari docker 5.9G  6月 28 05:10 save-xrdpubu22.tar
-rw-r--r-- 1 nari docker 2.5G  7月  3 06:40 save-xrdpubu22.tar.gz
nari@nafslinux-ubu22:/docker/nariDockerDat/cl_nari/DockerImages$ 

docker loadする

tera termのマクロを軽く書いておいて、ローカルlinuxで作ったイメージファイルをコピーしてminikube側へ持ってくる。

ローカルlinuxの永続化領域はMドライブとしてsmb共有してるから、それをscp使ってコピーさせる
scpでコピーした先はhyperkitの中では/minikubeMacとして見えてるから、minikube sshしてから/dataのpvにコピー
hyperkitの中でdocker loadさせるとローカルlinuxで動いてるコンテナのイメージがそのまんま動く

だいたいこんな感じ。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91


include 'Y:\94_connect\connect\teraIni\gvis.ini'

SOURFILE1 = 'M:\DockerImages\save-jupyter.tar.gz' 
DESTFILE1 = '/Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save-jupyter.tar.gz' 

SOURFILE2 = 'M:\DockerImages\save-mariadb.tar.gz' 
DESTFILE2 = '/Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save-mariadb.tar.gz' 

SOURFILE3 = 'M:\DockerImages\save-xrdpubu22.tar.gz' 
DESTFILE3 = '/Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save-xrdpubu22.tar.gz' 

SOURFILE4 = 'M:\DockerImages\save-django.tar.gz' 
DESTFILE4 = '/Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save-django.tar.gz' 


; --- 接続 --------------
 conSTR = '192.168.1.117 /ssh /2 /auth=password /user=nari /passwd='
 strconcat conSTR gvis_macP
 strconcat conSTR ' /F='
 strconcat conSTR gvis_iPTH
 strconcat conSTR 'gray.INI '
 strconcat conSTR '/timeout='
 strconcat conSTR gvis_TOUT

; ---debug --------------
; messagebox conSTR 'info'

 connect conSTR
 if result <> 2 goto end

wait "%"
sendln 'rm -f /Users/nari/Documents/personal/minikube/nariDockerDat/DockerImages/save*'

wait "nari@gvis-mac ~ %"
scpsend SOURFILE1 DESTFILE1 
scpsend SOURFILE2 DESTFILE2 
scpsend SOURFILE3 DESTFILE3 
scpsend SOURFILE4 DESTFILE4 

;; ファイル送信プロセスの確認
do
  mpause 5000
  sprintf2 str 'ps -ef |grep -v grep |grep -c scp'
  sendln str
  waitln '0' '1'
loop while result != 1
;; ファイル送信が完了すると次のマクロ動かす
sendln 'echo SCP finish'

wait "%"
sendln 'min'

wait "%"
sendln 'minikube ssh'

wait "$"
sendln 'cd /minikubeMac/nariDockerDat/DockerImages/'

wait "$"
sendln 'gunzip save-jupyter.tar.gz'

wait "$"
sendln 'gunzip save-mariadb.tar.gz'

wait "$"
sendln 'gunzip save-xrdpubu22.tar.gz'

wait "$"
sendln 'gunzip save-django.tar.gz'


wait "$"
sendln 'docker load < ./save-jupyter.tar'

wait "$"
sendln 'docker load < ./save-mariadb.tar'

wait "$"
sendln 'docker load < ./save-xrdpubu22.tar'

wait "$"
sendln 'docker load < ./save-django.tar'


wait "$"
sendln 'rm -f ./save*'

; wait gvis_wS7
; sendln 'exit'

end

使うとscpが始まる。

gvis-minikubeStart

docker saveが終わったらこうなる。 10分ぐらいで終わる。

1
2
3


nari@gvis-mac script % docker images | grep ubu
save-xrdpubu22                                  gvis-saved   2ce64510de95   25 hours ago    6.22GB
nari@gvis-mac script % 

xrdpするPodのためにマニフェスト用意する

マニフェストを定義してPodのふるまいが決まる。

deploymentのマニフェスト

さっきのtera termマクロに書いておいたcl-ubun22-deployment.yamlの定義。

Deploymentを初めて作った。書き方というか、段落とか定義する内容は厳しめ。

kubernetesの本家サイトにある書き方を見て作ってみた。 imageってとこにさっき用意したdockerイメージの名前を書いて使う。

稼働させるときはkubectl create -f cl-ubun22-deployment.yamlってやっとく。 minikube起動させたら勝手に動き出す。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42



# 参考URL
#   https://qiita.com/witchy/items/3a39b674097b86a44546

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cl-ubun22
  labels:
    app: cl-ubun22
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cl-ubun22
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: cl-ubun22
    spec:
      containers:
        - env:
          image: save-xrdpubu22:gvis-saved
          name: cl-ubun22
          ports:
            - containerPort: 3389
          resources: {}

          volumeMounts: # コンテナ内のどのディレクトリにpersistentVolumeをマウントするか
            - name: ubun22-persistent-storage1
              mountPath: /gvis

      hostname: clubu22
      restartPolicy: Always

      volumes:
      - name: ubun22-persistent-storage1
        persistentVolumeClaim:
          claimName: gvis-pv-ubun22-claim
          # name=gvis-pv-ubun22-claimを使って、マウントできるPVを探す

永続化領域(Persistent Volume)のためのマニフェスト

小振りでええから永続化領域使いたかったから、minikube sshしたときのhyperkit内にある/dataフォルダにデータを作るようにPersistent Volume使う設定にしてる。

この領域あったら簡単なデータ置き場には使える。

使うときはkubectl create -f gvis-PersistentVol-ubun22.yamlとか先にやってからdeploymentのポッドに参照させる。１回反映させても/dataには何にもできんけど、deploymentを作って使い始めるとフォルダが作られる。 linuxホストにあるsmb領域にバックアップしとけば内容維持できる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


# 参考URL
#   https://kubernetes.io/ja/docs/setup/learning-environment/minikube/
#   
#   MinikubeのVMはtmpfsで起動するため、ほとんどのディレクトリーは再起動しても持続しません (minikube stop)。 
#   しかし、Minikubeは以下のホストディレクトリーに保存されているファイルを保持するように設定されています:
#    /data
#    /var/lib/minikube
#    /var/lib/docker
#
#   https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes
#   https://qiita.com/witchy/items/3a39b674097b86a44546
#   https://qiita.com/ysakashita/items/924786aa24ef3bb864ef
#

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

deployment反映してデータ置いてからminikube sshするとこうなる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


nari@gvis-mac minikube % sc
nari@gvis-mac script % minikube ssh 
                         _             _            
            _         _ ( )           ( )           
  ___ ___  (_)  ___  (_)| |/')  _   _ | |_      __  
/' _ ` _ `\| |/' _ `\| || , <  ( ) ( )| '_`\  /'__`\
| ( ) ( ) || || ( ) || || |\`\ | (_) || |_) )(  ___/
(_) (_) (_)(_)(_) (_)(_)(_) (_)`\___/'(_,__/'`\____)

$ cd /data/gvis-pv-ubun22/
$ ls -l
total 12
drwx------ 2 docker docker 4096 Jun 27 17:24 _old
drwx------ 5 docker docker 4096 Jul  3 05:43 download
drwx------ 2 docker docker 4096 Jun 27 17:24 script
$

常用したい処理をscriptに置いとけるし、downloadにデータ残しとける。

ローカルLANからminikubeのPodへ接続できるように

GKEだとロードバランサをPodに紐づけてエンドポイントみたいなのを作る。

minikubeはコンテナのポートフォワードができるから、そっち使う。

こういうスクリプトを書いておいたら、即つながる。 statefulsetやと名前を維持できるんやけど、deploymentのPodの名前はminikubeの起動ごとに変わるから、kubectl get poした結果をgrepとawkで引っ掛けてる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18



#!/bin/sh
## -------------------------------------------------------------------------
## Script Name  : 304_PortForwardPod.sh
##  Created by  : T.Naritomi
##          on  : 2023.06.20
##  Updated by  : 
##          on  :
##  Parameters  : 
##  Return Code : 0=Normal End
##     Comments : https://udomomo.hatenablog.com/entry/2020/11/01/235612
## -------------------------------------------------------------------------

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

kubectl port-forward --address 0.0.0.0 `kubectl get pod | grep cl-ubun22 | awk '{print $1}'` 33389:3389

exit

windowsホストからminikubeのPodへrdp接続するとこうなる。

ローカルlinuxのdockerコンテナでcommitした状態から、docker saveしたものをminikubeでdocker loadしてるのでvscodeもプラグイン維持されて持ってこれてる。

gvis-minikubeStart

いったん完成

完全に完成したわけやないけど、いったん練習で作ったもんはこんな感じで動いた。

次はmariadbとdjangoのコンテナもPodにして入れるかな。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


+-mac----------------+
| +-minikube-------+ |
| |                | |
| +----------------+ |
| +-hyperkit-------+ |
| |  +-container-+ | |
| |  | kubernetes| | |
| |  +-----------+ | |
| |  +-container-+ | |
| |  | xrdp      | | |
| |  +-----------+ | |
| +----------------+ |
+--------------------+

実際の稼働画面はこんな感じ。

gvis-minikubeStart

事前に調べて読んだとこ

どうやればできっかなぁって読ませてもらったサイト。作者さんありがとう。

参考URL：

https://blog.kondoumh.com/entry/2019/10/05/090944

https://minikube.sigs.k8s.io/docs/drivers/hyperkit/

https://ottan.jp/posts/2021/09/993782180/

https://zenn.dev/korosuke613/scraps/d4e81c5a5fab74

https://unicorn.limited/jp/rd/kubernetes/20180420-minikube-config.html

https://qiita.com/satto_sann/items/188dc5750c6d821b3004

https://qiita.com/pu_ri/items/75c80e388c79fe0d3f0b

お菓子の家が作れるシステムエンジニアです

目標#

構築#

hyperkit入れる#

hypberkitの確認#

OSの種類#

dockerってユーザでdocker使える#

動いてるプロセス#

使い込むリソース#

minikube入れる#

minikube設定してく#

minikubeの初期設定#

minikubeの設定確認#

minikubeのバージョン確認#

minikubeの中のkubernetesクラスタバージョン確認#

macに入れたkubectlのバージョン確認#

minikube dashboardでブラウザに状態表示させる#

先にxrdp使えるPod作る#

ローカルlinuxホストからxrdpのdockerイメージを持ってくる#

docker saveする#

docker loadする#

xrdpするPodのためにマニフェスト用意する#

deploymentのマニフェスト#

永続化領域(Persistent Volume)のためのマニフェスト#

ローカルLANからminikubeのPodへ接続できるように#

いったん完成#

事前に調べて読んだとこ#

目標

構築

hyperkit入れる

hypberkitの確認

OSの種類

dockerってユーザでdocker使える

動いてるプロセス

使い込むリソース

minikube入れる

minikube設定してく

minikubeの初期設定

minikubeの設定確認

minikubeのバージョン確認

minikubeの中のkubernetesクラスタバージョン確認

macに入れたkubectlのバージョン確認

minikube dashboardでブラウザに状態表示させる

先にxrdp使えるPod作る

ローカルlinuxホストからxrdpのdockerイメージを持ってくる

docker saveする

docker loadする

xrdpするPodのためにマニフェスト用意する

deploymentのマニフェスト

永続化領域(Persistent Volume)のためのマニフェスト

ローカルLANからminikubeのPodへ接続できるように

いったん完成

事前に調べて読んだとこ