Crea un cluster utente con Controlplane V2

Questo documento mostra come creare un cluster utente con Controlplane V2 abilitato.

Che cos'è kubeception?

Il termine kubeception è utilizzato per trasmettere l'idea che un cluster Kubernetes viene utilizzato per creare e gestire altri cluster Kubernetes. Nel contesto di GKE 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.

Con Controlplane V2, il piano di controllo per un cluster utente viene eseguito su uno o più nodi nel cluster utente stesso.

I vantaggi di Controlplane V2 includono:

  • Coerenza dell'architettura tra cluster di amministrazione e cluster utente

  • Isolamento degli errori. Un errore del cluster di amministrazione non influisce sui cluster utente.

  • Separazione operativa. Un upgrade del cluster di amministrazione non causa tempi di inattività per i cluster utente.

  • Separazione dei deployment. Puoi posizionare i cluster di amministrazione e utente in domini di errore o siti geografici diversi. Ad esempio, un cluster utente in una località perimetrale potrebbe trovarsi in un sito geografico diverso da quello del cluster di amministrazione.

Prima di iniziare

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

Requisiti

Un cluster utente con Controlplane V2 abilitato:

  • Devi utilizzare il bilanciatore del carico MetalLB in bundle
  • Deve essere abilitato Dataplane V2

Pianifica gli indirizzi IP

Quando pianifichi gli indirizzi IP per il cluster utente, tieni presente questi requisiti per Controlplane V2:

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

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

  • Il VIP del piano di controllo del cluster utente deve trovarsi nella stessa VLAN dei nodi worker del cluster utente e dei nodi del piano di controllo del cluster utente. Questo è 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 il cluster di amministrazione o utente utilizzi.

Per un cluster utente, non è necessario compilare la sezione vCenter poiché, 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 a tua scelta nella sezione vCenter del file di configurazione del cluster utente. Per maggiori informazioni, consulta Configurare la gerarchia degli oggetti vSphere.

Con Controlplane V2, i nodi del piano di controllo per il cluster utente si trovano nel cluster utente stesso. I nodi del piano di controllo utilizzano quindi le risorse vSphere specificate nel file di configurazione del cluster utente. Ad esempio, supponi di specificare datacenter-1 per il cluster di amministrazione e datacenter-2 per il cluster utente. I nodi del piano di controllo per il cluster utente si troveranno 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.

Con Controlplane V2, 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

Ecco un esempio di cluster utente con le seguenti caratteristiche:

  • Ci sono tre nodi worker.

  • I nodi worker hanno indirizzi IP statici.

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

  • Il bilanciatore del carico è MetalLB.

  • Dataplane V2 e Controlplane V2 sono abilitati.

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

Il seguente diagramma illustra la rete per i cluster di amministrazione e per gli 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 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
      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
...
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"
...
enableControlplaneV2: true
enableDataplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

Ecco 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 quattro indirizzi anche se ci sono solo tre nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade, l'aggiornamento e la riparazione automatica del cluster.

  • I server DNS e NTP sono specificati nella sezione hostConfig. In questo esempio, questi server DNS e NTP sono destinati ai nodi del piano di controllo e ai nodi worker. Questo perché i nodi worker hanno indirizzi IP statici. Se i nodi worker dovessero ottenere i propri indirizzi IP da un server DHCP, questi server DNS e NTP sarebbero solo per i nodi del piano di controllo.

  • 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 entrambi nella stessa VLAN dei nodi worker e del piano di controllo.

  • I VIP riservati ai servizi di tipo LoadBalancer sono specificati nella sezione loadBalancer.metalLB.addressPools del file di configurazione del cluster utente. Questi VIP si trovano nella stessa VLAN dei nodi worker e dei nodi del piano di controllo. Il set di VIP specificato in questa sezione deve includere il VIP in entrata e non il VIP del piano di controllo.

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

Regole firewall per Controlplane V2

Oltre alle regole firewall standard, crea le seguenti regole firewall:

Da

Porta di origine

A

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 del nodo del piano di controllo di un cluster utente.

Le seguenti regole firewall standard non sono necessarie per un cluster utente in cui è abilitato Controlplane V2:

Da

Porta di origine

A

Porta Dst

Protocollo

Descrizione

Nodi worker del cluster di amministrazione

Tutti

Nodi del cluster utente

22

SSH

Comunicazione dal server API a kubelet su un tunnel SSH

Nodi worker del cluster utente

Tutti

VIP del piano di controllo del cluster utente

8132

GRPC

Connessione Konnectivity

Crea un cluster utente con Controlplane V2 abilitato

Questa sezione mostra come creare un cluster utente con Controlplane V2 abilitato. In questo esempio, il cluster utente utilizza la stessa istanza del server vCenter del cluster di amministrazione.

Segui le istruzioni in Creare un cluster utente.

Quando compili il file di configurazione del cluster utente:

  • Imposta enableControlplaneV2 su true.

  • Imposta enableDataplaneV2 su true.

  • Imposta loadBalancer.kind su "MetalLB"

  • 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 solo 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, ma non 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

Verifica che non ci siano pod in esecuzione nel cluster di amministrazione nello spazio dei nomi USER_CLUSTER_NAME. Questo è in contrasto con il modello kubeception, in cui sarebbero in esecuzione diversi pod del piano di controllo nello spazio dei nomi USER_CLUSTER_NAME del cluster di amministrazione:

kubectl --kubeconfig kubeconfig get pods --namespace USER_CLUSTER_NAME

Output:

No resources found in ... namespace.

Verifica che siano presenti pod del piano di controllo in esecuzione nel cluster utente:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods\
    --namespace kube-system\
    --selector tier=control-plane

Output di esempio:

clusterapi-controllers-5bbfb6bd9f-57gz8   3/3     Running   1
…
etcd-cp-vm-1                              1/1     Running   0
…
kube-apiserver-cp-vm-1                    1/1     Running   0
…
kube-controller-manager-cp-vm-1           1/1     Running   0
…
kube-scheduler-cp-vm-1                    1/1     Running   0

Connessioni SSH ai nodi

Con Controlplane V2, per ottenere una connessione SSH a un nodo del piano di controllo del cluster utente, utilizza la stessa chiave SSH che utilizzi per connetterti ai nodi worker del cluster utente.

A differenza di un cluster utente kubeception, in cui useresti la stessa chiave SSH che utilizzi per connetterti ai nodi worker del cluster di amministrazione.

Esegui l'upgrade di un cluster utente

Segui le istruzioni in Upgrade di Anthos clusters on VMware.

Tieni presente che quando esegui l'upgrade di un cluster utente in cui è abilitato Controlplane V2, viene eseguito l'upgrade dell'intero cluster utente, inclusi i nodi del piano di controllo dell'utente.

Al contrario, per i cluster utente di cui è stato eseguito il deployment con il modello kubeception, i nodi del piano di controllo non vengono aggiornati durante l'upgrade dei cluster utente e non fino all'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 in cui è abilitato Controlplane V2, i dischi dati del cluster non vengono eliminati automaticamente. quindi i dischi dati devono essere eliminati manualmente. Un cluster ad alta disponibilità ha tre dischi dati, mentre un cluster non ad alta disponibilità ha un disco dati.

I dischi dati per i nodi del piano di controllo del cluster utente si trovano nel datastore specificato nel campo masterNode.vSphere.datastore del file di configurazione del cluster utente.

I dischi dati per il 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 dati sono denominati:

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

Puoi utilizzare il client vSphere per eliminare i dischi di dati.

Crea un cluster utente con il proprio vCenter Server

In determinate situazioni, ha senso creare un cluster utente che utilizza la propria istanza di vCenter Server. In altre parole, il cluster di amministrazione e un cluster utente associato utilizzano istanze diverse di vCenter Server.

Ad esempio, in una località perimetrale, potresti voler 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 degli oggetti vSphere, che includa data center, cluster, pool di risorse, datastore e cartelle.

Segui le istruzioni in Creare un cluster utente con Controlplane V2 abilitato.

Oltre ai passaggi descritti in questa 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"

Regole del firewall

Oltre alle regole firewall standard e alle regole firewall richieste per Controlplane V2 in generale, crea la seguente regola firewall se il tuo cluster utente ha un proprio vCenter Server:

Da

Porta di origine

A

Porta Dst

Protocollo

Descrizione

Nodi del cluster di amministrazione

Tutti

Server vCenter del cluster utente

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.

Risoluzione dei problemi

Vedi Risolvere i problemi relativi alla creazione e all'upgrade dei cluster.

Passaggi successivi