使用 AWS re:Post 即表示您同意 AWS re:Post 使用條款
AWS re:Postre:Post

為什麼我無法使用 Amazon EKS 中的指標伺服器，從容器、Pod 或節點收集指標？

4 分的閱讀內容
0

我無法使用 Amazon Elastic Kubernetes Service (Amazon EKS) 叢集中的指標伺服器，從容器、Pod 或節點收集指標。

簡短說明

在 Amazon EKS 中，依預設未安裝指標伺服器。如果您已建立叢集，但無法使用指標伺服器收集指標，請確認您已將指標伺服器應用程式部署至叢集。

如果您仍然無法使用指標伺服器收集指標，請完成以下各節中的步驟：

  • 檢查您是否可自叢集節點和 Pod 擷取指標。
  • 檢查 APIService 是否可用且可處理請求。
  • 檢查 GitHub 上的常見問題。
  • 如果指標顯示如下，請檢查 Horizontal Pod Autoscaler (HPA) 和應用程式資源請求：<unknown>。

**注意：**指標伺服器並不是長期監控應用程式和叢集效能的最佳實務。如需長期監視，請參閱 Kubernetes 網站上的 ](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/)Pod 和容器的資源管理[。Kubernetes 社群會維護指標伺服器，並在 GitHub 頁面上報告問題。

解決方法

請參閱下列步驟，以對指標伺服器的一些最常見問題進行疑難排解。

檢查您是否可從叢集的節點和 Pod 擷取指標

檢查 API 伺服器與指標伺服器之間的錯誤。若要從叢集的節點和 Pod 提取指標，請執行下列命令：

$ kubectl top nodes
$ kubectl top pods

如果您未從任一命令收到錯誤，則參閱檢查 APIService 是否可用且可處理請求一節。

如果您收到錯誤，請根據您收到的錯誤，完成下列其中一節的步驟：

  • Error from server (Forbidden)
  • Error from server (ServiceUnavailable)
  • Client.Timeout exceeded while awaiting headers
  • Connection refused

Error from server (Forbidden)

此錯誤訊息表示您具有 RBAC 授權相關的問題。若要解決此錯誤，請確認下列事項：

  • ServiceAccount 已正確連接至部署。
  • ClusterRole/Role 和 ClusterRoleBinding/RoleBindings 會使用指標伺服器的正確 RBAC 權限。

如需詳細資訊，請參閱 Kubernetes 網站上的使用 RBAC 授權。

如果您透過 aws-auth ConfigMap 中定義的角色存取叢集，請確認已設定使用者名稱欄位和映射。

  1. 若要描述 aws-auth ConfigMap，請執行下列命令：

    $ kubectl describe -n kube-system configmap aws-auth

  2. 確認您已針對存取叢集的角色設定使用者名稱欄位。請參閱下列範例：

    Name:         aws-auth
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
mapRoles:
----
...
-
  groups:
  - system:masters
  rolearn: arn:aws:iam::123456789123:role/kubernetes-devops
  username: devops:{{SessionName}}  # Ensure this has been specified.

Error from server (ServiceUnavailable)

若要檢查叢集中指標伺服器服務應用程式的組態是否出現問題，請執行下列命令：

$ kubectl describe apiservices v1beta1.metrics.k8s.io

輸出看起來類似於下列範例：

Name:         v1beta1.metrics.k8s.io
Namespace:
Labels:       app=metrics-server
...
Status:
  Conditions:
    Last Transition Time:  2020-01-09T13:57:23Z
    Message:               all checks passed
    Reason:                Passed
    Status:                True
    Type:                  Available
Events:                    <none>

如果指標伺服器服務可用且通過檢查，則狀態會設定為真。

如果您將狀態設定為 True 且問題仍然存在，請參閱檢查 APIService 是否可用且可處理請求一節。

如果狀態已設定為 False，請尋找相關的原因代碼與使用者可看懂的訊息，了解輸出中的條件。請參閱下列失敗的 APIService 範例：

...
Status:
  Conditions:
    Last Transition Time:  2020-01-09T14:40:28Z
    Message:               no response from https://10.0.35.231:443: Get https://10.0.35.231:443: dial tcp 10.0.35.231:443: connect: connection refused
    Reason:                FailedDiscoveryCheck
    Status:                False
    Type:                  Available

如果原因不是 FailedDiscoveryCheck，請參閱其他 APIServer 條件失敗原因一節。

如果原因代碼為 FailedDiscoveryCheck，則表示指標伺服器服務可用且 Pod 正在執行。當 Kubernetes APIServer 嘗試連線至指標伺服器端點時，就會傳回錯誤。

如果 APIServer 條件訊息包含 Client.Timeout exceeded while awaiting headers，請參閱解決「Client.Timeout exceeded while awaiting headers」錯誤一節。

如果 APIServer 條件訊息包含 connection refused，請參閱解決「connection refused」錯誤一節。

解決「Client.Timeout exceeded while awaiting headers」錯誤

APIService 中的錯誤訊息表示安全群組或網路存取控制清單 (ACL) 未正確設定。如此將無法存取 metrics-server Pod。請參閱下列範例：

no response from https://10.0.35.231:443: Get https://10.0.35.231:443: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

若要解決此錯誤，請確認安全群組符合 Amazon EKS 的最低流量需求。

解決「connection refused」錯誤

APIServer 訊息中的該錯誤表示容器正在錯誤的連接埠上進行接聽。請參閱下列範例：

no response from https://10.0.35.231:443: Get https://10.0.35.231:443: dial tcp 10.0.35.231:443: connect: connection refused

若要解決此錯誤，請執行下列命令，以確認 metrics-server 部署中的連接埠、映像及命令值正確：

$ kubectl describe deployment metrics-server -n kube-system

輸出看起來類似於下列範例：

Name:                   metrics-server
Namespace:              kube-system
CreationTimestamp:      Wed, 08 Jan 2020 11:48:45 +0200
Labels:                 app=metrics-server
...
  Containers:
   metrics-server:
    Image:      gcr.io/google_containers/metrics-server-amd64:v0.3.6
    Port:       443/TCP
    Command:
    - /metrics-server
    - --logtostderr
    - --secure-port=443
...

注意： 命令和映像值可能會根據指標伺服器部署的方式和映像儲存的位置而有所不同。如果命令包含 --secure-port 參數，則該 Pod 公開的 連接埠 (先前範例中的 443/TCP) 必須符合此參數。如果命令不包含 --secure-port 參數，則該連接埠會預設為 443。

其他 APIServer 條件失敗原因

如果您收到下列任何 APIService 代碼，請根據相關的錯誤訊息採取行動： ServiceNotFound、ServiceAccessError、ServicePortError、EndpointsNotFound、EndpointsAccessError 或 MissingEndpoints。

  1. 若要取得具有錯誤的服務相關資訊，請執行下列命令：

    $ kubectl get service -n kube-system

    在輸出訊息中，確認 Kubernetes 服務的名稱和命名空間與 APIService.Spec.Service 中定義的名稱和命名空間相同。然後，確認連接埠已設定為 443/TCP。請參閱下列範例：

    NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
metrics-server                   ClusterIP   172.20.172.133   <none>        443/TCP    65m

  2. 若要列出端點，請執行下列命令：

    $ kubectl get endpoints metrics-server -n kube-system

    在輸出訊息中，確認您至少具有一個適用於 metrics-server 服務的端點：

    NAME             ENDPOINTS         AGE
metrics-server   10.0.35.231:443   76m

  3. 若要確認部署存在，且標籤符合 metrics-server 服務的標籤，請執行下列命令：

    $ kubectl describe deploy metrics-server -n kube-system

    在輸出訊息中，確認部署至少具有一個複本：

    Name:                   metrics-server
Namespace:              kube-system
CreationTimestamp:      Wed, 08 Jan 2020 11:48:45 +0200
Labels:                 app=metrics-server
                        release=metrics-server
...
Selector:               app=metrics-server,release=metrics-server
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
...
Pod Template:
  Labels:           app=metrics-server
                    release=metrics-server
  Service Account:  metrics-server
  Containers:
   metrics-server:
    Image:      gcr.io/google_containers/metrics-server-amd64:v0.3.6
...

如果您仍無法使用指標伺服器收集指標，請參閱檢查 APIService 是否可用且可處理請求一節。

檢查 APIService 是否可用且可處理請求

若要從指標伺服器 Pod 擷取日誌，請執行下列命令：

$ kubectl logs -n <namespace> -l app=metrics-server

例如，metrics-server 中的錯誤日誌以 E 開頭：

E0610 23:13:28.247604       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:13:43.260069       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:16:13.346070       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-cj67b: no metrics known for pod "default/php-apache-b5f58cc5f-cj67b"
E0610 23:16:13.346087       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-sqc6l: no metrics known for pod "default/php-apache-b5f58cc5f-sqc6l"
E0610 23:16:13.346091       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-4cpwk: no metrics known for pod "default/php-apache-b5f58cc5f-4cpwk"

指標伺服器錯誤日誌會指出指標伺服器部署命令中的組態問題，或指標伺服器容器的相關錯誤。如果錯誤訊息不明顯，或您懷疑該訊息為錯誤，請完成檢查 GitHub 上的常見問題一節中的步驟。

檢查 GitHub 上的常見問題

如果您仍無法從容器、Pod 或節點收集指標，請檢查 GitHub 上的指標伺服器相關常見問題。

檢查 HPA 和應用程式資源請求是否具有未知的指標

  1. 若要檢查 HPA 組態，請執行下列命令：

    $ kubectl get hpa -n namespace 2048-deployment

    注意：使用應用程式的 HPA 組態值取代命名空間和 2048-deployment。您可能會看到 <unknown>(在輸出的目標資料欄下)。請參閱下列範例：

    NAME              REFERENCE                    TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
2048-deployment   Deployment/2048-deployment   <unknown>/80%   1         2         2          10s

  2. 等待數分鐘，然後重複步驟 1 中的命令。

    如果您仍然收到 <unknown> 錯誤，請執行下列命令：

    $ kubectl describe hpa -n <namespace> 2048-deployment

    接著，檢查輸出中的事件區段，以取得詳細資訊：

    Name:                                                  2048-deployment
Namespace:                                             2048-game
...
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 80%
Min replicas:                                          1
Max replicas:                                          2
Deployment pods:                                       2 current / 2 desired
Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: missing request for cpu
Events:
  Type     Reason                   Age                     From                       Message
  ----     ------                   ----                    ----                       -------
  Warning  FailedGetResourceMetric  3m29s (x4333 over 19h)  horizontal-pod-autoscaler  missing request for cpu

    如果訊息資料欄顯示 [x] 缺少請求，則部署或 ReplicaSet 可能在其規格中尚未宣告資源請求。確認 Pod 中的所有容器皆已宣告請求。遺漏請求可能會造成 HPA 中的指標傳回 <unknown> 回應。

如需詳細資訊，請參閱 Kubernetes 網站上的 Pod 和容器的資源管理。

主題
容器
標籤
Amazon Elastic Kubernetes Service
語言
中文 (繁體)
AWS 官方
AWS 官方已更新 1 年前
沒有評論

相關內容