Kubernetes環境のスクラッチ構築のために、仮想マシンのファイルシステムのrootパーティションの拡張を試みようと思ったけど...

世はまさに、大コンテナ時代!...はい、技術の進化の波に完全に取り残さてます、どうもボクです。マイクロサービスを実現する上でコンテナ技術が利用されるんだと。マイクロサービスについては、

thinkit.co.jp

⇧  上記サイト様が詳しいです。

サービス・メッシュという言葉は、

dreamarts.connpass.com

⇧  株式会社ドリーム・アーツが主催の勉強会で、CTOの石田さんに教えていただきました。

 

BTW(By the wayの意味)、ちょっと前の記事で、Kubernetes環境のスクラッチ構築を試みようとした時に、ファイルシステムのrootパーティションの容量が足りず、必要なファイル群をインストールできなかった... と思ってたんだけど、足りないのは「/」にマウントされてる「tmpfs」ってファイルシステムの容量だったらしい...気づくのに3日ぐらい無駄にしました(涙)、まじで時間を返して欲しい...。

詳細は後半で。

ts0818.hatenablog.com

⇧  この回ですね...

 で、今回、ファイルシステムの拡張にトライしようってな具合です。

BTW(By the wayの意味)、Javaに詳しい寺田さんのブログで、

yoshio3.com

⇧  『Quarkus』って技術がRed Hut 社が公開したと紹介されてました。

こちらの技術も時間を見つけて取り組んでみたいですね。

 

さらに、BTW(By the wayの意味)、

microk8s.io

⇧  シングルノードなKubernetes 環境で良ければ、上記サイト様の「MicroK8s」ってのが手軽にKubernetes環境を構築できるらしいです。

 

まずは、仮想マシンファイルシステムのrootパーティションの拡張に、レッツトライ~。

 

LVMを使っていく方針で

Linuxのディスク(ボリューム)を管理するコマンドは、

qiita.com

⇧  上記サイト様によりますと、結構な数ありますかね。

そんな中で、

go-journey.club

⇧  上記サイト様を参考に、今回は、LVMっていうユーティリティを利用していこうってことで。

まずは、仮想マシンを起動で。自分は、Windows 10 Homeを利用しているので、Docker ToolBoxで作った仮想マシンを使っていきます。

Docker ToolBoxで作成してある仮想マシン一覧を表示してみます。

docker-machine ls    

f:id:ts0818:20190427101704p:plain

⇧  仮想マシン名の「defualt」って、スペル間違えてますね...

stackoverflow.com

⇧  仮想マシンのリネーム方法がむちゃくちゃ面倒臭そうなので、リネームは時間ある時で。

とりあえず、仮想マシンを起動で。

docker-machine start [仮想マシン名]  

f:id:ts0818:20190427102457p:plain

あとは、指示通りコマンドを実行...って、デフォルトの仮想マシン名(『default』)でない場合は、仮想マシン名まで付けたコマンドを実行する必要があるらしい。

f:id:ts0818:20190427102559p:plain

sshログインする時も同様に仮想マシン名の指定が必要ですね...

f:id:ts0818:20190427102815p:plain

無事ログインできたということで。

Docker ToolBoxで作成された仮想マシンはデフォルトの状態では、Tiny Core Linuxってディストリビューションを元にしているらしいんだけど...

f:id:ts0818:20190428095234p:plain

⇧  『Operating System:Boot2Docker 18.09.3(TCL 8.2.1)』の「TCL」が「Tiny Core Linux」のことを指しているとしたら、むちゃくちゃ分かりづらいわ~!

f:id:ts0818:20190428095535p:plain

⇧  uname -a でカーネルのバージョンなどの表示を行うことで、ある程度の情報は知ることができるらしい、Tiny Core Linux の情報はどこにも出てこないけど...

まぁ、よく分からんのだけれど、boot2dockerってディストリビューションが、Tiny Core Linuxってディストリビューションをラッピングしてるようなイメージなんですかね?

なのでかは分からんのだけれど、パッケージ管理ツールは、Tiny Core Linux のものを利用するらしい...分かりづらいわ!

forum.tinycorelinux.net

⇧  上記サイト様を参考に、いま、仮想マシンにインストールされてるライブラリ(Tiny Core Linuxでは、エクステンションっていうらしい)を確認。

tce-status -i 

f:id:ts0818:20190427105346p:plain

んで、Tiny Core Linux でLVMを利用するには、「lvm2」ってのをインストールする必要があるらしい。

www.markn.org

⇧  上記サイト様が詳しいです。

Tiny Core Linux で利用できるライブラリ群(エクステンション)は、以下のサイトで確認できるようです。

tinycorelinux.net

 

lvm2 で絞ってみました。

f:id:ts0818:20190427110119p:plain

ということで、

 

f:id:ts0818:20190428101800p:plain

f:id:ts0818:20190428103723p:plain

⇧  「69-dm-lvm-metad.rules」ってファイルもしくはディレクトリが存在しないと...どういうこっちゃ?
 

docker@defualt:~$ ls -la /usr/local/share/lvm2/files
/
total 0
drwxr-xr-x    2 root     root           120 Apr 27  2017 .
drwxr-xr-x    3 root     root            60 Jan  2  2014 ..
lrwxrwxrwx    1 root     root            55 Apr 28 01:17 10-dm.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/10-dm.rules
lrwxrwxrwx    1 root     root            59 Apr 28 01:17 11-dm-lvm.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/11-dm-lvm.rules
lrwxrwxrwx    1 root     root            60 Apr 28 01:17 13-dm-disk.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/13-dm-disk.rules
lrwxrwxrwx    1 root     root            62 Apr 28 01:17 95-dm-notify.rules -> /tmp/tcloop/lvm2/usr/local/share/lvm2/files/95-dm-notify.rules

⇧ なんか、「/tmp/tcloop/lvm2/usr/local/share/lvm2/files/69-dm-lvm-metad.rules」へのシンボリック・リンク「69-dm-lvm-metad.rules」が「/usr/local/share/lvm2/files/」に存在しないらしい...というか、「/tmp/tcloop/lvm2/usr/local/share/lvm2/files/69-dm-lvm-metad.rules」が存在しないからシンボリック・リンク「69-dm-lvm-metad.rules」が作成されなかったってことですかね?

 

権限の問題とか?と思って、

zashikiro.hateblo.jp

⇧  上記サイト様を参考に、rootユーザーに切り替えて試してみるも、

f:id:ts0818:20190428111915p:plain

⇧  そもそも、root ユーザーじゃ実行すらできないしね...

パッケージ管理ツールでインストールしてんのにな~...っていうか、バグ?こちらとしてはどうにも手の施しようが無い気が... 

いけるとこまで、行ってみるということで。fdiskコマンドで現在のディスク構成(どんなディスクがパソコンに搭載されているのか)を確認

fdisk -l

f:id:ts0818:20190428124932p:plain

dfコマンドでディスクとパーティションの関係を確認

df -h

結果

root@defualt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
tmpfs                   890.4M    229.5M    660.9M  26% /
tmpfs                   494.7M         0    494.7M   0% /dev/shm
/dev/sda1                29.2G     48.8M     27.6G   0% /mnt/sda1
cgroup                  494.7M         0    494.7M   0% /sys/fs/cgroup
/c/Users                464.9G    263.0G    201.8G  57% /c/Users
/dev/sda1                29.2G     48.8M     27.6G   0% /mnt/sda1/var/lib/docker
/dev/loop0              868.0K    868.0K         0 100% /mnt/sda1/tmp/tcloop/lvm2

「/」の容量が、1GBに満たないって...あと、「/mnt/sda1/tmp/tcloop/lvm2」にマウントされた「/dev/loop0」 のファイル使用率が100%になってるのが「69-dm-lvm-metad.rules」が作成されなかった原因な気がしますかね、いや~、容量の調整したいからlvm2 を入れようとしているのに、lvm2 のインストールでも容量が足りずって...

f:id:ts0818:20190428145003p:plain

一旦、仮想マシンを作り直しました。(仮想マシンの内容がすべて無くなってしまうので、内容を取っておきたい場合は、他サイト様を参考で)

f:id:ts0818:20190429102310p:plain

f:id:ts0818:20190429102357p:plain

f:id:ts0818:20190429102501p:plain

容量が増えてますね。

f:id:ts0818:20190429102602p:plain

ただ、rootパーティションの容量はまったく変わらずという...
当然のごとく、lvm2 のインストールでも同じエラー。

f:id:ts0818:20190429105730p:plain

ちなみに、boot2docker(Tiny Core Linux)のfilesystem はというと、「extfs」の「ext4」ってものになるらしい。

docker@default:~$ df -T
Filesystem           Type       1K-blocks      Used Available Use% Mounted on
tmpfs                tmpfs         911788    235084    676704  26% /
tmpfs                tmpfs         506548         0    506548   0% /dev/shm
/dev/sda1            ext4        48340772     55248  45760396   0% /mnt/sda1
cgroup               tmpfs         506548         0    506548   0% /sys/fs/cgroup
/c/Users             vboxsf     487436396 277841628 209594768  57% /c/Users
/dev/sda1            ext4        48340772     55248  45760396   0% /mnt/sda1/var/lib/docker

「/dev/sda1」のタイプが「ext4」となっとるので。

で、3日ぐらい無駄にして気づいたんですが、私のやりたかったことは、タイプが「tmpfs」ってもので「/」にマウントされてるファイルシステムの容量を増やしたいってことってことになるらしい。

www.linuxquestions.org

www.looklinux.com

⇧  上記サイト様を参考にリサイズできました...すみません、LVMとか一切不要だったという...私の費やした3日間を返していただきたい(哀)

というわけで、改めて、仮想マシンを作り直しました。仮想マシンを削除する際は、仮想マシンは必ず停止しておきましょう。

f:id:ts0818:20190501115734p:plain

⇧  コマンドが受け付けない場合でも、「Oracle VM VirtualBox マネージャー」から強制的に「電源オフ(W)」で停止できます。

では、仮想マシンの再作成で。メモリとか、CPUを増やしてます。

docker-machine create -d virtualbox --virtualbox-cpu-count 4 --virtualbox-memory 5120 --virtualbox-disk-size 50000 default

f:id:ts0818:20190501115349p:plain

f:id:ts0818:20190501115607p:plain

そしたらば、指定のあるコマンドを実行後、sshログインし、rootユーザーに切り替え、「/」にマウントされてる「tmpfs」の容量を増やします。

mount -o remount,size=10G tmpfs /

f:id:ts0818:20190501120216p:plain

結果は、

root@default:~# df -h
Filesystem                Size      Used Available Use% Mounted on
tmpfs                    10.0G    229.6M      9.8G   2% /
tmpfs                   494.7M         0    494.7M   0% /dev/shm
/dev/sda1                46.1G     53.9M     43.6G   0% /mnt/sda1
cgroup                  494.7M         0    494.7M   0% /sys/fs/cgroup
/c/Users                464.9G    265.0G    199.8G  57% /c/Users
/dev/sda1                46.1G     53.9M     43.6G   0% /mnt/sda1/var/lib/docker

できました。

そんじゃ、いよいよ、Kubernetesのスクラッチ構築で。

 

 

まずは、Kubernetes 本体をダウンロードしていきます。

github.com

調子に乗って、「pre-release」版をダウンロードしてしまった...

f:id:ts0818:20190430160324p:plain

ダウンロードしたgzファイルを展開していきます。

f:id:ts0818:20190430160453p:plain

展開されました。

f:id:ts0818:20190430160821p:plain

んで、「~/kubernetes/server/」「~/kubernetes/client/」ともに、まだバイナリ群が無いので、

f:id:ts0818:20190501113942p:plain

Kubernetesに必要なものをインストールするために、スクリプトを実行する必要があるらしい。

f:id:ts0818:20190430165839p:plain

スクリプトを実行で。

sudo ~/kubernetes/cluster/get-kube-binaries.sh

f:id:ts0818:20190430170241p:plain

f:id:ts0818:20190430170428p:plain

⇧  なんか、パスを追加すれば良いらしいんだけど、「/home/docker/」は仮想マシンが再起動されるたびに、リセットされちゃうんで、ファイル群を移動しておく必要があるかと。

移動で。「/usr/local/bin/」配下なら大丈夫かと。

sudo mkdir -p /usr/local/bin/kubernetes/client/bin/
sudo mv ~/kubernetes/client/bin/* /usr/local/bin/kubernetes/client/bin/

f:id:ts0818:20190501121335p:plain

そしたら、パスを追加で。

export PATH=$PATH:[追加するディレクトリ名]

f:id:ts0818:20190430170709p:plain

一応、「kubernetes-server-linux-amd64.tar.gz」「kubernetes-client-linux-amd64.tar.gz」が配置されたんだけど、

f:id:ts0818:20190501121830p:plain

⇧  クライアント側は、展開してくれてるんだけども、何故かしらは分からんのだけれども、サーバー側は自力で展開する必要があるらしい...

www.takanyan.net

ulam.io

komeiy.hatenablog.com

tuxknight-notes.readthedocs.io

⇧  で、上記サイト様を参考にしようとしたんだけども、

https://kubernetes.io/docs/setup/scratch/

⇧  上記のアドレスに飛んでみると、

f:id:ts0818:20190430223304p:plain

⇧ まさかの公式サイトは 404 Page Not Found...もしや、スクラッチ構築は非推奨になったんですかね...まじか...5日間ぐらい無駄にしちまってるんですが...

 

とりあえず、続けてみます。

「/home/docker/kubernetes/server/」に移動しておいてから、

tar -xzf kubernetes-server-linux-amd64.tar.gz   

f:id:ts0818:20190501122708p:plain

⇧  tar を実行した時に、うんともすんとも言わないから成功してるのかが分からんのだけれども...一応、ファイル群は展開されたようです。

 

っていうか、「kubernetes-src.tar.gz」は展開すべきなのかが分からん...

github.com

⇧  だいぶ、前に、「kubernetes-src.tar.gz」に何もソース入ってないけどってissueがあったそうな...

展開してみたら、なんか、むっちゃファイルがおるんですが...必要なファイルが分からんのだけれども...

f:id:ts0818:20190501110751p:plain

⇧  「kubernetes-src.tar.gz」関連については、保留で。

 

f:id:ts0818:20190501122802p:plain

んで、「~/kubernetes/server/kubernetes/server/bin/*」を「/usr/local/bin/」へ移動で。

f:id:ts0818:20190501124314p:plain


 

そしたらば、kubernetesの「api-server」を動作させるのに必要な「etcd」をインストールしていきます。

github.com

⇧  上記サイト様の適当なバージョンを選択し、「リンクのアドレスをコピー(E)」しちゃいましょう。

f:id:ts0818:20190430164029p:plain

そしたら、ダウンロードで。

wget https://github.com/etcd-io/etcd/releases/download/v3.3.12/etcd-v3.3.12-linux-amd64.tar.gz

f:id:ts0818:20190430164217p:plain

 そしたら、展開で。

tar -xzvf etcd-v3.3.12-linux-amd64.tar.gz

f:id:ts0818:20190430164519p:plain

etcd~系のものを、「/usr/local/bin」に配置すれば良いらしい。

sudo mv ~/etcd-v3.3.12-linux-amd64/etcd/* /usr/local/bin

f:id:ts0818:20190501130309p:plain

f:id:ts0818:20190501130401p:plain

「etcd」の起動に、仮想マシンIPアドレスが必要らしいので、コマンドプロンプトをもう1つ起ち上げて、IPを確認。

f:id:ts0818:20190501125432p:plain

そんでは、「etcd」を起動で。

etcd --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://[仮想マシンのIPアドレス]:2379 &> /tmp/etcd.log &    

etcd が動いているか確認。

etcdctl cluster-health

f:id:ts0818:20190501125405p:plain

そしたらば、「api-server」 の起動で。「api-server」は、サーバー側のバイナリ群に入ってるものらしいので、「/usr/local/bin/」に移動済みってことになるようです。

kube-apiserver --etcd-servers=http://localhost:2379 --service-cluster-ip-range=[kubernetes のクラスタ内でのみ疎通が可能な ClusterIPの範囲]/24 --bind-address=0.0.0.0 --admission-control="" --insecure-bind-address=0.0.0.0 &> /tmp/apiserver.log &

f:id:ts0818:20190501130730p:plain

起動確認。

curl http://localhost:8080/api/v1/nodes

f:id:ts0818:20190501131451p:plain

一応、「api-server」が動くところまでは行けたらしい。
5日間ぐらい無駄にしてしまった...公式のドキュメントにkubernetesのスクラッチ構築の手順とか載せて欲しいですな...見つけれないだけで、存在するのかしら?

連休の半分が潰れてしまったではないか(涙)

ということで、今回はこのへんで。