ハイブリッド クラウド環境で Kubernetes を拡張する際の課題と解決策

トラフィックが急増した場合、ユーザーの需要を満たすためにアプリケーションを拡張する必要があります。この記事では、Kubernetes を拡張してハイブリッド クラウド環境を管理する際に発生する可能性のある課題と、Kubernetes の拡張をシンプルかつ効率的に完了する方法について説明します。

[[247489]]

導入

あなたのビジネスがオンラインであると仮定しましょう。つまり、Web サイトを運営するためのプライベート クラウドを備えた独自のデータ センターを所有しているとします。アプリケーションを実行し、そのデータを保存するには、多数のサーバーを展開する必要があります。

おそらくほとんどの場合、Web サイトの全体的なトラフィックはかなり安定しています。しかし、ウェブサイトのトラフィックが突然増加する場合もあります。これに対してどのように対処しますか?

まず、トラフィックの増加に対応できるようにアプリケーションを拡張できる必要があります。年に数回しか使用しない新しいハードウェアに余分なお金をかけたくない場合は、ハイブリッド クラウド モデルへの移行を検討してください。

プライベート クラウドからハイブリッド クラウドに移行すると、時間とコストを大幅に節約できます。アプリケーション（の一部）をパブリック クラウドに拡張すると、使用したリソースに対してのみ、使用した分だけ料金を支払うことになります。

しかし、パブリッククラウドはどのように選択すればよいのでしょうか?複数選択できますか？

簡単に答えると、はい、おそらく複数のパブリック クラウド プロバイダーを選択する必要があるでしょう。さまざまなチームがさまざまな要件を持つさまざまなアプリケーションに取り組んでいる場合、1 つのクラウド プロバイダーではすべてのニーズを満たすことができない可能性があります。さらに、多くの組織では、データを特定の場所に物理的に保存することを要求する特定の法律、規制、ポリシーに準拠する必要があります。複数のパブリック クラウドを使用する戦略は、組織がこれらの厳格で多様な要件を満たすのに役立ちます。また、複数のデータセンター リージョンまたはアベイラビリティ ゾーンから選択して、エンド ユーザーに可能な限り近い場所に配置することもでき、最適なパフォーマンスと最小限のレイテンシを実現します。

クラウド間のスケーリングの課題

クラウドを使用することを決定したので、元の質問に戻りましょう。アプリケーションには、スケーリングが必要なコンテナ上で実行されるアプリケーション用のマイクロサービス デプロイメント アーキテクチャがあります。ここで Kubernetes が役立ちます。 Kubernetes は、ノードのクラスター全体でコンテナ化されたアプリケーションを管理およびオーケストレーションするのに役立つソリューションです。 Kubernetes はデプロイメント、ノード、クラスターの管理とスケーリングに役立ちますが、クラウド プロバイダー間でそれらを簡単に管理およびスケーリングするのには役立ちません。これについては後ほど詳しく説明します。

Kubernetes クラスターは、Kubernetes がアプリケーションを実行するためのリソースを提供するマシン (物理/仮想) のグループです。まず、理解する必要がある Kubernetes の基本的な概念は次のとおりです。

Pod は、1 つ以上のコンテナを制御し、アプリケーションとしてスケジュールされるユニットです。通常、アプリケーションごとに 1 つの Pod を作成して、個別にスケーリングおよび制御できるようにする必要があります。

ノード コンポーネントは、Kubernetes のワーカー マシンです。ノードは、クラスターに応じて仮想マシン (VM) または物理マシンになります。各ノードにはポッドの実行に必要なサービスが含まれており、マスター コンポーネントによって管理されます。

マスター コンポーネントは、Pod のライフサイクルを管理します。 Pod が停止した場合、コントローラーは新しい Pod を作成します。 Pod をスケールアップまたはスケールダウンすると、コントローラーによって Pod が作成/破棄されます。コントローラー タイプの詳細については、以下を参照してください。

https://kubernetes.io/docs/con...aset/

これら 3 つのコンポーネントの役割は、コンテナーを展開してスケジュールすることです。マスター コンポーネントはスケジュールとスケーリングのコマンドを指示し、ノードはそれに応じてポッドを調整します。

上記は Kubernetes の非常に基本的な概念にすぎません。この記事「ゼロベース入門│Kubernetesを理解する」は、Kubernetes をより詳しく理解するのに役立ちます。

Kubernetes を使用してクラウド間でスケーリングする問題を解決しようとする場合、いくつかの重要な課題があります。

• 複数のクラウド、複数のクラスタの管理、ユーザーの設定、ポリシーの設定が困難
• インストールと設定の複雑さ
• 異なる環境にいるユーザーやチームは異なる体験をする

Rancher は上記の問題の解決に役立ちます。 Rancher は、Kubernetes を本番環境で実行するためのオープンソースのコンテナ管理プラットフォームです。 Rancher の次の機能は、コンピューティング リソースがローカルにホストされているか、複数のクラウドでホストされているかに関係なく、アプリケーションの管理と拡張に役立ちます。

• 複数のクラスタとクラウドにわたる共通のインフラストラクチャ管理
• 使いやすいKubernetes構成およびデプロイメントインターフェース
• ワンクリックでポッドとクラスターを簡単に拡張
• アクセス制御とユーザー管理 (ldap、AD)
• ワークロード、RBAC、ポリシー、プロジェクト管理
• Rancher は、複数のクラウド上の複数の Kubernetes クラスター、または Kubernetes を実行できるあらゆるインフラストラクチャを一元的に制御できます。

2 つの異なるリージョンで複数の Kubernetes クラスターを管理する方法を見てみましょう。

Rancher 2.0インスタンスを起動する

まず、Rancher 2.0 インスタンスを起動します。具体的な方法については、こちらのクイックスタートガイドを参照してください: https://rancher.com/quick-start/

Rancher と Kubernetes を使い始める

2 つの異なるリージョンの GCP に 2 つのマネージド Kubernetes クラスターを作成しましょう。これを行うには、サービス アカウント キーが必要です。

[グローバル] タブでは、利用可能なすべてのクラスターとそのステータスを確認できます。プロビジョニング状態から始まり、クラスターの準備ができると状態はアクティブに変わります。

これで、Kubernetes クラスターから各ノードにいくつかのポッドがデプロイされました。これらのポッドは、Kubernetes と Rancher の内部システムによって使用されます。

続けて、両方のクラスターにワークロードをデプロイしてみましょう。デフォルトのプロジェクトを順番に選択します。これにより、ワークロード タブが開きます。 [デプロイ] をクリックし、最初のクラスターの名前と Docker イメージを httpd に設定し、2 番目のクラスターの名前と Docker イメージを nginx に設定します。これは、Web サーバーをポート マッピング領域に公開するためです。レイヤー 4 ロード バランシングでインターネット トラフィックを選択します。

nginx/httpd ワークロードをクリックすると、Kubernetes の推奨に従って、Rancher が ReplicaSet を管理するためのデプロイメントを実際に作成したことがわかります。この ReplicaSet によって作成された Pod も表示されます。

ポッドとクラスターのスケーリング

Rancher インスタンスは 2 つのクラスターを管理しています。

 us-east1b-cluster、5 つの httpd ポッドを実行 
 europe-west4-a クラスター、1 つの nginx Pod を実行

スケール列の下の「-」（マイナスアイコン）をクリックして、httpd Pod を減らします。ポッドの数がすぐに減少したことがわかりました。

ポッドをスケールアップするには、「スケール」列の下の + (プラスアイコン) をクリックします。完了すると、作成中の Pod と ReplicaSets のスケーリング イベントがすぐに表示されます。ポッドの右側のメニューを使用してポッドの 1 つを削除し、ReplicaSet がそれを目的の状態に一致するように再作成する様子を確認します。

その結果、最初のクラスターの httpd Pod の数は 5 から 2 に変わり、2 番目のクラスターの nginx Pod の数は 1 から 7 に変わりました。現在、2 番目のクラスターのリソースはほぼ不足しているように見えます。

Rancher を使用すると、ノードを追加してクラスターを拡張することもできます。これを試して、ノードの数を 5 に編集してみましょう。

「調整されたクラスター」を見せるのは Rancher ですが、舞台裏でクラスター マスターをアップグレードし、ノード プールのサイズを変更するのは Kubernetes です。

しばらく待つと、最終的に 5 つのノードが稼働しているのがわかるはずです。

Rancher が管理しているすべてのクラスターの全体的な概要を確認できるように、[グローバル] タブを確認しましょう。

新しいリソースが利用可能になったため、必要に応じてさらにポッドを追加できるようになりました。ポッドの数を 13 に変更してみましょう。

何よりも素晴らしいのは、これらすべてがダウンタイムなしで実行されることです。 Pod をスケールアップまたはスケールダウンしたり、クラスターのサイズを変更したりする場合は、httpd/nginx に *** パブリック IP をデプロイし、HTTP 応答ステータス コードは常に 200 になります。

要約する

Kubernetes クラスターのスケーリング演習を見直してみましょう。

• Rancherを使用して2つのクラスターを作成しました
• 1つのnginxポッドと5つのhttpdポッドでワークロードをデプロイしました
• 2つのデプロイメントのスケーリング
• クラスターのサイズを変更しました

これらの操作はすべて、Rancher の使いやすく直感的な UI を数回クリックするだけで実行できます。もちろん、API を使用してこれらの操作を完了することもできます。

どちらの場合でも、すべての Kubernetes クラスターを管理し、そのステータスを監視し、必要に応じてデプロイメントを拡張できる中心的なポイントが存在します。ハイブリッド/マルチクラウド、マルチリージョン クラスターでのインフラストラクチャ管理とコンテナ オーケストレーションに役立つツールをお探しの場合は、オープン ソースの Rancher Kubernetes プラットフォームが最適です。