Memecahkan masalah dengan kluster 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 topik terpisah Menyelesaikan masalah IAMMemecahkan masalah Konektor Amazon EKS, dan Pemecahan Masalah untuk ADOT menggunakan topik Eks Add-On.

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

Kapasitas tidak mencukupi

Jika Anda menerima kesalahan berikut saat mencoba membuat klaster Amazon EKS, maka salah satu Availability Zone yang Anda tentukan tidak memiliki kapasitas yang cukup untuk mendukung klaster.

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 Availability Zone dimana cluster tidak dapat berada. Bandingkan Availability Zones tempat subnet Anda berada dengan daftar Availability Zone dalam persyaratan dan pertimbangan 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 runbook. AWSSupport-TroubleshootEKSWorkerNode Untuk informasi selengkapnya, lihat AWSSupport-TroubleshootEKSWorkerNode di referensi buku runbook Automation AWS Systems Manager.

Tidak sah atau akses ditolak (kubectl)

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

Ini bisa disebabkan oleh salah satu alasan berikut:

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

hostname doesn’t match

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”? di Python Permintaan Pertanyaan yang Sering Diajukan.

getsockopt: no route to host

Docker berjalan dalam kisaran 172.17.0.0/16 CIDR di kluster Amazon EKS. Kami menyarankan agar 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

Instances failed to join the Kubernetes cluster

Jika Anda menerima kesalahan Instances failed to join the Kubernetes cluster dalam AWS Management Console, pastikan bahwa akses endpoint pribadi kluster diaktifkan, atau bahwa Anda telah mengonfigurasi blok CIDR dengan benar untuk akses titik akhir publik. Untuk informasi selengkapnya, lihat Kontrol akses jaringan ke titik akhir server API cluster.

Kode kesalahan grup node terkelola

Jika grup node terkelola Anda mengalami masalah kesehatan perangkat keras, Amazon EKS mengembalikan kode kesalahan untuk membantu Anda mendiagnosis masalah tersebut. Pemeriksaan kesehatan ini tidak mendeteksi masalah perangkat lunak karena didasarkan pada pemeriksaan EC2 kesehatan Amazon. 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

Not authorized for images

Salah satu penyebab potensial pesan Not authorized for images kesalahan adalah menggunakan Amazon EKS pribadi Windows AMI akan diluncurkan Windows kelompok simpul terkelola. Setelah merilis baru Windows AMIs, AWS membuat AMIs yang lebih tua dari 4 bulan pribadi, yang membuat mereka tidak lagi dapat diakses. Jika grup node terkelola Anda menggunakan private Windows AMI, pertimbangkan untuk memperbarui grup node terkelola Windows Anda. Meskipun kami tidak dapat menjamin bahwa kami dapat menyediakan akses ke AMIs yang telah dibuat pribadi, Anda dapat meminta akses dengan mengajukan tiket ke AWS Support. Untuk informasi selengkapnya, lihat Patch di Panduan EC2 Pengguna Amazon.

Node dalam NotReady keadaan

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

Untuk Amazon EKS dioptimalkan Windows AMIs, 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-reserved dan/atau system-reserved. Anda melakukan ini menggunakan parameter -KubeletExtraArgs baris perintah dalam skrip bootstrap. Untuk informasi selengkapnya, lihat Reserve Compute Resources for System Daemon di Kubernetes dokumentasi dan Parameter konfigurasi skrip bootstrap dalam panduan pengguna ini.

Alat pengumpulan log CNI

Bagian Amazon VPC CNI plugin for Kubernetes memiliki skrip pemecahan masalah sendiri yang tersedia di node di. /opt/cni/bin/aws-cni-support.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 /opt/cni/bin/aws-cni-support.sh

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh
sudo bash eks-log-collector.sh

Skrip mengumpulkan informasi diagnostik berikut. Versi CNI yang telah di-deploy dapat lebih awal dari versi skrip.

      This is version 0.6.1. New versions can be found at https://github.com/awslabs/amazon-eks-ami

Trying to collect common operating system logs...
Trying to collect kernel logs...
Trying to collect mount points and volume information...
Trying to collect SELinux status...
Trying to collect iptables information...
Trying to collect installed packages...
Trying to collect active system services...
Trying to collect Docker daemon information...
Trying to collect kubelet information...
Trying to collect L-IPAMD information...
Trying to collect sysctls information...
Trying to collect networking information...
Trying to collect CNI configuration information...
Trying to collect running Docker containers and gather container data...
Trying to collect Docker daemon logs...
Trying to archive gathered information...

	Done... your bundled logs are located in /var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

Informasi diagnostik dikumpulkan dan disimpan di:

/var/log/eks_i-0717c9d54b6cfaa19_2020-03-24_0103-UTC_0.6.1.tar.gz

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 AWS Wilayah Tiongkok, 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 spec, seperti yang ditunjukkan pada contoh berikut Pod spesifikasi.

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 Kubernetes versi sebelum memutakhirkan bidang kontrol

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

Saat meluncurkan banyak node, ada Too Many Requests kesalahan

Jika Anda meluncurkan banyak node secara bersamaan, Anda mungkin melihat pesan kesalahan di log eksekusi data EC2 pengguna Amazon yang mengatakanToo Many Requests. Ini dapat terjadi karena bidang kontrol sedang kelebihan beban dengan describeCluster panggilan. Kelebihan beban mengakibatkan pelambatan, 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 sedang diteruskan ke skrip bootstrap node. Saat memasukkan argumen ini, skrip bootstrap tidak perlu melakukan describeCluster panggilan, yang membantu mencegah bidang kontrol kelebihan beban. Untuk informasi selengkapnya, lihat Berikan data pengguna untuk meneruskan argumen ke bootstrap.sh file yang disertakan dengan Amazon EKS yang dioptimalkan Linux/Bottlerocket AMI.

HTTP 401 respons kesalahan tidak sah pada Kubernetes Permintaan server API

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

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

Anda dapat mengidentifikasi semua yang ada Pods 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, mungkin masih berfungsi, versi platformnya tidak akan diperbarui oleh Amazon EKS.

Masalah

Peran IAM cluster telah 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 telah dihapus — Subnet yang 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 subnet IDs 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 subnet yang IDs dikembalikan dalam output tidak cocok dengan subnet IDs 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 klaster, 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.

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

Masalah

Grup keamanan yang ditentukan selama pembuatan klaster telah dihapus - Jika Anda menentukan grup keamanan selama pembuatan klaster, Anda dapat melihatnya IDs 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 bukanlah masalahnya. Jika grup keamanan dikembalikan, maka 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 grup keamanan yang IDs ditampilkan dalam output tidak cocok dengan grup keamanan IDs yang ditentukan saat kluster dibuat, maka jika Anda ingin Amazon EKS memperbarui cluster, Anda perlu mengubah grup keamanan yang digunakan oleh cluster. Amazon EKS tidak akan memperbarui klaster jika grup keamanan IDs yang ditentukan pada pembuatan klaster tidak ada.

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

Kesehatan cluster FAQs dan kode kesalahan dengan jalur resolusi

Amazon EKS mendeteksi masalah dengan kluster EKS Anda dan infrastruktur klaster dan menyimpannya di kesehatan klaster. Anda dapat mendeteksi, memecahkan masalah, dan mengatasi masalah klaster lebih cepat dengan bantuan informasi kesehatan klaster. Ini memungkinkan Anda untuk membuat lingkungan aplikasi yang lebih aman dan up-to-date. Selain itu, mungkin tidak mungkin bagi Anda untuk meningkatkan ke versi yang lebih baru Kubernetes atau Amazon EKS untuk menginstal pembaruan keamanan pada klaster 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 teratasi.

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

Untuk mengakses kesehatan klaster Anda di konsol Amazon EKS, cari bagian yang disebut Masalah Kesehatan di tab Ikhtisar halaman detail klaster Amazon EKS. Data ini juga akan tersedia dengan memanggil DescribeCluster tindakan di EKS API, misalnya dari dalam Antarmuka Baris AWS Perintah.

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