Google Distributed Cloud は、ターゲット オペレーティング システムのディストリビューションがサポートするハードウェアで動作する幅広いシステムをサポートしています。Google Distributed Cloud は最小のハードウェア構成で実行することも、複数のマシンで実行して柔軟性、可用性、パフォーマンスを向上させることもできます。
Google Distributed Cloud の構成に関係なく、ノードとクラスタには、実行中のクラスタとワークロードのニーズを満たす十分な CPU、RAM、ストレージ リソースが必要です。
このページは、会社の戦略に従って IT ソリューションとシステム アーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
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: 4 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を実行します。次のいずれかのネットワーク カーネル モジュールが読み込まれている必要があります。
ip_tables（これは、必須ではないフロントエンド Debian パッケージiptablesとは異なります）nf_tables
モジュールを読み込むには、次のコマンドを実行します。
modprobe MODULE_NAMEクラスタの作成では、Google Distributed Cloud システム コンポーネントに必要な空き容量のみがチェックされます。この変更により、アプリケーション ワークロードに割り当てるスペースをより詳細に制御できます。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 バイト、コントロール プレーン ノードのみ該当）。
クラスタのバージョンに関係なく、前述のディレクトリ リストは同じパーティション、または異なるパーティションのいずれに存在しても問題ありません。基盤となる同じパーティションに存在する場合、スペース要件は、パーティション上の個別のディレクトリに必要なスペースの合計です。どのリリース バージョンでも、クラスタの作成プロセスで必要に応じてディレクトリが作成されます。
/var/lib/etcdディレクトリと/etc/kubernetesディレクトリは存在しないか、空のいずれかの状態です。RHEL 9.2 または Ubuntu 22.04 を実行するマシンの場合、最大ユーザー インスタンスとユーザー ウォッチの Linux カーネル
inotifyの上限は、次の値以上である必要があります。fs.inotify.max_user_instances:8192fs.inotify.max_user_watches:524288
Google Distributed Cloud をインストールして実行するための前提条件に加え、ユーザーは、業界またはビジネス セグメントの関連基準を遵守する必要があります。たとえば、クレジット カードを取り扱う業種では PCI DSS 要件、防衛産業のビジネスではセキュリティ テクニカル実装ガイド（STIG）への遵守が必要になります。
ロードバランサ マシンの前提条件
Deployment に専用のロードバランサ ノードプールがない場合は、ワーカーノードまたはコントロール プレーンノードを使用してロードバランサのノードプールを作成できます。その場合、追加の前提条件があります。
- マシンが同じレイヤ 2 サブネット内に配置されている。
- VIP がすべてロードバランサのノードのサブネット上にあり、サブネットのゲートウェイからルーティング可能である。
- ロードバランサのサブネットのゲートウェイが、マスターのロードバランサにパケットを転送する Gratuitous ARP をリッスンする必要がある。