Cluster in vSphere

Le sezioni seguenti descrivono come configurare i cluster del carico di lavoro di Tanzu Kubernetes Grid (TKG) in modo che utilizzino funzionalità specifiche per vSphere. Le funzionalità non sono completamente configurabili nel file di configurazione flat del cluster o nella specifica dell'oggetto di tipo Kubernetes.

Per informazioni su come configurare i cluster del carico di lavoro in vSphere utilizzando i file di configurazione e le specifiche degli oggetti, vedere:

Distribuzione di un cluster con un'immagine OVA personalizzata

Se si utilizza una singola immagine OVA personalizzata per ogni versione di Kubernetes per distribuire cluster in un sistema operativo, importare il file OVA in vSphere e quindi specificarlo per tanzu cluster create con l'opzione --tkr.

Tuttavia, se si utilizzano più immagini OVA personalizzate per la stessa versione di Kubernetes, il valore di --tkr è ambiguo. Ciò si verifica quando i file OVA per la stessa versione di Kubernetes:

Hanno sistemi operativi diversi, ad esempio creati da make build-node-ova-vsphere-ubuntu-1804, make build-node-ova-vsphere-photon-3 e make build-node-ova-vsphere-rhel-7.
Hanno lo stesso nome ma si trovano in cartelle di vCenter diverse.

Per risolvere questa ambiguità, impostare l'opzione VSPHERE_TEMPLATE sull'immagine OVA desiderata prima di eseguire tanzu cluster create.

Se il nome dell'immagine del modello OVA è univoco, impostare VSPHERE_TEMPLATE solo sul nome dell'immagine.
Se più immagini condividono lo stesso nome, impostare VSPHERE_TEMPLATE sul percorso completo dell'inventario dell'immagine in vCenter. Questo percorso ha il formato /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE, in cui:
- MY-DC è il data center contenente l'immagine del modello OVA.
- MY-FOLDER-PATH è il percorso dell'immagine nel data center, come indicato nella vista Macchine virtuali e modelli di vCenter.
- MY-IMAGE è il nome dell'immagine.
Ad esempio:
```
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
```
È possibile determinare manualmente il percorso completo dell'immagine nell'inventario di vCenter o utilizzare la CLI govc:
1. Installare govc. Per le istruzioni di installazione, vedere il repository govmomi in GitHub.
2. Impostare le variabili di ambiente per govc per accedere a vCenter:
  - export GOVC_USERNAME=VCENTER-USERNAME
  - export GOVC_PASSWORD=VCENTER-PASSWORD
  - export GOVC_URL=VCENTER-URL
  - export GOVC_INSECURE=1
3. Eseguire govc find / -type m e individuare il nome dell'immagine nell'output in cui sono elencati gli oggetti in base ai loro percorsi completi nell'inventario.

Per ulteriori informazioni sulle immagini OVA personalizzate, vedere Creazione di immagini di macchine.

Distribuzione di un cluster con tag di regione e zona per CSI

È possibile specificare una regione e una zona per il cluster del carico di lavoro da integrare con i tag di regione e zona configurati per vSphere CSI (Cloud Storage Interface). Per i cluster che si estendono in più zone, ciò consente ai nodi worker di trovare e utilizzare lo storage condiviso, anche se vengono eseguiti in zone che non dispongono di pod di storage, ad esempio in una rete RAN (Radio Access Network) delle telecomunicazioni.

Per distribuire un cluster del carico di lavoro con tag di regione e zona che abilitano lo storage condiviso con vSphere CSI:

Creare tag in vCenter Server:
1. Creare categorie di tag in vCenter Server seguendo le indicazioni di Creazione e modifica di una categoria di tag. Ad esempio, k8s-region e k8s-zone.
2. Seguire le indicazioni di Creazione e modifica di un tag di vSphere per creare tag nelle categorie di regioni e zone nel data center, come illustrato in questa tabella:
  
  Categoria Tag
  
  k8s-zone zone-a
  zone-b
  zone-c
  
  k8s-region region-1

Categoria	Tag
`k8s-zone`	`zone-a` `zone-b` `zone-c`
`k8s-region`	`region-1`

Creare tag corrispondenti per i cluster e il data center seguendo le istruzioni di Assegnazione o rimozione di un tag di vSphere come indicato nella tabella.


Oggetti di vSphere	Tag
`datacenter`	`region-1`
`cluster1`	`zone-a`
`cluster2`	`zone-b`
`cluster3`	`zone-c`

Per abilitare regioni e zone personalizzate per il driver CSI di un cluster del carico di lavoro di vSphere, impostare le variabili VSPHERE_REGION e VSPHERE_ZONE nel file di configurazione del cluster sui tag precedenti. Ad esempio:
```
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
```
Quando la CLI di Tanzu crea un cluster del carico di lavoro con queste variabili impostate, etichetta ogni nodo del cluster con le chiavi della topologia failure-domain.beta.kubernetes.io/zone e failure-domain.beta.kubernetes.io/region.
Per creare il cluster del carico di lavoro, eseguire tanzu cluster create, come descritto in Creazione di un cluster basato sul piano o TKC.
Dopo aver creato il cluster e con il contesto kubectl impostato sul cluster, è possibile controllare le etichette di regione e zona eseguendo una delle operazioni seguenti:
- Eseguire kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region e verificare che nell'output vengano elencati i nodi del cluster.
- Eseguire kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' e verificare che la regione e la zona siano abilitate in vsphere-csi.

Per ulteriori informazioni sulla configurazione di vSphere CSI, vedere Driver vSphere CSI - Distribuzione con topologia.

Cluster in account vSphere diversi

Tanzu Kubernetes Grid può eseguire cluster del carico di lavoro in più account della piattaforma di destinazione, ad esempio per dividere l'utilizzo del cloud tra team diversi o applicare profili di sicurezza diversi ai carichi di lavoro di produzione, staging e sviluppo.

Per distribuire cluster del carico di lavoro in un account vSphere alternativo, diverso da quello utilizzato per distribuire il cluster di gestione, eseguire i passaggi seguenti:

Impostare il contesto di kubectl sul cluster di gestione:
```
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
```
In cui MY-MGMT-CLUSTER è il nome del cluster di gestione.
Creare un file secret.yaml con i contenuti seguenti:
```
apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
  namespace: CAPV-MANAGER-NAMESPACE
stringData:
  username: VSPHERE-USERNAME
  password: VSPHERE-PASSWORD
```
In cui:
- SECRET-NAME è un nome che viene attribuito al segreto client.
- CAPV-MANAGER-NAMESPACE è lo spazio dei nomi in cui è in esecuzione il pod capv-manager. Valore predefinito: capv-system.
- VSPHERE-USERNAME e VSPHERE-PASSWORD sono credenziali di accesso che consentono di accedere all'account vSphere alternativo.
Utilizzare il file per creare l'oggetto Secret:
```
kubectl apply -f secret.yaml
```

Creare un file identity.yaml con i contenuti seguenti:

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
spec:
  secretName: SECRET-NAME
  allowedNamespaces:
    selector:
      matchLabels: {}

In cui:

EXAMPLE-IDENTITY è il nome da utilizzare per l'oggetto VSphereClusterIdentity.
SECRET-NAME è il nome attribuito al segreto client in precedenza.

Utilizzare il file per creare l'oggetto VsphereClusterIdentity:
```
kubectl apply -f identity.yaml
```

Il cluster di gestione può ora distribuire cluster del carico di lavoro all'account alternativo.

Per distribuire un cluster del carico di lavoro nell'account:

Creare un manifest del cluster eseguendo tanzu cluster create --dry-run.

Modificare la definizione di VSphereCluster nel manifesto per impostare il valore spec.identityRef.name per il relativo oggetto VSphereClusterIdentity sull'identità EXAMPLE-IDENTITY creata in precedenza:

...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
 name: new-workload-cluster
spec:
 identityRef:
   kind: VSphereClusterIdentity
   name: EXAMPLE-IDENTITY
...

Eseguire kubectl apply -f my-cluster-manifest.yaml per creare il cluster del carico di lavoro.

Dopo aver creato il cluster del carico di lavoro, accedere a vSphere con le credenziali dell'account alternativo. Il cluster verrà visualizzato in esecuzione.

Per ulteriori informazioni, vedere Identity Management nel repository Cluster API Provider vSphere.

Distribuzione di un cluster che utilizza un cluster di datastore

Nota
Questa funzionalità non funziona come previsto. Se si assegnano tag a più datastore in un cluster di datastore, come base per il criterio di storage di un cluster del carico di lavoro, il cluster del carico di lavoro utilizza solo uno dei datastore.

Per consentire a un cluster del carico di lavoro di utilizzare un cluster di datastore anziché un singolo datastore, configurare un criterio di storage che abbia come destinazione tutti i datastore all'interno del cluster di datastore nel modo seguente:

Creare un tag e associarlo ai datastore pertinenti:
1. Eseguire le procedure in Tag di vSphere per creare categorie di tag in vCenter Server. Assicurarsi che la categoria includa Datastore come tipo di oggetto associabile.
2. Eseguire le altre procedure in Tag di vSphere per creare un tag nella categoria creata nel passaggio precedente e per associare il nuovo tag a tutti i datastore appartenenti al cluster di datastore.
Seguire le istruzioni di Creazione di un criterio di storage della macchina virtuale per il posizionamento basato su tag per creare un criterio di storage basato su tag.
Nel file di configurazione del cluster:
- Impostare VSPHERE_STORAGE_POLICY_ID sul nome del criterio di storage creato nel passaggio precedente.
- Assicurarsi che VSPHERE_DATASTORE non sia impostato. Un'impostazione VSPHERE_DATASTORE sostituirebbe l'impostazione del criterio di storage.

Distribuzione di un cluster di carichi di lavoro multi OS

Per distribuire un cluster del carico di lavoro con più sistemi operativi che dispone di nodi di lavoro Windows e basati su Linux, creare un'immagine della macchina Windows personalizzata, distribuire un cluster del carico di lavoro Windows e quindi aggiungere una MachineDeployment Linux per convertire il cluster del carico di lavoro solo Windows in un cluster con più sistemi operativi.

I cluster con più sistemi operativi possono ospitare carichi di lavoro Windows e Linux durante l'esecuzione dei componenti TKG basati su Linux nei nodi worker, a cui appartengono.

Creare un'immagine della macchina Windows eseguendo tutte le procedure descritte in Immagini delle macchine personalizzate di Windows.
Creare un file YAML, ad esempio win-osimage.yaml per aggiungere un OSImage nel cluster di gestione che punti al modello quando è stata creata un'immagine della macchina Windows.

È possibile utilizzare il seguente file YAML di esempio. Modificare il valore spec.image.ref.template con la posizione del modello Windows creato. Il percorso è specifico dell'ambiente vSphere.
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.27.5---vmware.2-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.27.5
     version: v1.27.5+vmware.2-tkg.1-windows
   type: ova
 kubernetesVersion: v1.27.5+vmware.2
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"
```
Eseguire kubectl apply -f win-osimage.yaml per aggiungere OSImage.
Aggiungere il nuovo pacchetto OSImage e tkg-windows alla TKR che si desidera utilizzare per il cluster MultiOS in modo che la risoluzione TKR e la convalida del webhook vengano completate correttamente e che i componenti Windows possano essere installati.

Utilizzare il comando seguente per modificare la TKR per aggiungere OSImage come nuovo elemento in spec.osImages e per aggiungere il pacchetto tkg-windows come nuovo elemento in spec.bootstrapPackages.
```
$ kubectl edit tkr v1.27.5---vmware.2-tkg.1
```
Il pacchetto tkg-windows è disponibile nel repository ufficiale con tanzu package available list tkg-windows.tanzu.vmware.com. Di seguito è disponibile un esempio di TKr funzionante:
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
 name: v1.27.5---vmware.2-tkg.1
spec:
 bootstrapPackages:
 # Add the tkg-windows package to this list AND keep the other packages already listed here under bootstrapPackages.
 - name: tkg-windows.tanzu.vmware.com.0.31.0+vmware.1
 osImages:
 # Add the Windows OSImage name to this list AND kKeep the other images already listed here under osImages.
 - name: v1.27.5---vmware.2-tkg.1-windows
```
Nota
Questa modifica della TKR non verrà sovrascritta dal gestore del controller TKR; anche se il gestore riconcilia continuamente le TKR dal repository TKG con il repository interno, la sua riconciliazione non comporta modifiche, ma solo la creazione di nuove TKR mancanti
Verificare che il file di configurazione del cluster MultiOS disponga dei seguenti parametri:
```
IS_WINDOWS_WORKLOAD_CLUSTER: "true"
```
Creare la specifica di un oggetto cluster basato sulla classe eseguendo il comando seguente:
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
In cui:
- WINDOWS-CLUSTER è il nome del cluster Windows.
- CLUSTER-CONFIG è il nome del file di configurazione.

Aggiungere la nuova classe di distribuzione della macchina tkg-worker all'oggetto cluster in my-cluster-spec.yaml. Assicurarsi che l'annotazione sia corretta in modo che TKG possa cercare l'oggetto OSImage.

È possibile aggiungere la nuova specifica tkg-worker a spec.workers.machineDeployments in modo analogo all'esempio seguente:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: WINDOWS-CLUSTER
spec:
  workers:
    machineDeployments:
    - class: tkg-worker
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
        name: md-0-l
        replicas: 1
    - class: tkg-worker-windows
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
        name: md-0
        replicas: 1

Distribuire il cluster con più sistemi operativi eseguendo il comando seguente:

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

I nodi ricevono etichette e taint con le informazioni del sistema operativo in Etichette, annotazioni e taint ben noti.

Nota
Il backup e il ripristino dei cluster del carico di lavoro multi OS non sono supportati.

Note sulla sicurezza dei gruppi di porte distribuite

Se si distribuiscono cluster Windows o MultiOS, è necessario assicurarsi che determinati criteri di sicurezza nei gruppi di porte distribuite siano impostati su Reject. Ad esempio, se la modalità promiscua è impostata su Accept, i nodi possono passare dallo stato Ready allo stato NotReady.

In vSphere Client, selezionare la rete utilizzata per i nodi Windows, passare a Distributed Switch virtuale (Virtual Distributed Switch) > Criterio di sicurezza gruppo di porte distribuite (Distributed Portgroup Security Policy) e impostare questi criteri su Reject:

Modalità promiscua
Modifiche all'indirizzo MAC
Trasmissioni contraffatte