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

 

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:

  1. 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

  2. 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

  3. 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.

  4. Per creare il cluster del carico di lavoro, eseguire tanzu cluster create, come descritto in Creazione di un cluster basato sul piano o TKC.

  5. 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:

  1. 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.

  2. 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.

  3. Utilizzare il file per creare l'oggetto Secret:

    kubectl apply -f secret.yaml

  4. 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.

  5. 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:

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

  2. 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
...

  3. 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:

  1. Creare un tag e associarlo ai datastore pertinenti:

    1. Creare categorie di tag in vCenter Server seguendo le indicazioni di Creazione, modifica o eliminazione di una categoria di tag. Assicurarsi che la categoria includa Datastore come tipo di oggetto associabile.
    2. Seguire le istruzioni di Creazione di un tag per creare un tag all'interno della categoria creata nel passaggio precedente.
    3. Seguire le istruzioni di Assegnazione o rimozione di un tag per associare il nuovo tag a tutti i datastore appartenenti al cluster di datastore.

  2. 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.

  3. 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.

  1. Creare un'immagine della macchina Windows eseguendo tutte le procedure descritte in Immagini delle macchine personalizzate di Windows.

  2. 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.24.10---vmware.1-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.24.10+vmware.1-tkg.1
     version: v1.24.10+vmware.1-tkg.1-windows
   type: ova
 kubernetesVersion: v1.24.10+vmware.1
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"

  3. Eseguire kubectl apply -f win-osimage.yaml per aggiungere OSImage.

  4. Aggiungere la versione di TKR a spec.osImages in modo che la risoluzione di TKR e la convalida webhook vengano completate correttamente. Utilizzare il comando seguente per aggiungere la versione di TKR a spec.osImages.

    $ kubectl edit tkr v1.24.10---vmware.x-tkg.x
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
  name: v1.24.10---vmware.x-tkg.x
spec:
  bootstrapPackages:
  # Keep the other packages listed here.
  - name: tkg-windows.tanzu.vmware.com.0.28.1+vmware.1
  osImages:
  # Keep the other images listed here.
  - name: v1.24.10---vmware.1-tkg.1-windows

    In TKR, abilitare il pacchetto tkg-windows aggiungendo un nuovo elemento in spec.bootstrapPackages. Il pacchetto è disponibile nel repository ufficiale tramite tanzu package available list tkg-windows.tanzu.vmware.com. Di seguito è disponibile un esempio di TKR funzionante:

  5. 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 di Windows. * CLUSTER-CONFIG è il nome del file di configurazione.

  6. 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

  7. 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.

Affidabilità della CNI Antrea Windows

La rete HNS non è persistente in Windows. Dopo il riavvio del nodo Windows, la rete HNS creata da antrea-agent viene rimossa e l'estensione Open vSwitch è disabilitata per impostazione predefinita. Pertanto, dopo il riavvio del nodo Windows, rimuovere le porte e il bridge OVS obsoleti. È possibile utilizzare lo script della guida Clean-AntreaNetwork.ps1 per pulire il bridge OVS.

Per scaricare lo script, utilizzare uno dei metodi seguenti:

  • Installazione manuale
  • Installazione automatizzata

Installazione manuale

Per installare manualmente lo script della Guida in ogni nodo del carico di lavoro isolato:

  1. Scaricare lo script di installazione di Clean-AntreaNetwork.ps1 da questo esempio di codice. Lo script di installazione scaricato snippet.ps1 installa Clean-AntreaNetwork.ps1.

  2. Accedere tramite SSH al nodo ed eseguire il comando seguente.

    powershell snippet.ps1

Installazione automatizzata

Per creare un ClusterClass personalizzato che installi automaticamente lo script di guida in ogni nuovo nodo del carico di lavoro:

  1. Eseguire i passaggi in Creazione di una ClusterClass per creare l'oggetto ClusterClass personalizzato.

  2. Applicare la patch da questo esempio di codice utilizzando YTT e applicare la specifica al cluster di gestione:

    ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -

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
check-circle-line exclamation-circle-line close-line
Scroll to top icon