Untuk menghindari risiko keamanan dan stabilitas akibat versi kluster yang usang, serta untuk mengakses kemampuan Kubernetes terbaru dan dukungan teknis, lakukan upgrade versi kluster Anda secara tepat waktu. Pemeriksaan awal ACK, kebijakan upgrade yang dapat dikonfigurasi beserta pengaturannya, serta pemantauan progres upgrade membantu Anda menyelesaikan proses upgrade kluster dengan lancar.
Mengapa Anda perlu melakukan upgrade
ACK memungkinkan Anda membuat kluster menggunakan tiga minor versions Kubernetes terbaru. Misalnya, jika ACK mendukung Kubernetes 1.31, 1.32, dan 1.33, Anda tidak dapat lagi membuat kluster dengan versi 1.30. Anda juga tidak dapat membuat kluster menggunakan patch versions yang sudah kedaluwarsa. Untuk informasi selengkapnya, lihat panduan versi.
Menjalankan versi yang usang menimbulkan risiko keamanan dan stabilitas. Setelah suatu versi tidak lagi didukung, kluster Anda tidak akan menerima fitur baru, perbaikan bug, atau dukungan teknis yang tepat waktu, serta rentan terhadap celah keamanan yang belum ditambal.
Lakukan upgrade kluster secara proaktif dan tepat waktu untuk mendapatkan fitur terbaru serta perbaikan bug, dan untuk menerima dukungan teknis yang lebih responsif.
Penting Saat meng-upgrade kluster, ACK menjalankan pemeriksaan awal. Namun, pemeriksaan ini tidak dapat mendeteksi semua konfigurasi fitur atau API yang tidak kompatibel. Berdasarkan model tanggung jawab bersama, Anda bertanggung jawab untuk tetap mengetahui rilis versi dengan membaca dokumen bantuan serta memantau pesan konsol dan internal. Sebelum meng-upgrade kluster, tinjau pertimbangan upgrade untuk versi target.
Dampak upgrade
ACK menyediakan kebijakan upgrade bertahap dan berkelompok untuk memastikan kelangsungan dan stabilitas layanan Anda selama proses upgrade kluster.
Item | Deskripsi |
Pemeriksaan awal | Pemeriksaan awal mengidentifikasi potensi risiko kompatibilitas dalam kluster, seperti API yang sudah usang, versi add-on yang tidak kompatibel, serta masalah pada status node atau disk, dan memberikan saran tentang cara memperbaikinya. Hasil pemeriksaan awal tidak memengaruhi workload yang berjalan di kluster. |
Upgrade control plane | Upgrade ini tidak memengaruhi aplikasi yang sedang berjalan dalam sebagian besar kasus. Jika sebuah aplikasi sangat bergantung pada API server, aplikasi tersebut mungkin perlu mencoba kembali koneksi karena adanya pemutusan sambungan singkat. Kluster ACK yang dikelola: API server dikelola oleh ACK dan di-restart secara bergilir selama proses upgrade. Kluster khusus ACK: Selama proses upgrade, ACK melakukan upgrade in-place pada setiap master node satu per satu.
Durasi: Pada Kluster ACK yang dikelola dan Kluster ACK Serverless, peningkatan dikelola oleh ACK dan memerlukan waktu sekitar 5 menit. Untuk Cluster khusus ACK, node master ditingkatkan satu per satu secara berurutan, dengan setiap node memerlukan waktu sekitar 8 menit. |
Upgrade node pool | Node di-upgrade secara berkelompok untuk memastikan kelangsungan layanan. Sesuaikan kebijakan upgrade berkelompok, seperti jumlah maksimum node per kelompok dan interval antar-kelompok, untuk mengendalikan dampak terhadap layanan Anda.
Upgrade in-place: Disk tidak diganti dan node tidak diinisialisasi ulang. Pod aplikasi terus berjalan, dan layanan tidak terganggu. Upgrade penggantian disk: Node dikosongkan (drained), sistem disk diganti, dan node diinisialisasi ulang. Perhatikan hal-hal berikut: ACK mengosongkan node dan memindahkan pod pada node tersebut ke node lain yang tersedia sesuai dengan PDB. Untuk memastikan ketersediaan tinggi, sebarkan beberapa replika di berbagai node. Konfigurasikan
Pod Disruption Budget (PDB) untuk layanan penting guna mengontrol jumlah pod yang dapat terganggu pada saat yang bersamaan.
ACK menginisialisasi ulang node berdasarkan konfigurasi node pool saat ini, seperti metode logon node, OS image, dan versi container runtime. Biasanya, Anda harus memperbarui konfigurasi node pool dengan mengedit node pool. Jika Anda memodifikasi node dengan cara lain, perubahan tersebut akan ditimpa selama proses upgrade. Jika sebuah pod pada node mereferensikan HostPath yang mengarah ke sistem disk, data dalam direktori HostPath akan hilang setelah upgrade penggantian disk.
Durasi: Durasi tergantung pada metode pengelompokan node. Peningkatan in-place memerlukan waktu sekitar 5 hingga 10 menit per batch, sedangkan peningkatan penggantian disk tanpa snapshot membutuhkan waktu sekitar 8 menit. Durasi spesifik dipengaruhi oleh waktu draining node. Jika snapshot dibuat, peningkatan dimulai setelah proses pembuatan snapshot selesai, yang waktunya bergantung pada volume data. |
Proses upgrade
Upgrade kluster ACK mencakup upgrade control plane dan node pool. Jalankan pemeriksaan awal sebelum melakukan upgrade, dan jadwalkan upgrade selama jam sepi. Setelah control plane di-upgrade, periksa status operasional kluster, lalu putuskan apakah akan meng-upgrade node pool.
Pertimbangan upgrade
Bidang kontrol
Anda harus meng-upgrade versi Kubernetes kluster ACK secara berurutan melalui versi yang didukung. Rollback tidak didukung. Untuk melakukan beberapa kali upgrade, pantau stabilitas layanan kluster setelah setiap upgrade sebelum memulai upgrade berikutnya.
Tinjau panduan versi dan catatan rilis dari setiap versi untuk memahami detail versi, deprecated APIs, dan pertimbangan upgrade versi target. Hal ini bertujuan untuk menghindari masalah ketidakcocokan akibat perubahan fitur pada versi yang lebih baru.
Upgrade control plane tidak memengaruhi aplikasi yang sedang berjalan. API server di-restart secara bergilir selama proses upgrade. Jika aplikasi Anda sangat bergantung pada API server, pastikan aplikasi tersebut mampu mencoba kembali koneksi.
Kubernetes 1.24 dan yang lebih baru tidak mendukung Docker sebagai container runtime bawaan. Saat meng-upgrade kluster dari 1.22 ke 1.24 atau yang lebih baru, Anda harus Memigrasikan container runtime node dari Docker ke containerd.
Hindari melakukan operasi dan pemeliharaan (O&M) pada kluster selama upgrade control plane. Jangan men-deploy atau memperbarui beban kerja Anda selama proses upgrade. Pod baru mungkin gagal mendapatkan alamat IP saat API server sedang di-restart.
Node pool
Persiapan
Upgrade kluster menggunakan yum untuk mengunduh paket perangkat lunak yang diperlukan. Jika Anda memodifikasi konfigurasi jaringan node secara manual atau menggunakan citra sistem operasi (OS) kustom, pastikan yum berfungsi dengan benar pada node Anda. Jalankan yum makecache untuk memverifikasi.
ACK tidak sepenuhnya memvalidasi citra OS kustom dan tidak dapat menjamin bahwa citra tersebut dapat di-upgrade.
Jika Anda memodifikasi konfigurasi kluster, misalnya mengaktifkan swap atau menggunakan metode non-produksi seperti masuk ke node (Menyesuaikan konfigurasi kubelet node pool) untuk memodifikasi konfigurasi kubelet atau runtime, upgrade kluster mungkin gagal atau menimpa konfigurasi kustom Anda.
Setelah meng-upgrade kluster ke versi 1.18, ACK mengonfigurasi Kebijakan pemesanan resource node secara default. Jika pemesanan resource tidak dikonfigurasi dan penggunaan resource node tinggi, pod mungkin tidak dijadwalkan segera setelah dipindahkan. Cadangkan resource untuk node Anda. Jaga penggunaan CPU tetap di atau di bawah 50% dan penggunaan memori di atau di bawah 70%.
Pada kluster yang menjalankan versi 1.24 atau lebih lama, pod yang dikonfigurasi hanya dengan startup probe akan memasuki status NotReady secara singkat setelah kubelet di-restart. Deploy beban kerja dengan beberapa replika di berbagai node agar cukup banyak pod tetap tersedia selama restart node.
Jaga setidaknya 20% ruang disk tetap kosong. Hal ini mencegah pemindahan pod akibat kapasitas disk yang tidak mencukupi selama upgrade.
Batasan upgrade node pool
Upgrade node pool hanya mendukung operasi scale-out. Operasi scale-in tidak didukung.
Jika Anda memiliki worker node yang tidak dikelola dan tidak termasuk dalam node pool, migrasikan node tersebut. Untuk informasi selengkapnya, lihat Memigrasikan node yang tidak dikelola ke node pool.
Selama upgrade penggantian disk, ACK menginisialisasi ulang node berdasarkan konfigurasi node pool saat ini, termasuk metode logon, label, taint, OS image, dan versi runtime. Perbarui konfigurasi node pool seperti yang dijelaskan dalam Mengedit node pool. Perubahan yang dilakukan dengan metode lain akan ditimpa selama proses upgrade.
Jika sebuah pod pada node mereferensikan HostPath yang mengarah ke sistem disk, data dalam direktori HostPath akan hilang setelah upgrade penggantian disk.
Saat meng-upgrade node pool pada kluster versi 1.31 atau lebih lama, proses tersebut juga meng-upgrade NVIDIA Device Plugin dan mereset segala konfigurasi non-standarnya.
Penyesuaian skala node dan penjadwalan
Jika penyesuaian skala node diaktifkan, ACK secara otomatis memperbarui cluster-autoscaler ke versi terbaru setelah upgrade kluster agar penskalaan tetap tersedia. Verifikasi bahwa cluster-autoscaler telah diperbarui. Untuk informasi selengkapnya, lihat Mengaktifkan penyesuaian otomatis node.
Selama upgrade kluster, node dengan Scaling Mode diatur ke Swift mungkin gagal di-upgrade karena dimatikan. Jika ada node yang tetap belum ter-upgrade karena Swift diaktifkan, hapus node tersebut secara manual.
Jaringan dan ketersediaan layanan
Jika sebuah pod mengakses pod lain pada node yang sama melalui alamat SLB dari Service LoadBalancer, dan externalTrafficPolicy diatur ke Local, rotasi node mungkin menempatkan pod-pod tersebut pada node yang berbeda. Hal ini dapat mengganggu konektivitas.
Selama upgrade penggantian disk, ACK mengosongkan node dan memindahkan pod ke node lain yang tersedia dengan tetap mematuhi Pod Disruption Budget (PDB). Untuk memastikan ketersediaan tinggi, deploy beban kerja dengan beberapa replika di berbagai node dan konfigurasikan PDB untuk layanan penting guna membatasi gangguan pod secara bersamaan.
Timeout default untuk mengosongkan node adalah 30 menit. Jika migrasi pod tidak selesai dalam periode ini, ACK menghentikan upgrade untuk menjaga stabilitas layanan.
Metode upgrade
Upgrade in-place dan upgrade penggantian disk
Untuk upgrade control plane, ACK mengelola prosesnya untuk kluster ACK yang dikelola dan kluster ACK Serverless. Kluster khusus ACK di-upgrade menggunakan upgrade in-place.
Untuk upgrade node pool, ACK menawarkan dua metode: upgrade in-place dan upgrade penggantian disk.
Upgrade in-place: Upgrade dilakukan langsung pada node yang ada tanpa mengganti sistem disk atau menginisialisasi ulang node. Data node asli tidak terpengaruh. Konfigurasi terkait instance ECS, seperti alamat IP dan mount disk, tetap tidak berubah. Namun, konfigurasi komponen yang dikelola ACK, seperti containerd dan kubelet, mungkin disesuaikan berdasarkan perbedaan antar-versi komponen.
Untuk menyesuaikan konfigurasi containerd atau kubelet, lihat Menyesuaikan konfigurasi kubelet node pool dan Menyesuaikan konfigurasi containerd untuk node pool.
Upgrade penggantian disk: Metode ini mengganti sistem disk dan menginisialisasi ulang node. Meskipun alamat IP dan mount data disk tetap tidak berubah, semua data pada sistem disk akan dihapus. Aktifkan snapshot disk dan backup sistem disk sebelum melanjutkan.
Data disk yang disambungkan ke node tidak terpengaruh.
Setelah upgrade penggantian disk, password logon default dari instance ECS menjadi tidak valid. Reset password.
Kasus khusus
Upgrade penggantian disk diperlukan dalam skenario berikut:
Alternatif: upgrade bergilir melalui node pool baru
Alih-alih meng-upgrade node yang ada, lakukan upgrade bergilir dengan membuat node pool baru dengan konfigurasi target. Migrasikan aplikasi secara bertahap dengan mengatur node pool lama menjadi unschedulable atau memperbarui penjadwalan beban kerja. Setelah migrasi diverifikasi, hapus node pool lama.
Anda akan ditagih untuk kedua node pool selama keduanya ada; hapus pool lama segera setelah migrasi untuk mengelola biaya.
FAQ
Bagaimana cara meng-upgrade kluster saya secara manual?
Untuk informasi selengkapnya, lihat Meng-upgrade kluster secara manual. Pertama, selesaikan pemeriksaan awal. Kemudian, lakukan upgrade dan verifikasi bahwa hasilnya sesuai harapan.
Apa praktik terbaik untuk meng-upgrade kluster?
Pertahankan frekuensi upgrade yang teratur: Pantau panduan versi, dokumen bantuan, email, dan pesan teks. Lakukan upgrade segera untuk memastikan dukungan dan keamanan yang berkelanjutan.
Buat rencana upgrade: Upgrade kluster melibatkan lebih dari sekadar perubahan nomor versi. Ini juga mencakup deprecated APIs, fitur yang sudah usang, dan perubahan besar. Buat rencana upgrade terperinci berdasarkan ukuran kluster dan kebutuhan bisnis, serta sediakan maintenance window. Lakukan upgrade selama jam sepi. Validasi upgrade di lingkungan pengujian sebelum menerapkannya ke produksi. Setelah upgrade, verifikasi dan pantau beban kerja Anda untuk memastikan bahwa upgrade tidak memengaruhi bisnis Anda.
Gunakan upgrade otomatis: Aktifkan fitur upgrade kluster otomatis. ACK menghasilkan rencana upgrade terlebih dahulu, memicu pemeriksaan awal, dan meng-upgrade kluster dalam maintenance window yang ditentukan. Hal ini mengurangi beban kerja O&M dalam manajemen versi.
Sebagai alternatif, buat kluster ACK Auto Mode. Versi kluster akan di-upgrade secara otomatis oleh ACK.
Berapa lama waktu yang dibutuhkan untuk upgrade kluster?
Control plane: Untuk kluster ACK yang dikelola dan kluster ACK Serverless, upgrade dikelola oleh ACK dan memakan waktu sekitar 5 menit. Untuk kluster khusus ACK, master node di-upgrade secara berurutan, yang memakan waktu sekitar 8 menit per node.
Node pool: Durasi bergantung pada konfigurasi pengelompokan node. Upgrade in-place memakan waktu sekitar 5 hingga 10 menit per kelompok. Upgrade penggantian disk tanpa snapshot memakan waktu sekitar 8 menit per kelompok, tetapi durasi sebenarnya dipengaruhi oleh proses pengosongan node. Jika Anda memilih untuk membuat snapshot, proses upgrade menunggu hingga snapshot selesai dibuat. Waktu yang diperlukan untuk membuat snapshot bergantung pada jumlah data.
Bisakah saya tetap menggunakan satu versi selamanya dan tidak meng-upgrade kluster saya?
Tidak, Anda tidak bisa. Potensi risiko keamanan pada versi yang usang dapat memengaruhi tidak hanya kluster Anda tetapi juga keamanan keseluruhan Alibaba Cloud. ACK tidak mengizinkan kluster tetap dalam kondisi usang untuk jangka waktu yang lama dan melakukan upgrade paksa untuk membawanya ke versi yang aman dan stabil.
Upgrade versi kluster Anda tepat waktu. Untuk informasi selengkapnya, lihat Meng-upgrade kluster secara manual. Hal ini memungkinkan Anda memanfaatkan fitur terbaru dan menerima dukungan teknis yang lebih baik dari ACK. Sebelum meng-upgrade, lihat catatan rilis untuk versi target guna memahami perubahan fitur dan catatan pentingnya. Aktifkan fitur upgrade kluster otomatis untuk memastikan kluster Anda di-upgrade secara otomatis dan berkala.
Apakah ACK mendukung upgrade lintas beberapa versi?
Versi kluster saya sangat lama. Bagaimana cara meng-upgrade-nya dengan cepat?
Gunakan salah satu solusi berikut.
Solusi 1: Upgrade kluster satu minor version pada satu waktu. Setelah setiap upgrade, periksa apakah aplikasi bisnis Anda di kluster berjalan seperti yang diharapkan sebelum melanjutkan ke upgrade berikutnya. Untuk informasi selengkapnya, lihat Meng-upgrade kluster secara manual.
Solusi 2: Buat kluster yang menjalankan versi terbaru, migrasikan aplikasi Anda secara bertahap ke kluster baru, lalu hapus kluster lama. Untuk informasi tentang cara membuat dan mengonfigurasi kluster, lihat Membuat kluster ACK yang dikelola.
Bagaimana cara beralih dari Docker ke containerd saat meng-upgrade kluster dari versi 1.22 ke 1.24?
ACK tidak lagi mendukung Docker sebagai container runtime bawaan pada versi 1.24 dan yang lebih baru. Anda harus memigrasikan container runtime node Anda dari Docker ke containerd.
Ganti runtime di node pool asli dengan menggunakan fitur upgrade node pool, atau buat node pool containerd baru dan migrasikan beban kerja Anda. Untuk informasi selengkapnya, lihat Memigrasikan container runtime node dari Docker ke containerd.
Bagaimana ACK memastikan stabilitas selama upgrade kluster?
Kluster ACK terdiri dari control plane dan node pool. Untuk kedua komponen tersebut, hasil pemeriksaan awal tidak memengaruhi aplikasi yang sedang berjalan, dan konsol memberikan saran perbaikan jika pemeriksaan gagal.
Upgrade control plane: ACK menyediakan fitur pemeriksaan awal yang memeriksa deprecated APIs, kompatibilitas add-on, kompatibilitas konfigurasi fitur, dan komponen control plane. Untuk informasi selengkapnya, lihat Meng-upgrade kluster secara manual.
Upgrade node pool: Upgrade node pool mencakup upgrade kubelet dan containerd. ACK menyediakan fitur pemeriksaan awal yang memeriksa status node, resource sistem, status disk, dan lingkungan jaringan.
Konfigurasikan juga kebijakan upgrade untuk mengontrol laju upgrade. Misalnya, tentukan node yang akan di-upgrade, atur jumlah maksimum node yang dapat di-upgrade di setiap kelompok, dan konfigurasikan kebijakan jeda upgrade. Jika sistem disk node Anda berisi data bisnis penting, Anda juga dapat membuat snapshot untuk node sebelum meng-upgrade node pool. Untuk informasi selengkapnya, lihat Meng-upgrade node pool.
Apakah upgrade paksa memengaruhi workload saya?
Upgrade paksa adalah upgrade in-place. Upgrade ini tidak mengganti disk atau mengubah sistem operasi maupun container runtime. Sebelum ACK melakukan upgrade paksa pada kluster, ACK akan memberi tahu Anda setidaknya satu bulan sebelumnya melalui pesan teks, email, dan pesan internal.
Kluster berikut tidak akan di-upgrade secara paksa:
Apakah kluster dengan versi yang sudah kedaluwarsa masih dapat digunakan secara normal?
Ya. Namun, kluster yang menggunakan versi kedaluwarsa terpapar risiko keamanan dan stabilitas. Segera upgrade kluster ke versi yang dipelihara.
Karena kluster ACK menggunakan arsitektur terkelola, risiko keamanan ini tidak hanya memengaruhi kluster Anda tetapi juga dapat berdampak pada keamanan keseluruhan Alibaba Cloud. Oleh karena itu, ACK tidak mengizinkan kluster tetap dalam kondisi usang untuk jangka waktu yang lama dan melakukan upgrade paksa ke versi yang aman dan stabil. Untuk informasi selengkapnya, lihat Upgrade wajib untuk versi usang.
Apakah rollback versi didukung setelah upgrade kluster?
Tidak. Rollback tidak didukung untuk versi control plane, kubelet, atau container runtime setelah upgrade.
Selama upgrade node pool, jika data layanan penting disimpan pada sistem disk node, buatlah snapshot untuk node sebelum upgrade guna mem-backup dan memulihkan data node.
Operasi mana yang harus saya lakukan terlebih dahulu jika saya perlu meng-upgrade kluster dan memigrasikannya ke kluster ACK Pro yang dikelola?
Selesaikan migrasi kluster terlebih dahulu. Setelah Anda memverifikasi bahwa layanan Anda berjalan normal, mulailah upgrade kluster.
Apa yang harus saya lakukan jika pemeriksaan awal melaporkan deprecated APIs?
Saat meng-upgrade kluster yang menjalankan Kubernetes 1.20 atau lebih baru, ACK memeriksa apakah versi saat ini menggunakan deprecated APIs. Hasil ini tidak menghalangi upgrade dan hanya bersifat informasional. Perbaiki masalah yang dilaporkan sebelum upgrade untuk menghindari dampak pada operasi kluster normal di versi baru.
Bagaimana cara mengatasi peringatan "versi komponen terlalu rendah" pada pemeriksaan awal?
Kecuali untuk komponen control plane dan beberapa komponen inti (seperti kube-proxy), ACK tidak meng-upgrade add-on kluster lainnya. Lihat add-on yang perlu di-upgrade pada halaman Add-ons di konsol. Rujuk Ikhtisar komponen dan catatan rilis untuk mempelajari kompatibilitas versi dan persyaratan upgrade. Kemudian upgrade add-on tersebut selama jam sepi.
Apakah wajar jika node memunculkan peringatan selama upgrade?
Peringatan sementara yang diharapkan berikut mungkin terjadi selama upgrade. Tidak diperlukan intervensi manual:
Peringatan tentang kegagalan sinkronisasi ConfigMaps, Secrets, dan ServiceAccounts selama restart kubelet.
Peringatan FailedMount selama upgrade penggantian disk (node sedang dibangun ulang).
Periode singkat di mana node berada dalam status NotReady.
Peringatan ini akan pulih secara otomatis setelah upgrade selesai, dan biasanya berlangsung selama beberapa menit.
Bisakah saya meng-upgrade kluster jika vSwitch tidak memiliki alamat IP yang tersedia?
Upgrade penggantian disk memerlukan alamat IP yang tersedia untuk membuat jaringan ECS temporary bagi sistem disk baru. Jika vSwitch tidak memiliki cukup alamat IP yang tersedia, tambahkan Secondary CIDR blocks, atau tambahkan vSwitch yang memiliki lebih banyak alamat IP tersedia ke node pool sebelum Anda melakukan upgrade.
Bagaimana cara mengatasi kegagalan upgrade dengan error "the aliyun service is not running on the instance"?
Cloud Assistant tidak tersedia, yang menyebabkan perintah upgrade gagal. Mulai atau hentikan Cloud Assistant, lalu coba upgrade kluster kembali. Untuk informasi selengkapnya, lihat Memulai, menghentikan, atau menguninstal Cloud Assistant Agent.
Bagaimana cara mengatasi error "PLEG not healthy" pada node?
Error ini menunjukkan bahwa kontainer atau container runtime tidak merespons. Restart node lalu coba upgrade kembali.
Apa yang harus saya lakukan jika saya mendapatkan error invalid object doesn't have additional properties saat meng-upgrade kluster?
Setelah meng-upgrade kluster, Anda juga harus meng-upgrade versi kubectl lokal Anda. Jika Anda tidak segera meng-upgrade-nya, Anda mungkin mengalami error seperti invalid object doesn't have additional properties saat menggunakan kubectl lokal karena versinya berbeda dari versi API server kluster. Untuk informasi selengkapnya tentang cara menginstal atau meng-upgrade kubectl, lihat Install and Set Up kubectl.