管理ワークステーションは、インストール中にクラスタをプロビジョニングするためのコマンドライン インターフェース(CLI)ツールと構成ファイルをホストします。また、インストール後に、プロビジョニングされたクラスタを操作するための CLI ツールもホストします。
このページは、基盤となる技術インフラストラクチャのライフサイクルの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
管理ワークステーションで bmctl
や Google Cloud CLI などのツールをダウンロードして実行し、クラスタや Google Cloud リソースを操作します。管理ワークステーションは、インストール、アップグレード、更新時にクラスタをプロビジョニングするための構成ファイルをホストします。インストール後、管理ワークステーションは kubeconfig
ファイルをホストします。これにより、kubectl
を使用してプロビジョニングされたクラスタを操作できます。管理ワークステーション上の重要なクラスタ オペレーションのログにもアクセスできます。1 つの管理ワークステーションを使用して、多数のクラスタを作成、管理できます。
管理ワークステーションが、以降のセクションに記載する前提条件を満たしていることを確認してください。
オペレーティング システムとソフトウェア
bmctl
を実行してコントロール プレーン ノードとして機能するために、管理ワークステーションにはノードと同じオペレーティング システム(OS)要件があります。管理ワークステーションには Docker が必要ですが、コンテナ ランタイムとして使用するためのものではありません。Google Distributed Cloud がクラスタを作成すると、管理ワークステーションに Kubernetes in Docker(kind)クラスタがデプロイされます。このブートストラップ クラスタは、クラスタの作成に必要な Kubernetes コントローラをホストします。特に指定しない限り、ブートストラップ クラスタはクラスタの作成が正常に完了すると削除されます。ブートストラップ クラスタでは、Docker がコンテナ イメージを pull する必要があります。
クラスタをインストールするには、管理ワークステーションが次の要件を満たしている必要があります。
オペレーティング システムが、サポートされている Linux ディストリビューションである。
サポートされている Linux OS とバージョンのリストについては、オペレーティング システムを選択するをご覧ください。このページには、各 OS の構成手順(Docker の構成など)へのリンクがあります。
Docker バージョン 19.03 以降がインストールされている。ただし、システムで cgroup v2 を使用する場合、管理ワークステーションへの Docker のインストールはバージョン 20.10.0 以降でなければなりません。(
/sys/fs/cgroup/cgroup.controllers
ファイルが存在することで、システムが cgroup v2 を使用しているかどうかを確認できます)。root ユーザー以外のユーザーが、
docker
グループのメンバーである(手順については、root ユーザー以外のユーザーとして Docker を管理するをご覧ください)。Google Cloud CLI がインストールされている。
クラスタの作成と管理には、
kubectl
ツールとbmctl
ツールを使用します。これらのツールをインストールするには、gcloud
ツールが必要です。gcloud
およびkubectl
コマンドライン ツールは gcloud CLI のコンポーネントです。コンポーネントのインストール手順など、インストール手順については、gcloud CLI をインストールするをご覧ください。kubectl
がインストールされている。gcloud CLI を使用して、次のコマンドでkubectl
をインストールします。gcloud components install kubectl
bmctl
が、作成または運用しているクラスタのバージョンにインストールされている。インストールには、
gcloud
を使用してbmctl
バイナリまたはイメージ パッケージをダウンロードすることが含まれます。手順については、Google Distributed Cloud on Bare Metal のダウンロードをご覧ください。
ハードウェア リソースの要件
管理ワークステーションでは、ツールを実行して、クラスタの作成と管理に関連するリソースを保存するために、大量のコンピューティング能力、メモリ、ストレージを必要とします。
デフォルトでは、クラスタのアップグレードとクラスタ作成のオペレーションでは、ブートストラップ クラスタが使用されます。ブートストラップ クラスタを使用すると、CPU とメモリの使用量が大幅に増加します。管理ワークステーションをコントロール プレーン ノードとして使用する場合は、管理ワークステーションのアクティビティによってクラスタ コントロール プレーンの機能に障害が発生しないように、推奨される上限の CPU と RAM を使用します。
etcd データベースのサイズとコントロール プレーン ノードの数によっては、クラスタのバックアップと復元のオペレーションで大量の RAM が消費されます。バックアップに必要な RAM の概算量は、コントロール プレーン ノードごとに 3~5 GiB です。メモリが不足しているためバックアップ プロセスが失敗します。これに合わせて RAM の要件を計画します。
次の表は、管理ワークステーションの最小および推奨のハードウェア要件を示したものです。
リソース | 最小 | 推奨 |
---|---|---|
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 のみをサポートします。
ネットワーキングの要件
管理ワークステーションは、Google Cloud とすべてのクラスタノードにアクセスする必要があります。
Google Cloud にアクセスする
管理ワークステーションは、Google Cloud にアクセスして、ツールとイメージのダウンロードとインストール、認可リクエストの処理、サービス アカウントの作成、ロギングとモニタリングの管理などを行います。Google Cloud にアクセスできないと、クラスタを作成できません。
Google Cloud へのアクセスは直接またはプロキシ サーバー経由のいずれかになります。Google Cloud に接続するさまざまな方法については、Google に接続するをご覧ください。プロキシ サーバーの構成については、プロキシの背後でインストールするをご覧ください。
Google Cloud へのアクセスの中断による影響については、Google Cloud からの一時的な接続解除の影響をご覧ください。
ノードへのアクセス
管理ワークステーションからクラスタを作成して管理するには、ノードマシンに対する次のアクセス権が必要です。
- すべてのクラスタノード マシンへのレイヤ 3 接続。
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
として)ノードマシンにログインできます。