Panduan patch dan peningkatan Azure Kubernetes Service

Bagian panduan operasi hari-2 Azure Kubernetes Service (AKS) ini menjelaskan patching dan peningkatan strategi untuk simpul pekerja AKS dan versi Kubernetes. Sebagai operator kluster, Anda harus memiliki rencana untuk menjaga kluster Anda tetap terbaru dan memantau perubahan dan penghentian API Kubernetes dari waktu ke waktu.

Latar belakang dan jenis pembaruan

Ada tiga jenis pembaruan untuk AKS, masing-masing satu bangunan pada yang berikutnya:

Jenis Pembaruan	Frekuensi peningkatan	Pemeliharaan Terencana didukung	Metode operasi yang didukung	Target	Link ke dokumentasi
Patch keamanan OS simpul	Setiap malam	Ya	Otomatis (mingguan), manual/tidak terkelola (malam hari)	Simpul	Gambar Simpul Peningkatan Otomatis
Peningkatan versi gambar node	Linux: Mingguan Windows: Bulanan	Ya	Otomatis, manual	Kumpulan simpul	Peningkatan gambar simpul AKS
Peningkatan versi Kubernetes (kluster)	Triwulanan	Ya	Otomatis, manual	Kumpulan kluster dan simpul	Peningkatan kluster AKS

Jenis pembaruan

• Patch keamanan OS simpul (khusus Linux). Untuk node Linux, Canonical Ubuntu dan Azure Linux membuat patch keamanan sistem operasi tersedia sekali per hari. Microsoft menguji dan menggabungkan patch ini dalam pembaruan mingguan untuk gambar simpul.

• Pembaruan mingguan untuk gambar simpul. AKS menyediakan pembaruan mingguan untuk gambar simpul. Pembaruan ini mencakup patch keamanan OS dan AKS terbaru, perbaikan bug, dan peningkatan. Pembaruan node tidak mengubah versi Kubernetes. Versi diformat menurut tanggal (misalnya, 202311.07.0) untuk Linux dan berdasarkan build dan tanggal OS Windows Server (misalnya, 20348.2113.231115) untuk Windows. Untuk informasi selengkapnya, lihat Status Rilis AKS.

• Rilis Kubernetes triwulanan. AKS menyediakan pembaruan triwulanan untuk rilis Kubernetes. Pembaruan ini memungkinkan pengguna AKS untuk memanfaatkan fitur dan penyempurnaan Kubernetes terbaru. Mereka termasuk patch keamanan dan pembaruan gambar simpul. Untuk informasi selengkapnya, lihat Versi Kubernetes yang didukung di AKS.

Pertimbangan pra-peningkatan

Dampak kluster keseluruhan

• Peningkatan di tempat (node dan kluster) memengaruhi performa lingkungan Kubernetes saat sedang berlangsung. Anda dapat meminimalkan efek ini melalui konfigurasi anggaran gangguan pod yang tepat, konfigurasi lonjakan simpul, dan perencanaan yang tepat.
• Menggunakan strategi pembaruan biru/hijau alih-alih meningkatkan di tempat menghilangkan dampak apa pun terhadap performa kluster tetapi meningkatkan biaya dan kompleksitas.
• Terlepas dari strategi peningkatan dan patching Anda, Anda harus memiliki proses pengujian dan validasi yang kuat untuk kluster Anda. Patch dan tingkatkan lingkungan yang lebih rendah terlebih dahulu, dan lakukan validasi pasca-pemeliharaan untuk memeriksa kluster, simpul, penyebaran, dan kesehatan aplikasi.

Praktik terbaik beban kerja AKS

Untuk memastikan kelancaran pengoperasian kluster AKS Anda selama pemeliharaan, ikuti praktik terbaik berikut:

• Tentukan anggaran gangguan pod (PDB). Menyiapkan anggaran gangguan pod untuk penyebaran Anda sangat penting. PDB memberlakukan jumlah minimum replika aplikasi yang tersedia untuk memastikan fungsionalitas berkelanjutan selama peristiwa gangguan. PDB membantu menjaga stabilitas kluster Anda selama pemeliharaan atau kegagalan node.

  Peringatan

  PDB yang salah dikonfigurasi dapat memblokir proses peningkatan karena API Kubernetes mencegah cordon dan pengurasan yang diperlukan yang terjadi dengan peningkatan gambar simpul bergulir. Selain itu, jika terlalu banyak pod dipindahkan secara bersamaan, pemadaman aplikasi dapat terjadi. Konfigurasi PDB mengurangi risiko ini.

• Periksa batas komputasi dan jaringan yang tersedia. Verifikasi batas komputasi dan jaringan yang tersedia di langganan Azure Anda melalui halaman kuota di portal Azure, atau dengan menggunakan perintah kuota az. Periksa sumber daya komputasi dan jaringan, terutama VM vCPU untuk simpul Anda, dan jumlah komputer virtual dan set skala komputer virtual. Jika Anda mendekati batas, minta penambahan kuota sebelum meningkatkan.
• Periksa ruang IP yang tersedia di subnet simpul. Selama pembaruan, node lonjakan tambahan dibuat di kluster Anda dan Pod dipindahkan ke simpul ini. Penting bagi Anda untuk memantau ruang alamat IP di subnet simpul Anda untuk memastikan ada cukup ruang alamat agar perubahan ini terjadi. Konfigurasi jaringan Kubernetes yang berbeda memiliki persyaratan IP yang berbeda. Sebagai titik awal, tinjau pertimbangan berikut:
  • Selama peningkatan, jumlah IP simpul meningkat sesuai dengan nilai lonjakan Anda. (Nilai lonjakan minimum adalah 1.)
  • Kluster yang didasarkan pada Azure CNI menetapkan alamat IP ke pod individual, sehingga perlu ada ruang IP yang cukup untuk pergerakan pod.
  • Kluster Anda terus beroperasi selama peningkatan. Pastikan bahwa ada cukup ruang IP yang tersisa untuk memungkinkan penskalakan simpul (jika diaktifkan).
• Atur beberapa lingkungan. Sebaiknya Siapkan lingkungan terpisah, seperti pengembangan, penahapan, dan produksi, untuk memungkinkan Anda menguji dan memvalidasi perubahan sebelum meluncurkannya ke produksi.
• Menyetel nilai peningkatan lonjakan. Secara default, AKS memiliki nilai lonjakan 1, yang berarti bahwa satu simpul tambahan dibuat pada satu waktu sebagai bagian dari proses peningkatan. Anda dapat meningkatkan kecepatan peningkatan AKS dengan meningkatkan nilai ini. Lonjakan 33% adalah nilai maksimum yang direkomendasikan untuk beban kerja yang sensitif terhadap gangguan. Untuk informasi selengkapnya, lihat Menyesuaikan peningkatan lonjakan simpul.
• Menyetel batas waktu pengurasan node. Batas waktu pengurasan simpul menentukan jumlah waktu maksimum kluster akan menunggu saat mencoba menjadwalkan ulang pod pada simpul yang diperbarui. Nilai default untuk ini adalah 30 menit. Untuk beban kerja yang berjuang untuk menjadwalkan ulang pod, akan sangat membantu untuk menyesuaikan nilai default ini.
• Rencanakan dan jadwalkan jendela pemeliharaan. Proses peningkatan dapat memengaruhi performa keseluruhan kluster Kubernetes Anda. Jadwalkan proses peningkatan di tempat di luar jendela penggunaan puncak, dan pantau performa kluster untuk memastikan ukuran yang memadai, terutama selama proses pembaruan.
• Periksa dependensi lain di kluster Anda. Operator Kubernetes sering menyebarkan alat lain ke kluster Kubernetes sebagai bagian dari operasi, seperti scaler KEDA, Dapr, dan jala layanan. Saat Anda merencanakan proses peningkatan, periksa catatan rilis untuk komponen apa pun yang Anda gunakan untuk memastikan kompatibilitas dengan versi target.

Mengelola pembaruan mingguan untuk gambar simpul

Microsoft membuat gambar simpul baru untuk simpul AKS sekitar sekali per minggu. Gambar simpul berisi patch keamanan OS terbaru, pembaruan kernel OS, pembaruan keamanan Kubernetes, versi biner yang diperbarui seperti kubelet, dan pembaruan versi komponen yang tercantum dalam catatan rilis.

Saat gambar simpul diperbarui, tindakan cordon dan pengurasan dipicu pada simpul kumpulan simpul target:

• Simpul dengan gambar yang diperbarui ditambahkan ke kumpulan simpul. Jumlah simpul yang ditambahkan pada saat yang sama diatur oleh nilai lonjakan.
• Tergantung pada nilai lonjakan, batch simpul yang ada berkode dan dikosongkan. Cordoning memastikan bahwa simpul tidak menjadwalkan pod. Pengurasan menghapus pod-nya dan menjadwalkannya ke simpul lain.
• Setelah node ini sepenuhnya dikosongkan, simpul dihapus dari kumpulan simpul. Simpul yang diperbarui ditambahkan oleh lonjakan menggantinya.
• Proses ini diulang untuk setiap batch simpul yang tersisa yang perlu diperbarui di kumpulan simpul.

Proses serupa terjadi selama peningkatan kluster.

Peningkatan gambar simpul otomatis

Secara umum, sebagian besar kluster harus menggunakan NodeImage saluran pembaruan. Saluran ini menyediakan VHD gambar simpul yang diperbarui setiap minggu dan diperbarui sesuai dengan jendela pemeliharaan kluster Anda.

Saluran yang tersedia meliputi yang berikut ini:

• None. Tidak ada pembaruan yang diterapkan secara otomatis.
• Unmanaged. Pembaruan Ubuntu dan Azure Linux diterapkan oleh OS setiap malam. Boot ulang harus dikelola secara terpisah. AKS tidak dapat menguji ini atau mengontrol irama ini.
• SecurityPatch. Patch keamanan OS yang diuji AKS, dikelola sepenuhnya, dan diterapkan dengan praktik penyebaran yang aman. Ini tidak berisi perbaikan bug OS hanya pembaruan keamanan.
• NodeImage. AKS memperbarui simpul dengan VHD yang baru di-patch yang berisi perbaikan keamanan dan perbaikan bug pada irama mingguan. Ini sepenuhnya diuji dan disebarkan dengan praktik penyebaran yang aman. Untuk informasi real time tentang gambar simpul yang saat ini disebarkan, lihat Pembaruan gambar simpul AKS.

Untuk memahami irama default tanpa jendela pemeliharaan yang ditetapkan, lihat memperbarui kepemilikan dan irama.

Jika Anda memilih Unmanaged saluran pembaruan, Anda perlu mengelola proses reboot dengan menggunakan alat seperti kured. Unmanaged tidak dilengkapi dengan praktik penyebaran aman yang disediakan AKS dan tidak akan berfungsi di bawah jendela pemeliharaan. Jika Anda memilih SecurityPatch saluran pembaruan, pembaruan dapat diterapkan sesering mingguan. Tingkat patch ini mengharuskan VHD disimpan di grup sumber daya Anda, yang dikenakan biaya nominal. Kontrol saat SecurityPatch diterapkan dengan mengatur yang sesuai aksManagedNodeOSUpgradeSchedule yang selaras dengan irama yang paling sesuai untuk beban kerja Anda. Untuk informasi selengkapnya, lihat Membuat jendela pemeliharaan. Jika Anda juga memerlukan perbaikan bug yang biasanya dilengkapi dengan gambar node baru (VHD), maka Anda perlu memilih NodeImage saluran alih-alih SecurityPatch.

Sebagai praktik terbaik, gunakan NodeImage saluran pembaruan dan konfigurasikan aksManagedNodeOSUpgradeSchedule jendela pemeliharaan ke waktu ketika kluster berada di luar jendela penggunaan puncak. Lihat Membuat jendela pemeliharaan untuk atribut yang dapat Anda gunakan untuk mengonfigurasi jendela pemeliharaan kluster. Atribut utamanya adalah:

• name. Gunakan aksManagedNodeOSUpgradeSchedule untuk pembaruan OS simpul.
• utcOffset. Konfigurasikan zona waktu.
• startTime. Atur waktu mulai jendela pemeliharaan.
• dayofWeek. Atur hari dalam seminggu untuk jendela. Contohnya,Saturday.
• schedule. Atur frekuensi jendela. Untuk NodeImage pembaruan, kami sarankan weekly.
• durationHours. Atur atribut ini ke setidaknya empat jam.

Contoh ini menetapkan jendela pemeliharaan mingguan ke pukul 20.00 Waktu Timur pada hari Sabtu:

az aks maintenanceconfiguration add -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule --utc-offset=-05:00 --start-time 20:00 --day-of-week Saturday --schedule-type weekly --duration 4

Untuk contoh selengkapnya, lihat Menambahkan konfigurasi jendela pemeliharaan dengan Azure CLI.

Konfigurasi ini idealnya akan disebarkan sebagai bagian dari penyebaran infrastruktur sebagai kode kluster.

Anda dapat memeriksa jendela pemeliharaan yang dikonfigurasi dengan menggunakan Azure CLI:

az aks maintenanceconfiguration list -g <ResourceGroupName> --cluster-name <AKSClusterName>

Anda juga dapat memeriksa detail jendela pemeliharaan tertentu dengan menggunakan CLI:

az aks maintenanceconfiguration show -g <ResourceGroupName> --cluster-name <AKSClusterName> --name aksManagedNodeOSUpgradeSchedule

Jika jendela pemeliharaan kluster tidak dikonfigurasi, pembaruan gambar simpul terjadi dua kali. Sebanyak mungkin, pemeliharaan AKS terjadi dalam jendela yang dikonfigurasi, tetapi waktu pemeliharaan tidak dijamin.

Penting

Jika Anda memiliki kumpulan simpul dengan sejumlah besar simpul tetapi tidak dikonfigurasi dengan lonjakan simpul, peristiwa peningkatan otomatis mungkin tidak memicu. Gambar simpul dalam kumpulan simpul hanya akan ditingkatkan sementara perkiraan total waktu peningkatan dalam waktu 24 jam.

Dalam situasi ini, Anda dapat mempertimbangkan salah satu hal berikut:

• membagi simpul menjadi kumpulan simpul yang berbeda jika kuota vCPU Anda hampir penuh dan Anda tidak dapat meningkatkan kuota vCPU
• mengonfigurasi lonjakan simpul untuk mengurangi perkiraan waktu peningkatan jika kuota vCPU Anda sudah cukup

Anda dapat memeriksa status peristiwa peningkatan melalui log aktivitas Azure Anda, atau dengan meninjau log sumber daya di kluster Anda.

Anda dapat Berlangganan peristiwa Azure Kubernetes Service (AKS) dengan Azure Event Grid yang mencakup peristiwa peningkatan AKS. Peristiwa ini dapat memberi tahu Anda ketika versi baru Kubernetes tersedia dan membantu melacak perubahan status simpul selama proses peningkatan.

Anda juga dapat mengelola proses pembaruan mingguan dengan menggunakan GitHub Actions. Metode ini memberikan kontrol yang lebih terperinci dari proses pembaruan.

Proses pembaruan simpul manual

Anda dapat menggunakan perintah kubectl describe node untuk menentukan versi kernel OS dan versi gambar OS dari node di kluster Anda:

kubectl describe nodes <NodeName>

Contoh output (terpotong):

System Info:
  Machine ID:                 bb2e85e682ae475289f2e2ca4ed6c579
  System UUID:                6f80de9d-91ba-490c-8e14-9e68b7b82a76
  Boot ID:                    3aed0fd5-5d1d-4e43-b7d6-4e840c8ee3cf
  Kernel Version:             5.15.0-1041-azure
  OS Image:                   Ubuntu 22.04.2 LTS
  Operating System:           linux
  Architecture:               arm64
  Container Runtime Version:  containerd://1.7.1+azure-1
  Kubelet Version:            v1.26.6
  Kube-Proxy Version:         v1.26.6

Gunakan perintah az aks nodepool list Azure CLI untuk menentukan versi gambar node simpul dalam kluster:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,NodeImageVersion:nodeImageVersion}" --output table

Contoh output:

Name       NodeImageVersion
---------  ---------------------------------------------
systempool  AKSUbuntu-2204gen2containerd-202307.12.0
usernodepool  AKSUbuntu-2204gen2arm64containerd-202307.12.0

Gunakan az aks nodepool get-upgrades untuk menentukan versi gambar simpul terbaru yang tersedia untuk kumpulan simpul tertentu:

az aks nodepool get-upgrades \
   --resource-group <ResourceGroupName> \
   --cluster-name <AKSClusterName> \
   --nodepool-name <NodePoolName> --output table

Contoh output:

KubernetesVersion    LatestNodeImageVersion                         Name     OsType
-------------------  ---------------------------------------------  -------  --------
1.26.6               AKSUbuntu-2204gen2arm64containerd-202308.10.0  default  Linux

Peningkatan kluster

Komunitas Kubernetes merilis versi minor Kubernetes kira-kira setiap tiga bulan. Untuk memberi Anda informasi tentang versi dan rilis AKS baru, halaman catatan rilis AKS diperbarui secara berkala. Anda juga dapat berlangganan umpan GitHub AKS RSS, yang menyediakan pembaruan real time tentang perubahan dan peningkatan.

AKS mengikuti kebijakan dukungan N - 2 , yang berarti bahwa dukungan penuh disediakan untuk rilis terbaru (N) dan dua versi minor sebelumnya. Dukungan platform terbatas ditawarkan untuk versi minor ketiga sebelumnya. Untuk informasi selengkapnya, lihat Kebijakan dukungan AKS.

Untuk memastikan bahwa kluster AKS Anda tetap didukung, Anda perlu membuat proses peningkatan kluster berkelanjutan. Proses ini melibatkan pengujian versi baru di lingkungan yang lebih rendah dan merencanakan peningkatan ke produksi sebelum versi baru menjadi default. Pendekatan ini dapat mempertahankan prediktabilitas dalam proses peningkatan Anda dan meminimalkan gangguan pada aplikasi. Untuk informasi selengkapnya, lihat Meningkatkan kluster AKS.

Jika kluster Anda memerlukan siklus peningkatan yang lebih lama, gunakan versi AKS yang mendukung opsi Dukungan Jangka Panjang (LTS). Jika Anda mengaktifkan opsi LTS, Microsoft menyediakan dukungan yang diperluas untuk versi Kubernetes selama dua tahun, yang memungkinkan siklus peningkatan yang lebih lama dan terkontrol. Untuk informasi selengkapnya, lihat Versi Kubernetes yang didukung di AKS.

Peningkatan kluster mencakup peningkatan node dan menggunakan proses cordon dan pengurasan serupa.

Sebelum Anda meningkatkan

Sebagai praktik terbaik, Anda harus selalu meningkatkan dan menguji di lingkungan yang lebih rendah untuk meminimalkan risiko gangguan dalam produksi. Peningkatan kluster memerlukan pengujian tambahan karena melibatkan perubahan API, yang dapat memengaruhi penyebaran Kubernetes. Sumber daya berikut dapat membantu Anda dalam proses peningkatan:

• Buku kerja AKS untuk API yang tidak digunakan lagi. Dari halaman gambaran umum kluster di portal Azure, Anda dapat memilih Diagnosis dan selesaikan masalah, buka kategori Buat, Tingkatkan, Hapus, dan Skala, lalu pilih penghentian API Kubernetes. Melakukannya menjalankan buku kerja yang memeriksa versi API yang tidak digunakan lagi yang digunakan di kluster Anda. Untuk informasi selengkapnya, lihat Menghapus penggunaan API yang tidak digunakan lagi.
• Halaman catatan rilis AKS. Halaman ini menyediakan informasi komprehensif tentang versi dan rilis AKS baru. Tinjau catatan ini untuk tetap mendapatkan informasi tentang pembaruan dan perubahan terbaru.
• Halaman catatan rilis Kubernetes. Halaman ini memberikan wawasan terperinci tentang versi Kubernetes terbaru. Beri perhatian khusus pada catatan peningkatan mendesak, yang menyoroti informasi penting yang mungkin memengaruhi kluster AKS Anda.
• Komponen AKS melanggar perubahan berdasarkan versi. Tabel ini memberikan gambaran umum komprehensif tentang perubahan yang melanggar dalam komponen AKS, berdasarkan versi. Dengan merujuk ke panduan ini, Anda dapat secara proaktif mengatasi potensi masalah kompatibilitas sebelum proses peningkatan.

Selain sumber daya Microsoft ini, pertimbangkan untuk menggunakan alat sumber terbuka untuk mengoptimalkan proses peningkatan kluster Anda. Salah satu alat tersebut adalah Fairwinds pluto, yang dapat memindai penyebaran dan bagan Helm untuk API Kubernetes yang tidak digunakan lagi. Alat-alat ini dapat membantu Anda memastikan bahwa aplikasi Anda tetap kompatibel dengan versi Kubernetes terbaru.

Proses peningkatan

Untuk memeriksa kapan kluster Anda memerlukan peningkatan, gunakan az aks get-upgrades untuk mendapatkan daftar versi peningkatan yang tersedia untuk kluster AKS Anda. Tentukan versi target untuk kluster Anda dari hasil.

Berikut contohnya:

az aks get-upgrades \
   --resource-group <ResourceGroupName> --name <AKSClusterName> --output table

Contoh output:

MasterVersion  Upgrades
-------------  ---------------------------------
1.26.6         1.27.1, 1.27.3

Periksa versi Kubernetes dari simpul di kumpulan simpul Anda untuk menentukan kumpulan yang perlu ditingkatkan:

az aks nodepool list \
   --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> \
   --query "[].{Name:name,k8version:orchestratorVersion}" --output table

Contoh output:

Name          K8version
------------  ------------
systempool    1.26.6
usernodepool  1.26.6

Memutakhirkan secara manual

Untuk meminimalkan gangguan dan membantu memastikan peningkatan yang lancar untuk kluster AKS Anda, ikuti pendekatan peningkatan ini:

1. Tingkatkan sarana kontrol AKS. Mulailah dengan meningkatkan sarana kontrol AKS. Langkah ini melibatkan peningkatan komponen sarana kontrol yang bertanggung jawab untuk mengelola dan mengatur kluster Anda. Meningkatkan sarana kontrol terlebih dahulu membantu memastikan kompatibilitas dan stabilitas sebelum Anda meningkatkan kumpulan simpul individual.
2. Tingkatkan kumpulan simpul sistem Anda. Setelah Anda meningkatkan sarana kontrol, tingkatkan kumpulan simpul sistem di kluster AKS Anda. Kumpulan simpul terdiri dari instans komputer virtual yang menjalankan beban kerja aplikasi Anda. Meningkatkan kumpulan simpul secara terpisah memungkinkan peningkatan infrastruktur yang mendasar dan sistematis yang terkontrol dan sistematis yang mendukung aplikasi Anda.
3. Tingkatkan kumpulan simpul pengguna. Setelah Anda meningkatkan kumpulan simpul sistem, tingkatkan kumpulan simpul pengguna apa pun di kluster AKS Anda.

Dengan mengikuti pendekatan ini, Anda dapat meminimalkan gangguan selama proses peningkatan dan mempertahankan ketersediaan aplikasi Anda. Berikut adalah langkah-langkah terperinci:

1. Jalankan perintah az aks upgrade dengan --control-plane-only bendera untuk meningkatkan hanya sarana kontrol kluster dan bukan kumpulan simpul kluster:

   az aks upgrade \
      --resource-group <ResourceGroupName> --name <AKSClusterName> \
      --control-plane-only \
      --kubernetes-version <KubernetesVersion>
   

2. Jalankan peningkatan nodepool az aks untuk meningkatkan kumpulan node ke versi target:

   az aks nodepool upgrade \
      --resource-group <ResourceGroupName> --cluster-name <AKSClusterName> --name <NodePoolName> \
      --no-wait --kubernetes-version <KubernetesVersion>
   

   Selama peningkatan kumpulan simpul, AKS membuat simpul lonjakan, cordon, dan menguras pod dalam simpul yang sedang ditingkatkan, mencitrakan ulang simpul, dan kemudian membatalkan pengaturan pod. Proses ini kemudian berulang untuk node lain di kumpulan simpul.

Anda dapat memeriksa status proses peningkatan dengan menjalankan kubectl get events. Untuk informasi tentang pemecahan masalah peningkatan kluster, lihat dokumentasi pemecahan masalah AKS.

Mendaftarkan kluster di saluran rilis peningkatan otomatis

AKS juga menawarkan solusi peningkatan kluster otomatis untuk menjaga kluster Anda tetap terbarui. Jika Anda menggunakan solusi ini, Anda harus memasangkannya dengan jendela pemeliharaan untuk mengontrol waktu peningkatan. Jendela peningkatan harus empat jam atau lebih. Saat Anda mendaftarkan kluster di saluran rilis, Microsoft secara otomatis mengelola versi dan meningkatkan irama untuk kluster dan kumpulan simpulnya.

Peningkatan otomatis kluster menawarkan opsi saluran rilis yang berbeda. Berikut adalah lingkungan yang direkomendasikan dan konfigurasi saluran rilis:

Lingkungan	Meningkatkan saluran	Deskripsi
Produksi	stable	Untuk stabilitas dan kematangan versi, gunakan saluran stabil atau reguler untuk beban kerja produksi.
Penahapan, pengujian, pengembangan	Sama seperti produksi	Untuk memastikan bahwa pengujian Anda menunjukkan versi tempat Anda akan meningkatkan lingkungan produksi, gunakan saluran rilis yang sama dengan produksi.
Kenari	rapid	Untuk menguji rilis Kubernetes terbaru dan fitur atau API AKS baru, gunakan rapid saluran . Anda dapat meningkatkan waktu Anda untuk memetakan saat versi dipromosikan rapid ke saluran yang Anda gunakan untuk produksi.

Pertimbangan

Tabel berikut menjelaskan karakteristik berbagai skenario peningkatan dan patching AKS:

Skenario	Dimulai pengguna	Peningkatan Kubernetes	Peningkatan OS kernel	Pembaruan citra node
Penambal keamanan	Tidak	Tidak	Ya, setelah boot ulang	Ya
Pembuatan kluster	Ya	Mungkin	Ya, jika gambar node yang diperbarui menggunakan kernel yang diperbarui	Ya, relatif terhadap kluster yang ada jika rilis baru tersedia
Peningkatan Kubernetes sarana kontrol	Ya	Ya	No	Tidak
Peningkatan Kubernetes kumpulan simpul	Ya	Ya	Ya, jika gambar node yang diperbarui menggunakan kernel yang diperbarui	Ya, jika rilis baru tersedia
Peningkatan skala kumpulan simpul	Ya	No	No	Tidak
Pembaruan citra node	Ya	Tidak	Ya, jika gambar node yang diperbarui menggunakan kernel yang diperbarui	Ya
Peningkatan otomatis kluster	Tidak	Ya	Ya, jika gambar node yang diperbarui menggunakan kernel yang diperbarui	Ya, jika rilis baru tersedia

• Patch keamanan OS yang diterapkan sebagai bagian dari peningkatan gambar simpul mungkin menginstal versi kernel yang lebih baru daripada pembuatan kluster baru yang akan diinstal.
• Peningkatan skala kumpulan simpul menggunakan model yang saat ini terkait dengan set skala komputer virtual. Kernel OS ditingkatkan saat patch keamanan diterapkan, dan simpul di-boot ulang.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

• Anthony Nevico | Arsitek Solusi Cloud Utama

Kontributor lain:

• Rishabh Saha | Arsitek Solusi Utama
• Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Ali Yousefi | Arsitek Solusi Cloud

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah berikutnya

• Dokumentasi produk AKS
• Pelacak rilis AKS
• Peta jalan AKS
• Akselerator zona pendaratan AKS
• Memecahkan masalah AKS
• Mengoptimalkan peningkatan AKS
• Tanya Jawab Umum Peningkatan OS Node
• Set konstruksi AKS
• Otomatisasi garis besar AKS
• Menentukan Operasi Hari-2

Sumber daya terkait

• Panduan operasi hari-2 AKS
• Praktik triase AKS