Crea un cluster utente con un nuovo modello di installazione

Questo documento mostra come creare un cluster utente che utilizza un nuovo modello di installazione disponibile come funzionalità di anteprima nella versione 1.13 di Cluster Anthos su VMware (GKE On-Prem).

Cos'è la kubeception?

Il termine kubeception è utilizzato per comunicare l'idea che un cluster Kubernetes venga utilizzato per creare e gestire altri cluster Kubernetes. Nel contesto dei cluster Anthos su VMware, kubeception si riferisce al caso in cui il piano di controllo per un cluster utente viene eseguito su uno o più nodi in un cluster di amministrazione.

A partire dalla versione 1.13.0, puoi scegliere di eseguire il piano di controllo per un cluster utente su uno o più nodi nel cluster utente stesso. Nelle versioni precedenti dei cluster Anthos su VMware, kubeception era l'unica opzione. Ciò significa che tutti i cluster utente avevano i propri piani di controllo nel cluster di amministrazione.

Il nuovo modello di installazione introduce la coerenza architetturale tra i cluster di amministrazione e gli utenti e disaccoppia il cluster di utenti dal cluster di amministrazione. Questo è un vantaggio per scenari come l'esecuzione di cluster su diversi siti geografici.

Prima di iniziare

Devi avere un cluster di amministrazione e la versione del cluster di amministrazione deve essere 1.13.0 o successiva.

Pianifica i tuoi indirizzi IP

Quando pianifichi i tuoi indirizzi IP per il cluster utente, tieni presente i seguenti requisiti per il nuovo modello di installazione:

  • I nodi del piano di controllo per il cluster utente devono recuperare i propri indirizzi IP da un elenco di indirizzi statici che fornisci. anche se i nodi worker cercano di recuperare i propri indirizzi da un server DHCP. Sono necessari tre nodi del piano di controllo per un cluster utente ad alta disponibilità, ma un solo nodo del piano di controllo per un cluster utente non ad alta disponibilità.

  • I nodi del piano di controllo del cluster utente devono essere nella stessa VLAN dei nodi worker del cluster utente. Ciò è in contrasto con il modello kubeception.

  • Il VIP del piano di controllo del cluster utente deve essere nella stessa VLAN dei nodi worker del cluster utente e dei nodi del piano di controllo del cluster utente. Ciò è in contrasto con il modello kubeception.

Pianifica il tuo ambiente vSphere

Il file di configurazione del cluster di amministrazione e il file di configurazione del cluster utente hanno entrambi una sezione vCenter in cui puoi specificare le risorse vSphere che vuoi che vengano utilizzate dall'amministratore o dal cluster utente.

Per un cluster utente, non è necessario compilare la sezione vCenter, perché per impostazione predefinita un cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione. Tuttavia, se vuoi che il cluster utente utilizzi risorse vSphere diverse da quelle specificate per il cluster di amministrazione, puoi compilare i campi scelti da te nella sezione vCenter del file di configurazione del cluster utente. Per ulteriori informazioni, consulta Configurare la gerarchia degli oggetti vSphere.

Nel nuovo modello di installazione, i nodi del piano di controllo per il cluster utente si trovano nel cluster utente stesso. Quindi i nodi del piano di controllo utilizzano le risorse vSphere specificate nel file di configurazione del cluster utente. Supponi, ad esempio, di specificare datacenter-1 per il tuo cluster di amministrazione e datacenter-2 per il tuo cluster utente. I nodi del piano di controllo per il cluster utente saranno in datacenter-2.

Gruppi anti-affinità

Il file di configurazione del cluster di amministrazione e il file di configurazione del cluster utente hanno entrambi un campo antiAffinityGroups.enabled che puoi impostare su true o false.

Nel nuovo modello di installazione, i nodi del piano di controllo per il cluster utente vengono distribuiti in base al valore antiAffinityGroups.enabled nel file di configurazione del cluster utente.

Al contrario, con il modello kubeception, i nodi del piano di controllo per il cluster utente vengono distribuiti in base al valore antiAffinityGroups.enabled nel file di configurazione del cluster di amministrazione.

Esempio

Di seguito è riportato un esempio di cluster utente con le seguenti caratteristiche:

  • Ci sono tre nodi worker.

  • I nodi worker hanno indirizzi IP statici.

  • Ci sono tre nodi del piano di controllo. ovvero un cluster ad alta disponibilità.

  • Il bilanciatore del carico è MetalLB.

  • Il cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione.

Il seguente diagramma illustra la rete per i cluster di amministrazione e di utenti:

Cluster di amministrazione e cluster utente
Un cluster di amministrazione e un cluster utente (fai clic per ingrandire)

Ecco un esempio di file di blocco 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
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
...
kubeception: false
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.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      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"
...
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

Questi sono i punti importanti da comprendere nell'esempio precedente:

  • Gli indirizzi IP statici per i nodi worker vengono specificati in un file di blocco IP. Il file di blocco IP ha quattro indirizzi, anche se ci sono solo tre nodi worker. Durante l'upgrade del cluster, l'aggiornamento e la riparazione automatica è necessario un indirizzo IP aggiuntivo.

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

  • Il VIP del piano di controllo e il VIP in entrata sono nella stessa VLAN dei nodi worker e dei nodi del piano di controllo.

  • I VIP messi da parte per i servizi di tipo LoadBalancer vengono specificati nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente. Questi VIP sono nella stessa VLAN dei nodi worker e dei nodi del piano di controllo.

  • Il file di configurazione del cluster utente non include una sezione vCenter. Quindi il cluster utente utilizza le stesse risorse vSphere del cluster di amministrazione.

Creazione di regole firewall

Oltre alle regole firewall standard, crea le seguenti regole firewall in base alle tue esigenze:

Da

Porta di origine

To

Porta DST

Protocollo

Descrizione

Nodi del cluster di amministrazione

Tutti

VIP del piano di controllo del cluster utente

443

https

Consenti a nodi e pod nel cluster di amministrazione di comunicare con il server API Kubernetes del cluster utente.

Nodi del cluster di amministrazione

Tutti

Nodi del piano di controllo del cluster utente

443

https

Consenti a nodi e pod nel cluster di amministrazione di comunicare con il server API Kubernetes del cluster utente utilizzando l'indirizzo IP di un nodo del piano di controllo del cluster utente.

Nodi del cluster di amministrazione

Tutti

Cluster utente vCenter Server

443

https

Consenti al cluster di amministrazione di gestire il ciclo di vita del cluster utente. Obbligatorio se hai specificato un valore per vCenter.address diverso dall'indirizzo vCenter nel file di configurazione del cluster di amministrazione.

Nodi del piano di controllo del cluster utente

1024 - 65535

Registro Docker locale on-premise

Dipende dal registro

TCP/https

Obbligatorio se hai specificato un registro privato nel file di configurazione del cluster di amministrazione.

Crea un cluster utente con il nuovo modello

Questa sezione mostra come creare un cluster utente che utilizza il nuovo modello di installazione. In questo esempio, il cluster utente utilizza la stessa istanza di vCenter Server del cluster di amministrazione.

Segui le istruzioni per creare un cluster utente.

Quando compili il file di configurazione del cluster utente:

  • Imposta il valore di kubeception su false.

  • Non specificare un valore per vCenter.address.

  • Compila la sezione network.controlPlaneIPBlock. Se vuoi un cluster utente ad alta disponibilità, specifica tre indirizzi IP. Altrimenti, specifica un indirizzo IP.

Quando il cluster utente è in esecuzione, verifica che il piano di controllo sia in esecuzione su uno o tre nodi nel cluster utente:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

L'output mostra uno o tre nodi del piano di controllo insieme ai nodi worker. Ad esempio:

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Verifica che il piano di controllo per il cluster utente non sia in esecuzione nel cluster di amministrazione:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide

Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

L'output mostra un nodo del piano di controllo per il cluster di amministrazione stesso, ma non mostra i nodi del piano di controllo per il cluster utente. Ad esempio:

admin-vm-1   Ready    control-plane,master   82m
admin-vm-2   Ready                           71m
admin-vm-3   Ready                           71m

Upgrade di un cluster utente

Segui le istruzioni in Upgrade dei cluster Anthos su VMware.

Tieni presente che, quando esegui l'upgrade di un cluster utente con il nuovo modello di installazione, viene eseguito l'upgrade dell'intero cluster utente, inclusi i nodi del piano di controllo utente.

Al contrario, per i cluster utente di cui è stato eseguito il deployment con il modello kubeception, non viene eseguito l'upgrade dei nodi del piano di controllo durante l'upgrade del cluster utente e non verrà eseguito l'upgrade fino al upgrade del cluster di amministrazione.

Eliminazione di un cluster utente

Per eliminare un cluster utente:

gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER

Sostituisci USER_CLUSTER con il nome del cluster utente.

Quando elimini un cluster utente che utilizza il nuovo modello di installazione, i dischi di dati del cluster non vengono eliminati automaticamente. Devi quindi eliminare manualmente i dischi. Un cluster ad alta disponibilità ha tre dischi dati e un cluster non ad alta disponibilità ha un disco dati.

I dischi dati del cluster utente si trovano in una delle seguenti posizioni:

  • ADMIN_CLUSTER/USER_CLUSTER/

  • ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/

Sostituisci ADMIN_CLUSTER con il nome del cluster di amministrazione.

Se hai specificato una cartella nel campo vCenter.dataDisk del file di configurazione del cluster di amministrazione, sostituisci ADMIN_DISK_FOLDER con il nome della cartella.

Per un cluster non ad alta disponibilità, il disco dati è denominato USER_CLUSTER-0-data.vmdk.

Per un cluster ad alta disponibilità, i dischi di dati hanno il nome:

  • USER_CLUSTER-0-dati.vmdk
  • USER_CLUSTER-1-dati.vmdk.
  • USER_CLUSTER-2-dati.vmdk

Puoi utilizzare il client vSphere per eliminare i dischi dati.

Crea un cluster utente con il proprio vCenter Server

In alcune situazioni, è opportuno creare un cluster utente che utilizza la propria istanza di vCenter Server. Ciò significa che il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località periferica potresti avere una macchina fisica che esegue vCenter Server e una o più macchine fisiche che eseguono ESXi. Puoi quindi utilizzare l'istanza locale di vCenter Server per creare una gerarchia di oggetti vSphere, inclusi data center, cluster, pool di risorse, datastore e cartelle.

Segui le istruzioni per creare un cluster utente con il nuovo modello.

Oltre ai passaggi indicati in quella sezione, compila l'intera sezione vCenter del file di configurazione del cluster utente. In particolare, specifica un valore per vCenter.address diverso dall'indirizzo di vCenter Server specificato nel file di configurazione del cluster di amministrazione.

Esempio

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

Risolvere i problemi

Consulta Risoluzione dei problemi di creazione e upgrade del cluster.

Passaggi successivi