管理ワークステーションの前提条件

管理ワークステーションは、インストール中にクラスタをプロビジョニングするためのコマンドラインインターフェース（CLI）ツールと構成ファイルをホストします。また、インストール後に、プロビジョニングされたクラスタとやり取りするための CLI ツールもホストします。

管理ワークステーションで bmctl や Google Cloud CLI などのツールをダウンロードして実行し、クラスタや Google Cloud リソースを操作します。管理ワークステーションは、インストール、アップグレード、更新時にクラスタをプロビジョニングするための構成ファイルをホストします。インストール後、管理ワークステーションは kubeconfig ファイルをホストします。これにより、kubectl を使用してプロビジョニングされたクラスタを操作できます。管理ワークステーション上の重要なクラスタオペレーションのログにもアクセスできます。1 つの管理ワークステーションを使用して、多数のクラスタを作成、管理できます。

管理ワークステーションが、以降のセクションに記載する前提条件を満たしていることを確認してください。

オペレーティングシステムとソフトウェア

bmctl を実行してコントロールプレーンノードとして機能するために、管理ワークステーションにはノードと同じオペレーティングシステム（OS）要件があります。管理ワークステーションには Docker が必要ですが、コンテナランタイムとして使用するためのものではありません。GKE on Bare Metal がクラスタを作成すると、管理ワークステーションに Docker 内の Kubernetes（種類）クラスタをデプロイします。このブートストラップ クラスタは、クラスタの作成に必要な Kubernetes コントローラをホストします。特に指定しない限り、ブートストラップクラスタはクラスタの作成が正常に完了すると削除されます。ブートストラップクラスタでは、Docker がコンテナイメージを pull する必要があります。

クラスタをインストールするには、管理ワークステーションが次の要件を満たしている必要があります。

オペレーティングシステムが、サポートされている Linux ディストリビューションである。

サポートされている Linux OS とバージョンのリストについては、オペレーティングシステムを選択するをご覧ください。このページには、各 OS の構成手順（Docker の構成など）へのリンクがあります。
Docker バージョン 19.03 以降がインストールされている。ただし、システムで cgroup v2 を使用する場合、管理ワークステーションへの Docker のインストールはバージョン 20.10.0 以降でなければなりません。（システムが /sys/fs/cgroup/cgroup.controllers ファイルが存在することで、cgroup v2 を使用しているかどうかを確認できます）。cgroup v2 は、プレビュー機能としてのみサポートされます。プレビュー機能を本番環境で使用することはおすすめしません。

警告: snap によってインストールされた Docker は、デフォルトでは厳格な閉じ込めモードになっています。つまり、Docker は $HOME ディレクトリ外のファイルにアクセスできません。管理ワークステーションで snap info --verbose docker | grep confinement を実行して、Docker が厳格な閉じ込めモードになっていることを確認します。これに該当する場合は、bmctl-workspace フォルダが $HOME ディレクトリにあることを確認してください。
root ユーザー以外のユーザーが、docker グループのメンバーである（手順については、root ユーザー以外のユーザーとして Docker を管理するをご覧ください）。
Google Cloud CLI がインストールされている。

クラスタの作成と管理には、kubectl ツールと bmctl ツールを使用します。これらのツールをインストールするには、gcloud ツールと gsutil ツールが必要です。gcloud、gsutil、kubectl の各コマンドラインツールは gcloud CLI のコンポーネントです。コンポーネントのインストール手順など、インストール手順については、gcloud CLI をインストールするをご覧ください。
kubectl がインストールされている。gcloud CLI を使用して、次のコマンドで kubectl をインストールします。
```
gcloud components install kubectl
```
bmctl が、作成または運用しているクラスタのバージョンにインストールされている。

インストールには、gsutil を使用して bmctl バイナリまたはイメージパッケージをダウンロードすることが含まれます。手順については、Anthos clusters on bare metal のダウンロードをご覧ください。

ハードウェアリソースの要件

管理ワークステーションでは、ツールを実行して、クラスタの作成と管理に関連するリソースを保存するために、大量のコンピューティング能力、メモリ、ストレージを必要とします。

デフォルトでは、クラスタのアップグレードとクラスタ作成のオペレーションでは、ブートストラップクラスタが使用されます。ブートストラップクラスタを使用すると、CPU とメモリの使用量が大幅に増加します。管理ワークステーションをコントロールプレーンノードとして使用する場合は、管理ワークステーションのアクティビティによってクラスタコントロールプレーンの機能に障害が発生しないように、推奨される上限の CPU と RAM を使用します。

etcd データベースのサイズとコントロールプレーンノードの数によっては、クラスタのバックアップと復元のオペレーションで大量の RAM が消費されます。バックアップに必要な RAM の概算量は、コントロールプレーンノードごとに 3～5 GiB です。メモリが不足しているためバックアッププロセスが失敗します。これに合わせて RAM の要件を計画します。

次の表は、管理ワークステーションの最小および推奨のハードウェア要件を示したものです。

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

^* GKE on Bare Metal は、CPU マイクロアーキテクチャレベル v3（x86-64-v3）以上の x86-64 CPU と vCPU のみをサポートしています。

ネットワーキングの要件

管理ワークステーションは、Google Cloud とすべてのクラスタノードにアクセスする必要があります。

Google Cloud へのアクセス

管理ワークステーションは、Google Cloud にアクセスして、ツールとイメージのダウンロードとインストール、認可リクエストの処理、サービスアカウントの作成、ロギングとモニタリングの管理などを行います。Google Cloud にアクセスできないと、クラスタを作成できません。

Google Cloud へのアクセスは直接またはプロキシサーバー経由のいずれかになります。Google Cloud に接続するさまざまな方法については、Google に接続するをご覧ください。プロキシサーバーの構成については、プロキシの背後でインストールするをご覧ください。

Google Cloud へのアクセスの中断による影響については、Google Cloud からの一時的な接続解除の影響をご覧ください。

ノードへのアクセス

管理ワークステーションからクラスタを作成して管理するには、ノードマシンに対する次のアクセス権が必要です。

すべてのクラスタノードマシンへのレイヤ 3 接続。
SSH を使用したすべてのクラスタノードマシンへのパスワードなしの root アクセス。直接または sudo による SSH アクセス。
コントロールプレーン VIP にアクセスできる。

IP 転送

管理ワークステーションで IP 転送を有効にする必要があります。IP 転送を使用せずにブートストラップクラスタは作成できません。このため、クラスタの作成がブロックされます。IP 転送が無効になっている場合、クラスタを作成しようとすると、次のようなエラーが表示されます。

Error message: E0202 14:53:25.979322 225917 console.go:110] Error creating cluster: create kind cluster failed: error creating bootstrap cluster: failed to init node with kubeadm: command "docker exec --privileged bmctl-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

IP 転送設定は、次のコマンドで確認できます。

cat /proc/sys/net/ipv4/ip_forward

値 1 は、IP 転送が有効になっていることを示します。IP 転送が無効になっている（0）場合は、次のコマンドを使用して有効にします。

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

ノードへの `root` SSH アクセスを設定する

管理ワークステーションとクラスタノードマシン間の安全なパスワードなしの接続を有効にするには、管理ワークステーションで SSH 認証鍵を作成し、公開鍵をクラスタノードと共有します。

各クラスタノードマシンで root SSH パスワード認証を有効にします。/etc/ssh/sshd_config ファイルで PermitRootLogin と PasswordAuthentication の行をコメント解除するか追加して、値を yes に設定します。
```
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

...

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

...

PasswordAuthentication yes
```
最初に、管理ワークステーションから鍵を共有するには、リモートクラスタノードマシンで SSH パスワード認証を有効にする必要があります。
SSH 構成の変更を適用するには、SSH サービスを再起動します。
```
sudo systemctl restart ssh.service
```
管理ワークステーションで秘密鍵と公開鍵のペアを生成します。鍵のパスフレーズは設定しないでください。次のコマンドを実行して鍵を生成します。
```
ssh-keygen -t rsa
```
SSH の設定に、クラスタノードマシンへの sudo ユーザーアクセスを使用することもできます。ただし、パスワードを持たない root ユーザー以外の接続では、spec.nodeAccess.loginUser フィールドを使用してクラスタ構成ファイルを更新する必要があります。このフィールドはデフォルトでコメントアウトされます。クラスタの作成中または作成後の任意の時点で、root 以外のユーザー名を loginUser で指定できます。詳細については、loginUser をご覧ください。
生成された公開鍵をクラスタノードマシンに追加します。
```
ssh-copy-id -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
```
以下を置き換えます。
- PATH_TO_IDENTITY_FILE: SSH 公開鍵を含むファイルのパス。デフォルトでは、公開鍵を含む ID ファイルのパスは /home/USERNAME/.ssh/id_rsa.pub です。
- CLUSTER_NODE_IP: SSH 公開鍵を追加するノードマシンの IP アドレス。
sshd_config ファイルで PasswordAuthentication を no に設定し、SSH サービスを再起動することで、クラスタノードマシンで SSH パスワード認証を無効にします。
管理ワークステーションで次のコマンドを使用して、ワークステーションとノードマシン間で公開鍵認証が機能することを確認します。
```
ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
```
SSH が適切に構成されると、パスワードを入力しなくても、管理ワークステーションから（root として）ノードマシンにログインできます。

次のステップ

ノードマシンの前提条件