Kubernetesは、企業におけるコンテナオーケストレーションのデファクト標準になりました。それには正当な理由があります - コンテナ化されたアプリケーションの管理を簡単なものにする、多くの機能を提供しているからです。一方でKubernetesには、いくつかの新たな課題もあります。その最も大きなものは、大規模な分散システムを効果的に管理するために、複数のKubernetesクラスタを展開し管理する必要があることです。
すでに設計とコーディングが完了したアプリがあり、コンテナを構築し、後はそれらを実行するのみ、という状況を想像してください。コードからアプリを実行するのは気分のよいものですが、コンテナ化されたアプリケーションを開発した経験がある人なら誰でも知っているように、それは当初思っていたほど単純な作業ではありません。本番環境にデプロイする前には、さまざまな開発/テスト/ステージのサイクルがあります。さらに、拡張性の問題もあります。水平方向のスケーラビリティ、レジリエンス、あるいはエンドユーザとの距離が近いなどの理由で、運用アプリケーションをさまざまな場所で実行することが必要になるかも知れません。
環境が増えれば、(クラスタの)問題も増える
まったく新規のアプリケーション構想であっても、複数のデプロイメント環境が必要になるまでには、それほど時間がかからないのが普通です。既存のアプリケーションのマイグレーションであれば、さまざまなセキュリティドメイン、さまざまな組織/課金、さらには特定のクラウドベンダのマシンラーニング用ツールキットとの親和性など、さらに多くの課題に直面することになります。
この問題を解決する最も一般的な方法は、複数のKubernetesクラスタを立ち上げて、それぞれ専用の環境でアプリケーションコンポーネントを実行することです。セキュリティの高いドメインでは、Kubernetesのロールベースアクセス制御（RBAC）や監査機能を広範に利用することになるでしょう。テスト環境ならば、運用時の挙動を数多く再現すると同時に、デバッグや検査が容易になるような設定が必要になります。自分の開発環境については — もしかしたら私と同じように、Dockerの設定を開いて、単にKubernetesのチェックボックスにチェックするだけかも知れません。使いやすさと短命(ephemerality)が、ここでは最も重要になります。
少なくとも数セットのKubernetesクラスタを立ち上げて、それぞれでマイクロサービスをホストすることになるでしょう。同じクラスタ内のこれらマイクロサービス間の通信は、サービスメッシュによって拡張することが可能です。クラスタ内部ならは、 Istioがレジリエンス、セキュリティ、可観測性を向上させる共通の通信パターンを提供してくれます。では、クラスタを越える場合についてはどうでしょうか？
Kubernetesクラスタの複数運用を恐れる必要はありませんが、複数のクラスタを実行する場合には、その上に優秀なアプリケーションを容易に展開できるように、クラスタ間の通信や対話の方法について検討しておく必要があります。Istioのようなサービスメッシュは、そのようなマルチクラスタ通信を容易にしてくれます。Istioにはマルチクラスタのサポートがあります。1.1では新機能が追加されていますし、将来さらに多くの機能が追加される予定です。サービスクラスタを導入して、複数のクラスタ間の通信を簡素化する方法も検討すべきです。
一般的なユースケース
Aspen Meshでは、これらのユーザニーズに合わせてマルチクラスターサービスメッシュを運用することに関して、質問を受けています。
- 組織規模上の理由から複数のクラスタを運用していますが、それらの監視と管理をひとつの場所で行いたいと思っています。クラスタ間通信は一般的に行いませんが、実施する場合には、明確に定義されたAPIを通じて行っています。
- 高可用性のために複数のクラスタを立ち上げています。それらは相互のクローンで、一方のクラスタに障害が発生した場合に、他方のクラスタがそれを引き継ぎ可能であることが非常に重要です。
- ハイレベルなアプリを構成するために、複数のクラスタを結合しています。エンドツーエンドのアプリケーションエクスペリエンスを適切に提供するため、クラスタ内のマイクロサービスが、別のクラスタのマイクロサービスと通信する必要があります。
3番目のカテゴリは、クラスタ間トラフィックを必要とするマルチクラスタです。クラスタ間トラフィックのサポートが必要な場合は、クラスタ間のネットワーキングや、フォールトトレランスの要件によって実装が異なります。
マルチクラスタで何が得られるのか
マルチクラスタとサービスメッシュを検討する場合には、まず何が必要なのかを特定し、その上で実現方法に移る必要があります。
一枚ガラス(Single pane of glass)
複数のサービスメッシュ（クラスタ毎にひとつ）を1か所から運用する方法です。すべてのクラスタの構成、メトリック、トレースを、ひとつの画面(a single pane of glass)に表示することが可能です。
統合信頼ドメイン(Unified trust domain)
サービスメッシュを使用して、強力な相互TLS暗号化で保護されたワークロード識別を提供します。このようなゼロ信頼モデルは、送信元IPのようなトポロジ情報に基づいてワークロードを信頼する方法よりも優れています。脆弱な境界スタックによって出所をコントロールするのではなく、暗号法による証明を基盤としているからです。
統合信頼ドメインでは、すべてのワークロードが共通の信頼基盤につながることによって、相互認証を可能にしています。サービスメッシュコントロールプレーンは、それがひとつであるか、あるいは複数であるかに関わらず、共通の信頼基盤に対して設定されます。
独立障害ドメイン(Independent fault domain)
クラスタとその関連するインフラストラクチャ自体が正常に動作する上で、他のクラスタに依存しないクラスタは、独立障害ドメインです。ここで言う"関連するインフラストラクチャ"の中には、サービスメッシュも含まれています。サービスメッシュをインストールしているならば、通信のレジリエンスをアプリケーションの下にあるインフラストラクチャ層に移すことがその目的だからです。ひとつのクラスタ内のサービスメッシュに障害が発生した場合に、それによって別のクラスタ内のサービスメッシュが損なわれる可能性があるならば、それは独立障害ドメインとは認められません。
クラスタ間トラフィック
あるクラスタ内のサービスと別のクラスタ内のサービスが直接通信し、高度なルーティングや可観測性、透過的暗号化といったサービスメッシュのメリットをその通信に持たせたいのであれば、クラスタ間トラフィックをサービスメッシュの一環として確保する必要があります。 つまり、東西のトラフィックがひとつのクラスタから出て、インターネットなど中間ネットワークを経由して、別のクラスタに入る必要があるのです。
これはおそらく、ほとんどの人がマルチクラスターサービスメッシュを検討する場合に最初に考えることですが、フォールトトレランスにも影響するので、ここでは個別に説明します。
異種(heterogeneous)/非フラット(non-flat)ネットワーク
非フラットネットワークは、フラットなネットワークを要件として持つことなく、複数のクラスタにまたがるサービスをサポートします。これはつまり、他のメッシュを考慮せずに、ひとつのメッシュ内のIP割り当てが可能であると同時に、メッシュ間の通信にVPNやネットワークトンネルが必要でないということを意味しています。
あなたの組織がすでに多数のさまざまなクラスタを抱えていて、まだポッドのIPアドレス範囲の干渉防止策が取られていないか、あるいは２度と経験したくないような困難を経験しているのならば、これはまさにうってつけのものになるでしょう。
マルチクラスタ・サービスメッシュ・アプローチ
マルチクラスタに何を求めるかはそれぞれ違うかも知れませんので、それぞれのアプローチで何を提供できるのか、順に見て行きたいと思います。
独立したクラスタ群
これはマルチクラスタではありません。複数のクラスタがあって、それぞれがサービスメッシュを使用しているとしても、統一的なマルチクラスタサービスメッシュを採用しなければならない、ということではないのです。そもそも、なぜ複数のクラスタになったのか、考えてみてください。個々のクラスタを、独立した独自の障害ドメインにしたいのであれば、依存関係を削除して、クラスタを分離するのが合理的です。ニーズさえ満たしているならば、ポッドのスケジューリングや永続化ディスク管理のように、サービスメッシュをクラスタ単位のサービスとして扱うことに何ら問題はありません。
共通管理
独立クラスタ群アプローチの次のステップは、複数のクラスタを対象とする共通管理システムです。このモデルでは、各クラスタは独立して動作しますが、それぞれのメッシュは共通の管理インターフェイスを通じて管理されます。システム(あるいは、このケースではシステム群）の監視やデバッグに使用するものを、システムそれ自体の外部に常駐するようにしておけば、システムが故障した場合でも検査や修正が可能になります。
これらのクラスタ間で共通の信頼源(root of trust、認証局あるいは署名証明書)を使用するように選択した場合は、統合信頼ドメイン(unified trust domain)とすることも可能です。
障害ドメインの独立性が最優先事項である場合、これはよい選択になります。このオプションでは、サービスレベルの契約を背景として、外部の一枚ガラス(pane of glass)にすべてを統合することが可能になるため、ソフトウェアをサービスとして使用するのに適しています。
このようなレジリエンスには価値があるという考えから、Aspen Meshでは、クラスタ間のアプローチを有効にしない場合でも、このユースケースをサポートできるようにしています。このアプローチは他のものもサポートしますが、ユーザが不必要にクラスタ間トラフィックに殺到しないように注意してください。
ゲートウェイ経由のクラスタ対応サービスルーティング
Istioでのこのアプローチには、クラスタ毎にひとつずつの独立したサービスメッシュと、クラスタ内のサービスが他のクラスタ内のサービスと通信可能にするための設定が必要になります。まず最初に、すべてのメッシュに対してひとつの統合信頼ドメインを設定します。次に、別のクラスタにあるサービスからの信頼できるトラフィックを受け入れるように、入力ゲートウェイを設定します。最後に、特定サービスのトラフィックをひとつのクラスタからルーティングして、別のクラスタに送信できるようにサービスエントリを設定します。
異なるクラスタ内のサービスが互いに直接通信できるようにするには、これが最初の方法です。同時に、各クラスタは、依然として独立したメッシュ制御プレーンおよび障害ドメインです。つまり、クラスタBのサービスメッシュに障害が発生しても、クラスタAは機能します。クラスタBのサービスが利用できなくなった場合も同様です。このクラスタ間トラフィックを設定するのは、ユーザの責任になります。
フラットネットワーク
このモデルでは、すべてのクラスタにわたるサービスメッシュについて述べています。各クラスタのポッドが重複しないIPアドレスを持つように調整して、すべてのポッドが任意のクラスタ内の他のポッドにトラフィックをルーティングできるようにします。共通のファイアウォール内に多数のクラスタがあるかも知れませんし、クラスタ間にVPNトンネルを構築する場合もあります。各クラスタから検出されたポッド、サービス、設定をひとつの全体ビューにまとめるように、サービスメッシュを設定します。
フラットネットワークでは、すべてのクラスタにまたがった、ひとつのスーパーサービスメッシュが存在するかのように見えます。この方法には、いくつかの欠点があります。このスーパーサービスメッシュは、ひとつのコントロールプレーンによって管理されるため、問題が発生した場合には、すべてのクラスタのサービスメッシュに影響が及ぶのです。複数のKubernetesクラスタへの分割が、元々はフォールトトレランスを目的としたものであった場合、このアプローチは、それを無効にすることになります。もうひとつの考慮すべき事項は、すべてのクラスタを管理するようにコントロールプレーンを拡張する必要がある、ということです。さらに、このフラットネットワークは、コントロールプレーンとクラスタ間トラフィックを処理するために十分なパフォーマンスを備えていなければなりません。
スプリットホライズン・エンドポイントディスカバリサービス（EDS）
このアプローチも同じように、クラスタをまたいだひとつのサービスメッシュを生成しますが、フラットなネットワーク構成は必要ありません。各クラスタ内のポッド、サービス、設定を検出する、ひとつのコントロールプレーンがあるのは同じですが、 スプリットホライズンDNSに相当するIstioのEDSが、フラットネットワークの要件を置き換えます。
クラスタ内のポッドのサイドカーには、通信対象となるサービス毎のエンドポイントがリストとして設定されています。同じクラスタ内にあるポッドはEDSリスト内に直接表れますが、別のクラスタにあるポッドに対しては、代わりに他のクラスタの入力ゲートウェイが示されています。ポッドは、通信するエンドポイントを選択してトラフィックを送信します。エンドポイントがローカルの場合、通信はポッドとポッドで直接行われます。リモートエンドポイントを選択した場合は、ポッドが通信しようとしているサービス用にマークされた、関連する入力ゲートウェイのアドレスにトラフィックを送信します。入力ゲートウェイはトラフィックを受け取って、サービスを実装するクラスタ内のポッドのひとつに送信します。トラフィックの送信先の決定には、Server Name Indication（SNI）が使用されます。
フラットネットワークのアプローチと同じく、これによって統合されたサービスメッシュコントロールプレーンが形成され、単一の障害ドメインと単一の信頼ドメインが導入されます。ネットワーク構成がフラットである必要はなく、ひとつのクラスタが、他のクラスタの入口ゲートウェイのパブリックアドレスにトラフィックを送信できればよいのです。
マルチクラスタにすべきか、そうではないか
開発上および組織上の理由から複数のクラスタを運用する場合は、自らの要件を理解した上で、それらをマルチクラスタ環境で接続するかどうかを決定し、そうであれば、さまざまなアプローチと、それぞれの選択肢に関わるトレードオフを理解することが重要です。
ここまで読んだのであれば、おそらくは、マルチクラスタを選択するでしょうから、本当の問題は、最良の実装方法は何か、ということになります。以下の表が、あなたにぴったりのアプローチを決める手助けになればと思います。
|
|
|
|
|
|
|
| 独立 |
|
|
|||
| 共通管理 |
|
|
|
||
| フラットネットワーク |
|
|
|
||
| スプリットホライズン |
|
|
|
|
|
| クラスタ対応サービスルーティング |
|
|
|
|
サービスメッシュの役割を果たすIstioが有効で、適切に使用されていれば、それがマルチクラスタ通信を容易にしてくれます。複数のクラスタにまたがるコミュニケーションの単純化にサービスメッシュの利用を検討すべき理由と方法、サービスメッシュによるマルチクラスタ通信、あるいはサービスメッシュ全般に関する私の見解について、より詳しい話をしたいのであれば、andrew@aspenmesh.ioまでお気軽にお問い合わせください。
著者について
Andrew Jenkins氏はAspen MeshのCTOで、組織におけるマイクロサービス管理の負担軽減を支援するためにエンタープライズサービスメッシュを開発しています。Kubernetesのようなコンテナ環境ソフトウェアを扱うネットワークアーキテクトであるJenkins氏は、急速に変化するチームを目に見える成果へと向かわせる、技術的リーダーシップをキャリアとしています。氏の専門分野はC++、JavaScript（Node.js）、Python、C、Go、Javaによるソフトウェア開発です。ソフトウェアおよびハードウェアのテスト、FPGA、および宇宙科学機器のボード設計の経験も持っています。