Penomoran versi GKE pada Azure

Halaman ini menjelaskan penomoran versi GKE di Azure Kubernetes.

Versi cluster

Saat membuat cluster atau node pool, Anda harus menentukan versi Kubernetes yang ingin dijalankan. Anda hanya dapat membuat cluster atau kumpulan node baru dengan versi Kubernetes yang didukung.

Skema dan ritme versi

GKE di Azure menggunakan pembuatan versi semantik Kubernetes untuk merujuk ke versi Kubernetes yang didukung, tetapi menambahkan versi patch GKE. Ini menghasilkan nomor versi dari

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

Misalnya, versi Kubernetes terbaru yang didukung adalah 1.29.3-gke.600.

Versi utama Kubernetes (x)
Versi utama akan bertambah saat perubahan diperkenalkan ke API publik yang perilaku atau operasinya tidak kompatibel dengan versi sebelumnya. Versi utama menaikkan versi Kubernetes dari x.y menjadi x+1.0.
Versi minor Kubernetes (y)
Kubernetes merilis versi minor baru sekitar setiap empat bulan. Versi minor menambahkan versi Kubernetes dari 1.y menjadi 1.y+1; misalnya, Kubernetes 1.21 adalah rilis minor yang mengikuti Kubernetes 1.20. Upgrade versi minor umumnya melibatkan fungsi baru dan perbaikan bug, tetapi tidak menerapkan perubahan yang dapat menyebabkan gangguan. Terkadang, fitur atau komponen API tidak digunakan lagi dalam rilis versi minor.
Rilis patch Kubernetes (z)
Rilis patch Kubernetes baru (seperti 1.21.1) untuk digunakan dengan GKE di Azure biasanya dirilis sebulan sekali. Rilis patch hanya menyertakan perbaikan keamanan dan bug.
Rilis patch GKE (-gke.a)
Rilis patch dengan akhiran -gke.a yang lebih tinggi (seperti 1.24.1-gke.a) menyertakan update keamanan dan/atau perbaikan bug untuk GKE di Azure bersama dengan software Kubernetes upstream open source. Update atau perbaikan ini diperlukan untuk kompatibilitas dan interoperabilitas dengan Google Cloud dan Azure.

Dukungan untuk versi

Untuk kebijakan pembuatan versi di seluruh GKE Enterprise, lihat Kebijakan Dukungan Versi.

Kemiringan versi

Versi node dan kumpulan node dapat mencapai dua versi minor yang lebih lama daripada bidang kontrol, tetapi, sesuai dengan kebijakan condong versi Kubernetes OSS, tidak boleh lebih baru daripada versi bidang kontrol. Sebaiknya node Anda selalu menggunakan versi yang didukung, terlepas dari pedoman kemiringan versi.

Langkah selanjutnya