Memecahkan masalah dengan cluster dan node Amazon EKS

Bab ini mencakup beberapa kesalahan umum yang mungkin dapat Anda temui saat menggunakan Amazon EKS dan cara yang dilakukan untuk mengatasinya. Jika Anda perlu memecahkan masalah area Amazon EKS tertentu, lihat Add-Ons topik terpisahMenyelesaikan masalah IAM,Memecahkan masalah Amazon EKS Connector, dan Pemec ahan Masalah untuk ADOT menggunakan EKS.

Untuk informasi pemecahan masalah lainnya, lihat konten Pusat Pengetahuan tentang Layanan Amazon Elastic Kubernetes di Re:Post. AWS

Kapasitas tidak mencukupi

Jika Anda menerima kesalahan berikut saat mencoba membuat cluster Amazon EKS, maka salah satu Zona Ketersediaan yang Anda tentukan tidak memiliki kapasitas yang cukup untuk mendukung cluster.

Cannot create cluster 'example-cluster' because region-1d, the targeted Availability Zone, does not currently have sufficient capacity to support the cluster. Retry and choose from these Availability Zones: region-1a, region-1b, region-1c

Mencoba lagi membuat klaster Anda dengan subnet di klaster VPC yang meng-host di Availability Zone dikembalikan oleh pesan kesalahan ini.

Ada Zona Ketersediaan yang tidak dapat berada di kluster. Bandingkan Zona Ketersediaan tempat subnet Anda berada dengan daftar Zona Ketersediaan dalam persyaratan dan pertim bangan Subnet.

Simpul gagal untuk bergabung dengan klaster

Ada beberapa alasan umum yang mencegah simpul bergabung dengan klaster:

Untuk mengidentifikasi dan memecahkan masalah penyebab umum yang mencegah node pekerja bergabung dengan cluster, Anda dapat menggunakan AWSSupport-TroubleshootEKSWorkerNode runbook. Untuk informasi selengkapnya, lihat AWSSupport-TroubleshootEKSWorkerNode di referensi runbook AWS System Manager Automation.

Tidak sah atau akses ditolak (kubectl)

Jika Anda menerima salah satu kesalahan berikut saat menjalankan kubectl perintah, berarti Anda belum mengon kubectl figurasi dengan benar untuk Amazon EKS atau kredentif untuk prinsipal IAM (peran atau pengguna) yang Anda gunakan jangan memetakan ke nama pengguna Kubernetes yang memiliki izin yang cukup untuk objek Kubernetes di cluster Amazon EKS Anda.

Ini bisa disebabkan oleh salah satu alasan berikut:

Jika Anda menginstal dan mengkonfigurasi AWS CLI, Anda dapat mengonfigurasi kredentif IAM yang Anda gunakan. Untuk informasi selengkapnya, lihat Mengkonfigurasi AWS CLI di Panduan Pengguna Antar AWS muka Baris Perintah. Anda juga dapat mengonfigurasi kubectl untuk menggunakan peran IAM, jika Anda mengambil peran IAM untuk mengakses objek Kubernetes di cluster Anda. Untuk informasi selengkapnya, lihat Hubungkan kubectl ke cluster EKS dengan membuat file kubeconfig.

hostname tidak cocok

Versi Python sistem Anda harus 2.7.9 atau lebih baru. Jika tidak, Anda menerima hostname doesn’t match kesalahan dengan panggilan AWS CLI ke Amazon EKS. Untuk informasi selengkapnya, lihat Apa itu kesalahan “nama host tidak cocok”? dalam Pertanyaan yang Sering Diajukan Python.

getsockopt: tidak ada rute ke host

Docker berjalan di Kisaran CIDR 172.17.0.0/16 di klaster Amazon EKS. Sebaiknya subnet VPC cluster Anda tidak tumpang tindih dengan rentang ini. Jika tidak, Anda akan menerima kesalahan berikut:

Error: : error upgrading connection: error dialing backend: dial tcp 172.17.<nn>.<nn>:10250: getsockopt: no route to host

Instans gagal bergabung dengan cluster Kubernetes

Jika Anda menerima kesalahan Instances failed to join the Kubernetes cluster di Konsol Manajemen AWS, pastikan bahwa akses titik akhir pribadi cluster diaktifkan, atau bahwa Anda telah mengonfigurasi blok CIDR dengan benar untuk akses titik akhir publik. Untuk informasi selengkapnya, lihat Titik akhir server API klaster.

Kode kesalahan grup simpul terkelola

Jika grup node terkelola Anda mengalami masalah kesehatan perangkat keras, Amazon EKS mengembalikan kode kesalahan untuk membantu Anda mendiagnosis masalah. Pemeriksaan kesehatan ini tidak mendeteksi masalah perangkat lunak karena didasarkan pada pemeriksaan kesehatan Amazon EC2. Daftar berikut menjelaskan kode kesalahan.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl describe clusterrole eks:node-manager

kubectl describe clusterrolebinding eks:node-manager

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: eks:node-manager
rules:
- apiGroups:
  - ''
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - delete
- apiGroups:
  - ''
  resources:
  - nodes
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - ''
  resources:
  - pods/eviction
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks:node-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: eks:node-manager
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: eks:node-manager

kubectl apply -f eks-node-manager-role.yaml

Tidak diotorisasi untuk gambar

Salah satu penyebab potensial pesan Not authorized for images kesalahan adalah menggunakan Amazon EKS Windows AMI pribadi untuk meluncurkan grup node yang dikelola Windows. Setelah merilis AMI Windows baru, AWS membuat AMI yang lebih tua dari 4 bulan menjadi pribadi, yang membuatnya tidak lagi dapat diakses. Jika grup node terkelola menggunakan AMI Windows pribadi, pertimbangkan untuk memperbarui grup node terkelola Windows Anda. Meskipun kami tidak dapat menjamin bahwa kami dapat menyediakan akses ke AMI yang telah dibuat pribadi, Anda dapat meminta akses dengan mengajukan tiket ke AWS Dukungan. Untuk informasi selengkapnya, lihat Pat ch di Panduan Pengguna Amazon EC2.

Node berada dalam NotReady keadaan

Jika node Anda memasuki NotReady status, ini kemungkinan menunjukkan bahwa node tidak sehat dan tidak tersedia untuk menjadwalkan Pod baru. Hal ini dapat terjadi karena berbagai alasan, seperti node kekurangan sumber daya yang cukup untuk CPU, memori, atau ruang disk yang tersedia.

Untuk AMI Windows yang dioptimalkan Amazon EKS, tidak ada reservasi untuk sumber daya komputasi yang ditentukan secara default dalam kubelet konfigurasi. Untuk membantu mencegah masalah sumber daya, Anda dapat mencadangkan sumber daya komputasi untuk proses sistem kubelet dengan menyediakan nilai konfigurasi untuk kube- and/or reservasi sistem-reservasi. Anda melakukan ini menggunakan parameter -KubeletExtraArgs baris perintah dalam skrip bootstrap. Untuk informasi selengkapnya, lihat Cadangan Sumber Daya Komputasi untuk Daemon Sistem dalam dokumentasi Kubernetes dan dalam panduan pengguna ini. Parameter konfigurasi skrip bootstrap

Kolektor Log EKS

Untuk memecahkan masalah dengan node Amazon EKS, ada skrip bawaan yang tersedia di node yang terletak di/etc/eks/log-collector-script/eks-log-collector.sh. Anda dapat menggunakan skrip untuk mengumpulkan log diagnostik untuk kasus dukungan dan pemecahan masalah umum.

Menggunakan perintah berikut ini untuk menjalankan skrip di simpul Anda:

sudo bash /etc/eks/log-collector-script/eks-log-collector.sh

curl -O https://amazon-eks.s3.amazonaws.com/support/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

Skrip mengumpulkan informasi diagnostik berikut.

$ sudo bash /etc/eks/log-collector-script/eks-log-collector.sh

      This is version 0.7.8. New versions can be found at https://github.com/awslabs/amazon-eks-ami/blob/main/log-collector-script/

Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
...
...

	Done... your bundled logs are located in /var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz

Informasi diagnostik dikumpulkan dan disimpan di:

/var/log/eks_i-EXAMPLE_2025-03-25_0000-UTC_0.7.8.tar.gz

Untuk mengambil bundel log untuk node Bottlerocket, silakan merujuk ke Bo ttlerocket Logs untuk detail lebih lanjut.

Jaringan waktu aktif kontainer belum siap

Anda mungkin mendapatkan kesalahan Container runtime network not ready dan otorisasi kesalahan yang mirip dengan berikut ini:

4191 kubelet.go:2130] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized
4191 kubelet_node_status.go:106] Unable to register node "ip-10-40-175-122.ec2.internal" with API server: Unauthorized
4191 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:452: Failed to list *v1.Service: Unauthorized

Ini dapat terjadi karena salah satu alasan berikut:

Waktu habis handshake TLS

Ketika node tidak dapat membuat koneksi ke titik akhir server API publik, Anda mungkin melihat kesalahan yang mirip dengan kesalahan berikut.

server.go:233] failed to run Kubelet: could not init cloud provider "aws": error finding instance i-1111f2222f333e44c: "error listing AWS instances: \"RequestError: send request failed\\ncaused by: Post  net/http: TLS handshake timeout\""

Proses kubelet akan terus-menerus me-respawn dan menguji titik akhir server API. Kesalahan juga dapat terjadi sementara selama prosedur yang performa update klaster bergulir di bidang kendali, seperti perubahan konfigurasi atau versi update.

Untuk mengatasi masalah itu, memeriksa tabel rute dan grup keamanan untuk memastikan bahwa lalu lintas dari simpul dapat mencapai titik akhir publik.

InvalidClientTokenId

Jika Anda menggunakan peran IAM untuk akun layanan untuk Pod atau DaemonSet diterapkan ke cluster di Wil AWS ayah China, dan belum menyetel variabel AWS_DEFAULT_REGION lingkungan dalam spesifikasi, Pod atau DaemonSet mungkin menerima kesalahan berikut:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid

Untuk mengatasi masalah ini, Anda perlu menambahkan variabel AWS_DEFAULT_REGION lingkungan ke Pod atau DaemonSet spesifikasi Anda, seperti yang ditunjukkan pada contoh spesifikasi Pod berikut.

apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
  - name: envar-demo-container
    image: gcr.io/google-samples/node-hello:1.0
    env:
    - name: AWS_DEFAULT_REGION
      value: "region-code"

Grup node harus cocok dengan versi Kubernetes sebelum memutakhirkan bidang kontrol

Sebelum Anda memutakhirkan pesawat kontrol ke versi Kubernetes baru, versi minor dari node terkelola dan Fargate di cluster Anda harus sama dengan versi pesawat kontrol Anda saat ini. Amazon EKS update-cluster-version API menolak permintaan sampai Anda memutakhirkan semua node yang dikelola Amazon EKS ke versi cluster saat ini. Amazon EKS menyediakan API untuk meningkatkan node terkelola. Untuk informasi tentang memutakhirkan versi Kubernetes grup node terkelola, lihat. Memperbarui grup node terkelola untuk klaster Anda Untuk memutakhirkan versi node Fargate, hapus pod yang diwakili oleh node dan gunakan kembali pod setelah Anda memutakhirkan bidang kontrol Anda. Untuk informasi selengkapnya, lihat Perbarui klaster yang ada ke versi Kubernetes baru.

Saat meluncurkan banyak node, ada kesalahan Ter lalu Banyak Permintaan

Jika Anda meluncurkan banyak node secara bersamaan, Anda mungkin melihat pesan kesalahan di log eksekusi data pengguna Amazon EC2 yang mengatakanToo Many Requests. Hal ini dapat terjadi karena bidang kontrol kelebihan beban dengan describeCluster panggilan. Overloading mengakibatkan throttling, node gagal menjalankan skrip bootstrap, dan node gagal bergabung dengan cluster sama sekali.

Pastikan bahwa--apiserver-endpoint,--b64-cluster-ca, dan --dns-cluster-ip argumen diteruskan ke skrip bootstrap node. Saat menyertakan argumen ini, skrip bootstrap tidak perlu melakukan describeCluster panggilan, yang membantu mencegah bidang kontrol kelebihan beban. Untuk informasi selengkapnya, lihat Menentukan AMI.

Respons kesalahan HTTP 401 tidak sah pada permintaan server API Kubernetes

Anda melihat kesalahan ini jika token akun layanan Pod telah kedaluwarsa pada cluster.

Server API Kubernetes cluster Amazon EKS Anda menolak permintaan dengan token yang lebih lama dari 90 hari. Dalam versi Kubernetes sebelumnya, token tidak memiliki kedaluwarsa. Ini berarti bahwa klien yang mengandalkan token ini harus menyegarkannya dalam waktu satu jam. Untuk mencegah server API Kubernetes menolak permintaan Anda karena token yang tidak valid, versi SDK klien Kubernetes yang digunakan oleh beban kerja Anda harus sama, atau lebih baru dari versi berikut:

Anda dapat mengidentifikasi semua Pod yang ada di cluster Anda yang menggunakan token basi. Untuk informasi selengkapnya, lihat Token akun layanan.

Versi platform Amazon EKS lebih dari dua versi di belakang versi platform saat ini

Ini dapat terjadi ketika Amazon EKS tidak dapat memperbarui versi platform cluster Anda secara otomatis. Meskipun ada banyak penyebab untuk ini, beberapa penyebab umum mengikuti. Jika salah satu dari masalah ini berlaku untuk cluster Anda, itu mungkin masih berfungsi, versi platformnya tidak akan diperbarui oleh Amazon EKS.

Masalah

Per an IAM cluster dihapus — Peran ini ditentukan saat cluster dibuat. Anda dapat melihat peran mana yang ditentukan dengan perintah berikut. Ganti my-cluster dengan nama klaster Anda.

aws eks describe-cluster --name my-cluster --query cluster.roleArn --output text | cut -d / -f 2

Contoh output adalah sebagai berikut.

eksClusterRole

Solusi

Buat peran IAM cluster baru dengan nama yang sama.

Masalah

Subnet yang ditentukan selama pembuatan cluster dihapus — Subnet yang akan digunakan dengan cluster ditentukan selama pembuatan cluster. Anda dapat melihat subnet mana yang ditentukan dengan perintah berikut. Ganti my-cluster dengan nama klaster Anda.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.subnetIds

Contoh output adalah sebagai berikut.

[
"subnet-EXAMPLE1",
"subnet-EXAMPLE2"
]

Solusi

Konfirmasikan apakah ID subnet ada di akun Anda.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" --query "Subnets[*].SubnetId"

Contoh output adalah sebagai berikut.

[
"subnet-EXAMPLE3",
"subnet-EXAMPLE4"
]

Jika ID subnet yang dikembalikan dalam output tidak cocok dengan ID subnet yang ditentukan saat cluster dibuat, maka jika Anda ingin Amazon EKS memperbarui cluster, Anda perlu mengubah subnet yang digunakan oleh cluster. Ini karena jika Anda menentukan lebih dari dua subnet saat membuat cluster, Amazon EKS secara acak memilih subnet yang Anda tentukan untuk membuat antarmuka jaringan elastis baru. Antarmuka jaringan ini memungkinkan bidang kontrol untuk berkomunikasi dengan node Anda. Amazon EKS tidak akan memperbarui cluster jika subnet yang dipilihnya tidak ada. Anda tidak memiliki kendali atas subnet mana yang Anda tentukan pada pembuatan cluster yang dipilih Amazon EKS untuk membuat antarmuka jaringan baru.

Saat Anda memulai pembaruan versi Kubernetes untuk cluster Anda, pembaruan dapat gagal karena alasan yang sama.

Masalah

Grup keamanan yang ditentukan selama pembuatan cluster dihapus — Jika Anda menentukan grup keamanan selama pembuatan cluster, Anda dapat melihat ID mereka dengan perintah berikut. Ganti my-cluster dengan nama klaster Anda.

aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.securityGroupIds

Contoh output adalah sebagai berikut.

[
    "sg-EXAMPLE1"
]

Jika [] dikembalikan, maka tidak ada grup keamanan yang ditentukan saat cluster dibuat dan grup keamanan yang hilang tidak menjadi masalah. Jika grup keamanan dikembalikan, konfirmasikan bahwa grup keamanan ada di akun Anda.

Solusi

Konfirmasikan apakah grup keamanan ini ada di akun Anda.

vpc_id=$(aws eks describe-cluster --name my-cluster --query cluster.resourcesVpcConfig.vpcId --output text)
aws ec2 describe-security-groups --filters "Name=vpc-id,Values=$vpc_id" --query "SecurityGroups[*].GroupId"

Contoh output adalah sebagai berikut.

[
"sg-EXAMPLE2"
]

Jika ID grup keamanan yang dikembalikan dalam output tidak cocok dengan ID grup keamanan yang ditentukan saat cluster dibuat, maka jika Anda ingin Amazon EKS memperbarui cluster, Anda perlu mengubah grup keamanan yang digunakan oleh cluster. Amazon EKS tidak akan memperbarui cluster jika ID grup keamanan yang ditentukan saat pembuatan cluster tidak ada.

Saat Anda memulai pembaruan versi Kubernetes untuk cluster Anda, pembaruan dapat gagal karena alasan yang sama.

FAQ kesehatan cluster dan kode kesalahan dengan jalur resolusi

Amazon EKS mendeteksi masalah dengan cluster EKS Anda dan infrastruktur cluster dan menyimpannya di objek kesehatan sumber daya cluster EKS Anda. Anda dapat mendeteksi, memecahkan masalah, dan mengatasi masalah cluster lebih cepat dengan bantuan informasi kesehatan cluster. Ini memungkinkan Anda untuk membuat lingkungan aplikasi yang lebih aman dan terkini. Selain itu, mungkin tidak mungkin bagi Anda untuk meningkatkan ke versi Kubernetes yang lebih baru atau bagi Amazon EKS untuk menginstal pembaruan keamanan pada cluster yang terdegradasi sebagai akibat dari masalah dengan infrastruktur atau konfigurasi cluster yang diperlukan. Amazon EKS dapat memakan waktu 3 jam untuk mendeteksi masalah atau mendeteksi bahwa masalah telah diselesaikan.

Kesehatan cluster Amazon EKS adalah tanggung jawab bersama antara Amazon EKS dan penggunanya. Anda bertanggung jawab atas prasyarat infrastruktur peran IAM dan subnet Amazon VPC, serta infrastruktur lain yang diperlukan, yang harus disediakan terlebih dahulu. Amazon EKS mendeteksi perubahan dalam konfigurasi infrastruktur dan cluster ini.

Untuk mengakses kesehatan cluster Anda di konsol Amazon EKS, cari tabel bernama Masalah Kesehatan di tab Masalah kesehatan Cluster pada dasbor pengamatan yang diakses dari halaman detail cluster Amazon EKS. Data ini juga akan tersedia dengan memanggil DescribeCluster tindakan di EKS API, misalnya dari dalam AWS Command Line Interface.

Dua kolom pertama adalah apa yang diperlukan untuk nilai respons API. Bidang ketiga dari ClusterIssue objek Kesehatan adalah ResourceIds, yang pengembaliannya tergantung pada jenis masalah.