Perbarui kelompok node - Container Service for Kubernetes

Saat memperbarui versi Kubernetes kluster, perbarui lapisan kontrol terlebih dahulu, lalu perbarui kelompok node selama jam sepi. Pembaruan kelompok node mencakup pembaruan kubelet dan runtime kontainer. Sebelum memulai pembaruan, ACK melakukan pemeriksaan awal untuk mengidentifikasi dan melaporkan potensi risiko guna memastikan proses berjalan lancar.

Catatan

Penskalaan node
- Jika penskalaan node diaktifkan untuk kluster, komponen cluster-autoscaler secara otomatis diperbarui ke versi terbaru setelah pembaruan kluster. Hal ini memastikan fitur auto scaling berfungsi dengan benar. Setelah pembaruan kluster, verifikasi bahwa komponen cluster-autoscaler menjalankan versi yang benar. Untuk informasi lebih lanjut, lihat Aktifkan penskalaan otomatis node.
- Selama pembaruan kluster, node yang Scaling Mode-nya diatur ke Swift mungkin gagal diperbarui karena dimatikan. Jika node dalam mode Swift tidak diperbarui setelah pembaruan kluster selesai, kami menyarankan Anda menghapus node tersebut secara manual.
Setelah memperbarui kluster ke Kubernetes 1.18, ACK mengonfigurasi pemesanan sumber daya node secara default. Jika pemesanan sumber daya tidak dikonfigurasi dan penggunaan sumber daya node tinggi, pod mungkin gagal dijadwalkan ulang tepat waktu setelah dievakuasi. Kami menyarankan Anda memesan sumber daya untuk node Anda. Untuk kinerja optimal, utilisasi CPU tidak boleh melebihi 50% dan utilisasi memori tidak boleh melebihi 70%. Untuk informasi lebih lanjut, lihat Kebijakan pemesanan sumber daya node.
Pada kluster yang menjalankan Kubernetes 1.24 atau lebih lama, jika pod dalam workload hanya dikonfigurasi dengan startup probe, pod tersebut mungkin memasuki status NotReady untuk periode singkat setelah kubelet direstart. Kami menyarankan Anda menggunakan strategi penerapan multi-replika untuk mendistribusikan workload di beberapa node. Hal ini memastikan cukup banyak pod tetap tersedia selama restart node.
Jika pod mengakses pod lain pada node yang sama menggunakan alamat IP Instance SLB yang diekspos oleh layanan LoadBalancer, dan externalTrafficPolicy layanan diatur ke Local, kedua pod tersebut mungkin tidak lagi berada pada node yang sama setelah node diganti. Hal ini dapat menyebabkan gangguan jaringan.
Citra OS (operating system) kustom tidak divalidasi secara ketat oleh ACK. ACK tidak dapat menjamin pembaruan yang berhasil untuk kluster yang menggunakan citra OS kustom.
Selama pembaruan kluster, yum digunakan untuk mengunduh paket perangkat lunak yang diperlukan. Jika Anda telah memodifikasi konfigurasi jaringan node atau menggunakan citra OS kustom, pastikan yum berfungsi dengan benar pada node tersebut. Anda dapat menjalankan perintah yum makecache untuk memverifikasi statusnya.
Jika Anda telah membuat perubahan konfigurasi kustom pada kluster, seperti mengaktifkan partisi SWAP atau memodifikasi konfigurasi kubelet atau runtime kontainer dari command line, proses pembaruan mungkin gagal atau konfigurasi kustom Anda mungkin ditimpa.
Saat memperbarui node dengan mengganti disk sistemnya, ACK melakukan node draining. Pod dievakuasi dari node ke node lain yang tersedia sesuai dengan PodDisruptionBudget (PDB) yang dikonfigurasi. Untuk memastikan ketersediaan layanan yang tinggi, kami menyarankan Anda menggunakan strategi penerapan multi-replika untuk mendistribusikan workload di beberapa node. Anda juga harus mengonfigurasi PDB untuk layanan kritis guna mengontrol jumlah pod yang dapat terganggu secara bersamaan.
Timeout default untuk node draining adalah 30 menit. Jika migrasi pod tidak selesai dalam waktu tersebut, ACK menghentikan pembaruan untuk memastikan stabilitas layanan.
Saat memperbarui node dengan mengganti disk sistemnya, ACK menginisialisasi ulang node berdasarkan konfigurasi saat ini dari kelompok node, seperti metode login node, label, taint, citra OS, dan versi runtime kontainer. Biasanya, Anda memperbarui konfigurasi kelompok node dengan mengedit kelompok node. Jika Anda telah memodifikasi node dengan metode lain, perubahan tersebut akan ditimpa selama pembaruan.
Jika pod pada node menggunakan volume HostPath yang mengarah ke disk sistem, data dalam direktori tersebut hilang setelah pembaruan dengan mengganti disk sistem.
Selama pembaruan kelompok node, hanya operasi scale-out yang didukung. Operasi scale-in tidak didukung.
Jika node merupakan node unmanaged (node pekerja yang tidak dikelola oleh kelompok node mana pun), Anda harus terlebih dahulu memigrasikannya ke kelompok node. Untuk informasi lebih lanjut, lihat Migrasikan node unmanaged ke kelompok node.
Saat memperbarui kluster ACK, Anda tidak dapat memperbarui kelompok node Lingjun.
Saat meningkatkan kelompok node pada kluster versi 1.31 atau lebih lama, proses tersebut juga meningkatkan NVIDIA Device Plugin dan mengatur ulang semua konfigurasi non-standarnya.

Fitur

Pembaruan kelompok node mencakup pembaruan kubelet dan runtime kontainer.

Pembaruan Kubelet: Meningkatkan kubelet pada node dalam kelompok node ke versi yang sama dengan lapisan kontrol. Secara default, ACK melakukan pembaruan in-place.
Pembaruan runtime kontainer: Saat versi runtime kontainer baru dirilis, Anda dapat meningkatkan runtime kontainer pada node ke versi terbaru.
- Saat memigrasikan runtime kontainer dari Docker ke containerd, node dalam kelompok node diperbarui dengan mengganti disk sistemnya. Hal ini menghapus seluruh konten disk sistem. Sebelum memulai pembaruan, pastikan untuk melakukan backup semua data penting dari disk sistem. Untuk informasi lebih lanjut, lihat Migrasikan runtime kontainer node dari Docker ke containerd.
- Kecuali untuk node ContainerOS, ACK secara default melakukan pembaruan in-place saat Anda meningkatkan dari satu versi containerd ke versi yang lebih baru. File /etc/containerd/config.toml pada node diganti dengan versi baru yang disediakan oleh ACK.
  Penting
  - Node ContainerOS tidak mendukung pembaruan in-place untuk containerd. Anda hanya dapat memperbaruinya dengan mengganti disk sistem. Untuk prosedur peningkatan, lihat Tingkatkan versi ContainerOS yang lebih lama dari 3.4 ke versi terbaru.
  - Selama pembaruan runtime kontainer, prober pod dan lifecycle hook mungkin gagal. Pod juga mungkin restart in-place.
- Pada kluster yang menjalankan Kubernetes 1.24 atau lebih lama, saat memperbarui Docker ke versi yang lebih baru, ACK secara default memperbarui node dalam kelompok node dengan mengganti disk sistemnya. Hal ini menghapus seluruh konten disk sistem. Sebelum memulai pembaruan, pastikan untuk melakukan backup semua data penting dari disk sistem.

Prosedur

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Nodes > Node Pools.

Di halaman Node Pools, temukan kelompok node yang ingin Anda perbarui dan pilih > Kubelet Update di kolom Actions. Konfigurasikan parameter seperti yang dijelaskan dalam tabel berikut.

Parameter		Deskripsi
Kubelet Update Information		Lihat versi kubelet saat ini dan pilih versi target.
Runtime Update Information		Lihat versi runtime saat ini dan pilih versi runtime target. Saat Anda memigrasikan runtime kontainer node dari Docker ke containerd, node dalam kelompok node diperbarui dengan mengganti disk sistemnya. Proses ini menghapus seluruh konten pada disk sistem. Jika kluster Anda menjalankan Kubernetes 1.22 dan versi containerd yang terpasang adalah 1.6.34 (versi yang relatif baru), pembaruan tidak didukung.
Update Nodes		Tentukan node yang akan diperbarui: semua node atau node tertentu.
Update Method		Pilih metode pembaruan. In-place Upgrade dan Upgrade by Replacing System Disk didukung. Untuk informasi tentang logika dan proses pembaruan, lihat Informasi referensi: Pembaruan in-place dan pembaruan dengan mengganti disk sistem. In-place Upgrade: Memperbarui komponen yang diperlukan pada node yang ada. Metode ini tidak mengganti disk sistem atau menginisialisasi ulang node, dan tidak memengaruhi data pada node. Upgrade by Replacing System Disk: Menginisialisasi ulang node dengan mengganti disk sistemnya. Properti instans node, seperti nama, ID, dan alamat IP-nya, tetap tidak berubah, tetapi semua data pada disk sistem dihapus. Data pada disk data yang dipasang terpisah tidak terpengaruh.
Ignore Warnings		Menentukan apakah akan melanjutkan pembaruan jika pemeriksaan awal melaporkan peringatan. Contoh item tingkat peringatan adalah pod dalam kelompok node menggunakan `hostPath` yang mengarah ke disk sistem.
Batch Update Policy	Maximum Number of Nodes per Batch	ACK memperbarui node secara batch berdasarkan jumlah maksimum node konkuren yang Anda tentukan. Untuk informasi lebih lanjut tentang proses pembaruan, lihat Informasi referensi: Pembaruan in-place dan pembaruan dengan mengganti disk sistem.
	Automatic Pause Policy	Kebijakan jeda untuk proses pembaruan node.
	Interval Between Batches	Jika Anda mengatur Automatic Pause Policy ke Do not set, Anda dapat menentukan interval waktu antar batch pembaruan. Nilainya berkisar antara 5 hingga 120 menit.
	Auto Snapshot	Jika disk sistem node Anda berisi data bisnis penting, Anda dapat memilih untuk membuat snapshot untuk node sebelum memperbarui kelompok node. Hal ini memungkinkan Anda mencadangkan dan memulihkan data node. Pembuatan snapshot dikenai biaya. Untuk informasi lebih lanjut, lihat Harga snapshot. Kemajuan pembuatan diperbarui secara real time. Jika snapshot tidak lagi diperlukan setelah pembaruan, hapus segera. Catatan Jika Anda memilih Upgrade By Replacing System Disk sebagai metode pembaruan, kami menyarankan Anda mengaktifkan Auto Snapshot. Pembuatan snapshot dikenai biaya. Untuk informasi lebih lanjut, lihat Harga snapshot.

Setelah menyelesaikan konfigurasi, klik Precheck. Setelah pemeriksaan awal berhasil, ikuti petunjuk di layar untuk memulai pembaruan.
Catatan
Jika pemeriksaan awal gagal atau mengembalikan peringatan, lihat Solusi untuk item pemeriksaan yang gagal atau lihat Pre-check Report seperti yang diminta untuk memecahkan masalah.
Selama pembaruan, Anda dapat melakukan operasi berikut sesuai petunjuk:
- Pause: Menjeda pembaruan kluster adalah status antara. Kami menyarankan Anda tidak melakukan operasi lain pada kluster selama periode ini dan segera menyelesaikan proses pembaruan. Jika pembaruan tetap dijeda lebih dari tujuh hari, ACK secara otomatis menghentikan proses dan membersihkan semua event serta log terkait.
  Setelah menjeda pembaruan, Anda tidak dapat mengembalikan versi kubelet dan runtime kontainer pada node yang sudah diperbarui.
- Cancel: Membatalkan pembaruan. Setelah mengklik Cancel, Anda tidak dapat mengembalikan versi kubelet dan runtime kontainer pada node yang sudah diperbarui.
Setelah pembaruan, Anda dapat membuka halaman Nodes, klik nama node, lalu klik tab Basic Information untuk memverifikasi bahwa versi kubelet dan runtime kontainer sudah benar.

Pembaruan in-place dan penggantian disk sistem

Proses pembaruan in-place dan penggantian

Bagian berikut menjelaskan proses untuk pembaruan in-place dan pembaruan dengan mengganti disk sistem. ACK memperbarui node dalam kelompok node secara batch berdasarkan jumlah maksimum node konkuren yang ditentukan. Jumlah node dalam setiap batch meningkat secara eksponensial (1, 2, 4, 8, dan seterusnya) hingga mencapai batas maksimum yang ditentukan. Setelah itu, setiap batch berikutnya dilanjutkan dengan jumlah node maksimum. Misalnya, jika Anda menetapkan jumlah maksimum node konkuren menjadi 4, satu node diperbarui di batch pertama, dua node di batch kedua, dan empat node di batch ketiga serta batch selanjutnya.

Gambar di bawah ini menunjukkan proses pembaruan batch dengan jumlah maksimum node konkuren sebesar N. Jumlah node yang diperbarui di setiap batch adalah 1, 2, 4, 8, dan seterusnya, hingga mencapai N.

Logika pembaruan in-place

ACK melakukan pemeriksaan awal pembaruan. Jika terdeteksi masalah kritis pada kontainer, seperti kegagalan memproses permintaan ttrpc atau proses kontainer tidak merespons sinyal, pembaruan dihentikan.
Status saat ini dari kontainer dan pod disimpan ke direktori tmp sementara.
Sistem meningkatkan containerd, crictl, dan file konfigurasi terkait ke versi baru yang disediakan oleh ACK, lalu me-restart containerd. Tindakan ini tidak memengaruhi kontainer yang sedang berjalan. Jika sebelumnya Anda memodifikasi file /etc/containerd/config.toml pada node, pembaruan akan menimpa perubahan Anda.
Sistem memastikan kubelet berjalan dengan baik dan node siap.

Logika penggantian disk sistem

Node dikosongkan (drained). Jika node dapat dijadwalkan, sistem mengaturnya menjadi tidak dapat dijadwalkan.
Instans ECS dimatikan.
Disk sistem diganti. ID disk sistem berubah, tetapi tipe cloud disk, alamat IP instans, dan alamat MAC elastic network interface tetap tidak berubah.
Node diinisialisasi ulang.
Node dihidupkan kembali dan menjadi siap. Pada saat yang sama, node diatur kembali menjadi dapat dijadwalkan.
Jika Anda mengatur node menjadi tidak dapat dijadwalkan sebelum proses draining dimulai, node tersebut tidak secara otomatis diatur kembali menjadi dapat dijadwalkan setelah pembaruan selesai.

FAQ

Apakah saya dapat mengembalikan kelompok node setelah pembaruan?

Anda tidak dapat mengembalikan kubelet atau runtime kontainer setelah pembaruan. Anda hanya dapat mengembalikan OS. Saat mengembalikan OS, Anda harus memastikan kelompok node masih mendukung citra aslinya.

Apakah pembaruan memengaruhi aplikasi saya?

Pembaruan in-place: Pod tidak direstart, dan aplikasi Anda tidak terpengaruh.

Pembaruan dengan mengganti disk sistem: Node dikosongkan selama jenis pembaruan ini. Jika pod Anda menerapkan logika graceful shutdown dan diterapkan dengan replika ganda di berbagai node, aplikasi Anda tidak terpengaruh. Untuk mencegah beberapa replika aplikasi yang sama diperbarui dalam batch yang sama, Anda dapat mengatur jumlah maksimum node konkuren secara manual ke nilai yang lebih kecil dari jumlah replika pod.

Berapa lama setiap batch pembaruan memakan waktu?

Pembaruan in-place: Kurang dari 5 menit.

Pembaruan dengan mengganti disk sistem: Biasanya kurang dari 8 menit jika tidak membuat snapshot. Jika Anda memilih untuk membuat snapshot, pembaruan dimulai setelah snapshot dibuat, dan total waktu tergantung pada waktu pembuatan snapshot. Proses pembaruan kelompok node memberikan waktu 40 menit untuk pembuatan snapshot. Jika snapshot tidak selesai dalam 40 menit, pembaruan node mengalami timeout dan gagal. Pada titik ini, operasi pembaruan pada node belum dimulai. Jika Anda tidak menyimpan data bisnis pada disk sistem, Anda dapat melewati pembuatan snapshot untuk mengurangi waktu pembaruan.

Apakah data node hilang selama pembaruan?

Saat memperbarui runtime kontainer dengan mengganti disk sistem, jangan menyimpan data penting pada disk sistem, atau pastikan untuk mencadangkannya terlebih dahulu. Data pada disk data tidak terpengaruh selama pembaruan.

Dampak terhadap IP node setelah penggantian disk sistem

Saat disk sistem diganti, ID-nya berubah, tetapi tipe cloud disk, alamat IP instans, dan alamat MAC elastic network interface tetap tidak berubah. Untuk informasi lebih lanjut, lihat Ganti disk sistem (sistem operasi).

Bagaimana cara memperbarui node unmanaged?

Kluster yang dibuat sebelum fitur kelompok node tersedia mungkin memiliki node unmanaged yang tidak termasuk dalam kelompok node mana pun. Anda dapat memigrasikan node unmanaged tersebut ke kelompok node lalu memperbarui kelompok node tersebut. Untuk informasi lebih lanjut tentang cara memigrasikan node unmanaged, lihat Migrasikan node unmanaged ke kelompok node.

Pembersihan direktori Docker setelah beralih ke containerd

Selain file yang dikelola oleh kluster Kubernetes, seperti kontainer, citra, dan log, direktori Docker juga berisi jalur file yang Anda buat sendiri. Jika Anda tidak lagi memerlukan isi direktori Docker, Anda dapat menghapusnya secara manual dari disk data setelah beralih runtime.

Bagaimana cara memulihkan data dari snapshot?

Saat memperbarui kelompok node, Anda dapat membuat snapshot untuk setiap node. Snapshot disimpan selama tujuh hari secara default, tetapi Anda dapat menghapusnya lebih awal secara manual. Dalam kasus langka, seperti kehilangan data setelah pembaruan, Anda dapat menggunakan salah satu metode berikut untuk memulihkan data Anda:

Jika Anda melakukan pembaruan in-place (misalnya, hanya versi kubelet yang diperbarui), Anda dapat mengembalikan disk menggunakan snapshot. Untuk informasi lebih lanjut, lihat Kembalikan cloud disk menggunakan snapshot.
Jika Anda melakukan pembaruan dengan mengganti disk sistem (misalnya, OS atau runtime kontainer diperbarui), Anda dapat membuat cloud disk baru dari snapshot untuk memulihkan data. Untuk informasi lebih lanjut, lihat Buat disk data dari snapshot.

Topik terkait

Anda juga dapat mengaktifkan pembaruan kluster otomatis untuk mengurangi beban O&M. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara otomatis.
Untuk riwayat perubahan containerd, lihat Catatan rilis containerd.
Kelompok node terkelola ACK menyediakan patching otomatis untuk CVE (Common Vulnerabilities and Exposures) OS. Untuk informasi lebih lanjut, lihat Patching CVE otomatis (Direkomendasikan).
Kubernetes 1.24 tidak lagi mendukung Docker sebagai runtime kontainer bawaan. Anda harus memigrasikan runtime kontainer node dari Docker ke containerd. Untuk informasi lebih lanjut, lihat Migrasikan runtime kontainer node dari Docker ke containerd.
Alat command-line untuk Docker dan containerd berbeda. Untuk perbandingan perintah umum, lihat Perbandingan perintah umum untuk Docker dan containerd.
Kami menyarankan Anda segera memperbarui citra OS ke versi terbaru. Untuk informasi lebih lanjut, lihat Ubah sistem operasi.