本主題說明在將 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
之後,您就可以使用此物件規格來部署叢集,如從物件規格來建立以類別為基礎的叢集中所述。
繼續建立工作負載叢集。