AWS クラスタの構成ファイル

このトピックでは、スタンドアローン管理クラスタを使用して Amazon Web Services (AWS) にデプロイする前に、フラット構成ファイルまたは Kubernetes スタイルのオブジェクト仕様を使用して、Tanzu Kubernetes Grid (TKG) のワークロード クラスタを使用する方法について説明します。

構成ファイルとオブジェクト仕様を使用してワークロード クラスタを構成する方法の一般的な情報については、「構成ファイルとオブジェクト仕様」を参照してください。

クラスタの構成ファイルまたはオブジェクト仕様に含まれない構成を必要とする AWS 固有のワークロード クラスタ機能を使用するには、「AWS 上のクラスタ」を参照してください。

概要

ワークロード クラスタを 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 を設定できます。

AZ 全体にわたるワーカーの分散

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 配置メカニズムはカスタマイズできません。

ワーカー ノードの AZ 配置設定の構成

AWS で複数の AZ prod クラスタを作成するときに、必要に応じて、3 つの AZ のそれぞれに対して tanzu cluster create コマンドが作成するワーカー ノードの数を指定することができます。

これを行うには、次の手順を実行します。

1. クラスタ構成ファイルに次の変数を含めます。

   • 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) 内のワーカー ノードの数を設定します。

   上記の「ワークロード クラスタ テンプレート」の説明に従って、他の必須およびオプションの設定に加えてこれらの変数を設定します。

2. クラスタを作成します。例：

   tanzu cluster create my-prod-cluster -f my-prod-cluster-config.yaml
   

開発管理クラスタからの Prod クラスタの展開

AWS で実行されている dev 管理クラスタから prod ワークロード クラスタを作成する場合は、tanzu cluster create コマンドを実行する前に、クラスタ構成ファイルに追加の変数のサブセットを定義する必要があります。これにより、Tanzu Kubernetes Grid がクラスタを作成し、その制御プレーン ノードとワーカー ノードを AZ 間で分散できます。

AWS 上の dev 管理クラスタから prod ワークロード クラスタを作成するには、次の手順を実行します。

1. クラスタ構成ファイルに次の変数を設定します。

   • 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

2. （オプション）「ワーカー ノードの AZ 配置設定の構成」の手順に従って、展開するワーカー ノードのデフォルトの AZ 配置メカニズムをカスタマイズします。デフォルトでは、Tanzu Kubernetes Grid は prod ワーカー ノードを AZ 間で均等に分散します。

3. 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
  

  このオブジェクト仕様を使用して、「オブジェクト仕様からのクラスベースのクラスタの作成」の説明に従ってクラスタを展開できます。

次の手順

「ワークロード クラスタの作成」に進みます。