Siklus Hidup Kluster

Kluster Kubernetes merilis versi minor baru sekitar tiga kali setahun, sehingga peningkatan versi menjadi pekerjaan rutin operasi dan bukan proyek besar yang sekali jalan. Topik ini membahas ritme peningkatan versi minor, kebijakan version skew yang menentukan seberapa jauh komponen boleh berbeda versi, serta trade-off antara kluster managed dan self-hosted dari sisi beban operasi. Setelah membacanya, jadwal peningkatan sebuah kluster dapat disusun dengan batasan yang benar.

Ritme peningkatan versi minor#

Kubernetes menomori rilisnya sebagai versi minor seperti 1.31 dan 1.32, dengan angka patch seperti 1.32.2 di dalam versi minor yang sama. Rilis versi minor dapat membawa perubahan pada API dan perilaku komponen, sedangkan rilis patch hanya memuat perbaikan. Karena itu peningkatan versi minor dilakukan satu langkah pada satu waktu, misalnya 1.31 ke 1.32 lalu ke 1.33, tanpa melompati versi. Kelompok komponen ditingkatkan dalam urutan yang lazim berbunyi: control plane terlebih dahulu, kemudian Node satu per satu dengan proses drain agar Pod dipindahkan dengan tertib.

Selama urutan itu berjalan, komponen berbeda berada pada versi yang berbeda pula, dan kondisi tersebut diperkirakan oleh proyek Kubernetes selama batasnya tidak dilampaui. Batas inilah yang ditetapkan kebijakan version skew pada bagian berikutnya.

Kebijakan version skew#

Version skew adalah perbedaan versi antarkomponen yang masih diizinkan agar kluster tetap berfungsi. Aturan yang paling sering relevan sehari-hari berbunyi: kubelet boleh tertinggal maksimal dua versi minor dari API server dan tidak boleh lebih baru. Dengan API server 1.32, kubelet yang didukung berada di versi 1.32, 1.31, dan 1.30. Pada kluster dengan beberapa instance API server, jarak antarinstance tidak boleh lebih dari satu versi minor, sedangkan komponen seperti kube-proxy tidak boleh lebih baru dari API server yang dilayainya.

Kebijakan ini menentukan urutan kerja pada peningkatan. Sebelum control plane naik satu versi minor, kubelet di semua Node harus sudah berada paling jauh dua versi di bawah versi baru, agar tidak ada Node yang keluar dari batas setelah kenaikan. Setelah control plane naik, Node diperbarui satu per satu sebelum jarak versi mencapai tiga. Pemeriksaan jarak ini cukup sederhana untuk dihitung dari data versi komponen, sebagaimana dipraktikkan pada bagian berikutnya.

Memeriksa jarak versi antarkomponen#

Data versi komponen tersedia melalui perintah seperti kubectl get nodes, yang menampilkan versi kubelet tiap Node. Berkas berikut berisi salinan ringkas data tersebut untuk satu kluster contoh berisi tiga Node, ditulis sebelum control plane dinaikkan.

{
  "kluster": "lab-catatan",
  "api_server": "1.32",
  "node": [
    {
      "nama": "node-01",
      "kubelet": "1.31"
    },
    {
      "nama": "node-02",
      "kubelet": "1.30"
    },
    {
      "nama": "node-03",
      "kubelet": "1.29"
    }
  ]
}

Skrip berikut memeriksa setiap Node terhadap batas dua versi minor, lalu menilai dampak kenaikan satu langkah pada control plane.

import json

# membaca status versi komponen kluster dari berkas versi-kluster.json
data = json.load(open("versi-kluster.json", encoding="utf-8"))
api = data["api_server"]
api_minor = int(api.split(".")[1])
BATAS = 2  # kubelet boleh tertinggal maksimal dua versi minor dari API server

print(f"Kluster {data['kluster']}: API server {api}")
for node in data["node"]:
    minor = int(node["kubelet"].split(".")[1])
    selisih = api_minor - minor
    if selisih < 0:
        status = "LEBIH BARU DARI API SERVER, TIDAK DIIZINKAN"
    elif selisih > BATAS:
        status = "MELEWATI BATAS"
    else:
        status = "AMAN"
    print(f"{node['nama']}: kubelet {node['kubelet']} (selisih {selisih} versi minor) {status}")

# menilai dampak peningkatan satu langkah pada control plane
print(f"Peningkatan API server ke 1.{api_minor + 1} menaikkan batas kubelet terendah menjadi 1.{api_minor + 1 - BATAS}")

Kluster lab-catatan: API server 1.32
node-01: kubelet 1.31 (selisih 1 versi minor) AMAN
node-02: kubelet 1.30 (selisih 2 versi minor) AMAN
node-03: kubelet 1.29 (selisih 3 versi minor) MELEWATI BATAS
Peningkatan API server ke 1.33 menaikkan batas kubelet terendah menjadi 1.31

Keluaran menunjukkan node-03 sudah berada di luar batas sebelum peningkatan apa pun, sehingga pekerjaan pertama berbunyi: naikkan kubelet node-03 paling rendah ke 1.30, dan paling aman ke 1.31. Setelah ketiga Node memenuhi batas, control plane barulah dinaikkan ke 1.33 satu langkah tanpa melompat.

Trade-off managed versus self-hosted#

Kluster managed berarti penyedia mengoperasikan control plane dan menyediakan peningkatan versi sebagai layanan, sedangkan kluster self-hosted berarti seluruh komponen termasuk control plane dioperasikan sendiri di atas infrastruktur sendiri. Keduanya memenuhi kebutuhan yang berbeda, dan pilihannya menentukan siapa yang mengerjakan setiap langkah peningkatan versi.

Tabel tersebut menunjukkan trade-off yang jelas. Managed memindahkan beban peningkatan dan pemulihan ke penyedia dengan biaya langganan, sedangkan self-hosted memberikan kendali penuh dengan konsekuensi waktu tim untuk setiap langkah kecil. Kebijakan version skew tetap relevan pada keduanya, karena kubelet pada Node pekerja tetap harus mengikuti batas versi yang sama di mana pun control plane dijalankan.

Praktik peningkatan yang aman#

Peningkatan yang aman dimulai jauh sebelum perintah peningkatan dijalankan. Pengumuman rilis dibaca untuk menemukan API yang dihapus pada versi tujuan, manifest yang menggunakan API tersebut diperbaiki lebih dahulu, dan seluruh alur diuji pada kluster staging yang mirip dengan produksi. Cadangan etcd diambil sebelum control plane disentuh, sehingga kegagalan tetap memiliki jalur pemulihan.

Proses pada Node berjalan satu per satu. Node dikosongkan dengan drain, ditingkatkan, dikembalikan, dan beban kerja diverifikasi sebelum Node berikutnya disentuh. Setelah seluruh Node selesai, versi kubelet diperiksa kembali terhadap kebijakan version skew.

# tidak-dijalankan
# mengosongkan Node sebelum peningkatan agar Pod dipindahkan dengan tertib
kubectl drain node-01 --ignore-daemonsets
# memeriksa versi kubelet tiap Node setelah proses peningkatan
kubectl get nodes -o wide

NAME      STATUS   ROLES           AGE   VERSION   INTERNAL-IP
node-01   Ready    control-plane   90d   v1.32.2   192.168.49.2
node-02   Ready    <none>          90d   v1.31.4   192.168.49.3
node-03   Ready    <none>          90d   v1.31.4   192.168.49.4

Keluaran di atas menampilkan kolom VERSION yang memuat versi kubelet, sehingga jarak versi terhadap API server terbaca langsung dari daftar Node.

Ringkasan#

• Rilis minor Kubernetes muncul sekitar tiga kali setahun dan peningkatan dilakukan satu versi minor pada setiap langkah, dimulai dari control plane lalu Node satu per satu.
• Kebijakan version skew mengizinkan kubelet tertinggal maksimal dua versi minor dari API server dan melarang kubelet yang lebih baru.
• Pemeriksaan jarak versi berupa pengurangan sederhana nomor minor yang dapat dihitung dari data kubectl get nodes.
• Kluster managed memindahkan beban peningkatan ke penyedia dengan biaya langganan, sedangkan self-hosted memberi kendali penuh dengan beban operasi yang ditanggung sendiri.

Referensi#

• Version Skew Policy — Kubernetes — Kebijakan resmi jarak versi yang diizinkan antarkomponen Kubernetes.
• Release History — Kubernetes — Riwayat rilis Kubernetes beserta ritme versi minor dan patch.