管理ワークステーションの作成

このドキュメントでは、Google Distributed Cloud の管理ワークステーションを作成する方法について説明します。管理ワークステーションは、インストール中にクラスタをプロビジョニングするためのコマンドライン インターフェース（CLI）ツールと構成ファイルをホストします。また、インストール後に、プロビジョニングされたクラスタとやり取りするための CLI ツールもホストします。

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

ここでは手順全体を詳しく解説します。管理ワークステーションの作成の概要については、基本クラスタの作成ガイドで管理ワークステーションを作成するをご覧ください。

管理ワークステーションを作成する方法は 2 つあります。

• gkeadm を使用して、vSphere 環境に管理ワークステーション VM を作成します。

• 任意のパソコンにユーザー管理の管理ワークステーションを作成します。

gkeadm

始める前に

vCenter サーバーのアドレスを確認します。

CA 証明書のパスを確認します。

Google Cloud CLI をインストールします。

複数の Google Cloud プロジェクトの使用の説明に従って、1 つ以上の Google Cloud プロジェクトを作成します。

サービス アカウントの計画

gkeadm を使用して管理ワークステーションを作成するときに、gkeadm でサービス アカウントとキーの一部を自動的に作成することもできます。この場合、gkeadm により、適切な Identity and Access Management ロールがサービス アカウントに付与されます。

また、サービス アカウントとキーを手動で作成することもできます。その場合、IAM のロールをサービス アカウントに手動で付与する必要があります。

サービス アカウントを手動で作成すると、gkeadm で作成する場合よりもサービス アカウントを柔軟に作成できます。

• 自動的に作成されたサービス アカウントは、コンポーネント アクセス サービス アカウントと同じ親 Google Cloud プロジェクトを持ちます。サービス アカウントを手動で作成する場合は、親 Google Cloud プロジェクトを選択できます。

• 自動的に作成されたサービス アカウントには、コンポーネント アクセス サービス アカウントの親の Google Cloud プロジェクトに対する IAM のロールがすべて付与されます。クラスタに関連付けられている Google Cloud プロジェクトが 1 つだけであれば問題ありませんが、クラスタに複数の Google Cloud プロジェクトが関連付けられている場合は、選択した Google Cloud プロジェクトのサービス アカウントにロールを付与できるようにする必要があります。

独自のサービス アカウントを作成する場合は、サービス アカウントとキーの手順で作成してください。

gkeadm によって自動的にサービス アカウントを作成している場合でも、コンポーネント アクセス サービス アカウントは手動で作成する必要があります。コンポーネント アクセス サービス アカウントを作成して適切な IAM ロールを付与する方法については、コンポーネント アクセス サービス アカウントをご覧ください。

このほかにも、監査ロギング サービス アカウントも手動で作成する必要があります。GKE On-Prem API クライアントを使用してユーザー クラスタを管理する場合は、管理クラスタ内で監査ロギングを有効にする必要があります。

構成ファイルのテンプレートを生成する

現在のディレクトリに gkeadm をダウンロードします。

テンプレートを生成します。

./gkeadm create config

上記のコマンドにより、現在のディレクトリに次のファイルが作成されます。

• credential.yaml
• admin-ws-config.yaml

credential.yaml の入力

credential.yaml に vCenter のユーザー名とパスワードを入力します。例:

kind: CredentialFile
items:
- name: vCenter
username: "my-account-name"
password: "AadmpqGPqq!a"

admin-ws-config.yaml の入力

注: 管理ワークステーションに特殊文字は使用できません。また、作成後に名前を変更することはできません。

admin-ws-config.yaml のいくつかのフィールドには、デフォルト値や生成された値がすでに入力されています。入力された値をそのまま使用することも、必要に応じて変更することもできます。

すでに入力されているフィールドを確認します。

vCenter:
credentials:
  fileRef:
  path: credential.yaml
  entry: vCenter

adminWorkstation:
name: gke-admin-ws-...
cpus: 4
memoryMB: 8192

diskGB: 100
dataDiskName: gke-on-prem-admin-workstation-data-disk,,,.vmdk
dataDiskMB: 512
network:
  ntpServer: ntp.ubuntu.com

警告: 管理クラスタとユーザー クラスタに静的 IP を使用する場合は、admin-ws-config.yaml で指定された管理ワークステーション名が IP ブロック ファイル admin-ip-block.yaml と user-ip-block.yaml にホスト名として含まれていないことを確認してください。

入力が必要なフィールド

次の必須フィールドに入力します。フィールドに入力する方法については、管理ワークステーションの構成ファイルをご覧ください。

gcp:
 componentAccessServiceAccountKeyPath: "Fill in"
vCenter:
credentials:
  address: "Fill in"
datacenter: "Fill in"
datastore: "Fill in"
cluster: "Fill in"
network: "Fill in"
resourcePool: "Fill in"
caCertPath: "Fill in"

vSphere VM フォルダ内に管理ワークステーションを作成する場合は、vCenter.folder フィールドに入力します。

vCenter:
folder: "Fill in"

管理ワークステーションがプロキシ サーバーの背後にある場合は、次のように proxyURL フィールドに入力します。

adminWorkstation:
proxyURL: "Fill in"

管理ワークステーションが DHCP サーバーから IP アドレスを取得する場合は、ipAllocationMode を "dhcp" に設定して、hostconfig セクションを削除します。

adminWorkstation:
network:
  ipAllocationMode: "dhcp"

管理ワークステーションに静的 IP アドレスを指定する場合は、ipAllocationMode を "static" に設定し、hostconfig セクションに入力します。

adminWorkstation:
network:
  ipAllocationMode: "static"
  hostconfig:
    ip: "Fill in"
    gateway: "Fill in"
    netmask: "Fill in"
    dns:
    - "Fill in"

注: vCenter ネットワークで、入力した静的 IP アドレスがまだ使用されていないことを確認してください。

ログイン

1. 任意の Google アカウントでログインします。SDK の account プロパティが設定されます。

gcloud auth login

1. SDK の account プロパティが正しく設定されていることを確認します。

gcloud config list

1. SDK の account プロパティとして設定された Google アカウントは、SDK アカウントと呼ばれます。gkeadm コマンドライン ツールは、SDK アカウントを使用して管理ワークステーション OVA をダウンロードし、Google Cloud プロジェクトでサービスを有効にします。

gkeadm によってサービス アカウントが自動的に作成されるようにした場合、gkeadm は、SDK アカウントを使用してサービス アカウントとキーを作成し、サービス アカウントにロールを付与します。つまり gkeadm を実行して管理ワークステーションを作成する前に、SDK account プロパティを設定することが重要です。

出力には、SDK account プロパティの値が表示されます。例:

[core]
account = [e-mail]
disable_usage_reporting = False
Your active configuration is: [default]

SDK アカウントにロールを付与する

SDK アカウントには、コンポーネント アクセス サービス アカウントの親 Google Cloud プロジェクトに対する次の IAM ロールが必要です。これにより、gkeadm が Google Cloud プロジェクトでサービスを有効にできるようになります。

• serviceUsage.serviceUsageAdmin

gkeadm によってサービス アカウントが自動的に作成されるようにした場合は、SDK アカウントに、コンポーネント アクセス サービス アカウントの親プロジェクトに対する次のロールも付与されている必要があります。これにより、gkeadm がサービス アカウントとキーを作成できるようになります。

• resourcemanager.projectIamAdmin
• iam.serviceAccountCreator
• iam.serviceAccountKeyAdmin

Google Cloud プロジェクトにロールを付与するには、Google Cloud プロジェクトに対する特定の権限が必要です。詳細については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

必要な権限があれば、自分でロールを付与できます。それ以外の場合は、組織内の別のユーザーがロールを付与する必要があります。

必要なロールを SDK アカウントに付与するには:

Linux / macOS

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:ACCOUNT" \
  --role="roles/serviceusage.serviceUsageAdmin"

Windows

gcloud projects add-iam-policy-binding PROJECT_ID ^
  --member="user:ACCOUNT" ^
  --role="roles/serviceusage.serviceUsageAdmin"

次のように置き換えます。

• PROJECT_ID: コンポーネント アクセス サービス アカウントの親の Google Cloud プロジェクトの ID

• ACCOUNT: SDK アカウント

gkeadm がサービス アカウントを自動的に作成する場合に追加のロールを付与するには:

Linux / macOS

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:ACCOUNT" \
  --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:ACCOUNT" \
  --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:ACCOUNT" \
  --role="roles/iam.serviceAccountKeyAdmin"

Windows

gcloud projects add-iam-policy-binding PROJECT_ID ^
  --member="user:ACCOUNT" ^
  --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
  --member="user:ACCOUNT" ^
  --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID ^
  --member="user:ACCOUNT" ^
  --role="roles/iam.serviceAccountKeyAdmin"

次のように置き換えます。

• PROJECT_ID: コンポーネント アクセス サービス アカウントの親プロジェクトの ID

• ACCOUNT: SDK アカウント

管理ワークステーションの作成

次のコマンドを入力して、管理ワークステーションを作成します。gkeadm で connect-register と logging-monitoring サービス アカウントを作成する場合は、--auto-create-service-accounts フラグを含めます。これらのサービス アカウントを手動で作成する場合は、フラグを省略します。

./gkeadm create admin-workstation [--auto-create-service-accounts]

出力には、管理ワークステーションの作成に関する詳細情報が含まれます。

...
Getting ... service account...
...
********************************************************************
Admin workstation is ready to use.

Admin workstation information saved to /usr/local/google/home/me/my-admin-workstation
This file is required for future upgrades
SSH into the admin workstation with the following command:
ssh -i /usr/local/google/home/me/.ssh/gke-admin-workstation ubuntu@172.16.5.1
********************************************************************

管理ワークステーションへの SSH 接続の確立

上記の出力の終わり付近に、管理ワークステーションへの SSH 接続に使用できるコマンドが表示されています。ここで、そのコマンドを入力します。例:

ssh -i /usr/local/google/home/me/.ssh/gke-admin-workstation ubuntu@172.16.5.1

管理ワークステーション上のファイルを一覧表示します。

ls -1

出力には、コンポーネント アクセス サービス アカウントの 2 つのクラスタ構成ファイル（CA 証明書ファイルと JSON キーファイル）が表示されます。gkeadm によってサービス アカウントが作成されている場合には、そのサービス アカウントの JSON キーファイルも表示されます。例:

admin-cluster.yaml
user-cluster.yaml
vcenter-ca-cert.pem
component-access-key.json

管理ワークステーションで gkeadm がコンポーネント アクセス サービス アカウントを有効にしたことを確認します。

gcloud config get-value account

JSON キーファイルを管理ワークステーションにコピーする

クラスタを作成する前に、サービス アカウントの JSON キーファイルをホーム ディレクトリの管理ワークステーションにコピーする必要があります。

コンポーネント アクセス サービス アカウントのキーはすでに管理ワークステーションに存在します。

gkeadm create admin-workstation の実行時に --auto-create-service-accounts フラグを指定した場合、次のサービス アカウントのキーは、ホーム ディレクトリの管理ワークステーションにすでに存在しています。それ以外の場合は、管理ワークステーションのホーム ディレクトリに手動でキーをコピーする必要があります。

• Connect-register サービス アカウント
• logging-monitoring サービス アカウント

次のいずれかのサービス アカウントを作成した場合は、そのサービス アカウントのキーを管理ワークステーションのホーム ディレクトリに手動でコピーする必要があります。

• 使用状況測定サービス アカウント
• 監査ロギング サービス アカウント
• Binary Authorization サービス アカウント

バックアップ ファイルから管理ワークステーションを復元する

管理ワークステーションをアップグレードすると、gkeadm upgrade コマンドによってバックアップ ファイルが保存されます。今後、管理ワークステーションがなくなった場合や、アップグレードした管理ワークステーション上に存在したファイルの一部が失われた場合は、バックアップ ファイルを使用して、アップグレード直後の状態に復元された管理ワークステーションを作成できます。

バックアップ ファイルから管理ワークステーションを作成するには、次のコマンドを実行します。

gkeadm create admin-workstation --restore-from-backup ADMIN_WORKSTATION_NAME-backup.tar.gz

ADMIN_WORKSTATION_NAME は、管理ワークステーションの名前に置き換えます。

ユーザー管理

管理ワークステーションとして使用するコンピュータを選択します。Ubuntu または Red Hat Enterprise Linux（RHEL）を使用できます。要件は次のとおりです。

• Ubuntu 20.04 LTS または 22.04 LTS

  • 4 個の CPU コア
  • 8 GiB の RAM
  • 100 GiB のストレージ

• RHEL 8.6、8.7、8.8

  • 4 個の CPU コア
  • 12 GB の RAM
  • 256 GiB のストレージ

Google Cloud にアクセスする

管理ワークステーションは、ツールのダウンロードとインストール、承認リクエストの処理、サービス アカウントの作成などを行うために、Google Cloud にアクセスする必要があります。

Google Cloud に接続するさまざまな方法については、Google に接続するをご覧ください。

Google Cloud へのアクセスは直接またはプロキシ サーバー経由のいずれかになります。ファイアウォール ルールとプロキシ サーバーの構成については、プロキシとファイアウォール ルールをご覧ください。

vCenter Server へのアクセス

管理ワークステーションからクラスタを作成して管理するには、vCenter Server のインスタンスにアクセスする必要があります。詳細については、以下をご覧ください。

• vSphere の要件
• vCenter サーバーのアドレスを特定する
• vCenter CA ルート証明書の取得

NTP サーバーを設定する

クラスタが NTP サーバーを使用するように構成されている場合は、管理ワークステーションで時刻同期サービスを設定し、timedatectl がクラスタと同期した時刻を報告するようにする必要があります。これは、大幅な時間のずれが原因で、期限の不一致によって証明書の検証の失敗を回避するために必要です。

Ubuntu

chrony 時間サーバーの使用をおすすめします。

chrony をインストールするには:

sudo apt-get update
sudo apt install chrony

これにより、次の 2 つのバイナリが提供されます。

• chronyd - ネットワーク タイム プロトコルを介して同期して提供するデーモン
• chronyc - chrony デーモンのコマンドライン インターフェース

chronyd を構成するには、次の手順を実行します。

/etc/chrony/chrony.conf を編集して、サーバー行を追加または削除します。次に、chrony を再起動します。

sudo systemctl restart chrony.service

RHEL

chrony 時間サーバーの使用をおすすめします。

インストール手順については、chrony の構成方法をご覧ください。

パスワードなしの sudo

セキュリティ ポリシーで許可されている場合は、現在のユーザーに対してパスワードなしの sudo を有効にします。これにより、gkectl が非公開のレジストリを準備します。ネットワークがプロキシ サーバーの背後にある場合は Docker のプロキシを設定し、削除が失敗した場合の管理クラスタのライフサイクルに使用するブートストラップ クラスタを強制的に削除できます。

パスワードなしの sudo を有効にせず、管理クラスタに非公開レジストリを使用する場合は、管理クラスタを作成する前に次の手動構成を行います。

• このディレクトリに非公開レジストリの CA ルート証明書を配置します。

  /etc/docker/certs.d/REGISTRY_ADDRESS/

  REGISTRY_ADDRESS は、非公開レジストリを実行するマシンのアドレスに置き換えます。

  詳細については、証明書を使用してリポジトリ クライアントを検証するをご覧ください。

• ネットワークがプロキシ サーバーの背後にある場合は、管理クラスタの構成ファイルでプロキシ サーバーを指定し、プロキシ サーバーを使用するように Docker を構成します。

パスワードなしの sudo を有効にしない場合、管理クラスタを作成した後に kind クラスタを手動で削除する必要があります。詳細については、トラブルシューティング ドキュメントの Kind クラスタが削除されないをご覧ください。

ソフトウェアをインストールする

Ubuntu

以下のソフトウェアをインストールします。

• Docker バージョン 19.03 以降: Ubuntu に Docker Engine をインストールするをご覧ください。root 以外のユーザーが docker グループのメンバーであることを確認します。root 以外のユーザーとして Docker を管理するをご覧ください。

• Google Cloud CLI の最新バージョン: gcloud CLI をインストールするをご覧ください。

• kubectl: gcloud components install kubectl を実行するか、apt-get を使用します。

sudo apt-get update
sudo apt-get -y install kubectl

RHEL

以下のソフトウェアをインストールします。

Docker 19.03 以降

1. 以前の Docker バージョンをすべて削除します。

   sudo dnf remove docker \
     docker-client \
     docker-client-latest \
     docker-common \
     docker-latest \
     docker-latest-logrotate \
     docker-logrotate \
     docker-engine
   

2. podman-manpages を削除します。

   sudo dnf remove podman-manpages
   

3. Docker 19.03 以降をインストールします。

   sudo dnf install -y yum-utils
   
   sudo yum-config-manager \
     --add-repo \
     https://download.docker.com/linux/centos/docker-ce.repo
   
   sudo dnf install -y --allowerasing docker-ce docker-ce-cli containerd.io
   
   sudo systemctl start docker
   

4. バージョン 19.03 以降が実行されていることを確認します。

   sudo docker version
   

5. 出力と次の例を比較して、クライアントとサーバーのバージョンが 19.03 以降であることを確認します。

   Client: Docker Engine - Community
   Version:           19.03.13
   ...
   Server: Docker Engine - Community
   Engine:
   Version:          19.03.13
   

6. Docker が動作していることを確認します。

   docker run hello-world
   

   次のように表示されます。

   Hello from Docker!
   

   This message shows that your installation appears to be working correctly.

Google Cloud CLI の最新バージョン:

gcloud CLI をインストールするをご覧ください。

kubectl

gcloud components install kubectl を実行します。

ログイン

SDK の account プロパティとして設定された Google アカウントは、SDK アカウントと呼ばれます。gkectl コマンドライン ツールは、SDK アカウントを使用してクラスタノード OVA のダウンロード、コンテナ イメージの pull などを行います。そのため、gkectl コマンドを実行する前に SDK アカウント プロパティを設定することが重要です。

任意の Google アカウントでログインします。SDK の account プロパティが設定されます。

gcloud auth login

SDK の account プロパティが正しく設定されていることを確認します。

gcloud config list

出力には、SDK account プロパティの値が表示されます。例:

[core]
account = [e-mail]
disable_usage_reporting = False
Your active configuration is: [default]

gkectl とバンドルをダウンロードする

gkectl をインストールするディレクトリに移動します。

gkectl をダウンロードします。

gcloud storage cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

VERSION は、Google Distributed Cloud のバージョンに置き換えます。例: 1.16.0-gke.1

Google Distributed Cloud バンドルをダウンロードします。バージョンが、gkectl のダウンロードに使用したバージョンと一致していることを確認します。

gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

サービス アカウントとキー

次の必須のサービス アカウントと JSON キーファイルを作成していることを確認します。

• コンポーネント アクセス
• connect-register
• logging-monitoring

また、必要に応じて、オプションのサービス アカウントと JSON キーファイルを作成していることを確認します。

• 監査ロギング
• 使用状況測定

すべての JSON キーファイルを管理ワークステーションのホーム ディレクトリに配置します。

トラブルシューティング

次のセクションでは、SSH 認証鍵が失われた場合や破損した場合に、管理ワークステーションへの SSH アクセスを再度有効にします。

SSH 認証鍵の復元

一時 VM を使用して次の操作を行います。

1. 新しい SSH 認証鍵のセットを生成するには、Compute Engine ドキュメントの SSH 認証鍵を作成するの説明に従います。

2. 一時 VM と管理ワークステーションが Powered Off 状態であることを確認します。

3. vSphere 内で、管理ワークステーションのブートディスクを一時 VM にアタッチします。

   ブートディスクには Hard disk 1 というラベルが付いています。

4. 次のコマンドを実行して、VM 内にブートディスクをマウントします。

   sudo mkdir -p /mnt/boot-disk
   sudo mount DISK_ID /mnt/boot-disk
   

   DISK_ID は、ブートディスク ID に置き換えます。この ID の形式は dev/sdc1 に似ています。

5. ブートディスクの authorized_keys ファイルを編集して、最初の手順で生成した公開鍵ファイルの内容を追加します。

   vi /mnt/boot-disk/.ssh/authorized_keys
   

6. 一時 VM をシャットダウンします。

7. 管理ワークステーションをパワーオンします。

8. 新しく生成された秘密鍵を使用して、管理ワークステーションにアクセスします。

   ssh -i ~/.ssh/new-admin-ws.key ubuntu@"${ADMIN_WS_IP}"
   

新しく生成された秘密鍵を使用して、管理ワークステーションへのアクセスを続行します。

次のステップ

管理クラスタを作成する