本文介紹使用節點自動調整功能時可能遇到的常見問題及解決方案。
問題一：HPA的監控資料current欄位顯示警告資訊
當HPA的監控資料的current欄位顯示以下資訊時，表示Controller Manager無法訪問監控資料來源擷取對應的監控資料。
Name: kubernetes-tutorial-deployment
Namespace: default
Labels: <none>
Annotations: <none>
CreationTimestamp: Mon, 10 Jun 2019 11:46:48 +0530
Reference: Deployment/kubernetes-tutorial-deployment
Metrics: ( current / target )
resource cpu on pods (as a percentage of request): <unknown> / 2%
Min replicas: 1
Max replicas: 4
Deployment pods: 1 current / 0 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: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedGetResourceMetric 3m3s (x1009 over 4h18m) horizontal-pod-autoscaler unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request (get pods.metrics.k8s.io)原因如下：
原因一：resource metrics資料來源無法使用。
先執行命令
kubectl top pod檢查是否返回資料。如果所有的Pod都無資料，請執行kubectl get apiservice檢查當前提供resource metrics的資料來源的情況。返回的樣本資料如下。
NAME SERVICE AVAILABLE AGE v1. Local True 29h v1.admissionregistration.k8s.io Local True 29h v1.apiextensions.k8s.io Local True 29h v1.apps Local True 29h v1.authentication.k8s.io Local True 29h v1.authorization.k8s.io Local True 29h v1.autoscaling Local True 29h v1.batch Local True 29h v1.coordination.k8s.io Local True 29h v1.monitoring.coreos.com Local True 29h v1.networking.k8s.io Local True 29h v1.rbac.authorization.k8s.io Local True 29h v1.scheduling.k8s.io Local True 29h v1.storage.k8s.io Local True 29h v1alpha1.argoproj.io Local True 29h v1alpha1.fedlearner.k8s.io Local True 5h11m v1beta1.admissionregistration.k8s.io Local True 29h v1beta1.alicloud.com Local True 29h v1beta1.apiextensions.k8s.io Local True 29h v1beta1.apps Local True 29h v1beta1.authentication.k8s.io Local True 29h v1beta1.authorization.k8s.io Local True 29h v1beta1.batch Local True 29h v1beta1.certificates.k8s.io Local True 29h v1beta1.coordination.k8s.io Local True 29h v1beta1.events.k8s.io Local True 29h v1beta1.extensions Local True 29h ... [v1beta1.metrics.k8s.io kube-system/metrics-server True 29h] ... v1beta1.networking.k8s.io Local True 29h v1beta1.node.k8s.io Local True 29h v1beta1.policy Local True 29h v1beta1.rbac.authorization.k8s.io Local True 29h v1beta1.scheduling.k8s.io Local True 29h v1beta1.storage.k8s.io Local True 29h v1beta2.apps Local True 29h v2beta1.autoscaling Local True 29h v2beta2.autoscaling Local True 29h如果
v1beta1.metrics.k8s.io所對應的SERVICE不是kube-system/metrics-server，檢查是否由於安裝Prometheus Operator覆蓋導致。如果是覆蓋導致的問題，可以通過部署以下的YAML模板進行恢複。apiVersion: apiregistration.k8s.io/v1beta1 kind: APIService metadata: name: v1beta1.metrics.k8s.io spec: service: name: metrics-server namespace: kube-system group: metrics.k8s.io version: v1beta1 insecureSkipTLSVerify: true groupPriorityMinimum: 100 versionPriority: 100如果非上述問題，請參見相關文檔metric-server的問題診斷部分。
原因二：滾動發布或者擴容時無法擷取資料。
預設metrics-server的採集周期是1秒。剛擴容或更新完成後，metrics-server會有一段時間無法擷取監控資料。請於擴容或更新後2秒左右進行查看。
原因三：缺少request欄位設定。
HPA預設是通過
usage/request作為利用率的數值，因此可以檢查Pod的Resource欄位中是否包含Request欄位。
問題二：HPA在滾動發布時出現擴容多餘Pod
社區的Controller Manager會在滾動發布的時候，對於沒有監控資料的Pod，進行監控資料的補零操作，從而有一定的機率出現擴容出多餘的Pod現象（多彈現象）。您可以通過升級ACK提供的最新版Metrics Server，並在Metrics Server的啟動參數上開啟開關防止多彈。
# 在Metrics Server的啟動參數中加入以下選項。
--enable-hpa-rolling-update-skipped=true問題三：HPA到達閾值不進行擴縮容
HPA的擴縮容的觸發條件不是嚴格超過閾值或低於閾值，還需要額外考慮的是如果擴容或者縮容後，是否會再次觸發縮容或者擴容，減少震蕩的情境。
問題四：HPA採集周期如何配置？
對於版本號碼大於v0.2.1-b46d98c-aliyun的Metrics Server啟動參數設定--metric-resolution，例如--metric-resolution=15s即可。
問題五：兩個HPA，一個設定CPU規則，一個設定Memory規則。當CPU擴容後，Memory會觸發縮容嗎？
CPU擴容後，Memory會觸發縮容，建議將兩者配置在同一個HPA中。
問題六：當CPU規則和Memory規則配置在同一個HPA時，這時需要同時滿足CPU規則和Memory規則，還是只需要滿足一個規則就會擴容？
當兩個metrics觸發彈性的個數不同時，優先根據穩定性原則，彈出更多的副本或者在縮容時保留更多的副本。