Questo documento mostra come configurare un criterio di archiviazione delle VM per un cluster GKE su VMware.
Panoramica
In vSphere, Storage Policy Based Management (SPBM) consente di allineare l'archiviazione alle esigenze delle applicazioni delle macchine virtuali. Fornisce un framework dei criteri di archiviazione che funge da singolo pannello di controllo unificato per un'ampia gamma di servizi dati e soluzioni di archiviazione.
In un cluster Anthos su VMware, puoi specificare criteri di archiviazione come alternativa alla specifica dei datastore. Tu definisci i criteri di archiviazione in base ai requisiti delle tue applicazioni e poi vSphere seleziona e gestisce automaticamente i datastore. Ciò può ridurre l'overhead e la manutenzione associati all'archiviazione.
Ereditarietà
Puoi specificare un criterio di archiviazione per un cluster utente, un pool di nodi in un cluster utente o un set di nodi del piano di controllo in un cluster utente. Puoi anche specificare un criterio di archiviazione per un cluster di amministrazione, purché il cluster di amministrazione abbia un piano di controllo ad alta disponibilità e non abbia pool di nodi Windows.
Se specifichi un criterio di archiviazione per un cluster utente, il criterio viene ereditato dai pool di nodi nel cluster utente. Se specifichi un criterio di archiviazione per un singolo pool di nodi, viene utilizzato questo criterio al posto del criterio di archiviazione a livello di cluster. Allo stesso modo, se specifichi un datastore per un singolo pool di nodi, viene utilizzato questo datastore al posto del criterio di archiviazione a livello di cluster.
In un cluster utente in cui è abilitato Controlplane V2, il criterio di archiviazione a livello di cluster viene ereditato dai nodi del piano di controllo. Se specifichi un criterio di archiviazione o un datastore per i nodi del piano di controllo, viene utilizzato il criterio di archiviazione o il datastore al posto del criterio di archiviazione a livello di cluster.
Applicazione di criteri di archiviazione ai datastore
Puoi applicare un criterio di archiviazione a un singolo datastore o a più datastore. Se applichi un criterio di archiviazione a più datastore, le risorse di archiviazione per un cluster di amministrazione, un cluster utente o un pool di nodi possono essere distribuite tra i datastore.
Esempio: creare un criterio di archiviazione e un cluster utente
Questa sezione fornisce un esempio di creazione di un criterio di archiviazione e di un cluster utente. Questo esempio illustra l'idea che un criterio di archiviazione può essere applicato a due datastore.
Applica tag ai datastore
Per eseguire i passaggi in questo esempio, l'ambiente vSphere deve avere almeno due datastore.
Il cluster vSphere che ospiterà i nodi per il tuo cluster utente deve avere accesso ai datastore che prevedi di utilizzare per questo esercizio. Esiste un controllo preflight che lo verifica.
L'account vCenter che utilizzi per applicare i tag deve disporre dei seguenti privilegi di privilegi di tagging vSphere su vCenter Server principale:
- Tagging vSphere.Crea tag vSphere
- Categoria tag vSphere Tagging.Create
- vSphere Tagging.Assign o Annulla assegnazione del tag vSphere
In vSphere Client, assegna lo stesso tag a ciascuno dei datastore che hai scelto di utilizzare per questo esercizio. Per le istruzioni, consulta Assegnare tag a Datastore.
Per ulteriori informazioni, consulta Tag e attributi vSphere.
Crea un criterio di archiviazione
In vSphere Client, crea un criterio di archiviazione delle VM per il posizionamento basato su tag. Nel criterio di archiviazione, specifica il tag applicato ai datastore selezionati. Per le istruzioni, consulta Creare un criterio di archiviazione delle VM per il posizionamento basato su tag.
Per ulteriori informazioni, consulta la pagina relativa ai criteri di archiviazione delle VM.
Se utilizzi un datastore vSAN, consulta il criterio di archiviazione vSAN.
Creazione di un cluster utente
In questo esercizio creerai un cluster utente con un piano di controllo ad alta disponibilità, quindi ci sono tre nodi del piano di controllo. Oltre ai nodi del piano di controllo, ci sono sei nodi worker, tre in un pool di nodi e tre in un secondo pool. Tutti i nodi utilizzano indirizzi IP statici.
Inizia seguendo le istruzioni in Creare un cluster utente.
Quando compili il file di configurazione del cluster utente:
Imposta il valore di
vCenter.storagePolicyName
sul nome di un criterio di archiviazione esistente. Non impostare un valore pervCenter.datastore
.Specifica due pool di nodi. Per il primo pool di nodi, non specificare un datastore e non specificare un criterio di archiviazione. Per il secondo pool di nodi, imposta il valore di
vsphere.datastore
sul nome di un datastore esistente.
Esempio di file di configurazione del cluster
Ecco un esempio di file di blocchi IP e di una parte di un file di configurazione del cluster utente.
user-ipblock.yaml
blocks: - netmask: 255.255.255.0 gateway: 172.16.21.1 ips: - ip: 172.16.21.2 - ip: 172.16.21.3 - ip: 172.16.21.4 - ip: 172.16.21.5 - ip: 172.16.21.6 - ip: 172.16.21.7 - ip: 172.16.21.8
user-cluster-yaml
apiVersion: v1 kind: UserCluster ... vCenter: storagePolicyName: "my-storage-policy" network: hostConfig: dnsServers: - "203.0.113.2" - "198.51.100.2" ntpServers: - "216.239.35.4" ipMode: type: "static" ipBlockFilePath: "user-ipblock.yaml" controlPlaneIPBlock: netmask: "255.255.255.0" gateway: "172.16.21.1" ips: - ip: "172.16.21.9" hostname: "cp-vm-1" - ip: "172.16.21.10" hostname: "cp-vm-2" - ip: "172.16.21.11" hostname: "cp-vm-3" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" ingressVIP: "172.16.21.30" kind: MetalLB metalLB: addressPools: - name: "address-pool-1" addresses: - "172.16.21.30-172.16.21.39" ... enableControlplaneV2: true masterNode: cpus: 4 memoryMB: 8192 replicas: 3 nodePools: - name: "worker-pool-1" enableLoadBalancer: true - name: "worker-pool-2" vSphere: datastore: "my-np2-datastore" ...
Di seguito sono riportati i punti importanti da comprendere nell'esempio precedente:
Gli indirizzi IP statici per i nodi worker sono specificati in un file di blocchi IP. Il file dei blocchi IP ha sette indirizzi anche se ci sono solo sei nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.
Gli indirizzi IP statici per i tre nodi del piano di controllo sono specificati nella sezione
network.controlPlaneIPBlock
del file di configurazione del cluster utente. Non è necessario un indirizzo IP aggiuntivo in questo blocco.Il campo
masterNode.replicas
è impostato su3
, quindi saranno presenti tre nodi del piano di controllo. InmasterNode
, non viene specificato nulla pervsphere.datastore
ovsphere.storagePolicyName
. I nodi del piano di controllo utilizzeranno quindi il criterio di archiviazione specificato invCenter.storagePolicyName
.Il file di configurazione del cluster utente include un valore per
vCenter.storagePolicy
, ma non un valore pervCenter.datastore
. Il criterio di archiviazione specificato verrà utilizzato dai nodi in qualsiasi pool che non specifica un criterio di archiviazione o un proprio datastore.In
node-pool-1
, non viene specificato nulla pervsphere.datastore
ovsphere.storagePolicyName
. Di conseguenza, i nodi innode-pool-1
utilizzeranno il criterio di archiviazione specificato invCenter.storagePolicyName
.In
node-pool-2
, il valore divsphere.datastore
èmy-np2-datastore
, pertanto i nodi innode-pool-2
utilizzano quel datastore e non usano un criterio di archiviazione.
Continua a creare il cluster utente come descritto in Creare un cluster utente.
Crea un cluster utente in un data center separato dal cluster di amministrazione
Un cluster utente può trovarsi in un data center separato dal cluster di amministrazione. I due data center possono utilizzare la stessa istanza di vCenter Server o istanze diverse di vCenter Server.
Questa sezione fornisce un esempio di come creare un cluster utente che utilizza un'istanza di vCenter Server separata dal cluster di amministrazione. Poiché i cluster di amministrazione e utente utilizzano istanze separate di vCenter Server, si trovano anche in data center separati.
Inizia seguendo le istruzioni in Creare un cluster utente.
Quando compili il file di configurazione del cluster utente:
Imposta il valore di
vCenter.storagePolicyName
sul nome di un criterio di archiviazione esistente. Non impostare un valore pervCenter.datastore
.In
vCenter
, specifica i valori peraddress
,datacenter
,cluster
eresourcePool
.Specifica un valore per
network.vCenter.networkName
.Specifica due pool di nodi. Per il primo pool di nodi, non specificare un datastore e non specificare un criterio di archiviazione. Per il secondo pool di nodi, imposta il valore di
vsphere.datastore
sul nome di un datastore esistente.
Esempio di file di configurazione del cluster
Ecco un esempio di file di blocchi IP e di una parte di un file di configurazione del cluster utente.
user-ipblock.yaml
blocks: - netmask: 255.255.255.0 gateway: 172.16.21.1 ips: - ip: 172.16.21.2 - ip: 172.16.21.3 - ip: 172.16.21.4 - ip: 172.16.21.5 - ip: 172.16.21.6 - ip: 172.16.21.7 - ip: 172.16.21.8
user-cluster-yaml
apiVersion: v1 kind: UserCluster ... vCenter: address: "my-vcenter-server-2.my-domain.example" datacenter: "my-uc-data-center" cluster: "my-uc-vsphere-cluster" resourcePool: "my-uc-resource-pool" storagePolicyName: "my-storage-policy" network: vCenter: networkName: "my-uc-network" hostConfig: dnsServers: - "203.0.113.2" - "198.51.100.2" ntpServers: - "216.239.35.4" ipMode: type: "static" ipBlockFilePath: "user-ipblock.yaml" controlPlaneIPBlock: netmask: "255.255.255.0" gateway: "172.16.21.1" ips: - ip: "172.16.21.9" hostname: "cp-vm-1" - ip: "172.16.21.10" hostname: "cp-vm-2" - ip: "172.16.21.11" hostname: "cp-vm-3" loadBalancer: vips: controlPlaneVIP: "172.16.21.40" ingressVIP: "172.16.21.30" kind: MetalLB metalLB: addressPools: - name: "address-pool-1" addresses: - "172.16.21.30-172.16.21.39" ... enableControlplaneV2: true masterNode: cpus: 4 memoryMB: 8192 replicas: 3 nodePools: - name: "worker-pool-1" enableLoadBalancer: true - name: "worker-pool-2" vSphere: datastore: "my-np2-datastore" ...
Di seguito sono riportati i punti importanti da comprendere nell'esempio precedente:
Il file di configurazione del cluster utente include un valore per
vCenter.storagePolicy
, ma non un valore pervCenter.datastore
. Il criterio di archiviazione specificato verrà utilizzato dai nodi in qualsiasi pool di nodi che non specifica un proprio criterio di archiviazione o un proprio datastore.In
vCenter
sono stati specificati valori peraddress
,datacenter
,cluster
eresourcePool
. Di conseguenza, il cluster utente utilizzerà un server vCenter, un data center, un cluster vSphere e un pool di risorse diversi dal cluster di amministrazione.Esiste un valore specificato per
network.vCenter.networkName
.Il campo
masterNode.replicas
è impostato su3
, quindi saranno presenti tre nodi del piano di controllo. InmasterNode
, non viene specificato nulla pervsphere.datastore
ovsphere.storagePolicyName
. I nodi del piano di controllo utilizzeranno quindi il criterio di archiviazione specificato invCenter.storagePolicyName
.In
node-pool-1
, non viene specificato nulla pervsphere.datastore
ovsphere.storagePolicyName
. Di conseguenza, i nodi innode-pool-1
utilizzeranno il criterio di archiviazione specificato invCenter.storagePolicyName
.In
node-pool-2
, il valore divsphere.datastore
èmy-np2-datastore
, pertanto i nodi innode-pool-2
utilizzano quel datastore e non usano un criterio di archiviazione.
Continua a creare il cluster utente come descritto in Creare un cluster utente.
Spazio di archiviazione vMotion in uso
Questa sezione mostra come utilizzare vMotion di archiviazione in un cluster che usa SPBM. Se vuoi utilizzare vMotion di archiviazione in un cluster che non utilizza SPBM, consulta Utilizzare lo strumento di migrazione del datastore.
Segui questi passaggi:
Esegui la migrazione di tutte le VM del cluster nel datastore di destinazione. Per le istruzioni, consulta Eseguire la migrazione di una macchina virtuale a una nuova risorsa di computing e spazio di archiviazione.
Verifica che la migrazione delle VM al nuovo datastore sia stata eseguita correttamente.
Recupera gli oggetti macchina nel cluster:
kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
Nell'output, in
status.disks
, puoi vedere i dischi collegati alle VM. Ad esempio:status: addresses: – address: 172.16.20.2 type: ExternalIP disks: – bootdisk: true datastore: pf-ds06 filepath: ci-bluecwang-head-xvz2ccv28bf9wdbx-2/ci-bluecwang-head-xvz2ccv28bf9wdbx-2.vmdk uuid: 6000C29d-8edb-e742-babc-9c124013ba54 – datastore: pf-ds06 filepath: anthos/gke-admin-nc4rk/ci-bluecwang-head/ci-bluecwang-head-2-data.vmdk uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9
Verifica che sia stata eseguita la migrazione di tutti i dischi di tutte le macchine nel cluster nel datastore di destinazione.
Esegui
gkectl diagnose
per verificare che il cluster sia integro.Aggiorna il criterio di archiviazione per escludere i datastore precedenti. In caso contrario, i nuovi volumi e le VM ricreate potrebbero essere assegnati a un datastore precedente.