本主题介绍了在将 Tanzu Kubernetes Grid (TKG) 工作负载集群部署到具有独立管理集群的 Amazon Web Services (AWS) 之前,如何使用平面配置文件或 Kubernetes 样式的对象规范配置该集群。
有关如何使用配置文件和对象规范配置工作负载集群的一般信息,请参见配置文件和对象规范。
要使用 AWS 特定的工作负载集群功能,这些功能需要在集群的配置文件或对象规范之外进行某些配置,请参见 AWS 上的集群。
重要Tanzu Kubernetes Grid v2.4.x 是支持在 AWS 上创建 TKG 工作负载集群的上一个 TKG 版本。Tanzu Kubernetes Grid v2.5 版本中将移除在 AWS 上创建 TKG 工作负载集群的功能。
从现在开始,VMware 建议您使用 Tanzu Mission Control 创建本机 AWS EKS 集群,而不是在 AWS 上创建新的 TKG 工作负载集群。有关如何使用 Tanzu Mission Control 创建本机 AWS EKS 集群的信息,请参见《Tanzu Mission Control》文档中的 管理 AWS EKS 集群的生命周期。
有关详细信息,请参见《VMware Tanzu Kubernetes Grid v2.4 发行说明》中的弃用 AWS 和 Azure 上的 TKG 管理和工作负载集群。
要在工作负载集群部署到 AWS 之前对其进行配置,请创建集群配置文件或 Kubernetes 式对象规范文件。将其中任一文件传递到 tanzu cluster create
的 -f
选项时,Tanzu CLI 使用文件中定义的配置信息连接到 AWS 帐户并创建集群将使用的资源。例如,您可以指定控制平面和工作节点虚拟机的大小,在可用区之间分发节点,并在集群之间共享 VPC。
有关将工作负载集群部署到 AWS 时必须指定的选项的完整列表,请参见配置文件变量参考。
注意要提高多租户环境中的安全性,请将工作负载集群部署到不同于部署管理集群所用的 AWS 帐户。要跨多个 AWS 帐户部署工作负载集群,请参见不同 AWS 帐户上的集群。
要创建集群配置文件,可以使用以下工作负载集群模板中的模板。创建配置文件后,继续创建工作负载集群。
以下模板包括与在 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_REGION
,如配置 AWS 帐户凭据中所述。
在 AWS 上创建多可用区 (AZ) prod
集群时,Tanzu Kubernetes Grid 会在集群配置中指定的 AZ 之间平均分配其控制平面和工作节点。这包括配置了以下任一项的工作负载集群:
CONTROL_PLANE_MACHINE_COUNT
设置WORKER_MACHINE_COUNT
设置例如,如果指定 WORKER_MACHINE_COUNT: 5
,Tanzu Kubernetes Grid 在第一个 AZ 中部署两个工作节点,在第二个 AZ 中部署两个工作节点,在第三个 AZ 中部署一个工作节点。您可以按照下面为工作节点配置 AZ 放置设置中的说明操作,为工作节点自定义此默认 AZ 放置机制。无法为控制平面节点自定义默认 AZ 放置机制。
在 AWS 上创建多 AZ prod
集群时,您可以选择性地指定 tanzu cluster create
命令在每个三 AZ 中创建的工作节点数。
为此,请执行以下操作:
在集群配置文件中包含以下变量:
WORKER_MACHINE_COUNT_0
:设置第一个 AZ AWS_NODE_AZ
中的工作节点数。WORKER_MACHINE_COUNT_1
:设置第二个 AZ AWS_NODE_AZ_1
中的工作节点数。WORKER_MACHINE_COUNT_2
:设置第三个 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 在 AZ 之间平均分布 prod
工作节点。
通过运行 tanzu cluster create
命令部署集群。例如:
tanzu cluster create my-cluster -f my-cluster-config.yaml
您可以使用 Tanzu CLI 将集群配置文件转换为基于类的工作负载集群的 Kubernetes 样式对象规范,而无需部署集群:
要为使用 tanzu cluster create
创建的每个基于类的集群生成对象规范文件,请确保在 Tanzu CLI 的配置中将 auto-apply-generated-clusterclass-based-configuration
功能设置为 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
然后,您可以使用此对象规范部署集群,如从对象规范创建基于类的集群中所述。
继续创建工作负载集群。