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

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

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

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

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

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

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

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

    サポートされている Linux OS とバージョンのリストについては、オペレーティング システムを選択するをご覧ください。このページには、各 OS の構成手順(Docker の構成など)へのリンクがあります。

  • Docker バージョン 19.03 以降がインストールされている。

  • root ユーザー以外のユーザーが、docker グループのメンバーである(手順については、root ユーザー以外のユーザーとして Docker を管理するをご覧ください)。

  • Google Cloud CLI がインストールされている。

    クラスタの作成と管理には kubectl ツールと bmctl ツールを使用します。これらのツールをインストールするには、gcloud ツールと gsutil ツールが必要です。gcloudgsutilkubectl の各コマンドライン ツールは 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

ネットワーキングの要件

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

Google Cloud へのアクセス

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

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

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

ノードへのアクセス

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

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

ノードへの 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
    

    sudo ユーザー アクセスを使用して、クラスタノード マシンから SSH を設定することもできます。ただし、パスワードを持たない 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 ファイルのパスは ~/.ssh/id_rsa.pub です。
    • CLUSTER_NODE_IP: SSH 公開鍵を追加するノードマシンの IP アドレス。
  5. sshd_config ファイル内の PasswordAuthentication 行をコメントアウトして SSH サービスを再起動することで、クラスタノード マシンで SSH パスワード認証を無効にします。

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

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

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

次のステップ