このドキュメントでは、Google Distributed Cloud の管理ワークステーションを作成する方法について説明します。管理ワークステーションは、インストール中にクラスタをプロビジョニングするためのコマンドライン インターフェース(CLI)ツールと構成ファイルをホストします。また、インストール後に、プロビジョニングされたクラスタとやり取りするための CLI ツールもホストします。
このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。
ここでは手順全体を詳しく解説します。管理ワークステーションの作成の概要については、基本クラスタの作成ガイドで管理ワークステーションを作成するをご覧ください。
管理ワークステーションを作成する方法は 2 つあります。
gkeadm
を使用して、vSphere 環境に管理ワークステーション VM を作成します。任意のパソコンにユーザー管理の管理ワークステーションを作成します。
gkeadm
始める前に
複数の 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
のいくつかのフィールドには、デフォルト値や生成された値がすでに入力されています。入力された値をそのまま使用することも、必要に応じて変更することもできます。
入力が必要なフィールド
次の必須フィールドに入力します。フィールドに入力する方法については、管理ワークステーションの構成ファイルをご覧ください。
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"
ログイン
- 任意の Google アカウントでログインします。SDK の
account
プロパティが設定されます。
gcloud auth login
- SDK の
account
プロパティが正しく設定されていることを確認します。
gcloud config list
- SDK の
account
プロパティとして設定された Google アカウントは、SDK アカウントと呼ばれます。gkeadm
コマンドライン ツールは、SDK アカウントを使用して管理ワークステーション OVA をダウンロードし、Google Cloud プロジェクトでサービスを有効にします。
gkeadm
によってサービス アカウントが自動的に作成されるようにした場合、gkeadm
は、SDK アカウントを使用してサービス アカウントとキーを作成し、サービス アカウントにロールを付与します。つまり gkeadm
を実行して管理ワークステーションを作成する前に、SDK account
プロパティを設定することが重要です。
出力には、SDK account
プロパティの値が表示されます。例:
[core] account = my-name@google.com 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 プロジェクトの IDACCOUNT
: 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
: コンポーネント アクセス サービス アカウントの親プロジェクトの IDACCOUNT
: 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 のインスタンスにアクセスする必要があります。詳細については、以下をご覧ください。
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 以降
以前の Docker バージョンをすべて削除します。
sudo dnf remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine
podman-manpages を削除します。
sudo dnf remove podman-manpages
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
バージョン 19.03 以降が実行されていることを確認します。
sudo docker version
出力と次の例を比較して、クライアントとサーバーのバージョンが 19.03 以降であることを確認します。
Client: Docker Engine - Community Version: 19.03.13 ... Server: Docker Engine - Community Engine: Version: 19.03.13
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 = my-name@google.com 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 キーファイルを作成していることを確認します。
また、必要に応じて、オプションのサービス アカウントと JSON キーファイルを作成していることを確認します。
すべての JSON キーファイルを管理ワークステーションのホーム ディレクトリに配置します。
トラブルシューティング
次のセクションでは、SSH 認証鍵が失われた場合や破損した場合に、管理ワークステーションへの SSH アクセスを再度有効にします。
SSH 認証鍵の復元
一時 VM を使用して次の操作を行います。
新しい SSH 認証鍵のセットを生成するには、Compute Engine ドキュメントの SSH 認証鍵を作成するの説明に従います。
一時 VM と管理ワークステーションが
Powered Off
状態であることを確認します。vSphere 内で、管理ワークステーションのブートディスクを一時 VM にアタッチします。
ブートディスクには
Hard disk 1
というラベルが付いています。次のコマンドを実行して、VM 内にブートディスクをマウントします。
sudo mkdir -p /mnt/boot-disk sudo mount DISK_ID /mnt/boot-disk
DISK_ID
は、ブートディスク ID に置き換えます。この ID の形式はdev/sdc1
に似ています。ブートディスクの
authorized_keys
ファイルを編集して、最初の手順で生成した公開鍵ファイルの内容を追加します。vi /mnt/boot-disk/.ssh/authorized_keys
一時 VM をシャットダウンします。
管理ワークステーションをパワーオンします。
新しく生成された秘密鍵を使用して、管理ワークステーションにアクセスします。
ssh -i ~/.ssh/new-admin-ws.key ubuntu@"${ADMIN_WS_IP}"
新しく生成された秘密鍵を使用して、管理ワークステーションへのアクセスを続行します。