Google Distributed Cloud は、ターゲット オペレーティング システムのディストリビューションがサポートするハードウェアで動作する幅広いシステムをサポートしています。Google Distributed Cloud は最小のハードウェア構成で実行することも、複数のマシンで実行して柔軟性、可用性、パフォーマンスを向上させることもできます。
Google Distributed Cloud の構成に関係なく、ノードとクラスタには、実行中のクラスタとワークロードのニーズを満たす十分な CPU、RAM、ストレージ リソースが必要です。
このページは、会社の戦略に従って IT ソリューションとシステム アーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。 Google Cloudのコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。
CPU、RAM、ストレージの最小要件と推奨要件
Google Distributed Cloud をインストールするときに、さまざまなタイプのクラスタを作成できます。
- ワークロードを実行するユーザー クラスタ。
- 管理クラスタ。ワークロードを実行するためのユーザー クラスタを作成して制御します。
- スタンドアロン クラスタは、ワークロードを管理および実行できる単一のクラスタですが、ユーザー クラスタの作成や管理はできません。
- ハイブリッド クラスタは、ワークロードを管理および実行できます。また、追加のユーザー クラスタを作成して管理することもできます。
クラスタタイプに加えて、リソース要件の観点から次のインストール プロファイルを選択します。
- デフォルト: デフォルト プロファイルは標準のシステム リソース要件を満たしており、あらゆるクラスタタイプで使用できます。 
- エッジ: エッジ プロファイルでは、システム リソース要件が大幅に少なくなっています。リソースが制限されているエッジデバイスには、このプロファイルを使用することをおすすめします。エッジ プロファイルは、スタンドアロン クラスタでのみ使用できます。 
デフォルトのプロファイルを使用するクラスタタイプのリソース要件
次の表に、Google Distributed Cloud がデフォルトのプロファイルを使用して管理クラスタ、ハイブリッド クラスタ、ユーザー クラスタ、スタンドアロン クラスタを運用、管理するために必要なハードウェアの最小要件と推奨要件を示します。
| リソース | 最小 | 推奨 | 
|---|---|---|
| CPU / vCPU* | 4 コア | 8 コア | 
| RAM | 16 GiB | 32 GiB | 
| ストレージ | 128 GiB | 256 GiB | 
* Google Distributed Cloud は、CPU マイクロアーキテクチャ レベル v3(x86-64-v3)以降で x86-64 CPU および vCPU のみをサポートします。
エッジ プロファイルを使用したスタンドアロン クラスタのリソース要件
次の表に、Google Distributed Cloud がエッジ プロファイルを使用してスタンドアロン クラスタを運用、管理するために必要なハードウェアの最小要件と推奨要件を示します。
| リソース | 最小 | 推奨 | 
|---|---|---|
| CPU / vCPU* | 2 コア | 4 コア | 
| RAM | Ubuntu: 5 GiB RHEL: 6 GiB | Ubuntu: 8 GiB RHEL: 12 GiB | 
| ストレージ | 128 GiB | 256 GiB | 
* Google Distributed Cloud は、CPU マイクロアーキテクチャ レベル v3(x86-64-v3)以降で x86-64 CPU および vCPU のみをサポートします。
エッジ プロファイルを使用してスタンドアロン クラスタを構成するには、次のことをおすすめします。
- bmctlを別のワークステーションで実行します。ターゲット クラスタ ノードで- bmctlを実行する必要がある場合は、最小要件を満たすため 2 GiB のメモリが必要です。たとえば、Ubuntu の場合は 6 GiB、RHEL の場合は 8 GiB が必要です。
- MaxPodsPerNodeを 110 に設定します。クラスタで実行するノード数は、平均でノードあたり 30 個までです。- MaxPodsPerNodeを上位の構成にするか、ノードあたり 30 個を超えるユーザー Pod を実行するには、追加のリソースが必要になることがあります。
- GDC 上の VM ランタイムのコンポーネントは、この最小リソース構成では考慮されていません。GDC 上の VM ランタイムには、クラスタにデプロイされる VM の数に応じて追加のリソースが必要です。 
その他のストレージ要件
Google Distributed Cloud はストレージ リソースを提供しません。必要なストレージは、システム上でプロビジョニングして構成する必要があります。
詳細なストレージ要件については、インストールの前提条件の概要をご覧ください。
必要なストレージを構成する方法については、Google Distributed Cloud のストレージの構成をご覧ください。
ノードマシンの前提条件
ノードマシンには次の前提条件があります。
- ハードウェアの最小要件を満たしている。
- サポート対象の Linux ディストリビューションのオペレーティング システムを使用している。カーネル要件などの詳細については、オペレーティング システムを選択するをご覧ください。
- インターネット アクセスがある。
- 他のすべてのノードマシンに対するレイヤ 3 接続
- コントロール プレーン VIP にアクセスできる。
- 必要なポートにアクセスできる。コントロール プレーン ノード、ワーカーノード、ロードバランサ ノードの特定のポート要件については、ネットワーク要件のページでポートの使用をご覧ください。
- 適切に構成された DNS ネームサーバーがある。
- 重複するホスト名がない。
- 次の NTP サービスのいずれかが有効になっていて、機能している。
- chrony
- ntp
- ntpdate
- systemd-timesyncd
 
- 作業用のパッケージ マネージャー(apt、dnfなど)。
- Ubuntu では、Uncomplicated Firewall(UFW)を無効にする必要があります。UFW を無効にするには、 - systemctl stop ufwを実行します。
- 次のいずれかのネットワーク カーネル モジュールが読み込まれている必要があります。 - iptables-nft(これは、必須ではないフロントエンド Debian パッケージ- iptablesとは異なります)- iptables-legacyはサポートされていません。
- nf_tables。
 - モジュールを読み込むには、次のコマンドを実行します。 - modprobe MODULE_NAME
- ディスク空き容量の要件: - 1.29.100 以降- Google Distributed Cloud をインストールすると、プリフライト チェックが実行されます。これらのチェックでは、これらのディレクトリのファイル システムに十分な容量があることを確認します。 - ディレクトリ - スペース要件 - /(ルート ディレクトリ)- 4 GiB(4,294,967,296 バイト) - /var/log/fluent-bit-buffers- 12 GiB(12,884,901,888 バイト) - /var/opt/buffered-metrics- 10016 MiB(10,502,537,216 バイト) - /var/lib/containerd- コントロール プレーン ノード用に 30 GiB(32,212,254,720 バイト)
- ワーカーノード用に 10 GiB(10,485,760 バイト)
 - /var/lib/kubelet- 500 MiB(524,288,000 バイト) - /var/lib/etcd- 20 GiB(21,474,836,480 バイト、コントロール プレーン ノードのみ該当) - /var/lib/etcd-events- 5 GiB(5,368,709,120 バイト、コントロール プレーン ノードのみ該当) - アプリケーション ワークロードに割り当てるスペースをより詳細に制御できるように、クラスタ作成のプリフライト チェックでは、Google Distributed Cloud システム コンポーネントに必要な空き容量のみがチェックされます。デプロイを予定しているワークロードによっては、追加のストレージが必要になる場合があります。 - クラスタをバージョン 1.29.100 以降にアップグレードすると、プリフライト チェックで - /(ルート ディレクトリ)に 2 GiB 以上の空き容量があることが確認されます。- 1.29.0 以前- Google Distributed Cloud をインストールするたびに、次のディレクトリをサポートするファイル システムに必要な容量があることを確認するために、プリフライト チェックが実行されます。 - ディレクトリ - スペース要件 - /(ルート ディレクトリ)- 17 GiB(18,253,611,008 バイト) - /var/lib/containerd- コントロール プレーン ノード用に 30 GiB(32,212,254,720 バイト)
- ワーカーノード用に 10 GiB(10,485,760 バイト)
 - /var/lib/kubelet- 500 MiB(524,288,000 バイト) - /var/lib/etcd- 20 GiB(21,474,836,480 バイト、コントロール プレーン ノードのみ該当) - /var/lib/etcd-events- 5 GiB(5,368,709,120 バイト、コントロール プレーン ノードのみ該当) - アプリケーション ワークロードに割り当てるスペースをより詳細に制御できるように、クラスタ作成のプリフライト チェックでは、Google Distributed Cloud システム コンポーネントに必要な空き容量のみがチェックされます。デプロイを予定しているワークロードによっては、追加のストレージが必要になる場合があります。 - クラスタのバージョンに関係なく、ディレクトリは同じディスク パーティションまたは異なるディスク パーティションに存在できます。ディレクトリがディスク パーティションを共有している場合は、その共有パーティション上の個々のディレクトリに必要なスペースを合計して、合計スペース要件を計算します。こうしたディレクトリが存在しない場合、クラスタ設定で作成されます。 
- /var/lib/etcdディレクトリと- /etc/kubernetesディレクトリは存在しないか、空のいずれかの状態です。
- RHEL 9.2 または Ubuntu 22.04 を実行するマシンの場合、最大ユーザー インスタンスとユーザー ウォッチの Linux カーネル - inotifyの上限は、次の値以上である必要があります。- fs.inotify.max_user_instances:- 8192
- fs.inotify.max_user_watches:- 524288
 
Google Distributed Cloud をインストールして実行するための前提条件に加え、ユーザーは、業界またはビジネス セグメントの関連基準を遵守する必要があります。たとえば、クレジット カードを取り扱う業種では PCI DSS 要件、防衛産業のビジネスではセキュリティ テクニカル実装ガイド(STIG)への遵守が必要になります。
ロードバランサ マシンの前提条件
Deployment に専用のロードバランサ ノードプールがない場合は、ワーカーノードまたはコントロール プレーンノードを使用してロードバランサのノードプールを作成できます。その場合、追加の前提条件があります。
- マシンが同じレイヤ 2 サブネット内に配置されている。
- VIP がすべてロードバランサのノードのサブネット上にあり、サブネットのゲートウェイからルーティング可能である。
- ロードバランサのサブネットのゲートウェイが、マスターのロードバランサにパケットを転送する Gratuitous ARP をリッスンする必要がある。