今回、自宅Misskeyインスタンスである community.bluecore.net の解説記事を書いてみました。
当初は設計的な内容について書こうかと思ったのですが、それやるとかなーりめんどくさい記事になりそうなので、解説ということにしようかなと。

概要

前回と同じように、コンテナホストはVMware ESXi 6.5U3上のVMを使用しています。OSは個人的に慣れ親しんだCentOS7のLatestにしています。

今回のコンセプト

基本的には「障害が起きたときに、自律的に復帰できる構成」を目指しています。ただ、冗長化をするにはあまりリソースに余裕がないということもあり、コンテナは基本シングル構成にして一貫性を優先しています。

ただし、Misskeyのアプリケーションコンテナに関しては、スケールアウトできるのか、負荷分散して動くのか？といったところを確認するため、スケールアウト可能な構成で組んでいます。

コンテナホストのスペック

コンテナホストのスペック一覧は以下の通りです。

帯域というよりは、パケットの応答性が高いことに注目し、関連するサーバは10GbEネットワークに配置しています。単一セグメント構成です。

コンテナネットワーク

コンテナネットワークは、k3sの機能としては、デフォルトでFlannelというL2レイヤーのネットワークを構成するCNIプラグインが標準でついてくるのでこれを使用しています。10.43.0.0/16がクラスタ階層、10.42.0.0/16がコンテナ階層になっています。

通常、コンテナにアクセスするにはNodePortなどを使用してホストポートを開放するのが一般的ですが、実は各コンテナホストにあるiptablesがNATの制御を行っており、これを通じて外部→内部に対するネットワーク通信が可能になっています。

実際には【外部→L3→コンテナホスト(iptable→ClusterIP→Flannel→Pods)】という感じの動きをしています。

インターネットから入った通信はルーター、UTMを介して統合プロキシサーバにてWAFでのチェックを通じ、内部DNS越しにコンテナ名を名前解決したうえでいずれかのコンテナホストにアクセスします。前述したフローを通じてアプリケーションPodへ入り、結果を取得します。

k3sインフラストラクチャで欠かせないのがDDNSとなるCoreDNSであり、こことの名前解決をしないとうまくClusterIPを通じたサービスにバインドできません。インフラ内に配置した内部DNSにてCoreDNSへフォワードするように構成しています。

ClusterIPと紐付くゾーンは「<namespace>.svc.cluster.local」となっており、自宅インフラ内でも名前解決はこれをベースにしたFQDNを通じて行っています。

MisskeyはMastodonと少し毛並みの違うところがあり、複数のワーカープロセスそれぞれがウェブフロントエンド・ジョブ管理・配信をひと固まりで動かしてるように見えます。ワーカープロセスに対する通信も、FQDN単位で解決できるようにするため、基本的にはClusterIPを通じたアクセスをするようになっています。

各コンテナの構成は以下の通りで、Misskeyアプリケーションコンテナ以外は原則単一構成です。コンテナホストがダウンする事象が発生したら、5分程度経過したのちにオートヒーリングが動作し、別のコンテナホストへ移動するという形になります。その間はアクセス不能になりますし、場合によってはスローダウンの可能性もあります。

ストレージ

ストレージは基本的にNFSv3ストレージを使っており、これをPersistent Volumeと関連付けて動かしています。この辺りは以前のKubernetesと同じです。PersistentVolume Claimを通じてコンテナと通信しており、実際にはコンテナからコンテナホストをNATする形でストレージへアクセスする形となります。

なお、バックアップとして以前はpg_dumpなどを使用した論理バックアップを中心にデータ保全をしていたのですが、現在は別拠点に構成した仮想ストレージを別途配置し、そこへブロックベースのレプリケーションを行うようにしています。RPOは60minに設定しているので、比較的短いロールバックで障害時の復旧は行えそうに見えます。

今後は、AzureContainer Registryの導入や、AzureArc for Kubernetesが動いてくれたりしないかな？と考えつつ、必要に応じて拡張、整理していく予定です。