協助改進此頁面

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

故障診斷混合節點

本主題涵蓋一些使用 Amazon EKS 混合節點時可能遇到的常見錯誤與修正這些錯誤的方法。如需其他故障診斷資訊，請參閱 AWS re:Post 上的 排解 Amazon EKS 叢集和節點問題 和 Amazon EKS 的知識中心標籤。如果您無法解決問題，請聯絡 AWS Support。

使用 nodeadm debug 進行節點故障診斷 您可以從混合節點執行 nodeadm debug 命令，以驗證是否符合聯網和憑證要求。如需有關 nodeadm debug 命令的詳細資訊，請參閱 混合節點 nodeadm 參考。

使用叢集洞察偵測混合節點的問題 Amazon EKS 叢集洞察包括洞察檢查，可偵測叢集中 EKS 混合節點組態的常見問題。您可以從 AWS 管理主控台、AWS CLI 和 AWS SDK 檢視所有洞察檢查的結果。如需有關叢集洞察的詳細資訊，請參閱 利用叢集洞見為 Kubernetes 版本升級做好準備，並為錯誤組態進行故障診斷。

安裝混合節點故障診斷

下列故障診斷主題與使用 nodeadm install 命令在主機上安裝混合節點相依性相關。

nodeadm 命令失敗 must run as root

nodeadm install 命令必須由主機上具有 root 或 sudo 權限的使用者執行。如果您利用沒有 root 或 sudo 權限的使用者執行 nodeadm install，則會在 nodeadm 輸出中看到下列錯誤。

"msg":"Command failed","error":"must run as root"

無法連接至相依性

nodeadm install 命令可安裝混合節點所需的相依性。混合節點相依性包括 containerd、kubelet、kubectl 和 AWS SSM 或 AWS IAM Roles Anywhere 元件。您必須擁有從執行 nodeadm install 的位置的存取權，才能下載這些相依性。如需您必須能夠存取的位置清單的詳細資訊，請參閱 準備混合節點的聯網。如果您沒有存取權，則會在 nodeadm install 輸出中看到類似以下錯誤。

"msg":"Command failed","error":"failed reading file from url: ...: max retries achieved for http request"

無法更新套件管理工具

在安裝混合節點相依性之前，nodeadm install 命令會執行 apt update 或 yum update 或 dnf update。如果此步驟不成功，您可能會看到類似以下錯誤。若要修復，您可以在執行 nodeadm install 之前執行 apt update、yum update 或 dnf update，也可以嘗試重新執行 nodeadm install。

failed to run update using package manager

逾時或超過內容截止日期

執行 nodeadm install 時，如果您在安裝程序的各個階段看到錯誤，其中指出逾時或超過內容截止日期，則可能是連接速度緩慢，進而導致在逾時之前無法安裝混合節點相依性。若要解決這些問題，您可以嘗試使用 nodeadm 中的 --timeout 旗標來延長下載相依性的逾時持續時間。

nodeadm install K8S_VERSION --credential-provider CREDS_PROVIDER --timeout 20m0s
      

連接混合節點故障診斷

本節中的故障診斷主題與使用 nodeadm init 命令將混合節點連接至 EKS 叢集的程序有關。

操作錯誤或不支援的結構描述

執行 nodeadm init 時，如果您看到與 operation error 或 unsupported scheme 相關的錯誤，請檢查您的 nodeConfig.yaml，以確保其格式正確並傳遞給 nodeadm。如需有關 nodeConfig.yaml 的格式和選項的詳細資訊，請參閱 混合節點 nodeadm 參考。

"msg":"Command failed","error":"operation error ec2imds: GetRegion, request canceled, context deadline exceeded"

混合節點 IAM 角色缺少對 eks:DescribeCluster 動作的許可

執行 nodeadm init 時，nodeadm 會呼叫描述叢集，以嘗試收集有關 EKS 叢集的資訊。如果您的混合節點 IAM 角色沒有 eks:DescribeCluster 動作的許可。如需有關混合節點 IAM 角色所需許可的詳細資訊，請參閱 準備混合節點的憑證。

"msg":"Command failed","error":"operation error EKS: DescribeCluster, https response error StatusCode: 403 ... AccessDeniedException"

節點 IP 不在遠端節點網路 CIDR 中

執行 nodeadm init 時，如果節點的 IP 位址不在指定的遠端節點網路 CIDR 內，則您可能會遇到錯誤。錯誤看起來與下列範例類似：

node IP 10.18.0.1 is not in any of the remote network CIDR blocks [10.0.0.0/16 192.168.0.0/16]

此範例顯示 IP 10.18.0.1 的節點嘗試加入具有遠端網路 CIDR 10.0.0.0/16 和 192.168.0.0/16 的叢集。發生錯誤，因為 10.18.0.1 不在任一範圍內。

確認您已正確設定 RemoteNodeNetworks 以包含所有節點 IP 位址。如需有關聯網組態的詳細資訊，請參閱 準備混合節點的聯網。

aws eks describe-cluster --name CLUSTER_NAME --region REGION_NAME --query cluster.remoteNetworkConfig.remoteNodeNetworks

如果您的節點 IP 仍然不符合預期，請檢查下列項目：

ip addr show

混合節點未出現在 EKS 叢集中

如果您執行 nodeadm init 且已完成，但您的混合節點未出現在叢集中，混合節點與 EKS 控制平面之間的網路連線可能會發生問題，您可能並未設定必要的安全群組許可，或者您可能沒有混合節點 IAM 角色與 Kubernetes 角色型存取控制 (RBAC) 的必要映射。您可以使用下列命令檢查 kubelet 和 kubelet 日誌的狀態，進而開始偵錯程序。從無法加入叢集的混合節點執行下列命令。

systemctl status kubelet

journalctl -u kubelet -f

無法與叢集通訊

如果您的混合節點無法與叢集控制平面通訊，您可能會看到類似如下的日誌。

"Failed to ensure lease exists, will retry" err="Get ..."

"Unable to register node with API server" err="Post ..."

Failed to contact API server when waiting for CSINode publishing ... dial tcp <ip address>: i/o timeout

如果您看到這些訊息，請檢查下列項目，以確保其符合 準備混合節點的聯網 中詳述的混合節點要求。

未經授權

如果您的混合節點能夠與 EKS 控制平面通訊但無法註冊，您可能會看到類似如下的日誌。請注意，以下日誌訊息中的主要差異是 Unauthorized 錯誤。這表明該節點無法執行其任務，因為它沒有必要許可。

"Failed to ensure lease exists, will retry" err="Unauthorized"

"Unable to register node with API server" err="Unauthorized"

Failed to contact API server when waiting for CSINode publishing: Unauthorized

如果您看到這些訊息，請檢查下列項目，以確保其符合 準備混合節點的憑證 和 準備混合節點的叢集存取 中詳述的混合節點要求。

向 EKS 叢集註冊但顯示狀態為 Not Ready 的混合節點

如果您的混合節點已成功向 EKS 叢集註冊，但混合節點顯示狀態為 Not Ready，則首先要檢查的是容器聯網介面 (CNI) 狀態。如果您尚未安裝 CNI，則預期您的混合節點的狀態為 Not Ready。成功安裝並執行 CNI 後，節點狀態會更新為 Ready。如果您嘗試安裝 CNI，但未成功執行，請參閱此頁面上的 混合節點 CNI 故障診斷。

憑證簽署請求 (CSR) 卡在待定狀態

將混合節點連接到 EKS 叢集後，如果您看到混合節點有待定的 CSR，則您的混合節點不符合自動核准的要求。如果混合節點的 CSR 是由具有 eks.amazonaws.com/compute-type: hybrid 標籤的節點建立，且 CSR 具有下列主體替代名稱 (SAN)，則會自動核准及核發混合節點的 CSR：至少一個 DNS SAN 等於節點名稱且 IP SAN 屬於遠端節點網路 CIDR。

混合設定檔已存在

如果您變更 nodeadm 組態並嘗試使用新組態重新註冊節點，您可能會發現錯誤，其中會指出混合設定檔已存在，但其內容已變更。不要在組態變更之間執行 nodeadm init，而是要先執行 nodeadm uninstall，然後再執行 nodeadm install 和 nodeadm init。如此可確保正確清除組態中的變更。

"msg":"Command failed","error":"hybrid profile already exists at /etc/aws/hybrid/config but its contents do not align with the expected configuration"

混合節點無法解析私有 API

執行 nodeadm init 後，如果您在 kubelet 日誌中發現錯誤，其中顯示由於存在 no such host 的情況而無法聯絡 EKS Kubernetes API 伺服器，您可能需要變更內部部署網路或主機層級的 EKS Kubernetes API 端點的 DNS 項目。請參閱 AWS Route53 文件中的將傳入 DNS 查詢轉送到您的 VPC。

Failed to contact API server when waiting for CSINode publishing: Get ... no such host

無法在 EKS 主控台中檢視混合節點

如果您已註冊混合節點，但無法在 EKS 主控台中進行檢視，請檢查您用來檢視主控台的 IAM 主體的許可。您使用的 IAM 主體必須具有特定的最低 IAM 和 Kubernetes 許可，才能在主控台中檢視資源。如需詳細資訊，請參閱 檢視 AWS 管理主控台 中的 Kubernetes 資源。

執行混合節點故障診斷

如果您的混合節點已向 EKS 叢集註冊，狀態為 Ready，然後轉換為狀態 Not Ready，則可能存在各種問題會導致運作狀態不佳，例如節點缺少充足的 CPU、記憶體或可用磁碟空間資源，或節點與 EKS 控制平面中斷連線。您可以使用下列步驟對節點進行故障診斷，如果您無法解決該問題，請聯絡 AWS Support。

從混合節點執行 nodeadm debug，以驗證是否符合聯網和憑證要求。如需有關 nodeadm debug 命令的詳細資訊，請參閱 混合節點 nodeadm 參考。

取得節點狀態

kubectl get nodes -o wide

檢查節點條件和事件

kubectl describe node NODE_NAME
      

取得 Pod 狀態

kubectl get pods -A -o wide

檢查 Pod 條件和事件

kubectl describe pod POD_NAME
      

檢查 Pod 日誌

kubectl logs POD_NAME
      

檢查 kubectl 日誌

systemctl status kubelet

journalctl -u kubelet -f

Pod 即時性探查失敗或 Webhook 無法運作

如果混合節點上執行的應用程式、附加元件或 Webhook 未正確啟動，您可能會遇到封鎖與 Pod 的通訊的聯網問題。若要讓 EKS 控制平面聯絡在混合節點上執行的 Webhook，您必須使用遠端 Pod 網路設定 EKS 叢集，並在 VPC 路由表中為內部部署 Pod CIDR 設定路由，且以傳輸閘道 (TGW)、虛擬私有閘道 (VPW) 或您用來連接 VPC 與內部部署網路的其他閘道為目標。如需有關混合節點的聯網需求的詳細資訊，請參閱 準備混合節點的聯網。此外，您還必須在內部部署防火牆中允許此流量，並確保您的路由器可正確路由到您的 Pod。如需有關在混合節點上執行 Webhook 的需求的詳細資訊，請參閱 設定混合節點的 Webhook。

此案例的常見 Pod 日誌訊息如下所示，其中 ip-address 是 Kubernetes Service 的叢集 IP。

dial tcp <ip-address>:443: connect: no route to host

kubectl logs 或 kubectl exec 命令無法運作

如果 kubectl logs 或 kubectl exec 命令在其他 kubectl 命令成功時逾時，那麼該問題可能與遠端網路組態有關。這些命令會透過叢集連接至節點上的 kubelet 端點。如需更多資訊，請參閱kubelet 端點。

確認您的節點 IP 和 Pod IP 位於為叢集設定的遠端節點網路和遠端 Pod 網路 CIDR 內。使用以下命令來檢查 IP 指派。

kubectl get nodes -o wide

kubectl get pods -A -o wide

將這些 IP 與您設定的遠端網路 CIDR 進行比較，以確保正確路由。有關網路組態需求，請參閱 準備混合節點的聯網。

混合節點 CNI 故障診斷

如果您一開始使用混合節點啟動 Cilium 或 Calico 時就遇到問題，最常見的原因是混合節點或混合節點上執行的 CNI Pod 與 EKS 控制平面之間存在聯網問題。請確保您的環境符合準備混合節點的聯網要求。將問題分成幾個部分非常實用。

混合節點的狀態為 Ready 且 CNI 未安裝

如果您的混合節點顯示狀態為 Ready，但您尚未在叢集上安裝 CNI，則混合節點上可能存在舊的 CNI 成品。根據預設，當您使用 Helm 等工具解除安裝 Cilium 和 Calico 時，不會從實體或虛擬機器中移除磁碟上的資源。此外，這些 CNI 的自訂資源定義 (CRD) 仍可能存在於舊安裝的叢集上。如需詳細資訊，請參閱 設定混合節點的 CNI 的「刪除 Cilium」和「刪除 Calico」章節。

Cilium 故障診斷

如果您在混合節點上執行 Cilium 時遇到問題，請參閱 Cilium 文件中的故障診斷步驟。以下各節涵蓋在混合節點上部署 Cilium 時可能特有的問題。

Cilium 未啟動

如果每個混合節點上執行的 Cilium 代理程式未啟動，請檢查 Cilium 代理程式 Pod 的日誌是否存在錯誤。Cilium 代理程式需要連線到 EKS Kubernetes API 端點才能啟動。如果未正確設定此連線，則 Cilium 代理程式啟動會失敗。在此情況下，您會在 Cilium 代理程式 Pod 日誌中看到類似如下的日誌訊息。

msg="Unable to contact k8s api-server"
level=fatal msg="failed to start: Get \"https://<k8s-cluster-ip>:443/api/v1/namespaces/kube-system\": dial tcp <k8s-cluster-ip>:443: i/o timeout"

Cilium 代理程式會在主機網路上執行。您的 EKS 叢集必須使用 RemoteNodeNetwork 進行設定，如此才能實現 Cilium 連線。確認您的 EKS 叢集具有其他安全群組，且該安全群組包含適用於 RemoteNodeNetwork 的傳入規則，您的 VPC 中為您的 RemoteNodeNetwork 設定了路由，並且您的內部部署網路已正確設定為允許連線至 EKS 控制平面。

如果 Cilium 運算子正在執行，且部分 Cilium 代理程式也正在執行 (並非全部)，則請確認您有可用的 Pod IP 可配置給叢集中的所有節點。您可以在 Cilium 組態中搭配使用叢集集區 IPAM 和 clusterPoolIPv4PodCIDRList 時，設定可配置的 Pod CIDR 大小。每個節點 CIDR 大小是使用 Cilium 組態中的 clusterPoolIPv4MaskSize 設定進行設定的。如需詳細資訊，請參閱 Cilium 文件中的展開叢集集區。

Cilium BGP 無法運作

如果您使用 Cilium BGP 控制平面向內部部署網路公告您的 Pod 或服務地址，則您可以使用下列 Cilium CLI 命令來檢查 BGP 是否會向資源公告路由。有關安裝 Cilium CLI 的步驟，請參閱 Cilium 文件中的安裝 Cilium CLI。

如果 BGP 正常運作，您應該在輸出中看到工作階段狀態為 established 的混合節點。您可能需要與聯網團隊合作，以便為環境的本機 AS、對等 AS 和對等地址確定正確的值。

cilium bgp peers

cilium bgp routes

如果您使用 Cilium BGP 來公告類型為 LoadBalancer 的 服務 IP，則您的 CiliumLoadBalancerIPPool 和 服務必須具有相同的標籤，而該標籤應該在您的 CiliumBGPAdvertisement 選取器中使用。以下所示為範例。請注意，如果您使用 Cilium BGP 來公告 LoadBalancer 類型的服務 IP，則 BGP 路由可能會在 Cilium 代理程式重新啟動期間中斷。如需詳細資訊，請參閱 Cilium 文件中的失敗案例。

服務

kind: Service
apiVersion: v1
metadata:
  name: guestbook
  labels:
    app: guestbook
spec:
  ports:
  - port: 3000
    targetPort: http-server
  selector:
    app: guestbook
  type: LoadBalancer

CiliumLoadBalancerIPPool

apiVersion: cilium.io/v2alpha1
kind: CiliumLoadBalancerIPPool
metadata:
  name: guestbook-pool
  labels:
    app: guestbook
spec:
  blocks:
  - cidr: <CIDR to advertise>
  serviceSelector:
    matchExpressions:
      - { key: app, operator: In, values: [ guestbook ] }

CiliumBGPAdvertisement

apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: bgp-advertisements-guestbook
  labels:
    advertise: bgp
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - ExternalIP
          - LoadBalancerIP
      selector:
        matchExpressions:
          - { key: app, operator: In, values: [ guestbook ] }

Calico 故障診斷

如果您在混合節點上執行 Calico 時遇到問題，請參閱 Calico 文件中的故障診斷步驟。以下各節涵蓋在混合節點上部署 Calico 時可能特有的問題。

下表摘要說明了 Calico 元件以及它們是否會依預設在節點或 Pod 網路上執行。如果您將 Calico 設定為使用 NAT 傳出 Pod 流量，則必須將內部部署網路設定為將流量路由到內部部署節點 CIDR，而您的 VPC 路由表必須設定有為內部部署節點 CIDR 的路由，且這些路由會以傳輸閘道 (TGW) 或虛擬私有閘道 (VGW) 為目標。如果您未將 Calico 設定為使用 NAT 傳出 Pod 流量，則必須將內部部署網路設定為將流量路由到內部部署 Pod CIDR，而您的 VPC 路由表必須設定有為內部部署 Pod CIDR 的路由，且這些路由會以傳輸閘道 (TGW) 或虛擬私有閘道 (VGW) 為目標。

Calico 資源已在封鎖節點上排程或執行

根據預設，Calico 資源未以 DaemonSet 執行並且具有靈活的容錯能力，可在尚未準備好排程或執行 Pod 的封鎖節點上排程這些資源。您可以變更您的運算子安裝以包含下列內容，進而限制非 DaemonSet Calico 資源的容錯。

installation:
  ...
  controlPlaneTolerations:
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  calicoKubeControllersDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300
  typhaDeployment:
    spec:
      template:
        spec:
          tolerations:
          - effect: NoExecute
            key: node.kubernetes.io/unreachable
            operator: Exists
            tolerationSeconds: 300
          - effect: NoExecute
            key: node.kubernetes.io/not-ready
            operator: Exists
            tolerationSeconds: 300

憑證故障診斷

對於 AWS SSM 混合啟用和 AWS IAM Roles Anywhere，您可以從混合節點執行下列命令，進而驗證混合節點 IAM 角色的憑證是否已在您的混合節點上正確設定。確認節點名稱和混合節點 IAM 角色名稱與您的預期相符。

sudo aws sts get-caller-identity

{
    "UserId": "ABCDEFGHIJKLM12345678910:<node-name>",
    "Account": "<aws-account-id>",
    "Arn": "arn:aws:sts::<aws-account-id>:assumed-role/<hybrid-nodes-iam-role/<node-name>"
}

AWS Systems Manager (SSM) 故障診斷

如果您針對混合節點憑證使用 AWS SSM 混合啟用，則請注意由 nodeadm 安裝在混合節點上的下列 SSM 目錄和成品。如需有關 SSM 代理程式的詳細資訊，請參閱《AWS Systems Manager 使用者指南》中的使用 SSM 代理程式。

重新啟動 SSM 代理程式

重新啟動 SSM 代理程式即可解決某些問題。您可以使用以下命令來重新啟動。

AL2023 和其他作業系統

systemctl restart amazon-ssm-agent

Ubuntu

systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent

檢查 SSM 端點的連線

確認您可以從混合節點連接至 SSM 端點。如需 SSM 端點的清單，請參閱 AWS Systems Manager 端點和配額。使用 AWS SSM 混合啟用的 AWS 區域取代以下命令中的 us-west-2。

ping ssm.us-west-2.amazonaws.com

檢視已註冊的 SSM 執行個體的連線狀態

您可以使用下列 AWS CLI 命令，檢查已向 SSM 混合啟用註冊的執行個體的連線狀態。使用您執行個體的機器 ID 取代機器 ID。

aws ssm get-connection-status --target mi-012345678abcdefgh
      

SSM Setup CLI 檢查總和不相符

執行 nodeadm install 時，如果您看到 ssm-setup-cli 檢查總和不相符的問題，則您應該確認主機上的現有 SSM 安裝並非較舊版本。如果您的主機上有較舊的 SSM 安裝，則請將其移除並重新執行 nodeadm install，以解決問題。

Failed to perform agent-installation/on-prem registration: error while verifying installed ssm-setup-cli checksum: checksum mismatch with latest ssm-setup-cli.

SSM InvalidActivation

如果您發現向 AWS SSM 註冊執行個體時出現錯誤，請確認 nodeConfig.yaml 中的 region、activationCode 和 activationId 正確無誤。EKS 叢集的 AWS 區域必須與 SSM 混合啟用的區域相符。如果這些值設定錯誤，您可能會看到類似如下的錯誤。

ERROR Registration failed due to error registering the instance with AWS SSM. InvalidActivation

SSM ExpiredTokenException：包含在​請求中的安全性權杖已過期

如果 SSM 代理程式無法重新整理憑證，您可能會看到 ExpiredTokenException。在這種情況下，如果您能夠從混合節點連接至 SSM 端點，您可能需要重新啟動 SSM 代理程式，以強制執行憑證重新整理。

"msg":"Command failed","error":"operation error SSM: DescribeInstanceInformation, https response error StatusCode: 400, RequestID: eee03a9e-f7cc-470a-9647-73d47e4cf0be, api error ExpiredTokenException: The security token included in the request is expired"

執行 register machine 命令時發生 SSM 錯誤

如果您發現向 SSM 註冊機器時出現錯誤，您可能需要重新執行 nodeadm install，以確保已正確安裝所有 SSM 相依性。

"error":"running register machine command: , error: fork/exec /opt/aws/ssm-setup-cli: no such file or directory"

SSM ActivationExpired

執行 nodeadm init 時，如果您發現因為過期的啟用而向 SSM 註冊執行個體發生錯誤，您需要建立新的 SSM 混合啟用、使用新的 SSM 混合啟用的 activationCode 和 activationId 更新 nodeConfig.yaml，並重新執行 nodeadm init。

"msg":"Command failed","error":"SSM activation expired. Please use a valid activation"

ERROR Registration failed due to error registering the instance with AWS SSM. ActivationExpired

SSM 無法重新整理快取的憑證

如果您發現重新整理快取的憑證失敗，/root/.aws/credentials 檔案可能已從您的主機上刪除。首先檢查您的 SSM 混合啟用，並確保其處於作用中狀態，且您的混合節點已正確設定為使用啟用。檢查位於 /var/log/amazon/ssm 的 SSM 代理程式日誌，並在 SSM 端解決問題後重新執行 nodeadm init 命令。

"Command failed","error":"operation error SSM: DescribeInstanceInformation, get identity: get credentials: failed to refresh cached credentials"

清除 SSM

若要從主機移除 SSM 代理程式，您可以執行下列命令。

dnf remove -y amazon-ssm-agent
sudo apt remove --purge amazon-ssm-agent
snap remove amazon-ssm-agent
rm -rf /var/lib/amazon/ssm/Vault/Store/RegistrationKey

AWS IAM Roles Anywhere 故障診斷

如果您針對混合節點憑證使用 AWS IAM Roles Anywhere，則請注意由 nodeadm 安裝在混合節點上的下列目錄和成品。如需故障診斷 IAM Roles Anywhere 的詳細資訊，請參閱《AWS IAM Roles Anywhere 使用者指南》中的故障診斷 AWS IAM Roles Anywhere 身分和存取權。

IAM Roles Anywhere 無法重新整理快取的憑證

如果您發現重新整理快取的憑證失敗，請檢閱 /etc/aws/hybrid/config 的內容，並確認已正確設定 nodeadm 組態中的 IAM Roles Anywhere。確認存在 /etc/iam/pki。每個節點都必須有唯一的憑證和金鑰。根據預設，使用 IAM Roles Anywhere 作為憑證提供者時，nodeadm 會將 /etc/iam/pki/server.pem 用於憑證位置和名稱，以及將 /etc/iam/pki/server.key 用於私有金鑰。您可能需要先建立目錄，然後再將憑證和金鑰放入具有 sudo mkdir -p /etc/iam/pki 的目錄中。您可以使用以下命令來驗證憑證的內容。

openssl x509 -text -noout -in server.pem

open /etc/iam/pki/server.pem: no such file or directory
could not parse PEM data
Command failed {"error": "... get identity: get credentials: failed to refresh cached credentials, process provider error: error in credential_process: exit status 1"}

IAM Roles Anywhere 未獲授權執行 sts:AssumeRole

在 kubelet 日誌中，如果您在使用 IAM Roles Anywhere 時發現 sts:AssumeRole 操作的存取遭拒問題，請檢查混合節點 IAM 角色的信任政策，以確認允許 IAM Roles Anywhere 服務主體擔任混合節點 IAM 角色。此外，請確認您的混合節點 IAM 角色信任政策中已正確設定信任錨 ARN，並且您的混合節點 IAM 角色已新增至您的 IAM Roles Anywhere 設定檔。

could not get token: AccessDenied: User: ... is not authorized to perform: sts:AssumeRole on resource: ...

IAM Roles Anywhere 未獲授權設定 roleSessionName

在 kubelet 日誌中，如果您發現設定 roleSessionName 時出現存取遭拒問題，請確認您已為 IAM Roles Anywhere 設定檔將 acceptRoleSessionName 設為 true。

AccessDeniedException: Not authorized to set roleSessionName

作業系統故障診斷

RHEL

權利或訂閱管理員註冊失敗

如果您正在執行 nodeadm install，且由於權利註冊問題而無法安裝混合節點相依性，則請確保您已在主機上正確設定您的 Red Hat 使用者名稱和密碼。

This system is not registered with an entitlement server

Ubuntu

找不到 GLIBC

如果您將 Ubuntu 用於作業系統，並將 IAM Roles Anywhere 用作具有混合節點的憑證提供者，同時還發現找不到 GLIBC 的問題，則您可以手動安裝該相依性，進而解決問題。

GLIBC_2.32 not found (required by /usr/local/bin/aws_signing_helper)

執行下列命令以安裝相依性：

ldd --version
sudo apt update && apt install libc6
sudo apt install glibc-source

Bottlerocket

如果您已啟用 Bottlerocket 管理員容器，則可使用 SSH 來進行存取，以利用更高的權限進行進階偵錯和故障診斷。下列各節包含需要在 Bottlerocket 主機環境中執行的命令。進入管理員容器後，您可以執行 sheltie，以取得 Bottlerocket 主機中的完整根 shell。

sheltie

您也可以在每個命令前加上字首 sudo chroot /.bottlerocket/rootfs，進而從管理員容器 Shell 的下列區段中執行命令。

sudo chroot /.bottlerocket/rootfs <command>

使用 logdog 進行日誌收集

Bottlerocket 提供 logdog 公用程式來高效收集日誌和系統資訊，進而供故障診斷之用。

logdog

logdog 公用程式會從 Bottlerocket 主機上的不同位置收集日誌，並將其合併為 tarball。根據預設，tarball 會在 /var/log/support/bottlerocket-logs.tar.gz 中建立，並且可從 /.bottlerocket/support/bottlerocket-logs.tar.gz 的託管容器存取。

使用 journalctl 存取系統日誌

您可以使用下列命令檢查各種系統服務的狀態 (例如 kubelet、containerd 等等)，並檢視其日誌。-f 旗標會即時追蹤日誌。

若要檢查 kubelet 服務狀態並擷取 kubelet 日誌，您可以執行：

systemctl status kubelet
journalctl -u kubelet -f

若要檢查 containerd 服務狀態並擷取協調的 containerd 執行個體的日誌，您可以執行：

systemctl status containerd
journalctl -u containerd -f

若要檢查 host-containerd 服務狀態並擷取主體 containerd 執行個體的日誌，您可以執行：

systemctl status host-containerd
journalctl -u host-containerd -f

如需擷取引導容器和託管容器的日誌，您可以執行：

journalctl _COMM=host-ctr -f