Questo argomento spiega come elencare le versioni di Kubernetes disponibili e distribuire un cluster del carico di lavoro con una versione di Kubernetes non predefinita.
Ogni versione di Tanzu Kubernetes Grid con un cluster di gestione autonomo fornisce una versione predefinita e due versioni non predefinite di Kubernetes, che è possibile recuperare eseguendo tanzu kubernetes-release get
.
Tanzu Kubernetes Grid gestisce le versioni di Kubernetes con oggetti versione Tanzu Kubernetes (TKr). Un TKr specifica le immagini del sistema operativo, i componenti core di Kubernetes e i pacchetti di bootstrap compatibili con la versione di Kubernetes definita nel TKr. Quando si esegue tanzu cluster create
con un TKr predefinito o non predefinito, Tanzu Kubernetes Grid utilizza i componenti e i pacchetti di bootstrap specificati nel TKr per creare il cluster. Legge inoltre il file di configurazione del cluster per stabilire quale delle immagini del sistema operativo compatibili utilizzare durante la creazione del cluster.
Per un elenco completo delle versioni di Kubernetes supportate, vedere Versioni di Kubernetes supportate in Tanzu Kubernetes Grid v2.3 nelle Note di rilascio di VMware Tanzu Kubernetes Grid 2.3.
Per recuperare l'elenco di tutte le versioni di Kubernetes disponibili con la compatibilità corrente e lo stato di aggiornamento, eseguire tanzu kubernetes-release get
con un argomento di corrispondenza della versione facoltativo, ad esempio:
tanzu kubernetes-release get
.v1.24.17
, eseguire tanzu kubernetes-release get v1.24.17
.tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.24.17---vmware.1-tkg.1 v1.24.17+vmware.1-tkg.1 True True
v1.25.13---vmware.1-tkg.1 v1.25.13+vmware.1-tkg.1 True True
v1.26.8---vmware.2-tkg.1 v1.26.8+vmware.1-tkg.1 True True
Per scoprire le versioni di TKr disponibili per uno specifico cluster del carico di lavoro, eseguire tanzu cluster available-upgrades get
con il nome completo del cluster, ad esempio:
tanzu cluster available-upgrades get my-cluster
È possibile attivare o disattivare un TKr. Per attivare un TKr:
tanzu kubernetes-release activate TKR-NAME
Ad esempio:
tanzu kubernetes-release activate v1.25.13---vmware.1-tkg.1
Per disattivare un TKr:
tanzu kubernetes-release deactivate TKR-NAME
Ad esempio:
tanzu kubernetes-release deactivate v1.25.13---vmware.1-tkg.1
Ogni versione di Tanzu Kubernetes Grid fornisce una versione predefinita di Kubernetes. La versione predefinita per Tanzu Kubernetes Grid v2.3 Kubernetes v1.26.8.
Quando Kubernetes upstream rilascia patch o nuove versioni, VMware le pubblica in un registro pubblico e il controller di versione Tanzu Kubernetes le importa nel cluster di gestione. In questo modo, la CLI di tanzu
crea cluster in base alle nuove versioni.
In vSphere e Azure, è necessario eseguire un passaggio aggiuntivo prima di poter distribuire cluster che eseguono versioni non predefinite di Kubernetes:
vSphere: Importare il relativo file OVA del modello di immagine di base in vSphere e convertirlo in un modello di macchina virtuale. Per informazioni sull'importazione dei file OVA di base in vSphere, vedere Importazione del modello immagine di base in vSphere.
Azure: Eseguire la CLI di Azure per accettare la licenza per la versione del sistema operativo di base. Dopo aver accettato una licenza, è possibile ignorare questo passaggio in futuro:
tanzu kubernetes-release get
nella SKU dell'immagine di Azure come indicato di seguito:
v
iniziale in k8s-
..
in dot
nel numero di versione.+vmware.*
finale in -ubuntu-2004
per designare Ubuntu v20.04, la versione predefinita del sistema operativo per tutte le macchine virtuali Tanzu Kubernetes Grid in Azure.k8s-1dot26dot8-ubuntu-2004
, k8s-1dot25dot13-ubuntu-2004
.eseguire az vm image terms accept
. Ad esempio:
az vm image terms accept --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot26dot8-ubuntu-2004
Amazon Web Services (AWS): Non è richiesta alcuna azione. Le immagini macchina Amazon (AMI) Amazon Linux 2 che includono le versioni di Kubernetes supportate sono disponibili pubblicamente per tutti gli utenti di AWS, in tutte le regioni di AWS supportate. Tanzu Kubernetes Grid utilizza automaticamente l'AMI appropriata per la versione di Kubernetes specificata.
Per distribuire il cluster del carico di lavoro che esegue una versione di Kubernetes non predefinita:
Se si distribuisce un cluster basato su un piano, impostare una variabile di ambiente ALLOW_LEGACY_CLUSTER
su true
:
export ALLOW_LEGACY_CLUSTER=true
Se la versione della patch Kubernetes con cui si sta distribuendo il cluster è precedente all'ultima patch supportata per la sua versione secondaria, come indicato in Versioni di Kubernetes supportate, creare un oggetto ConfigMap
per il relativo TKr nello spazio dei nomi tkg-system
:
Creare una definizione di oggetto ConfigMap
nello spazio dei nomi tkg-system
in cui siano elencati i TKR precedenti:
apiVersion: v1
kind: ConfigMap
metadata:
namespace: tkg-system
name: TKR-CONFIG-NAME
labels:
run.tanzu.vmware.com/additional-compatible-tkrs: ""
data:
tkrVersions: |
- TKR-VERSON-1
- TKR-VERSON-2
Dove TKR-CONFIG-NAME
è un nome oggetto legale, ad esempio tkg-v2.3.1
, e i valori TKR-VERSON-*
sono le versioni precedenti di TKr elencate in tanzu kubernetes-release get
, ad esempio v1.24.14--vmware.1-tkg
.
Creare l'oggetto ConfigMap
:
kubectl apply -f old-tkrs-config.yaml
Per distribuire un cluster del carico di lavoro con una versione di Kubernetes che non sia quella predefinita per la versione di Tanzu Kubernetes Grid, specificare la versione Tanzu Kubernetes nell'opzione --tkr
. Ad esempio, per distribuire un cluster Kubernetes v1.25.13, eseguire:
tanzu cluster create my-1-25-13-cluster --tkr v1.25.13---vmware.1-tkg
Per ulteriori dettagli su come creare un cluster del carico di lavoro, vedere Creazione di cluster del carico di lavoro.
Per le combinazioni comuni di versione del sistema operativo, versione di Kubernetes e infrastruttura di destinazione, Tanzu Kubernetes Grid con un cluster di gestione autonomo fornisce immagini di macchine predefinite. Facoltativamente, è possibile specificare immagini di macchine personalizzate, incluse le immagini create dall'utente.
Le sezioni seguenti spiegano come distribuire un cluster con un'immagine di macchina alternativa o personalizzata:
In un file di configurazione del cluster vengono impostati OS_NAME
, OS_VERSION
e OS_ARCH
per specificare l'immagine della macchina di base, ad esempio ubuntu
, 20.04
o photon
, 3
e amd64
. Per impostazione predefinita, si utilizzano le immagini del sistema operativo distribuite da VMware, ma è anche possibile specificare l'immagine del sistema operativo alternativa da utilizzare per i nodi del cluster:
Caricare l'immagine da vSphere come descritto in Importazione del modello di immagine di base in vSphere.
Eseguire una delle seguenti operazioni, a seconda che l'immagine condivida la stessa versione del sistema operativo di un'immagine della macchina esistente distribuita da VMware:
Se si specifica un'immagine alternativa con il nome, la versione e l'architettura del sistema operativo di un TKr esistente e di un'immagine distribuita da VMware, modificarne l'oggetto OSImage
, ad esempio:
kubectl edit OSImage v1.26.4---vmware.1-tkg.1-6c92aa1cbb96b644085e6229f41ef14d
In caso contrario, creare e applicare un nuovo oggetto OSImage
utilizzando come modello una definizione di oggetto OSImage
esistente. Impostare i valori metadata.name
e spec.image.ref.version
sul nome del file OVA.
Nel blocco spec.image.ref
dell'oggetto OSImage
, aggiungere un campo e un valore dell'identificatore. Ad esempio, per abilitare un'alternativa a Kubernetes v1.26.4 nell’immagine Ubuntu 20.04 distribuita da VMware:
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
creationTimestamp: "2023-06-02T06:08:35Z"
generation: 2
labels:
image-type: ova
os-arch: amd64
os-name: ubuntu
os-type: linux
...
spec:
image:
ref:
MY-FIELD: MY-VALUE
version: v1.26.4---vmware.1-tkg.1-6c92aa1cbb96b644085e6229f41ef14d
type: ova
kubernetesVersion: v1.26.4+vmware.1
os:
arch: amd64
name: ubuntu
type: linux
version: "2004"
Dove MY-FIELD
e MY-VALUE
sono il campo dell'identificatore e il valore impostato da includere nelle specifiche dell'oggetto Cluster
.
MY-VALUE
deve essere lungo 0-63 caratteri e può essere vuoto. In caso contrario, deve iniziare e terminare con caratteri alfanumerici e contenere caratteri alfanumerici, trattini (-
), caratteri di sottolineatura (_
) o punti (.
).metadata.labels
dell'oggetto OSImage
seguendo il modello ova-MY-FIELD: MY-VALUE
.Per utilizzare l'immagine della macchina alternativa in un cluster, modificare l'oggetto Cluster
per aggiungere l'impostazione ova-MY-FIELD=MY-VALUE
a metadata.annotations
per i nodi del cluster che utilizzeranno l'immagine.
metadata.annotations
in topology.controlPlane
.metadata.annotations
in topology.workers.machineDeployments
per le distribuzioni delle macchine che utilizzeranno l'immagine.Ad esempio:
metadata:
annotations:
run.tanzu.vmware.com/resolve-os-image: image-type=ova,ova-my-field=my-value
È possibile creare la propria immagine della macchina da utilizzare per i nodi del cluster. I motivi per eseguire questa operazione includono:
Per istruzioni, vedere Creazione di immagini di macchine.