GDC の Kubernetes クラスタ

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップで使用できる Kubernetes クラスタ オプションと機能について説明します。Kubernetes クラスタは、Google Kubernetes Engine（GKE）でマネージド Kubernetes サービスを提供します。これにより、業界標準の Kubernetes 手法を使用してコンテナ ワークロードをデプロイして実行できます。

このドキュメントは、プラットフォーム管理者グループ内の IT 管理者や、組織内のコンテナ ワークロードの管理を担当するアプリケーション オペレーター グループ内のアプリケーション デベロッパーなどのユーザーを対象としています。詳細については、GDC エアギャップの対象ユーザーに関するドキュメントをご覧ください。

非接続環境の GKE

GKE on GDC は、GKE のコア機能と機能を切断された環境に提供するマネージド Kubernetes サービスです。ドキュメントでは、GKE on GDC によって管理されるクラスタを Kubernetes クラスタと呼びます。Kubernetes のコンセプトの詳細については、Kubernetes の学習を開始するをご覧ください。

GKE on GDC を使用すると、パブリック Google Cloudで GKE を使用する場合と同様に、切断された環境でコンテナ ワークロードを作成して管理できます。

次の表に、GDC と Google Cloudのクラスタの比較を示します。

機能 説明 GDC 上の GKE GKE on Google Cloud
完全に切断されている インターネットに接続されていない環境で動作可能。 はい ×
バックアップ ソリューション クラスタのデータと構成のコピーを作成し、データ保護を確保して、障害、エラー、サイバー攻撃からの復元を可能にするサービス。 Backup for GDC Backup for GKE
ロギングとモニタリングの統合 ログの収集と分析、主要業績評価指標のモニタリングを組み合わせて、クラスタの動作を包括的に把握できるサービス。 Prometheus、Grafana、Loki Cloud Logging と Cloud Monitoring
マネージド コンテナ レジストリ コンテナ イメージをホストして整理し、イメージのインフラストラクチャ、可用性、セキュリティを処理するサービス。 Managed Harbor Service Artifact Registry
コンテナの分離 コンテナ アプリケーションとその依存関係を、互いに、またホストシステムから分離して独立させることができる。 はい はい
GPU と TPU のサポート 処理能力を強化できるハイ パフォーマンス コンピューティング ユニット。 GPU のみ GPU と TPU
水平 Pod 自動スケーリング CPU やメモリ使用量などの観測された指標に基づいて、デプロイや他のワークロードの Pod レプリカの数を自動的に調整します。 はい はい
Linux コンテナ Linux ホストでアプリケーションを実行するための分離された環境。 はい はい
クラスタの UI クラスタの管理とモニタリングを視覚的に行うための、ユーザー フレンドリーなグラフィカル インターフェース。 共有クラスタのみ はい
クラスタ リソースの UI クラスタのコンテナ ワークロードを管理およびモニタリングするための、ユーザー フレンドリーな視覚的な方法を提供するグラフィカル インターフェース。 表示のみ はい

GKE と、パブリック Google Cloudで利用可能な機能の完全なセットの詳細については、GKE のドキュメントを確認するをご覧ください。

Kubernetes クラスタのメリット

GKE on GDC は、次のような Kubernetes クラスタに重要なメリットをもたらします。

  • マルチクラスタ ライフサイクル管理: コンテナ ワークロードのさまざまなホスト インスタンスに対して、複数のクラスタを GDC に同時にデプロイします。
  • 完全にサポートされている Kubernetes ディストリビューション: 最新の標準 Kubernetes 機能がバンドルされたクラスタを作成します。
  • 費用の可視性: リアルタイムの使用状況と分析情報をモニタリングし、Kubernetes の費用を継続的にモニタリングできます。
  • マルチチーム管理: 複数のユーザー グループに Kubernetes クラスタへのアクセス権を付与し、柔軟な管理境界を設定します。
  • 自動化された Kubernetes ワークフロー: 自動ノード プロビジョニングと水平 Pod 自動スケーリングを利用して、コンテナ ワークロードをシームレスに管理します。

これらの機能はすべて GKE on GDC に標準で付属しており、マネージド Kubernetes サービスによって作成されたクラスタで使用できます。

GDC クラスタのアーキテクチャ

Kubernetes クラスタは論理的に分離され、異なる障害ドメインと分離保証が提供されます。場合によっては、物理的に分離されることもあります。

Kubernetes クラスタは、共有クラスタまたは標準クラスタとして構成します。共有クラスタは複数のプロジェクトにまたがっています。標準クラスタは、単一のプロジェクトにスコープ設定されます。詳細については、Kubernetes クラスタの構成をご覧ください。

Kubernetes クラスタは、コントロール プレーンとノードと呼ばれるワーカーマシンで構成されます。コントロール プレーンとノードが、Kubernetes クラスタのオーケストレーション システムを構成します。GKE on GDC は、コントロール プレーンやすべてのシステム コンポーネントなど、クラスタの基盤となるインフラストラクチャ全体を管理します。コンテナ化されたワークロードを実行するワーカーノードの管理は、お客様の責任となります。

次の図は、Kubernetes クラスタのアーキテクチャを示しています。

Kubernetes クラスタは、コントロール プレーン、ノード、サービスで構成されます。

この図は、次のコンポーネントを含む Kubernetes クラスタを示しています。

コントロール プレーンについて

コントロール プレーンは、Kubernetes API サーバー、スケジューラ、コアリソース コントローラなどのプロセスを実行します。GKE on GDC は、クラスタの作成から削除までのコントロール プレーンのライフサイクルを管理します。コントロール プレーン上で実行される Kubernetes バージョンのアップグレードも管理の対象になります。アップグレードは GDC によって自動的に行われますが、自動スケジュールの前に手動で行うこともできます。

コントロール プレーンと Kubernetes API

コントロール プレーンはクラスタの統合エンドポイントです。コントロール プレーンは Kubernetes API 呼び出しを介して操作します。コントロール プレーンは、Kubernetes API サーバー プロセス（kube-apiserver）を実行して API リクエストを処理します。Kubernetes API 呼び出しは次の方法で行います。

  • 直接呼び出し: KRM
  • 間接呼び出し: kubectl CLI や GDC コンソールなどの Kubernetes コマンドライン クライアント。

API サーバー プロセスはクラスタのすべての通信のハブとなります。すべての内部クラスタ コンポーネント（ノード、システム プロセス、アプリ コントローラなど）は、API サーバーのクライアントとして機能します。

API リクエストにより、クラスタ内のオブジェクトに対して「選択された状態」が Kubernetes に通知されます。Kubernetes は常にその状態を維持しようとします。Kubernetes では、API のオブジェクトを命令で構成することも、宣言で構成することもできます。

ワーカーノードの管理

コントロール プレーンは、クラスタのすべてのノードで実行される処理を管理します。コントロール プレーンは、ワークロードをスケジューリングし、ワークロードのライフサイクル、スケーリング、アップグレードを管理します。また、これらのワークロードのネットワーク リソースやストレージ リソースの管理も行います。コントロール プレーンとノードは Kubernetes API を使用して相互に通信を行います。

ノードについて

ノードは、コンテナ化されたアプリケーションと他のワークロードを実行するワーカーマシンです。個々のマシンは、GKE on GDC によって作成される仮想マシン（VM）です。コントロール プレーンは、各ノードから報告されるノードのステータスを管理します。

ノードは、クラスタのワークロードを構成するコンテナをサポートするために必要なサービスを実行します。これにはランタイムと Kubernetes ノード エージェント（kubelet）も含まれます。後者は、コントロール プレーンと通信し、ノード上でスケジュールされたコンテナの起動と実行を行います。

GKE on GDC では、ノードごとのエージェント（DaemonSet）として稼働する多くのシステム コンテナが実行され、ログの収集やクラスタ内のネットワーク接続などの機能を提供しています。

ノードはノードプールにグループ化されます。これは、同じ構成と特性を共有するクラスタ内のノードのセットです。ノードプール内に単一ノードを構成することはできません。

カスタム ノードプールは、他より多くのリソース（メモリやローカル ディスク容量など）を必要とする Pod をスケジュールする場合に役立ちます。Pod のスケジューリングをより細かく制御する必要がある場合は、ノード taints を使用できます。

詳細については、ノードプールを管理するをご覧ください。

Kubernetes クラスタの構成

GKE on GDC サービスでは、組織内のコンテナ ワークロードを管理するために次のクラスタ構成を使用できます。

  • 共有クラスタ: 複数のプロジェクトにまたがる組織スコープの Kubernetes クラスタ。単一のプロジェクトによって管理されるのではなく、複数のプロジェクトに接続されます。
  • 標準クラスタ: プロジェクト内のクラスタ リソースを管理し、複数のプロジェクトにまたがることはできない、プロジェクト スコープの Kubernetes クラスタ。

コンテナ ワークロードの管理要件に最適なクラスタを選択できます。詳細については、Kubernetes クラスタの構成をご覧ください。

クラスタ内の GPU ワークロード

GDC は Kubernetes クラスタの NVIDIA GPU サポートを提供し、GPU デバイスをユーザー ワークロードとして実行します。たとえば、GPU 環境で AI と ML のノートブックを実行することを希望する場合があります。クラスタで GPU デバイスをサポートするには、GPU マシンをプロビジョニングしてクラスタを構成する必要があります。GDC の Kubernetes クラスタでサポートされているマシンタイプの一覧については、クラスタノードマシンをご覧ください。

GPU は静的に割り当てられます。最初の 4 つの GPU は、常に事前トレーニング済みの AI や ML API などのワークロード専用です。これらの GPU は Kubernetes クラスタで実行されません。残りの GPU は Kubernetes クラスタで使用できます。AI と ML のノートブックは Kubernetes クラスタで実行されます。

AI や ML API などのコンポーネントをクラスタで実行できるように、適切なクラスタタイプに GPU マシンを割り当ててください。詳細については、共有クラスタを作成するまたは標準クラスタを作成するをご覧ください。

GKE on GDC の制限事項

次の GKE 機能は、GKE on GDC では使用できない制限事項です。

  • 自動クラスタ管理
    • ノードの自動修復: ノードが異常になったときに自動的にノードを修正するクラスタ モニタリング。手動で介入する必要性が軽減されます。
    • クラスタの自動アップグレード: クラスタのコントロール プレーンとワーカーノードの Kubernetes バージョンを自動的にアップグレードし、クラスタでサポートされている安全なバージョンが実行されるようにします。
    • クラスタの自動スケーリング: ワークロードの需要に基づいてノードを追加または削除することで、クラスタのサイズを自動的に調整します。
    • GKE Autopilot: インフラストラクチャ管理を処理するフルマネージド運用モード。
    • 垂直 Pod 自動スケーリング: 過去の使用状況に基づいて、クラスタの Pod の CPU リクエストとメモリ リクエストおよび上限を自動的に調整します。
  • マルチクラウド
  • オペレーション

次のステップ