**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. # Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis Kesehatan node mengacu pada status operasional dan kemampuan node Kubernetes untuk menjalankan beban kerja secara efektif. Node yang sehat mempertahankan konektivitas jaringan yang diharapkan, memiliki sumber daya komputasi dan penyimpanan yang memadai, dan dapat berhasil menjalankan beban kerja tanpa gangguan. Untuk membantu menjaga node yang sehat di kluster EKS, EKS menawarkan *agen pemantauan node* dan *perbaikan node otomatis*. Fitur-fitur ini secara otomatis diaktifkan dengan komputasi Mode Otomatis EKS. Anda juga dapat menggunakan perbaikan node otomatis dengan grup node terkelola EKS dan Karpenter, dan dapat menggunakan agen pemantauan simpul EKS dengan jenis komputasi EKS apa pun kecuali untuk Fargate. AWS Agen pemantauan simpul EKS dan perbaikan simpul otomatis paling efektif bila digunakan bersama, tetapi mereka juga dapat digunakan secara individual dalam kluster EKS. **penting** *Agen pemantauan node* dan *perbaikan otomatis node* hanya tersedia di Linux. Fitur-fitur ini tidak tersedia di Windows. ## Agen pemantauan simpul Agen pemantauan simpul EKS membaca log simpul untuk mendeteksi masalah kesehatan. Ini mem-parsing log untuk mendeteksi kegagalan dan memunculkan informasi status tentang status kesehatan node. Untuk setiap kategori masalah yang terdeteksi, agen menerapkan yang didedikasikan `NodeCondition` untuk node pekerja. Untuk informasi rinci tentang masalah kesehatan simpul yang terdeteksi oleh agen pemantau simpul EKS, lihat[Mendeteksi masalah kesehatan simpul dengan agen pemantauan simpul EKS](node-health-nma.md). Komputasi Mode Otomatis EKS mencakup agen pemantauan simpul. Untuk jenis komputasi EKS lainnya, Anda dapat menambahkan agen pemantauan node sebagai add-on EKS atau Anda dapat mengelolanya dengan perkakas Kubernetes seperti Helm. Untuk informasi selengkapnya, lihat [Konfigurasikan agen pemantauan simpul](node-health-nma.md#node-monitoring-agent-configure). Dengan agen pemantauan simpul EKS, kategori masalah kesehatan simpul berikut muncul sebagai kondisi simpul. Perhatikan,`Ready`,`DiskPressure`, dan `MemoryPressure` merupakan kondisi node Kubernetes standar yang muncul bahkan tanpa agen pemantauan node EKS. | Kondisi Node | Deskripsi | | --- | --- | | AcceleratedHardwareReady | AcceleratedHardwareReady menunjukkan apakah perangkat keras yang dipercepat (GPU, Neuron) pada node berfungsi dengan benar. | | ContainerRuntimeReady | ContainerRuntimeReady menunjukkan apakah runtime kontainer (containerd, dll.) berfungsi dengan benar dan dapat menjalankan kontainer. | | DiskPressure | DiskPressure adalah kondisi Kubernetes standar yang menunjukkan node mengalami tekanan disk (ruang disk rendah atau I/O tinggi). | | KernelReady | KernelReady menunjukkan apakah kernel berfungsi dengan benar tanpa kesalahan kritis, kepanikan, atau kelelahan sumber daya. | | MemoryPressure | MemoryPressure adalah kondisi Kubernetes standar yang menunjukkan node mengalami tekanan memori (memori yang tersedia rendah). | | NetworkingReady | NetworkingReady menunjukkan apakah tumpukan jaringan node berfungsi dengan benar (antarmuka, perutean, konektivitas). | | StorageReady | StorageReady menunjukkan apakah subsistem penyimpanan node berfungsi dengan benar (disk, sistem file, I/O). | | Siap | Ready adalah kondisi Kubernetes standar yang menunjukkan node sehat dan siap menerima pod. | ## Perbaikan simpul otomatis Perbaikan node otomatis EKS terus memantau kesehatan node, bereaksi terhadap masalah yang terdeteksi, dan mengganti atau me-reboot node bila memungkinkan. Ini meningkatkan keandalan klaster dengan intervensi manual minimal dan membantu mengurangi waktu henti aplikasi. Dengan sendirinya, perbaikan node otomatis EKS bereaksi terhadap `Ready` kondisi kubelet, objek node yang dihapus secara manual, dan instance grup node yang dikelola EKS yang gagal bergabung dengan cluster. Ketika perbaikan node otomatis EKS diaktifkan dengan agen pemantauan node diinstal, perbaikan node otomatis EKS bereaksi terhadap kondisi node tambahan:`AcceleratedHardwareReady`,,`ContainerRuntimeReady`, `KernelReady``NetworkingReady`, dan`StorageReady`. Perbaikan node otomatis EKS tidak bereaksi terhadap Kubernetes standar`DiskPressure`,`MemoryPressure`, atau `PIDPressure` kondisi node. 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. Dalam skenario ini, beban kerja tunduk pada perilaku penggusuran tekanan [node](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction) Kubernetes. Untuk informasi lebih lanjut tentang perbaikan simpul otomatis EKS, lihat[Secara otomatis memperbaiki node di kluster EKS](node-repair.md). **Topics** # Mendeteksi masalah kesehatan simpul dengan agen pemantauan simpul EKS Topik ini merinci masalah kesehatan simpul yang terdeteksi oleh agen pemantau simpul EKS, bagaimana masalah tersebut muncul sebagai kondisi atau peristiwa node, dan cara mengonfigurasi agen pemantauan node. Agen pemantauan simpul EKS dapat digunakan dengan atau tanpa perbaikan simpul otomatis EKS. Untuk informasi lebih lanjut tentang perbaikan node otomatis EKS, lihat[Secara otomatis memperbaiki node di kluster EKS](node-repair.md). Kode sumber untuk agen pemantauan simpul EKS dipublikasikan GitHub di [aws/ eks-node-monitoring-agent](https://github.com/aws/eks-node-monitoring-agent) repositori. ## 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](learn-status-conditions.md#status-node-conditions). + Event — Masalah sementara atau konfigurasi node sub-optimal. Tidak ada tindakan perbaikan otomatis yang akan terjadi. Untuk informasi selengkapnya, lihat [Peristiwa simpul](learn-status-conditions.md#status-node-events). ## AcceleratedHardware masalah kesehatan simpul Kondisi pemantauan adalah `AcceleratedHardwareReady` untuk masalah dalam tabel berikut yang memiliki tingkat keparahan “Kondisi”. Peristiwa dan kondisi dalam tabel di bawah ini adalah untuk masalah kesehatan node terkait NVIDIA dan Neuron. | 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 secara 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 | ## Kode kesalahan NVIDIA XID Agen pemantauan node mendeteksi kesalahan NVIDIA XID dari log kernel GPU. Kesalahan XID terbagi dalam dua kategori: + **Kode XID terkenal** — Kesalahan kritis yang mengatur kondisi node (`AcceleratedHardwareReady=False`) dan memicu perbaikan otomatis saat diaktifkan. Format kode alasannya adalah`NvidiaXID[Code]Error`. Kode XID terkenal yang dideteksi agen pemantau simpul EKS mungkin tidak mewakili daftar lengkap kode NVIDIA XID yang memerlukan tindakan perbaikan. + **Kode XID tidak dikenal** — Logging sebagai event Kubernetes saja. Ini tidak memicu perbaikan otomatis. Format kode alasannya adalah`NvidiaXID[Code]Warning`. Untuk menyelidiki kesalahan XID yang tidak diketahui, tinjau log kernel Anda dengan`dmesg | grep -i nvrm`. Untuk informasi selengkapnya tentang kesalahan XID, lihat Kesalahan [Xid](https://docs.nvidia.com/deploy/xid-errors/index.html#topic_5_1) di *Deployment GPU NVIDIA* dan Dokumentasi Manajemen. Untuk informasi selengkapnya tentang pesan XID individual, lihat [Memahami Pesan Xid di Dokumentasi](https://docs.nvidia.com/deploy/gpu-debug-guidelines/index.html#understanding-xid-messages) *Penerapan dan Manajemen GPU NVIDIA*. Tabel berikut mencantumkan kode XID yang terkenal, artinya, dan tindakan perbaikan node default jika diaktifkan. | Kode XID | Deskripsi | Tindakan Perbaikan | | --- | --- | --- | | 13 | Pengecualian Mesin Grafis — Terjadi kesalahan mesin grafis GPU, biasanya disebabkan oleh masalah perangkat lunak atau bug driver. | Boot ulang | | 31 | Kesalahan halaman memori GPU — Aplikasi mencoba mengakses memori GPU yang tidak dipetakan atau dapat diakses. | Boot ulang | | 48 | Kesalahan ECC Bit Ganda - Kesalahan bit ganda yang tidak dapat diperbaiki terjadi dalam memori GPU, yang menunjukkan potensi degradasi perangkat keras. | Boot ulang | | 63 | Acara pemetaan ulang memori GPU - Driver GPU memetakan ulang sebagian memori GPU karena kesalahan yang terdeteksi. Ini sering dapat dipulihkan. | Boot ulang | | 64 | Kegagalan pemetaan ulang memori GPU - GPU tidak dapat memetakan ulang memori yang rusak, menunjukkan masalah perangkat keras. | Boot ulang | | 74 | NVLink Kesalahan - Terjadi kesalahan pada NVLink interkoneksi berkecepatan tinggi antara GPUs. | Ganti | | 79 | GPU telah jatuh dari bus — GPU tidak lagi dapat diakses melalui PCIe, biasanya menunjukkan kegagalan perangkat keras atau masalah daya. | Ganti | | 94 | Kesalahan memori yang terkandung — Terjadi kesalahan memori tetapi terkandung dan tidak mempengaruhi aplikasi lain. | Boot ulang | | 95 | Kesalahan memori yang tidak terkendali — Terjadi kesalahan memori yang mungkin memengaruhi aplikasi atau memori sistem lain. | Boot ulang | | 119 | GSP RPC Timeout — Komunikasi dengan Prosesor Sistem GPU habis waktu, mungkin karena masalah firmware. | Ganti | | 120 | Kesalahan GSP - Terjadi kesalahan pada Prosesor Sistem GPU. | Ganti | | 121 | Kesalahan C2C - Terjadi kesalahan pada chip-to-chip interkoneksi (digunakan dalam multi-die). GPUs | Ganti | | 140 | ECC Unrecover Error - Kesalahan ECC lolos dari penahanan dan mungkin memiliki data yang rusak. | Ganti | Untuk melihat kondisi node saat ini yang terkait dengan kesehatan GPU, jalankan perintah berikut. ``` kubectl get nodes -o custom-columns='NAME:.metadata.name,ACCELERATOR_READY:.status.conditions[?(@.type=="AcceleratedHardwareReady")].status,REASON:.status.conditions[?(@.type=="AcceleratedHardwareReady")].reason' ``` Untuk melihat peristiwa terkait XID di cluster Anda, jalankan salah satu perintah berikut. ``` kubectl get events | grep -i "NvidiaXID" ``` ## 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 | | EFAErrorMetrik | Peristiwa | Metrik driver EFA menunjukkan ada antarmuka dengan penurunan kinerja. | 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 | `sysctl`Pengaturan 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 di`iptables`, 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 | `kubelet`Ini 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 | ## Konfigurasikan agen pemantauan simpul Agen pemantauan simpul EKS digunakan sebagai DaemonSet file. Saat Anda menerapkannya sebagai add-on EKS, Anda dapat menyesuaikan instalasi dengan nilai konfigurasi berikut. Untuk konfigurasi default, rujuk bagan [Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) agen pemantauan simpul EKS. | Opsi Konfigurasi | Deskripsi | | --- | --- | | `monitoringAgent.resources.requests.cpu` | Permintaan sumber daya CPU untuk agen pemantauan. | | `monitoringAgent.resources.requests.memory` | Permintaan sumber daya memori untuk agen pemantauan. | | `monitoringAgent.resources.limits.cpu` | Batas sumber daya CPU untuk agen pemantauan. | | `monitoringAgent.resources.limits.memory` | Batas sumber daya memori untuk agen pemantauan. | | `monitoringAgent.tolerations` | Toleransi untuk menjadwalkan agen pemantauan pada node yang tercemar. | | `monitoringAgent.additionalArgs` | Argumen baris perintah tambahan untuk diteruskan ke agen pemantauan. | **catatan** Anda dapat mengkonfigurasi `hostname-override` dan `verbosity` seperti `monitoringAgent.additionalArgs` dengan add-on EKS atau instalasi Helm. Saat ini Anda tidak dapat menyesuaikan `probe-address` (`8002`) atau `metrics-address` (`8003`) agen pemantauan node melalui argumen tambahan dengan add-on EKS atau instalasi Helm. Agen pemantauan node mencakup komponen server NVIDIA DCGM (Data Center GPU Manager) (`nv-hostengine`) untuk memantau NVIDIA. GPUs Komponen ini hanya berjalan pada node yang merupakan tipe instans GPU NVIDIA seperti yang `nodeAffinity` ditunjukkan oleh bagan [Helm](https://github.com/aws/eks-node-monitoring-agent/blob/main/charts/eks-node-monitoring-agent/values.yaml) agen. Anda tidak dapat menggunakan instalasi NVIDIA DCGM yang ada dengan agen pemantauan simpul EKS, berikan umpan balik tentang [GitHub masalah peta jalan EKS \$12763](https://github.com/aws/containers-roadmap/issues/2763) jika Anda memerlukan fungsi ini. Saat Anda menggunakan agen pemantauan simpul EKS sebagai add-on EKS, Anda dapat menyesuaikan instalasi NVIDIA DCGM dengan nilai konfigurasi berikut. | Opsi Konfigurasi | Deskripsi | | --- | --- | | `dcgmAgent.resources.requests.cpu` | Permintaan sumber daya CPU untuk agen DCGM. | | `dcgmAgent.resources.requests.memory` | Permintaan sumber daya memori untuk agen DCGM. | | `dcgmAgent.resources.limits.cpu` | Batas sumber daya CPU untuk agen DCGM. | | `dcgmAgent.resources.limits.memory` | Batas sumber daya memori untuk agen DCGM. | | `dcgmAgent.tolerations` | Toleransi untuk penjadwalan agen DCGM pada node yang tercemar. | Anda dapat menggunakan perintah AWS CLI berikut untuk mendapatkan informasi yang berguna tentang versi dan skema untuk add-on agen pemantauan simpul EKS EKS. Dapatkan versi add-on agen terbaru untuk versi Kubernetes Anda. Ganti `1.35` dengan versi Kubernetes Anda. ``` aws eks describe-addon-versions \ --addon-name eks-node-monitoring-agent \ --kubernetes-version 1.35 \ --query='addons[].addonVersions[].addonVersion' ``` Dapatkan skema add-on agen yang didukung di add-on EKS. Ganti `v1.5.1-eksbuild.1` dengan versi agen Anda. ``` aws eks describe-addon-configuration \ --addon-name eks-node-monitoring-agent \ --addon-version v1.5.1-eksbuild.1 ``` # Secara otomatis memperbaiki node di kluster EKS Topik ini merinci perilaku perbaikan node otomatis EKS dan cara mengonfigurasinya untuk memenuhi kebutuhan Anda. Perbaikan simpul otomatis EKS diaktifkan secara default dalam Mode Otomatis EKS, dan dapat digunakan dengan grup simpul yang dikelola EKS dan Karpenter. Tindakan perbaikan node otomatis EKS default dirangkum dalam tabel di bawah ini dan mereka berlaku untuk perilaku untuk Mode Otomatis EKS, grup node terkelola EKS, dan Karpenter. Saat menggunakan Mode Otomatis EKS atau Karpenter, semua tindakan `AcceleratedHardwareReady` perbaikan dilakukan`Replace`, dan hanya grup simpul yang dikelola EKS yang mendukung `Reboot` sebagai tindakan perbaikan. Untuk daftar rinci masalah kesehatan node yang terdeteksi oleh agen pemantau simpul EKS dan tindakan perbaikan node yang sesuai, lihat[Mendeteksi masalah kesehatan simpul dengan agen pemantauan simpul EKS](node-health-nma.md). | Kondisi Node | Deskripsi | Perbaikan setelah | Tindakan perbaikan | | --- | --- | --- | --- | | AcceleratedHardwareReady | AcceleratedHardwareReady menunjukkan apakah perangkat keras yang dipercepat (GPU, Neuron) pada node berfungsi dengan benar. | 10m | Ganti atau Reboot | | ContainerRuntimeReady | ContainerRuntimeReady menunjukkan apakah runtime kontainer (containerd, dll.) berfungsi dengan benar dan dapat menjalankan kontainer. | 30m | Ganti | | DiskPressure | DiskPressure adalah kondisi Kubernetes standar yang menunjukkan node mengalami tekanan disk (ruang disk rendah atau I/O tinggi). | N/A | Tidak ada | | KernelReady | KernelReady menunjukkan apakah kernel berfungsi dengan benar tanpa kesalahan kritis, kepanikan, atau kehabisan sumber daya. | 30m | Ganti | | MemoryPressure | MemoryPressure adalah kondisi Kubernetes standar yang menunjukkan node mengalami tekanan memori (memori yang tersedia rendah). | N/A | Tidak ada | | NetworkingReady | NetworkingReady menunjukkan apakah tumpukan jaringan node berfungsi dengan benar (antarmuka, perutean, konektivitas). | 30m | Ganti | | StorageReady | StorageReady menunjukkan apakah subsistem penyimpanan node berfungsi dengan benar (disk, sistem file, I/O). | 30m | Ganti | | Siap | Ready adalah kondisi Kubernetes standar yang menunjukkan node sehat dan siap menerima pod. | 30m | Ganti | Tindakan perbaikan node otomatis EKS dinonaktifkan dalam skenario berikut secara default. Tindakan perbaikan node yang sedang berlangsung berlanjut di setiap skenario. Lihat [Konfigurasikan perbaikan node otomatis](#configure-node-repair) cara mengganti pengaturan default ini. **Grup simpul terkelola EKS** + Grup node memiliki lebih dari lima node dan lebih dari 20% node dalam kelompok node tidak sehat. + Pergeseran zona untuk kluster Anda dipicu melalui Application Recovery Controller (ARC). **Mode Otomatis EKS dan Karpenter** + Lebih dari 20% node di dalamnya NodePool tidak sehat. + Untuk standalone NodeClaims, 20% node di cluster tidak sehat. ## Konfigurasikan perbaikan node otomatis Perbaikan node otomatis tidak dapat dikonfigurasi saat menggunakan Mode Otomatis EKS dan selalu diaktifkan dengan pengaturan default yang sama dengan Karpenter. ### Karpenter Untuk menggunakan perbaikan node otomatis dengan Karpenter, aktifkan gerbang fitur. `NodeRepair=true` Anda dapat mengaktifkan gerbang fitur melalui opsi `--feature-gates` CLI atau variabel `FEATURE_GATES` lingkungan dalam penyebaran Karpenter. Untuk informasi lebih lanjut, lihat dokumentasi [Karpenter](https://karpenter.sh/docs/concepts/disruption/#node-auto-repair). ### Grup simpul terkelola Anda dapat mengaktifkan perbaikan node otomatis saat membuat grup node terkelola EKS baru atau dengan memperbarui grup node terkelola EKS yang ada. + **Konsol Amazon EKS** — Pilih kotak centang **Aktifkan perbaikan otomatis node** untuk grup node terkelola. Untuk informasi selengkapnya, lihat [Buat grup node terkelola untuk klaster Anda](create-managed-node-group.md). + ** AWS CLI** - Tambahkan `--node-repair-config enabled=true` ke perintah [https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html](https://docs.aws.amazon.com/cli/latest/reference/eks/create-nodegroup.html)atau [https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html](https://docs.aws.amazon.com/cli/latest/reference/eks/update-nodegroup-config.html). + **eksctl** [— Konfigurasikan`managedNodeGroups.nodeRepairConfig.enabled: true`, lihat contoh di eksctl. GitHub](https://github.com/eksctl-io/eksctl/blob/main/examples/44-node-repair.yaml) Saat menggunakan grup node terkelola EKS, Anda dapat mengontrol perilaku perbaikan otomatis node dengan pengaturan berikut. Untuk mengontrol kapan perbaikan otomatis node berhenti mengambil tindakan, tetapkan ambang batas berdasarkan jumlah node yang tidak sehat dalam grup node. Tetapkan jumlah absolut atau persentase, tetapi tidak keduanya. | Pengaturan | Deskripsi | | --- | --- | | `maxUnhealthyNodeThresholdCount` | Jumlah absolut node yang tidak sehat di atas mana perbaikan otomatis node berhenti. Gunakan ini untuk membatasi ruang lingkup perbaikan. | | `maxUnhealthyNodeThresholdPercentage` | Persentase node yang tidak sehat di atas mana perbaikan otomatis node berhenti (0-100). | Untuk mengontrol berapa banyak node perbaikan pada saat yang sama, Anda dapat mengkonfigurasi perbaikan paralelisme. Seperti halnya ambang simpul yang tidak sehat, tetapkan jumlah absolut atau persentase, tetapi tidak keduanya. | Pengaturan | Deskripsi | | --- | --- | | `maxParallelNodesRepairedCount` | Jumlah maksimum node untuk diperbaiki secara bersamaan. | | `maxParallelNodesRepairedPercentage` | Persentase maksimum node yang tidak sehat untuk diperbaiki secara bersamaan (0-100). | Dengan`nodeRepairConfigOverrides`, Anda dapat menyesuaikan perilaku perbaikan untuk kondisi tertentu. Gunakan ini ketika Anda memerlukan tindakan perbaikan yang berbeda atau waktu tunggu untuk jenis masalah yang berbeda. Setiap penggantian membutuhkan semua bidang berikut: | Bidang | Deskripsi | | --- | --- | | `nodeMonitoringCondition` | Jenis kondisi node yang dilaporkan oleh agen pemantauan node. Misalnya:`AcceleratedHardwareReady`,`NetworkingReady`,`StorageReady`,`KernelReady`. | | `nodeUnhealthyReason` | Kode alasan spesifik untuk kondisi tidak sehat. Misalnya: `NvidiaXID31Error`, `IPAMDNotRunning`. | | `minRepairWaitTimeMins` | Waktu minimum dalam beberapa menit bahwa kondisi harus bertahan sebelum node memenuhi syarat untuk diperbaiki. Gunakan ini untuk menghindari perbaikan node untuk masalah sementara. | | `repairAction` | Tindakan yang harus diambil ketika kondisi terpenuhi. Nilai yang valid: `Replace` (menghentikan dan mengganti node), `Reboot` (reboot node), atau `NoAction` (tidak ada tindakan perbaikan). | Contoh AWS CLI berikut membuat grup node dengan pengaturan perbaikan kustom. ``` aws eks create-nodegroup \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --node-role arn:aws:iam::111122223333:role/NodeRole \ --subnets subnet-0123456789abcdef0 \ --node-repair-config '{ "enabled": true, "maxUnhealthyNodeThresholdPercentage": 10, "maxParallelNodesRepairedCount": 3, "nodeRepairConfigOverrides": [ { "nodeMonitoringCondition": "AcceleratedHardwareReady", "nodeUnhealthyReason": "NvidiaXID64Error", "minRepairWaitTimeMins": 5, "repairAction": "Replace" }, { "nodeMonitoringCondition": "AcceleratedHardwareReady", "nodeUnhealthyReason": "NvidiaXID31Error", "minRepairWaitTimeMins": 15, "repairAction": "NoAction" } ] }' ``` Konfigurasi ini melakukan hal berikut: + Mengaktifkan perbaikan otomatis node + Menghentikan tindakan perbaikan ketika lebih dari 10% node tidak sehat + Memperbaiki hingga 3 node sekaligus + Mengganti kesalahan XID 64 (kegagalan pemetaan ulang memori GPU) untuk mengganti node setelah 5 menit. Defaultnya adalah reboot setelah 10 menit. + Mengganti kesalahan XID 31 (kesalahan halaman memori GPU) agar tidak mengambil tindakan. Defaultnya adalah reboot setelah 10 menit. # Lihat status kesehatan node Anda Topik ini menjelaskan alat dan metode yang tersedia untuk memantau status kesehatan simpul di kluster Amazon EKS. Informasi tersebut mencakup kondisi node, peristiwa, dan kasus deteksi yang membantu Anda mengidentifikasi dan mendiagnosis masalah tingkat simpul. Gunakan perintah dan pola yang dijelaskan di sini untuk memeriksa sumber daya kesehatan node, menafsirkan kondisi status, dan menganalisis peristiwa node untuk pemecahan masalah operasional. Anda bisa mendapatkan beberapa informasi kesehatan node dengan perintah Kubernetes untuk semua node. Dan jika Anda menggunakan agen pemantauan node melalui Amazon EKS Auto Mode atau add-on terkelola Amazon EKS, Anda akan mendapatkan lebih banyak variasi sinyal node untuk membantu memecahkan masalah. Deskripsi masalah kesehatan yang terdeteksi oleh agen pemantauan simpul juga tersedia di dasbor observabilitas. Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan simpul dengan agen pemantauan simpul EKS](node-health-nma.md). ## Kondisi simpul Kondisi node mewakili masalah terminal yang membutuhkan tindakan remediasi seperti penggantian instance atau reboot. **Untuk mendapatkan kondisi untuk semua node:** ``` kubectl get nodes -o 'custom-columns=NAME:.metadata.name,CONDITIONS:.status.conditions[*].type,STATUS:.status.conditions[*].status' ``` **Untuk mendapatkan kondisi rinci untuk node tertentu** ``` kubectl describe node node-name ``` **Contoh kondisi output dari node yang sehat:** ``` - lastHeartbeatTime: "2024-11-21T19:07:40Z" lastTransitionTime: "2024-11-08T03:57:40Z" message: Monitoring for the Networking system is active reason: NetworkingIsReady status: "True" type: NetworkingReady ``` **Contoh kondisi node yang tidak sehat dengan masalah jaringan:** ``` - lastHeartbeatTime: "2024-11-21T19:12:29Z" lastTransitionTime: "2024-11-08T17:04:17Z" message: IPAM-D has failed to connect to API Server which could be an issue with IPTable rules or any other network configuration. reason: IPAMDNotReady status: "False" type: NetworkingReady ``` ## Peristiwa simpul Peristiwa node menunjukkan masalah sementara atau konfigurasi sub-optimal. **Untuk mendapatkan semua peristiwa yang dilaporkan oleh agen pemantauan node** Ketika agen pemantauan node tersedia, Anda dapat menjalankan perintah berikut. ``` kubectl get events --field-selector=reportingComponent=eks-node-monitoring-agent ``` Contoh output: ``` LAST SEEN TYPE REASON OBJECT MESSAGE 4s Warning SoftLockup node/ip-192-168-71-251.us-west-2.compute.internal CPU stuck for 23s ``` **Untuk mendapatkan acara untuk semua node** ``` kubectl get events --field-selector involvedObject.kind=Node ``` **Untuk mendapatkan acara untuk node tertentu** ``` kubectl get events --field-selector involvedObject.kind=Node,involvedObject.name=node-name ``` **Untuk menonton acara secara real-time** ``` kubectl get events -w --field-selector involvedObject.kind=Node ``` **Contoh keluaran acara:** ``` LAST SEEN TYPE REASON OBJECT MESSAGE 2m Warning MemoryPressure Node/node-1 Node experiencing memory pressure 5m Normal NodeReady Node/node-1 Node became ready ``` ## Perintah pemecahan masalah umum ``` # Get comprehensive node status kubectl get node node-name -o yaml # Watch node status changes kubectl get nodes -w # Get node metrics kubectl top node ``` # Mengambil log node untuk node terkelola menggunakan kubectl dan S3 Pelajari cara mengambil log node untuk node terkelola Amazon EKS yang memiliki agen pemantauan node. ## Prasyarat Pastikan Anda memiliki yang berikut: + Cluster Amazon EKS yang ada dengan agen pemantauan node. Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md). + Alat `kubectl` baris perintah diinstal dan dikonfigurasi untuk berkomunikasi dengan cluster Anda. + AWS CLI diinstal dan masuk dengan izin yang cukup untuk membuat bucket dan objek S3. + Versi terbaru dari Python 3 diinstal + AWS SDK untuk Python 3, Boto 3, diinstal. ## Langkah 1: Buat tujuan bucket S3 (opsional) Jika Anda belum memiliki ember S3 untuk menyimpan log, buat satu. Gunakan perintah AWS CLI berikut. Bucket default ke daftar kontrol `private` akses. Ganti *bucket-name* dengan nama bucket unik pilihan Anda. ``` aws s3api create-bucket --bucket ``` ## Langkah 2: Buat URL S3 yang telah ditandatangani sebelumnya untuk HTTP Put Amazon EKS mengembalikan log node dengan melakukan operasi HTTP PUT ke URL yang Anda tentukan. Dalam tutorial ini, kita akan menghasilkan URL PUT HTTP S3 yang telah ditandatangani sebelumnya. Log akan dikembalikan sebagai tarball gzip, dengan ekstensi. `.tar.gz` **catatan** Anda harus menggunakan AWS API atau SDK untuk membuat URL unggahan S3 yang telah ditandatangani sebelumnya untuk EKS untuk mengunggah file log. Anda tidak dapat membuat URL unggahan S3 yang telah ditandatangani sebelumnya menggunakan CLI AWS . 1. Tentukan di mana dalam ember Anda ingin menyimpan log. Misalnya, Anda dapat menggunakan *2024-11-12/logs1.tar.gz* sebagai kunci. 1. Simpan kode Python berikut ke file. *presign-upload.py* Ganti ** dan**. Kuncinya harus diakhiri dengan`.tar.gz`. ``` import boto3; print(boto3.client('s3').generate_presigned_url( ClientMethod='put_object', Params={'Bucket': '', 'Key': ''}, ExpiresIn=1000 )) ``` 1. Jalankan skrip dengan ``` python presign-upload.py ``` 1. Perhatikan output URL. Gunakan nilai ini di langkah berikutnya sebagai*http-put-destination*. Untuk informasi selengkapnya, lihat [Menghasilkan URL yang telah ditetapkan sebelumnya untuk mengunggah file](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-presigned-urls.html#generating-a-presigned-url-to-upload-a-file) di AWS Boto3 SDK untuk Dokumentasi Python. ## Langkah 3: Buat NodeDiagnostic sumber daya Identifikasi nama node tempat Anda ingin mengumpulkan log dari. Buat `NodeDiagnostic` manifes yang menggunakan nama node sebagai nama sumber daya, dan berikan tujuan URL PUT HTTP. ``` apiVersion: eks.amazonaws.com/v1alpha1 kind: NodeDiagnostic metadata: name: spec: logCapture: destination: http-put-destination ``` Menerapkan manifes ke klaster. ``` kubectl apply -f nodediagnostic.yaml ``` Anda dapat memeriksa Status koleksi dengan menjelaskan `NodeDiagnostic` sumber daya: + Status `Success` atau `SuccessWithErrors` menunjukkan bahwa tugas selesai dan log yang diunggah ke tujuan yang disediakan (`SuccessWithErrors`menunjukkan bahwa beberapa log mungkin hilang) + Jika statusnya Gagal, konfirmasikan URL unggahan sudah terbentuk dengan baik dan tidak kedaluwarsa. ``` kubectl describe nodediagnostics.eks.amazonaws.com/ ``` ## Langkah 4: Unduh log dari S3 Tunggu sekitar satu menit sebelum mencoba mengunduh log. Kemudian, gunakan S3 CLI untuk mengunduh log. ``` # Once NodeDiagnostic shows Success status, download the logs aws s3 cp s3:///key ./.tar.gz ``` ## Langkah 5: Bersihkan NodeDiagnostic sumber daya + `NodeDiagnostic`sumber daya tidak dihapus secara otomatis. Anda harus membersihkannya sendiri setelah Anda mendapatkan artefak log Anda ``` # Delete the NodeDiagnostic resource kubectl delete nodediagnostics.eks.amazonaws.com/ ``` ## NodeDiagnostic `node`Destinasi Dimulai dengan `v1.6.0` versi Node Monitoring Agent, ada opsi untuk mengatur tujuan pengumpulan log`node`. Menggunakan tujuan ini akan mengarah ke pengumpulan dan persistensi sementara log pada node untuk koleksi nanti. Selain fungsi ini, dalam GitHub repositori Node Monitoring Agent adalah `kubectl` plugin yang dapat Anda instal untuk interaksi yang mudah dan pengumpulan log. Untuk informasi lebih lanjut, lihat [dokumentasi untuk `kubectl ekslogs` plugin](https://github.com/aws/eks-node-monitoring-agent/blob/main/tools/kubectl-ekslogs/README.md). ## Contoh Penggunaan ``` # Collect NodeDiagnostic logs from a single node kubectl ekslogs # Collect NodeDiagnostic logs from multiple nodes kubectl ekslogs # Collect NodeDiagnostic logs from all nodes with a specific label kubectl ekslogs -l = ```