ゲスト投稿 : Kubernetes ワークロードのマルチクラウド運用を Cloudflare で一括管理
Google Cloud Japan Team
編集部注 : 私たちはお客様のワークロードをすべて Google Cloud Platform（GCP）にホストしたいと考えていますが、時にそうはいかないこともあります。今回お届けする Cloudflare の投稿では、Kubernetes ベースのワークロードを Google Kubernetes Engine と Amazon Web Services（AWS）の両方で運用するためのマルチクラウド構成を、Cloudflare Load Balancer を使って有効にする方法を紹介します。
コンテナ技術のすばらしい点の 1 つは、異なるプラットフォームで同じエクスペリエンスや機能を提供できることです。そのおかげで、開発者はアプリケーションの書き換えやアップデートを行わなくても、新しいクラウド プロバイダーの環境にアプリケーションをデプロイできます。
つまり、複数のクラウド プロバイダーの環境で同じアプリケーションを実行できるのです。コンテナ化されたアプリケーションを複数のクラウドで運用できれば、ロックインを回避し、アプリケーションを最適なクラウドで実行して、全体的なコストを抑えることができます。
Kubernetes をお使いの方は、多数のノードによるクラスタやサービスへのトラフィックを、内部負荷分散サービスを使って管理していることでしょう。これは最も一般的かつ実際的なアプローチです。しかし、複数のクラウドでアプリケーションを運用している場合は、それらのクラウドにトラフィックをインテリジェントに分散するのが難しいことがあります。
このブログ記事では、皆さんがマルチクラウド構成のメリットを享受できるように、Kubernetes とともに Cloudflare Load Balancer を使用する方法を解説します。
ほとんどのクラウド ベンダーが提供するロード バランサは多くの場合、特定のクラウド インフラストラクチャに合わせて構築されています。ロード バランサ自体が単一障害点になることもあります。
一方、Cloudflare の Global Anycast Network は、世界 120 か所のデータセンターから成り、負荷分散など Cloudflare のすべての機能を提供し、オリジン サーバーがどのクラウドでホストされているかにかかわらず、高いパフォーマンスと可用性を実現します。
Cloudflare のユーザーは、可用性を最大化するとともにレイテンシを最小化する、自分に最も近い最適なデータセンターに誘導されます。特定のデータセンターへの接続に問題がある場合は、ユーザー トラフィックは使用可能な次善の選択肢に自動的に再転送されます。
また Global Anycast Network は、オリジン サーバーのヘルス チェックを行い、いずれかがダウンすると担当者に電子メールで通知するとともに、自動フェイルオーバー機能によって外部へのサービス提供を継続します。
コンテナ化されたアプリケーションを複数のクラウドにまたがって実行することで、プラットフォーム非依存を実現し、大規模障害に対する耐性を確保できます。Cloudflare では以下の機能をすべて利用できます。
- セキュリティ ポリシー（DDoS 攻撃の軽減、WAF など）を適用し、モニタリングする
- Cloudflare Load Balancer を用いて複数のリージョン間やクラウド ベンダー間のルーティングを管理する
- 1 か所からパフォーマンス設定を調整する（これにより、構成管理にかかる時間が短縮され、構成ミスが発生する可能性が低くなる）
- サービスをオンプレミスからクラウドに、あるいは異なるクラウド プロバイダー間で移行するとともに、ウェブ アプリケーションを追加し、変更する
Cloudflare による AWS と GCP 間での負荷分散
皆さんの理解の助けとなるように、私たちは、Cloudflare Load Balancer と Kubernetes を GCP と AWS で使用してアプリケーションをデプロイする方法のガイドを作成しました。下図は、Kubernetes にデプロイされているアプリケーションのトラフィックを、Cloudflare Load Balancer がどのように Google Cloud と他のクラウド ベンダーに分散するかを示しています。
この例では、GCP のオリジン サーバーは Ingress コントローラと HTTP ロード バランサを使用し、他のクラウド ベンダーのオリジン サーバーは独自のロード バランサを使用しています。ここでのポイントは、こうした任意のオリジン構成に Cloudflare Load Balancer が対応できることです。
Cloudflare を使って複数のクラウド間でアプリケーションの負荷分散をセットアップする方法の概要を以下に示します。
ステップ 1 : コンテナ クラスタを作成
GCP は、Kubernetes コンテナの実行を Google Kubernetes Engine でサポートしており、これには Google Cloud Shell からアクセスできます。Cloud Shell にはコマンドライン ツールの gcloud、docker、kubectl がプリインストールされています。次のコマンドを実行すると、3 ノードのクラスタが作成されます。クラスタは、Kubernetes が実行されている Compute Engine VM インスタンスのプールで構成されます。
AWS
AWS は最近、Amazon Elastic Container Service（ECS）で Kubernetes コンテナ オーケストレーション システムをサポートすると発表しました。プレビューに申し込むには、Amazon Elastic Container Service for Kubernetes（Amazon EKS）をクリックしてください。Amazon EKS が利用可能になるまでは、以下の手順に従い、AWS で Kubernetes クラスタを作成します。
- 次のツールをローカル マシンにインストールする。Docker、AWS CLI（AWS アカウントを使用）、Kubectl、Kops（クラスタの作成を容易にする Kubernetes 提供のツール）
- ドメイン名を持つ（mydomain.com など）
- ユーザーが AWS Elastic Container Registry にアクセスするためのポリシーを AWS コンソールで用意する
Kubernetes クラスタの作成には以下の 2 つの AWS リソースも必要です。
- S3 バケット : 作成されたクラスタとその構成に関する情報を保存するために必要
- Route53 ドメイン（ホステッド ゾーン）: コンテナの実行用に、たとえば k8s.mydomain.com などのドメインが必要。Kops は DNS を用いて、クラスタ内での検出と、クライアントから Kubernetes API サーバーへのアクセスを可能にするための検出を行う
S3 バケットをセットアップし、Kops を使ってホステッド ゾーンを作成したら、クラスタの構成を作成して S3 に保存できます。
続いて、次のコマンドを実行すると、AWS でクラスタを作成できます。
Kops は 1 つのマスター ノードと 2 つのスレーブを作成します。これが Kops のデフォルト設定です。
ステップ 2 : アプリケーションをデプロイ
このステップは Kubernetes Engine でも AWS でも同じです。ステップ 1 に従ってクラスタを作成したら、kubectl を使ってアプリケーションをクラスタにデプロイします。通常、アプリケーションは Docker イメージからデプロイできます。これにより、スレーブ ノードの 1 つにスケジュールされたポッドが作成されます。
ステップ 3 : アプリケーションをインターネットにエクスポーズ
AWS の場合、アプリケーションをインターネットからのトラフィックにエクスポーズすると、自動的に外部 IP アドレスがそのサービスに割り当てられ、AWS Elastic Load Balancer が作成されます。一方、GCP の場合は、Kubernetes Engine で実行されるコンテナに対してデフォルトではインターネットからアクセスできません。デフォルトでは外部 IP アドレスを持っていないからです。Kubernetes Engine では、アプリケーションをサービスとして内部的にエクスポーズし、Ingress コントローラで Ingress リソースを作成しなければなりません。これによって HTTP（S）ロード バランサが作成されます。
アプリケーションをサービスとして内部的にエクスポーズするには次のコマンドを実行します。
HTTP（S）ウェブ サーバー アプリケーションへのパブリック アクセスが可能になるように Ingress リソースを作成するには、yaml 構成ファイルを作成する必要があります。このファイルにより、トラフィックをサービスに誘導する Ingress リソースを定義します。
Ingress リソースをデプロイしたら、クラスタ内で動作する Ingress コントローラが HTTP（S）ロード バランサを作成します。HTTP（S）ロード バランサは、すべての外部 HTTP トラフィックをサービスに転送します。
ステップ 4 : アプリケーションをスケールアップ
レプリカ（ポッド）を追加する手順は Kubernetes Engine でも AWS でも同じです。このステップでは、アプリケーションを実行する同一のインスタンスを追加します。
前のステップでプロビジョニングされたロード バランサは、こうした新しいレプリカへのトラフィック転送を自動的に開始します。
Cloudflare Load Balancer のセットアップ
以上で、Cloudflare Load Balancer をセットアップする準備が整いました。セットアップは非常にシンプルなプロセスです。- Cloudflare Load Balancer のホスト名を作成する（lb.mydomain.com など）
- オリジン プールを作成する（GCP 用のプールと AWS 用のプールなど）
- ヘルス チェックを作成する
- ジオ ルーティングをセットアップする（たとえば、北米東部からのトラフィックはすべて AWS インスタンスに転送）
セットアップの詳細については、こちらのドキュメントをご覧ください。
Cloudflare Warp Ingress Controller とは
私たちは StackPointCloud と協力して Cloudflare Warp Ingress Controller も開発しました。このコントローラは、複数のベンダーのクラウドにおける Kubernetes の起動を非常に容易にし、それらを Cloudflare コントローラを使って連携させます。StackPointCloud 内では 1 回のクリックだけで Cloudflare Warp Ingress Controller を追加できます。もう 1 回クリックすると Kubernetes クラスタをデプロイできます。その舞台裏では、Cloudflare Warp トンネルを使って Ingress コントローラを実装し、Cloudflare が管理する URL に Kubernetes サービスを接続しています。Warp コントローラはクラスタの 1 つの名前空間で Ingress トンネルを管理します。多数のコントローラが名前空間ごとに異なる資格情報を使用して、さまざまな名前空間に存在できます。
マルチクラウドの世界における Kubernetes
GCP と Microsoft Azure では以前から Kubernetes がネイティブにサポートされており、それに続く形で AWS における Kubernetes のネイティブ サポートも発表されました。Kubernetes が異種クラウド ワークロードを管理する最も有力な技術として浮上しているのは明らかです。アプリケーションがどのプロバイダーのクラウドで実行されているかにかかわらず、アプリケーションをデプロイ、管理する一貫した方法を提供してくれるからです。
こうしたマルチクラウド構成で Cloudflare Load Balancer を使用すれば、クラウド間でトラフィックを分散するとともに、ベンダー固有の統合やロックインを回避することができます。
Cloudflare についてもっと知りたい方は、Cloudflare のウェブ サイトをご覧になるか、あるいはこちらまでお問い合わせください。ご連絡をお待ちしています。
* この投稿は米国時間 2 月 22 日、Cloudflare の Special Projects 担当 Solutions Engineer である Kamilla Amirova 氏によって投稿されたもの（投稿はこちら）の抄訳です。
- By Kamilla Amirova, Solutions Engineer, Special Projects, Cloudflare
