Amazon EKS 故障診斷

此章節涵蓋一些您在使用 Amazon EKS 時可能遇到的常見錯誤，並提供解決方法。如果您需要針對特定 Amazon EKS 區域進行疑難排解，請參閱個別 疑難排解 IAM、對 Amazon EKS 連接器中的問題進行疑難排解 和針對使用 EKS 附加元件的 ADOT 進行疑難排解主題。

如需其他疑難排解資訊，請參閱 AWS re:Post 上有關 Amazon Elastic Kubernetes Service 的知識中心內容。

容量不足

如果您在嘗試建立 Amazon EKS 叢集時收到下列錯誤，則代表其中一個您指定的可用區域沒有足夠的容量來支援叢集。

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

重新嘗試使用叢集 VPC 中的子網路來建立您的叢集，叢集 VPC 託管於此錯誤訊息傳回之可用區域之中。

有些可用區域是叢集無法駐留的。將子網路所在的可用區域與 子網需求和注意事項 中的可用區域清單進行比較。

節點無法加入叢集

有幾個常見的原因會阻擋節點加入叢集：

若要識別和疑難排解導致 Worker 節點無法加入叢集的常見原因，您可以使用 AWSSupport-TroubleshootEKSWorkerNode Runbook。如需詳細資訊，請參閱 AWS Systems Manager Automation Runbook 參考 中的 AWSSupport-TroubleshootEKSWorkerNode。

未經授權或存取遭拒 (kubectl)

如果您在執行 kubectl 命令時，收到以下其中一個錯誤，則表示未為 Amazon EKS 正確設定 kubectl，或者表示您使用的 IAM 主體 (角色或使用者) 憑證並未映射到對 Amazon EKS 叢集上的 Kubernetes 物件具有足夠許可的 Kubernetes 使用者。

這種情況可能由下列原因之一造成：

如果您安裝並設定 AWS CLI，則可以設定您使用的 IAM 登入資料。如需詳細資訊，請參閱《AWS Command Line Interface 使用者指南》中的設定 AWS CLI。如果您透過擔任 IAM 角色來存取叢集上的 Kubernetes 物件，則也可以將 kubectl 設定為使用 IAM 角色。如需詳細資訊，請參閱 建立或更新 Amazon EKS 叢集的 kubeconfig 檔案。

hostname doesn't match

您的系統 Python 版本必須為 2.7.9 或更新版本。否則，您會在 AWS CLI 撥打 Amazon EKS 時收到hostname doesn't match錯誤訊息。如需詳細資訊，請參閱 Python Requests Frequently Asked Questions 中的 What are "hostname doesn't match" errors 部分。

getsockopt: no route to host

Docker 會在 Amazon EKS 叢集的 172.17.0.0/16 CIDR 範圍中執行。我們建議不要將叢集的 VPC 子網路與這個範圍重疊。否則，您會收到以下錯誤：

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

如果您Instances failed to join the Kubernetes cluster在中收到錯誤 AWS Management Console，請確定已啟用叢集的私人端點存取，或已正確設定 CIDR 區塊以進行公用端點存取。如需詳細資訊，請參閱 Amazon EKS 叢集端點存取控制。

受管節點群組錯誤代碼

如果受管節點群組遇到硬體運作狀態問題，Amazon EKS 會傳回錯誤代碼，以協助您診斷問題。這些運作狀態檢查不會偵測軟體問題，因為檢查是以 Amazon EC2 運作狀態檢查為基礎。以下清單描述了這些錯誤代碼。

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

導致 Not authorized for images 錯誤訊息的一個潛在原因是使用私有 Amazon EKS Windows AMI 啟動 Windows 受管節點群組。發布新的 Windows AMI 後， AWS 將超過 4 個月的 AMI 設為私有，這使得它們無法再訪問。如果您的受管節點群組使用私有 Windows AMI，請考慮更新Windows受管節點群組。雖然我們無法保證我們可以提供對已設為私密 AMI 的存取權，但您可以向 Sup AWS port 人員提交票證來要求存取權限。如需詳細資訊，請參閱 Amazon EC2 使用者指南中的修補程式、安全性更新和 AMI ID。

節點處於NotReady狀態

如果您的節點進入NotReady狀態，這可能表示節點運作狀況不佳且無法排程新Pods節點。這可能是由於各種原因而發生的，例如節點缺乏足夠的資源來容納 CPU、記憶體或可用磁碟空間。

對於 Amazon EKS 最佳化的 Windows AMI，組態中預設不會針對預設指定的運算資源保留。kubelet若要協助避免資源問題，您可以透過提供kube-reserved和/或的組態值，為系統程序保留運算資源system-reserved。kubelet您可以使用啟動程序指-KubeletExtraArgs令碼中的命令列參數來執行此作業 如需詳細資訊，請參閱Kubernetes文件中的為系統精靈保留計算資源，以及本使用指南中的 Bootstrap 指令碼組態參數。

CNI 日誌收集工具

Amazon VPC CNI plugin for Kubernetes 有自己的故障診斷指令碼，在 /opt/cni/bin/aws-cni-support.sh 節點上可用。您可以使用指令碼來收集支援案例和一般故障診斷的診斷日誌。

在您的節點使用以下命令即可執行指令碼：

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

該指令碼收集的診斷資訊如下。您已部署的 CNI 版本可能比指令碼版本更早。

      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

診斷資訊收集後將存放於：

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

容器執行階段網路尚未就緒

您可能會收到類似下列的 Container runtime network not ready 錯誤和授權錯誤：

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

這種情況可能由下列原因之一造成：

TLS 交握逾時

當節點無法建立與公有 API 伺服器端點的連接時，您可能會收到類似下列的錯誤。

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

kubelet 程序將持續重新產生並測試 API 伺服器端點。在控制平面中執行叢集滾動更新 (例如組態變更或版本更新) 的任何程序期間，也可能會暫時發生錯誤。

若要解決此問題，請檢查路由表和安全群組，以確保來自節點的流量可以到達公有端點。

InvalidClientTokenId

如果您針對中國叢集Pod或DaemonSet部署到中國叢集的服務帳戶使用 IAM 角色 AWS 區域，且尚未在規格中設定AWS_DEFAULT_REGION環境變數，則Pod或DaemonSet可能會收到下列錯誤：

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

若要解決此問題，您需要將 AWS_DEFAULT_REGION 環境變數新增至您的 Pod 或 DaemonSet 規格，如下列範例 Pod 規格所示。

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"

VPC 許可 Webhook 憑證過期

如果用來簽署 VPC 許可 Webhook 的憑證過期，則新 Windows Pod 部署的狀態會保持在 ContainerCreating。

若要解決此問題，如果資料平面支援舊版 Windows，請參閱 續約 VPC 許可 Webhook 憑證。如果叢集和平台版本晚於 Windows 支援先決條件列出的版本，則建議您移除資料平面上的舊版 Windows 支援，並為您的控制平面啟用它。如此，您不再需要管理 Webhook 憑證。如需詳細資訊，請參閱 為您的 Amazon EKS 叢集啟用 Windows 支援。

升級控制平面之前，節點群組必須符合 Kubernetes 版本

在將控制平面升級為新的 Kubernetes 版本之前，您叢集中的次要版本的受管和 Fargate 節點必須要與控制平面目前版本的版本相同。在將所有 Amazon EKS 受管節點升級為目前的叢集版本前，Amazon EKS update-cluster-version API 都會拒絕請求。Amazon EKS 提供 API 來升級受管節點。如需升級受管節點群組 Kubernetes 版本的資訊，請參閱 更新受管節點群組。若要升級 Fargate 節點的版本，請刪除節點所代表的 pod，並在升級控制平面後重新部署 pod。如需詳細資訊，請參閱 更新 Amazon EKS 叢集 Kubernetes 版本。

啟動許多節點時，會出現 Too Many Requests 錯誤

如果同時啟動許多節點，您可能會 Amazon EC2 使用者資料執行日誌看見錯誤訊息，其顯示 Too Many Requests。這可能是因為控制平面因 describeCluster 呼叫超載。超載會導致調節、節點無法執行引導指令碼，以及節點無法完全加入叢集。

確認將 --apiserver-endpoint、--b64-cluster-ca 和 --dns-cluster-ip 引數傳遞至節點的引導指令碼。包含這些引數時，不需要引導指令碼進行 describeCluster 呼叫，這有助於防止控制平面超載。如需詳細資訊，請參閱 提供使用者資料以將引數傳遞給 bootstrap.sh 檔案，其中包含經 Amazon EKS 優化的 Linux/Bottlerocket AMI。

針對 Kubernetes API 伺服器請求回應的 HTTP 401 未經授權的錯誤

如果叢集上的 Pod 服務帳戶字符已過期，您會看到這些錯誤。

您的 Amazon EKS 叢集的 Kubernetes API 伺服器拒絕超過 90 天的字符的請求。在 Kubernetes 舊版本中，字符沒有過期。這意味著倚賴這些字符的客戶端必須在一小時內進行重新整理。為了防止 Kubernetes API 服務器因無效字符而拒絕您的請求，您的工作負載使用的 Kubernetes 用戶端開發套件版本必須與以下版本相同或為更新版本：

您可以識別叢集中所有使用過時字符的現有 Pods。如需詳細資訊，請參閱 Kubernetes 服務帳戶。

Amazon EKS 平台版本比目前平台版本落後兩個版本以上

當 Amazon EKS 無法自動更新您的叢集時，平台版本可能會發生這種情況。儘管造成這種情況的原因很多，然而一些常見的原因如下。如果這些問題中有任何一個適用於您的叢集，其可能仍然可以運作，但 Amazon EKS 不會更新其平台版本。

問題

該叢集 IAM 角色已刪除，此角色是在建立叢集時指定。您可以使用以下命令，查看指定了哪個角色。使用您叢集的名稱取代 my-cluster。

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

範例輸出如下。

eksClusterRole

解決方案

建立具有相同名稱的新叢集 IAM 角色。

問題

已刪除叢集建立期間指定的子網路 – 即叢集建立期間指定要與叢集搭配使用的子網路。您可以使用以下命令，查看指定了哪些子網路。使用您叢集的名稱取代 my-cluster。

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

範例輸出如下。

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

解決方案

確認您的帳戶中是否存在子網路 ID。

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"

範例輸出如下。

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

如果輸出中傳回的子網路 ID 與建立叢集時指定的子網路 ID 不符，假如您希望 Amazon EKS 更新叢集，則需要變更叢集使用的子網路。這是因為如果您在建立叢集時指定了兩個以上的子網路，Amazon EKS 會隨機選取您指定在其中建立新彈性網路介面的子網路。這些網路介面可讓控制平面與節點進行通訊。如果叢集選取的子網路不存在，Amazon EKS 將不會更新叢集。您無法控制 Amazon EKS 會從您於建立叢集時指定的子網路中選擇哪些在其中建立新網路介面。

當您啟動叢集的 Kubernetes 版本更新，該更新可能會因相同的原因而失敗。

問題

叢集建立期間指定的安全群組已刪除 – 如果您在叢集建立期間指定了安全群組，您可以使用下列命令查看其 ID。使用您叢集的名稱取代 my-cluster。

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

範例輸出如下。

[
    "sg-EXAMPLE1"
]

如果傳回 []，若在建立叢集時未指定安全群組，而缺少安全群組並不是問題所在。如果傳回安全群組，則請確認安全群組位於您的帳戶中。

解決方案

請確認這些安全性群組是否位於您的帳戶中。

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"

範例輸出如下。

[
"sg-EXAMPLE2"
]

如果輸出中傳回的安全群組 ID 與建立叢集時指定的安全群組 ID 不符，若您希望 Amazon EKS 更新該叢集，則需要變更叢集使用的安全群組。如果在建立叢集時指定的安全群組 ID 不存在，Amazon EKS 將不會更新叢集。

當您啟動叢集的 Kubernetes 版本更新，該更新可能會因相同的原因而失敗。

含解析路徑的叢集健康狀態常見問題與錯誤

Amazon EKS 會偵測 Amazon EKS 叢集以及叢集基礎設施的問題，並將問題存放在叢集運作狀態中。藉助叢集運作狀態資訊，您可以更快速地偵測、診斷並解決叢集問題，這可讓您建立更安全且更安全的應用程式環境 up-to-date。此外，由於必要的基礎設施或叢集組態出現問題，您可能無法升級至較新版本的 Kubernetes，也可能無法讓 Amazon EKS 在降級的叢集上安裝安全更新。Amazon EKS 可能需要 3 小時才能偵測到問題或偵測某個問題是否已解決。

維護 Amazon EKS 叢集的運作狀態是 Amazon EKS 及其使用者共同的責任。使用者負責 IAM 角色和 Amazon VPC 子網路的必備基礎設施，以及其他必須事先提供的必要基礎設施。Amazon EKS 偵測此基礎設施和叢集的組態變更。

若要在 Amazon EKS 主控台中查看叢集的運作狀態，請在 Amazon EKS 叢集詳細資訊頁面的概觀索引標籤中，找到名為運作狀態問題的區段。相關資料也可以透過呼叫 EKS API 中的 DescribeCluster 動作來取得，例如從 AWS Command Line Interface中進行呼叫。

前兩欄是 API 回應值所需的內容。「Health」 ClusterIssue 對象的第三個字段是resourceIds，其返回取決于問題類型。