Mengaktifkan perbaikan simpul otomatis dan menyelidiki masalah kesehatan simpul - Amazon EKS
Agen pemantauan simpulPerbaikan simpul otomatisMasalah kesehatan simpul

Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengaktifkan perbaikan simpul otomatis dan menyelidiki masalah kesehatan simpul

Kesehatan node mengacu pada status operasional dan kemampuan node untuk menjalankan beban kerja secara efektif. Node yang sehat mempertahankan konektivitas yang diharapkan, memiliki sumber daya yang cukup, dan dapat berhasil menjalankan Pod tanpa gangguan. Untuk informasi tentang mendapatkan detail tentang node Anda, lihat Lihat status kesehatan node Anda danMengambil log node untuk node terkelola menggunakan kubectl dan S3.

Untuk membantu menjaga node yang sehat, Amazon EKS menawarkan agen pemantauan node dan perbaikan otomatis node.

penting

Agen pemantauan node dan perbaikan otomatis node hanya tersedia di Linux. Fitur-fitur ini tidak tersedia di Windows.

Agen pemantauan simpul

Agen pemantauan node secara otomatis membaca log node untuk mendeteksi masalah kesehatan tertentu. Ini mem-parsing melalui log node untuk mendeteksi kegagalan dan memunculkan berbagai informasi status tentang node pekerja. Dedicated NodeCondition diterapkan pada node pekerja untuk setiap kategori masalah yang terdeteksi, seperti masalah penyimpanan dan jaringan. Deskripsi masalah kesehatan yang terdeteksi tersedia di dasbor observabilitas. Untuk informasi selengkapnya, lihat Masalah kesehatan simpul.

Agen pemantauan node disertakan sebagai kemampuan untuk semua kluster Mode Otomatis Amazon EKS. Untuk jenis cluster lainnya, Anda dapat menambahkan agen pemantauan sebagai add-on Amazon EKS. Untuk informasi selengkapnya, lihat Buat add-on Amazon EKS.

Perbaikan simpul otomatis

Node auto repair adalah fitur tambahan yang terus memantau kesehatan node, secara otomatis bereaksi terhadap masalah yang terdeteksi dan mengganti node bila memungkinkan. Ini membantu ketersediaan cluster secara keseluruhan dengan intervensi manual minimal. Jika pemeriksaan kesehatan gagal, node secara otomatis ditutup sehingga tidak ada Pod baru yang dijadwalkan pada node.

Dengan sendirinya, perbaikan otomatis simpul dapat bereaksi terhadap kondisi Ready dari kubelet dan objek simpul apa pun yang dihapus secara manual. Ketika dipasangkan dengan agen pemantauan node, perbaikan otomatis node dapat bereaksi terhadap lebih banyak kondisi yang tidak akan terdeteksi sebaliknya. Kondisi tambahan ini meliputi KernelReady, NetworkingReady, dan StorageReady.

Pemulihan simpul otomatis ini secara otomatis mengatasi masalah simpul intermiten seperti kegagalan untuk bergabung dengan klaster, kubelet yang tidak responsif, dan peningkatan kesalahan akselerator (perangkat). Peningkatan keandalan membantu mengurangi waktu henti aplikasi dan meningkatkan operasi klaster. Secara default, perbaikan otomatis node tidak secara otomatis memperbaiki node untuk kondisi tertentu sepertiDiskPressure,, MemoryPressurePIDPressure, dan DCGM (NVIDIA Data Center GPU Manager) kesalahan alat diagnostik atau pemantauan. Kondisi ini sering menunjukkan masalah dengan perilaku aplikasi, konfigurasi beban kerja, atau batasan sumber daya daripada kegagalan tingkat simpul, sehingga sulit untuk menentukan tindakan perbaikan default yang sesuai. Namun, Anda dapat menyesuaikan perilaku ini menggunakan nodeRepairConfigOverrides untuk mengaktifkan tindakan perbaikan otomatis untuk kondisi ini berdasarkan kasus penggunaan Anda. Amazon EKS menunggu 10 menit sebelum bertindak AcceleratedHardwareReadyNodeConditions, dan 30 menit untuk semua kondisi lainnya.

Grup node terkelola juga akan secara otomatis menonaktifkan perbaikan node untuk alasan keamanan di bawah dua skenario. Setiap operasi perbaikan yang sebelumnya sedang berlangsung akan berlanjut untuk kedua situasi.

  • Jika pergeseran zona untuk cluster Anda telah dipicu melalui Application Recovery Controller (ARC), semua operasi perbaikan berikutnya dihentikan.

  • Jika grup node Anda memiliki lebih dari lima node dan lebih dari 20% node dalam grup node Anda berada dalam keadaan tidak sehat, operasi perbaikan dihentikan.

Anda dapat mengaktifkan perbaikan otomatis node saat membuat atau mengedit grup node terkelola.

Amazon EKS memberikan kontrol yang lebih terperinci atas perilaku perbaikan otomatis node melalui hal-hal berikut:

  • maxUnhealthyNodeThresholdCount dan maxUnhealthyNodeThresholdPercentage

    • Bidang ini memungkinkan Anda menentukan ambang batas hitungan atau persentase node yang tidak sehat, di atasnya tindakan perbaikan otomatis node akan berhenti. Ini memberikan kontrol lebih besar atas “radius ledakan” perbaikan otomatis node.

    • Anda dapat mengatur jumlah absolut atau persentase, tetapi tidak keduanya.

  • maxParallelNodesRepairedCount dan maxParallelNodesRepairedPercentage

    • Bidang ini memungkinkan Anda untuk menentukan jumlah maksimum node yang dapat diperbaiki secara bersamaan atau paralel, dinyatakan sebagai hitungan atau persentase dari semua node yang tidak sehat. Ini memberi Anda kontrol yang lebih halus atas kecepatan penggantian node.

    • Seperti halnya ambang simpul yang tidak sehat, Anda dapat mengatur jumlah absolut atau persentase, tetapi tidak keduanya.

  • nodeRepairConfigOverrides

    • Ini adalah struktur kompleks yang memungkinkan Anda mengatur penggantian granular untuk tindakan perbaikan tertentu. Penggantian ini mengontrol tindakan perbaikan dan waktu tunda perbaikan sebelum node dianggap memenuhi syarat untuk diperbaiki.

    • Bidang spesifik dalam struktur ini adalah:

      • nodeMonitoringCondition: Kondisi tidak sehat yang dilaporkan oleh agen pemantau simpul.

      • nodeUnhealthyReason: Alasan mengapa agen pemantauan node mengidentifikasi node sebagai tidak sehat.

      • minRepairWaitTimeMins: Waktu minimum (dalam menit) bahwa kondisi perbaikan dan alasan tidak sehat harus bertahan sebelum node memenuhi syarat untuk diperbaiki.

      • repairAction: Tindakan yang harus dilakukan sistem perbaikan ketika kondisi di atas terpenuhi.

    • Jika Anda menggunakan bidang ini, Anda harus menentukan semua bidang dalam struktur. Anda juga dapat memberikan daftar penggantian ini.

    • nodeMonitoringConditionDan nodeUnhealthyReason merupakan input teks manual yang Anda tetapkan untuk menunjukkan bahwa Anda ingin menyimpang dari perilaku default sistem.

    • repairActionBidang minRepairWaitTimeMins dan memungkinkan Anda menentukan penyimpangan dari perilaku default sistem.

    • Contoh berikut menunjukkan cara mengganti waktu tunggu hingga 20 menit sebelum Amazon EKS me-reboot node yang mengalami NvidiaXID13Error kondisi. Secara default, Amazon EKS menunggu 10 menit sebelum mengambil tindakan perbaikan pada AcceleratedHardwareReady kondisi.

      aws eks update-nodegroup-config \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --node-repair-config 'enabled=true,nodeRepairConfigOverrides=[{nodeMonitoringCondition=AcceleratedHardwareReady,nodeUnhealthyReason=NvidiaXID13Error,minRepairWaitTimeMins=20}]'

Masalah kesehatan simpul

Tabel berikut menjelaskan masalah kesehatan simpul yang dapat dideteksi oleh agen pemantauan node. Ada dua jenis masalah:

  • Kondisi — Masalah terminal yang menjamin tindakan remediasi seperti penggantian instance atau reboot. Ketika perbaikan otomatis diaktifkan, Amazon EKS akan melakukan tindakan perbaikan, baik sebagai penggantian node atau reboot. Untuk informasi selengkapnya, lihat Kondisi simpul.

  • Event — Masalah sementara atau konfigurasi node sub-optimal. Tidak ada tindakan perbaikan otomatis yang akan terjadi. Untuk informasi selengkapnya, lihat Peristiwa simpul.

AcceleratedHardware masalah kesehatan simpul

Kondisi pemantauan adalah AcceleratedHardwareReady untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”.

Jika perbaikan otomatis diaktifkan, tindakan perbaikan yang tercantum mulai 10 menit setelah masalah terdeteksi. Untuk informasi selengkapnya tentang kesalahan XID, lihat Kesalahan Xid di Deployment GPU NVIDIA dan Dokumentasi Manajemen. Untuk informasi selengkapnya tentang pesan XID individual, lihat Memahami Pesan Xid di Dokumentasi Penerapan dan Manajemen GPU NVIDIA.

Nama Kepelikan Deskripsi Tindakan Perbaikan

DCGMDiagnosticKegagalan

Kondisi

Kasus uji dari rangkaian uji diagnostik aktif DCGM gagal.

Tidak ada

DCGMError

Kondisi

Koneksi ke proses host DCGM terputus atau tidak dapat dibuat.

Tidak ada

DCGMFieldKesalahan [Kode]

Peristiwa

DCGM mendeteksi degradasi GPU melalui pengenal bidang.

Tidak ada

DCGMHealthKode [Kode]

Peristiwa

Pemeriksaan kesehatan DCGM gagal dengan cara yang tidak fatal.

Tidak ada

DCGMHealthKode [Kode]

Kondisi

Pemeriksaan kesehatan DCGM gagal dengan cara yang fatal.

Tidak ada

Neuron DMAError

Kondisi

Mesin DMA mengalami kesalahan yang tidak dapat dipulihkan.

Ganti

HBMUncorrectableKesalahan Neuron

Kondisi

HBM mengalami kesalahan yang tidak dapat diperbaiki dan menghasilkan hasil yang salah.

Ganti

NCUncorrectableKesalahan Neuron

Kondisi

Kesalahan memori Neuron Core yang tidak dapat diperbaiki terdeteksi.

Ganti

SRAMUncorrectableKesalahan Neuron

Kondisi

SRAM on-chip mengalami kesalahan paritas dan menghasilkan hasil yang salah.

Ganti

NvidiaDeviceCountMismatch

Peristiwa

Jumlah yang GPUs terlihat melalui NVMLtidak konsisten dengan jumlah perangkat NVIDIA pada sistem file.

Tidak ada

NvidiaDoubleBitError

Kondisi

Kesalahan bit ganda dihasilkan oleh driver GPU.

Ganti

Nvidia NCCLError

Peristiwa

Segfault terjadi di perpustakaan NVIDIA Collective Communications (libnccl).

Tidak ada

NVLinkKesalahan Nvidia

Kondisi

NVLink kesalahan dilaporkan oleh driver GPU.

Ganti

PCIeKesalahan Nvidia

Peristiwa

PCIe tayangan ulang dipicu untuk pulih dari kesalahan transmisi.

Tidak ada

NvidiaPageRetirement

Peristiwa

Pengemudi GPU telah menandai halaman memori untuk pensiun. Ini dapat terjadi jika ada kesalahan bit ganda tunggal atau dua kesalahan bit tunggal ditemui di alamat yang sama.

Tidak ada

NvidiaPowerError

Peristiwa

Pemanfaatan daya GPUs melanggar ambang batas yang diizinkan.

Tidak ada

NvidiaThermalError

Peristiwa

Status termal GPUs melanggar ambang batas yang diizinkan.

Tidak ada

Kesalahan NvidiaXid [Kode]

Kondisi

Terjadi kesalahan GPU kritis.

Ganti atau Reboot

Peringatan NvidiaXid [Kode]

Peristiwa

Terjadi kesalahan GPU non-kritis.

Tidak ada

ContainerRuntime masalah kesehatan simpul

Kondisi pemantauan adalah ContainerRuntimeReady untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”.

Nama Kepelikan Deskripsi Tindakan Perbaikan

ContainerRuntimeFailed

Peristiwa

Runtime container gagal membuat container, kemungkinan terkait dengan masalah yang dilaporkan jika terjadi berulang kali.

Tidak ada

DeprecatedContainerdConfiguration

Peristiwa

Gambar kontainer menggunakan manifes gambar usang versi 2, skema 1 baru-baru ini ditarik ke node melalui. containerd

Tidak ada

KubeletFailed

Peristiwa

Kubelet memasuki keadaan gagal.

Tidak ada

LivenessProbeFailures

Peristiwa

Kegagalan probe keaktifan terdeteksi, berpotensi menunjukkan masalah kode aplikasi atau nilai batas waktu yang tidak mencukupi jika terjadi berulang kali.

Tidak ada

PodStuckTerminating

Kondisi

Sebuah Pod sedang atau macet terminating untuk waktu yang berlebihan, yang dapat disebabkan oleh kesalahan CRI yang mencegah perkembangan status pod.

Ganti

ReadinessProbeFailures

Peristiwa

Kegagalan probe kesiapan terdeteksi, berpotensi menunjukkan masalah kode aplikasi atau nilai batas waktu yang tidak mencukupi jika terjadi berulang kali.

Tidak ada

[Nama] RepeatedRestart

Peristiwa

Unit systemd sering restart.

Tidak ada

ServiceFailedToStart

Peristiwa

Unit systemd gagal memulai.

Tidak ada

Masalah kesehatan simpul kernel

Kondisi pemantauan adalah KernelReady untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”.

Nama Kepelikan Deskripsi Tindakan Perbaikan

AppBlocked

Peristiwa

Tugas telah diblokir untuk jangka waktu yang lama dari penjadwalan, biasanya disebabkan oleh diblokir pada input atau output.

Tidak ada

AppCrash

Peristiwa

Aplikasi pada node telah crash.

Tidak ada

ApproachingKernelPidMax

Peristiwa

Jumlah proses mendekati jumlah maksimum PIDs yang tersedia per kernel.pid_max pengaturan saat ini, setelah itu tidak ada lagi proses yang dapat diluncurkan.

Tidak ada

ApproachingMaxOpenFiles

Peristiwa

Jumlah file yang terbuka mendekati jumlah maksimum file terbuka yang mungkin diberikan pengaturan kernel saat ini, setelah itu membuka file baru akan gagal.

Tidak ada

ConntrackExceededKernel

Peristiwa

Pelacakan koneksi melebihi maksimum untuk kernel dan koneksi baru tidak dapat dibuat, yang dapat mengakibatkan hilangnya paket.

Tidak ada

ExcessiveZombieProcesses

Peristiwa

Proses yang tidak dapat sepenuhnya direklamasi terakumulasi dalam jumlah besar, yang menunjukkan masalah aplikasi dan dapat menyebabkan mencapai batas proses sistem.

Tidak ada

ForkFailedOutOfPIDs

Kondisi

Panggilan fork atau exec gagal karena sistem kehabisan proses IDs atau memori, yang mungkin disebabkan oleh proses zombie atau kelelahan memori fisik.

Ganti

KernelBug

Peristiwa

Bug kernel terdeteksi dan dilaporkan oleh kernel Linux itu sendiri, meskipun ini kadang-kadang disebabkan oleh node dengan CPU tinggi atau penggunaan memori yang menyebabkan pemrosesan peristiwa tertunda.

Tidak ada

LargeEnvironment

Peristiwa

Jumlah variabel lingkungan untuk proses ini lebih besar dari yang diharapkan, berpotensi disebabkan oleh banyak layanan dengan enableServiceLinks set ke true, yang dapat menyebabkan masalah kinerja.

Tidak ada

RapidCron

Peristiwa

Pekerjaan cron berjalan lebih cepat daripada setiap lima menit pada node ini, yang dapat memengaruhi kinerja jika pekerjaan tersebut menghabiskan sumber daya yang signifikan.

Tidak ada

SoftLockup

Peristiwa

CPU terhenti untuk jangka waktu tertentu.

Tidak ada

Masalah kesehatan simpul jaringan

Kondisi pemantauan adalah NetworkingReady untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”.

Nama Kepelikan Deskripsi Tindakan Perbaikan

BandwidthInExceeded

Peristiwa

Paket telah diantrian atau dijatuhkan karena bandwidth agregat masuk melebihi maksimum untuk instance.

Tidak ada

BandwidthOutExceeded

Peristiwa

Paket telah diantrian atau dijatuhkan karena bandwidth agregat keluar melebihi maksimum untuk instance.

Tidak ada

ConntrackExceeded

Peristiwa

Pelacakan koneksi melebihi maksimum untuk instance dan koneksi baru tidak dapat dibuat, yang dapat mengakibatkan hilangnya paket.

Tidak ada

IPAMDInconsistentNegara

Peristiwa

Status pos pemeriksaan IPAMD pada disk tidak mencerminkan runtime IPs dalam container.

Tidak ada

IPAMDNoIPs

Peristiwa

IPAMD kehabisan alamat IP.

Tidak ada

IPAMDNotSiap

Kondisi

IPAMD gagal terhubung ke server API.

Ganti

IPAMDNotBerlari

Kondisi

Proses Amazon VPC CNI tidak ditemukan berjalan.

Ganti

IPAMDRepeatedlyMulai ulang

Peristiwa

Beberapa restart dalam layanan IPAMD telah terjadi.

Tidak ada

InterfaceNotRunning

Kondisi

Antarmuka ini tampaknya tidak berjalan atau ada masalah jaringan.

Ganti

InterfaceNotUp

Kondisi

Antarmuka ini tampaknya tidak aktif atau ada masalah jaringan.

Ganti

KubeProxyNotReady

Peristiwa

Kube-proxy gagal menonton atau mencantumkan sumber daya.

Tidak ada

LinkLocalExceeded

Peristiwa

Paket dijatuhkan karena PPS lalu lintas ke layanan proxy lokal melebihi maksimum antarmuka jaringan.

Tidak ada

MACAddressPolicyMisconfigured

Peristiwa

Konfigurasi tautan systemd-networkd memiliki nilai yang salah. MACAddressPolicy

Tidak ada

MissingDefaultRoutes

Peristiwa

Ada aturan rute default yang hilang.

Tidak ada

Hilang IPRoutes

Peristiwa

Ada rute yang hilang untuk Pod IPs.

Tidak ada

Hilang IPRules

Peristiwa

Ada aturan yang hilang untuk Pod IPs.

Tidak ada

MissingLoopbackInterface

Kondisi

Antarmuka loopback hilang dari instance ini, menyebabkan kegagalan layanan tergantung pada konektivitas lokal.

Ganti

NetworkSysctl

Peristiwa

sysctlPengaturan jaringan node ini berpotensi salah.

Tidak ada

PPSExceeded

Peristiwa

Paket telah diantrian atau dijatuhkan karena PPS dua arah melebihi maksimum untuk instance.

Tidak ada

PortConflict

Peristiwa

Jika sebuah Pod menggunakan HostPort, ia dapat menulis iptables aturan yang mengganti port host yang sudah terikat, yang berpotensi mencegah akses server API. kubelet

Tidak ada

UnexpectedRejectRule

Peristiwa

Sebuah tak terduga REJECT atau DROP aturan ditemukan diiptables, berpotensi memblokir lalu lintas yang diharapkan.

Tidak ada

Masalah kesehatan simpul penyimpanan

Kondisi pemantauan adalah StorageReady untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”.

Nama Kepelikan Deskripsi Tindakan Perbaikan

EBSInstanceIOPSExceeded

Peristiwa

IOPS maksimum untuk instance terlampaui.

Tidak ada

EBSInstanceThroughputExceeded

Peristiwa

Throughput Maksimum untuk instance terlampaui.

Tidak ada

EBSVolumeIOPSExceeded

Peristiwa

IOPS maksimum untuk Volume EBS tertentu terlampaui.

Tidak ada

EBSVolumeThroughputExceeded

Peristiwa

Throughput Maksimum untuk volume Amazon EBS tertentu terlampaui.

Tidak ada

EtcHostsMountFailed

Peristiwa

Pemasangan kubelet yang dihasilkan /etc/hosts gagal karena /var/lib/kubelet/pods remounting data pengguna selama operasi. kubelet-container

Tidak ada

IODelays

Peristiwa

Penundaan input atau output terdeteksi dalam suatu proses, berpotensi menunjukkan penyediaan input-output yang tidak mencukupi jika berlebihan.

Tidak ada

KubeletDiskUsageSlow

Peristiwa

kubeletIni melaporkan penggunaan disk yang lambat saat mencoba mengakses sistem file. Ini berpotensi menunjukkan masalah input-output atau sistem file disk yang tidak mencukupi.

Tidak ada

XFSSmallAverageClusterSize

Peristiwa

Ukuran XFS Average Cluster kecil, menunjukkan fragmentasi ruang kosong yang berlebihan. Ini dapat mencegah pembuatan file meskipun ada inode atau ruang kosong yang tersedia.

Tidak ada