Numerazione delle versioni di GKE su Azure

Questa pagina descrive la numerazione delle versioni di GKE su Azure Kubernetes.

Versioni cluster

Quando crei un cluster o un pool di nodi, devi specificare la versione di Kubernetes che vuoi che esegua. Puoi creare nuovi cluster o pool di nodi solo con una versione di Kubernetes supportata.

Schema della versione e cadenza

GKE su Azure utilizza il controllo delle versioni semantico di Kubernetes per fare riferimento alle versioni di Kubernetes supportate, ma aggiunge una versione patch di GKE. Viene restituito un numero di versione del modulo

  <code>x.y.z-gke.a</code>

Ad esempio, la versione di Kubernetes supportata più di recente è 1.29.3-gke.600.

Versione principale di Kubernetes (x)
Le versioni principali vengono incrementate quando viene apportata una modifica all'API pubblica il cui comportamento o operazione non è compatibile con la versione precedente. Una versione principale incrementa la versione di Kubernetes da x.y a x+1.0.
Versione secondaria di Kubernetes (y)
Kubernetes rilascia una nuova versione secondaria circa ogni quattro mesi. Una versione secondaria incrementa la versione di Kubernetes da 1.y a 1.y+1; ad esempio, Kubernetes 1.21 è la release secondaria successiva a Kubernetes 1.20. Gli upgrade delle versioni di minore entità in genere comportano nuove funzionalità e correzioni di bug, ma non introducono modifiche che provocano errori. A volte, una funzionalità o un componente API viene deprecato in una versione secondaria.
Release patch Kubernetes (z)
Le nuove release delle patch di Kubernetes (ad esempio 1.21.1) da utilizzare con GKE su Azure vengono rilasciate normalmente una volta al mese. Le release delle patch includono solo correzioni di bug e di sicurezza.
Release patch GKE (-gke.a)
Una release patch con suffisso -gke.a più alto (ad esempio 1.24.1-gke.a) include aggiornamenti della sicurezza e/o correzioni di bug per GKE su Azure insieme al software Kubernetes open source upstream. Questi aggiornamenti o correzioni sono necessari per la compatibilità e l'interoperabilità con Google Cloud e Azure.

Supporto per le versioni

Per il criterio di controllo delle versioni a livello di GKE Enterprise, vedi Criterio per il supporto delle versioni.

Disallineamento delle versioni

Le versioni dei nodi e del pool di nodi possono essere fino a due versioni secondarie precedenti al piano di controllo, ma, in conformità con i criteri di disallineamento delle versioni di Kubernetes OSS, non possono essere più recenti della versione del piano di controllo. Consigliamo vivamente di utilizzare sempre una versione supportata per i nodi, indipendentemente dalle linee guida per il disallineamento delle versioni.

Passaggi successivi