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

Saat memperbarui versi Kubernetes kluster, Anda harus memperbarui kelompok node selama jam non-puncak setelah memperbarui lapisan kontrol. Selama pembaruan kelompok node, kubelet dan runtime kontainer diperbarui. Container Service for Kubernetes (ACK) melakukan pemeriksaan awal sebelum memperbarui kelompok node untuk mengidentifikasi risiko pembaruan dan memastikan proses yang mulus.

Catatan penggunaan

Penskalaan node
- Jika penskalaan node diaktifkan untuk kluster, kluster secara otomatis memperbarui komponen cluster-autoscaler ke versi terbaru setelah kluster diperbarui. Ini memastikan fitur penskalaan otomatis berfungsi seperti yang diharapkan. Setelah kluster diperbarui, periksa apakah versi cluster-autoscaler telah diperbarui ke versi terbaru. Untuk informasi lebih lanjut, lihat Aktifkan penskalaan otomatis node.
- Selama pembaruan kluster, node dengan mode scaling mode diatur ke swift mode mungkin gagal diperbarui karena node dimatikan. Jika node dalam swift mode gagal diperbarui setelah kluster diperbarui, kami sarankan Anda menghapus node secara manual.
Setelah memperbarui versi Kubernetes kluster ke 1.18, ACK secara otomatis mengonfigurasi pemesanan sumber daya. Jika pemesanan sumber daya tidak dikonfigurasi untuk kluster dan penggunaan sumber daya node tinggi, ACK mungkin gagal menjadwalkan pod yang dievakuasi ke node setelah kluster diperbarui. Cadangkan sumber daya yang cukup pada node. Kami sarankan agar Penggunaan CPU tidak melebihi 50% dan Penggunaan memori tidak melebihi 70%. Untuk informasi lebih lanjut, lihat Kebijakan pemesanan sumber daya.
Jika pod dalam kluster yang menjalankan Kubernetes 1.24 atau lebih lama hanya dikonfigurasi dengan startup probe, pod mungkin sementara tetap dalam status NotReady setelah kubelet di-restart. Kami sarankan menggunakan strategi penyebaran multi-replika untuk mendistribusikan beban kerja di beberapa node guna memastikan ketersediaan pod selama restart node.
Jika sebuah pod mengakses pod lain pada node yang sama menggunakan alamat IP dari instance Server Load Balancer (SLB) yang diekspos oleh layanan LoadBalancer dan externalTrafficPolicy dari Layanan disetel ke Local, kedua pod mungkin tidak lagi berada pada node yang sama setelah node diperbarui. Ini dapat menyebabkan kegagalan jaringan.
Gambar OS kustom tidak divalidasi secara ketat oleh ACK. ACK tidak menjamin keberhasilan pembaruan kluster untuk kluster yang menggunakan gambar OS kustom.
Untuk memperbarui kluster, Anda harus menggunakan Yum untuk mengunduh paket perangkat lunak yang diperlukan. Jika kluster Anda menggunakan konfigurasi jaringan kustom atau gambar OS kustom, pastikan Yum dapat berjalan seperti yang diharapkan. Anda dapat menjalankan perintah yum makecache untuk memeriksa status Yum.
Jika kluster Anda menggunakan konfigurasi kustom lainnya, seperti partisi swap, konfigurasi kubelet yang dimodifikasi menggunakan CLI, atau konfigurasi runtime, kluster mungkin gagal diperbarui atau konfigurasi kustom mungkin ditimpa selama pembaruan.
Saat memperbarui node dengan mengganti disk sistem, ACK menguras node dan memindahkan pod dari node ke node lain yang tersedia berdasarkan PodDisruptionBudget (PDB). Untuk memastikan ketersediaan layanan yang tinggi, kami sarankan menggunakan strategi penyebaran multi-replika untuk mendistribusikan beban kerja di beberapa node. Anda juga dapat mengonfigurasi PDB untuk layanan utama untuk mengontrol jumlah pod yang terganggu pada saat yang sama.
Batas waktu default untuk pengurasan node adalah 30 menit. Jika migrasi pod gagal diselesaikan dalam periode batas waktu, ACK menghentikan pembaruan untuk memastikan stabilitas layanan.
Saat memperbarui node dengan mengganti disk sistem, ACK menginisialisasi ulang node sesuai dengan konfigurasi kelompok node saat ini, termasuk metode login node, label, taint, gambar sistem operasi, dan versi runtime. Secara normal, konfigurasi kelompok node diperbarui dengan mengedit kelompok node. Jika Anda membuat perubahan pada node dengan cara lain, perubahan tersebut akan ditimpa selama pembaruan.
Jika pod pada node menggunakan volume hostPath dan volume hostPath menunjuk ke disk sistem, data dalam volume hostPath hilang setelah node diperbarui dengan mengganti disk sistem.
Selama pembaruan kelompok node, Anda hanya dapat menambah ukuran kelompok node. Penyusutan tidak diperbolehkan.
Jika node Anda adalah node gratis, yaitu node pekerja yang tidak dikelola oleh kelompok node, Anda harus memigrasi node tersebut. Untuk informasi lebih lanjut, lihat Tambahkan node gratis ke kelompok node.

Deskripsi fitur

Selama pembaruan kelompok node, kubelet dan runtime kontainer diperbarui.

kubelet: Perbarui kubelet pada semua node dalam kelompok node ke versi yang sama dengan lapisan kontrol. Pembaruan langsung dilakukan pada kelompok node secara default.
Runtime kontainer: Jika versi runtime kontainer baru tersedia, Anda dapat memperbarui runtime kontainer node dalam kelompok node ke versi baru.
- Jika Anda memigrasi runtime kontainer dari Docker ke containerd, perubahan diterapkan dengan mengganti disk sistem node. Semua data dalam disk sistem dihapus. Cadangkan data dalam disk sistem terlebih dahulu.
- Jika Anda memperbarui versi containerd, pembaruan langsung dilakukan pada kelompok node secara default. File /etc/containerd/config.toml pada setiap node diganti dengan versi baru yang disediakan oleh ACK.
  Catatan
  Selama pembaruan runtime, probe pod dan kait siklus hidup mungkin gagal berjalan dan pod mungkin melakukan restart langsung.
- Dalam kluster yang menjalankan versi Kubernetes lebih lama dari 1.24, saat Anda memperbarui Docker, node dalam kelompok node diperbarui dengan mengganti disk sistem secara default. Proses pembaruan ini menghapus semua isi pada disk sistem. Oleh karena itu, pastikan untuk mencadangkan data penting pada disk sistem sebelum melakukan pembaruan.

Prosedur

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, temukan kluster yang ingin dikelola dan klik namanya. Di panel navigasi kiri, pilih Nodes > Node Pools.

Di halaman Node Pools, temukan kelompok node target dan pilih > Kubelet Update di kolom Actions. Lengkapi konfigurasi sebagai 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 memigrasi runtime kontainer dari Docker ke containerd, node dalam kelompok node diperbarui dengan mengganti disk sistem mereka. Proses ini menghapus semua isi pada disk sistem. Jika versi kluster Anda adalah 1.22 dan containerd yang terinstal adalah V1.6.34 (versi relatif baru), pembaruan tidak didukung.
Update Nodes		Tentukan node yang akan diperbarui: semua node atau node tertentu.
Update Method		Pilih metode peningkatan. In-place Upgrade dan Upgrade By Replacing System Disk didukung. Untuk deskripsi rinci dan prosedur, lihat Referensi: Pembaruan langsung dan pembaruan dengan mengganti disk sistem. In-place Upgrade: Komponen yang diperlukan diperbarui dan diganti pada node asli tanpa penggantian disk. Tidak ada re-inisialisasi node Mempertahankan data disk sistem Upgrade By Replacing System Disk: Node diinisialisasi ulang dengan mengganti disk sistem mereka. Memretensi atribut node (nama, ID, IP) Menghapus semua data disk sistem Mempertahankan disk data yang dipasang
Batch Update Policy	Maximum Number of Nodes per Batch	Node diperbarui secara berurutan berdasarkan parameter ini. Untuk detailnya, lihat Referensi: Pembaruan langsung dan pembaruan dengan mengganti disk sistem.
	Automatic Pause Policy	Menentukan kondisi jeda selama pembaruan node.
	Interval Between Batches	Jika Anda menyetel Automatic Pause Policy ke Do not set, Anda dapat menyetel penundaan antara batch pembaruan. Nilai ini bisa berupa bilangan bulat dari 5 hingga 120. Unit: menit.
	Auto Snapshot	Jika data penting berada pada disk sistem node Anda, buat snapshot sebelum memperbarui kelompok node untuk memfasilitasi pencadangan dan pemulihan data. Penggunaan snapshot memerlukan biaya. Kemajuan pembuatan snapshot diperbarui secara real-time. Setelah pembaruan, jika snapshot tidak lagi diperlukan, hapus mereka segera. Catatan Jika Anda memilih Upgrade By Replacing System Disk, kami sarankan Anda mengaktifkan Auto Snapshot.

Klik Precheck. Setelah pemeriksaan awal selesai, ikuti instruksi di halaman untuk memulai pembaruan.
Catatan
Jika kluster gagal dalam pemeriksaan awal atau hasil pemeriksaan awal berisi peringatan, lihat Item pemeriksaan kluster dan saran untuk memperbaiki masalah kluster atau periksa bagian Pre-check Details berdasarkan instruksi di halaman untuk menyelesaikan masalah.
Selama pembaruan, Anda dapat melakukan operasi berikut sesuai petunjuk:
- Pause: Tidak ada operasi yang dilakukan setelah Anda menjeda pembaruan kluster. Namun, kami sarankan Anda melanjutkan dan menyelesaikan pembaruan sesegera mungkin. Jika pembaruan dijeda lebih dari 7 hari, sistem secara otomatis menghentikan proses pembaruan. Event dan data log yang dihasilkan selama proses pembaruan juga dihapus.
  Setelah Anda klik Jeda, Anda tidak dapat mengembalikan kubelet dan runtime kontainer setelah Anda memperbaruinya.
- Cancel: Membatalkan pembaruan. Setelah Anda klik Cancel, pembaruan dibatalkan. Setelah Anda melakukan operasi ini, Anda tidak dapat mengembalikan kubelet dan runtime kontainer setelah Anda memperbaruinya.
Setelah pembaruan, klik nama node di halaman Nodes. Di tab Overview, periksa apakah versi kubelet dan versi runtime kontainer node telah diperbarui ke versi yang diinginkan.

Referensi: Pembaruan langsung dan pembaruan dengan mengganti disk sistem

Pembaruan langsung dan pembaruan dengan mengganti disk sistem

Berikut ini menjelaskan prosedur untuk pembaruan langsung dan pembaruan dengan mengganti disk sistem. Anda dapat menentukan jumlah maksimum node yang dapat diperbarui secara bersamaan dalam satu batch. Jumlah node yang diperbarui per batch meningkat secara bertahap dalam urutan berikut: 1, 2, 4, 8... Setelah konkurensi maksimum tercapai, jumlah node yang diperbarui dalam setiap batch sama dengan konkurensi maksimum. Misalnya, jika Anda menyetel konkurensi maksimum menjadi 4, satu node diperbarui dalam batch pertama, dua node diperbarui secara bersamaan dalam batch kedua, dan empat node diperbarui secara bersamaan dalam batch ketiga dan batch berikutnya.

Gambar berikut menunjukkan proses pembaruan batch saat konkurensi maksimum adalah N. Jumlah node yang diperbarui per batch meningkat secara bertahap dalam urutan berikut: 1, 2, 4, 8, ..., N

Bagaimana pembaruan langsung dilakukan pada node

Lakukan pemeriksaan awal sebelum pembaruan. Jika kontainer memiliki masalah kritis, seperti kegagalan pemrosesan permintaan ttrpc atau proses kontainer tidak merespons sinyal, pembaruan ditangguhkan.
Simpan status kontainer dan pod saat ini ke direktori tmp sementara.
Perbarui containerd, crictl, dan file konfigurasi terkait ke versi terbaru yang disediakan oleh ACK. Restart tidak memengaruhi kontainer yang sedang berjalan. Jika Anda memodifikasi file /etc/containerd/config.toml pada node, pembaruan akan menimpa perubahan Anda.
Pastikan kubelet berjalan seperti yang diharapkan dan node siap.

Bagaimana node diperbarui dengan mengganti disk sistem

Node dikuras. Saat node dikuras, node disetel ke tidak dapat dijadwalkan.
Instance Elastic Compute Service (ECS) dihentikan.
Disk sistem diganti dan ID disk diubah. Kategori disk sistem, alamat IP instance ECS, dan alamat MAC dari elastic network interfaces (ENI) yang terikat ke instance ECS tetap tidak berubah.
Node diinisialisasi ulang.
Node di-restart dan siap. Saat node siap, node disetel ke dapat dijadwalkan.
Jika node disetel ke tidak dapat dijadwalkan sebelum node dikuras, node tidak secara otomatis kembali ke dapat dijadwalkan setelah node diperbarui dengan mengganti disk sistem.

FAQ

Apakah saya dapat mengembalikan kelompok node setelah saya memperbarui kelompok node?

Anda tidak dapat mengembalikan kubelet dan runtime kontainer setelah Anda memperbaruinya. Anda hanya dapat mengembalikan Citra OS setelah Anda memperbaruinya. Citra OS asli yang ingin Anda gunakan harus didukung oleh kelompok node.

Apakah aplikasi terpengaruh selama pembaruan?

Pembaruan langsung: Pod tidak direstart dan aplikasi tidak terpengaruh.

Pembaruan dengan mengganti disk sistem: Node dikuras selama pembaruan. Jika aplikasi berjalan di beberapa pod yang tersebar di beberapa node dan shutdown yang mulus diaktifkan untuk pod, aplikasi tidak terpengaruh. Untuk informasi lebih lanjut tentang shutdown yang mulus, lihat Graceful shutdown and zero downtime deployments in Kubernetes. Untuk mencegah beberapa replika dari aplikasi yang sama diperbarui dalam batch yang sama, kami sarankan Anda menyetel konkurensi maksimum ke nilai kurang dari jumlah pod tempat aplikasi berjalan.

Berapa lama waktu yang diperlukan untuk memperbarui node dalam satu batch?

Pembaruan langsung: dalam 5 menit.

Pembaruan dengan mengganti disk sistem: dalam 8 menit jika snapshot tidak dibuat. Jika Anda memilih Buat Snapshot Sebelum Pembaruan, ACK mulai memperbarui node setelah snapshot dibuat. Batas waktu pembuatan snapshot adalah 40 menit. Jika pembuatan snapshot habis waktu, pembaruan node gagal dimulai. Jika tidak ada data bisnis yang disimpan pada disk sistem, kami sarankan Anda menghapus Buat Snapshot Sebelum Pembaruan.

Apakah kehilangan data terjadi saat node diperbarui?

Jika pembaruan runtime dilakukan dengan mengganti disk sistem, cadangkan data sebelum Anda memperbarui kelompok node atau jangan menyimpan data penting di disk sistem. Disk data tidak terpengaruh oleh pembaruan.

Apakah alamat IP node berubah setelah disk sistem node diganti?

Setelah disk sistem diganti, ID disk berubah tetapi kategori disk sistem, alamat IP instance ECS, dan alamat MAC dari ENI yang terikat ke instance ECS tetap tidak berubah. Untuk informasi lebih lanjut, lihat Ganti disk sistem (sistem operasi) dari instance.

Bagaimana cara memperbarui node gratis?

Node yang tidak ditambahkan ke kelompok node disebut node gratis. Node gratis ada di kluster yang dibuat sebelum fitur kelompok node dirilis. Untuk memperbaruinode gratis, tambahkan node ke kelompok node dan perbarui kelompok node. Untuk informasi lebih lanjut tentang cara menambahkan node gratis ke kelompok node, lihat Tambahkan node gratis ke kelompok node.

Apa yang harus saya lakukan jika direktori Docker masih ada dan memakan ruang disk setelah saya mengubah runtime kontainer node dari Docker ke containerd?

Selain kontainer, gambar, dan log terkait kluster, jalur file yang Anda buat termasuk dalam direktori Docker. Jika Anda tidak lagi memerlukan data dalam direktori Docker, Anda dapat menghapus direktori tersebut secara manual.

Bagaimana cara memulihkan data dari snapshot?

Anda dapat membuat snapshot untuk node dalam kelompok node saat Anda memperbarui kelompok node. Secara default, snapshot disimpan selama 7 hari. Anda dapat menghapus snapshot secara manual sebelum periode retensi berakhir. Jika data Anda hilang setelah Anda memperbarui kelompok node, Anda dapat menggunakan metode berikut untuk memulihkan data:

Jika pembaruan langsung dilakukan untuk hanya memperbarui kubelet, Anda dapat menggunakan snapshot untuk rollback disk. Untuk informasi lebih lanjut, lihat Rollback disk menggunakan snapshot.
Jika sistem operasi atau runtime kontainer diperbarui dengan mengganti disk sistem node dalam kelompok node, Anda dapat membuat disk dari snapshot. Untuk informasi lebih lanjut, lihat Buat disk data dari snapshot.

Referensi

Anda dapat mengaktifkan pembaruan otomatis untuk kluster untuk mengurangi tekanan operasional dan pemeliharaan. Untuk informasi lebih lanjut, lihat Peningkatan otomatis kluster.
Untuk informasi lebih lanjut tentang catatan rilis untuk containerd, lihat Catatan rilis untuk containerd.
Anda dapat membuat kelompok node terkelola dan mengaktifkan fitur patching kerentanan umum (CVE) otomatis untuk kelompok node. Untuk informasi lebih lanjut, lihat Patching CVE otomatis (disarankan).
Kubernetes 1.24 berencana untuk menghentikan dukungan Docker sebagai runtime kontainer bawaan. Untuk informasi lebih lanjut tentang cara memigrasi runtime kontainer node dari Docker ke containerd, lihat Migrasi runtime kontainer dari Docker ke containerd.
Docker dan containerd memiliki alat baris perintah yang berbeda. Untuk informasi lebih lanjut, lihat Perbandingan perintah umum yang disediakan oleh Docker Engine dan containerd.
Kami sarankan Anda memperbarui versi Citra OS sesegera mungkin. Untuk informasi lebih lanjut, lihat Ubah Sistem Operasi.