モバイルトップアップ(top-up)とリワード(reward)の世界的なソリューションプロバイダであるDT oneのエンジニアリングチームが、Hetzner(訳注:ドイツのホスティング会社)のホスティングプラットフォーム上に展開した同社のセルフマネージドKubernetesクラスタイングレスを対象に、IPフェールオーバベースのHA(High Availability)を実装した方法に関する記事を公開した。
DT Oneは、Hetznerのベアメタルマシン上に独自のKubernetesクラスタを運用する。クラスタにはnginxベースのKubernetesイングレスがあり、インターネットにサービスを公開している。イングレスノードの高可用性(HA/high-availability)を実現するためにさまざまなアプローチを試した結果、同社は最終的に、Hetznerの"vSwitch"仮想ネットワークを使用し、Puppetで自動化したIPフェールオーバベースのソリューションを採用することにした。
Kubernetesクラスタでは、インターネットなど外部ネットワークへのサービスの公開にレイヤ７(L7)イングレスを使用する。ほとんどのクラウドプロバイダが、マネージドKubernetesに加えて、ロードバランサを備えたイングレス実装を提供している。しかしながら、セルフマネージドなKubernetesイングレスでは、ロードバランサをnginxに頼るのが一般的である。
このようなセットアップのKubernetesで高可用性を実現するには、外部トラフィックに複数のIPを公開するためのVIP + keepalived的なソリューションが必要となる。keepalivedは、ホスト間の仮想IPをスイッチすることによって、VRRP(Virtual Route Redundancy Protocol)を使用したHAを提供するツールである。例えば、複数のイングレスノードをラウンドロビンDNSで設定する場合、ひとつのノードがフェールすると、それをDNSから手作業で除去しなければならない。しかしVIPを使用すれば、DNS名が示すのはひとつのIP(仮想IP)のみで、それがイングレスの動作しているノードを常に指していることをkeepalivedが保証してくれる。GCPやAWS、Azureなど、ロードバランサを提供するクラウドプラットフォームでは、プラットフォームがHAロードバランサを提供するのでVIPは不要だが、ユーザがロードバランサを管理するプラットフォームにおいては、VIPがHAを実現する手段になる。
InfoQはソリューションについてより詳しく知るべく、DT OneのDevOpsテックリーダのJan Hejl氏に説明を聞いた。
一般的にイングレスのポートは、メインホストのIPに結び付けられる。Hetznerでは、ひとつのサーバから別のサーバのIPアドレス(あるいはサブネット)に、サーバのロケーションに関係なく60秒以内にスイッチ可能なフェールオーバIP機能を提供している。チームは当初、keepalivedの管理するイングレスノード間でHetznerのフェイルオーバIPを切り替えるために、独自開発したPythonスクリプトを使用していた。その後既存のソリューションの修正バージョンを採用したのだが、暗号化されたVRRPを使用する必要があったり、IPv4を強いられるなど、いくつかの問題点を抱えていた。新しいVRRPv3プロトコルならばIPv6をサポートしているのだが、暗号化が不可能なのだ。セキュリティ上の問題について、Hejl氏は次のように述べている。
Hetznerのベアメタルマシンは/29、あるいは/26サブネットの一部であるため、自分たちのトラフィック以外のものを(tcpdumpを使うなどして)盗聴することが可能なのです。特に、IPが同じサブネット内にある場合は、arp_ignore/rp_filterなどの対策をしていたとしても、マルチキャストIPアドレスになりすますことは、それほど難しいことではありません。
セルフマネージドなL7イングレスを、DDoSなどの攻撃から守る手段はあるのだろうか？"Hetznerを最初のレベルの防御として、その背後に独自のファイアウォールを置くのです"、とHejl氏は説明している。
DT OneではPuppetをほとんどすべてに、TerraformをHetznerの仮想マシンやAWSデプロイメントの自動化に、それぞれ使用している、とHejl氏は言う。最初のソリューションでも自動化にPuppetを使用していたが、現在はHetznerが昨年導入したvSwitchという機能で置き換えられている。vSwitchはユーザマシンに分離したレイヤ２(L2)ネットワークを割り当てるため、暗号化されていないVRRPトラフィックをセキュリティ上の懸念なく使用することができる。ただし、HetznerのフェールオーバIPに関する問題は残る。つまり、ネットワーク全体の変更の反映に必要な時間(約30秒)が長過ぎるため、Hetznerで発生するサービス停止の影響を受けやすいのだ。
チームは最終的に、keepalivedと別々のvSwitchネットワーク上で通信する３台の物理ホストを使用し、Puppetを使って自動化された、実用的なソリューションに到達した。各ノードが他の２つのVIPのリーダとして、残り２台がフォロワとして動作する。keepalivedは、ノードの状態が変化した場合のEメール通知をサポートする。Hejl氏によれば、その他にもシステム監視と警告用にPrometheusとGrafana、Alertmanagerを使用しているということだ。