This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

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