最小限のインフラストラクチャを設定する

これは、単一のユーザー クラスタを使用した VMware 用 Google Distributed Cloud（ソフトウェアのみ）の小規模な概念実証のインストールについて説明するガイドの最初のパートです。このページは、技術インフラストラクチャの設定、モニタリング、管理を行う管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

このドキュメントでは、このインストール用に最小限の vSphere 環境と Google Cloud 環境を設定し、IP アドレスを計画する方法について説明します。また、フォローアップの基本的なクラスタを作成するでは、管理ワークステーション、管理クラスタ、ユーザー クラスタを作成する方法について説明します。

このガイドに従って設定したインフラストラクチャは、実際の本番環境でのニーズやユースケースに適していない可能性があります。本番環境でのインストールの詳細については、インストールの概要とガイドをご覧ください。

始める前に

手順の概要

この設定における主な手順は次のとおりです。

  1. 環境を設定する。リソースの要件を満たしていることを確認します。ここでは、このインストールの要件を満たす ESXi ホストと vSphere データストアの構成例が示されます。
  2. vSphere オブジェクトを設定する。Google Distributed Cloud コンポーネントは、vSphere オブジェクト階層内で実行されます。
  3. IP アドレスを計画する。Google Distributed Cloud では、管理者とユーザーがデプロイメントにアクセスするための仮想 IP アドレス（VIP）に加えて、すべてのノードの IP アドレスを指定する必要があります。この設定では、クラスタノードに静的 IP アドレスを使用します。例が示されますが、実際のネットワークに適したアドレスを選択するために、ネットワーク管理者に相談することをおすすめします。
  4. ファイアウォール ルールとプロキシルールを構成する
  5. Google Cloud リソースを設定する。これには、Google Distributed Cloud の設定と管理を行う際に使用する Google Cloud プロジェクトや、Google Distributed Cloud のコンポーネント ソフトウェアにアクセスしてダウンロードするために必要な権限を持つサービス アカウントが含まれます。

1. 環境を設定する

この最小限のインストールでは、ESXi を実行する単一の物理ホストを使用できます。

  1. ホストに次の CPU、RAM、ストレージの最小容量があることを確認します。

    • 8 個の物理的な CPU。各 CPU は 2.7 Ghz で、ハイパースレッディングが有効になっている
    • 80 ギビバイト（GiB）の RAM
    • 470 GiB のストレージ

  2. ESXi バージョン 7.0u2 以降がインストールされていることを確認します。

  3. vCenter Server バージョン 7.0u2 以降を使用していることを確認します。

ホストとデータストアの例

要件を満たす ESXi ホストと vSphere データストアの例を次に示します。

  • ESXi ホスト構成:

    • メーカー: Dell Inc.
    • 物理 CPU: 2.7 GHz の CPU が 8 個
    • プロセッサ タイプ: 2.70 GHz の Intel(R) Xeon(R) Platinum 8168 CPU
    • プロセッサ ソケット: 2
    • ESXi バージョン: 7.0u2 以降
    • vCenter Server のバージョン: 7.0u2 以降
    • ハイパースレッディング: 有効

  • データストア構成:

    • タイプ: VMFS 6.82
    • ドライブの種類: SSD
    • ベンダー: DELL
    • ドライブの種類: 論理
    • RAID レベル: RAID1

2. vSphere オブジェクトを設定する

vSphere 環境で次のオブジェクトを設定します。

vSphere データセンター、クラスタ、データストア、ネットワークの名前をメモします。これらは、基本的なクラスタを作成するで管理ワークステーションを設定するときに必要になります。

vSAN データストアを設定している場合は、govc を使用して、Google Distributed Cloud の仮想マシンディスク（VMDK）に使用する datastore ディレクトリにフォルダを作成します。

govc datastore.mkdir -namespace=true data-disks

3. IP アドレスを計画する

Google Distributed Cloud の概要で説明したように、Google Distributed Cloud のインストールには、次のような多数の IP アドレスが必要です。

  • すべてのノード用の IP アドレス
  • Kubernetes API サーバーなどのコントロール プレーン コンポーネントとユーザー クラスタ上で実行されるアプリケーションにアクセスするための仮想 IP アドレス（VIP）
  • Pod と Service 間の通信の CIDR 範囲

このため、Google Distributed Cloud を設定するうえで、IP アドレスの計画は重要な作業となります。アドレスの競合が発生しないか確認することも重要です。この単純なインストールの場合でも、構成のための適切な値を見つけるには、ネットワーク管理者の協力が必要になる場合があります。このセクションの残りの部分では、架空のネットワークでこのインストールが機能する値の具体例を紹介します（実際の値は異なります）。

  • この最小限のインストールのクラスタでは、バンドルされた MetalLB ロードバランサを使用します。このロードバランサはクラスタノード上で実行されるため、ロード バランシング用の追加の VM は必要ありません。

  • Google Distributed Cloud では、クラスタノードに静的 IP アドレスを指定するか、DHCP サーバーを使用するかを選択できます。この簡単なインストールでは、静的 IP アドレスを使用します。

VLAN の例

この小規模なインストールでは、管理ワークステーション、管理クラスタノード、ユーザー クラスタノードを vSphere ネットワークの同じ VLAN に配置することをおすすめします。たとえば、172.16.20.0/24 の範囲内のすべての IP アドレスが特定の VLAN にルーティングされているとします。また、ネットワーク管理者は、VM と仮想 IP アドレス（VIP）に 172.16.20.49～172.16.20.69 を使用できると説明しているとします。

次の図は、管理ワークステーション、管理クラスタ、ユーザー クラスタがある VLAN を示しています。VIP は、クラスタ内の特定のノードに関連付けられていません。これは、MetalLB のロードバランサが個々の Service の VIP を通知するノードを選択できるためです。たとえば、ユーザー クラスタで、1 つのワーカーノードが 172.16.20.64 をアナウンスし、別のワーカーノードが 172.16.20.65 をアナウンスできます。

管理クラスタとユーザー クラスタの IP アドレス。
管理クラスタとユーザー クラスタの IP アドレス（クリックして拡大）

IP アドレスの例: 管理ワークステーション

管理ワークステーションに対して、この例では、ネットワーク管理者から指定された範囲の最初のアドレス（172.16.20.49）を使用しています。

IP アドレスの例: クラスタノード

次の表は、クラスタノードで IP アドレスを使用する例を示しています。この表では、2 つの追加ノード（admin-vm-6 と user-vm-5）のアドレスが示されています。この追加のノードはクラスタのアップグレード、更新、自動修復中に必要になります。詳細については、ノード IP アドレスを管理するをご覧ください。

VM ホスト名 説明 IP アドレス
admin-vm-1 管理クラスタのコントロール プレーン ノード。 172.16.20.50
admin-vm-2 管理クラスタのコントロール プレーン ノード。 172.16.20.51
admin-vm-3 管理クラスタのコントロール プレーン ノード。 172.16.20.52
user-vm-1 ユーザー クラスタのコントロール プレーン ノード。 172.16.20.53
user-vm-2 ユーザー クラスタのワーカーノード 172.16.20.54
user-vm-3 ユーザー クラスタのワーカーノード 172.16.20.55
user-vm-4 ユーザー クラスタのワーカーノード 172.16.20.56
user-vm-5 172.16.20.57

IP アドレスの例: 管理クラスタの VIP

次の表に、管理クラスタのコントロール プレーン VIP を指定する方法の例を示します。

VIP 説明 IP アドレス
管理クラスタの Kubernetes API サーバーの VIP 管理クラスタのロードバランサで構成。 172.16.20.58

IP アドレスの例: ユーザー クラスタの VIP

次の表に、ユーザー クラスタの VIP を指定方法の例を示します。

ユーザー クラスタの Kubernetes API サーバーの VIP と上り（内向き）VIP は、どちらもワーカーノードとコントロールプレーン ノードと同じ VLAN にあります。

VIP 説明 IP アドレス
ユーザー クラスタの Kubernetes API サーバーの VIP 管理クラスタのロードバランサで構成。 172.16.20.59
Ingress VIP ユーザー クラスタのロードバランサで構成。 172.16.20.60
サービス VIP LoadBalancer タイプの Service 用の 10 個のアドレス。
必要に応じて、ユーザー クラスタのロードバランサで構成されます。
この範囲には上り（内向き）VIP が含まれます。これは MetalLB ロードバランサの要件です。		 172.16.20.60 - 172.16.20.69

Pod と Service の IP アドレス

クラスタノードの IP アドレスとデプロイメントにアクセスするための IP アドレスに加えて、各クラスタ内でクラスタ内トラフィックに使用できるアドレス範囲も指定する必要があります。

これを行うには、Pod の IP アドレス用に CIDR 範囲を、また Kubernetes Services の ClusterIP アドレス用に別の CIDR 範囲を指定する必要があります。これらは、このガイドの次のセクションで説明するように、クラスタ構成の一部として指定されます。

IP の計画の一環として、Pod と Service に使用する CIDR 範囲を決定します。特に理由がない限り、次のデフォルト範囲を使用します。

目的デフォルトの CIDR 範囲
管理クラスタ Pod192.168.0.0/16
ユーザー クラスタ Pod192.168.0.0/16
管理クラスタ Service10.96.232.0/24
ユーザー クラスタ Service10.96.0.0/20

デフォルト値は、次のことを表しています。

  • Pod CIDR 範囲は、複数のクラスタで同じにできます。

  • クラスタの Service CIDR 範囲は、他のクラスタの Service CIDR 範囲と重複しないようにする必要があります。

  • 通常、Service よりも多くの Pod が必要であるため、特定のクラスタでは Service CIDR 範囲よりも広い Pod CIDR 範囲が必要になる場合があります。たとえば、ユーザー クラスタのデフォルトの Pod 範囲は 2^(32-16) = 2^16 個のアドレスですが、ユーザー クラスタのデフォルト Service 範囲は 2^(32-20) = 2^12 個のアドレスのみです。

重複を回避する

ネットワークで到達可能な IP アドレスと重複しないように、デフォルト以外の CIDR 範囲の使用が必要になる場合があります。Service と Pod の範囲は、クラスタ内から到達可能にする必要があるクラスタ外のアドレスと重複しないようにしてください。

たとえば、Service の範囲が 10.96.232.0/24、Pod の範囲が 192.168.0.0/16 であるとします。Pod からいずれかの範囲のアドレスに送信されたトラフィックは、クラスタ内として扱われ、クラスタ外の宛先に到達しません。

特に、Service と Pod の範囲が次の対象と重複しないようにする必要があります。

  • 任意のクラスタ内に存在するノードの IP アドレス

  • ロードバランサ マシンで使用される IP アドレス

  • コントロール プレーン ノードとロードバランサで使用される VIP

  • vCenter Server、DNS サーバー、NTP サーバーの IP アドレス

Pod と Service の範囲には、RFC 1918 で定義されている内部 IP アドレス範囲を使用することをおすすめします。

RFC 1918 アドレスを使用することが推奨される理由の一つは次のとおりです。Pod または Service の範囲に外部 IP アドレスが含まれているとします。Pod からそれらの外部アドレスのいずれかに送信されたトラフィックは、クラスタ内トラフィックとして扱われ、外部の宛先に到達しません。

DNS サーバーとデフォルト ゲートウェイ

管理者クラスタとユーザー クラスタを作成する前に、次の IP アドレスも把握している必要があります。

  • 管理ワークステーションとクラスタノードで使用できる DNS サーバー

  • クラスタノードで使用できる NTP サーバー

  • 管理ワークステーションとクラスタノードを持つサブネットのデフォルト ゲートウェイの IP アドレス。たとえば、管理ワークステーション、管理クラスタノード、ユーザー クラスタノードがすべて 172.16.20.0/24 のサブネットにあるとします。サブネットのデフォルト ゲートウェイのアドレスは、172.16.20.1 になる可能性があります。

4. ファイアウォールとプロキシを構成する

プロキシルールとファイアウォール ルールの説明に従って、必要な Google Distributed Cloud トラフィックを許可するようにファイアウォールとプロキシを構成します。このタスクを実行するには、前のセクションで特定したクラスタノード IP アドレスが必要です。ユーザー クラスタと管理クラスタの IP アドレスは特定のノードに割り当てられないため、関連するすべてのファイアウォール ルールが各クラスタのすべての IP アドレスに適用されるようにする必要があります。

5. Google Cloud リソースを設定する

Google Cloud プロジェクトは、Google Distributed Cloud のインストールと管理に使用されるサービスなど、すべての Google Cloud サービスの作成、有効化、使用の基礎となります。Google Cloud プロジェクトの操作に慣れていない場合は、プロジェクトの作成と管理で詳細をご覧ください。

  1. 既存の Google Cloud プロジェクトを選択するか、プロジェクトを新規に作成します。

  2. 後で必要になるので、Google Cloud プロジェクト ID はメモしておいてください。

Google Cloud CLI を設定する

Google Cloud CLI は、プロジェクトでの作業に使用できるコマンドライン ツールです。Google Cloud SDK のインストールの手順に沿って、最新バージョンを使用していることを確認してください。

必要な権限

プロジェクト オーナーの場合（プロジェクトを自分で作成した場合など）は、この単純なインストールの残りの部分を実行するために必要なすべての権限がすでに付与されています。プロジェクト オーナーではない場合、Google アカウントに必要な権限があることを確認する必要があります（自身で確認するか、プロジェクト管理者に確認します）。

次の IAM ロールを使用すると、サービス アカウントの作成、IAM ロールの割り当て、API の有効化が可能となり、この設定の後半で gkeadm ツールによるサービス アカウントの作成と管理を行えるようになります。

  • resourcemanager.projectIamAdmin
  • serviceusage.serviceUsageAdmin
  • iam.serviceAccountCreator
  • iam.serviceAccountKeyAdmin

IAM ロールを自分で付与するために必要な権限の詳細については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。これらの権限がない場合は、組織内の他のユーザーにロールの付与を依頼する必要があります。

ロールを付与するには:

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/serviceusage.serviceUsageAdmin"

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/serviceusage.serviceUsageAdmin"

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: Google Cloud プロジェクトの ID
  • ACCOUNT: Google アカウントを表すメールアドレス

サービス アカウントを設定する

Google Distributed Cloud で使用する Google Cloud プロジェクトには、4 つのサービス アカウントが必要です。この演習では、2 つのサービス アカウントが自動的に生成されます。残りの 2 つのサービス アカウントは手動で作成する必要があります。

  • Connect-register サービス アカウント（自動生成）
  • logging-monitoring サービス アカウント（自動生成）
  • 監査ロギング サービス アカウント（手動で作成）
  • コンポーネント アクセス サービス アカウント（手動で作成）

監査ロギング サービス アカウント

  1. Google Cloud プロジェクトで、Google Distributed Cloud がクラスタから Cloud Audit Logs に Kubernetes 監査ログを送信するときに使用できるサービス アカウントを作成します。これは監査ロギング サービス アカウントと呼ばれます。

    gcloud iam service-accounts create audit-logging-sa \
    --display-name "Audit Logging Service Account" \
    --project PROJECT_ID

    PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。

  2. 新しく作成した監査ロギング サービス アカウントのメールアドレスを取得します。

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. 監査ロギング サービス アカウントの JSON キーを作成します。

    gcloud iam service-accounts keys create audit-logging-key.json \
    --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING

    SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING は、監査ロギング サービス アカウントのメールアドレスに置き換えます。

    監査ロギング サービス アカウントにロールを付与する必要はありません。

コンポーネント アクセス サービス アカウント

  1. Google Cloud プロジェクトで、Google Distributed Cloud が Container Registry からクラスタ コンポーネントのコードをダウンロードするときに使用できるサービス アカウントを作成します。これは、コンポーネント アクセス サービス アカウントと呼ばれます。

    gcloud iam service-accounts create component-access-sa \
    --display-name "Component Access Service Account" \
    --project PROJECT_ID

    PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。

  2. 新しく作成したコンポーネント アクセス サービス アカウントのメールアドレスを取得します。

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. コンポーネント アクセス サービス アカウントの JSON キーを作成します。

    gcloud iam service-accounts keys create component-access-key.json \
   --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS

    SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS は、コンポーネント アクセス サービス アカウントのメールアドレスに置き換えます。

  4. コンポーネント アクセス サービス アカウントに次の IAM ロールを追加します。

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.roleViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.serviceAccountViewer"

Google API を有効にする

  1. Google Cloud プロジェクトで、次の Google API を有効にします。これにより、プロジェクト内の Google Distributed Cloud に必要なすべての Google Cloud サービスを使用できます。

    gcloud services enable --project PROJECT_ID \
    anthos.googleapis.com \
    anthosgke.googleapis.com \
    anthosaudit.googleapis.com \
    cloudresourcemanager.googleapis.com \
    connectgateway.googleapis.com \
    container.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    gkeonprem.googleapis.com \
    kubernetesmetadata.googleapis.com \
    serviceusage.googleapis.com \
    stackdriver.googleapis.com \
    opsconfigmonitoring.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    iam.googleapis.com \
    storage.googleapis.com

  2. プロジェクトで GKE On-Prem API（gkeonprem.googleapis.com）を初めて有効にした場合は、API を初期化する必要があります。これを行うには、ユーザー クラスタの作成に使用できるバージョンを表示する gcloud CLI コマンドを実行します。

    gcloud container vmware clusters query-version-config \
    --project=PROJECT_ID \
    --location="us-central1"

    次のステップ

基本クラスタを作成する