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

Version 1.12 

• 最新
• バージョン 1.16
• 以前のバージョン（サポート対象外）

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

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

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

ベアメタル版 Anthos クラスタをインストールする場合は、さまざまなタイプのクラスタを作成できます。

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

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

• デフォルト: デフォルト プロファイルには標準のシステム リソース要件が揃っており、あらゆるクラスタタイプで使用できます。

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

警告: 次のリソース要件では、ワークロードの要件が考慮されていません。ワークロードの運用を最適化するには、リソース要件を別途検討する必要があります。

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

次の表では、ベアメタル版 Anthos クラスタで、デフォルトのプロファイルを使用して管理クラスタ、ハイブリッド クラスタ、ユーザー クラスタ、スタンドアロン クラスタを運用および管理するために必要な、ハードウェアの最小要件と推奨要件を示します。

リソース	最小	推奨
CPU / vCPU^*	4 コア	8 コア
RAM	16 GiB	32 GiB
ストレージ	128 GiB	256 GiB

^* Anthos clusters on bare metal は、x86 プロセッサ ファミリーの CPU と vCPU のみをサポートします。

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

次の表では、ベアメタル版 Anthos クラスタで、Edge プロファイルを使用してスタンドアロン クラスタを運用および管理するために必要な、ハードウェアの最小要件と推奨要件を示します。

リソース	最小	推奨
CPU / vCPU^*	2 コア	4 コア
RAM	Ubuntu: 4 GiB CentOS/RHEL: 6 GiB	Ubuntu: 8 GiB CentOS/RHEL: 12 GiB
ストレージ	128 GiB	256 GiB

^* Anthos clusters on bare metal は、x86 プロセッサ ファミリーの CPU と vCPU のみをサポートします。

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

• bmctl を別のワークステーションで実行する。ターゲット クラスタノードで bmctl を実行する必要がある場合は、最小要件を満たすために 2 GiB のメモリが必要です。たとえば、Ubuntu の場合は 6 GiB、CentOS/Redhat の場合は 8 GiB が必要です。

• MaxPodsPerNode を 110 に設定する。クラスタで実行するノード数は、平均でノードあたり 30 個までです。MaxPodsPerNode を上位の構成にするか、ノードあたり 30 個を超えるユーザー Pod を実行するには、追加のリソースが必要になることがあります。

• containerd をコンテナ ランタイムとして使用する。Docker コンテナ ランタイムで実行するためには、追加のリソースが必要になることがあります。

• この最小リソース構成では、Kubevirt コンポーネントを考慮しない。Kubevirt には、クラスタにデプロイされる VM の数に応じて追加のリソースが必要です。

追加のストレージ要件

ベアメタル版 Anthos クラスタには、ストレージ リソースが備わっていせん。必要なストレージは、システム上でプロビジョニングして構成する必要があります。

詳細なストレージ要件については、インストールの前提条件の概要をご覧ください。

必要なストレージを構成する方法については、ベアメタル版 Anthos クラスタ用ストレージの構成をご覧ください。

etcd のパフォーマンス

ディスク速度は etcd のパフォーマンスと安定性にとって重要です。ディスクが低速な場合は etcd のリクエストのレイテンシが増加し、クラスタの安定性に問題が発生する可能性があります。etcd ストアにはソリッド ステート ディスク（SSD）を使用することをおすすめします。etcd のドキュメントには、本番環境でクラスタを実行するときに最適な etcd パフォーマンスを実現するための、追加のハードウェアの最適化案が記載されています。

etcd とディスクのパフォーマンスを確認するには、Metrics Explorer で次の etcd I/O レイテンシ指標を使用します。

• etcd_disk_backend_commit_duration_seconds: 期間は 99 パーセンタイル（p99）に対して 25 ミリ秒未満にする必要があります。
• etcd_disk_wal_fsync_duration_seconds: 期間は 99 パーセンタイル（p99）に対して 10 ミリ秒未満にする必要があります。

etcd のパフォーマンスの詳細については、etcd の警告「エントリの適用に時間がかかりすぎた」は何を意味しますか？と etcd の警告「ハートビートの定刻での送信に失敗した」は何を意味しますか？をご覧ください。

ノードマシンの前提条件

ノードマシンには次の前提条件があります。

• サポート対象の Linux ディストリビューションのオペレーティング システムを使用している。詳細については、オペレーティング システムを選択するをご覧ください。
• Linux カーネルのバージョンが 4.17.0 以降。Ubuntu 18.04 と 18.04.1 は、Linux カーネル バージョン 4.15 上にあるため、互換性がありません。
• ハードウェアの最小要件を満たしている。
• インターネット アクセスがある。
• すべての他のノード マシンへのレイヤ 3 接続。
• コントロール プレーン VIP にアクセスできる。
• 適切に構成された DNS ネームサーバーがある。
• 重複するホスト名はない。
• 次の NTP サービスのいずれかが有効になっていて、機能している。
  • chrony
  • ntp
  • ntpdate
  • systemd-timesyncd
• apt、dnf などの有効なパッケージ マネージャーがある。
• Ubuntu では、Uncomplicated Firewall（UFW）を無効にする必要があります。 UFW を無効にするには、systemctl stop ufw を実行します。

• Ubuntu で、ベアメタル版 Anthos クラスタ 1.8.2 以降の場合、AppArmor を無効にする必要はない。ベアメタル版 Anthos クラスタの以前のリリースを使用してクラスタをデプロイする場合は、コマンド systemctl stop apparmor を使用して AppArmor を無効にします。

  注: クラスタのコンテナ ランタイムとして containerd を使用することをおすすめします。コンテナ ランタイムとしての Docker エンジンのサポートは、Anthos clusters on bare metal バージョン 1.13.0 以降で削除されました。詳細については、コンテナ ランタイムを Docker から containerd に変更するをご覧ください。

• コンテナ ランタイムとして Docker を選択した場合は、インストールされた Docker バージョン 19.03 以降を使用できます。ノードマシンに Docker がインストールされていない場合や、古いバージョンがインストールされている場合、ベアメタル上の Anthos がクラスタ作成時に Docker 19.03.13 以降をインストールする。

• デフォルトのコンテナ ランタイムである containerd を使用する場合、Docker は不要です。Docker をインストールすると、問題が発生する可能性があります。詳細については、既知の問題をご覧ください。

• クラスタの作成では、ベアメタル版 Anthos クラスタのシステム コンポーネントに必要な空き容量のみが確認されます。この変更により、アプリケーション ワークロードに割り当てるスペースをより詳細に制御できます。ベアメタル版 Anthos クラスタをインストールする場合は、次のディレクトリをサポートするファイル システムに必要な容量があり、次の要件を満たすようにしてください。

  • /: 17 GiB（18,253,611,008 バイト）。
  • /var/lib/docker または /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 ディレクトリと /etc/kubernetes ディレクトリは、存在しない、または空のいずれかの状態です。

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

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

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

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

次のステップ

• ネットワークを設定する
• 次のいずれかのオペレーティング システムを選択します。