Pemecahan masalah 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 di Amazon EKS Connector, dan Pemecahan Masalah untuk ADOT menggunakan topik Pengaya 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 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 di. Persyaratan dan pertimbangan subnet

Simpul gagal untuk bergabung dengan klaster

Ada beberapa alasan umum yang mencegah simpul bergabung dengan klaster:

• Jika node adalah node yang dikelola, Amazon EKS menambahkan entri ke aws-auth ConfigMap saat Anda membuat grup node. Jika entri dihapus atau dimodifikasi, maka Anda perlu menambahkannya kembali. Untuk informasi lebih lanjut, masukkan eksctl create iamidentitymapping --help di terminal Anda. Anda dapat melihat aws-auth ConfigMap entri Anda saat ini dengan mengganti my-cluster dalam perintah berikut dengan nama cluster Anda dan kemudian menjalankan perintah yang dimodifikasi:. eksctl get iamidentitymapping --cluster my-cluster ARN peran yang Anda tentukan tidak dapat menyertakan jalur selain. / Misalnya, jika nama peran Andadevelopment/apps/my-role, Anda harus mengubahnya menjadi my-role saat menentukan ARN untuk peran tersebut. Pastikan Anda menentukan ARN peran IAM node (bukan ARN profil instance).

  Jika node dikelola sendiri, dan Anda belum membuat entri akses untuk ARN peran IAM node, jalankan perintah yang sama yang terdaftar untuk node terkelola. Jika Anda telah membuat entri akses untuk ARN untuk peran IAM node Anda, maka itu mungkin tidak dikonfigurasi dengan benar dalam entri akses. Pastikan bahwa ARN peran IAM node (bukan ARN profil instance) ditentukan sebagai ARN utama dalam entri atau entri akses Anda. aws-auth ConfigMap Untuk informasi selengkapnya tentang entri akses, lihatKelola entri akses.

• AWS CloudFormation Template ClusterNamedi node Anda tidak sama persis dengan nama cluster yang Anda inginkan untuk bergabung dengan node Anda. Memasukkan nilai yang salah ke bidang ini menyebabkan konfigurasi yang salah pada file /var/lib/kubelet/kubeconfig simpul, dan simpul tidak akan bergabung dengan klaster.

• Simpul tidak ditandai sebagai dimiliki oleh klaster. Simpul Anda harus memiliki tanda berikut yang diterapkan untuk mereka, di mana my-cluster diganti dengan nama klaster Anda.

  Kunci	Nilai
  kubernetes.io/cluster/my-cluster	owned

• Simpul mungkin tidak dapat mengakses klaster menggunakan alamat IP publik. Pastikan bahwa simpul yang di-deploy di subnet publik memiliki alamat IP publik. Jika tidak, Anda dapat mengaitkan alamat IP Elastis ke simpul setelah diluncurkan. Untuk informasi selengkapnya, lihat Mengaitkan alamat IP Elastis dengan instans berjalan atau antarmuka jaringan. Jika subnet publik tidak diatur secara otomatis untuk menetapkan alamat IP publik ke instans yang di-deploy untuk itu, maka kami merekomendasikan untuk mengaktifkan pengaturan tersebut. Untuk informasi selengkapnya, lihat Memodifikasi atribut IPv4 pengalamatan publik untuk subnet Anda. Jika simpul di-deploy ke subnet privat, maka subnet harus memiliki rute ke gateway NAT yang memiliki alamat IP publik yang ditugaskan untuk itu.

• AWS STS Titik akhir untuk tempat Wilayah AWS Anda menerapkan node tidak diaktifkan untuk akun Anda. Untuk mengaktifkan wilayah, lihat Mengaktifkan dan menonaktifkan AWS STS dalam file. Wilayah AWS

• Node tidak memiliki entri DNS pribadi, sehingga kubelet log berisi node "" not found kesalahan. Pastikan bahwa VPC tempat node dibuat memiliki nilai yang ditetapkan untuk domain-name dan domain-name-servers seperti Options dalam file. DHCP options set Nilai defaultnya adalah domain-name:<region>.compute.internal dan domain-name-servers:AmazonProvidedDNS. Untuk informasi selengkapnya, lihat Set opsi DHCP di Panduan Pengguna Amazon VPC.

• Jika node dalam grup node terkelola tidak terhubung ke cluster dalam waktu 15 menit, masalah kesehatan “NodeCreationKegagalan” akan dipancarkan dan status konsol akan disetel ke. Create failed Untuk Windows AMI yang memiliki waktu peluncuran lambat, masalah ini dapat diselesaikan menggunakan peluncuran cepat.

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 prinsipal IAM (peran atau pengguna) yang Anda gunakan jangan dipetakan ke Kubernetes nama pengguna yang memiliki izin yang cukup untuk objek Kubernetes di kluster Amazon EKS Anda.

• could not get token: AccessDenied: Access denied

• error: You must be logged in to the server (Unauthorized)

• error: the server doesn't have a resource type "svc"

Ini bisa disebabkan oleh salah satu alasan berikut:

• Cluster dibuat dengan kredensi untuk satu prinsipal IAM dan kubectl dikonfigurasi untuk menggunakan kredensi untuk prinsipal IAM yang berbeda. Untuk mengatasi hal ini, perbarui kube config file Anda untuk menggunakan kredensi yang membuat klaster. Untuk informasi selengkapnya, lihat Membuat atau memperbarui kubeconfig file untuk kluster Amazon EKS.

• Jika klaster Anda memenuhi persyaratan platform minimum di bagian prasyaratKelola entri akses, entri akses tidak ada dengan prinsipal IAM Anda. Jika ada, itu tidak memiliki nama Kubernetes grup yang diperlukan yang ditentukan untuknya, atau tidak memiliki kebijakan akses yang tepat yang terkait dengannya. Untuk informasi selengkapnya, lihat Kelola entri akses.

• Jika klaster Anda tidak memenuhi persyaratan platform minimum diKelola entri akses, entri dengan prinsipal IAM Anda tidak ada di aws-authConfigMap. Jika ada, itu tidak dipetakan ke nama Kubernetes grup yang terikat ke Kubernetes Role atau ClusterRole dengan izin yang diperlukan. Untuk informasi selengkapnya tentang objek otorisasi Kubernetes berbasis peran (RBAC), lihat Menggunakan otorisasi RBAC dalam dokumentasi. Kubernetes Anda dapat melihat aws-auth ConfigMap entri Anda saat ini dengan mengganti my-cluster dalam perintah berikut dengan nama cluster Anda dan kemudian menjalankan perintah yang dimodifikasi:. eksctl get iamidentitymapping --cluster my-cluster Jika entri untuk ARN kepala sekolah IAM Anda tidak ada diConfigMap, masukkan eksctl create iamidentitymapping --help terminal Anda untuk mempelajari cara membuatnya.

Jika Anda menginstal dan mengkonfigurasi AWS CLI, Anda dapat mengkonfigurasi kredenal IAM 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 peran IAM, jika Anda mengasumsikan peran IAM untuk mengakses Kubernetes objek di klaster Anda. Untuk informasi selengkapnya, lihat Membuat atau memperbarui kubeconfig file untuk kluster Amazon EKS.

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 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

Dockerberjalan dalam kisaran 172.17.0.0/16 CIDR di kluster Amazon EKS. Kami merekomendasikan agar sub-jaringan VPC klaster Anda tidak tumpang tindih dengan kisaran 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 Kendali akses titik akhir klaster Amazon EKS.

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 kesehatan Amazon EC2. Daftar berikut menjelaskan kode kesalahan.

AccessDenied

Amazon EKS atau satu atau beberapa node terkelola Anda gagal mengautentikasi atau mengotorisasi dengan server API Kubernetes cluster Anda. Untuk informasi lebih lanjut tentang menyelesaikan penyebab umum, lihatMemperbaiki penyebab umum AccessDenied kesalahan untuk grup node terkelola. WindowsAMI pribadi juga dapat menyebabkan kode kesalahan ini di samping pesan Not authorized for images kesalahan. Untuk informasi selengkapnya, lihat Not authorized for images.

AmiIdNotFound

Kami tidak dapat menemukan ID AMI yang terkait dengan template peluncuran Anda. Pastikan bahwa AMI ada dan dibagikan dengan akun Anda.

AutoScalingGroupNotDitemukan

Kami tidak dapat menemukan grup Auto Scaling yang terkait dengan grup node terkelola. Anda dapat membuat ulang grup Auto Scaling dengan pengaturan yang sama untuk memulihkan.

ClusterUnreachable

Amazon EKS atau satu atau beberapa node terkelola tidak dapat berkomunikasi dengan server API Kubernetes cluster Anda. Hal ini dapat terjadi jika ada gangguan jaringan atau jika waktu keluar permintaan pemrosesan server API.

Ec2 SecurityGroup NotFound

Kami tidak dapat menemukan grup keamanan cluster untuk cluster. Anda harus membuat ulang klaster Anda.

Ec2 SecurityGroup DeletionFailure

Kami tidak dapat menghapus grup keamanan akses jarak jauh untuk grup node terkelola Anda. Menghapus dependensi dari grup keamanan.

Ec2 LaunchTemplate NotFound

Kami tidak dapat menemukan template peluncuran Amazon EC2 untuk grup node terkelola Anda. Anda harus membuat ulang grup node Anda untuk memulihkan.

Ec2 LaunchTemplate VersionMismatch

Versi template peluncuran Amazon EC2 untuk grup node terkelola Anda tidak cocok dengan versi yang dibuat Amazon EKS. Anda mungkin dapat kembali ke versi yang dibuat Amazon EKS untuk memulihkan.

IamInstanceProfileNotDitemukan

Kami tidak dapat menemukan profil instans IAM untuk grup node terkelola Anda. Anda mungkin dapat membuat ulang profil instans dengan pengaturan yang sama untuk memulihkan.

IamNodeRoleNotDitemukan

Kami tidak dapat menemukan peran IAM untuk grup node terkelola Anda. Anda mungkin dapat membuat ulang IAM role dengan pengaturan yang sama untuk memulihkan.

AsgInstanceLaunchFailures

Grup Auto Scaling Anda mengalami kegagalan saat mencoba meluncurkan instance.

NodeCreationKegagalan

Instans yang diluncurkan tidak dapat mendaftar dengan kluster Amazon EKS Anda. Penyebab umum kegagalan ini adalah tidak mencukupi IAM role simpul izin atau kurangnya akses internet keluar untuk simpul. Node Anda harus memenuhi salah satu dari persyaratan berikut:

• Mampu mengakses internet menggunakan alamat IP publik. Kelompok keamanan yang terkait dengan subnet tempat node berada harus mengizinkan komunikasi. Untuk informasi selengkapnya, lihat Persyaratan dan pertimbangan subnet dan Persyaratan dan pertimbangan grup keamanan Amazon EKS.

• Node dan VPC Anda harus memenuhi persyaratan di. Persyaratan klaster pribadi

InstanceLimitMelebihi

AWS Akun Anda tidak dapat meluncurkan instance lagi dari jenis instans yang ditentukan. Anda mungkin dapat meminta peningkatan batas instans Amazon EC2 untuk memulihkan.

InsufficientFreeAlamat

Satu atau beberapa subnet yang terkait dengan grup node terkelola Anda tidak memiliki cukup alamat IP yang tersedia untuk node baru.

InternalFailure

Kesalahan ini biasanya disebabkan oleh masalah sisi server Amazon EKS.

Memperbaiki penyebab umum AccessDenied kesalahan untuk grup node terkelola

Penyebab paling umum kesalahan AccessDenied saat melakukan pengoperasian pada grup simpul yang terkelola adalah hilangnya eks:node-manager ClusterRole atau ClusterRoleBinding. Amazon EKS mengatur sumber daya ini di klaster Anda sebagai bagian dari orientasi dengan grup simpul yang terkelola, dan ini diperlukan untuk mengelola grup simpul.

ClusterRole mungkin berubah seiring berjalannya waktu, tetapi seharusnya terlihat serupa dengan contoh berikut:

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               
            

ClusterRoleBinding mungkin berubah seiring berjalannya waktu, tetapi seharusnya terlihat serupa dengan contoh berikut:

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

Verifikasi bahwa eks:node-manager ClusterRole ada.

kubectl describe clusterrole eks:node-manager

Jika ada, membandingkan output dengan contoh ClusterRole sebelumnya.

Verifikasi bahwa eks:node-manager ClusterRoleBinding ada.

kubectl describe clusterrolebinding eks:node-manager

Jika ada, bandingkan output dengan contoh ClusterRoleBinding sebelumnya.

Jika Anda telah mengidentifikasi ClusterRole atau ClusterRoleBinding yang hilang atau rusak sebagai penyebab AcessDenied ketika meminta pengoperasian grup simpul yang terkelola, Anda dapat mengembalikannya. Simpan isi berikut ke file bernama eks-node-manager-role.yaml.

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

Terapkan file.

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

Coba lagi mengoperasikan grup simpul untuk melihat apakah itu menyelesaikan masalah Anda.

Not authorized for images

Salah satu penyebab potensial pesan Not authorized for images kesalahan adalah menggunakan Amazon EKS Windows AMI pribadi untuk meluncurkan grup node Windows terkelola. Setelah merilis Windows AMI baru, AWS membuat AMI yang lebih tua dari 4 bulan pribadi, yang membuatnya tidak lagi dapat diakses. Jika grup node terkelola Anda menggunakan Windows AMI pribadi, pertimbangkan untuk memperbarui grup node Windows terkelola 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 Support. Untuk informasi selengkapnya, lihat Patch, pembaruan keamanan, dan ID AMI di Panduan Pengguna Amazon EC2.

Node dalam NotReady keadaan

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

Untuk Windows AMI 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 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 Daemons dalam Kubernetes dokumentasi dan parameter konfigurasi skrip Bootstrap dalam panduan pengguna ini.

Alat pengumpulan log CNI

Ini 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

catatan

Jika skrip tidak ada di lokasi tersebut, maka kontainer CNI gagal untuk menjalankan. Anda dapat mengunduh dan menjalankan skrip secara manual dengan perintah berikut:

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:

1. Anda juga tidak memiliki aws-auth ConfigMap di cluster Anda atau tidak menyertakan entri untuk peran IAM yang Anda konfigurasikan dengan node Anda.

   ConfigMapEntri ini diperlukan jika node Anda memenuhi salah satu kriteria berikut:

   • Node terkelola dalam cluster dengan versi platform Kubernetes atau apa pun.

   • Node yang dikelola sendiri di cluster yang lebih awal dari salah satu versi platform yang tercantum di bagian prasyarat topik. Kelola entri akses

   Untuk mengatasi masalah ini, lihat entri yang ada di Anda ConfigMap dengan mengganti my-cluster dalam perintah berikut dengan nama cluster Anda, lalu jalankan perintah yang dimodifikasi:. eksctl get iamidentitymapping --cluster my-cluster Jika Anda menerima pesan kesalahan dari perintah, itu mungkin karena klaster Anda tidak memiliki file aws-authConfigMap. Perintah berikut menambahkan entri keConfigMap. Jika ConfigMap tidak ada, perintah juga membuatnya. Ganti 111122223333 dengan Akun AWS ID untuk peran IAM dan NodeRoleMyAmazoneks dengan nama peran node Anda.

   eksctl create iamidentitymapping --cluster my-cluster \
       --arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --group system:bootstrappers,system:nodes \
       --username system:node:{{EC2PrivateDNSName}}
   

   ARN peran yang Anda tentukan tidak dapat menyertakan jalur selain. / Misalnya, jika nama peran Andadevelopment/apps/my-role, Anda harus mengubahnya menjadi my-role saat menentukan ARN peran tersebut. Pastikan Anda menentukan ARN peran IAM node (bukan ARN profil instance).

2. Node yang dikelola sendiri berada dalam klaster dengan versi platform pada versi minimum yang tercantum dalam prasyarat dalam Kelola entri akses topik, tetapi entri tidak tercantum dalam aws-auth ConfigMap (lihat item sebelumnya) untuk peran IAM node atau entri akses tidak ada untuk peran tersebut. Untuk mengatasi masalah ini, lihat entri akses yang ada dengan mengganti my-cluster dalam perintah berikut dengan nama cluster Anda, lalu jalankan perintah yang dimodifikasi:. aws eks list-access-entries --cluster-name my-cluster Perintah berikut menambahkan entri akses untuk peran IAM node. Ganti 111122223333 dengan Akun AWS ID untuk peran IAM dan NodeRoleMyAmazoneks dengan nama peran node Anda. Jika Anda memiliki node Windows, ganti EC2_Linux dengan. EC2_Windows Pastikan Anda menentukan ARN peran IAM node (bukan ARN profil instance).

   aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/myAmazonEKSNodeRole --type EC2_Linux
   

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 klaster 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 Anda, seperti yang ditunjukkan dalam contoh Pod spesifikasi 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"

Sertifikat penerimaan VPC webhook kedaluwarsa

Jika sertifikat yang digunakan untuk menandatangani webhook penerimaan VPC kedaluwarsa, status penerapan baru Windows Pod tetap berlaku. ContainerCreating

Untuk mengatasi masalah jika Anda memiliki Windows dukungan lama di bidang data, lihatMemperbarui sertifikat webhook izin masuk VPC. Jika versi klaster dan platform Anda lebih lambat dari versi yang tercantum dalam prasyarat Windows dukungan, maka sebaiknya Anda menghapus Windows dukungan lama di bidang data Anda dan mengaktifkannya untuk bidang kontrol Anda. Setelah Anda melakukannya, Anda tidak perlu mengelola sertifikat webhook. Untuk informasi selengkapnya, lihat Mengaktifkan Windows dukungan untuk klaster Amazon EKS Anda.

Grup node harus cocok dengan Kubernetes versi sebelum memutakhirkan bidang kontrol

Sebelum Anda memutakhirkan bidang kontrol ke Kubernetes versi baru, 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 API untuk memutakhirkan node terkelola. Untuk informasi tentang memutakhirkan Kubernetes versi grup node terkelola, lihatMemperbarui grup simpul terkelola. Untuk memutakhirkan versi node Fargate, hapus pod yang diwakili oleh node dan terapkan kembali pod setelah Anda memutakhirkan bidang kontrol Anda. Untuk informasi selengkapnya, lihat Memperbarui Kubernetes versi cluster Amazon EKS.

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 pengguna Amazon EC2 yang mengatakan. Too 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 dioptimalkanLinux/BottlerocketAMI.

HTTP 401 respons kesalahan tidak sah pada permintaan server Kubernetes API

Anda melihat kesalahan ini jika token akun layanan telah kedaluwarsa di klaster. Pod

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

• Versi Go 0.15.7 dan yang lebih baru

• Versi 12.0.0 Python dan yang lebih baru

• Versi Java 9.0.0 dan yang lebih baru

• JavaScript versi 0.10.3 dan yang lebih baru

• Cabang Ruby master

• Versi Haskell 0.3.0.0

• C#versi 7.0.5 dan yang lebih baru

Anda dapat mengidentifikasi semua yang ada Pods di cluster Anda yang menggunakan token basi. Untuk informasi selengkapnya, lihat akun Kubernetes 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 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 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.

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

Masalah

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

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

Alasan lain mengapa Amazon EKS tidak memperbarui versi platform cluster Anda

• Anda tidak memiliki setidaknya enam (meskipun kami merekomendasikan 16) alamat IP yang tersedia di setiap subnet yang Anda tentukan saat Anda membuat cluster Anda. Jika Anda tidak memiliki cukup alamat IP yang tersedia di subnet, Anda perlu membebaskan alamat IP di subnet atau Anda perlu mengubah subnet yang digunakan oleh cluster untuk menggunakan subnet dengan alamat IP yang cukup tersedia.

• Anda mengaktifkan enkripsi rahasia saat membuat klaster dan AWS KMS kunci yang Anda tentukan telah dihapus. Jika Anda ingin Amazon EKS memperbarui cluster, Anda perlu membuat cluster baru

FAQ kesehatan cluster 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 memutakhirkan 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 AWS Command Line Interface.

Mengapa saya harus menggunakan fitur ini?

Anda akan mendapatkan peningkatan visibilitas ke dalam kesehatan kluster Amazon EKS Anda, dengan cepat mendiagnosis dan memperbaiki masalah apa pun, tanpa perlu menghabiskan waktu debugging atau membuka AWS kasus dukungan. Misalnya: Anda secara tidak sengaja menghapus subnet untuk kluster Amazon EKS, Amazon EKS tidak akan dapat membuat antarmuka dan Kubernetes AWS CLI perintah jaringan lintas akun seperti kubectl exec atau log. kubectl Ini akan gagal dengan kesalahan: Error from server: error dialing backend: remote error: tls: internal error. Sekarang Anda akan melihat masalah kesehatan Amazon EKS yang mengatakan:subnet-da60e280 was deleted: could not create network interface.

Bagaimana fitur ini berhubungan atau bekerja dengan AWS layanan lain?

Peran IAM dan subnet VPC Amazon adalah dua contoh infrastruktur prasyarat yang mendeteksi masalah kesehatan klaster. Fitur ini akan mengembalikan informasi terperinci jika sumber daya tersebut tidak dikonfigurasi dengan benar.

Apakah cluster dengan masalah kesehatan menimbulkan biaya?

Ya, setiap cluster Amazon EKS ditagih dengan harga Amazon EKS standar. Fitur kesehatan cluster tersedia tanpa biaya tambahan.

Apakah fitur ini berfungsi dengan kluster Amazon AWS Outposts EKS?

Ya, masalah cluster terdeteksi untuk kluster EKS di AWS Cloud termasuk cluster yang diperluas AWS Outposts dan cluster lokal aktif. AWS Outposts Kesehatan cluster tidak mendeteksi masalah dengan Amazon EKS Anywhere atau Amazon EKS Distro (EKS-D).

Bisakah saya mendapatkan pemberitahuan ketika masalah baru terdeteksi?

Tidak, Anda perlu memeriksa Amazon EKS Console atau memanggil EKS DescribeCluster API.

Apakah konsol memberi saya peringatan untuk masalah kesehatan?

Ya, setiap cluster dengan masalah kesehatan akan menyertakan spanduk di bagian atas konsol.

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

Kode	Pesan	ResourceIds	Cluster Dapat Dipulihkan?
SUBNET_NOT_FOUND	Kami tidak dapat menemukan satu atau lebih subnet yang saat ini terkait dengan cluster Anda. Hubungi Amazon EKS update-cluster-config API untuk memperbarui subnet.	Id Subnet	Ya
SECURITY_GROUP_NOT_FOUND	Kami tidak dapat menemukan satu atau lebih grup keamanan yang saat ini terkait dengan klaster Anda. Hubungi Amazon EKS update-cluster-config API untuk memperbarui grup keamanan	Id grup keamanan	Ya
IP_NOT_AVAILABLE	Satu atau beberapa subnet yang terkait dengan cluster Anda tidak memiliki cukup alamat IP yang tersedia untuk Amazon EKS untuk melakukan operasi manajemen klaster. Kosongkan alamat di subnet, atau kaitkan subnet yang berbeda ke klaster Anda menggunakan Amazon EKS update-cluster-config API.	Id Subnet	Ya
VPC_NOT_FOUND	Kami tidak dapat menemukan VPC yang terkait dengan cluster Anda. Anda harus menghapus dan membuat ulang cluster Anda.	VPC id	Tidak
ASSUME_ROLE_ACCESS_DENIED	Cluster Anda tidak menggunakan Amazon EKS service-linked-role. Kami tidak dapat mengambil peran yang terkait dengan klaster Anda untuk melakukan operasi manajemen Amazon EKS yang diperlukan. Periksa peran yang ada dan memiliki kebijakan kepercayaan yang diperlukan.	Peran IAM cluster	Ya
PERMISSION_ACCESS_DENIED	Cluster Anda tidak menggunakan Amazon EKS service-linked-role. Peran yang terkait dengan klaster Anda tidak memberikan izin yang memadai bagi Amazon EKS untuk melakukan operasi manajemen yang diperlukan. Periksa kebijakan yang dilampirkan pada peran klaster dan jika ada kebijakan penolakan terpisah yang diterapkan.	Peran IAM cluster	Ya
ASSUME_ROLE_ACCESS_DENIED_USING_SLR	Kami tidak dapat mengasumsikan manajemen cluster Amazon EKS service-linked-role. Periksa peran yang ada dan memiliki kebijakan kepercayaan yang diperlukan.	Amazon EKS service-linked-role	Ya
PERMISSION_ACCESS_DENIED_USING_SLR	Manajemen klaster Amazon EKS service-linked-role tidak memberikan izin yang cukup bagi Amazon EKS untuk melakukan operasi manajemen yang diperlukan. Periksa kebijakan yang dilampirkan pada peran klaster dan jika ada kebijakan penolakan terpisah yang diterapkan.	Amazon EKS service-linked-role	Ya
OPT_IN_REQUIRED	Akun Anda tidak memiliki langganan layanan Amazon EC2. Perbarui langganan akun Anda di halaman pengaturan akun Anda.	N/A	Ya
STS_REGIONAL_ENDPOINT_DISABLED	Titik akhir STS regional dinonaktifkan. Aktifkan titik akhir Amazon EKS untuk melakukan operasi manajemen klaster yang diperlukan.	N/A	Ya
KMS_KEY_DISABLED	AWS KMS Kunci yang terkait dengan cluster Anda dinonaktifkan. Aktifkan kembali kunci untuk memulihkan cluster Anda.	Sebuah KMS Key Arn	Ya
KMS_KEY_NOT_FOUND	Kami tidak dapat menemukan AWS KMS kunci yang terkait dengan cluster Anda. Anda harus menghapus dan membuat ulang cluster.	Sebuah KMS Key ARN	Tidak
KMS_GRANT_REVOKED	Hibah untuk AWS KMS Kunci yang terkait dengan cluster Anda dicabut. Anda harus menghapus dan membuat ulang cluster.	Sebuah KMS Key Arn	Tidak