**Bantu meningkatkan 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 GitHub ** tautan ** Edit halaman ini di 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. # Memecahkan Masalah Mode Otomatis EKS Dengan Mode Otomatis EKS, AWS bertanggung jawab lebih besar untuk Instans EC2 di AWS akun Anda. EKS bertanggung jawab atas runtime container pada node, sistem operasi pada node, dan pengontrol tertentu. Ini termasuk pengontrol penyimpanan blok, pengontrol penyeimbangan beban, dan pengontrol komputasi. Anda harus menggunakan AWS dan API Kubernetes untuk memecahkan masalah node. Anda dapat: + Gunakan sumber `NodeDiagnostic` daya Kubernetes untuk mengambil log node dengan menggunakan. [Agen pemantauan simpul](#auto-node-monitoring-agent) Untuk langkah lebih lanjut, lihat[Mengambil log node untuk node terkelola menggunakan kubectl dan S3](auto-get-logs.md). + Gunakan sumber `NodeDiagnostic` daya Kubernetes untuk menangkap lalu lintas jaringan pada node. Untuk langkah lebih lanjut, lihat[Tangkap lalu lintas jaringan pada node terkelola menggunakan kubectl dan S3](auto-get-tcpdump.md). + Gunakan perintah AWS EC2 CLI `get-console-output` untuk mengambil output konsol dari node. Untuk langkah lebih lanjut, lihat[Dapatkan output konsol dari instance terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console). + Gunakan wadah * debugging Kubernetes * untuk mengambil log node. Untuk langkah lebih lanjut, lihat[Dapatkan log simpul dengan menggunakan *wadah debug* dan `kubectl CLI`](#auto-node-debug-logs). **catatan** Mode Otomatis EKS menggunakan instans terkelola EC2. Anda tidak dapat mengakses instans terkelola EC2 secara langsung, termasuk dengan SSH. Anda mungkin memiliki masalah berikut yang memiliki solusi khusus untuk komponen Mode Otomatis EKS: + Pod macet dalam `Pending` status, yang tidak dijadwalkan ke node Mode Otomatis. Untuk solusi lihat[Memecahkan masalah Pod yang gagal menjadwalkan ke node Mode Otomatis](#auto-troubleshoot-schedule). + Instans terkelola EC2 yang tidak bergabung dengan cluster sebagai node Kubernetes. Untuk solusi lihat[Memecahkan masalah node yang tidak bergabung dengan cluster](#auto-troubleshoot-join). + Kesalahan dan masalah dengan`NodePools`,`PersistentVolumes`, dan `Services` yang menggunakan pengontrol yang disertakan dalam Mode Otomatis EKS. Untuk solusi lihat[Memecahkan masalah pengontrol yang disertakan dalam Mode Otomatis](#auto-troubleshoot-controllers). + Keamanan Pod yang ditingkatkan mencegah berbagi volume di seluruh Pod. Untuk solusi lihat[Berbagi Volume di Seluruh Pod](#auto-troubleshoot-share-pod-volumes). Anda dapat menggunakan metode berikut untuk memecahkan masalah komponen Mode Otomatis EKS: + [Dapatkan output konsol dari instance terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console) + [Dapatkan log simpul dengan menggunakan *wadah debug* dan `kubectl CLI`](#auto-node-debug-logs) + [Lihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol](#auto-node-ec2-web) + [Lihat Kesalahan IAM di AWS akun](#auto-node-iam) + [Mendeteksi masalah konektivitas node dengan `VPC Reachability Analyzer`](#auto-node-reachability) ## Agen pemantauan simpul Mode Otomatis EKS mencakup agen pemantauan simpul Amazon EKS. Anda dapat menggunakan agen ini untuk melihat informasi pemecahan masalah dan debugging tentang node. Agen pemantauan node menerbitkan Kubernetes dan `events` node. `conditions` Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md). ## Dapatkan output konsol dari instance terkelola EC2 dengan menggunakan AWS EC2 CLI Prosedur ini membantu memecahkan masalah waktu boot-time atau tingkat kernel. Pertama, Anda perlu menentukan ID Instans EC2 dari instans yang terkait dengan beban kerja Anda. Kedua, gunakan AWS CLI untuk mengambil output konsol. 1. Konfirmasikan bahwa Anda telah `kubectl` menginstal dan terhubung ke cluster Anda 1. (Opsional) Gunakan nama Deployment Kubernetes untuk mencantumkan pod terkait. ``` kubectl get pods -l app= ``` 1. Gunakan nama Pod Kubernetes untuk menentukan ID instance EC2 dari node terkait. ``` kubectl get pod -o wide ``` 1. Gunakan ID instance EC2 untuk mengambil output konsol. ``` aws ec2 get-console-output --instance-id --latest --output text ``` ## Dapatkan log simpul dengan menggunakan *wadah debug* dan `kubectl CLI` Cara yang disarankan untuk mengambil log dari node Mode Otomatis EKS adalah dengan menggunakan sumber `NodeDiagnostic` daya. Untuk langkah-langkah ini, lihat[Mengambil log node untuk node terkelola menggunakan kubectl dan S3](auto-get-logs.md). Namun, Anda dapat melakukan streaming log secara langsung dari instance dengan menggunakan `kubectl debug node` perintah. Perintah ini meluncurkan Pod baru pada node yang ingin Anda debug yang kemudian dapat Anda gunakan secara interaktif. 1. Luncurkan wadah debug. Perintah berikut menggunakan `i-01234567890123456` untuk ID instance node, `-it` mengalokasikan `tty` a dan melampirkan `stdin` untuk penggunaan interaktif, dan menggunakan `sysadmin` profil dari file kubeconfig. ``` kubectl debug node/i-01234567890123456 -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 ``` Contoh output adalah sebagai berikut. ``` Creating debugging pod node-debugger-i-01234567890123456-nxb9c with container debugger on node i-01234567890123456. If you don't see a command prompt, try pressing enter. bash-5.2# ``` 1. Dari shell, Anda sekarang dapat menginstal `util-linux-core` yang menyediakan `nsenter` perintah. Gunakan `nsenter` untuk memasukkan namespace mount PID 1 (`init`) pada host, dan jalankan `journalctl` perintah untuk melakukan streaming log dari: `kubelet` ``` yum install -y util-linux-core nsenter -t 1 -m journalctl -f -u kubelet ``` Demi keamanan, image container Amazon Linux tidak menginstal banyak binari secara default. Anda dapat menggunakan `yum whatprovides` perintah untuk mengidentifikasi paket yang harus diinstal untuk menyediakan biner tertentu. ``` yum whatprovides ps ``` ``` Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025. procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities Repo : @System Matched from: Filename : /usr/bin/ps Provide : /bin/ps procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities Repo : amazonlinux Matched from: Filename : /usr/bin/ps Provide : /bin/ps ``` ## Lihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol Anda dapat menggunakan AWS konsol untuk melihat status sumber daya yang terkait dengan cluster Mode Otomatis EKS Anda. + [Volume EBS ](https://console.aws.amazon.com/ec2/home#Volumes) + Lihat volume Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name` + [Penyeimbang Beban ](https://console.aws.amazon.com/ec2/home#LoadBalancers) + Lihat penyeimbang beban Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name` + [Instans EC2 ](https://console.aws.amazon.com/ec2/home#Instances) Instans Mode Otomatis EKS adalah instans yang dikelola EC2. Mulai 22 April 2026, instans terkelola baru dan sumber daya terkait disembunyikan secara default dari tampilan konsol EC2 dan operasi daftar API (seperti`DescribeInstances`). Jika Anda tidak melihat instans Mode Otomatis di konsol EC2, periksa setelan visibilitas sumber daya terkelola Anda: 1. Buka konsol Amazon EC2 di https://console.aws.amazon.com/ec2/. 1. Di panel navigasi, pilih **Dasbor**. 1. Pada ** kartu Atribut ** Akun, di bawah Peng ** aturan**, pilih Visibilitas ** sumber daya terkelola**. 1. Pilih ** Kelola**, lalu pilih sakelar visibilitas untuk instans terkelola. 1. Pilih **Simpan perubahan**. Setelah mengaktifkan visibilitas, Anda dapat melihat instance Mode Otomatis EKS dengan mencari kunci tag`eks:eks-cluster-name`. Atau, Anda dapat melihat node Mode Otomatis melalui: + Konsol Amazon EKS, di bawah ** tab ** Komputasi cluster Anda. + `kubectl get nodes`dari klien Kubernetes yang dikonfigurasi. + Kueri API EC2 langsung berdasarkan ID instance atau dengan `include-managed-resources` parameter. Untuk informasi selengkapnya, lihat [ Pengaturan visibilitas sumber daya terkelola ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html#managed-resource-visibility-settings) di Panduan * Pengguna * Amazon EC2. ## Lihat Kesalahan IAM di AWS akun 1. Arahkan ke CloudTrail konsol. 1. Pilih ** Riwayat acara ** dari panel navigasi kiri. 1. Pilih ikon pengaturan (roda gigi) di kanan atas tabel riwayat peristiwa dan aktifkan ** kolom Kode ** kesalahan. 1. Tinjau ** kolom Kode ** kesalahan untuk kesalahan terkait izin seperti`AccessDenied`,`UnauthorizedOperation`, dan. `InvalidClientTokenId` Untuk mempersempit daftar, filter berdasarkan sumber ** peristiwa ** (misalnya, `ec2.amazonaws.com` atau`eks.amazonaws.com`) dan rentang waktu. Untuk pemfilteran yang lebih tepat berdasarkan kode kesalahan di jendela waktu yang lebih besar, kueri penyimpanan data peristiwa CloudTrail Lake atau buat tabel Athena (**opsi ** Query in Lake ** dan ** Create Athena table di bagian atas halaman riwayat acara). Cari kesalahan yang terkait dengan cluster EKS Anda. Gunakan pesan kesalahan untuk memperbarui entri akses EKS, peran IAM cluster, atau peran IAM node. Anda mungkin perlu melampirkan kebijakan baru ke peran ini dengan izin untuk Mode Otomatis EKS. ## Memecahkan masalah Pod yang gagal menjadwalkan ke node Mode Otomatis Jika pod tetap dalam `Pending` status dan tidak dijadwalkan ke node mode otomatis, verifikasi apakah pod atau manifes penerapan Anda memiliki`nodeSelector`. Jika `nodeSelector` ada, pastikan bahwa itu digunakan `eks.amazonaws.com/compute-type: auto` untuk dijadwalkan pada node yang dibuat oleh Mode Otomatis EKS. Untuk informasi selengkapnya tentang label simpul yang digunakan oleh Mode Otomatis EKS, lihat[Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md). ## Memecahkan masalah node yang tidak bergabung dengan cluster Mode Otomatis EKS secara otomatis mengonfigurasi instans EC2 baru dengan informasi yang benar untuk bergabung dengan cluster, termasuk titik akhir cluster dan otoritas sertifikat cluster (CA). Namun, instans ini masih bisa gagal bergabung dengan cluster EKS sebagai node. Jalankan perintah berikut untuk mengidentifikasi instance yang tidak bergabung dengan cluster: 1. J `kubectl get nodeclaim` alankan untuk memeriksa `NodeClaims` apakah itu`Ready = False`. ``` kubectl get nodeclaim ``` 1. J `kubectl describe nodeclaim ` alankan dan lihat di bawah ** Status ** untuk menemukan masalah yang mencegah node bergabung dengan cluster. ``` kubectl describe nodeclaim ``` **Pesan kesalahan umum: ** `Error getting launch template configs` Anda mungkin menerima kesalahan ini jika Anda menyetel tag kustom `NodeClass` dengan izin peran IAM cluster default. Lihat [Pelajari tentang identitas dan akses di Mode Otomatis EKS](auto-learn-iam.md). `Error creating fleet` Mungkin ada beberapa masalah otorisasi dengan memanggil `RunInstances` panggilan dari API EC2. Per AWS CloudTrail iksa kesalahan dan lihat [Peran IAM cluster Mode Otomatis Amazon EKS](auto-cluster-iam-role.md) izin IAM yang diperlukan. ### Mendeteksi masalah konektivitas node dengan `VPC Reachability Analyzer` **catatan** Anda dikenakan biaya untuk setiap analisis yang dijalankan oleh VPC Reachability Analyzer. Untuk detail harga, lihat Harga [ Amazon VPC. ](https://aws.amazon.com/vpc/pricing/) Salah satu alasan mengapa instance tidak bergabung dengan cluster adalah masalah konektivitas jaringan yang mencegah mereka mencapai server API. Untuk mendiagnosis masalah ini, Anda dapat menggunakan [ VPC Reachability Analyzer ](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) untuk melakukan analisis konektivitas antara node yang gagal bergabung dengan cluster dan server API. Anda akan membutuhkan dua informasi: + **ID instance ** dari node yang tidak dapat bergabung dengan cluster + Alamat IP titik akhir server ** API Kubernetes ** Untuk mendapatkan ID ** instance**, Anda harus membuat beban kerja pada cluster untuk menyebabkan Mode Otomatis EKS meluncurkan instance EC2. Ini juga membuat `NodeClaim` objek di cluster Anda yang akan memiliki ID instance. J `kubectl get nodeclaim -o yaml` alankan untuk mencetak semua `NodeClaims` di cluster Anda. Masing-masing `NodeClaim` berisi ID instance sebagai bidang dan lagi di providerId: ``` kubectl get nodeclaim -o yaml ``` Contoh output adalah sebagai berikut. ``` nodeName: i-01234567890123456 providerID: aws:///us-west-2a/i-01234567890123456 ``` Anda dapat menentukan titik akhir ** server API ** Kubernetes Anda dengan menjalankan. `kubectl get endpoint kubernetes -o yaml` Alamat ada di bidang alamat: ``` kubectl get endpoints kubernetes -o yaml ``` Contoh output adalah sebagai berikut. ``` apiVersion: v1 kind: Endpoints metadata: name: kubernetes namespace: default subsets: - addresses: - ip: 10.0.143.233 - ip: 10.0.152.17 ports: - name: https port: 443 protocol: TCP ``` Dengan dua informasi ini, Anda dapat melakukan analisis. Pertama navigasikan ke VPC Reachability Analyzer di. Konsol Manajemen AWS 1. Pilih “Buat dan Analisis Jalur” 1. Berikan nama untuk analisis (misalnya “Node Join Failure”) 1. Untuk “Jenis Sumber” pilih “Instans” 1. Masukkan ID instance dari Node yang gagal sebagai “Sumber” 1. Untuk “Tujuan Jalur” pilih “Alamat IP” 1. Masukkan salah satu alamat IP untuk server API sebagai “Alamat Tujuan” 1. Perluas “Bagian Konfigurasi Header Paket Tambahan” 1. Masukkan “Port Tujuan” 443 1. Pilih “Protokol” sebagai TCP jika belum dipilih 1. Pilih “Buat dan Analisis Jalur” 1. Analisis mungkin memakan waktu beberapa menit untuk menyelesaikannya. Jika hasil analisis menunjukkan jangkauan gagal, itu akan menunjukkan di mana kegagalan berada di jalur jaringan sehingga Anda dapat menyelesaikan masalah. ## Berbagi Volume di Seluruh Pod EKS Auto Mode Nodes dikonfigurasi dengan SELinux dalam mode penegakan yang menyediakan lebih banyak isolasi antara Pod yang berjalan pada Node yang sama. Ketika SELinux diaktifkan, sebagian besar pod yang tidak memiliki hak istimewa akan secara otomatis menerapkan label keamanan multi-kategori (MCS) mereka sendiri. Label MCS ini unik per Pod, dan dirancang untuk memastikan bahwa proses dalam satu Pod tidak dapat memanipulasi proses di Pod lain atau pada host. Bahkan jika Pod berlabel berjalan sebagai root dan memiliki akses ke sistem file host, itu tidak akan dapat memanipulasi file, membuat panggilan sistem sensitif pada host, mengakses runtime container, atau mendapatkan materi kunci rahasia kubelet. Karena ini, Anda mungkin mengalami masalah saat mencoba berbagi data antar Pod. Misalnya, a `PersistentVolumeClaim` dengan mode akses `ReadWriteOnce` akan tetap tidak mengizinkan beberapa Pod untuk mengakses volume secara bersamaan. Untuk mengaktifkan berbagi ini antar Pod, Anda dapat menggunakan Pod `seLinuxOptions` untuk mengonfigurasi label MCS yang sama pada Pod tersebut. Dalam contoh ini, kita menetapkan tiga kategori `c123,c456,c789` ke Pod. Ini tidak akan bertentangan dengan kategori apa pun yang ditetapkan ke Pod pada node secara otomatis, karena mereka hanya akan diberi dua kategori. ``` securityContext: seLinuxOptions: level: "s0:c123,c456,c789" ``` ## Melihat peristiwa Karpenter di log bidang kontrol Untuk cluster EKS dengan log bidang kontrol diaktifkan, Anda dapat memperoleh wawasan tentang tindakan dan proses pengambilan keputusan Karpenter dengan menanyakan log. Ini dapat sangat berguna untuk memecahkan masalah Mode Otomatis EKS yang terkait dengan penyediaan, penskalaan, dan penghentian node. Untuk melihat Karpenter-related peristiwa, gunakan kueri Log CloudWatch s Insights berikut: ``` fields @timestamp, @message | filter @logStream like /kube-apiserver-audit/ | filter @message like 'DisruptionBlocked' or @message like 'DisruptionLaunching' or @message like 'DisruptionTerminating' or @message like 'DisruptionWaitingReadiness' or @message like 'Unconsolidatable' or @message like 'FailedScheduling' or @message like 'NoCompatibleInstanceTypes' or @message like 'NodeRepairBlocked' or @message like 'Disrupted' or @message like 'Evicted' or @message like 'FailedDraining' or @message like 'TerminationGracePeriodExpiring' or @message like 'TerminationFailed' or @message like 'FailedConsistencyCheck' or @message like 'InsufficientCapacityError' or @message like 'UnregisteredTaintMissing' or @message like 'NodeClassNotReady' | sort @timestamp desc ``` Kueri ini memfilter [ Karpenter-related peristiwa tertentu ](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) di log audit kube-apiserver. Peristiwa tersebut mencakup berbagai status gangguan, kegagalan penjadwalan, masalah kapasitas, dan masalah terkait node. Dengan menganalisis log ini, Anda dapat memperoleh pemahaman yang lebih baik tentang: + Mengapa Karpenter mengambil tindakan tertentu. + Masalah apa pun yang mencegah penyediaan, penskalaan, atau penghentian node yang tepat. + Potensi masalah kapasitas atau kompatibilitas dengan tipe instance. + Peristiwa siklus hidup node seperti gangguan, penggusuran, atau penghentian. Untuk menggunakan kueri ini: 1. Arahkan ke CloudWatch konsol 1. Pilih “Logs Insights” dari panel navigasi kiri 1. Pilih grup log untuk log bidang kontrol cluster EKS Anda 1. Tempelkan kueri ke editor kueri 1. Sesuaikan rentang waktu sesuai kebutuhan 1. Jalankan kueri Hasilnya menunjukkan garis waktu Karpenter-related peristiwa, membantu Anda memecahkan masalah dan memahami perilaku Mode Otomatis EKS di cluster Anda. Untuk meninjau tindakan Karpenter pada node tertentu, Anda dapat menambahkan filter baris berikut yang menentukan ID instance ke kueri: ``` |filter @message like /{{i-12345678910123456}}/ ``` **catatan** Untuk menggunakan kueri ini, pencatatan bidang kontrol harus diaktifkan pada cluster EKS Anda. Jika Anda belum melakukan ini, silakan merujuk ke[Kirim log pesawat kontrol ke CloudWatch Log](control-plane-logs.md). ## Memecahkan masalah pengontrol yang disertakan dalam Mode Otomatis Jika Anda memiliki masalah dengan pengontrol, Anda harus meneliti: + Jika sumber daya yang terkait dengan pengontrol itu diformat dengan benar dan valid. + Jika sumber daya AWS IAM dan Kubernetes RBAC dikonfigurasi dengan benar untuk cluster Anda. Untuk informasi selengkapnya, lihat [Pelajari tentang identitas dan akses di Mode Otomatis EKS](auto-learn-iam.md). ## Sumber daya terkait Gunakan artikel ini dari AWS Re: Post untuk langkah-langkah pemecahan masalah lanjutan: + [Bagaimana cara memecahkan masalah penskalaan umum di EKS Auto-Mode? ](https://repost.aws/articles/ARLpQOknr5Rb-w5iAT9sUBpQ) + [Bagaimana cara memecahkan masalah penyediaan nodepool dan nodeclass kustom di Mode Otomatis Amazon EKS? ](https://repost.aws/articles/ARPcmFS1POTgqPCBdcZFp6BQ) + [Bagaimana cara memecahkan masalah kumpulan node bawaan Mode Otomatis EKS dengan Status Tidak Dikenal? ](https://repost.aws/en/articles/ARLhrdl45TRASGkvViwtBG0Q)