**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.
# Memecahkan Masalah Mode Otomatis EKS
Dengan Mode Otomatis EKS, AWS tanggung jawab lebih besar untuk Instans EC2 di akun Anda. AWS EKS bertanggung jawab atas runtime kontainer pada node, sistem operasi pada node, dan pengontrol tertentu. Ini termasuk pengontrol penyimpanan blok, pengontrol penyeimbang beban, dan pengontrol komputasi.
Anda harus menggunakan AWS dan Kubernetes API untuk memecahkan masalah node. Anda dapat:
+ Gunakan `NodeDiagnostic` sumber daya Kubernetes untuk mengambil log node dengan menggunakan file. [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 `NodeDiagnostic` sumber daya Kubernetes untuk menangkap lalu lintas jaringan pada sebuah node. Untuk langkah lebih lanjut, lihat[Tangkap lalu lintas jaringan pada node terkelola menggunakan kubectl dan S3](auto-get-tcpdump.md).
+ Gunakan `get-console-output` perintah AWS EC2 CLI untuk mengambil output konsol dari node. Untuk langkah lebih lanjut, lihat[Dapatkan output konsol dari instans terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console).
+ Gunakan *kontainer debugging* Kubernetes untuk mengambil log node. Untuk langkah lebih lanjut, lihat[Dapatkan log node dengan menggunakan *wadah debug* dan CLI `kubectl`](#auto-node-debug-logs).
**catatan**
Mode Otomatis EKS menggunakan instans terkelola EC2. Anda tidak dapat langsung mengakses instans terkelola EC2, termasuk oleh SSH.
Anda mungkin memiliki masalah berikut yang memiliki solusi khusus untuk komponen Mode Otomatis EKS:
+ Pod terjebak 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).
+ Instance 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 instans terkelola EC2 dengan menggunakan AWS EC2 CLI](#auto-node-console)
+ [Dapatkan log node dengan menggunakan *wadah debug* dan CLI `kubectl`](#auto-node-debug-logs)
+ [Melihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol](#auto-node-ec2-web)
+ [Lihat Kesalahan IAM di akun Anda AWS](#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 pemecahan masalah dan debugging informasi tentang node. Agen pemantauan node menerbitkan Kubernetes `events` dan node. `conditions` Untuk informasi selengkapnya, lihat [Mendeteksi masalah kesehatan node dan mengaktifkan perbaikan node otomatis](node-health.md).
## Dapatkan output konsol dari instans terkelola EC2 dengan menggunakan AWS EC2 CLI
Prosedur ini membantu mengatasi masalah waktu boot atau masalah tingkat kernel.
Pertama, Anda perlu menentukan ID Instans EC2 dari instance 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 membuat daftar pod terkait.
```
kubectl get pods -l app=
```
1. Gunakan nama Pod Kubernetes untuk menentukan ID instans EC2 dari node terkait.
```
kubectl get pod -o wide
```
1. Gunakan ID instans EC2 untuk mengambil output konsol.
```
aws ec2 get-console-output --instance-id --latest --output text
```
## Dapatkan log node dengan menggunakan *wadah debug* dan CLI `kubectl`
Cara yang disarankan untuk mengambil log dari node Mode Otomatis EKS adalah dengan menggunakan `NodeDiagnostic` sumber 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 sebuah 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` ID instance node, `-it` mengalokasikan a `tty` 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 mengalirkan log dari: `kubelet`
```
yum install -y util-linux-core
nsenter -t 1 -m journalctl -f -u kubelet
```
Untuk 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 yang diberikan.
```
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
```
## Melihat sumber daya yang terkait dengan Mode Otomatis EKS di AWS Konsol
Anda dapat menggunakan AWS konsol untuk melihat status sumber daya yang terkait dengan kluster 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)
+ Lihat contoh Mode Otomatis EKS dengan mencari kunci tag `eks:eks-cluster-name`
## Lihat Kesalahan IAM di akun Anda AWS
1. Arahkan ke CloudTrail konsol
1. Pilih “Riwayat Acara” dari panel navigasi kiri
1. Terapkan filter kode kesalahan:
+ AccessDenied
+ UnauthorizedOperation
+ InvalidClientTokenId
Cari kesalahan yang terkait dengan kluster 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` file. Jika `nodeSelector` ada, pastikan bahwa itu digunakan `eks.amazonaws.com/compute-type: auto` untuk dijadwalkan pada node yang dibuat oleh EKS Auto Mode. Untuk informasi selengkapnya tentang label node 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 klaster (CA). Namun, instance ini masih bisa gagal untuk bergabung dengan cluster EKS sebagai node. Jalankan perintah berikut untuk mengidentifikasi instance yang tidak bergabung dengan cluster:
1. `kubectl get nodeclaim`Jalankan untuk memeriksa `NodeClaims` itu`Ready = False`.
```
kubectl get nodeclaim
```
1. Jalankan `kubectl describe nodeclaim ` dan lihat di bawah **Status** untuk menemukan masalah apa pun 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 dalam Mode Otomatis EKS](auto-learn-iam.md).
`Error creating fleet`
Mungkin ada beberapa masalah otorisasi dengan memanggil `RunInstances` panggilan dari EC2 API. AWS CloudTrail Periksa kesalahan dan lihat [Peran IAM kluster 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 menjalankan 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 dari titik akhir server **API Kubernetes**
Untuk mendapatkan **ID instans**, Anda harus membuat beban kerja di cluster untuk menyebabkan Mode Otomatis EKS meluncurkan instans EC2. Ini juga membuat `NodeClaim` objek di cluster Anda yang akan memiliki ID instance. Jalankan `kubectl get nodeclaim -o yaml` untuk mencetak semua yang `NodeClaims` ada 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 dengan menjalankannya**. `kubectl get endpoint kubernetes -o yaml` Alamatnya 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-tama navigasikan ke VPC Reachability Analyzer di file. Konsol Manajemen AWS
1. Klik “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 “Path Destination” pilih “IP Address”
1. Masukkan salah satu alamat IP untuk server API sebagai “Alamat Tujuan”
1. Perluas “Bagian Konfigurasi Header Paket Tambahan”
1. Masukkan “Port Tujuan” dari 443
1. Pilih “Protocol” sebagai TCP jika belum dipilih
1. Klik “Buat dan Analisis Jalur”
1. Analisis mungkin memakan waktu beberapa menit untuk menyelesaikannya. Jika hasil analisis menunjukkan kemampuan jangkauan yang gagal, itu akan menunjukkan di mana kegagalan berada di jalur jaringan sehingga Anda dapat menyelesaikan masalah.
## Berbagi Volume di Seluruh Pod
Node Mode Otomatis EKS dikonfigurasi dengan SELinux dalam mode penegakan yang memberikan 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 memiliki label keamanan multi-kategori (MCS) mereka sendiri yang diterapkan padanya. 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, ia tidak akan dapat memanipulasi file, membuat panggilan sistem sensitif pada host, mengakses runtime container, atau mendapatkan materi kunci rahasia kubelet.
Karena itu, Anda mungkin mengalami masalah saat mencoba berbagi data antar Pod. Misalnya, `PersistentVolumeClaim` dengan mode akses masih tidak `ReadWriteOnce` akan mengizinkan beberapa Pod untuk mengakses volume secara bersamaan.
Untuk mengaktifkan berbagi antar Pod ini, 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 diberikan dua kategori.
```
securityContext:
seLinuxOptions:
level: "s0:c123,c456,c789"
```
## Lihat peristiwa Karpenter di log pesawat kontrol
Untuk klaster 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 node, penskalaan, dan penghentian. Untuk melihat Karpenter-related peristiwa, gunakan kueri Wawasan CloudWatch Log 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 untuk [Karpenter-related peristiwa](https://github.com/kubernetes-sigs/karpenter/blob/main/pkg/events/reason.go) tertentu dalam log audit kube-apiserver. Peristiwa tersebut mencakup berbagai status gangguan, kegagalan penjadwalan, masalah kapasitas, dan masalah terkait simpul. 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 kapasitas atau masalah kompatibilitas dengan jenis instans.
+ Peristiwa siklus hidup node seperti gangguan, penggusuran, atau penghentian.
Untuk menggunakan kueri ini:
1. Arahkan ke CloudWatch konsol
1. Pilih “Wawasan Log” dari panel navigasi kiri
1. Pilih grup log untuk log bidang kontrol kluster EKS Anda
1. Tempelkan kueri ke editor kueri
1. Sesuaikan rentang waktu sesuai kebutuhan
1. Jalankan kueri
Hasilnya akan menunjukkan kepada Anda 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 di bawah ini yang menentukan ID instance ke kueri yang disebutkan di atas:
```
|filter @message like /[.replaceable]`i-12345678910123456`/
```
**catatan**
Untuk menggunakan kueri ini, pencatatan bidang kontrol harus diaktifkan di kluster 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 klaster Anda. Untuk informasi selengkapnya, lihat [Pelajari tentang identitas dan akses dalam 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 khusus di Amazon EKS Auto Mode?](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)