Untuk menghindari risiko keamanan dan stabilitas akibat versi kluster yang kedaluwarsa serta untuk memanfaatkan kemampuan terbaru Kubernetes dan dukungan teknis, lakukan peningkatan versi kluster Anda secara tepat waktu. ACK menyediakan pemeriksaan pra-peningkatan, mendukung kebijakan dan pengaturan kecepatan peningkatan yang dapat dikonfigurasi, serta menawarkan pemantauan progres peningkatan guna memastikan proses berjalan lancar.
Mengapa Anda harus melakukan peningkatan
ACK memungkinkan Anda membuat kluster menggunakan tiga versi minor terbaru Kubernetes. Misalnya, jika ACK mendukung Kubernetes 1.31, 1.32, dan 1.33, Anda tidak dapat lagi membuat kluster yang menggunakan versi 1.30. Anda juga tidak dapat membuat kluster yang menggunakan versi patch yang telah kedaluwarsa. Untuk informasi lebih lanjut, lihat panduan versi.
Kluster yang menjalankan versi kedaluwarsa memiliki risiko keamanan dan stabilitas. Setelah versi kluster kedaluwarsa, Anda tidak lagi dapat memanfaatkan fitur-fitur dan perbaikan bug dari versi Kubernetes baru, serta tidak dapat menerima dukungan teknis yang tepat waktu dan efektif. Selain itu, Anda terpapar risiko kerentanan keamanan yang belum diperbaiki.
Penting Saat melakukan peningkatan 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 memperbarui informasi tentang rilis versi dengan membaca dokumen bantuan serta memantau Konsol dan pesan internal. Sebelum melakukan peningkatan kluster, tinjau catatan rilis untuk versi baru tersebut.
Dampak peningkatan
ACK menyediakan kebijakan peningkatan bertahap dan berbasis batch untuk memastikan kelangsungan dan stabilitas Pod aplikasi Anda selama peningkatan kluster.
Pemeriksaan awal: Sebelum meningkatkan lapisan kontrol atau kelompok node, ACK menjalankan pemeriksaan awal untuk mengidentifikasi potensi risiko ketidakkompatibelan, seperti API yang sudah ditinggalkan, versi komponen yang tidak kompatibel, serta masalah pada status node atau disk. ACK juga memberikan saran cara mengatasi masalah tersebut. Pemeriksaan awal tidak memengaruhi layanan kluster Anda.
Lapisan kontrol:
Kluster ACK yang dikelola: API Server dikelola oleh ACK dan direstart secara bergiliran selama peningkatan. Proses ini biasanya tidak memengaruhi aplikasi yang sedang berjalan. Jika suatu aplikasi sangat bergantung pada API Server, aplikasi tersebut mungkin perlu mencoba koneksi ulang akibat pemutusan koneksi singkat.
Cluster khusus ACK: Selama peningkatan, ACK melakukan peningkatan in-place pada setiap node master secara berurutan. Proses ini biasanya tidak memengaruhi aplikasi yang sedang berjalan. Jika suatu aplikasi sangat bergantung pada API Server, aplikasi tersebut mungkin perlu mencoba koneksi ulang akibat pemutusan koneksi singkat.
Kelompok node: Node ditingkatkan secara bertahap untuk memastikan kelangsungan layanan. Sesuaikan kebijakan peningkatan batch, seperti menentukan jumlah maksimum node per batch dan interval antar batch, untuk mengontrol dampak terhadap layanan Anda.
Selama peningkatan in-place, disk tidak diganti dan node tidak diinisialisasi ulang. Pod aplikasi tetap berjalan, dan layanan tidak terganggu.
Peningkatan dengan penggantian sistem disk melibatkan draining node, mengganti sistem disk, dan menginisialisasi ulang node. Perhatikan dampak berikut:
Selama peningkatan dengan penggantian sistem disk, ACK melakukan draining node. Pod pada node tersebut dievakuasi ke node lain yang tersedia sesuai dengan Pod Disruption Budget (PDB). Untuk memastikan ketersediaan tinggi, gunakan strategi penerapan multi-replika, sebarkan beban kerja di beberapa node, dan konfigurasikan PDB untuk layanan kritis guna mengontrol jumlah Pod yang dapat terganggu secara bersamaan. Hal ini membantu menjaga kelangsungan layanan selama operasi maintenance node.
Selama peningkatan dengan penggantian sistem disk, ACK menginisialisasi ulang node berdasarkan konfigurasi saat ini dari kelompok node. Konfigurasi ini mencakup pengaturan seperti metode login node, citra OS, dan versi runtime kontainer. Perbarui konfigurasi kelompok node dengan cara mengedit kelompok node. Perubahan yang dilakukan pada node dengan cara lain akan ditimpa selama peningkatan.
Jika sebuah Pod pada node mereferensikan HostPath yang mengarah ke sistem disk, data dalam direktori HostPath akan hilang setelah peningkatan dengan penggantian sistem disk.
Proses peningkatan
Peningkatan kluster ACK melibatkan peningkatan lapisan kontrol dan kelompok node. Jalankan pemeriksaan awal sebelum memulai dan jadwalkan peningkatan pada jam sepi untuk meminimalkan dampak. Setelah peningkatan lapisan kontrol selesai, periksa status operasional kluster secara cermat. Kemudian, tingkatkan kelompok node agar sesuai dengan versi lapisan kontrol.
1. Persiapan
Tentukan versi target untuk peningkatan berdasarkan catatan rilis ACK. ACK hanya mendukung peningkatan satu versi minor dalam satu waktu. Anda tidak dapat melewatkan versi atau melakukan rollback ke versi sebelumnya.
Bacalah dengan cermat panduan versi untuk versi target. Pastikan Anda memahami pertimbangan peningkatan, perubahan utama, dan fitur yang sudah ditinggalkan guna menghindari masalah ketidakkompatibelan setelah peningkatan.
Rencanakan jendela maintenance untuk kluster. Jalankan pemeriksaan awal terlebih dahulu untuk mengidentifikasi potensi risiko dan lakukan peningkatan pada jam sepi.
2. Peningkatan Lapisan Kontrol
Jalankan pemeriksaan awal: Sebelum peningkatan, jalankan pemeriksaan awal. Lanjutkan peningkatan hanya setelah semua item pemeriksaan lolos atau semua masalah yang teridentifikasi telah diperbaiki.
Pemeriksaan awal memeriksa item seperti API yang sudah ditinggalkan (untuk versi 1.20 ke atas), kompatibilitas komponen, kompatibilitas konfigurasi fitur, status kluster, dan status komponen lapisan kontrol.
Lakukan peningkatan: Setelah pemeriksaan awal lolos, lakukan peningkatan.
Kluster ACK yang dikelola dan kluster ACK Serverless: ACK mengelola peningkatan tersebut. Komponen lapisan kontrol yang ditingkatkan mencakup kube-apiserver, kube-controller-manager, kube-scheduler, dan kube-proxy.
Cluster khusus ACK: Digunakan metode peningkatan in-place untuk memaksimalkan kelangsungan layanan serta mengurangi risiko migrasi data dan penyesuaian konfigurasi.
Klik untuk melihat prosesnya
Saat ACK mendeteksi bahwa etcd dan runtime kontainer kluster Anda perlu ditingkatkan, ACK meningkatkannya satu per satu pada node master.
Node master dipilih dan ditingkatkan satu per satu. ID node master yang sedang ditingkatkan ditampilkan.
Tingkatkan komponen master, termasuk kube-apiserver, kube-controller-manager, kube-scheduler, dan kube-proxy.
Tingkatkan kubelet pada node master.
Pemeriksaan pasca-peningkatan: Verifikasi bahwa versi kluster telah diperbarui dan komponen inti, aplikasi, pembuatan Pod, serta penambahan node semuanya berfungsi sebagaimana mestinya.
3. Peningkatan kelompok node
Peningkatan kelompok node melibatkan peningkatan kubelet dan runtime kontainer.
Jalankan pemeriksaan awal: Sebelum peningkatan, jalankan pemeriksaan awal. Lanjutkan peningkatan hanya setelah semua item pemeriksaan lolos atau semua masalah yang teridentifikasi telah diperbaiki.
Pemeriksaan awal memeriksa item seperti status node, sumber daya sistem, status disk, dan lingkungan jaringan.
Konfigurasikan kebijakan peningkatan dan lakukan peningkatan: Pilih metode peningkatan (in-place atau penggantian disk) dan konfigurasikan kebijakan peningkatan batch. Ini mencakup menentukan jumlah maksimum node per batch dan apakah akan membuat snapshot secara otomatis.
Pemeriksaan pasca-peningkatan: Verifikasi bahwa versi kubelet dan runtime kontainer telah diperbarui serta penjadwalan Pod dan aplikasi berfungsi sebagaimana mestinya.
4. Prosedur lainnya
Ubah citra OS: Untuk meningkatkan citra OS kelompok node atau mengganti jenis OS (misalnya, dari Alibaba Cloud Linux 2 ke Alibaba Cloud Linux 3), lihat Ubah sistem operasi.
Komponen kluster: ACK hanya meningkatkan lapisan kontrol dan komponen inti seperti kube-proxy. Tingkatkan komponen kluster lainnya secara manual melalui halaman Add-ons pada jam sepi. Rujuk Ikhtisar komponen dan catatan rilis untuk persyaratan kompatibilitas versi.
Pertimbangan peningkatan
Lapisan kontrol
Anda harus meningkatkan versi Kubernetes kluster ACK secara berurutan melalui versi-versi yang didukung. Rollback tidak didukung. Untuk melakukan beberapa peningkatan, pantau stabilitas layanan kluster setelah setiap peningkatan sebelum memulai peningkatan berikutnya.
Sebelum peningkatan, lihat Upgrade kluster untuk ikhtisar. Tinjau panduan versi dan catatan rilis untuk setiap versi. Pastikan Anda memahami detail versi, API yang sudah ditinggalkan, dan pertimbangan peningkatan guna menghindari masalah ketidakkompatibelan yang mungkin disebabkan oleh perubahan fitur pada versi yang lebih baru.
Peningkatan lapisan kontrol tidak memengaruhi aplikasi yang sedang berjalan. API Server direstart secara bergiliran selama peningkatan. Jika aplikasi Anda sangat bergantung pada API Server, aplikasi tersebut harus mampu mencoba koneksi ulang.
Kubernetes 1.24 ke atas tidak lagi mendukung Docker sebagai runtime kontainer bawaan. Saat Anda meningkatkan kluster dari 1.22 ke 1.24 atau versi yang lebih baru, Anda harus Migrasikan runtime kontainer node dari Docker ke containerd.
Hindari melakukan operasi dan maintenance (O&M) pada kluster selama peningkatan lapisan kontrol.
Kelompok node
Penyesuaian otomatis node
Jika penyesuaian otomatis node diaktifkan untuk kluster, komponen cluster-autoscaler secara otomatis diperbarui ke versi terbaru setelah kluster ditingkatkan. Hal ini memastikan fitur penyesuaian otomatis node berfungsi sebagaimana mestinya. Setelah kluster ditingkatkan, konfirmasi bahwa komponen cluster-autoscaler telah diperbarui ke versi yang diharapkan. Untuk informasi lebih lanjut, lihat Aktifkan penyesuaian otomatis node.
Selama peningkatan kluster, node dalam Fast Scaling Mode mungkin gagal ditingkatkan karena dimatikan. Jika ada node dalam Fast Scaling Mode yang tidak ditingkatkan, hapus secara manual setelah peningkatan selesai.
Setelah Anda meningkatkan kluster ke versi 1.18, ACK mengonfigurasi pemesanan sumber daya node secara default. Jika pemesanan sumber daya tidak dikonfigurasi untuk kluster dan penggunaan sumber daya node tinggi, Pod mungkin gagal dijadwalkan dengan cepat setelah dievakuasi. Untuk mencegah hal ini, pesan sumber daya untuk node. Kami menyarankan agar penggunaan CPU tidak melebihi 50% dan penggunaan memori tidak melebihi 70%. Untuk informasi lebih lanjut, lihat Kebijakan pemesanan sumber daya node.
Pada kluster versi 1.24 atau lebih lama, jika Pod untuk beban kerja dikonfigurasi hanya dengan probe startup, Pod tersebut mungkin memasuki status NotReady untuk waktu singkat setelah kubelet direstart. Kami menyarankan Anda menggunakan kebijakan penerapan multi-replika dan menyebarkan beban kerja di beberapa node untuk memastikan cukup Pod tersedia jika suatu node direstart.
Jika sebuah Pod mengakses Pod lain pada node yang sama melalui alamat SLB dari Service bertipe LoadBalancer, dan externalTrafficPolicy Service tersebut diatur ke Local, kedua Pod tersebut mungkin tidak lagi berada pada node yang sama setelah rotasi node. Hal ini dapat menyebabkan masalah konektivitas jaringan.
Karena ACK tidak memverifikasi secara ketat citra sistem operasi kustom, ACK tidak dapat menjamin keberhasilan peningkatan.
Peningkatan kluster memerlukan yum untuk mengunduh paket perangkat lunak yang diperlukan. Jika Anda mengubah konfigurasi jaringan node atau menggunakan citra OS kustom, pastikan yum dapat dijalankan pada node tersebut. Anda dapat menjalankan perintah yum makecache untuk memverifikasi hal ini.
Jika Anda mengubah konfigurasi kluster, misalnya dengan mengaktifkan partisi SWAP atau memodifikasi konfigurasi kubelet atau runtime menggunakan command line, peningkatan kluster mungkin gagal dan konfigurasi kustom Anda mungkin ditimpa.
Saat Anda meningkatkan node dengan mengganti sistem disk, ACK melakukan draining node. Proses ini mengevakuasi Pod ke node lain yang tersedia dan mematuhi Pod Disruption Budget (PDB). Untuk memastikan ketersediaan tinggi, kami menyarankan Anda menggunakan kebijakan penerapan multi-replika. Sebarkan beban kerja di beberapa node dan konfigurasikan PDB untuk layanan kritis guna mengontrol jumlah Pod yang dapat terganggu secara bersamaan.
Periode timeout default untuk draining node adalah 30 menit. Jika migrasi Pod belum selesai dalam periode timeout tersebut, ACK menghentikan peningkatan untuk memastikan stabilitas layanan.
Saat Anda meningkatkan node dengan mengganti sistem disk, ACK menginisialisasi ulang node berdasarkan konfigurasi kelompok node saat ini. Konfigurasi ini mencakup metode login, label, taint, citra OS, dan versi runtime. Anda harus memperbarui konfigurasi kelompok node hanya dengan cara mengedit kelompok node. Perubahan yang dilakukan pada konfigurasi node melalui metode lain akan ditimpa selama peningkatan.
Jika sebuah Pod pada node mereferensikan HostPath yang mengarah ke sistem disk, data dalam direktori HostPath akan hilang setelah sistem disk diganti selama peningkatan.
Selama peningkatan kelompok node, hanya operasi scale-out yang didukung. Operasi scale-in tidak didukung.
Jika node pekerja tidak dikelola oleh kelompok node mana pun (node tidak ditugaskan), Anda harus terlebih dahulu memigrasikannya ke kelompok node. Untuk informasi lebih lanjut, lihat Migrasikan node yang tidak ditugaskan ke kelompok node.
Metode peningkatan
Peningkatan in-place dan penggantian sistem disk
Untuk peningkatan lapisan kontrol, ACK mengelola proses tersebut untuk kluster ACK yang dikelola dan kluster ACK Serverless. Cluster khusus ACK ditingkatkan menggunakan metode peningkatan in-place.
Untuk peningkatan kelompok node, ACK menawarkan dua metode: peningkatan in-place dan peningkatan dengan penggantian sistem disk.
Peningkatan in-place: Peningkatan 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 pemasangan 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 Sesuaikan konfigurasi kubelet untuk kelompok node dan Sesuaikan konfigurasi containerd untuk kelompok node.
Peningkatan dengan penggantian sistem disk: Metode ini mengganti sistem disk dan menginisialisasi ulang node. Meskipun alamat IP dan pemasangan disk data tetap tidak berubah, semua data pada sistem disk akan dihapus. Aktifkan snapshot disk dan backup sistem disk sebelum melanjutkan.
Disk data yang disambungkan ke node tidak terpengaruh.
Kasus khusus
Peningkatan dengan penggantian sistem disk diperlukan dalam skenario berikut:
Alternatif: Peningkatan Rolling melalui Kelompok Node Baru
Ambil alternatif dengan membuat kelompok node baru yang memiliki konfigurasi target, alih-alih meningkatkan node yang ada. Migrasikan aplikasi secara bertahap dengan mengatur kelompok node lama menjadi unschedulable atau memperbarui penjadwalan beban kerja. Setelah migrasi diverifikasi, hapus kelompok node lama.
Anda akan ditagih untuk kedua kelompok node selama keduanya aktif; segera hapus kelompok lama setelah migrasi untuk mengelola biaya.
FAQ
Bagaimana cara saya melakukan peningkatan kluster secara manual?
Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual. Pertama, selesaikan pemeriksaan awal. Kemudian, lakukan peningkatan dan verifikasi bahwa hasilnya sesuai harapan Anda.
Apa praktik terbaik untuk peningkatan kluster?
Pertahankan frekuensi peningkatan rutin: Pantau panduan versi, dokumen bantuan, dan notifikasi resmi. Lakukan peningkatan segera untuk memastikan dukungan dan keamanan berkelanjutan.
Buat rencana peningkatan: Karena peningkatan melibatkan perubahan besar seperti penghapusan API, buat rencana peningkatan terperinci berdasarkan ukuran kluster dan kebutuhan bisnis. Sediakan jendela maintenance pada jam sepi dan validasi peningkatan di lingkungan pengujian sebelum menerapkannya ke lingkungan produksi.
Gunakan peningkatan otomatis: Anda dapat menggunakan fitur peningkatan kluster otomatis. ACK menghasilkan rencana peningkatan terlebih dahulu, memicu pemeriksaan awal, dan meningkatkan kluster dalam jendela maintenance yang ditentukan. Hal ini mengurangi beban O&M manajemen versi.
Anda juga dapat membuat kluster ACK yang dikelola dalam Intelligent Hosting Mode. Versi kluster tersebut secara otomatis ditingkatkan oleh ACK.
Berapa lama waktu yang dibutuhkan untuk peningkatan kluster?
Lapisan kontrol: Untuk kluster ACK yang dikelola dan kluster ACK Serverless, peningkatan dikelola oleh ACK dan memakan waktu sekitar 5 menit. Untuk cluster khusus ACK, node master ditingkatkan secara berurutan, yang memakan waktu sekitar 8 menit per node.
Kelompok node: Durasi tergantung pada konfigurasi batching node. Peningkatan in-place memakan waktu sekitar 5 hingga 10 menit per batch. Peningkatan dengan penggantian sistem disk tanpa snapshot memakan waktu sekitar 8 menit per batch, tetapi durasi aktual dipengaruhi oleh proses draining node. Jika Anda memilih untuk membuat snapshot, proses peningkatan menunggu hingga snapshot selesai dibuat. Waktu yang dibutuhkan untuk membuat snapshot tergantung pada jumlah data.
Apakah saya bisa tetap menggunakan satu versi selamanya dan tidak meningkatkan kluster saya?
Tidak, Anda tidak bisa. Risiko keamanan potensial pada versi kedaluwarsa dapat memengaruhi tidak hanya kluster Anda tetapi juga keamanan keseluruhan Alibaba Cloud. ACK tidak mengizinkan kluster tetap dalam keadaan kedaluwarsa dalam jangka waktu lama dan akan melakukan peningkatan paksa untuk membawanya ke versi yang aman dan stabil.
Kami menyarankan Anda segera meningkatkan versi kluster Anda. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual. Hal ini memungkinkan Anda memanfaatkan fitur terbaru dan menerima dukungan teknis yang lebih baik dari ACK. Sebelum peningkatan, lihat catatan rilis untuk versi target guna memahami perubahan fitur dan catatan pentingnya. Aktifkan fitur peningkatan kluster otomatis untuk memastikan kluster Anda ditingkatkan secara otomatis dan berkala.
Apakah ACK mendukung melewati versi minor selama peningkatan?
Tidak, tidak mendukung. Anda harus meningkatkan kluster satu versi minor dalam satu waktu. Selain itu, sebelum meningkatkan lapisan kontrol kluster, pastikan versi node kluster sama dengan versi lapisan kontrol.
Versi kluster saya sangat lama. Bagaimana cara mempercepat peningkatannya?
Anda dapat menggunakan salah satu solusi berikut.
Solusi 1: Tingkatkan kluster satu versi minor dalam satu waktu. Setelah setiap peningkatan, periksa apakah aplikasi bisnis Anda di kluster berjalan sebagaimana mestinya sebelum melanjutkan ke peningkatan berikutnya. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual.
Solusi 2: Buat kluster yang menjalankan versi terbaru, migrasikan aplikasi Anda secara bertahap ke kluster baru tersebut, lalu nonaktifkan kluster lama. Untuk informasi tentang cara membuat dan mengonfigurasi kluster, lihat Buat kluster ACK yang dikelola.
Bagaimana cara beralih dari Docker ke containerd saat meningkatkan kluster dari versi 1.22 ke 1.24?
ACK tidak lagi mendukung Docker sebagai runtime kontainer bawaan mulai versi 1.24 ke atas. Anda harus memigrasikan runtime kontainer node Anda dari Docker ke containerd.
Anda dapat mengganti runtime pada kelompok node asli menggunakan fitur peningkatan kelompok node, atau membuat kelompok node containerd baru dan memigrasikan beban kerja Anda. Untuk informasi lebih lanjut, lihat Migrasikan runtime kontainer node dari Docker ke containerd.
Bagaimana ACK memastikan stabilitas selama peningkatan kluster?
Kluster ACK terdiri dari lapisan kontrol dan kelompok node.
Peningkatan lapisan kontrol: ACK menyediakan fitur pemeriksaan pra-peningkatan yang memeriksa API yang sudah ditinggalkan, kompatibilitas komponen, kompatibilitas konfigurasi fitur, dan komponen lapisan kontrol. Hasil pemeriksaan tidak memengaruhi operasi normal aplikasi di kluster. Jika pemeriksaan gagal, saran perbaikan disediakan di Konsol. Untuk informasi lebih lanjut, lihat Tingkatkan kluster secara manual.
Peningkatan kelompok node: Peningkatan kelompok node mencakup peningkatan kubelet dan containerd. ACK menyediakan fitur pemeriksaan pra-peningkatan yang memeriksa status node, sumber daya sistem, status disk, dan lingkungan jaringan. Hasil pemeriksaan tidak memengaruhi operasi normal aplikasi di kluster. Jika pemeriksaan gagal, saran perbaikan disediakan di Konsol.
Anda juga dapat mengonfigurasi kebijakan peningkatan untuk mengontrol kecepatan peningkatan. Misalnya, Anda dapat menentukan node yang akan ditingkatkan, mengatur jumlah maksimum node yang dapat ditingkatkan dalam setiap batch, dan mengonfigurasi kebijakan jeda peningkatan. Jika sistem disk node Anda berisi data bisnis penting, Anda juga dapat membuat snapshot untuk node tersebut sebelum meningkatkan kelompok node. Untuk informasi lebih lanjut, lihat Tingkatkan kelompok node.
Apakah kluster dengan versi kedaluwarsa masih dapat digunakan secara normal?
Ya. Namun, kluster kedaluwarsa memiliki risiko keamanan dan stabilitas. Segera tingkatkan ke versi yang masih didukung.
Karena arsitektur kluster ACK bersifat managed, 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 keadaan kedaluwarsa dalam jangka waktu lama dan akan melakukan peningkatan wajib ke versi yang aman dan stabil. Untuk informasi lebih lanjut, lihat Peningkatan wajib versi kedaluwarsa.
Apakah rollback versi didukung setelah peningkatan kluster?
Tidak. Rollback tidak didukung untuk versi lapisan kontrol, kubelet, atau runtime kontainer setelah peningkatan.
Selama peningkatan kelompok node, jika data layanan penting disimpan pada sistem disk node, buat snapshot untuk node tersebut sebelum peningkatan guna mencadangkan dan memulihkan data node.
Operasi apa yang harus saya lakukan terlebih dahulu jika saya perlu meningkatkan kluster dan memigrasikannya ke kluster ACK Pro yang dikelola?
Selesaikan migrasi kluster sebelum memulai peningkatan. Setelah layanan diverifikasi stabil, lanjutkan dengan pembaruan versi.
Apa yang harus saya lakukan jika pemeriksaan awal melaporkan API yang sudah ditinggalkan?
Untuk Kubernetes 1.20 ke atas, ACK menyediakan notifikasi untuk API yang sudah ditinggalkan. Meskipun hal ini tidak menghambat peningkatan, perbaiki masalah tersebut terlebih dahulu untuk memastikan kompatibilitas aplikasi dengan versi baru.
Bagaimana cara mengatasi peringatan "versi komponen terlalu rendah" dalam pemeriksaan awal?
ACK hanya meningkatkan lapisan kontrol dan komponen inti tertentu seperti kube-proxy. Identifikasi komponen lain yang perlu diperbarui melalui halaman Add-ons di Konsol. Anda dapat melihat komponen yang perlu ditingkatkan. Sebelum melanjutkan, tinjau Ikhtisar komponen dan catatan rilis untuk memastikan kompatibilitas versi. Jadwalkan peningkatan komponen tersebut pada jam sepi untuk meminimalkan dampak terhadap layanan.
Bagaimana cara mengatasi kegagalan peningkatan dengan error "the aliyun service is not running on the instance"?
Error ini terjadi karena Asisten Cloud tidak tersedia, sehingga perintah peningkatan gagal. Mulai atau restart Asisten Cloud, lalu coba lagi peningkatan kluster. Untuk informasi lebih lanjut, lihat Mulai, hentikan, atau uninstal Cloud Assistant Agent.
Bagaimana cara mengatasi error "PLEG not healthy" pada node?
Error ini menunjukkan bahwa kontainer atau runtime kontainer tidak merespons. Restart node tersebut, lalu coba lagi peningkatan.
Apa yang harus saya lakukan jika mendapatkan error invalid object doesn't have additional properties saat meningkatkan kluster?
Setelah Anda meningkatkan kluster, Anda juga harus meningkatkan versi kubectl lokal Anda. Jika Anda tidak segera memperbaruinya, Anda mungkin mengalami error seperti invalid object doesn't have additional properties saat menggunakan kubectl lokal karena versinya berbeda dengan versi API Server kluster. Untuk informasi lebih lanjut tentang cara menginstal atau meningkatkan kubectl, lihat Install and Set Up kubectl. Sangat penting untuk menyelaraskan versi kubectl Anda dengan versi API server kluster guna mencegah masalah kompatibilitas.