Configurazione del cluster di gestione per AWS

Per creare un file di configurazione del cluster, è possibile copiare in Amazon Web Services (AWS) un file di configurazione esistente per una distribuzione precedente e aggiornarlo. In alternativa, è possibile creare un file da zero utilizzando un modello vuoto.

Importante
Tanzu Kubernetes Grid v2.4.x è l'ultima versione di TKG che supporta la creazione di cluster di gestione TKG autonomi in AWS. La possibilità di creare cluster di gestione TKG autonomi in AWS verrà rimossa nella versione Tanzu Kubernetes Grid v2.5.

A partire da ora, VMware consiglia di utilizzare Tanzu Mission Control per creare cluster AWS EKS nativi anziché creare nuovi cluster di gestione TKG in AWS. Per informazioni su come creare cluster AWS EKS nativi con Tanzu Mission Control, vedere Gestione del ciclo di vita dei cluster AWS EKS nella documentazione di Tanzu Mission Control.

Per ulteriori informazioni, vedere Deprecazione dei cluster di gestione e del carico di lavoro TKG in AWS e Azure nelle Note di rilascio di VMware Tanzu Kubernetes Grid v2.4.

Modello di configurazione del cluster di gestione

Il modello seguente include tutte le opzioni pertinenti per la distribuzione di cluster di gestione in AWS. È possibile copiare questo modello e utilizzarlo per distribuire cluster di gestione in AWS.

Per informazioni su come aggiornare le impostazioni comuni a tutte le piattaforme di destinazione, vedere Creazione di un file di configurazione del cluster di gestione
Per informazioni su tutte le variabili del file di configurazione, vedere Informazioni di riferimento sulle variabili del file di configurazione della CLI di Tanzu.
Per esempi di configurazione delle impostazioni di vSphere, vedere le sezioni sotto il modello.

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

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME:
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
# CLUSTER_API_SERVER_PORT:
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# CAPBK_BOOTSTRAP_TOKEN_TTL: 30m

#! ---------------------------------------------------------------------
#! 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
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""

#! ---------------------------------------------------------------------
#! AWS configuration
#! ---------------------------------------------------------------------

AWS_REGION:
AWS_NODE_AZ: ""
AWS_ACCESS_KEY_ID:
AWS_SECRET_ACCESS_KEY:
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
# 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_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_BASTION: sg-12345
# AWS_SECURITY_GROUP_CONTROLPLANE: sg-12346
# AWS_SECURITY_GROUP_APISERVER_LB: sg-12347
# AWS_SECURITY_GROUP_NODE: sg-12348
# AWS_SECURITY_GROUP_LB: sg-12349
# DISABLE_TMC_CLOUD_PERMISSIONS: false # Deactivates IAM permissions required for TMC enablement

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""

#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m

#! ---------------------------------------------------------------------
#! Identity management configuration
#! ---------------------------------------------------------------------

IDENTITY_MANAGEMENT_TYPE: "none"

#! Settings for IDENTITY_MANAGEMENT_TYPE: "oidc"
# CERT_DURATION: 2160h
# CERT_RENEW_BEFORE: 360h
# OIDC_IDENTITY_PROVIDER_CLIENT_ID:
# OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
# OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
# OIDC_IDENTITY_PROVIDER_ISSUER_URL:
# OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
# OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

#! The following two variables are used to configure Pinniped JWTAuthenticator for workload clusters
# SUPERVISOR_ISSUER_URL:
# SUPERVISOR_ISSUER_CA_BUNDLE_DATA:

#! Settings for IDENTITY_MANAGEMENT_TYPE: "ldap"
# LDAP_BIND_DN:
# LDAP_BIND_PASSWORD:
# LDAP_HOST:
# LDAP_USER_SEARCH_BASE_DN:
# LDAP_USER_SEARCH_FILTER:
# LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
# LDAP_USER_SEARCH_NAME_ATTRIBUTE:
# LDAP_GROUP_SEARCH_BASE_DN:
# LDAP_GROUP_SEARCH_FILTER:
# LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
# LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
# LDAP_ROOT_CA_DATA_B64:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

# ANTREA_NO_SNAT: true
# ANTREA_NODEPORTLOCAL: true
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_PROXY: true
# ANTREA_PROXY_ALL: true
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_PROXY_NODEPORT_ADDRS:
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_POLICY: true
# ANTREA_TRACEFLOW: true
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_EGRESS: true
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_FLOWEXPORTER: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_IPAM: false
# ANTREA_KUBE_APISERVER_OVERRIDE: ""
# ANTREA_MULTICAST: false
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_NETWORKPOLICY_STATS: true
# ANTREA_SERVICE_EXTERNALIP: true
# ANTREA_TRANSPORT_INTERFACE: ""
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

Impostazioni di connessione di AWS

Per fornire informazioni sull'account AWS, nonché sulla regione e la zona di disponibilità in cui si desidera distribuire il cluster, eseguire una delle operazioni seguenti:

(Opzione consigliata) Configurare un profilo di credenziali AWS con la CLI di AWS e impostare una variabile di ambiente AWS_PROFILE sul nome del profilo nella macchina di bootstrap.

Includere le credenziali dell'account e altre informazioni nel file di configurazione del cluster. Ad esempio:

AWS_REGION: eu-west-1
AWS_NODE_AZ: "eu-west-1a"
# Only use AWS_PROFILE OR combination of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, but not both.
AWS_PROFILE: tkg
# AWS_ACCESS_KEY_ID:  <encoded:QUtJQVQ[...]SU82TTM=>
# AWS_SECRET_ACCESS_KEY: <encoded:eGN4RHJmLzZ[...]SR08yY2ticQ==>
AWS_SSH_KEY_NAME: default
BASTION_HOST_ENABLED: true

Utilizzare solo AWS_PROFILE o una combinazione di AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY, ma non entrambi.
I valori di AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY devono essere codificati in base64.

Utilizzo di un bilanciamento del carico interno per il server dell'API

Per impostazione predefinita, Tanzu Kubernetes Grid on AWS crea un bilanciamento del carico pubblico per il server dell'API di Kubernetes del cluster di gestione.

Per gli ambienti con limitazioni Internet, ad esempio con air gap o proxy, è possibile evitare di creare un bilanciamento del carico pubblico impostando AWS_LOAD_BALANCER_SCHEME_INTERNAL su true nel file di configurazione del cluster:

AWS_LOAD_BALANCER_SCHEME_INTERNAL: true

Questa impostazione personalizza il bilanciamento del carico del cluster di gestione in modo che utilizzi uno schema interno. Ciò significa che il server dell'API di Kubernetes non sarà accessibile e non verrà instradato su Internet.

Configurazione delle dimensioni dei nodi

La CLI di Tanzu crea i singoli nodi dei cluster del carico di lavoro in base alle impostazioni specificate nel file di configurazione. In AWS, è possibile configurare tutte le macchine virtuali dei nodi in modo che abbiano le stesse configurazioni predefinite o impostare configurazioni predefinite diverse per i nodi del piano di controllo e i nodi worker. Utilizzando queste impostazioni, è possibile creare cluster di Tanzu Kubernetes che includano nodi con configurazioni diverse per i nodi del cluster di gestione. È inoltre possibile creare cluster in cui i nodi del piano di controllo e i nodi worker abbiano configurazioni diverse.

Quando si crea il cluster di gestione, i tipi di istanze per le macchine dei nodi vengono impostati nelle opzioni CONTROL_PLANE_MACHINE_TYPE e NODE_MACHINE_TYPE. Per impostazione predefinita, queste impostazioni vengono utilizzate anche per i cluster del carico di lavoro. La configurazione minima è 2 CPU e 8 GB di memoria. L'elenco dei tipi di istanze compatibili varia in base alle diverse regioni.

CONTROL_PLANE_MACHINE_TYPE: "t3.large"
NODE_MACHINE_TYPE: "m5.large"

È possibile sostituire queste impostazioni utilizzando le opzioni SIZE, CONTROLPLANE_SIZE e WORKER_SIZE. Per creare un cluster Tanzu Kubernetes in cui tutte le macchine virtuali dei nodi del piano di controllo e dei nodi worker abbiano le stesse dimensioni, specificare la variabile SIZE. Se si imposta la variabile SIZE, tutti i nodi verranno creati con la configurazione impostata. Per informazioni sulle configurazioni delle diverse dimensioni delle istanze dei nodi per Amazon EC2, vedere Tipi di istanze di Amazon EC2.

SIZE: "t3.large"

Per creare un cluster del carico di lavoro in cui le macchine virtuali dei nodi del piano di controllo e dei nodi worker abbiano le stesse dimensioni, specificare le opzioni CONTROLPLANE_SIZE e WORKER_SIZE.

CONTROLPLANE_SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

È possibile combinare le opzioni CONTROLPLANE_SIZE e WORKER_SIZE con l'opzione SIZE. Ad esempio, se si specifica SIZE: "t3.large" con WORKER_SIZE: "m5.xlarge", i nodi del piano di controllo verranno impostati su t3.large e i nodi worker verranno impostati su m5.xlarge.

SIZE: "t3.large"
WORKER_SIZE: "m5.xlarge"

Configurazione di VPC

Rimuovere i commenti e aggiornare le righe seguenti per specificare il VPC e l'altra infrastruttura AWS che ospiterà il cluster di gestione autonomo e verrà utilizzata da tale cluster

AWS_REGION:
AWS_NODE_AZ:
AWS_PRIVATE_SUBNET_ID:
AWS_PUBLIC_SUBNET_ID:
AWS_SSH_KEY_NAME:
AWS_VPC_ID:
BASTION_HOST_ENABLED:
CONTROL_PLANE_MACHINE_TYPE:
NODE_MACHINE_TYPE:
SERVICE_CIDR:
CLUSTER_CIDR:

Se si distribuisce un cluster di gestione di produzione, rimuovere i commenti e compilare anche quanto segue per i due nodi del piano di controllo aggiuntivi:

AWS_NODE_AZ_1:
AWS_NODE_AZ_2:
AWS_PRIVATE_SUBNET_ID_1:
AWS_PRIVATE_SUBNET_ID_2:
AWS_PUBLIC_SUBNET_ID_1:
AWS_PUBLIC_SUBNET_ID_2:

Ad esempio, la configurazione di un cluster di gestione della produzione in un VPC esistente potrebbe avere l'aspetto seguente:

AWS_REGION: us-west-2
AWS_NODE_AZ: us-west-2a
AWS_NODE_AZ_1: us-west-2b
AWS_NODE_AZ_2: us-west-2c
AWS_PRIVATE_SUBNET_ID: subnet-ID
AWS_PRIVATE_SUBNET_ID_1: subnet-ID
AWS_PRIVATE_SUBNET_ID_2: subnet-ID
AWS_PUBLIC_SUBNET_ID: subnet-ID
AWS_PUBLIC_SUBNET_ID_1: subnet-ID
AWS_PUBLIC_SUBNET_ID_2: subnet-ID
AWS_SSH_KEY_NAME: tkg
AWS_VPC_ID: vpc-ID
BASTION_HOST_ENABLED: "true"
CONTROL_PLANE_MACHINE_TYPE: m5.large
NODE_MACHINE_TYPE: m5.large
SERVICE_CIDR: 100.64.0.0/13
CLUSTER_CIDR: 100.96.0.0/11

Per impostazione predefinita, Tanzu Kubernetes Grid crea nuovi gruppi di sicurezza per la connessione del piano di controllo, dei nodi worker e dei bilanciamenti del carico. Se sono necessarie regole personalizzate, è possibile eseguire il provisioning preliminare dei gruppi di sicurezza, aggiungere i set di regole e configurare i cluster in modo che utilizzino i gruppi di sicurezza personalizzati come descritto di seguito.

Configurazione di gruppi di sicurezza personalizzati

Per impostazione predefinita, Tanzu Kubernetes Grid crea cinque gruppi di sicurezza in un VPC.

Per impedire a Tanzu Kubernetes Grid di creare nuovi gruppi di sicurezza e utilizzare invece quelli esistenti con provisioning preliminare con set di regole personalizzati, è necessario:

Creare gruppi di sicurezza con set di regole personalizzati che corrispondano il più possibile ai set di regole predefiniti.
Specificare i gruppi di sicurezza personalizzati nel file di configurazione del cluster impostando le variabili AWS_SECURITY_GROUP_* sui nomi dei gruppi di sicurezza. Ad esempio:
```
AWS_SECURITY_GROUP_BASTION: sg-12345
```

Di seguito sono elencati i cinque gruppi di sicurezza, le loro regole predefinite e le variabili di configurazione del cluster corrispondenti:

Gruppo: CLUSTER-NAME-bastion

Impostarlo con la variabile di configurazione del cluster AWS_SECURITY_GROUP_BASTION.

Regole:

Descrizione	Protocollo	Dalla porta	Alla porta	Consente l'ingresso da	Obbligatorio
SSH	TCP	22	22	0.0.0.0/0	No

Gruppo: CLUSTER-NAME-node

Impostarlo con la variabile di configurazione del cluster AWS_SECURITY_GROUP_NODE.

Regole:

Descrizione	Protocollo	Dalla porta	Alla porta	Consente l'ingresso da	Obbligatorio
SSH	TCP	22	22	Gruppo di sicurezza <nome-cluster>-bastion	No
Servizi della porta del nodo	TCP	30000	32767	0.0.0.0/0	No (vedere la nota seguente)
API kubelet	TCP	10250	10250	Gruppi di sicurezza <nome-cluster>-controlplane e <nome-cluster>-node	Sì
CNI Antrea	TCP	10349-10351	10349-10351	Gruppo di sicurezza <nome-cluster>-nodo	Sì
GENEVE	UDP	6081	6081	Gruppo di sicurezza <nome-cluster>-nodo	Sì

Nota
il valore 0.0.0.0/0 è in entrata solo dall'interno del VPC, dai VPC in peer e da tutte le reti connesse tramite VPN o DirectConnect. Il valore 0.0.0.0/0 non deve essere interpretato come accessibile da Internet. È possibile modificare sia l'intervallo di porte sia la regola di ingresso per i servizi delle porte del nodo purché si disponga dei diritti di amministratori e non vengano utilizzati per il funzionamento del cluster.

Gruppo: CLUSTER-NAME-controlplane

Impostarlo con la variabile di configurazione del cluster AWS_SECURITY_GROUP_CONTROLPLANE.

Regole:

Descrizione	Protocollo	Dalla porta	Alla porta	Consente l'ingresso da	Obbligatorio
SSH	TCP	22	22	Gruppo di sicurezza <nome-cluster>-bastion	No
API di Kubernetes	TCP	6443*	6443*	Gruppi di sicurezza <nome-cluster>-apiserver-lb, <nome-cluster>-apiserver-controlplane e <nome-cluster>-apiserver-node	Sì
etcd	TCP	2379	2379	Gruppo di sicurezza <nome-cluster>-controlplane	Sì
Peer etcd	TCP	2380	2380	Gruppo di sicurezza <nome-cluster>-controlplane	Sì
addons-manager	TCP	9865	9865	Gruppi di sicurezza <nome-cluster>-controlplane	Sì
kapp-controller	TCP	10100	10100	Gruppi di sicurezza <nome-cluster>-controlplane	Sì

* Se si imposta CLUSTER_API_SERVER_PORT, sostituire 6443 con il numero di porta impostato nella variabile.

Gruppo: CLUSTER-NAME-apiserver-lb

Impostarlo con la variabile di configurazione del cluster AWS_SECURITY_GROUP_APISERVER_LB.

Regole:

Descrizione	Protocollo	Dalla porta	Alla porta	Consente l'ingresso da	Obbligatorio
API di Kubernetes	TCP	6443*	6443*	0.0.0.0/0	No (vedere la nota seguente)

* Se si imposta CLUSTER_API_SERVER_PORT, sostituire 6443 con il numero di porta impostato nella variabile.

Nota
per impostazione predefinita, la regola 0.0.0.0/0 è accessibile da Internet quando non è specificata per il provisioning del bilanciamento del carico internamente. Se il bilanciamento del carico è interno, deve essere accessibile dal cluster di gestione (per i cluster del carico di lavoro) o dalla macchina di bootstrap (per il cluster di gestione). Questa regola può essere bloccata, ma in questo caso è NECESSARIO aggiungere la regola seguente:

Descrizione	Protocollo	Dalla porta	Alla porta	Consente l'ingresso da	Obbligatorio
API di Kubernetes nel cluster	TCP	6443*	6443*	Gruppi di sicurezza <nome-cluster>-controlplane e <nome-cluster>-node	Sì

* Se si imposta CLUSTER_API_SERVER_PORT, sostituire 6443 con il numero di porta impostato nella variabile.

Gruppo: CLUSTER-NAME-lb

Impostarlo con la variabile di configurazione del cluster AWS_SECURITY_GROUP_LB.

Questo gruppo di sicurezza viene utilizzato per i bilanciamenti del carico di lavoro. A questo gruppo di sicurezza non viene aggiunta alcuna regola ed è previsto che gli amministratori di AWS personalizzino il set di regole in base al carico di lavoro dell'applicazione.

Passaggi successivi

Dopo aver completato l'aggiornamento del file di configurazione del cluster di gestione, creare il cluster di gestione seguendo le istruzioni disponibili in Distribuzione di cluster di gestione da un file di configurazione.