Upgrade versi kubelet dan versi runtime kontainer dari kelompok node - Container Service for Kubernetes

Upgrade kelompok node mencakup peningkatan versi kubelet dan runtime kontainer pada node dalam kelompok tersebut. Anda dapat memilih antara upgrade in-place dan upgrade penggantian disk sesuai kebutuhan.

Perhatian

Jika kluster telah mengaktifkan fitur Auto Scaling, untuk memastikan fungsi autoscaling tidak terganggu, kluster akan secara otomatis memperbarui Cluster Autoscaler ke versi terbaru setelah upgrade berhasil. Setelah upgrade kluster, konfirmasi apakah versi Cluster Autoscaler normal. Untuk informasi lebih lanjut, lihat Aktifkan penyesuaian otomatis node.
Setelah meng-upgrade kluster ke versi 1.18, ACK akan mengonfigurasi pemesanan sumber daya node secara default. Jika kluster belum mengonfigurasi pemesanan sumber daya dan tingkat penggunaan node (water level) tinggi, terdapat risiko Pod tidak dapat dijadwalkan dengan cepat setelah eviction selama proses upgrade. Sisihkan sebagian sumber daya untuk node, dan disarankan agar penggunaan CPU tidak melebihi 50% serta penggunaan memori tidak melebihi 70%. Untuk informasi lebih lanjut, lihat Kebijakan pemesanan sumber daya node.
Pada kluster versi 1.24 dan di bawahnya, jika Pod workload hanya mengonfigurasi startup probe, Pod tersebut akan mengalami fenomena NotReady singkat setelah kubelet direstart. Disarankan menerapkan strategi deployment multi-replika untuk mendistribusikan workload ke beberapa node guna memastikan tersedianya cukup Pod selama restart node.
Jika sebuah Pod mengakses Pod lain pada node yang sama melalui alamat SLB dari Service bertipe LoadBalancer, dan externalTrafficPolicy Service tersebut diatur ke Local, maka setelah rotasi node, kedua Pod tersebut mungkin tidak lagi berada pada node yang sama, sehingga menyebabkan ketidaktersediaan jaringan.
Citra OS kustom tidak diverifikasi secara ketat oleh ACK. ACK tidak dapat menjamin keberhasilan upgrade sepenuhnya.
Upgrade kluster memerlukan penggunaan yum untuk mengunduh paket perangkat lunak yang diperlukan. Jika Anda telah mengubah konfigurasi jaringan node atau menggunakan citra OS kustom, pastikan yum pada node dapat digunakan secara normal. Anda dapat menjalankan yum makecache untuk memeriksa.
Jika Anda telah melakukan perubahan konfigurasi pada kluster, seperti mengaktifkan partisi SWAP, mengubah konfigurasi kubelet atau konfigurasi runtime melalui operasi black screen, proses upgrade kluster mungkin gagal atau konfigurasi kustom tersebut dapat ditimpa.
Saat meng-upgrade node melalui penggantian disk, ACK akan melakukan operasi draining node, meng-evict Pod pada node tersebut ke node lain yang tersedia dengan tetap mematuhi Pod Disruption Budget (PDB). Untuk memastikan ketersediaan tinggi layanan, disarankan menerapkan strategi deployment multi-replika guna mendistribusikan workload ke beberapa node, serta mengonfigurasi PDB untuk layanan kritis guna mengontrol jumlah Pod yang terganggu secara bersamaan.

Timeout default untuk draining node adalah 30 menit. Jika migrasi Pod tidak dapat diselesaikan dalam periode timeout tersebut, ACK akan menghentikan upgrade ini untuk memastikan stabilitas bisnis.
Saat meng-upgrade node melalui penggantian disk, ACK akan menginisialisasi ulang node sesuai konfigurasi saat ini dari kelompok node (seperti metode login node, label, taint, citra OS, versi runtime). Biasanya, untuk memperbarui konfigurasi kelompok node, Anda perlu menggunakan Buat dan kelola kelompok node. Jika Anda telah melakukan perubahan pada node melalui metode lain, perubahan tersebut akan ditimpa selama upgrade.
Jika Pod pada node mereferensikan HostPath yang mengarah ke sistem disk, data dalam direktori HostPath tersebut akan hilang setelah upgrade penggantian disk.
Selama proses upgrade kelompok node, hanya operasi ekspansi yang didukung; operasi scaling tidak didukung.
Jika node tersebut merupakan node terpisah (detached node), yaitu node Worker yang tidak dikelola oleh kelompok node, Anda perlu merujuk ke Tambahkan node bebas ke kelompok node untuk menyelesaikan migrasi.
Saat meng-upgrade versi kluster ACK, kelompok node Lingjun untuk sementara tidak didukung untuk di-upgrade.

Prosedur

Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.

Pada daftar Node Pools, pilih > Kubelet Upgrade untuk kelompok node target di kolom Actions, lalu lengkapi konfigurasi sesuai isi berikut.

Item konfigurasi		Deskripsi
Kubelet upgrade information		Lihat versi Kubelet saat ini dan pilih versi upgrade yang diinginkan.
Runtime upgrade information		Lihat versi runtime saat ini dan pilih versi runtime yang diinginkan. Saat meng-upgrade dari Docker ke containerd, node dalam kelompok node akan di-upgrade melalui penggantian dan reset disk (mengganti sistem disk node). Proses upgrade akan menghapus seluruh isi pada sistem disk. Untuk informasi lebih lanjut, lihat Migrasi runtime kontainer dari Docker ke containerd. Jika versi kluster Anda adalah 1.22 dan versi containerd yang terpasang adalah 1.6.34 (relatif baru), upgrade untuk sementara tidak didukung.
Upgrade nodes		Tentukan node yang akan di-upgrade (semua node atau sebagian node).
Upgrade method		Pilih metode upgrade. Kedua opsi In-place upgrade dan Disk replacement upgrade didukung. Lihat Referensi: In-place upgrade dan disk replacement upgrade untuk memahami logika dan deskripsi proses upgrade. In-place upgrade: Setelah pemeriksaan, komponen yang diperlukan akan langsung diperbarui dan diganti pada node asli. In-place upgrade tidak akan mengganti sistem disk maupun menginisialisasi ulang node. Data pada node asli tidak terpengaruh. Disk replacement upgrade: Setelah pemeriksaan, node akan diinisialisasi ulang dengan mengganti sistem disk node. Atribut instans node tidak berubah, seperti nama node, ID instans, IP, dll., namun data pada sistem disk node akan dihapus. Disk data yang dipasang tambahan pada node tidak terpengaruh.
Ignore Warning-level Check Items		Tentukan apakah akan mengabaikan item pemeriksaan tingkat peringatan pada tingkat kelompok node dan melanjutkan upgrade. Contoh item pemeriksaan tingkat peringatan adalah adanya pod dalam kelompok node yang menggunakan HostPath yang mengarah ke sistem disk.
Batch upgrade strategy	Maximum number of nodes per batch	Proses upgrade akan meng-upgrade node secara bertahap sesuai paralelisme maksimum yang ditetapkan. Untuk deskripsi proses upgrade, lihat Referensi: In-place upgrade dan disk replacement upgrade di bawah ini.
	Automatic pause strategy	Strategi jeda selama proses upgrade node.
	Interval time between batches	Jika strategi jeda otomatis diatur untuk tidak menjeda, Anda dapat memilih apakah perlu ada interval waktu antar setiap batch upgrade atau durasi interval tersebut. Rentang pilihan adalah 5–120 menit.
	Automatic snapshot	Jika Anda memiliki data bisnis penting pada sistem disk node, Anda dapat memilih apakah akan membuat snapshot untuk node tersebut sebelum meng-upgrade kelompok node guna mencadangkan dan memulihkan data node. Penggunaan snapshot akan dikenai biaya (lihat Penagihan snapshot). Progres pembuatan akan berubah secara dinamis. Setelah upgrade selesai, jika snapshot tidak lagi diperlukan, harap segera hapus. Catatan Jika Anda memilih disk replacement upgrade sebagai metode upgrade, disarankan mengaktifkan automatic snapshot. Pembuatan snapshot akan dikenai biaya sumber daya. Untuk rincian penagihan, lihat Penagihan snapshot.

Setelah konfigurasi selesai, klik Precheck, lalu mulai operasi upgrade sesuai petunjuk halaman setelah pre-check berhasil.

Catatan
Jika eksekusi pre-check gagal atau terdapat item peringatan, silakan merujuk ke Solusi untuk item pemeriksaan yang gagal atau periksa Check Report sesuai petunjuk halaman untuk troubleshooting dan perbaikan.
Selama upgrade, Anda dapat melakukan operasi berikut sesuai petunjuk halaman.
- Pause: Status pause kluster merupakan status perantara dalam proses upgrade kelompok node. Disarankan untuk tidak melakukan operasi pada kluster selama periode ini dan segera menyelesaikan proses upgrade. Kluster dalam status perantara akan menutup proses upgrade serta membersihkan semua event dan informasi log terkait upgrade setelah 7 hari.
  
  Setelah dijeda, kubelet dan runtime kontainer pada node yang telah selesai di-upgrade tidak mendukung rollback versi.
- Cancel: Batalkan upgrade. Setelah mengklik Cancel, kubelet dan runtime kontainer pada node yang telah selesai di-upgrade tidak mendukung rollback versi.
Setelah upgrade selesai, Anda dapat mengklik nama node pada halaman Nodes, lalu memeriksa apakah versi kubelet, versi runtime kontainer, dan informasi lainnya pada node sesuai ekspektasi di tab Basic Information.

Referensi: In-place upgrade dan disk replacement upgrade

Proses in-place upgrade dan disk replacement upgrade

Proses in-place upgrade dan disk replacement upgrade adalah sebagai berikut. Selama proses upgrade kelompok node, node akan di-upgrade secara bertahap sesuai paralelisme maksimum yang ditetapkan. Jumlah node yang di-upgrade dalam setiap batch adalah 1, 2, 4, 8... hingga mencapai paralelisme maksimum. Setelah mencapai paralelisme maksimum, setiap batch selanjutnya akan meng-upgrade node sesuai jumlah paralelisme maksimum tersebut. Misalnya, jika paralelisme maksimum diatur ke 4, maka jumlah node yang di-upgrade pada batch pertama adalah 1, batch kedua adalah 2, batch ketiga adalah 4, dan setiap batch berikutnya juga akan meng-upgrade 4 node.

Gambar berikut mengilustrasikan proses eksekusi batch dengan paralelisme maksimum = N, yaitu jumlah node yang di-upgrade dalam setiap batch adalah 1, 2, 4, 8... hingga mencapai paralelisme maksimum N.

Logika in-place upgrade dalam satu node

Lakukan pemeriksaan pra-upgrade. Jika kontainer memiliki exception kritis (seperti ketidakmampuan melayani permintaan ttrpc secara normal, proses dalam kontainer tidak dapat merespons sinyal secara normal, dll.), upgrade akan dihentikan.
Simpan status kontainer dan Pod saat ini ke direktori tmp sementara.
Upgrade containerd, crictl, dan file konfigurasi terkait ke versi baru yang disediakan oleh ACK, lalu restart containerd (perilaku ini tidak akan memengaruhi kontainer yang sedang berjalan). Jika sebelumnya Anda telah mengubah konfigurasi /etc/containerd/config.toml pada node, upgrade ini akan menimpa modifikasi Anda.
Pastikan kubelet berjalan normal dan node siap (ready).

Logika disk replacement upgrade dalam satu node

Lakukan draining node (jika node dapat dijadwalkan, sistem akan mengaturnya menjadi tidak dapat dijadwalkan).
Matikan ECS, yaitu hentikan node tersebut.
Ganti sistem disk. ID sistem disk akan berubah, tetapi tipe cloud disk, alamat IP instans, dan alamat MAC kartu jaringan elastis tetap tidak berubah.
Inisialisasi ulang node.
Nyalakan ulang node dan node siap (ready) (sekaligus atur node menjadi dapat dijadwalkan).

Jika node sebelumnya telah diatur menjadi tidak dapat dijadwalkan sebelum draining dilakukan, node tersebut tidak akan otomatis kembali ke status dapat dijadwalkan setelah upgrade penggantian disk selesai.

FAQ

Apakah upgrade kelompok node mendukung rollback versi?

Baik kubelet maupun runtime kontainer tidak mendukung rollback versi setelah upgrade. Sistem operasi mendukung rollback versi setelah upgrade, tetapi Anda perlu memastikan bahwa citra asli masih didukung oleh kelompok node.

Apakah layanan akan terpengaruh selama proses upgrade?

In-place upgrade: Pod tidak akan direstart dan layanan tidak terpengaruh.

Disk replacement upgrade: Selama upgrade penggantian disk, draining node akan dilakukan. Jika Pod menerapkan logika graceful exit (Graceful shutdown and zero downtime deployments in Kubernetes) dan dideploy dalam replika ganda di beberapa node, layanan tidak akan terganggu. Untuk menghindari banyak replika aplikasi yang sama di-upgrade dalam satu batch, Anda dapat menyesuaikan paralelisme secara manual agar kurang dari jumlah replika Pod.

Berapa lama perkiraan waktu upgrade setiap batch?

In-place upgrade: Dalam waktu 5 menit

Disk replacement upgrade: Umumnya dalam waktu 8 menit tanpa melibatkan snapshot. Jika snapshot dipilih selama upgrade, upgrade akan dieksekusi setelah pembuatan snapshot selesai. Waktu eksekusi bergantung pada durasi pembuatan snapshot. Upgrade kelompok node mentoleransi snapshot hingga 40 menit. Jika snapshot belum selesai dalam 40 menit, upgrade node akan dianggap gagal karena timeout. Node yang gagal belum memulai operasi upgrade pada titik tersebut. Jika Anda tidak menyimpan data bisnis di sistem disk, Anda dapat membatalkan pemilihan snapshot untuk menghindari waktu upgrade yang berkepanjangan.

Apakah data node akan hilang selama proses upgrade node?

Saat melakukan upgrade runtime node dengan mengganti sistem disk node, jangan simpan data penting di sistem disk atau siapkan cadangan terlebih dahulu. Disk data tidak terpengaruh selama proses upgrade.

Setelah node mengganti sistem disk, apakah alamat IP node berubah?

Dalam metode penggantian disk, ID sistem disk akan berubah, tetapi tipe cloud disk, alamat IP instans, dan alamat MAC kartu jaringan elastis tetap tidak berubah. Untuk informasi lebih lanjut, lihat Ganti sistem disk (sistem operasi).

Bagaimana cara meng-upgrade node kluster yang tidak termasuk dalam kelompok node mana pun?

Pada kluster lama yang dibuat sebelum fitur kelompok node diluncurkan, terdapat node terpisah (detached node) yang tidak termasuk dalam kelompok node mana pun. Anda dapat memigrasikan node terpisah tersebut ke kelompok node, lalu meng-upgrade kelompok node tersebut. Untuk cara memigrasikan node terpisah ke kelompok node, lihat Tambahkan node bebas ke kelompok node.

Setelah runtime node beralih dari Docker ke containerd, apa yang harus dilakukan jika direktori Docker tidak dibersihkan dan masih menggunakan disk space?

Selain file kontainer, citra, dan log yang dikelola oleh kluster Kubernetes, direktori Docker juga berisi jalur file yang Anda buat sendiri. Jika tidak diperlukan, harap hapus manual direktori Docker pada disk data setelah pergantian runtime.

Bagaimana cara memulihkan data berdasarkan snapshot?

Upgrade kelompok node mendukung pembuatan snapshot untuk node. Snapshot akan disimpan selama 7 hari secara default, dan Anda juga dapat membersihkan snapshot tersebut secara manual lebih awal. Dalam skenario ekstrem, seperti menemukan kehilangan data setelah upgrade, Anda dapat memulihkan data melalui metode berikut.

Jika menggunakan in-place upgrade, misalnya hanya meng-upgrade versi kubelet, Anda dapat memulihkan data dengan langsung melakukan rollback snapshot. Lihat Rollback disk menggunakan snapshot.
Jika menggunakan disk replacement upgrade, misalnya meng-upgrade sistem operasi atau runtime kontainer, Anda dapat memulihkan data dengan membuat cloud disk melalui snapshot. Lihat Buat disk data dari snapshot.

Dokumentasi terkait

Anda juga dapat mengaktifkan fungsi auto upgrade kluster untuk mengurangi tekanan operasi dan pemeliharaan versi. Lihat Upgrade kluster secara otomatis.
Untuk changelog containerd, lihat Catatan rilis runtime containerd.
Kelompok node terkelola ACK menyediakan fungsi perbaikan kerentanan CVE otomatis untuk sistem operasi. Lihat Patch otomatis kerentanan CVE OS (disarankan).
Kubernetes 1.24 tidak lagi mendukung penggunaan Docker sebagai runtime kontainer bawaan. Harap migrasikan runtime kontainer node dari Docker ke containerd. Lihat Migrasi runtime kontainer dari Docker ke containerd.

Alat command line Docker dan containerd berbeda. Untuk perbandingan perintah umum, lihat Perbandingan perintah umum yang disediakan oleh Docker Engine dan containerd.
Disarankan untuk memperbarui versi citra OS secara berkala. Lihat Ubah sistem operasi.