coreOSを利用して自宅kubernetes環境をkubesprayで構築する(その１

はじめに

勉強のため、k8sことkubernetesを構築しようと思い立った。正直いまだに、コンテナオーケストレーションってなに？という状態なのではあるが、触れる環境がないと難しいのと、課金が怖いので、AzureやAWS、GCPの無料枠を利用した環境構築はハードルがある。誰でも自宅サーバの1つや2つは持っているかと思うので、家にある自宅サーバ環境を利用してkubernetes環境を構築することにした。

環境構成

先日、メモリを増設した自宅サーバは以下の通り

家庭用ESXiサーバのハードウェアアップデート（メモリ追加編）

自宅サーバであるESXi6のメモリを8GBから16GBに換装させ、さまざまな仮想マシンを起動できるようにする。ESXiのメモリが増えることで

https://gatolynx.tokyo

いまだにメインのWindows7とCentOS 7 はそのままに、Windows8環境を落としてk8s環境用のメモリを確保することにする。

kubernetes環境の構築

kubernets環境を構築するには色々とお作法が必要らしいし、Linuxを基盤に利用するのが良いということなので、当初はCentOS 7をベースに考えていた。ただ、基盤として稼働するだけのOSに機能を持たせても仕方がないので、より軽量なOSがないかと考えていたところ、RancherOS というコンテナ環境に特化したOSがあるということを知った。

RancherOSを利用したkubernets環境ついてググっていたところRancherOSには、Rancherというノード機能があり、それぞれ別個に構築する必要がある、などなど、そもそもRancherOSとはなにか、という点が奥深く、壁に感じた。

より楽に、簡単に構築することが今回の目的であるため、RancherOSの学習に時間を取られるのはもったいない。そこで、RancherOSについてググっている中でたびたび比較されるCoreOSというLinuxのことを調べることにした。

これまたコンテナに特化したLinuxであり、セットアップもymlファイルベースでdocker-compose的に構築することができるらしいという情報に行きあたったので、CoreOSについて調べることにした。

CoreOS（Container Linux)とは

CoreOSとググっていたが、どうやら少し前に名称をContainer Linuxと変更していたらしい。ただ通称はいまだにCoreOSということで、CoreOSでググるとそれなりにヒットする。しかもRedhatが買収したらしい。

ググった感じ、数多くの先人たちははcloud-config.ymlというyamlファイルを特定箇所に配置しそれを読み込ませることで半自動的にセットアップが完了するという手順で環境構築をしていた模様だが、時折、ignition.jsonという文言がみられた。

公式のページにもcloud-configとignitionという2つのセットアップ手順があった。なんぞこれ？と思いながら調べていったところ、元々cloud-config.ymlでセットアップしていたことを、初期セットアップの時だけ発火するkickstart的な条件として利用できるのが、ignition.jsonというjson形式とのこと。

どのようなサーバ構成にしようか決まっていないものの、IPアドレスとNICの設定だけでも初期セットアップできると楽なので、ignition.jsonを利用することにした。

CoreOSのセットアップ

CoreOSのインストーラの入手

正確にいうとインストーラーというよりもPXEファイル的なブートISOのようである。公式サイトからダウンロードできます。

以前はこちらからダウンロードできました。

ESXi6のセットアップウィザードにCoreOSの項目があったので、空の仮想マシンとしてCoreOS VMを作成後、ダウンロードしておいたISOをデータストアにアップロードし、マウントさせ、起動。

起動が完了すると、ログイン状態となるためコンソールで接続してユーザにパスワード を設定する。

以後の作業にターミナルを利用する方が楽なため、パスワードの作成のみコンソール接続で行い、以後の作業はターミナルを利用した。

まずはコンソールで、OSのデフォルトユーザにパスワードを設定する。コンソールでは英字キーボードレイアウトであることと、Tab補完ができないため注意が必要。

1
2

$sudo passwd core
#coreユーザ（OSデフォルト）にパスワード作成

コンソールを抜け、ターミナルを開いて

1
2

$ ssh core@xxx.xxx.xxx.xxx 
#上で設定したOSにSSHする

これでターミナルから各種設定ができるようになる。

ignition.jsonの準備

ignition.jsonを作成するためには、手動でJsonファイルを書く必要があるわけではない（だったら大変）。これまで利用されてきたcloud-config.ymlを自動でjsonに吐き出してくれるツールが存在するため、それを導入する。

インストールにはbrewが利用できるため、以下を参考にインストールする

GitHub - coreos/container-linux-config-transpiler: Convert a Container Linux Config into Ignition

Convert a Container Linux Config into Ignition. Contribute to coreos/container-linux-config-transpiler development by creating an account on GitHub.

https://github.com

1

$brew install coreos-ct

インストール後、手元でcloud-configを作成する
例えば、今回作成したのは以下の通り。（注、以下では修正しているが、当初、GatewayとDNSの設定をtypoしていて、coreOSのインストーラーがダウンロードできず、なぜ外への通信ができないのか悩んだ。簡単に設定できるからこそtypo注意。

設定が完了したら、jsonを出力する。

1
2
3

$ct  < config.yml | pbcopy
#ct < config.yml でjsonが出力される。
#macの場合pbcopyにリダイレクトすればそのままコピーされる

コピーしたjsonをCoreOS側でignitionファイルとして利用する

1
2
3
4

$touch ignition.json
$vi ignition.json 

#中身をクリップボードから出力

CoreOSのインストール

OSには幾つかの種類があるが、オプション -C stable を付与して安定版を利用することにする。また、vmwareToolsがインストールされたモデルがあるため、それを利用するためのオプション _-o vmware_raw _を利用する。

ちなみにここまでやっていてようやく気が付いたのだが、CoreOS用のVMイメージを公式で公開していたorz

1
2
3

$sudo coreos-install -d /dev/sda  -C stable -i ignition.json -o vmware_raw
Current version of CoreOS Container Linux stable is 2247.7.0
....

curlか何かでインストーラーを持ってきている模様で、しばらく時間かかる。

その間にSlave用を作成、しようとしたところCoreOSが起動しなかった。
構成上、変更しているところはMasterが2GBメモリを振っているのに対して、Slave用には1GB(1024MB)だけ。一旦。1.5GB(1536MB）にして起動を試みる。

1.5GBとしたところ、無事、起動した。

そうしている中、Master側もタイムアウトして失敗していた。悲しい。（原因はDNSとGateway設定のtypoにあった。）修正して再度構築し直す。

起動後の確認

インストール完了後、再起動をせずに一度シャットダウンさせ、ブート用のISOを起動時にマウントしないようにさせた上で起動させる。オプション_ -o vmware_raw _を指定したため、起動後にVMware　Tools がホストのESXi上で動作していることが確認できた。

インストール終了後に詰まったところ

当たり前といえば当たり前だが、インストールが完了した後、VMをシャットダウンして、ISOをアンマウントして起動させる。→起動する。

が、このときにSSHしようとすると下記のエラーがでてログインできない。

1
2
3
4
5
6
7
8

~
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is ...

直前にSSHした際のフィンガープリントが変わっているため、ログインできなくなっているわけだ。

~/.ssh/knownhosts を書き換えればよいのだが、vim で開こうとすると、vimが壊れているというエラーがでて修正できなかった。焦った。

原因はCatalinaにしてから一度も利用していなかったため、vimが壊れていることに気がついていなかったため。ググる限り、壊れ方には何種類かあるみたいだったが、比較的軽症だったのか

1

$brew upgrade vim

で修復することができた。

さて、これでようやくk8sを構築する環境が整った。