AWS 集群配置文件

本主题介绍了在将 Tanzu Kubernetes Grid (TKG) 工作负载集群部署到具有独立管理集群的 Amazon Web Services (AWS) 之前，如何使用平面配置文件或 Kubernetes 样式的对象规范配置该集群。

有关如何使用配置文件和对象规范配置工作负载集群的一般信息，请参见配置文件和对象规范。

要使用 AWS 特定的工作负载集群功能，这些功能需要在集群的配置文件或对象规范之外进行某些配置，请参见 AWS 上的集群。

概览

要在工作负载集群部署到 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 帐户凭据中所述。

在 AZ 之间分布工作线程

在 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 放置机制。

为工作节点配置 AZ 放置设置

在 AWS 上创建多 AZ prod 集群时，您可以选择性地指定 tanzu cluster create 命令在每个三 AZ 中创建的工作节点数。

为此，请执行以下操作：

  1. 在集群配置文件中包含以下变量：

    • 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 中的工作节点数。

    除了其他必需和可选设置之外，您还可以设置以下变量，如上面的工作负载集群模板中所述。

  2. 创建集群。例如：

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

从 Dev 管理集群部署 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 在 AZ 之间平均分布 prod 工作节点。

  3. 通过运行 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

    然后，您可以使用此对象规范部署集群，如从对象规范创建基于类的集群中所述。

下一步操作

继续创建工作负载集群。

check-circle-line exclamation-circle-line close-line
Scroll to top icon