Kubernetesで始めるHCI(第一回 〜検証環境設計編〜)

#最終目標地点
ざっくりとした目標として以下のものを想定する。検証が進むに連れて変わる可能性は勿論ある。
![Kube Env](https://lh3.googleusercontent.com/V3fXlEO5FSm5ra7_AEvsD1ltL07aR3j8Otdt2kiH7bnq-GiHFRG8qsXQ8FnQXAI60yDmRaXk-jIPTNIRSg6hDUF3ZAZlLldWlhS4nuAHbTtLfI8bGpdlClloa5HlcByXQ2qEq5a8Ph8GWJjwrJtX4PljFCAYTAZL0BUw06yqRg5SpHCQGvnPPt1G9k2dq-IXNcw3bEkYc5iaTU9PFOT0fnA9KAcj9GIE41cgqyG-sPsmx6A5IJMXmPCKr5DV25pJWBavJtoOl6bpfereLW1813p3wJHsaQeII_dDHqcCFaf4CokC7pmdbaSODxtDizWOOOorshuu-no6cb_8mP1zisLLn6a9QpkxYjp2y2LZ98UzPgGPDy73i5vYLX0Sp2Ps-vpSybObqS4s-mjLy3rYeSvEs5nStxuQ2A7CcGuPaVBlJX0B1AHuc6h5Q5HH0ycZtjKJ6RXjRMqTLPLwJXqe0XenhDyEnRR194Aj99dNPWlZQD-h_0aIiuM8D_G0TiCsyWEBpEpgON0sx77-woN0mfVoCz9Jm0DgHiZ3Jo-MpZj5eVSvQcz2Xe-0xAVJm2PMJwLj2SekTofVZlzvN1nB-OwCQkTHc6pkLiSzxXGuhFW3ti8tPMgKL2ltRgEsV3drEFPUnhmqMSFyPYv-QK0tWsJZcTelPkqkCPNN94eouLg_QYVurCKYGPpbk1YqiUQFsX1Fc3ZzqvafvgdGcdQ-DKI=w1205-h871-no)
GKEだけで、継続開発することが出来れば何の問題もないのだが、Cloudで開発するのはお金がかかる。しかもどの程度かかるか開発段階では分からない。この点がクラウドが普及しきらない点であろう。今後改善はされるのだろうが、現時点でメリットの高い稼働率やメンテナンス性を考え本番環境のみをGKEに持っていければという想定をする。


#Networkを検証するために
以下のものを準備する
[構成図](https://docs.google.com/drawings/d/1fV2X5bRi4GOeUsD-6OIHigv-KCfuboK1vcZe_TQczSM/edit?usp=sharing)
Home Cloud部分を分解したものだが、論理的なNWを示す。特徴としては[Bird](https://bird.network.cz/)を使ったBGPを利用していることが大きい。冗長性、拡張性をBGPをLocal Network環境で利用する手法が近年注目を集めている。またMetal LBとの組み合わせでLBとしても利用できる。KubernetesにおいてはCalicoが同じ思想のもと構成されるが、Calicoを導入する場合はNWが衝突しないように注意する必要がある。これは検証結果を待って、どのように構成していくかを決定する。

こちらも現段階では想定後々変わる可能性あり。

#Storageを検証するために
[第零回](https://docs.google.com/drawings/d/19bqpYpsQhWYicyN22ATB7AmiSg86qn-JjkxXjPKmz3k/edit?usp=sharing)にも記載した通りKubernetesのBackendで動作するSDSとしてCephを選定している。容量と性能を出すためにTier構成でNVMeとHDDを利用する。Cephの性能検証はいろんなところで行われているのでそれらを吟味して、CephとしてはCPU、Memoryは極力小さく、Network, Storageデバイスは極力大きいものが必要になってくることがわかるだろう。そのほかの検証環境を加味して統合的に必要なリソースの計算を行う。
Storage IOに必要なリソースはCPU, Memory, NetworkそしてデバイスへのIOがある。HCIを設計していく上で、これらのバランスを加味した設計が重要になってくる。検証段階ではおおよそのあたりをつけ、予算と相談して可能な限りMinimal構成で進めていくのが良いだろう。今回の設計範囲は[ここ](https://docs.google.com/drawings/d/19bqpYpsQhWYicyN22ATB7AmiSg86qn-JjkxXjPKmz3k/edit?usp=sharing)で示したものを利用する。
最大でどの程度のIOが必要になるかを見積もるのは困難だが、近年のNVMeを利用したStorageデバイスで性能が足りないようであれば、それはアプリケーションの作りに問題があると考えるべきだろう。

#Kubernetesを検証するために
Kubernetesの検証環境はVMで作成する。HostとなるHyper VisorはUbuntu + KVMだ。KVMについては割愛するが仮想環境と物理環境の違いについては事前に予備知識として熟知しておく必要があるだろう。また、CephやBirdと連携するのでUbuntu + KVMが最も良い選択となる、その他の環境ではおそらく動かないことが多いだろう。
VMで建てたUbuntuにkubeadmを利用してkubernetes clusterを作成する。これの繰り返しで検証を行う。
ここでの目的はSDN、SDSとの連携、また性能に致命的な欠陥が出ないかを見ておくのも良いだろう。あとは運用していく上で必要になる試験を都度行う。それに応じて検証環境も変わる。

#その他あると便利なもの
そのほか、色々検証していく上で便利になりそうな、Windows環境やADを使ったDNSやPXEサーバなどを準備しておく、これらを含め検証環境の仮想マシンは、一律４VCPU、６GBで構成している。検証環境としては十分なリソース。
KubernetesのTest用VMは大量に生成することになるのである程度自動的に生成する仕組みがあるといいだろう。ImageのコピーとIP、Host名の設定を自動化出来れば事足りる。


#インフラエンジニアに必要な検証環境とは
色々書くにあたって検証環境の重要性を痛感したのでここで少しだけ触れておく。ソフトウェアエンジニアによるコードのテストは様々な手法があり、ナレッジは沢山あるけど、インフラエンジニアは何をどうテストしていけばいいのか迷う。基本的な考え方はソフトウェアと同じ、期待している動作を網羅出来るかどうかを試験することが出来ればいいのだが、インフラのテストはお金の都合と現実的に起こせる障害の試験の都合上ソフトウェアの試験程網羅性を持っていない。また実運用で必要となる挙動確認は運用が始まらないとわからないというケースが多々ある。だからこそ、試験環境が重要になってくるのだが、網羅性の低さからあまり重要視されていない。重要視されないから体系化されず、という悪循環がオンプレミスの時代に終止符を打ったとも言えるだろう。インフラだってコードに負けないくらい変化するし、バグや設計ミスとか無いシステムなんてこの世に存在しないんだということを改めて認識しておいてもらいたい。仏法には「十界互具」という言葉が存在する。最高の境涯である仏界に他九界が存在しているし、その逆もまた真であるとの意だが、システムにおいても最高のシステムが単独で存在するなんてことはあり得ない。数多くのバグや残念な仕様を乗り越えてこそ良いシステムはできる。
長々と余談が続いてしまったが、題名が気に成った人だけ読んでもらえると幸いに思う。