Memecahkan masalah dengan EKS cluster dan node Amazon

Bab ini mencakup beberapa kesalahan umum yang mungkin Anda lihat saat menggunakan Amazon EKS dan cara mengatasinya. Jika Anda perlu memecahkan masalah EKS area Amazon tertentu, lihat bagian terpisah Pemecahan masalah IAMMemecahkan masalah Konektor Amazon EKS, dan Pemecahan Masalah untuk ADOT menggunakan topik Add-On. EKS

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

Kapasitas tidak mencukupi

Jika Anda menerima kesalahan berikut saat mencoba membuat EKS klaster Amazon, 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

Coba lagi membuat klaster Anda dengan subnet di klaster Anda VPC yang di-host di Availability Zones yang ditampilkan oleh pesan galat ini.

Ada Availability Zone dimana cluster tidak dapat berada. Bandingkan Availability Zones tempat subnet Anda berada dengan daftar Availability Zone di. 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 Otomatisasi 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 IAM prinsipal (peran atau pengguna) yang Anda gunakan jangan dipetakan ke Kubernetes nama pengguna yang memiliki izin yang cukup untuk Kubernetes objek di EKS cluster Amazon Anda.

Ini bisa disebabkan oleh salah satu alasan berikut:

Jika Anda menginstal dan mengonfigurasi AWS CLI, Anda dapat mengonfigurasi IAM kredensyal yang Anda gunakan. Untuk informasi lebih lanjut, lihat Mengonfigurasi AWS CLI di Panduan Pengguna AWS Command Line Interface . Anda juga dapat mengonfigurasi kubectl untuk menggunakan IAM peran, jika Anda mengambil IAM peran untuk mengakses Kubernetes objek di cluster Anda. Untuk informasi selengkapnya, lihat Hubungkan kubectl ke sebuah EKS cluster 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 AWS CLI panggilan ke AmazonEKS. 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 172.17.0.0/16 CIDR kisaran di EKS cluster Amazon. Kami menyarankan agar VPC subnet klaster 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 CIDR blok dengan benar untuk akses titik akhir publik. Untuk informasi selengkapnya, lihat Kontrol akses jaringan ke titik akhir API server 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 pribadi EKS Windows AMIuntuk meluncurkan 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 Windows grup simpul terkelola. 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 Tambalan, pembaruan keamanan, dan AMI IDs 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 untukCPU, 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 memesan sumber daya komputasi untuk proses sistem kubelet dengan memberikan nilai konfigurasi untuk kube-reserveddan/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.

CNIalat pengumpulan log

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. CNIVersi yang telah Anda gunakan bisa 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:

TLSbatas waktu jabat tangan

Ketika sebuah node tidak dapat membuat koneksi ke titik akhir API server 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\""

kubeletProses ini akan terus respawn dan menguji endpoint 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 IAM peran untuk akun layanan untuk Pod atau DaemonSet diterapkan ke cluster di China Wilayah AWS, 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, 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 EKS dikelola Amazon 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 yang EKS dioptimalkanLinux/BottlerocketAMI.

HTTP401 respons kesalahan tidak sah pada Kubernetes APIpermintaan server

Anda melihat kesalahan ini jika PodToken akun layanan telah kedaluwarsa pada sebuah cluster.

EKSCluster Amazon Anda Kubernetes APIserver 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 APIserver dari menolak permintaan Anda karena token tidak valid, Kubernetes SDKversi klien 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, silakan lihat Kubernetes akun layanan.

Versi EKS platform Amazon 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 AmazonEKS.

Masalah

IAMPeran cluster telah dihapus — Peran ini ditentukan ketika cluster dibuat. Anda dapat melihat peran mana yang ditentukan dengan perintah berikut. Ganti my-cluster dengan nama cluster 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 IAMperan 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 cluster 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 EKS ingin Amazon 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 klaster yang EKS dipilih Amazon 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 cluster 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 EKS ingin Amazon memperbarui klaster, 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 EKS klaster dan infrastruktur klaster Anda 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 bagi 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 EKS cluster Amazon adalah tanggung jawab bersama antara Amazon EKS dan penggunanya. Anda bertanggung jawab atas infrastruktur prasyarat peran IAM dan VPC subnet Amazon, 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 EKS konsol Amazon, cari bagian yang disebut Masalah Kesehatan di tab Ikhtisar halaman detail EKS klaster Amazon. Data ini juga akan tersedia dengan memanggil DescribeCluster tindakan di EKSAPI, misalnya dari dalam AWS Command Line Interface.

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