This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

Configurazione del cluster di gestione per Microsoft Azure

Per creare un file di configurazione del cluster, è possibile copiare in Azure 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 Azure. La possibilità di creare cluster di gestione TKG autonomi in Azure verrà rimossa nella versione Tanzu Kubernetes Grid v2.5.

A partire da ora, VMware consiglia di utilizzare Tanzu Mission Control per creare cluster Azure AKS nativi anziché creare nuovi cluster di gestione TKG in Azure. Per informazioni su come creare cluster Azure AKS nativi con Tanzu Mission Control, vedere Gestione del ciclo di vita dei cluster Azure AKS 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 Azure. È possibile copiare questo modello e utilizzarlo per distribuire cluster di gestione in Azure.

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: azure
# 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
#! ---------------------------------------------------------------------

# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# AZURE_CONTROL_PLANE_MACHINE_TYPE: "Standard_D2s_v3"
# AZURE_NODE_MACHINE_TYPE: "Standard_D2s_v3"
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
# AZURE_CONTROL_PLANE_DATA_DISK_SIZE_GIB : ""
# AZURE_CONTROL_PLANE_OS_DISK_SIZE_GIB : ""
# AZURE_CONTROL_PLANE_MACHINE_TYPE : ""
# AZURE_CONTROL_PLANE_OS_DISK_STORAGE_ACCOUNT_TYPE : ""
# AZURE_ENABLE_NODE_DATA_DISK : ""
# AZURE_NODE_DATA_DISK_SIZE_GIB : ""
# AZURE_NODE_OS_DISK_SIZE_GIB : ""
# AZURE_NODE_MACHINE_TYPE : ""
# AZURE_NODE_OS_DISK_STORAGE_ACCOUNT_TYPE : ""

#! ---------------------------------------------------------------------
#! Azure configuration
#! ---------------------------------------------------------------------

AZURE_ENVIRONMENT: "AzurePublicCloud"
AZURE_TENANT_ID:
AZURE_SUBSCRIPTION_ID:
AZURE_CLIENT_ID:
AZURE_CLIENT_SECRET:
AZURE_LOCATION:
AZURE_SSH_PUBLIC_KEY_B64:
# AZURE_RESOURCE_GROUP: ""
# AZURE_VNET_RESOURCE_GROUP: ""
# AZURE_VNET_NAME: ""
# AZURE_VNET_CIDR: ""
# AZURE_CONTROL_PLANE_SUBNET_NAME: ""
# AZURE_CONTROL_PLANE_SUBNET_CIDR: ""
# AZURE_NODE_SUBNET_NAME: ""
# AZURE_NODE_SUBNET_CIDR: ""
# AZURE_CUSTOM_TAGS : ""
# AZURE_ENABLE_PRIVATE_CLUSTER : ""
# AZURE_FRONTEND_PRIVATE_IP : ""
# AZURE_ENABLE_ACCELERATED_NETWORKING : ""

#! ---------------------------------------------------------------------
#! 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 Azure

Specificare le informazioni relative all'account Azure e alla regione in cui si desidera distribuire il cluster.

Ad esempio:

AZURE_ENVIRONMENT: "AzurePublicCloud"
AZURE_TENANT_ID: b39138ca-[...]-d9dd62f0
AZURE_SUBSCRIPTION_ID: 3b511ccd-[...]-08a6d1a75d78
AZURE_CLIENT_ID: <encoded:M2ZkYTU4NGM[...]tZmViZjMxOGEyNmU1>
AZURE_CLIENT_SECRET: <encoded:bjVxLUpIUE[...]EN+d0RCd28wfg==>
AZURE_LOCATION: westeurope
AZURE_SSH_PUBLIC_KEY_B64: c3NoLXJzYSBBQUFBQjN[...]XJlLmNvbQ==

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 del carico di lavoro 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 AZURE_CONTROL_PLANE_MACHINE_TYPE e AZURE_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.

AZURE_CONTROL_PLANE_MACHINE_TYPE: "Standard_D2s_v3"
AZURE_NODE_MACHINE_TYPE: "Standard_D2s_v3"

È possibile sostituire queste impostazioni utilizzando le opzioni SIZE, CONTROLPLANE_SIZE e WORKER_SIZE. Per creare un cluster del carico di lavoro 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. Impostarla su Standard_D2s_v3, Standard_D4s_v3 e così via. Per informazioni sulle istanze dei nodi per Azure, vedere Dimensioni per le macchine virtuali in Azure.

SIZE: Standard_D2s_v3

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: Standard_D2s_v3
WORKER_SIZE: Standard_D4s_v3

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

SIZE: Standard_D2s_v3
WORKER_SIZE: Standard_D4s_v3

Distribuzione di un cluster con subnet di nodi personalizzate

Per specificare subnet personalizzate (intervalli di IP) per i nodi di un cluster, impostare le variabili nel modo seguente prima di creare il cluster. È possibile definirle come variabili di ambiente prima di eseguire tanzu cluster create o includerle nel file di configurazione del cluster passato con l'opzione --file.

Per specificare una subnet personalizzata (intervallo di IP) per il nodo del piano di controllo in un cluster:

  • Subnet già definita in Azure: impostare AZURE_CONTROL_PLANE_SUBNET_NAME sul nome della subnet.
  • Creare una nuova subnet: impostare AZURE_CONTROL_PLANE_SUBNET_NAME per assegnare un nome alla nuova subnet e facoltativamente impostare AZURE_CONTROL_PLANE_SUBNET_CIDR su un intervallo CIDR nella VNet di Azure configurata.
    • Se si omette AZURE_CONTROL_PLANE_SUBNET_CIDR, viene generato automaticamente un CIDR.

Per specificare una subnet personalizzata per i nodi worker in un cluster, impostare le variabili di ambiente AZURE_NODE_SUBNET_NAME e AZURE_NODE_SUBNET_CIDR seguendo le stesse regole del nodo del piano di controllo indicate in precedenza.

Ad esempio:

AZURE_CONTROL_PLANE_SUBNET_CIDR: 10.0.0.0/24
AZURE_CONTROL_PLANE_SUBNET_NAME: my-cp-subnet
AZURE_NODE_SUBNET_CIDR: 10.0.1.0/24
AZURE_NODE_SUBNET_NAME: my-worker-subnet
AZURE_RESOURCE_GROUP: my-rg
AZURE_VNET_CIDR: 10.0.0.0/16
AZURE_VNET_NAME: my-vnet
AZURE_VNET_RESOURCE_GROUP: my-rg

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.

Importante

se è la prima volta che si distribuisce un cluster di gestione in Azure con una nuova versione di Tanzu Kubernetes Grid, ad esempio v2.3, assicurarsi di aver accettato la licenza dell'immagine di base per tale versione. Per informazioni, vedere Accettazione della licenza dell'immagine di base in Preparazione della distribuzione dei cluster di gestione in Microsoft Azure.

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