一、はじめに

先週、私はTencent Global Digital Ecosystem Conferenceに参加しました

。

今日は、皆さんと共有したい私の収穫の一つは、マルチクラスタツールを理解したことです

ソフトウェア開発の同僚なら、Kubernetesを聞いたことがあるでしょう。それはコンテナ管理ツールで、非常に複雑です

想像に難くないように、複数のKubernetesクラスタを同時に管理するツールはもっと複雑です。しかし、今回私が発見したのは、マルチクラスタは実はとても理解しやすいということです

その時、大会でTencentの新しいサービスに関する講演があり、マルチクラスタ管理に関連して、TKE AppFabricと呼ばれるものがあり、とても簡単に説明されていて、私はすぐに理解しました__JHSNS_SEG_40907fdd_8__以下、私はできるだけ簡単な言葉で、Kubernetes とは、マルチクラスタツールとは、そして最も簡単な使用方法とは何かを説明します。

二、Docker から始めましょう

Kubernetes を理解するには、Docker から話し始める必要があります

。

2013年、Docker が誕生し、革新的にソフトウェアアプリケーションの実行環境とソースコードをパッケージ化して、コンテナイメージ（image）を作成しました

。コンテナイメージは標準化されたファイルであり、ソフトウェアがどの言語で開発されても最終的にコンテナとして作成されるときは、同じ形式となります。そのため、あるツールですべてのコンテナプロジェクトのリリースを処理でき、開発言語の違いを完全に無視できます。

Dockerが標準化された、一括でソフトウェアを実行するプロセスを提供したことが、後に一般的な「コンテナアプリケーション管理ツール」の道を開いたのです。

現在、Dockerはソフトウェアデプロイメントの標準です。ソフトウェアがソースコードでリリースされるか、コンテナイメージでリリースされるかに関わらず、最終的にすべてDocker内でデプロイおよび実行されます。

三、マイクロサービスアーキテクチャ

Dockerが登場した後、ソフトウェアデプロイメントは大幅に簡略化され、コンテナイメージを実行するだけになりました。自然と、開発者たちは、単体の巨大なソフトウェアを複数のコンポーネント（つまり複数のコンテナ）に分割してデプロイできるかどうかを考え始めました。

初期の企業向け大型アプリケーションは、通常、巨大なモノリシックソフトウェア（monolithic）であり、異なる機能を持つ複数のコンポーネントを含んでいました。一つのコンポーネントを変更するだけで、全ソフトウェアを再デプロイする必要がありました。

現在の実践では、大きな機能コンポーネントを分割し、それぞれが独立したサービスであり、Dockerコンテナとして個別にリリースおよびデプロイされます。

その結果、モノリシックソフトウェアは複数のDockerコンテナで構成されるソフトウェアシステムに変化し、これが現在人気のある「マイクロサービスアーキテクチャ」（microservices）です。ソフトウェアには複数のマイクロサービスが含まれ、それぞれが一つのDockerコンテナに対応しています。

四、コンテナ管理ツール Kubernetes

マイクロサービスは、各リリースが多くの異なるコンテナを伴うことを意味し、それらを管理するのは課題となります。コンテナ管理ツールが登場しました。

様々なコンテナ管理ツールの中で、最も有名なのはKubernetesです。

これはGoogleが開発したオープンソースソフトウェアで、語頭Kと語尾sの間に8文字があるため、よくK8sと表記されることがあります。すでに実質的なコンテナ管理の標準となっています。

具体的には、主に以下のような機能があります。

（1）統一的なハードウェアインターフェース。開発者は下位のハードウェアの詳細を気にする必要がなく、下位のサーバーがどのような違いがあるかに関わらず、統一された操作インターフェースとして抽象化されます。

（2）自動スケールアウト。ソフトウェアの負荷状況に応じて、迅速に水平スケールアウトを実行できます。

（3）高可用性。あるコンテナが失敗した場合、自動的に再起動または交換され、トラフィックが利用可能なノードに流れることを保証します。ソフトウェアリリースに問題がある場合、自動的にロールバックすることもできます。

（4）その他の機能。サービスディスカバリ、負荷分散、リソース監視など多くの関連機能を備え、多数のプラグインや拡張機能があり、活発なコミュニティがあります。

五、マルチクラスタとは何か？

Kubernetesの下層は、多くのコンテナが実行されているサーバー群です。各Kubernetesインスタンスは、クラスタ（cluster）と呼ばれます。

。通常のソフトウェアアプリケーションでは、一つのクラスタで十分ですが、以下の理由から、エンタープライズアプリケーションでは複数のクラスタにデプロイする必要があることが多いです。

マルチクラスタ（multi cluster）は、同じデータセンター内に配置することも、異なるデータセンターに配置することも可能です。実際の運用では後者が一般的で、異なるデータセンターに分散している場合、クラスタが異なるクラウドプロバイダから来ているか、あるいは異なる種類のクラウドである場合は、「マルチクラウド」（multicloud）と呼ばれます。

マルチクラスタの主な考慮事項は以下の通りです。

（1）故障耐性。あるクラスタに問題が発生した場合でも、別のクラスタがあるため、利用可能状態を保証できます。

（2）分離。クラスタ間で非常に強い物理的な分離を実現し、上層ユーザ（テナント）の分離を達成できます。

（3）柔軟性。マルチクラウドはサプライヤー依存を減らすのに役立ち、必要に応じて最適なインフラストラクチャとサービスを選択できます。

コンプライアンス。異なる地域には異なる規制要件がある可能性があり、複数のクラスターは各クラスターに対してより精密なセキュリティポリシーとアクセス制御を実施できる。

六、複数のクラスターの課題

複数のクラスターには前節の利点があるが、複雑性も倍増し、ユーザーに多くの課題をもたらす。

（1）設定と管理の複雑さ。すべてのクラスターには一貫した設定とデプロイが必要であり、差異をできるだけ排除する必要がある。

（2）ネットワーク接続と遅延。異なる地理的な位置にあるクラスター間で安全で信頼性の高い接続を保証し、同時に遅延を最大限に減少させる方法。

（3）サービスの発見と負荷分散。あるサービスが異なるクラスター内の他のサービスを発見する方法、および異なるクラスター間で負荷を均等に分散する方法。

（4）監視。すべてのクラスターのメトリクスとログは、集中管理しやすいようにまとめるのが望ましいです。

（5）セキュリティとアクセス制御。複数のクラスターのセキュリティポリシー、アクセス制御、資格情報管理はより複雑になり、慎重なルール設定と個別の設定が必要です。

七、複数クラスターのツールとその問題

上記の課題を解決するために、専用の複数クラスター管理ツールが登場しました。例えば Argo CD、Rancher Fleet、Karmada などです。

これらは開発者と Kubernetes の間の中間層として機能し、クラスター管理の複雑さを解決します。

問題は、これらのツールを使用するには、まず Kubernetes を学び、その後にツール自体を学ぶ必要があるということです。これは大きな学習コストであり、したがって複数クラスターのツールはアプリケーション開発者ではなく、クラスター管理者向け。

現実には、マルチクラスタは非常に専門的な分野であり、他の分野の開発者は全く理解できない。開発者がソフトウェア開発を完了した後、アプリケーションをクラスタ管理者に渡し、その後者にデプロイしてもらう。

双方にとって都面倒なことです。一方で、開発者はデプロイメント戦略を決定できず、下位レベルのリソースも把握できず、多くの場合コンテナ管理に介入しなければなりません。他方で、クラスター管理者はアプリケーションレベルに介入させられることになり、下位レベルのリソースの調整が発生した場合、開発者に通知してアプリケーションの運用を保証するための参加を求めなければなりません。

アプリケーション向けのマルチクラスタヘルパー TKE AppFabric

どうすれば開発者が複数のクラスタを簡単に使えるようにできるか？

Tencent Cloudのソリューションは、アプリケーションに向けて中間層を追加し、複数クラスタツールのレイヤーを隠蔽して使用しやすさを向上させますこのサービスは TKE AppFabric と名付けられます。

その名前のうち、TKEは「テンセントクラウドコンテナサービス」（Tencent Kubernetes Engine）を指し、AppFabricはアプリケーションコンテナを織物のように編み込むことを意味します。

それはアプリケーション開発者を対象としており、その位置づけは「上からアプリケーションをサポートし、下からクラスタを管理する」であり、アプリケーションの多クラスタアシスタントと見なすことができます。

多クラスタツールのラッピングが施されているため、複雑な専門用語はなく、非常に分かりやすく、開発者は迅速に理解し、使い始めることができます。下位のリソースを心配する必要はなく、「クラスタ」という概念を知る必要もありません。

そのシンプルさは、以下の点に現れています。

まず、開発者がより理解しやすい「可用区」（availability zone）を使用します。アプリケーションデプロイ時には、どのゾーン（例えば広州1区、上海1区）にデプロイするか、つまりデプロイ位置を指定するだけでよいです。

全プロセスがアプリケーションに向けられており、Kubernetesから疎結合になっています。この点では、開発者がより多くのエネルギーをビジネスに注ぐことができ、一方でクラウドサービスプロバイダーはリソースを十分に配分し、リソースの利用率を高めることができます。同時に、クラスターのアップグレードとメンテナンスについても、上層のユーザーは意識しません。

次に、設定が簡略化され、宣言式設定を採用しており、宣言ファイルを書けばよいので、さらに学習コストが低くなっています。

さらに、Kubernetesとアプリケーション実行に関連する機能をカプセル化し、より使いやすくなり、さまざまなモニタリング指標とログも一箇所に集められ、より簡単に発見できるようになっています。

九、マルチクラスター事例：WeCom（WeCom）

WeComはTKE AppFabricの上に構築されており、それを通じて、どうやってマルチクラスターで大規模サービスを構築するかを見てみましょう。

下の図がWeComのバックエンドアーキテクチャです。

上記の図では、ゲートウェイ（gateway）がアクセスの入り口です。その下には、zone1、zone2、zone3の3つの可用性ゾーンが同時にデプロイされています。これらは異なるデータセンターにデプロイされています。

これら3つの可用性ゾーンは全く同じ構成で、各ゾーンには1つのシステムインスタンスがデプロイされています。各システムインスタンスには、app1がapp2に依存し、app2がapp3に依存する、3層の依存関係を持つアプリケーションが3つ含まれています。これら3つのアプリケーション自体は、それぞれコンテナグループ（app pods）です。

このようなアーキテクチャには3つの利点があり、高可用性と負荷分散を保証します。

（1）故障時の展開。ある可用性ゾーンに障害が発生した場合、他の可用性ゾーンに切り替えることができます（例えば、zone1のapp2に障害が発生した場合、zone2のapp2に切り替える）。これにより、サービスの可用性が保証されます。

（2）ルーティング制御。ユーザーに最も近い可用性ゾーンを自動的に割り当てることで、アクセス速度を向上させます。

（3）グレースケールリリース。新しい機能は最初に単一の可用ゾーンでグレースケール検証を行い、完了した後にすべての可用ゾーンでリリースし、リリースリスクを低減します。

現地でのスピーチによると、すべてのTencent内部リソースのクラウド移行業務、例えばQQ、Tencent会議、オーディオビデオ業務はTKE AppFabric上でデプロイされます。今年の第4四半期には对外テスト運用を開始し、来年の第1四半期に正式に公開されます。

十、まとめ

「マイクロサービスアーキテクチャ」を採用するエンタープライズアプリケーションで、業務が重要で高可用性が必要な場合、複数のKubernetesクラスターを選択することはほぼ必然です。

会社に専任のチームがある場合は、自分で複数のクラスター管理を行うことができますが、そうでない場合はクラウドサービスプロバイダのツールを検討することもできます。

私は、ますます多くのクラウドサービスプロバイダーが、将来、2つのツールを同時に提供する可能性があると信じています。一つは、上級ユーザー専用の元のマルチクラスターツールで、もう一つはTKE AppFabricのようなアプリケーション向け、マルチクラスターの詳細を隠蔽するアシスタントツールで、一般の開発者に提供されます。

マルチクラスターやTKE AppFabricに興味がある方々は、下のQRコードを微信でスキャンして、製品マニュアルを確認してください。

（終）