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

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

このページは、基盤となる技術インフラストラクチャのライフサイクルの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

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

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

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

bmctl を実行してコントロール プレーン ノードとして機能するために、管理ワークステーションにはノードと同じオペレーティング システム(OS)要件があります。管理ワークステーションには Docker が必要ですが、コンテナ ランタイムとして使用するためのものではありません。Google Distributed Cloud がクラスタを作成すると、管理ワークステーションに Docker 内の Kubernetes(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 認証鍵を作成し、公開鍵をクラスタノードと共有します。

  1. 各クラスタノード マシンで root SSH パスワード認証を有効にします。/etc/ssh/sshd_config ファイルで PermitRootLoginPasswordAuthentication の行をコメント解除するか追加して、値を 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 パスワード認証を有効にする必要があります。

  2. SSH 構成の変更を適用するには、SSH サービスを再起動します。

    sudo systemctl restart ssh.service
    
  3. 管理ワークステーションで秘密鍵と公開鍵のペアを生成します。鍵のパスフレーズは設定しないでください。次のコマンドを実行して鍵を生成します。

    ssh-keygen -t rsa
    

    SSH の設定に、クラスタノード マシンへの sudo ユーザー アクセスを使用することもできます。ただし、パスワードを持たない root ユーザー以外の接続では、spec.nodeAccess.loginUser フィールドを使用してクラスタ構成ファイルを更新する必要があります。このフィールドはデフォルトでコメントアウトされます。クラスタの作成中または作成後の任意の時点で、root 以外のユーザー名を loginUser で指定できます。詳細については、loginUser をご覧ください。

  4. 生成された公開鍵をクラスタ ノードマシンに追加します。

    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 アドレス。
  5. sshd_config ファイルで PasswordAuthenticationno に設定し、SSH サービスを再起動することで、クラスタノード マシンで SSH パスワード認証を無効にします。

  6. 管理ワークステーションで次のコマンドを使用して、ワークステーションとノードマシン間で公開鍵認証が機能することを確認します。

    ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
    

    SSH が適切に構成されると、パスワードを入力しなくても、管理ワークステーションから(root として)ノードマシンにログインできます。

次のステップ