さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。
(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)
指針
これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。
しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。
そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。
また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。
(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)
Server Hardware
本構成では、物理サーバを3台使用しています。
うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。
Hypervisor for Virtualization
Hypervisor には引き続き proxmox を利用します。
VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。
Infrastructure with kubernetes
物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。
また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。
これらの物理サーバは 10GbE 2本で接続されています。
さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。
HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。
Registry for Container
Docker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。
また、これらのレジストリは kubernetes が動くマシンとは独立し、ストレージサーバ上の仮想マシンで動作させています。
kubernetes クラスタ内に配置しなかったのはストレージサーバ上で動作させるほうがストレージ的に都合が良かったためです。
適当なマシンが手に入れば引っ越し予定ですので、それと同時に kubernetes クラスタ内に配置するかもしれません。
このあたりはまだ詰めきれていない状態です。
HTTP and HTTPS Traffic
外部からのHTTP(HTTPS)トラフィックは、Nginx Reverse Proxy を使用して Ingress Load Balancer へ流しています。
ルータからのフォワーディングは 1IP に向けることしか出来なかったので、間に Nginx を挟み Ingress が動く複数のワーカーへ通信を分散しています。手元の機材では、これ以外の方法が思いつきませんでした
Redundancy and Scalability
構成上、 Nginx や Registry が単一障害点となっていますが、 kubernetes クラスタについては物理・論理の両方での冗長性を確保しています。
例えば、物理的にサーバをメンテナンスする際にも、もう一方のサーバでサービスは動き続けます。
また、ワーカーの動く仮想マシンの1つをシャットダウンしたとしても、サービスは動き続けることが出来ます。
さらに、水平方向へのスケーリングも容易に行うことができ、これらは Horizontal Pod Autoscaler によってオートスケーリングされます。
個人レベルでは全く意味がないですが、ある程度の冗長性とスケーラビリティを実現しました。これで気軽にサーバの電源を落とせます
まとめ
今回、自宅ラックで構成した環境は、kubernetes をメインとしました。
それに付随して、スケーラビリティを確保することができ、ラックのメンテナンスが容易になりました。
kubernetes の検証も兼ねて構成したものですので、構成した本番環境以外で別途クラスタを構築し、今後の学習に利用する予定です。
眠くなってきたので、今回はこのあたりで終わっておきます。