本利用しているのとは別枠で試験利用してたGCPの300ドルお試し期間が終わった。
kubernetesの環境をローカルで作ってもう少しできないかなって考えたら、minikubeって選択肢があることに気づいた。
ubuntuのvmにdocker環境作って動かしてるけど、intelのmacでコンテナ仮想化ってどうやるんやろ。
勉強のためにやってみた。
目標
まずは目標設定。
イメージ湧かせましょ。
コンテナ仮想化ってのは、そもそもdockerとかcontainerdとか使う。
自分が本利用してるGCPでは、主にubuntuにdocker入れて使ってる。
普段使いのドキュメントやgitもここで維持。
+-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でコピーを利用運用している。
+-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で動くコントロールプレーンの名前っぽいコンテナが出てくる。
+-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
Overview HyperKit is an open-source hypervisor for macOS hypervisor, optimized for lightweight virtual machines and cont...
minikube.sigs.k8s.io
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って見えるからちょっと古い。
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として使えてるんやったらええか。
$ 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 $
動いてるプロセス
プロセスとして動いてるのはこんなん出てきた。
仕組みはよー知らんけど、頑張って動いてるみたい。
$ 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起動した後に確認しているから、初期状態はもうちょっと消費が少ないかも。
$ 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。
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使って一発で入る。
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の初期設定
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でクラスタ作る。
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のお試ししたときのコンテキストが残ってた。
もう潰したから後で消しとこ。
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を確認。
クラスタ作ったとこなんやから、そらなんもないわな。
nari@gvisMac13 script % kubectl get po No resources found in default namespace.
minikubeのシステムPodを確認。
昔に本読んだときにdns/etc/proxyとかシステムPodの話読んだことあったな。
こうやって動いてるんやなぁ。
起動直後、コマンドラインの結果見てると、STATUSがエラーになってる。
リソースとか起動順序とかあるんやろな。
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になる。自律的にステータスを正常にしてくれるってのはこういうことなんかな。
ある意味とても粘着質なシステムで、めっちゃネバって起動してくる。
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の停止。
普通にとまる。
nari@gvisMac13 script % minikube stop ✋ 「minikube」ノードを停止しています... 🛑 1 台のノードが停止しました。 nari@gvisMac13 script %
minikubeのバージョン確認
brewがなんとかしてくれるんかな。
最初はminikubeのバージョンをkubernetesのバージョンと勘違いしてた。
nari@gvisMac13 minikube % minikube version minikube version: v1.30.1 commit: 08896fd1dc362c097c925146c4a0d0dac715ace0 nari@gvisMac13 minikube %
minikubeで使えるバージョンの確認。
nari@gvisMac13 minikube % minikube update-check CurrentVersion: v1.30.1 LatestVersion: v1.30.1 nari@gvisMac13 minikube %
kubernetesのバージョンリリースも公開されているから、気づいたらアップデートするかな。
アップデートしたら、クラスタとか作り直しになって全部消えるんかなぁ。
Releases
The Kubernetes project maintains release branches for the most recent three minor releases (1.31, 1.30, 1.29). Kubernete...
kubernetes.io
GoogleのGKE関連リリース予定に追随してく必要があったかなぁ。
GKE リリース スケジュール | Google Kubernetes Engine (GKE) | Google Cloud
GKE のおおよそのリリース スケジュール。マイナー バージョンの自動アップグレードとサポート終了（EOL）の日付も示されています。
cloud.google.com
使ったことないけど、AWSのkubernetes(EKS)にもリリース予定ってのがあるらしい。
EKS の Kubernetes バージョンライフサイクルを理解する - Amazon EKS
Amazon EKS が標準および延長サポート期間で Kubernetes バージョンをサポートする方法を説明します。これにより、最新バージョン、機能、セキュリティパッチでクラスターをプロアクティブに更新できます。
docs.aws.amazon.com
minikubeの中のkubernetesクラスタバージョン確認
minikubeでkubernetesバージョン指定しての起動。
2023年6月は1.27.2が最新らしい。
今作ったクラスタいったん潰して作ってみた。
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を試してみる。
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が指定できる。
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
Before you begin You must use a kubectl version that is within one minor version difference of your cluster. For example...
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バージョン確認してみる。
https://storage.googleapis.com/kubernetes-release/release/stable.txt
storage.googleapis.com
2023年6月の時点ではv1.27.2って書いてあった。
このへんの意識忘れそうやな。
予定はこのへんに書いてある。
毎月リリースあるねんな。
Patch Releases
Schedule and team contact information for Kubernetes patch releases.For general information about Kubernetes release cyc...
kubernetes.io
minikube dashboardでブラウザに状態表示させる
裏側でコンテナ起動してるんやろなぁ。
これ動かすとブラウザが起動してコマンドライン戻ってこん。minikube dashboard &ってコマンドライン戻るようにして普段は使う。
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できるようにコンテナを作ってある。
このコンテナをminikube環境に作れば、他のPodと疎通して使えるはず。
ローカルLANのdnsでも名前引きできるから、ファイルサーバも見えるしもちろんインターネットも使えるから、google driveとかも見える。
ping/traceroute/mysqlとか使いたいから、 ローカルlinuxのイメージ置き場のxrdpコンテナにはいろいろ入ってる。
minikubeの中のk8sでポッドの間で通信させるときの動作確認に使う。
docker saveする
一番大きなイメージのgvis-ubu22を持ってくるようにする。
4.21GBはデカいけどlibreofficeとか入ってるからしゃぁないな。
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側に取り込んで使う。
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倍サイズが変わるやん。
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で動いてるコンテナのイメージがそのまんま動く
だいたいこんな感じ。
include 'Y:_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が始まる。
docker saveが終わったらこうなる。
10分ぐらいで終わる。
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起動させたら勝手に動き出す。
# 参考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領域にバックアップしとけば内容維持できる。
# 参考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するとこうなる。
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で引っ掛けてる。
# !/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もプラグイン維持されて持ってこれてる。
いったん完成
完全に完成したわけやないけど、いったん練習で作ったもんはこんな感じで動いた。
次はmariadbとdjangoのコンテナもPodにして入れるかな。
+-mac----------------+ | +-minikube-------+ | | | | | | +----------------+ | | +-hyperkit-------+ | | | +-container-+ | | | | | kubernetes| | | | | +-----------+ | | | | +-container-+ | | | | | xrdp | | | | | +-----------+ | | | +----------------+ | +--------------------+
実際の稼働画面はこんな感じ。
事前に調べて読んだとこ
どうやればできっかなぁって読ませてもらったサイト。
作者さんありがとう。
参考URL：https://blog.kondoumh.com/entry/2019/10/05/090944https://minikube.sigs.k8s.io/docs/drivers/hyperkit/https://ottan.jp/posts/2021/09/993782180/https://zenn.dev/korosuke613/scraps/d4e81c5a5fab74https://unicorn.limited/jp/rd/kubernetes/20180420-minikube-config.htmlhttps://qiita.com/satto_sann/items/188dc5750c6d821b3004
