為什麼我無法在 Amazon EKS 中執行 kubectl 命令?

上次更新日期:2021 年 11 月 24 日

我無法在 Amazon Elastic Kubernetes Service (Amazon EKS) 中成功執行 kubectl 命令,如 kubectl exec、kubectl logs、kubectl attach 或 kubectl port-forward。

解決方案

您無法在 Amazon EKS 叢集中成功執行命令 (如 kubectl execkubectl logskubectl attachkubectl port-forward) 的最常見原因是 API 伺服器未與在工作節點上執行的 kubelet 正常通訊。

若要對此錯誤進行疑難排解,請驗證以下各項:

  • Pod 在次要無類別網域間路由 (CIDR) 範圍內執行。
  • 用於控制平面和節點的安全群組使用傳入和傳出規則的最佳實務。
  • aws-auth ConfigMap 具有正確的 AWS Identity and Access Management (IAM) 角色,其中包含與您的節點關聯的 Kubernetes 使用者名稱。
  • 滿足提交新憑證的要求。

Pod 在次要無類別網域間路由 (CIDR) 範圍內執行

在建立叢集後,Amazon EKS 無法立即與新增至 virtual private cloud (VPC) 的其他 CIDR 區塊的子網路中啟動的節點通訊。將 CIDR 區塊新增至現有叢集導致的更新範圍可能需要五小時才能被 Amazon EKS 辨識。如需詳細資訊,請參閱叢集 VPC 考量

如果 Pod 在次要 CIDR 範圍內執行,則請執行以下操作:

  • 等待長達五小時,這些命令才能開始工作。
  • 確保每個子網路中至少有五個可用 IP 地址,以成功完成自動化。

使用以下範例政策來檢視任何 VPC 中所有子網路的可用 IP 地址:

[ec2-user@ip-172-31-51-214 ~]$ aws ec2 describe-subnets --filters "Name=vpc-id,Values=vpc-078af71a874f2f068" | jq '.Subnets[] | .SubnetId + "=" + "\(.AvailableIpAddressCount)"'
"subnet-0d89886ca3fb30074=8186"
"subnet-0ee46aa228bdc9a74=8187"
"subnet-0a0186a277b8b6a51=8186"
"subnet-0d1fb1de0732b5766=8187"
"subnet-077eff87a4e25316d=8187"
"subnet-0f01c02b04708f638=8186"

用於控制平面和節點的安全群組具有最低要求的傳入和傳出規則

要使 API 伺服器在工作節點上執行時對 kubelet 進行 API 呼叫,它必須具有最低要求的傳入和傳出規則。若要驗證用於控制平面和節點的安全群組是否具有最低要求的傳入和傳出規則,請參閲 Amazon EKS 安全群組考量

aws-auth ConfigMap 具有正確的 IAM 角色,其中包含與您的節點關聯的 Kubernetes 使用者名稱

您必須具有正確的 IAM 角色,其中包含與您的節點關聯的 Kubernetes 使用者名稱,且套用於 aws-auth ConfigMap。若要將 aws-auth ConfigMap 套用於您的叢集,請參閲管理叢集的使用者或 IAM 角色

滿足提交新憑證的要求

Amazon EKS 叢集要求節點的 kubelet 為自身提交和輪換服務憑證。服務憑證不可用時,會發生憑證錯誤。

1.    執行以下命令以驗證 kubelet 伺服器憑證:

cd /var/lib/kubelet/pki/# use openssl command to validate kubelet server cert 
sudo openssl x509 -text -noout -in kubelet-server-current.pem

輸出類似於以下內容:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1e:f1:84:62:a3:39:32:c7:30:04:b5:cf:b0:91:6e:c7:bd:5d:69:fb
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Oct 11 19:03:00 2021 GMT
            Not After : Oct 11 19:03:00 2022 GMT
        Subject: O=system:nodes, CN=system:node:ip-192-168-65-123.us-east-2.compute.internal
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:7f:44:c6:95:7e:0f:1e:f8:f8:bf:2e:f8:a9:40:
                    6a:4f:83:0a:e8:89:7b:87:cb:d6:b8:47:4e:8d:51:
                    00:f4:ac:9d:ef:10:e4:97:4a:1b:69:6f:2f:86:df:
                    e0:81:24:c6:62:d2:00:b8:c7:60:da:97:db:da:b7:
                    c3:08:20:6e:70
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                A8:EA:CD:1A:5D:AB:DC:47:A0:93:31:59:ED:05:E8:7E:40:6D:ED:8C
            X509v3 Authority Key Identifier:
                keyid:2A:F2:F7:E8:F6:1F:55:D1:74:7D:59:94:B1:45:23:FD:A1:8C:97:9B

            X509v3 Subject Alternative Name:
                DNS:ec2-3-18-214-69.us-east-2.compute.amazonaws.com, DNS:ip-192-168-65-123.us-east-2.compute.internal, IP Address:192.168.65.123, IP Address:3.18.214.69

2.    檢閱 kubelet 日誌是否有憑證錯誤。如果您沒有看到錯誤,則表示滿足提交新憑證的要求。

kubelet 日誌憑證錯誤的範例:

kubelet[8070]: I1021 18:49:21.594143 8070 log.go:184] http: TLS handshake error from 192.168.130.116:38710: no serving certificate available for the kubelet

注意:如需更詳細的日誌,請開啟具有旗標 --v=4 的 kubelet 詳細日誌,然後在工作節點上重新啟動 kubelet。kubelet 詳細日誌類似於以下內容:

#kubelet verbosity can be increased by updating this file ...max verbosisty level --v=4
sudo vi /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
# Normal kubelet verbosisty is 2 by default
cat /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf
[Service]
Environment='KUBELET_ARGS=--node-ip=192.168.65.123 --pod-infra-container-image=XXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com/eks/pause:3.1-eksbuild.1 --v=2
#to restart the demon and kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet
#make sure kubelet in running state
sudo systemctl status kubelet
# to stream logs for kubelet
journalctl -u kubelet -f

3.    如果您看到錯誤,請驗證工作節點上的 kubelet config 檔案 /etc/kubernetes/kubelet/kubelet-config.json,然後確認 RotateKubeletServerCertificateserverTLSBootstrap 旗標列為 true:

"featureGates": {
"RotateKubeletServerCertificate": true
},
"serverTLSBootstrap": true,

4.    執行以下 eks:node-bootstrapper 命令,以確認 kubelet 具有提交憑證簽署請求 (CSR) 所需的角色型存取控制 (RBAC) 系統許可:

$ kubectl get clusterrole eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

輸出類似於以下內容:

kind: ClusterRole
metadata:
 annotations:
 kubectl.kubernetes.io/last-applied-configuration: |
 {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"labels":{"eks.amazonaws.com/component":"node"},"name":"eks:node-bootstrapper"},"rules":[{"apiGroups":["certificates.k8s.io"],"resources":["certificatesigningrequests/selfnodeserver"],"verbs":["create"]}]}
 creationTimestamp: "2019-11-17T05:01:38Z"
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "168"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/eks%3Anode-bootstrapper
 uid: 564b6a3a-08f7-11ea-9d07-06e275d1e5e0
rules:
- apiGroups:
 - certificates.k8s.io
resources:
- certificatesigningrequests/selfnodeserver
verbs:
- create

所需的 RBAC 許可包括以下內容:

- apiGroups: ["certificates.k8s.io"]
resources: ["certificatesigningrequests/selfnodeserver"]
verbs: ["create"]

5.    執行以下命令以檢查叢集角色 eks:node-bootstrapper 是否綁定至 system:bootstrapperssystem:nodes。這可讓 kubelet 為自身提交和輪換服務憑證。

$ kubectl get clusterrolebinding eks:node-bootstrapper -o yaml
apiVersion: rbac.authorization.k8s.io/v1

輸出類似於以下內容:

kind: ClusterRoleBinding
metadata:
 labels:
 eks.amazonaws.com/component: node
 name: eks:node-bootstrapper
 resourceVersion: "167"
 selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/eks%3Anode-bootstrapper
 uid: 564a00de-08f7-11ea-9d07-06e275d1e5e0
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: eks:node-bootstrapper
subjects:
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:bootstrappers
- apiGroup: rbac.authorization.k8s.io
 kind: Group
 name: system:nodes

此文章是否有幫助?


您是否需要帳單或技術支援?