このトピックでは、スタンドアローン管理クラスタを使用して Amazon Web Services (AWS) にデプロイする前に、フラット構成ファイルまたは Kubernetes スタイルのオブジェクト仕様を使用して、Tanzu Kubernetes Grid (TKG) のワークロード クラスタを使用する方法について説明します。
構成ファイルとオブジェクト仕様を使用してワークロード クラスタを構成する方法の一般的な情報については、「構成ファイルとオブジェクト仕様」を参照してください。
クラスタの構成ファイルまたはオブジェクト仕様に含まれない構成を必要とする AWS 固有のワークロード クラスタ機能を使用するには、「AWS 上のクラスタ」を参照してください。
重要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 管理クラスタとワークロード クラスタの廃止」を参照してください。
ワークロード クラスタを AWS に展開する前に構成するには、クラスタ構成ファイルまたは Kubernetes スタイルのオブジェクト仕様ファイルを作成します。これらのファイルのいずれかを tanzu cluster create
の -f
オプションに渡すと、Tanzu CLI はファイルで定義されている構成情報を使用して AWS アカウントに接続し、クラスタが使用するリソースを作成します。たとえば、制御プレーンとワーカー ノード仮想マシンのサイズを指定したり、アベイラビリティ ゾーン間でノードを分散したり、クラスタ間で VPC を共有したりできます。
ワークロード クラスタを AWS に展開するときに指定する必要があるオプションの完全なリストについては、「構成ファイル変数リファレンス」を参照してください。
注マルチテナント環境のセキュリティを向上させるには、管理クラスタの展開に使用されたものとは異なる AWS アカウントにワークロード クラスタを展開します。複数の AWS アカウントにワークロード クラスタを展開するには、「Clusters on Different AWS Accounts」を参照してください。
クラスタ構成ファイルを作成するには、以下の「ワークロード クラスタ テンプレート」のテンプレートを使用できます。構成ファイルを作成したら、「ワークロード クラスタの作成」に進みます。
次に示すテンプレートには、AWS へのワークロード クラスタの展開に関連するすべてのオプションが含まれています。このテンプレートをコピーして更新し、ワークロード クラスタを AWS に展開できます。
必須オプションはコメント解除されています。オプションの設定はコメントアウトされています。必要に応じて、デフォルト値が含まれています。
テンプレートの下のセクションで説明されているオプションを除き、AWS に固有のワークロード クラスタの変数を構成する方法は、管理クラスタとワークロード クラスタの両方で同じです。変数の構成方法の詳細については、「構成ファイルからの管理クラスタの展開」と「AWS の管理クラスタ構成」を参照してください。
#! ---------------------------------------------------------------------
#! Cluster creation basic configuration
#! ---------------------------------------------------------------------
#! CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT:
CNI: antrea
#! ---------------------------------------------------------------------
#! Node configuration
#! AWS-only MACHINE_TYPE settings override cloud-agnostic SIZE settings.
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
CONTROL_PLANE_MACHINE_TYPE: t3.large
NODE_MACHINE_TYPE: m5.large
# NODE_MACHINE_TYPE_1: ""
# NODE_MACHINE_TYPE_2: ""
# CONTROL_PLANE_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:
#! ---------------------------------------------------------------------
#! AWS Configuration
#! ---------------------------------------------------------------------
AWS_REGION:
# AWS_LOAD_BALANCER_SCHEME_INTERNAL: false
AWS_NODE_AZ: ""
# AWS_NODE_AZ_1: ""
# AWS_NODE_AZ_2: ""
# AWS_VPC_ID: ""
# AWS_PRIVATE_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID_1: ""
# AWS_PRIVATE_SUBNET_ID_1: ""
# AWS_PUBLIC_SUBNET_ID_2: ""
# AWS_PRIVATE_SUBNET_ID_2: ""
# AWS_VPC_CIDR: 10.0.0.0/16
# AWS_PRIVATE_NODE_CIDR: 10.0.0.0/24
# AWS_PUBLIC_NODE_CIDR: 10.0.1.0/24
# AWS_PRIVATE_NODE_CIDR_1: 10.0.2.0/24
# AWS_PUBLIC_NODE_CIDR_1: 10.0.3.0/24
# AWS_PRIVATE_NODE_CIDR_2: 10.0.4.0/24
# AWS_PUBLIC_NODE_CIDR_2: 10.0.5.0/24
# AWS_SECURITY_GROUP_APISERVER_LB: ""
# AWS_SECURITY_GROUP_BASTION: ""
# AWS_SECURITY_GROUP_CONTROLPLANE: ""
# AWS_SECURITY_GROUP_LB: ""
# AWS_SECURITY_GROUP_NODE: ""
# AWS_IDENTITY_REF_KIND: ""
# AWS_IDENTITY_REF_NAME: ""
# AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB: 80
# AWS_NODE_OS_DISK_SIZE_GIB: 80
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------
# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: false
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""
# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""
# TKG_PROXY_CA_CERT: ""
ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------
ENABLE_AUTOSCALER: false
# AUTOSCALER_MAX_NODES_TOTAL: "0"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m"
# AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m"
# AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m"
# AUTOSCALER_MIN_SIZE_0:
# AUTOSCALER_MAX_SIZE_0:
# AUTOSCALER_MIN_SIZE_1:
# AUTOSCALER_MAX_SIZE_1:
# AUTOSCALER_MIN_SIZE_2:
# AUTOSCALER_MAX_SIZE_2:
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
# ANTREA_NO_SNAT: false
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_PROXY_ALL: false
# ANTREA_PROXY_NODEPORT_ADDRS: ""
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "30s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_KUBE_APISERVER_OVERRIDE:
# ANTREA_TRANSPORT_INTERFACE:
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_MULTICAST_IGMPQUERY_INTERVAL: "125s"
# ANTREA_TUNNEL_TYPE: geneve
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_ENABLE_BRIDGING_MODE: false
# ANTREA_DISABLE_TXCHECKSUM_OFFLOAD: false
# ANTREA_DNS_SERVER_OVERRIDE: ""
# ANTREA_MULTICLUSTER_ENABLE: false
# ANTREA_MULTICLUSTER_NAMESPACE: ""
クラスタを AWS に展開する場合は、クラスタを展開するリージョンに AWS_REGION
を設定します。「AWS アカウントの認証情報の構成」の説明に従って、クラスタ構成ファイル、ローカル環境変数、または認証情報プロファイルで AWS_REGION
を設定できます。
AWS で複数の AZ prod
クラスタを作成すると、Tanzu Kubernetes Grid は、クラスタ構成で指定したアベイラビリティ ゾーン (AZ) 全体にわたり制御プレーンとワーカー ノードを均等に分散します。これには、次のいずれかを使用して構成されたワークロード クラスタが含まれます。
CONTROL_PLANE_MACHINE_COUNT
設定WORKER_MACHINE_COUNT
設定たとえば、WORKER_MACHINE_COUNT: 5
を指定した場合、Tanzu Kubernetes Grid は最初の AZ に 2 つのワーカー ノード、2 番目の AZ に 2 つのワーカー ノード、3 番目の AZ に 1 つのワーカー ノードを展開します。次の「ワーカー ノードの AZ 配置設定の構成」の手順に従って、ワーカー ノードのデフォルトの AZ 配置メカニズムを必要に応じてカスタマイズすることもできます。制御プレーン ノードのデフォルトの AZ 配置メカニズムはカスタマイズできません。
AWS で複数の AZ prod
クラスタを作成するときに、必要に応じて、3 つの AZ のそれぞれに対して tanzu cluster create
コマンドが作成するワーカー ノードの数を指定することができます。
これを行うには、次の手順を実行します。
クラスタ構成ファイルに次の変数を含めます。
WORKER_MACHINE_COUNT_0
:最初の AZ (AWS_NODE_AZ
) 内のワーカー ノードの数を設定します。WORKER_MACHINE_COUNT_1
:2 番目の AZ (AWS_NODE_AZ_1
) 内のワーカー ノードの数を設定します。WORKER_MACHINE_COUNT_2
:3 番目の AZ (AWS_NODE_AZ_2
) 内のワーカー ノードの数を設定します。上記の「ワークロード クラスタ テンプレート」の説明に従って、他の必須およびオプションの設定に加えてこれらの変数を設定します。
クラスタを作成します。例:
tanzu cluster create my-prod-cluster -f my-prod-cluster-config.yaml
AWS で実行されている dev
管理クラスタから prod
ワークロード クラスタを作成する場合は、tanzu cluster create
コマンドを実行する前に、クラスタ構成ファイルに追加の変数のサブセットを定義する必要があります。これにより、Tanzu Kubernetes Grid がクラスタを作成し、その制御プレーン ノードとワーカー ノードを AZ 間で分散できます。
AWS 上の dev
管理クラスタから prod
ワークロード クラスタを作成するには、次の手順を実行します。
クラスタ構成ファイルに次の変数を設定します。
PLAN
を prod
に設定します。AWS_NODE_AZ
変数:AWS_NODE_AZ
は、dev
管理クラスタを展開したときに設定されています。prod
ワークロード クラスタの場合は、AWS_NODE_AZ_1
と AWS_NODE_AZ_2
を追加します。AWS_PUBLIC_SUBNET_ID
(既存の VPC)変数:AWS_PUBLIC_NODE_CIDR
または AWS_PUBLIC_SUBNET_ID
は、dev
管理クラスタを展開したときに設定されています。prod
ワークロード クラスタの場合は、次のいずれかを追加します。
AWS_PUBLIC_NODE_CIDR_1
と AWS_PUBLIC_NODE_CIDR_2
AWS_PUBLIC_SUBNET_ID_1
と AWS_PUBLIC_SUBNET_ID_2
AWS_PRIVATE_SUBNET_ID
(既存の VPC)変数:AWS_PRIVATE_NODE_CIDR
または AWS_PRIVATE_SUBNET_ID
は、dev
管理クラスタを展開したときに設定されています。prod
ワークロード クラスタの場合は、次のいずれかを追加します。
AWS_PRIVATE_NODE_CIDR_1
と AWS_PRIVATE_NODE_CIDR_2
AWS_PRIVATE_SUBNET_ID_1
と AWS_PRIVATE_SUBNET_ID_2
(オプション)「ワーカー ノードの AZ 配置設定の構成」の手順に従って、展開するワーカー ノードのデフォルトの AZ 配置メカニズムをカスタマイズします。デフォルトでは、Tanzu Kubernetes Grid は prod
ワーカー ノードを AZ 間で均等に分散します。
tanzu cluster create
コマンドを実行して、クラスタを展開します。例:
tanzu cluster create my-cluster -f my-cluster-config.yaml
Tanzu CLI を使用すると、クラスタを展開せずに、クラスタ構成ファイルをクラスベースのワークロード クラスタの Kubernetes スタイルのオブジェクト仕様ファイルに変換できます。
tanzu cluster create
を使用して作成するクラスベースのクラスタごとにオブジェクト仕様ファイルを作成するには、auto-apply-generated-clusterclass-based-configuration
機能が Tanzu CLI の構成で false
に設定されていることを確認します。この機能は、デフォルトで false
に設定されています。auto-apply-generated-clusterclass-based-configuration
が false
に設定されている場合に、--file
フラグを指定して tanzu cluster create
を実行すると、クラスタ構成ファイルがオブジェクト仕様ファイルに変換され、クラスタを作成することなくコマンドが終了します。構成を確認したら、Tanzu CLI によって生成されたオブジェクト仕様ファイルを使用して tanzu cluster create
を再実行します。デフォルトの構成を更新した場合、false
に設定を戻すには、次のコマンドを実行します。
tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration false
単一クラスタのオブジェクト仕様ファイルを生成するには、--dry-run
オプションを tanzu cluster create
に渡して、出力をファイルに保存します。クラスタを作成する場合に使用するのと同じオプションと構成 --file
を使用します。例:
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
このオブジェクト仕様を使用して、「オブジェクト仕様からのクラスベースのクラスタの作成」の説明に従ってクラスタを展開できます。
「ワークロード クラスタの作成」に進みます。