Anthos clusters on bare metal は、ベアメタル向け Google Distributed Cloud（ソフトウェアのみ）になりました。詳細については、プロダクトの概要をご覧ください。

このページは Cloud Translation API によって翻訳されました。

クラスタノードマシンの前提条件

Google Distributed Cloud は、ターゲットオペレーティングシステムのディストリビューションがサポートするハードウェアで動作する幅広いシステムをサポートしています。Google Distributed Cloud は最小のハードウェア構成で実行することも、複数のマシンで実行して柔軟性、可用性、パフォーマンスを向上させることもできます。

Google Distributed Cloud の構成に関係なく、ノードとクラスタには、実行中のクラスタとワークロードのニーズを満たす十分な CPU、RAM、ストレージリソースが必要です。

このページは、会社の戦略に従って IT ソリューションとシステムアーキテクチャを定義する管理者、アーキテクト、オペレーターを対象としています。 Google Cloudのコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

CPU、RAM、ストレージの最小要件と推奨要件

Google Distributed Cloud をインストールするときに、さまざまなタイプのクラスタを作成できます。

ワークロードを実行するユーザークラスタ。
管理クラスタ。ワークロードを実行するためのユーザークラスタを作成して制御します。
スタンドアロンクラスタは、ワークロードを管理および実行できる単一のクラスタですが、ユーザークラスタの作成や管理はできません。
ハイブリッドクラスタは、ワークロードを管理および実行できます。また、追加のユーザークラスタを作成して管理することもできます。

クラスタタイプに加えて、リソース要件の観点では次のインストールプロファイルから選択できます。

デフォルト: デフォルトプロファイルには標準のシステムリソース要件が揃っており、あらゆるクラスタタイプで使用できます。
Edge: Edge プロファイルでは、システムリソース要件が大幅に軽減されています。リソースが制限されたエッジデバイスには、このプロファイルを使用することをおすすめします。エッジプロファイルは、スタンドアロンクラスタでのみ使用できます。

デフォルトのプロファイルを使用する全クラスタタイプのリソース要件

次の表に、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 のみをサポートします。

Edge プロファイルを使用したスタンドアロンクラスタのリソース要件

次の表は、Google Distributed Cloud が Edge プロファイルを使用してスタンドアロンクラスタを運用、管理するために必要な、ハードウェアの最小要件と推奨要件を示しています。

リソース	最小	推奨
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 のみをサポートします。

Edge プロファイルを使用してスタンドアロンクラスタを構成するには、次のようにすることをおすすめします。

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`	10,016 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 バイト、コントロールプレーンノードにのみ該当）

クラスタのバージョンに関係なく、ディレクトリは同じディスクパーティションまたは異なるディスクパーティションに配置できます。ディレクトリがディスクパーティションを共有している場合は、その共有パーティション上の個々のディレクトリに必要なスペースを合計して、合計スペース要件を計算します。これらのディレクトリが存在しない場合は、クラスタ設定によって作成されます。

/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
詳細については、RHEL または Ubuntu の構成ドキュメントをご覧ください。

Google Distributed Cloud をインストールして実行するための前提条件に加え、お客様は業界またはビジネスセグメントを治める関連基準（クレジットカードを処理するビジネスに関する PCI DSS 要件、防衛産業のビジネスに関するセキュリティテクニカル実装ガイド（STIG）など）を遵守することが期待されます。

ロードバランサマシンの前提条件

デプロイメントに専用のロードバランサノードプールがない場合は、ワーカーノードまたはコントロールプレーンノードを使用してロードバランサのノードプールを作成できます。その場合、追加の前提条件があります。

マシンが同じレイヤ 2 サブネット内に配置されている。
VIP がすべて、ロードバランサのノードのサブネットにあり、サブネットのゲートウェイからルーティング可能。
ロードバランサのサブネットのゲートウェイが、メインのロードバランサにパケットを転送する Gratuitous ARP をリッスンする必要がある。