Kubernetes を使った異種混合デプロイ パターン

この記事では、Kubernetes を使用して本番環境レベルの異種混合デプロイを作成する場合の一般的なパターンについて説明します。この記事では、3 つの使用事例を示し、各事例のデプロイを作成するために使用できるアーキテクチャの詳細について説明します。アーキテクチャの説明には、Kubernetes の概要と Google Kubernetes Engine(GKE)の詳細が含まれます。

異種混合デプロイ

異種混合デプロイでは、通常、特定の技術的ニーズや運用上のニーズに対応するため、2 つ以上の異なるインフラストラクチャ環境またはリージョンを接続します。異種混合デプロイは、デプロイの詳細に応じて「ハイブリッド」、「マルチクラウド」、「パブリック-プライベート」と呼ばれます。この記事では、単一のクラウド環境、複数のパブリック クラウド環境(マルチクラウド)、またはオンプレミス環境とパブリック クラウド環境の組み合わせ(ハイブリッドまたはパブリック-プライベート)内の複数のリージョンにまたがる異種混合デプロイについて説明します。

単一の環境またはリージョンに限定されたデプロイでは、さまざまなビジネス上および技術上の課題が発生する可能性があります。

  • リソースの上限: 単一の環境、特にオンプレミス環境では、本番環境のニーズを満たすコンピューティング リソース、ネットワーキング リソース、ストレージ リソースが存在しない場合があります。
  • 地理的範囲の制限: 単一環境のデプロイでは、互いに地理的に離れた場所にいるユーザーが 1 つのデプロイにアクセスする必要があります。ユーザーのトラフィックは、中心となるロケーションに到達するまでに世界中を移動する可能性があります。
  • 限られた可用性: ウェブ規模のトラフィック パターンを処理するアプリは、フォールト トレランスと復元力を維持する必要があります。
  • ベンダー ロックイン: プラットフォームとインフラストラクチャがベンダーレベルで抽象化されるため、アプリの移植が妨げられる場合があります。
  • 柔軟性の低いリソース: リソースが特定のコンピューティング サービス、ストレージ サービス、ネットワーキング サービスに限定される場合があります。

異種混合デプロイは、これらの課題に対処するのに役立ちますが、計画的で確定的なプロセスと手順を使用して設計する必要があります。一度限りまたはその場しのぎのデプロイ手順では、デプロイやプロセスが脆弱になり、障害に耐えられない可能性があります。その場しのぎのプロセスでは、データが消失したり、トラフィックがドロップしたりする可能性があります。優れたデプロイ プロセスは、再現可能でなければならず、実績のあるアプローチを使用してプロビジョニング、構成、メンテナンスを管理する必要があります。

異種混合デプロイの一般的なシナリオは、マルチクラウド デプロイ、オンプレミス データの外部接続、および継続的インテグレーション / 継続的デリバリー(CI / CD)プロセスの 3 つです。

以降のセクションでは、異種混合デプロイの一般的な使用事例について、Kubernetes とその他のインフラストラクチャ リソースを使用して適切に設計されたアプローチとともに説明します。

マルチクラウド

すべてのデプロイが比較的類似しているマルチクラウド デプロイは、Kubernetes で使用される最も一般的な異種混合デプロイ パターンの 1 つです。

マルチクラウド デプロイの用途の 1 つは、トラフィックの転送方法を選択することです。最も単純なデプロイでは、一定の割合の受信トラフィックを特定のデプロイに送信できます。オンプレミス インフラストラクチャとパブリック クラウド インフラストラクチャから構築されたデプロイでは、より多くのトラフィックをクラウド インフラストラクチャに送信することで、長期的な移行を促進したり、制約のあるオンプレミス リソースを回避したりすることができます。

マルチクラウド デプロイのもう 1 つの一般的な用途は、単一環境の障害に耐えられる高可用性デプロイを構成することです。このようなシナリオでは、同じ Kubernetes デプロイを目的の環境に合わせてオーケストレートすることができます。単一環境に障害が発生した場合は、すべてのトラフィックのニーズを満たすように各デプロイをスケールアップできる必要があります。

最終的には、マルチクラウド デプロイを使用して、物理的にユーザーに近いデプロイを作成できます。ユーザーのできるだけ近くにデプロイを配置することで、リクエストとレスポンスのレイテンシを最小限に抑えることができます。

トラフィックの転送

堅牢なマルチクラウド デプロイは、DNS トラフィック管理サービスを使用して DNS クエリを個々のデプロイに解決します。一般的なトラフィック分割の使用事例では、トラフィックをパーセンテージで個々のデプロイに分割するように DNS トラフィック管理メカニズムを構成できます。

トラフィックの分割

高可用性デプロイでは、各環境のカスタム ヘルスチェックを使用して DNS メカニズムを構成できます。環境に異常が発生すると、正常なステータスの更新が送信されなくなり、DNS メカニズムはトラフィックの転送先をまだ正常な状態にあるデプロイに切り替えることができます。

ユーザーに対するレイテンシが重要な場合、DNS メカニズムは受信リクエストの IP アドレスを使用しておおよその位置を判定し、地理的に最も近くにあるデプロイにトラフィックを転送できます。NS1DynAkamai などの DNS インフラストラクチャ サービス プロバイダを使用して、複数のデプロイメント間でトラフィックを転送できます。

リクエストの処理

DNS が特定のデプロイにトラフィックを転送したときに、ロードバランサは着信するリクエストを受信し、それらを Kubernetes クラスタに転送する必要があります。Kubernetes には、着信するトラフィックにポッドを公開するためのメカニズムとして、ServiceIngress の 2 つが用意されています。

Kubernetes クラスタにデプロイされたポッドには、クラスタの内部または外部にある他のアプリやシステムから簡単にアクセスできません。ポッドにアクセスできるようにするには、まずサービスを作成する必要があります。サービスは、デフォルトでクラスタの内部からの接続を自動的に受け入れますが、クラスタの外部からの接続を受け入れるように構成することもできます。

外部のリクエストを受け入れるようにサービスを構成する場合は、サービスタイプを NodePort または LoadBalancer として設定します。

サービスタイプを NodePort に設定すると、Kubernetes クラスタ内のすべてのノードで各サービスに固有のポートが公開されます。この固有のポートにより、各ノードは接続を受け入れ、着信するリクエストを適切なポッドにプロキシ負荷分散します。

LoadBalancer サービスタイプは NodePort のスーパーセットです。タイプを LoadBalancer に設定すると、各ノードにポートが構成されるのに加えて、外部ロードバランサが自動的にプロビジョニングされます。この外部ロードバランサは、トラフィックをクラスタに転送し、さらにポッドに転送するように設定されます。

Kubernetes のサービスはレイヤ 4 の構成要素です。つまり、IP アドレスとポート番号を使用することによってのみ、アクセシビリティをサポートすることができます。HTTP(S)(レイヤ 7)の負荷分散メカニズムである Ingress は、受信接続をバックエンドの Kubernetes クラスタ サービスに到達できるようにするルールの集まりです。Ingress メカニズムを構成して、外部から到達可能な URL、受信トラフィックの負荷分散、SSL 終端、名前ベースの仮想ホスティングなどのアプリレイヤの追加機能をサービスに提供できます。HTTP ホストヘッダーや HTTP URL パスを使用して、着信トラフィックをサービスによって公開されたポッドに転送できます。

ポッドに転送されるトラフィック

共有サービス

マルチクラウド デプロイを実行する場合は、各デプロイで 1 つ以上の共有サービス(データベースなど)を実行する必要があります。共有サービス間の通信は、レイテンシが低く、安全である必要があります。

レイテンシが低く帯域幅が広い接続では、ダイレクト ピアリングやサードパーティが管理するネットワーク相互接続を使用して、各デプロイの基盤となるネットワークを接続できます。GCP では、利用可能ないずれかのネットワーク エッジで Google とダイレクト ピアリングを行うことで、直接接続が可能になります。ダイレクト ピアリングを円滑に行うには、いくつかの技術的要件があります。これらの要件を満たせなければ、Cloud Interconnect を使用することもできます。Cloud Interconnect のサービス プロバイダを使用すると、エンタープライズ クラスの接続を介して Google のネットワーク エッジに接続できるようになります。

接続が確立されたら、VPN を使用して各環境間のリンクを保護します。各デプロイで、VPN ゲートウェイを使用してデプロイ間のトラフィックを保護する必要があります。GCP では、Cloud VPN が IPSec VPN 接続を使用してトラフィックを保護します。Cloud VPN では、複数の VPN トンネルの帯域幅を集約することができ、また Cloud Router を使用したスタティック ルーティングまたはダイナミック ルーティングも可能です。

クラスタ管理

マルチクラウド デプロイでは、各 Kubernetes クラスタを個々のエンティティとして管理および制御できます。そのためには、各クラスタに手動でポッドとサービスを作成する必要があります。この方法の利点は、各デプロイに共有のアプリやサービスを含めながら、そのデプロイにしか適さないアプリやサービスを含めることもできる点にあります。

たとえば、デプロイを地理的に分散する必要がある一方で、国固有またはリージョン固有で必ずしもすべての地域に対応していないサービスが存在する場合があります。

トラフィック分割が均一に分散していないデプロイでは、受信したトラフィックとリクエストが適切に処理されるように、クラスタ単位でポッドとサービスをデプロイする必要があります。

サービス ディスカバリ

マルチクラウド デプロイでは、サービス ディスカバリを使用して、さまざまなアプリとサービスが実行時にお互いを簡単に見つけられるようにする必要があります。サービス ディスカバリを使用すると、デプロイの前に複雑または脆弱な命名方法や命名規則を知っておく必要がなくなります。サービス ディスカバリのメカニズムは、送信元と送信先のアプリに対して透過的である必要があります。マルチクラウド デプロイでは、これらのメカニズムによって、アプリとサービスがローカル実行サービスと他のクラスタのリモート実行サービスを検出できるようにする必要があります。

スタンドアロンの個々のクラスタとして構築およびデプロイされたデプロイでは、サービス ディスカバリ メカニズムがデータセンター対応である必要があります。つまり、着信リクエスト、ローカルの可用性、および負荷容量に基づいてリクエストを適切なクラスタに送信する機能を備えた調整済みの分散システムとして動作できる必要があります。ConsulLinkerd などのサードパーティ システムを使用すると、マルチクラウドの Kubernetes Deployment でのクラスタ間および環境間のサービス ディスカバリが容易になります。

Kubernetes は、Kubernetes クラスタ内の非公開 DNS ゾーンの解決をサポートしています。このサポートは、他のクラスタの完全修飾ドメイン名がわかっており、それらのクラスタにトラフィックを簡単にルーティングできるハイブリッドまたはマルチクラウドのシナリオで役立ちます。ConfigMap を使用して、非公開の「スタブ」ドメインへのアクセスを設定できます。非公開 DNS ゾーンをスタンドアロンのメカニズムとして解決する Kubernetes サポートを使用して、リクエストを特定の Kubernetes クラスタに送信したり、Consul などの外部システムと連携させたりできます。

アーキテクチャ

次の図は、マルチクラウド デプロイ アーキテクチャの例を示しています。

マルチクラウド デプロイ

オンプレミス データの外部接続

クラウド デプロイは、限定公開のデプロイやオンプレミスのデプロイで利用できる範囲を超えて機能を拡張するように設計できます。たとえば、限定公開のデータシステムまたはインフラストラクチャにアクセスできるクラウドベースのアプリを設計してデプロイすることができます。

限定公開のデプロイやオンプレミスのデプロイでは、可用性、ポータビリティ、リソースの柔軟性が制限される可能性があることを思い出してください。クラウドベースのデプロイへの移行は、これらの制限に対処できますが、従来のアーキテクチャ、セキュリティ コンプライアンス、またはその他のソフトウェア要件のために不可能な場合があります。このようなシナリオでは、限定公開の環境やオンプレミスの環境よりも優れた柔軟性や機能を持つクラウド環境に、新しいアプリを構築してデプロイできます。

アーキテクチャ

次の図は、オンプレミスのデータ インフラストラクチャを外部接続するクラウドアプリを示すアーキテクチャの例です。

オンプレミス データの外部接続

ネットワーキング

オンプレミスのデータ インフラストラクチャがクラウドアプリによって外部接続されるデプロイでは、ユーザーに対するアプリ全体のレスポンス時間を最小限に抑えるため、安全でレイテンシの小さい接続が必要です。Cloud Interconnect またはダイレクト ピアリングを使用すると、レイテンシを最小化し、オンプレミス環境とクラウド環境の間で利用可能な帯域幅を最大化できます。接続が確立されたら、各デプロイで VPN ゲートウェイを使用してデプロイ間のトラフィックを保護する必要があります。GCP では、Cloud VPN が IPSec VPN 接続を使用してトラフィックを保護します。Cloud VPN は、帯域幅を集約するために複数の VPN トンネルをサポートし、Cloud Router を使用してスタティック ルーティングまたはダイナミック ルーティングをサポートします。オンプレミスのデータ インフラストラクチャを外部接続する場合は、セキュリティが重要な問題になるため、特定の GCP インスタンスからのトラフィックのみを許可するようにルートとオンプレミスのファイアウォールを構成する必要があります。

クラウド アーキテクチャ

このようなハイブリッド デプロイのクラウド部分では、アーキテクチャ コンポーネントに適切なロードバランサ、アプリケーション ホスティング基盤、VPN ゲートウェイ、サービス ディスカバリ メカニズムを含める必要があります。ロードバランサの選択は、エンドユーザー向けアプリの要件に依存します。GCP 上でのデプロイの場合、Cloud Load Balancing は、グローバルに使用できる単一のエニーキャスト IP を使用した HTTP(S)、TCP、UDP をサポートします。

このようなハイブリッドのシナリオでは、GCP で利用できる Kubernetes のマネージド デプロイである GKE にポッドとサービスをデプロイできます。GKE は、送信トラフィックをオンプレミス インフラストラクチャに転送します。GKE は、Cloud VPN を使用してトラフィックを保護し、Cloud Router を使用してスタティック ルートまたはダイナミック ルートを構成します。この構成により、GKE クラスタからのトラフィックだけが VPN 接続を通過するようになります。

オンプレミス アーキテクチャ

このデプロイのオンプレミス部分には、クラウドアプリをバックアップするデータ インフラストラクチャが含まれています。このようなデプロイでは、多くの場合、データシステムの前面に CRUD API をデプロイすることでいくつかの利点が得られます。

データシステムに高いレベルのセキュリティやコンプライアンスが求められる場合は、CRUD API を使用して受信接続やクエリを監査し、ログに記録できます。データ インフラストラクチャが従来のシステム上で実行されている場合は、CRUD API を使用して新しいアプリに最新の接続オプションを提供できます。

いずれの場合も、CRUD API を使用することで、データベースの認証と承認の組み込みメカニズムをアプリが必要とするメカニズムから切り離し、アプリが必要とするだけの CRUD 機能を提供できます。具体的には、データのサブセットのみをダウンストリーム アプリに公開する必要がある場合に、API はデータへのアクセスを管理するのに役立ちます。

API を使用して接続とクエリを監査することで、基礎となるデータの長期的な移行戦略を定義することもできます。データのサブセットのみが必要であり、厳重なセキュリティやコンプライアンスのポリシーに該当しない場合、そのデータは Cloud Platform に移行できます。

上のアーキテクチャ図は、オンプレミスで動作する Kubernetes でホストされている CRUD API を示しています。オンプレミスで Kubernetes を使用することには、技術的な必要性はありませんが、Kubernetes をクラウド インフラストラクチャのデプロイ ターゲットとみなすチームが増えているため、システムの使用と運用に関する専門知識を増やすことができるという利点があります。

オンプレミス インフラストラクチャでは、潜在的なセキュリティの問題を最小限に抑えるため、トラフィックが既知のソースからのみ CRUD API に到達できるように VPN ゲートウェイとファイアウォールを構成する必要があります。

サービス ディスカバリ

ハイブリッド デプロイのシナリオでは、サービス ディスカバリを使用して、さまざまなアプリとサービスが実行時にお互いを簡単に見つけられるようにする必要があります。長期的には、オンプレミスの CRUD API のさまざまなコンポーネントを活用するクラウドアプリがさらにデプロイされる可能性があります。CRUD API にも、タスク固有の API やオンプレミスのデータ インフラストラクチャをサポートする API などの機能が徐々に追加される可能性があります。このようなデプロイのシナリオでは、クラウドアプリとオンプレミスの CRUD 機能のリリース サイクルが大きく異なる可能性があります。ConsulLinkerd などの外部のサービス ディスカバリ メカニズムを使用すると、リソースとバージョンが疎結合になるため、それぞれ独立して各環境で繰り返し利用できます。

クラウドアプリを GKE または Kubernetes にのみデプロイする予定の場合は、Kubernetes の内部 DNS 機構 kube-dns を構成して、非公開 DNS ドメインをオンプレミス環境のプライベート IP アドレスに解決できます。この構成では、クラウド環境で実行されているポッドが標準の DNS クエリを使用して、オンプレミス環境で実行されているサービスに簡単にアクセスできます。詳しくは、Kubernetes での非公開 DNS ゾーンとアップストリーム ネームサーバーの構成をご覧ください。

CI / CD ワークロード

既存のオンプレミス デプロイから始まるマルチクラウド ワークロードは、より集中的なワークロードをクラウド環境に移行することでメリットが得られます。

クラウド環境では、コンピューティング リソースが自動的にスケーリングされ、コードの完成からアーティファクトの作成までの時間を短縮できるため、継続的インテグレーション(CI)ワークロードが移行の最適な候補になります。

継続的デリバリー(CD)ワークロードも、テスト環境の簡単にプロビジョニングしてデプロイできるクラウド環境で実行することでメリットが得られます。移行により、ユニットテストの並列ビルドプロセスの数を増やすことができます。もう 1 つの潜在的な利点は、エンドツーエンドの統合テストやその他の自動テストでテストデプロイの数を増やせることです。

クラウドベースのコンテナ向け CI / CD ワークロードでは、通常、次の高レベルプロセスを使用します。

  • 開発。 デベロッパーは、コードの変更を commit し、ローカルホストまたはリモートホストのソース リポジトリに push します。
  • ビルド。 ビルドサービスはソースコード リポジトリを継続的にポーリングします。新しい変更が見つかると、サービスはビルドプロセスを開始します。
  • ユニットテスト。このプロセスでは、ソースをビルドし、ユニットテストを行い、結果のコンテナ イメージを構築します。
  • 統合テスト。このプロセスでは、テストクラスタを作成し、関連するアーティファクトとともにコンテナ イメージをデプロイし、統合テストを行います。
  • ベイク。 正常に完了すると、コンテナ イメージにリリース バージョンのメタデータがタグ付けされます。
  • デプロイ。 デベロッパーまたは管理者は、必要に応じて新しいアーティファクトを本番環境にデプロイできます。

使用例

GCP で最も一般的に使用される CI / CD ツールは、JenkinsSpinnaker です。Jenkins は、スタンドアロンのコンピューティング インスタンスにデプロイするか、Kubernetes の一連のポッドやサービスとしてデプロイすることができる一般的なオープンソースの CI / CD システムです。Spinnaker は、複数のターゲットに対するソフトウェア配信をオーケストレートして自動化できるオープンソースの CD システムです。Spinnaker では、CI システム(Jenkins など)やその他のツール(Cloud Builder など)を活用できます。

Jenkins と Kubernetes

Jenkins と Kubernetes を使用した CI / CD ワークロードについては、おすすめの方法、共通の構成パターン、継続的デリバリーのオーケストレーションについて説明する以下のドキュメントをご覧ください。

Spinnaker

Spinnaker は、オープンソースのマルチクラウド CD プラットフォームであり、ソフトウェア デプロイのワークフローとクラスタ管理をオーケストレートすることができます。Spinnaker のクラスタ管理機能には、インスタンス グループ、インスタンス、ファイアウォール、ロードバランサなどのクラウド リソースをプロビジョニングして制御する機能が含まれています。ソフトウェア デプロイのワークフローは複数のパイプラインで構成され、個々のパイプラインは「ステージ」と呼ばれる一連のアクションで構成されています。Spinnaker パイプラインでは、1 つのステージから次のステージにパラメータを渡すことができます。パイプラインは、手動で開始するか、自動トリガー(外部の CI システム、cron スクリプト、その他のパイプラインなど)を使用して開始できます。Spinnaker には、イメージのベイク、イメージのデプロイ、インスタンス グループの操作、およびユーザー入力のリクエストを行うために、事前にパッケージ化されたステージがいくつか用意されています。次の図は、Spinnaker パイプラインでどのようにソフトウェアがリリースされるかを示しています。

Spinnaker パイプライン

ソフトウェアは、ビルドされ、次にテストされます。すべてのテストに合格すると、変更不可能なイメージがベイクされ、クラウドで使用可能になります。イメージが使用可能になると、クラスタにイメージをデプロイして実行中のソフトウェアを更新できます。

アーキテクチャ

Spinnaker は、コンテナのデプロイを操作するときに Jenkins や Cloud Build などの外部の CI システムを利用して、ビルド、テスト、ベイクの各ステップを実行します。その後、Spinnaker は標準のパイプライン ステージを使用してターゲット デプロイをオーケストレートします。次の図は、このようなシステムのアーキテクチャを示しています。

Spinnaker と Jenkins

GCP に Spinnaker をデプロイする方法については、Compute Engine での Spinnaker の実行をご覧ください。

Jenkins を使用したビルド

Jenkins は、Spinnaker のパイプラインを開始するトリガーのサポート機能と連携して動作します。Jenkins のビルドを使用して、Spinnaker パイプラインを自動的にトリガーできます。Spinnaker パイプラインでは、Jenkins スクリプトのステージでリリース プロセスのテストステージとベイクステージを実行できます。Spinnaker に組み込まれたクラスタ管理ステージでは、ターゲット デプロイをオーケストレートできます。詳しくは、Spinnaker の Hello デプロイの例をご覧ください。

Cloud Build を使用したビルド

Container Build は、高速で一貫した信頼性の高い環境でコンテナ イメージをビルドする GCP のフルマネージド サービスです。Cloud Build は、Cloud Source Repositories と直接統合され、ソースやリポジトリタグの変更に基づいて自動的にビルドを開始します。Cloud Build は、Docker コンテナでビルドを実行し、コンテナにパッケージ化できるカスタム ビルドステップをサポートできます。Cloud Build でのビルドは、高度なカスタマイズが可能で、順次実行と同時実行をサポートしています。ビルドプロセスの状態変更は、Cloud Pub/Sub トピックに自動的にパブリッシュされます。

Spinnaker は Cloud Build を直接サポートしていませんが、Cloud Build で自動的に使用されるコンテナ レジストリである Cloud Container Registry をサポートしています。Container Registry をポーリングし、更新されたコンテナ イメージのバージョンまたはタグの検出に基づいてパイプラインを開始するように Spinnaker を構成できます。このようなシナリオでは、リリース プロセスのビルド、テスト、ベイクの各ステージを実行するように Cloud Build を構成する必要があります。Container Registry を利用するように Spinnaker を構成する方法について詳しくは、Spinnaker のドキュメントをご覧ください。

Kubernetes デプロイのオーケストレーション

Spinnaker に組み込まれたクラスタ管理メカニズムは、Kubernetes をサポートしています。Spinnaker のサーバー グループとロードバランサは、それぞれ Kubernetes 内のレプリカセットとサービスに対応しています。

以下のドキュメントには、Kubernetes にポッドとサービスをデプロイするように Spinnaker を構成するために必要な手順が記載されています。

次のステップ

  • Google Cloud Platform のその他の機能を試すには、チュートリアルをご覧ください。
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...