次の図は、ブループリントによって単一の環境にデプロイされるアーキテクチャの概要を示しています。このアーキテクチャは、本番環境、非本番環境、開発環境の 3 つの環境にデプロイします。
この図には次のものが含まれています。
- Cloud Load Balancing は、複数のリージョンにわたるアプリケーション トラフィックを Kubernetes Service オブジェクトに分散します。各 Service の背後には、関連する Pod の論理グループがあります。
- Anthos Service Mesh を使用すると、Kubernetes Service が相互に通信できます。
- Kubernetes Service は、Kubernetes の Namespace として表されるテナントにグループ化されます。テナントは、クラスタ内で動作する複数のユーザーとワークロードを抽象化したもので、アクセス制御に個別の RBAC を使用します。各テナントには、データベース、ストレージ バケット、Pub/Sub サブスクリプションなどのテナント固有のクラウド リソース用のプロジェクトもあります。
- ピア Service とクラウド リソースにアクセスするための独自の ID を持つ Namespace。フリートの Workload Identity により、異なるクラスタの同じ Namespace で ID が一貫しています。各環境には、環境間の権限昇格を軽減するために個別の Workload Identity プールがあります。
- 各 Service には、その Service をビルドしてデプロイする専用のパイプラインがあります。同じパイプラインを使用して、Service を開発環境にデプロイし、非本番環境にデプロイして、最後に本番環境にデプロイします。
デベロッパー プラットフォームのアーキテクチャ上の重要な決定
次の表に、このブループリントで実装するアーキテクチャ上の決定を示します。
決定分野 | 決定 | 理由 |
---|---|---|
複数のリージョンを横断してデプロイします。 |
リージョン停止中のアプリケーションの利用を許可します。 |
|
エンタープライズ基盤ブループリント上にデプロイします。 |
基盤によって提供される組織構造とセキュリティ管理を使用します。 |
|
基盤に設定されている 3 つの環境フォルダ( |
アクセス制御が異なる環境を分離します。 |
|
アプリケーションをコンテナとしてパッケージ化してデプロイします。 |
責任の分離、効率的な運用、アプリケーションのポータビリティをサポートします。 |
|
GKE クラスタでアプリケーションを実行します。 |
コンテナのパイオニアが構築したマネージド コンテナ サービスを使用します。 |
|
アプリケーション コンテナを複製してアクティブ / アクティブ構成で実行します。 |
可用性を高め、迅速な段階的ロールアウトを実現し、開発速度を向上させることができます。 |
|
2 つの異なるリージョンにある 2 つの GKE クラスタで本番環境をプロビジョニングします。 |
単一のクラウド リージョンよりも高い可用性を実現できます。 |
|
2 つの異なるリージョンにある 2 つの GKE クラスタで非本番環境をプロビジョニングします。 |
本番環境にデプロイする前に、ロードバランサなどのクロスリージョン設定に対する変更をステージングします。 |
|
単一の GKE クラスタ インスタンスで開発環境をプロビジョニングします。 |
費用の削減に役立ちます。 |
|
GKE クラスタごとに高可用性コントロール プレーンを構成します。 |
アップグレード中やサイズ変更中にクラスタ コントロール プレーンを使用できるようにします。 |
|
各 GKE クラスタの Namespace、Service、ID にわたって同一性のコンセプトを使用します。 |
異なるクラスタで名前が同じである Kubernetes オブジェクトが同じものとして扱われるようにします。この正規化は、フリート リソースの管理を容易にすることを目的としています。 |
|
コントロール プレーンへの Private Service Connect アクセスとプライベート ノードプールを使用して、GKE クラスタのプライベート IP アドレス空間を有効にします。 |
Kubernetes クラスタ API をスキャン攻撃から保護するために役立ちます。 |
|
Connect Gateway を介した GKE クラスタへの管理者権限を有効にします。 |
1 つのコマンドで、複数のクラスタにアクセスするための認証情報を取得します。グループとサードパーティの ID プロバイダを使用して、クラスタ アクセスを管理します。 |
|
Pod は直接インターネットに公開されませんが、インターネットに接続するリソースにはアクセスできるため、クラスタの全体的なセキュリティ ポスチャーを改善します。 |
||
Container-Optimized OS とシールドされた GKE ノードを使用するようにノードを構成します。 |
ノードの攻撃対象領域を制限します。 |
|
各環境を GKE フリートに関連付けます。 |
GKE クラスタのセットを 1 つのユニットとして管理できるようにします。 |
|
基盤インフラストラクチャ パイプラインを使用して、アプリケーション ファクトリー、フリート スコープ パイプライン、マルチテナント インフラストラクチャ パイプラインをデプロイします。 |
アプリケーション インフラストラクチャをデプロイするための制御、監査、反復可能なメカニズムを提供します。 |
|
GKE Enterprise の構成とポリシーの管理機能を使用して GKE クラスタを構成します。 |
GKE クラスタに、コードとしての構成を可能にするサービスを提供します。 |
|
アプリケーション ファクトリーを使用して、ブループリントで使用されるアプリケーションの CI / CD パイプラインをデプロイします。 |
反復可能なパターンを提供して、アプリケーション パイプラインを簡単にデプロイします。 |
|
アプリケーションの CI / CD パイプラインを使用して、ブループリント アプリケーション コンポーネントをビルドし、デプロイします。 |
アプリケーションをデプロイするための制御、監査、反復可能なメカニズムを提供します。 |
|
Cloud Build、Cloud Deploy、Artifact Registry を使用するようにアプリケーションの CI / CD パイプラインを構成します。 |
マネージド ビルドとデプロイ サービスを使用して、セキュリティ、スケール、シンプルさを最適化します。 |
|
環境をまたいで不変のコンテナを使用し、Binary Authorization でコンテナに署名します。 |
コードの出所を明確にし、コードが確実に環境をまたいでテストされるようにします。 |
|
Cloud Logging と Cloud Monitoring を含む Google Cloud Observability を使用します。 |
Google Cloud の統合マネージド サービスを使用して運用を簡素化します。 |
|
Container Threat Detection(Security Command Center のサービス)を有効にして、コンテナの完全性をモニタリングします。 |
コンテナを継続的にモニタリングすることでセキュリティを強化するマネージド サービスを使用します。 |
|
GKE Google グループに基づく Kubernetes ロールベース アクセス制御(RBAC)によって、GKE クラスタへのアクセスを制御します。 |
アクセス制御を Google Cloud ID にリンクしてセキュリティを強化します。 |
|
Kubernetes Service ごとに固有の Kubernetes サービス アカウントを使用します。このアカウントは、Workload Identity を使用することで IAM サービス アカウントとして機能します。 |
各 Service に提供する必要のある権限を最小限に抑えてセキュリティを強化します。 |
|
GKE Gateway API を介して Service を公開します。 |
上り(内向き)ルールとロード バランシングの構成を管理するための宣言型およびリソースベースのアプローチを提供することで、構成管理を簡素化します。 |
|
Anthos Service Mesh と Certificate Authority Service を使用して、Service を分散サービスとして実行します。 |
Service 間に認証を適用することでセキュリティを強化します。また、正常でない Service からトラフィックをリダイレクトすることで自動フォールト トレランスを実現します。 |
|
AlloyDB for PostgreSQL にはクロスリージョン レプリケーションを使用します。 |
データベース レイヤで高可用性を実現します。 |
|
各環境で共有 VPC インスタンスを構成し、サービス プロジェクトに GKE クラスタを作成します。 |
共有 VPC により、環境の分離を維持しながら、ネットワーク構成管理を一元化できます。 |
|
マルチクラスタのマルチリージョン構成で Cloud Load Balancing を使用します。 |
高可用性で低レイテンシのサービスを実現するため、単一のエニーキャスト IP アドレスを指定してリージョン化された GKE クラスタにアクセスします。 |
|
Service へのクライアント アクセスに HTTPS 接続を使用します。クライアントの HTTP リクエストを HTTPS にリダイレクトします。 |
転送中のセンシティブ データの保護と中間者攻撃の防止に役立ちます。 |
|
Certificate Manager を使用して一般公開証明書を管理します。 |
証明書を一元的に管理できます。 |
|
Google Cloud Armor でウェブ インターフェースを保護します。 |
一般的なウェブ アプリケーションの脆弱性やボリューム型攻撃から保護することで、セキュリティを強化します。 |
実際の決定はブループリントとは異なる場合があります。代替方法については、デフォルトの推奨事項に代わる方法をご覧ください。
次のステップ
- デベロッパー プラットフォームの管理(このシリーズの次のドキュメント)について確認する。