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:
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 su3
.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
sutrue
.Imposta
enableDataplaneV2
sutrue
.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.