File di configurazione del cluster AWS

Questo argomento spiega come utilizzare un file di configurazione piatto o una specifica di oggetto di tipo Kubernetes per configurare un cluster di carichi di lavoro Tanzu Kubernetes Grid (TKG) prima di distribuirlo su Amazon Web Services (AWS) con un cluster di gestione autonomo.

Per informazioni generali su come configurare i cluster del carico di lavoro utilizzando i file di configurazione e le specifiche degli oggetti, vedere File di configurazione e specifiche degli oggetti.

Per utilizzare le funzioni del cluster di carichi di lavoro specifiche di AWS che richiedono una configurazione al di fuori del file di configurazione del cluster o delle specifiche dell'oggetto, vedere Cluster su AWS.

Panoramica

Per configurare un cluster del carico di lavoro prima di distribuirlo in AWS, creare un file di configurazione del cluster o un file di specifica di oggetto di tipo Kubernetes. Quando si passa uno di questi file all'opzione -f di tanzu cluster create, la CLI di Tanzu utilizza le informazioni di configurazione definite nel file per connettersi all'account AWS e creare le risorse che il cluster utilizzerà. Ad esempio, è possibile specificare le dimensioni per le macchine virtuali del piano di controllo e dei nodi worker, distribuire i nodi nelle zone di disponibilità e condividere VPC tra i cluster.

Per l'elenco completo delle opzioni che è necessario specificare quando si distribuiscono cluster del carico di lavoro in AWS, vedere Informazioni di riferimento sulle variabili del file di configurazione.

Nota

Per migliorare la sicurezza in un ambiente multi-tenant, distribuire i cluster dei carichi di lavoro in un account AWS diverso da quello utilizzato per distribuire il cluster di gestione. Per distribuire i cluster dei carichi di lavoro in più account AWS, vedere Cluster in account AWS diversi.

Creazione di un file di configurazione

Per creare un file di configurazione del cluster, è possibile utilizzare il modello in Modello di cluster del carico di lavoro, di seguito. Dopo aver creato il file di configurazione, passare a Creazione di cluster del carico di lavoro.

Modello di cluster del carico di lavoro

Il modello seguente include tutte le opzioni pertinenti per la distribuzione di cluster del carico di lavoro in AWS. È possibile copiare questo modello e aggiornarlo per distribuire cluster del carico di lavoro in AWS.

Le opzioni obbligatorie non sono commentate. Le impostazioni facoltative sono commentate. I valori predefiniti sono inclusi, se applicabile.

Ad eccezione delle opzioni descritte nelle sezioni sotto il modello, il modo in cui si configurano le variabili per i cluster del carico di lavoro specifici di AWS è identico per i cluster di gestione e i cluster del carico di lavoro. Per informazioni su come configurare le variabili, vedere Distribuzione di cluster di gestione da un file di configurazione e Configurazione del cluster di gestione per 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: ""

Specifica della regione

Quando si distribuisce un cluster in AWS, impostare AWS_REGION sulla regione in cui si desidera distribuire il cluster. È possibile impostare AWS_REGION nel file di configurazione del cluster, in una variabile d'ambiente o in un profilo delle credenziali, come descritto in Configurazione delle credenziali dell'account AWS.

Distribuzione dei lavoratori tra le ZD

Quando si crea un cluster multi-ZD prod in AWS, Tanzu Kubernetes Grid distribuisce in modo uniforme il piano di controllo e i nodi worker nelle zone di disponibilità (ZD) specificate nella configurazione del cluster. Sono inclusi i cluster del carico di lavoro configurati con uno dei seguenti valori:

• Numero di nodi del piano di controllo
• Impostazione di CONTROL_PLANE_MACHINE_COUNT maggiore del numero predefinito di nodi del piano di controllo
• Numero predefinito di nodi worker
• Impostazione di WORKER_MACHINE_COUNT maggiore del numero predefinito di nodi worker

Ad esempio, se si specifica WORKER_MACHINE_COUNT: 5, Tanzu Kubernetes Grid distribuisce due nodi worker nella prima ZD, due nodi worker nella seconda ZD e un nodo worker nella terza ZD. Facoltativamente, è possibile personalizzare questo meccanismo di posizionamento nelle ZD predefinito per i nodi worker seguendo le istruzioni di Configurazione delle impostazioni di posizionamento nelle ZD per i nodi worker di seguito. Non è possibile personalizzare il meccanismo di posizionamento nelle ZD predefinito per i nodi del piano di controllo.

Configurazione delle impostazioni di posizionamento nelle ZD per i nodi worker

Quando si crea un cluster multi-ZD prod in AWS, è possibile specificare facoltativamente quanti nodi worker il comando tanzu cluster create crea in ciascuna delle tre ZD.

A tale scopo:

1. Nel file di configurazione del cluster, includere le seguenti variabili:

   • WORKER_MACHINE_COUNT_0: Imposta il numero di nodi worker nella prima ZD, AWS_NODE_AZ.
   • WORKER_MACHINE_COUNT_1: Imposta il numero di nodi worker nella seconda ZD, AWS_NODE_AZ_1.
   • WORKER_MACHINE_COUNT_2: Imposta il numero di nodi worker nella terza ZD, AWS_NODE_AZ_2.

   È possibile impostare queste variabili in aggiunta alle altre impostazioni obbligatorie e facoltative, come descritto in precedenza in Modello di cluster del carico di lavoro.

2. Creare il cluster. Ad esempio:

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

Distribuzione di un cluster prod da un cluster di gestione dev

Quando si crea un cluster del carico di lavoro prod da un cluster di gestione dev in esecuzione in AWS, è necessario definire un sottoinsieme di variabili aggiuntive nel file di configurazione del cluster prima di eseguire il comando tanzu cluster create. In questo modo, Tanzu Kubernetes Grid può creare il cluster e distribuire il piano di controllo e i nodi worker del cluster tra le ZD.

Per creare un cluster del carico di lavoro prod da un cluster di gestione dev in AWS, eseguire i passaggi seguenti:

1. Impostare le variabili seguenti nel file di configurazione del cluster:

   • Impostare PLAN su prod.
   • Variabili AWS_NODE_AZ: il valore di AWS_NODE_AZ è stato impostato quando è stato distribuito il cluster di gestione dev. Per il cluster del carico di lavoro prod, aggiungere AWS_NODE_AZ_1 e AWS_NODE_AZ_2.
   • Variabili AWS_PUBLIC_SUBNET_ID (VPC esistente): il valore di AWS_PUBLIC_NODE_CIDR o AWS_PUBLIC_SUBNET_ID è stato impostato quando è stato distribuito il cluster di gestione dev. Per il cluster del carico di lavoro prod, aggiungere uno degli elementi seguenti:
     • AWS_PUBLIC_NODE_CIDR_1 e AWS_PUBLIC_NODE_CIDR_2
     • AWS_PUBLIC_SUBNET_ID_1 e AWS_PUBLIC_SUBNET_ID_2
   • Variabili AWS_PRIVATE_SUBNET_ID (VPC esistente): il valore di AWS_PRIVATE_NODE_CIDR o AWS_PRIVATE_SUBNET_ID è stato impostato quando è stato distribuito il cluster di gestione dev. Per il cluster del carico di lavoro prod, aggiungere uno degli elementi seguenti:
     • AWS_PRIVATE_NODE_CIDR_1 e AWS_PRIVATE_NODE_CIDR_2
     • AWS_PRIVATE_SUBNET_ID_1 e AWS_PRIVATE_SUBNET_ID_2

2. (Facoltativo) Personalizzare il meccanismo di posizionamento nelle ZD predefinito per i nodi worker che si intende distribuire seguendo le istruzioni di Configurazione delle impostazioni di posizionamento nelle ZD per i nodi di lavoro. Per impostazione predefinita, Tanzu Kubernetes Grid distribuisce i nodi worker prod in modo uniforme tra le ZD.

3. Distribuire il cluster eseguendo il comando tanzu cluster create. Ad esempio:

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

Creazione di un file di specifica di oggetto

È possibile utilizzare la CLI di Tanzu per convertire un file di configurazione cluster nel file della specifica di un oggetto in stile Kubernetes per un cluster del carico di lavoro basato sulla classe senza distribuire il cluster:

• Per generare un file di specifiche degli oggetti per ogni cluster basato su classi creato con tanzu cluster create, assicurarsi che la funzionalità auto-apply-generated-clusterclass-based-configuration sia impostata su false nella configurazione della CLI di Tanzu. Per impostazione predefinita, questa funzionalità è impostata su false. Quando auto-apply-generated-clusterclass-based-configuration è impostato su false e si esegue tanzu cluster create con il flag --file, il comando converte il file di configurazione del cluster in un file di specifiche dell'oggetto ed esce senza creare il cluster. Dopo aver rivisto la configurazione, si esegue nuovamente tanzu cluster create con il file di specifiche dell'oggetto generato dalla CLI di Tanzu. Se è stata aggiornata la configurazione predefinita, per impostarla nuovamente su false, eseguire:

  tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration false
  

• Per generare un file di specifiche degli oggetti per un singolo cluster, passare l'opzione --dry-run a tanzu cluster create e salvare l'output in un file. Utilizzare le stesse opzioni e lo stesso --file di configurazione che si utilizzerebbero se si stesse creando il cluster, ad esempio:

  tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
  

  È quindi possibile utilizzare questa specifica di oggetto per distribuire un cluster come descritto in Creazione di un cluster basato sulla classe dalla specifica di un oggetto.

Passaggi successivi

Passare a Creazione di cluster del carico di lavoro.