AWS への管理クラスタの展開の準備

このトピックでは、Tanzu Kubernetes Grid を実行するために Amazon Web Services (AWS) を準備する方法について説明します。

Tanzu CLI またはインストーラインターフェイスを使用して管理クラスタを展開するには、事前に、Tanzu CLI を実行するブートストラップマシンを準備し、Amazon Web Services (AWS) アカウントを設定する必要があります。

VMware Cloud on AWS に Tanzu Kubernetes Grid をインストールする場合は、vSphere 環境にインストールします。環境の準備については、「VMware Cloud 環境への管理クラスタの展開の準備」にある「VMware Cloud on AWS の準備」を参照してください。管理クラスタの展開については、「vSphere への管理クラスタの展開の準備」を参照してください。

重要
Tanzu Kubernetes Grid v2.4.x は、AWS でのスタンドアローン TKG 管理クラスタの作成をサポートする TKG の最後のバージョンです。AWS でスタンドアローン TKG 管理クラスタを作成する機能は、Tanzu Kubernetes Grid v2.5 リリースで削除される予定です。

以降、VMware では、AWS で新しい TKG 管理クラスタを作成する代わりに、Tanzu Mission Control を使用してネイティブの AWS EKS クラスタを作成することをお勧めします。Tanzu Mission Control を使用してネイティブの AWS EKS クラスタを作成する方法については、Tanzu Mission Control ドキュメントの「AWS EKS クラスタのライフサイクルの管理」を参照してください。

詳細については、『VMware Tanzu Kubernetes Grid v2.4 Release Notes』の「AWS および Azure での TKG 管理クラスタとワークロードクラスタの廃止」を参照してください。

一般的な要件

Tanzu CLI がローカルにインストールされている。「スタンドアローン管理クラスタで使用する Tanzu CLI と Kubernetes CLI のインストール」を参照してください。
次を備えたアクティブな AWS アカウントがある。
- アクセスキーとアクセスキーシークレット。アクセスキーの詳細については、AWS ドキュメントの「AWS アカウントとアクセスキー」を参照してください。
- 「必要な AWS 権限」で説明されている権限。これらの権限により、Tanzu Kubernetes Grid は AWS にクラスタを作成し、管理できます。
管理クラスタを展開するアベイラビリティゾーン内の VPC。たとえば、手動で、または AWS CloudFormation や Terraform などのツールを使用して作成した VPC です。VPC は以下で構成する必要があります。
- 開発クラスタ用の 2 つのサブネット、または本番クラスタ用の 6 つのサブネット。
- 以下に示す NAT ゲートウェイ。それ以外の場合は、「NAT ゲートウェイなしの Amazon VPC」を参照してください。
  - 開発クラスタ用の 1 つの NAT ゲートウェイ、または本番クラスタ用の 3 つの NAT ゲートウェイ。
    - AWS のデフォルトの NAT ゲートウェイ割り当ては、1 アカウントにつき、アベイラビリティゾーンあたり 5 インスタンスです。管理クラスタを展開すると、すべてのワークロードクラスタが管理クラスタ VPC とその NAT ゲートウェイを共有します。
    - 「Amazon Web Services アカウントのリソース使用量」および AWS ドキュメントの「Amazon VPC クォータ」を参照してください。
  - 1 つのインターネットゲートウェイ、および対応するルーティングテーブル。
  - （オプション）適切なルールを使用して構成されたセキュリティグループ。
AWS アカウントに、Elastic IP (EIP) アドレスについての十分なリソース割り当てがある。デフォルトの EIP 割り当ては、1 アカウントにつき、リージョンあたり 5 つの EIP アドレスです。
ローカルブートストラップマシンと、作成するクラスタ内のすべての仮想マシンのポート 6443 間でトラフィックが許可されている。ポート 6443 では、Kubernetes API がデフォルトで公開されます。管理クラスタまたはワークロードクラスタについてこのポートを変更するには、クラスタの展開時に CLUSTER_API_SERVER_PORT 変数を設定します。
TCP について、ローカルブートストラップマシンと、管理クラスタのコンポーネント情報 (BOM) ファイルにリストされているイメージリポジトリとの間でトラフィックがポート 443 を介して許可されている。*
- BOM ファイルは ~/.config/tanzu/tkg/bom/ にあり、その名前には Tanzu Kubernetes Grid バージョンが含まれています（例：v2.4.0 の場合は tkg-bom-v2.4.0+vmware.1.yaml）。
- projects.registry.vmware.com/tkg など、すべての imageRepository 値に対して DNS ルックアップを実行して、アクセスを許可する CNAME を検索します。
AWS CLI がローカルにインストールされている。
jq がローカルにインストールされています。

AWS CLI ガイドでは、SSH キーペアの作成時に jq を使用して JSON を処理しています。また、これは、CLI を使用して Tanzu Kubernetes Grid を展開する際、環境変数または構成変数を準備するためにも使用されます。
CAPA の既知の問題を回避するには、ローカル環境または管理クラスタ構成ファイルで EXP_EXTERNAL_RESOURCE_GC=false を設定します。

* または、外部ネットワークアクセスなしでインストールする場合は、「インターネットが制限された環境の準備」を参照してください。

AWS アカウントのリソース使用量

作成するクラスタごとに、Tanzu Kubernetes Grid は、AWS アカウントに一連のリソースを使用します。

リソース	Tanzu Kubernetes Grid が使用
VPC	1
弾性 IP アドレス	アベイラビリティゾーン (AZ) あたり 1 つ*
サブネット	インターネットに接続する場合は AZ あたり 2 つ、内部の場合は AZ あたり 1 つ*
EC2 セキュリティグループ (VPC)	4
インターネットゲートウェイ	1
NAT Gateway	デフォルト* の展開の場合は AZ あたり 1 つ
制御プレーン EC2 インスタンス	AZ あたり 1*

*開発クラスタは 1 つのアベイラビリティゾーンを使用し、本番クラスタは 3 を使用します。

AWS はこれらのリソースにデフォルトの制限または割り当てを実装します。ユーザーはこの制限を変更できます。デフォルトの制限は通常、クラスタの作成と使用を開始するには十分ですが、クラスタまたはワークロード数を増やすと、これらの AWS 制限を超過し、Tanzu Kubernetes Grid による新しいクラスタの作成や、新しいワークロードの展開ができなくなる可能性があります。

AWS アカウントで指定した制限は定期的に評価し、ビジネスニーズに合わせてサービス割り当ての増加を必要に応じて要求することをお勧めします。

最も関連性の高いサービス割り当ては次のとおりです。

サービスコード	割り当て名	割り当てコード
vpc	リージョンあたりのインターネットゲートウェイ	L-A4707A72
vpc	アベイラビリティゾーンあたりの NAT ゲートウェイ	L-FE5A380F
vpc	リージョンあたりの VPC	L-F678F1CE
ec2	実行中のオンデマンド標準（A、C、D、H、I、M、R、T、Z）インスタンス	L-1216C47A
ec2	EC2 VPC 弾性 IP アドレス	L-0263D0A3
elasticloadbalancing	リージョンあたりのクラシックロードバランサ	L-E9E9831D

必要に応じて、新しい VPC を作成する代わりに VPC を共有することもできます（ワークロードクラスタが管理クラスタと VPC を共有する場合など）。

クラスタノードインスタンスのサイズの詳細については、AWS ドキュメントの「Amazon EC2 インスタンスタイプ」を参照してください。

NAT ゲートウェイなしの Amazon VPC

Tanzu Kubernetes Grid は、次のいずれかの条件が満たされると、NAT ゲートウェイが接続されていない VPC に展開できます。

ワークロードクラスタが展開されるサブネットに、インターネットへのルートが 0.0.0.0/0 のルートテーブルがある、または
「インターネットが制限された環境の準備」の説明に従って、展開環境でインターネットが制限されている。

Tanzu Kubernetes Grid では、ルーティングテーブルに特定のルートが存在するかどうかはチェックされません。したがって、VPC NAT ゲートウェイ、EC2 インスタンスまたはアプライアンス、インターネットゲートウェイ、中継ゲートウェイ、または DirectConnect を介したインターネット接続がサポートされます。

管理クラスタのサイズ設定の例

次の表は、AWS 上の管理クラスタのサイズ設定の例を示しています。このデータを指針として、管理クラスタの規模を、展開するワークロードクラスタ数を処理できるサイズに調整してください。「ワークロードクラスタ仮想マシンサイズ」列には、「管理可能な最大規模…」列の例で使用された仮想マシンのサイズが一覧表示されます。

管理クラスタのプラン	管理クラスタ仮想マシンサイズ	管理可能な最大規模…	ワークロードクラスタ仮想マシンサイズ
3 台の制御プレーンノードと 3 台のワーカーノード	制御プレーンノード：`m4.large`（CPU：2、メモリ：8 GB）ワーカーノード：`m4.large`（CPU：2、メモリ：8 GB）	例： 5 台のワークロードクラスタ（各クラスタに 3 台の制御プレーンと 200 台のワーカーノードを展開）、または 10 台のワークロードクラスタ（各クラスタに 3 台の制御プレーンと 50 台のワーカーノードを展開）	制御プレーンノード：`c4.large`（CPU：2、メモリ：3.75 GB）ワーカーノード：`c4.large`（CPU：2、メモリ：3.75 GB）
3 台の制御プレーンノードと 3 台のワーカーノード	制御プレーンノード：`m4.large`（CPU：2、メモリ：8 GB）ワーカーノード：`m4.large`（CPU：2、メモリ：8 GB）	例：1 台のワークロードクラスタ（3 台の制御プレーンと 500 台のワーカーノードを展開）	制御プレーンノード：`c5.4xlarge`（CPU：16、メモリ：32 GB）ワーカーノード：`c5.xlarge`（CPU：4、メモリ：8 GB）
3 台の制御プレーンノードと 3 台のワーカーノード	制御プレーンノード：`m4.xlarge`（CPU：4、メモリ：16 GB）ワーカーノード：`m4.xlarge`（CPU：4、メモリ：16 GB）	例：200 台のワークロードクラスタ（各クラスタに 3 台の制御プレーンと 5 台のワーカーノードを展開）	制御プレーンノード：`c4.large`（CPU：2、メモリ：3.75 GB）ワーカーノード：`c4.large`（CPU：2、メモリ：3.75 GB）

必要な AWS 権限

次のセクションでは、Tanzu Kubernetes Grid が AWS にクラスタを展開および管理するために必要とする権限を示します。

Tanzu Kubernetes Grid によって設定される権限：これらの権限は、tanzu mc permissions aws set コマンドを実行したとき、またはインストーラインターフェイスで [AWS CloudFormation スタックの作成の自動化 (Automate creation of AWS CloudFormation Stack)] チェックボックスを選択したときに、Tanzu Kubernetes Grid によって自動的に設定されます。
- Tanzu CLI エイリアス mc は、management-cluster の省略形です。
ユーザーが設定する権限：これらの権限は手動で追加します。

Tanzu Kubernetes Grid によって設定される権限

Tanzu Kubernetes Grid が AWS にクラスタを展開できるようにするには、AWS アカウントに CloudFormation スタック tkg-cloud-vmware-com を作成する必要があります。この CloudFormation スタックにより、Tanzu Kubernetes Grid が AWS でクラスタを展開および実行するために必要な ID とアクセス管理 (IAM) のリソースおよび権限が定義されます。

スタックを作成するには、このトピックの手順を完了した後、クラスタを展開する前に tanzu mc permissions aws set コマンドを実行するか、インストーラインターフェイスで [AWS CloudFormation スタックの作成の自動化 (Automate creation of AWS CloudFormation Stack)] チェックボックスを選択します。詳細については、「構成ファイルからの管理クラスタの展開」の「IAM リソースの作成」セクション、または「インストーラインターフェイスを使用した管理クラスタの展開」を参照してください。この操作は、Tanzu Kubernetes Grid 環境で使用する AWS リージョンの数が 1 つか複数かにかかわらず、AWS アカウントごとに 1 回のみ実行する必要があります。

tanzu mc permissions aws set を実行するか、[AWS CloudFormation スタックの作成の自動化 (Automate creation of AWS CloudFormation Stack)] を選択すると、次の IAM プロファイル、ロール、およびポリシーが作成されます。スタックの作成時に Tanzu Kubernetes Grid に指定した認証情報を持つユーザーには、AWS アカウントでこれらの IAM リソースを作成するための管理者権限が必要です。

プロファイル / AWS::IAM::InstanceProfile：
- 制御プレーン – control-plane.tkg.cloud.vmware.com：Kubernetes 制御プレーンコンポーネントを実行している EC2 インスタンスによって使用されます。
- ノード – nodes.tkg.cloud.vmware.com：Tanzu Kubernetes Grid クラスタ内のすべての非制御プレーン EC2 インスタンスで使用されます。
- コントローラ – controllers.tkg.cloud.vmware.com：インスタンスプロファイルが添付された EC2 のジャンプボックスから Tanzu Kubernetes Grid をブートストラップするために使用できます。
ロール / AWS::IAM::Role：これらは上記の AWS IAM インスタンスプロファイルに 1 対 1 でマッピングされます。
- 制御プレーン – control-plane.tkg.cloud.vmware.com
- ノード – nodes.tkg.cloud.vmware.com
- コントローラ – controllers.tkg.cloud.vmware.com
ポリシー / AWS::IAM::ManagedPolicy：
- arn:aws:iam::YOUR-ACCOUNT-ID:policy/control-plane.tkg.cloud.vmware.com：上記の制御プレーンの IAM ロールに接続されています。
- arn:aws:iam::YOUR-ACCOUNT-ID:policy/nodes.tkg.cloud.vmware.com：上記の制御プレーンおよびノードの IAM ロールに接続されています。
- arn:aws:iam::YOUR-ACCOUNT-ID:policy/controllers.tkg.cloud.vmware.com：上記の制御プレーンおよびコントローラの IAM ロールに接続されています。

Tanzu Kubernetes Grid によって AWS アカウントに CloudFormation スタックが作成されたら、AWS コンソールで [CloudFormation] > [スタック (Stacks)] に移動することでテンプレートを取得できます。CloudFormation スタックの詳細については、AWS ドキュメントの「スタックの操作」を参照してください。

または、tanzu mc permissions aws set を実行したり、[AWS CloudFormation スタックの作成の自動化 (Automate creation of AWS CloudFormation Stack)] を選択したりする代わりに、上記の IAM リソースを作成するために Tanzu Kubernetes Grid が使用するテンプレートを取得し、AWS アカウントで直接 tkg-cloud-vmware-com スタックを作成できます。このテンプレートを取得するには、tanzu mc permissions aws generate-cloudformation-template を実行します。

Tanzu Mission Control で必要な権限

以下の IAM 権限は、管理クラスタを Tanzu Mission Control に登録する場合にのみ必要です。これらの権限は、tanzu mc permissions aws set コマンドを実行すると、nodes.tkg.cloud.vmware.com IAM ロールに自動的に追加されます。

{
  "Action": [
    "servicequotas:ListServiceQuotas",
    "ec2:DescribeKeyPairs",
    "ec2:DescribeInstanceTypeOfferings",
    "ec2:DescribeInstanceTypes",
    "ec2:DescribeAvailabiilityZones",
    "ec2:DescribeRegions",
    "ec2:DescribeSubnets",
    "ec2:DescribeRouteTables",
    "ec2:DescribeVpcs",
    "ec2:DescribeNatGateways",
    "ec2:DescribeAddresses",
    "elasticloadbalancing:DescribeLoadBalancers"
  ],
  "Resource": [
    "*"
  ],
  "Effect": "Allow"
}

これらの権限を無効にするには、DISABLE_TMC_CLOUD_PERMISSIONS を true に設定してから、tanzu mc permissions aws set を実行します。詳細については、「管理クラスタの Tanzu Mission Control への登録」を参照してください。

ユーザーが設定する権限

AWS アカウントごとに 1 回、次の権限を手動で設定する必要があります。

インストーラインターフェイス

インストーラインターフェイスから管理クラスタを展開する場合、クラスタの展開時に Tanzu Kubernetes Grid に指定した認証情報を持つユーザーには、"ec2:DescribeInstanceTypeOfferings" 権限と "ec2:DescribeInstanceTypes" 権限が必要です。ユーザーが現在これらの権限を持っていない場合は、それらの権限を含むカスタムポリシーを作成して、ユーザーに適用することができます。

AWS アカウントの認証情報の構成

Tanzu Kubernetes Grid が Amazon EC2 上に仮想マシンを作成して管理できるようにするには、AWS アカウントと次が必要です。

AWS アカウントの認証情報
管理クラスタを展開するすべての AWS リージョンについての、アカウントに登録された SSH キーペア

Tanzu Kubernetes Grid クラスタを展開するリージョンについての SSH キーペアを作成するには、アカウントの認証情報を設定する必要があります。

EC2 へのアクセスに使用する、AWS アカウントの認証情報を構成するためのオプションはいくつかあります。以下のサブセクションでは、それらのオプションについて説明します。

VMware では、aws configure コマンドを使用して管理する、認証情報プロファイルを使用するオプションをお勧めします。これらのプロファイルは、ローカルの共有構成ファイル（通常は ~/.aws/config に配置）に保存されます。

認証情報構成のオプションは次のとおりです（複数使用する場合、優先順位は降順）。

ワークロードクラスタ構成ファイルの変数（ワークロードクラスタを作成する場合のみ）。以下の「クラスタ構成ファイル」を参照してください。
ローカルの静的な環境変数。以下の「ローカル環境変数」を参照してください。
（推奨）認証情報プロファイル。aws configure を実行すると更新されます。これらは、Linux または macOS の場合は ~/.aws/config、Windows の場合は C:\Users\USERNAME\.aws\config にあるファイルに保存され、credentials という名前に変更できます。以下の「認証情報プロファイル」を参照してください。
インスタンスプロファイルの認証情報。IAM ロールを各 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに関連付けることができます。そのロールの一時的な認証情報は、インスタンスで実行されているコードで使用できるようになります。認証情報は、Amazon EC2 メタデータサービスを介して配布されます。詳細については、『Amazon EC2 Linux インスタンス用ユーザーガイド』の「IAM Roles for AWS」、および『IAM ユーザーガイド』の「インスタンスプロファイルの使用」を参照してください。

ローカル環境変数

AWS 認証情報を構成するオプションの 1 つは、ブートストラップマシンでローカル環境変数を設定することです。ローカル環境変数を使用するには、AWS アカウントに次の環境変数を設定します。

export AWS_ACCESS_KEY_ID=aws_access_key。ここで、aws_access_key は AWS アクセスキーです。
export AWS_SECRET_ACCESS_KEY=aws_access_key_secret。ここで、aws_access_key_secret は AWS アクセスキーシークレットです。
export AWS_SESSION_TOKEN=aws_session_token。ここで、aws_session_token は、アカウントに付与された AWS セッショントークンです。この変数を指定する必要があるのは、一時アクセスキーを使用する必要がある場合のみです。一時アクセスキーの使用の詳細については、「Understanding and getting your AWS credentials」を参照してください。
export AWS_REGION=aws_region。ここで、aws_region は、クラスタを展開する AWS リージョンです。たとえば、us-west-2 などです。

AWS リージョンの完全なリストについては、「AWS サービスエンドポイント」を参照してください。通常の AWS リージョンに加えて、AWS GovCloud で us-gov-east リージョンと us-gov-west リージョンを指定することもできます。

Tanzu Kubernetes Grid は、次の AWS CLI 環境変数をサポートします。

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN
AWS_SHARED_CREDENTIALS_FILE
AWS_CONFIG_FILE
AWS_REGION
AWS_PROFILE

これらの詳細については、『AWS Command Line Interface ユーザーガイド』を参照してください。

認証情報プロファイル

Tanzu Kubernetes Grid を操作する場合に推奨される方法は、aws configure コマンドを使用して AWS 認証情報をローカル認証情報または構成ファイルに保存することです。AWS 構成ファイルは、静的な認証情報から外部認証情報ヘルパーを介した SSO まで、さまざまな認証メカニズムに対応できます。

AWS 認証情報ファイルは、デフォルトプロファイルと追加の名前付きプロファイルの両方を含む、複数のアカウントに対応できます。認証情報ファイルとプロファイルは、上記の認証情報の優先順位の一環として、ローカル環境変数の後に適用されます。

ブートストラップマシンで AWS アカウントの認証情報ファイルとプロファイルを設定するには、aws configure CLI コマンドを使用します。

どの AWS 認証情報ファイルとプロファイルを使用するかをカスタマイズするには、次の環境変数を設定します。

export AWS_PROFILE=profile_name。ここで、profile_name は、使用する AWS アクセスキーを含むプロファイル名です。この変数の値を指定しない場合は、プロファイル名 default が使用されます。名前付きプロファイルの使用に関する詳細については、AWS ドキュメントの「AWS CLI の名前付きプロファイル」を参照してください。
export AWS_SHARED_CREDENTIAL_FILE=path_to_credentials_file。ここで、path_to_credentials_file は、AWS アクセスキー情報を含む認証情報ファイルの場所と名前です。この環境変数を定義しない場合、デフォルトの場所とファイル名は $HOME/.aws/credentials です。
export AWS_CONFIG=path_to_config_file。ここで、path_to_config_file は、プロファイル構成を含む構成ファイルの場所と名前です。この環境変数を定義しない場合、デフォルトの場所とファイル名は $HOME/.aws/config です。明示的な認証情報ソースを指定する場合、または外部の認証情報プロセスを使用している場合は、このファイルを使用します。

注
AWS 認証情報または構成ファイルで作成した名前付きプロファイルは、AWS の Tanzu Kubernetes Grid インストーラ UI の [AWS 認証情報プロファイル (AWS Credential Profile)] ドロップダウンに選択可能なオプションとして表示されます。

AWS 認証情報の仕組みとデフォルトの AWS 認証情報プロバイダチェーンの詳細については、AWS ドキュメントの「AWS アカウントのベストプラクティス」を参照してください。

クラスタ構成ファイル

クラスタの作成に使用する構成ファイルで AWS 認証情報を指定するには、次の変数を設定します。

AWS_ACCESS_KEY_ID（base 64 でエンコード）
AWS_SECRET_ACCESS_KEY（base 64 でエンコード）
AWS_SESSION_TOKEN（オプション）

AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY は、<encoded:(base64 encoded value)> という形式で渡す必要があります。たとえば、AWS アクセスキー ID が AKIAIOSFODNN7EXAMPLE、シークレットアクセスキーが wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY、セッショントークンが AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OP の場合、これを構成ファイルで次のように設定する必要があります。

AWS_ACCESS_KEY_ID: <encoded:QUtJQUlPU0ZPRE5ON0VYQU1QTEU=>
AWS_SECRET_ACCESS_KEY: <encoded:d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQ==>
AWS_SESSION_TOKEN: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

以前のバージョンの Tanzu Kubernetes Grid では、認証情報がクラスタ構成ファイルに保存されていました。Tanzu Kubernetes Grid 1.4 以降では、AWS の認証情報はデフォルトでは構成ファイルに保存されません。

EC2 キーペアの登録

ローカル環境変数を使用するか、認証情報ファイルとプロファイルを使用して、AWS アカウントの認証情報を設定したら、AWS アカウントの EC2 キーペアを生成する必要があります。Tanzu Kubernetes Grid は、このキーペアのパブリックキー部分を AWS に渡して、各リージョン内で認証を行います。

注
AWS は RSA キーのみをサポートします。AWS に必要なキーの形式は、vSphere で必要なキーとは異なります。vSphere と AWS の両方の環境で同じキーペアを使用することはできません。

管理クラスタの展開に使用しているアカウントとリージョンの EC2 キーペアがない場合は、次の手順を実行してキーペアを作成します。

Tanzu Kubernetes Grid で使用するリージョンごとに、名前付きキーペアを作成し、その名前を含む .pem ファイルを出力します。たとえば、次のコマンドは default を使用し、ファイルを default.pem として保存します。
```
aws ec2 create-key-pair --key-name default --output json | jq .KeyMaterial -r > default.pem
```
プロファイルのデフォルトではないリージョンのキーペアを作成するか、ローカルで AWS_DEFAULT_REGION として設定するには、--region オプションを含めます。
Amazon EC2 ダッシュボードにログインし、[ネットワークとセキュリティ (Network & Security)] > [キーペア (Key Pairs)] に移動して、作成したキーペアがアカウントに登録されていることを確認します。

次の手順

本番環境では、クラスタの ID 管理を有効にすることを強くお勧めします。

管理クラスタを展開する前に実行する準備手順の詳細については、「ID 管理の構成」の「ID プロバイダの詳細の取得」を参照してください。
Tanzu Kubernetes Grid での ID 管理とアクセス制御の概念については、「ID とアクセス管理について」を参照してください。

外部インターネット接続のある環境で Tanzu Kubernetes Grid を使用している場合は、ID 管理を設定した時点で、管理クラスタを AWS に展開する準備が整います。

インストーラインターフェイスを使用して管理クラスタを展開します。これは、最初の展開に推奨されるオプションです。
構成ファイルから管理クラスタを展開します。これは、より複雑ですが、構成の柔軟性が高い方法です。
クラスタを AWS だけでなく、vSphere や Azure に展開する場合は、「vSphere への管理クラスタの展開の準備」や「Microsoft Azure への管理クラスタの展開の準備」を参照して、これらのプラットフォームに必要な設定を確認してください。