Kubernetesマルチクラスターとは？ アーキテクチャと管理

マルチクラスターとは？

主要な点について話す。マルチクラスターKubernetesは、複数のKubernetesクラスターを同時に利用する最新のアーキテクチャです。使われるクラスターは密接に連携し、企業がクラスターの障害を経験しないように設計されています。

初心者向けに説明すると、クラスターとはノードの集合です。ノードにはワーカーとコントロールの二種類があり、それぞれ役割が異なります。例えば、コントロールノードはクラスターの状態管理を担当し、ワーカーノードはコンテナの実行を担います。

これらが組み合わさってKubernetesの中核をなすクラスターを形成します。一般的には、クラスターはKubernetesサービスを利用するコンピュータ群とも考えられます。また、マルチクラスターとは物理的または仮想的に展開された複数のコンピュータ群を指します。

システムと同様に、マルチクラスターにはユーザー認証やアクセス制御に用いる専用のセキュリティ管理システムが備わります。

さらに付け加えると、マルチクラスターは単に複数のクラウドを利用することではありません。複数のKubernetes環境を同期させ、容易に管理するために、様々な手法やツールを組み合わせた状態を指します。

‍

なぜマルチクラスターなのか？

従来は一つのクラスターのみが使われていました。なぜ今、マルチクラスターが求められ、開発者コミュニティで支持されるのか、その理由は以下の通りです。

• リソースを最大限に活用できる

この手法はリソースの無駄を出さず、データセンターの性能要件に応じてクラスターを柔軟に配置できます。

例えば、低遅延で迅速な処理を必要とするアプリは、近隣のデータセンターのクラスターに割り当てられ、そのコードは高性能マシンで動作します。

逆に、迅速な処理を求めず高性能マシンの負荷を抑えたい場合は、消費電力の少ないデータセンターが適しています。こうした要件に応じたデータセンターとリソースの割り当てはマルチクラスターがあってこそ実現可能です。

• 規制遵守が容易になる

規制遵守は必須ですが、複数領域の管理は手間がかかります。マルチクラスターなら、多国籍領域で一括して遵守対策を実施でき、分散コンピューティングにおいても効果を発揮します。

• テナントの分離が容易

Kubernetesは一度に複数のテナントを扱いにくい点が指摘されますが、迅速な開発やステージングにはマルチテナントが欠かせません。

マルチクラスターなら、namespaceを利用してテナントを簡単に隔離できます。

• 管理が容易になる

集中管理システムを導入することで、連携クラスター全体のログ、監査、セキュリティ、トラブルシューティングなどを一括管理でき、大幅な時間と労力の節約につながります。

• フェイルオーバーの可能性が少ない

前述の通り、複数のクラスターがあれば、単一クラスターの障害で全体が停止することを防げます。性能維持には重要な点です。

• シームレスなスケーラビリティとアプリのバースト対応が可能

単一クラスターでは拡張に限界がありますが、マルチクラスターならその制約を超えてスケール可能です。

• 地理的に分散したシステムの管理が容易に

地理的に多様な環境では単一クラスターでの管理は困難ですが、各地にクラスターを展開することで容易に管理できます。

• IoTサービスの向上

IoTサービスや製品を提供する場合、アプリがデータソースに近いほど性能が向上します。近くにクラスターを配置することが最適です。

‍

マルチクラスターKubernetesのアーキテクチャ

Kubernetesのアーキテクチャはクラスターを基盤としています。したがって、Kubernetesの仕組みを理解するには、まずクラスターとは何かを知る必要があります。ここでは三つのプレーンがあります。

最初のプレーンはコントロールプレーンで、Kubernetesクラスターの頭脳です。Control Manager、Scheduler、APIサーバーなどが含まれます。

次にデータプレーンがあり、KubernetesマルチクラスターのIngressなどでクラスターのストレージの役割を果たします。これはetcdデータベースを用いて実装されます。

最後にワーカープレーンがあり、クラスター内のワークロードを実行します。クラスターのノードとポッドを動かす役割です。

下記の図を参照して、アーキテクチャの概要を把握してほしい。

一見簡単に見えますが、実際は複雑です。例えば、同一クラスターの全く同じコピーを作成するクラスタ冗長性アーキテクチャも存在します。

‍

セグメンテーション対レプリケーション

さらに、マルチクラスターKubernetesを利用することで、アプリ設計者はレプリケーションとセグメンテーションのアーキテクチャを活用できます。ただし、同時に存在できるのはどちらか一方です。では、なぜこれらが重要なのでしょうか？

セグメンテーションアーキテクチャは、アプリを複数の独立したセグメントに分割します。各セグメントは独立したKubernetesサービスとみなされ、要件に応じてクラスターに割り当てられます。この方式では、アプリ間およびクラスター間の内部通信がスムーズです。

また、セグメンテーションによりマイクロサービス指向の結合が緩やかになり、独立性が向上します。これにより、常時利用可能で高い性能を発揮できます。

次にレプリケーションについて説明する。これは、一つのクラスターの全く同じコピーを作成し、異なるデータセンターに展開する方式です。これにより、高性能とクラスター全体のレジリエンスが実現され、近隣に配置されたコピー同士ならトラフィックのルーティングも容易です。

次に、両者の違いを理解してほしい。レプリケーションでは、機械学習を用いて二つのクラスターの類似点を検出します。

一方、セグメンテーションではデータを手動でグループ分けし、大量データの要求を把握します。

同じではないが、どちらもアプリの性能や利用性の向上に寄与するため、現在非常に求められています。

‍

Kubernetes中心の構成対ネットワーク中心の構成

k8sマルチクラスターを扱う際、二つの選択肢があります。

一つ目はKubernetes中心の構成で、各クラスターに異なるアプリを展開し、中央の管理プラットフォームで一括管理します。展開には手間がかかりますが、クラスター管理は容易です。

二つ目はネットワーク中心の構成で、アプリの全く同じコピーを作成し、異なる種類のクラスターで利用します。これらのクラスターは通常、各地に配置され、独立した存在として動作します。すべてと通信するために専用のネットワークが必要になる場合もあります。

‍

マルチクラスターアーキテクチャの利点と課題

マルチクラスターアーキテクチャは、その有利な点から近年大いに注目されています。まだその利点をご存じでない場合は、以下のリストを参照してください。

この手法により、クラスターのアップグレード、管理、セキュリティ修正が容易になります。連携する全クラスターに対し、ワンクリックでルールや例外を適用できるツールもあり、各クラスターに個別の手間をかける必要がありません。

• 構成のカスタマイズを容易に実現できる。各アプリは、例えばCNIプラグインやIoT連携など、固有の設定を必要とするため、マルチクラスターにより必要に応じたカスタマイズが可能です。隔離の境界設定やクラスターのライフサイクル管理も行えます。
• 複数のサードパーティベンダーを利用している組織にとって、マルチクラスターは有用です。ベンダーロックインを防ぎ、たとえベンダーが価格やモデルを変更してもワークロードに影響を及ぼしません。この構成はワークロードをクラウド非依存にし、モデルの切り替えやアップグレードを容易にします。
• 開発において完全な柔軟性を実現でき、様々な能力を持つクラスターを利用可能です。

これまで利点について述べたが、次に多くの課題について説明する。

• 第一の課題は、高度な複雑性である。Kubernetesの管理は容易ではなく、複数クラスターを連携させるとその複雑性は倍増します。各クラスターごとに異なる設定、ファイアウォール、さらには多数のAPIやAPIサーバーの管理が要求されます。
• 第二の課題は、各クラスターごとに求められるセキュリティ対策を確実にすることで、これが非常に煩雑になります。
• 第三に、マルチクラスター展開においては、全てのワークフローやプロセスを入念に計画・整理する必要があり、これは大きな負担となります。
• 最後に、高コストの問題がある。複数クラスターの調達には多大な費用がかかり、購入、保守、アップデートなどへの投資が必要なため、すべての組織に適した選択とはならない。

‍

複数のKubernetesクラスターへはどう接続するか？

Kubernetesマルチクラスター管理の核心は、各独立クラスターが統一された存在として見なされる点にあります。Kubernetesフェデレーションと同様、一見シンプルに思えますが、運用者にとっては分かりにくく複雑さを増します。

複数のKubernetesクラスターに接続する際は、アプリ中心のアプローチが推奨されます。これにより各クラスターは独立性を保ち、クラスター移行は通常アプリ側で処理されますが、サービスメッシュを利用している場合はその役割を担うこともあります。

いずれの手法も複数クラスターに接続するための標準的な方法です。どちらを採用するにしても、ネットワーク面の影響を重視することが重要です。

‍

複数のKubernetesクラスターをどう扱うか？

マルチクラスターを採用するには、基本となるワークフローを理解する必要があります。まずは、Kubernetesで単一クラスターに接続する方法を把握することから始めるとよいでしょう。

通常、kubectlなどのクライアントが用いられ、基本的なクラスター定義が記述されたファイルが使用されます。

これらのファイルで、demoとgettingstartedという二つのクラスターを確認し、コンテキストを切り替えて利用します。

kubectl config --kubeconfig=mykubeconfigfile set-context appcontext --cluster=gettingstarted --namespace=app1 --user=nick

このコマンドにより、新しいコンテキストがKUBECONFIGに紐付けられます。

...
contexts:
- context:
    cluster: gettingstarted
    user: mark
  name: mark@gettingstarted
- context:
    cluster: demo
    user: mark
  name: mark@demo
- context:
    cluster: gettingstarted
    namespace: app2
    user: mark
  name: appcontext
current-context: mark@gettingstarted
...

新しいコンテキストを使用するには、以下のコマンドを実行する。

kubectl config set current-context appcontext

これで設定は完了。以降実行するコマンドは新しいコンテキスト上で動作し、複数のクラスターを扱えるようになります。分散システムの利点を活用してほしい。

結論

単一クラスター機能を持つKubernetesは優れているが、IoTや分散システムに求められる拡張機能には対応が難しい。柔軟性、レジリエンス、セキュリティが重要な場合、Kubernetesマルチクラスターが適した選択となる。

このアーキテクチャは制約を設けず、カスタマイズやスケーラビリティの無限の可能性を提供する。一方、複雑性や高オーバーヘッドといった課題も伴うが、アプリ開発を強化する点は大いに評価できる。