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

これは、単一のユーザー クラスタを使用した Google Distributed Cloud の小規模な概念実証のインストールについて説明するガイドの最初のパートです。

このドキュメントでは、このインストール用に最小限の 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 つの物理的な、2.7 Ghz でハイパースレッディングが有効なCPU
    • 80 ギビバイト（GiB）の RAM
    • 128 GiB のストレージ

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

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

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

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

  • ESXi ホスト構成:

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

  • Datastore 構成:

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

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

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

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

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

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 は、クラスタ内の特定のノードに関連付けられていません。これは、MetaLB のロードバランサが個々の 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 ホスト名 Description 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 Description IP アドレス
管理クラスタの Kubernetes API サーバーの VIP 管理クラスタのロードバランサで構成。 172.16.20.58

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

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

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

VIP Description 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
ユーザー クラスタ サービス10.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 アドレスを使用することが推奨される理由の 1 つは次のとおりです。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 がクラスタから Kubernetes 監査ログを Cloud Audit Logs に送信するために使用できるサービス アカウントを作成します。これは監査ロギング サービス アカウントと呼ばれます。

    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.comAPI を初期化する必要があります。これを行うには、クラスタの作成に使用できるバージョンを表示する gcloud CLI コマンドを実行します。

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

    次のステップ

基本クラスタを作成する