Kebijakan Gangguan Node di Azure Kubernetes Service (AKS) (Pratinjau)

Saat Anda mengelola dan memelihara kluster AKS, perubahan konfigurasi tertentu mengharuskan simpul digambarkan ulang. Operasi reimage ini memicu pembaruan bergulir yang membuat ulang simpul. Selama proses reimage, AKS mengordon node (mencegah penjadwalan pod baru), mengosongkan pod yang ada dari node tersebut (mengusir lalu menjadwalkannya ulang ke node lain yang tersedia dengan tetap mematuhi Pod Disruption Budget), lalu melakukan reimage pada node dengan konfigurasi yang diperbarui. Proses ini adalah pembuatan ulang node penuh, bukan sekadar mulai ulang—VM yang mendasarinya diinstal ulang menggunakan image OS baru. Meskipun volume persisten yang dikonfigurasi dengan benar (menggunakan Disk Azure, Azure Files, atau penyimpanan eksternal lainnya) tidak terpengaruh, data apa pun yang disimpan dalam penyimpanan sementara lokal simpul (seperti volume EmptyDir atau jalur lokal) hilang secara permanen. Operasi ini diperlukan untuk menerapkan pembaruan penting, tetapi dapat mengganggu beban kerja yang berjalan dan memengaruhi ketersediaan aplikasi. Node Disruption Policy memberi Anda kontrol mendetail ketika operasi gangguan ini diizinkan untuk melanjutkan, membantu Anda menyeimbangkan kebutuhan akan pembaruan dengan stabilitas operasional.

Important

Fitur pratinjau AKS tersedia atas dasar layanan mandiri dan pendaftaran sukarela. Pratinjau disediakan "apa adanya" dan "sebagaimana tersedia," dan pratinjau tersebut dikecualikan dari perjanjian tingkat layanan (SLA) serta garansi terbatas. Fitur pratinjau AKS sebagian didukung oleh dukungan pelanggan sebatas upaya terbaik. Dengan demikian, fitur-fitur ini tidak dimaksudkan untuk penggunaan produksi. Untuk informasi lebih lanjut, lihat artikel dukungan berikut ini:

Apa itu Kebijakan Gangguan Node?

Node Disruption Policy adalah konfigurasi tingkat kluster yang mengatur kapan operasi yang memerlukan reimage node dan penyebaran ulang dapat dijalankan. Ini bertindak sebagai gerbang kontrol, memungkinkan Anda untuk:

  • Sesuaikan operasi yang berpotensi mengganggu dengan periode pemeliharaan Anda.
  • Cegah perubahan konfigurasi selama periode bisnis kritis sambil tetap mengizinkan peningkatan image node dan patch keamanan dilakukan.
  • Pertahankan perilaku kluster yang dapat diprediksi selama peristiwa lalu lintas tinggi.

Kebijakan ini berlaku untuk perubahan konfigurasi yang diprakarsai pengguna dan memerlukan pembuatan ulang node, seperti memperbarui sertifikat kepercayaan otoritas sertifikat (CA) kustom, memodifikasi pengaturan profil keamanan, atau mengubah konfigurasi OS node.

Note

Yang terpenting, kebijakan ini tidak memblokir pembaruan versi image node (termasuk saluran upgrade SecurityPatch dan NodeImage) maupun upgrade versi Kubernetes. Operasi ini terus dilanjutkan sesuai dengan jadwal yang dikonfigurasi bahkan ketika kebijakan diatur ke Block. Untuk detailnya, lihat Operasi peningkatan yang tidak dikontrol oleh Kebijakan Gangguan Simpul. Selain itu, operasi pemulihan tertentu tidak dikontrol oleh kebijakan ini untuk memastikan kesehatan dan ketersediaan kluster. Untuk detailnya, lihat Operasi pemulihan yang tidak dikontrol oleh Kebijakan Gangguan Simpul.

Cara kerja Kebijakan Gangguan Node

Anda mengonfigurasi Kebijakan Gangguan Node di tingkat kluster melalui nodeDisruptionProfile properti . Saat Anda mencoba operasi yang memerlukan reimage node, AKS memeriksa pengaturan kebijakan saat ini:

  • Evaluasi kebijakan: AKS mengevaluasi apakah operasi diizinkan berdasarkan kebijakan saat ini.
  • Pemeriksaan jendela pemeliharaan (jika berlaku): Jika menggunakan AllowDuringMaintenanceWindow, AKS memverifikasi apakah waktu saat ini termasuk dalam jendela pemeliharaan yang dikonfigurasi.
  • Pelaksanaan atau pemblokiran operasi: Operasi yang mengganggu node akan dilaksanakan jika diizinkan, atau ditolak dengan pesan kesalahan jika diblokir.

Opsi kebijakan

Kebijakan Gangguan Node mendukung tiga konfigurasi kebijakan:

Policy Deskripsi Skenario penggunaan
Allow Memungkinkan operasi yang memerlukan reimage pada node dilanjutkan kapan saja. Ini adalah perilaku default. Gunakan saat Anda ingin memprioritaskan penerapan pembaruan dengan cepat dan dapat mentolerir gangguan beban kerja.
AllowDuringMaintenanceWindow Memblokir operasi yang memerlukan pencitraan ulang node, kecuali jika dilakukan dalam jendela pemeliharaan aksManagedNodeOSUpgradeSchedule. Konfigurasi dapat menggunakan jadwal inline atau menautkan ke periode pemeliharaan bersama. Gunakan saat Anda ingin membatasi gangguan pada jendela pemeliharaan tertentu yang selaras dengan jadwal operasional Anda.
Block Memblokir semua operasi yang memerlukan pengimejan ulang node. Gunakan saat Anda perlu mencegah gangguan node, seperti selama periode bisnis penting atau peristiwa lalu lintas tinggi.

Note

Saat Anda menggunakan AllowDuringMaintenanceWindow, Anda harus mengonfigurasi jendela pemeliharaan aksManagedNodeOSUpgradeSchedule. Konfigurasi pemeliharaan dapat menentukan jadwal secara inline atau mereferensikan jendela pemeliharaan bersama. Untuk informasi selengkapnya tentang menyiapkan jendela pemeliharaan, lihat Menggunakan pemeliharaan terencana untuk menjadwalkan dan mengontrol peningkatan untuk kluster Azure Kubernetes Service Anda. Jika Anda tidak mengonfigurasi jendela pemeliharaan, operasi gangguan node diizinkan.

Considerations

Ingatlah pertimbangan berikut saat menggunakan Kebijakan Gangguan Node:

Operasi yang dicakup dalam Kebijakan Gangguan Node

Operasi tingkat kluster

Pengaktifan kebijakan jaringan dan peningkatan CNI Overlay Azure

Untuk menginstal komponen jaringan yang diperlukan dan mengonfigurasi aturan jaringan yang mengamankan dan mengelola komunikasi pod-ke-pod, Anda perlu menggambar ulang simpul.

Tabel berikut menguraikan peningkatan kebijakan jaringan yang memicu reimage:

Dari Untuk
Tidak ada (tidak ada kebijakan jaringan) Kebijakan Jaringan Azure
Tidak ada (tidak ada kebijakan jaringan) Calico
CNI Azure Azure CNI Overlay (lapisan jaringan CNI Azure)
Kebijakan Jaringan Azure Tidak ada (tidak ada kebijakan jaringan)
Calico Tidak ada (tidak ada kebijakan jaringan)

Note

Beralih antara kebijakan jaringan Azure dan Calico setelah salah satunya diaktifkan tidak memerlukan imaging ulang.

Perubahan pada saluran upgrade OS node

Setiap saluran menggunakan infrastruktur dan konfigurasi patching OS yang berbeda yang tidak dapat Anda ubah pada simpul yang sedang berjalan.

Tabel berikut merinci perubahan kanal upgrade OS node yang memicu reimage:

Dari Untuk
Tidak Dikelola Tidak
Tidak disebutkan Tidak Dikelola
Tambalan Keamanan Tidak Dikelola
NodeImage Tidak Dikelola
Tidak Tidak Dikelola
Tidak disebutkan Tidak Dikelola
Tidak Dikelola Tambalan Keamanan
Tidak Dikelola NodeImage

Pengaktifan tumpukan ganda IPv6

Untuk mendukung komunikasi dual-stack, node memerlukan konfigurasi IP IPv4 dan IPv6 serta pembaruan stack jaringan (seperti aturan nftables).

Tabel berikut menguraikan konfigurasi IP dan pembaruan tumpukan jaringan yang memicu reimage:

Dari Untuk
Hanya IPv4 IPv4 + IPv6 (tumpukan ganda)

Perubahan bidang data Cilium

Anda perlu menginstal atau menghapus program eBPF yang menangani pemrosesan paket di tingkat kernel.

Tabel berikut menguraikan perubahan bidang data Cilium yang memicu gambaran ulang:

Dari Untuk
Tidak Cilium
Cilium Tidak

Pembaruan konfigurasi proksi HTTP

Semua komponen simpul (kontainer, kubelet, layanan sistem) memerlukan konfigurasi proksi yang diperbarui yang diterapkan di seluruh sistem. Saat Anda memperbarui konfigurasi proksi HTTP, AKS secara otomatis menggambar ulang semua kumpulan simpul di kluster.

Node Disruption Policy memicu pencitraan ulang ketika Anda mengubah salah satu properti konfigurasi proksi HTTP berikut atau melakukan salah satu operasi berikut:

  • httpProxy: URL Proksi untuk koneksi HTTP
  • httpsProxy: URL Proksi untuk koneksi HTTPS
  • noProxy: Daftar tujuan yang akan dikecualikan dari proksi
  • trustedCa: Sertifikat CA alternatif yang dikodekan Base64
  • Mengaktifkan proksi HTTP pada kluster (dengan --enable-http-proxy)
  • Menonaktifkan proksi HTTP pada kluster (dengan --disable-http-proxy)
  • Mengaktifkan kembali proksi HTTP pada kluster yang sebelumnya telah dinonaktifkan

sertifikat CA kustom yang diperbarui

Anda harus menginstal sertifikat CA baru di penyimpanan kepercayaan OS untuk memengaruhi validasi TLS untuk layanan internal dan registri privat.

Kebijakan Gangguan Node memicu proses reimage saat Anda menambahkan, menghapus, atau memperbarui sertifikat CA kustom.

Perubahan pada identitas Kubelet

Anda harus menerapkan kredensial identitas baru ke konfigurasi simpul. Ini termasuk penetapan identitas awal, pembaruan identitas, dan pengaturan ulang profil perwakilan layanan.

Kebijakan Gangguan Simpul memicu gambar ulang saat Anda memperbarui identitas terkelola atau identitas terkelola yang ditetapkan pengguna untuk kubelet.

perubahan zona Private DNS

Anda harus memperbarui pengaturan pemecah masalah DNS untuk mengatasi titik akhir server API privat menggunakan zona DNS baru.

Kebijakan Gangguan Node memicu reimage saat Anda memodifikasi konfigurasi zona DNS privat di kluster privat.

Pengaktifan Integrasi VNet API Server

Anda harus mengonfigurasi ulang node agar dapat berkomunikasi dengan server API melalui alamat IP load balancer internal yang diproyeksikan ke subnet terdelegasi.

Kebijakan Gangguan Node memicu gambar ulang saat Anda mengaktifkan Integrasi VNet API Server pada kluster yang ada yang sebelumnya tidak menggunakannya. Perubahan ini sesuai dengan perubahan properti apiServerAccessProfile.enableVnetIntegration (secara internal, field privateConnectProfile.enabled) dari false (atau belum disetel) menjadi true:

Dari Untuk
apiServerAccessProfile.enableVnetIntegration: false atau hapus setelan apiServerAccessProfile.enableVnetIntegration: true

Perubahan perutean host eBPF

Anda perlu menginstal atau menghapus program eBPF yang menyediakan penerusan paket berkinerja tinggi (mode akselerasi BpfVeth).

Tabel berikut merangkum perubahan pada perutean host eBPF yang memicu proses reimage:

Dari Untuk
Perutean standar Perutean host eBPF diaktifkan
Perutean host eBPF diaktifkan Perutean standar

Operasi tingkat kumpulan simpul

Operasi ini hanya memengaruhi kumpulan simpul tertentu tempat Anda membuat perubahan. Mereka memicu proses reimage bergilir pada kumpulan node tersebut:

Pembaruan profil DNS lokal

Anda perlu menerapkan perubahan pada daemon cache DNS serta aturan penerusan DNS pada tingkat node.

Kebijakan Gangguan Node memicu reimage saat Anda mengubah konfigurasi profil LocalDNS.

Perubahan keamanan Peluncuran Tepercaya

Anda tidak dapat mengubah konfigurasi firmware VM dan pengaturan proses boot pada VM yang berjalan. Perubahan ini mengharuskan Anda membuat ulang VM.

Tabel berikut menguraikan perubahan keamanan Trusted Launch yang memicu proses reimage:

Konfigurasi Dari Untuk
vTPM (Modul Platform Tepercaya virtual) Disabled Enabled
vTPM (Modul Platform Tepercaya virtual) Enabled Disabled
Secure Boot (Pengaktifan Aman) Disabled Enabled
Secure Boot (Pengaktifan Aman) Enabled Disabled

Perubahan pada streaming artefak

Anda perlu menginstal atau menghapus komponen streaming artefak untuk memungkinkan penarikan gambar kontainer yang lebih cepat dengan streaming lapisan gambar sesuai permintaan.

Tabel berikut menguraikan perubahan streaming artefak yang memicu gambar ulang:

Dari Untuk
Disabled Enabled
Enabled Disabled

Pembaruan profil Windows GMSA (khusus pool node Windows saja)

Anda perlu menerapkan pengaturan GMSA baru, konfigurasi server DNS, dan kredensial untuk bergabung ke domain demi integrasi Direktori Aktif pada node Windows.

Kebijakan Gangguan Node memicu gambaran ulang kumpulan simpul Windows ketika perubahan GMSA memerlukan penerapan konfigurasi node baru:

Dari Untuk Memicu penginstalan ulang image sistem
GMSA dinonaktifkan GMSA diaktifkan Yes
GMSA diaktifkan (server DNS / akar domain diatur atau diubah) GMSA diaktifkan dengan server DNS atau domain root yang diperbarui Yes
GMSA diaktifkan (server DNS disetel) GMSA dinonaktifkan Yes
GMSA diaktifkan (server DNS belum diatur) GMSA dinonaktifkan Tidak (tidak ada konfigurasi simpul yang akan diterapkan)

Lampiran Kelompok Reservasi Kapasitas

Anda perlu membuat kembali VM yang mendasarinya agar dialokasikan dari kapasitas terpesan di Grup Reservasi Kapasitas (CRG). Node yang ada tidak diprovisikan untuk CRG, sehingga AKS harus mencitrakan ulang kumpulan node agar terkait dengan reservasi.

Kebijakan Gangguan Simpul memicu gambar ulang saat Anda melampirkan Grup Reservasi Kapasitas ke kumpulan simpul yang sudah ada yang belum memilikinya.

Dari Untuk Memicu penginstalan ulang image sistem
Tidak ada Grup Reservasi Kapasitas yang terlampir Grup Reservasi Kapasitas ditautkan Yes

Operasi yang dicakup oleh Kebijakan Disrupsi Node pada Kubernetes 1.37 dan versi yang lebih baru

Pada Kubernetes 1.37 dan yang lebih baru, Node Disruption Policy mencakup perubahan konfigurasi berikut yang memerlukan reimage node. Pada Kubernetes 1.36 dan versi yang lebih lama, Anda harus menjalankan az aks nodepool upgrade secara manual dengan --node-image-only setelah membuat perubahan konfigurasi ini untuk menerapkan perubahan tersebut ke node Anda.

  • Perubahan konfigurasi SSH: Mengubah metode akses SSH (SSH yang dinonaktifkan, SSH berbasis Entra ID, atau SSH Pengguna Lokal) atau memperbarui kunci publik SSH pada kumpulan simpul.
  • Perubahan pembatasan IMDS: Mengaktifkan atau menonaktifkan pembatasan Instance Metadata Service (IMDS) untuk memblokir akses pod ke titik akhir IMDS.
  • Perubahan profil bootstrap: Mengubah profil bootstrap, seperti mengalihkan artifactSource antara Direct dan Cache, atau mengubah containerRegistryId (Azure Container Registry digunakan untuk kluster terisolasi jaringan).
  • Perubahan jenis outbound: Mengubah jenis konektivitas outbound kluster (loadBalancer, userDefinedRouting, managedNATGateway, atau userAssignedNATGateway).

Operasi upgrade tidak diatur oleh Kebijakan Gangguan Node

Kebijakan Disrupsi Node tidak mengendalikan operasi upgrade berikut. Operasi peningkatan ini dilanjutkan terlepas dari pengaturan kebijakan Anda. Peningkatan versi dapat diprakarsai oleh pelanggan atau oleh AKS dalam periode pemeliharaan terencana. Untuk memungkinkan operasi ini dilanjutkan sesuai jadwal, jauhkan operasi tersebut dengan sengaja keluar dari cakupan Kebijakan Gangguan Node. Selain itu, jika operasi yang dicakup oleh Kebijakan Gangguan Node disertakan dalam perubahan konfigurasi yang sama dengan peningkatan, operasi tersebut tidak akan dikontrol oleh Kebijakan Gangguan Node.

  • Pembaruan versi image node: Memutakhirkan ke versi image OS node yang baru (secara manual atau melalui saluran upgrade otomatis). Operasi ini merupakan operasi reimage yang paling umum dan mencakup patch keamanan, pembaruan OS, serta rilis image node AKS.
  • Peningkatan versi Kubernetes: Meningkatkan versi Kubernetes pada kumpulan simpul, yang menerapkan biner Kubernetes baru, konfigurasi kubelet yang diperbarui, dan perubahan tingkat OS.

Operasi pemulihan tidak dikontrol oleh Kebijakan Gangguan Node

Kebijakan Gangguan Simpul tidak mengontrol operasi pemulihan otomatis berikut. Operasi ini dapat terjadi terlepas dari pengaturan kebijakan Anda untuk memastikan kesehatan dan pemulihan kluster.

  • Pembatalan konfigurasi kumpulan simpul: Ketika operasi pembaruan kumpulan simpul gagal karena masalah konfigurasi atau infrastruktur yang tidak valid, AKS secara otomatis kembali ke status baik terakhir yang diketahui dan menggambarkan kembali node untuk mengembalikan konfigurasi.
  • Operasi pemulihan kluster administratif: Saat insinyur dukungan Azure melakukan pemulihan kluster administratif selama penanganan insiden, image pada node diinstal ulang untuk memastikan konsistensi antara status control plane dan konfigurasi node.
  • Pembaruan kredensial identitas node: AKS secara berkala memperbarui kredensial identitas node untuk keamanan dan kepatuhan. Pembaruan yang dimulai oleh sistem ini memicu reimage node untuk menerapkan kredensial baru ke seluruh pool node.

Integrasi dengan pemeliharaan terencana

Node Disruption Policy berfungsi dengan lancar dengan jendela pemeliharaan terjadwal AKS. Saat Anda mengatur kebijakan ke AllowDuringMaintenanceWindow, operasi disruptif selaras dengan periode pemeliharaan Anda aksManagedNodeOSUpgradeSchedule. Jadwal dapat berupa inline atau ditautkan ke jendela pemeliharaan bersama. Integrasi ini memastikan bahwa:

  • Perubahan hanya terjadi selama jendela waktu yang disetujui.
  • Operasi berkoordinasi dengan pemeliharaan terjadwal lainnya.
  • Tim menyadari kapan gangguan mungkin terjadi.

Integrasi ini memberikan pendekatan komprehensif untuk mengelola perubahan kluster dan meminimalkan dampak pada menjalankan beban kerja.

Note

Saat Anda menggunakan AllowDuringMaintenanceWindow, Anda harus mengonfigurasi jendela pemeliharaan aksManagedNodeOSUpgradeSchedule. Menggunakan jendela pemeliharaan default atau aksManagedAutoUpgradeSchedule (upgrade otomatis kluster) tidak memenuhi persyaratan ini. Konfigurasi aksManagedNodeOSUpgradeSchedule yang ditautkan ke jendela pemeliharaan bersama memenuhi persyaratan ini. Jika Anda menetapkan AllowDuringMaintenanceWindow tanpa jendela aksManagedNodeOSUpgradeSchedule yang dikonfigurasi, semua operasi disruptif diizinkan (kebijakan tidak memiliki jendela yang dapat menjadi pembatas). Untuk informasi selengkapnya tentang menyiapkan jendela pemeliharaan, lihat Menggunakan pemeliharaan terencana untuk menjadwalkan dan mengontrol peningkatan untuk kluster Azure Kubernetes Service Anda.

Praktik terbaik

Pertimbangkan rekomendasi ini saat menerapkan Kebijakan Gangguan Node:

  • Gunakan AllowDuringMaintenanceWindow untuk produksi: Gabungkan dengan jendela pemeliharaan terencana untuk mengontrol kapan gangguan terjadi di lingkungan produksi.
  • Atur Block selama periode kritis: Blokir sementara operasi yang mengganggu selama peristiwa lalu lintas tinggi, peluncuran produk, atau respons insiden. Jangan gunakan Block tanpa batas waktu. Meskipun Block sesuai untuk pembekuan jangka pendek (peristiwa terencana, respons insiden).
  • Memungkinkan fleksibilitas dalam non-produksi: Gunakan Allow dalam lingkungan pengembangan dan pengujian di mana iterasi cepat lebih penting daripada stabilitas.
  • Mengkomunikasikan perubahan kebijakan: Pastikan tim Anda memahami kebijakan saat ini dan mengetahui kapan operasi mungkin diblokir.
  • Rencanakan jendela pemeliharaan dengan tepat: Ukuran jendela pemeliharaan Anda untuk mengakomodasi operasi yang perlu Anda lakukan.
  • Perilaku kebijakan pengujian: Memvalidasi pengaturan kebijakan di lingkungan non-produksi sebelum menerapkannya ke kluster produksi.
  • Memantau operasi yang diblokir: Lacak kapan operasi diblokir untuk mengoptimalkan jadwal pemeliharaan Anda.

Konten terkait

  • Terakhir diperbarui pada