本文介紹容器服務ACK彈性伸縮的常見問題及解決辦法。
類型 | 問題 |
水平伸縮（HPA）常見問題 | |
基于組件指標的水平伸縮常見問題 | |
節點自動伸縮常見問題 |
HPA的監控數據current字段為何顯示為unknown？
當HPA的監控數據的current字段顯示為unknown時，表示kube-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所對應的apiservice不是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如果非上述問題，請確認已在集群的運維管理 > 組件管理頁面安裝了metrics-server組件。更多信息，參見metrics-server。
原因二：滾動發布或者擴容時無法獲取數據。
默認metrics-server的采集周期是1 min。剛擴容或更新完成后，metrics-server會有一段時間無法獲取監控數據。請于擴容或更新后2 min左右進行查看。
原因三：缺少request字段設置。
HPA默認是通過實際的利用率/request作為利用率的數值，因此可以檢查Pod的Resource字段中是否包含Request字段。
為何HPA在滾動發布時出現擴容多余Pod？
社區Controller Manager在滾動發布時，對于沒有監控數據的Pod，進行監控數據的補零操作，從而有一定的概率出現擴容出多余的Pod現象（多彈現象）。您可以通過以下配置防止多彈。
集群維度配置。
您可以通過升級ACK提供的最新版metrics-server，并在metrics-server的啟動參數上開啟開關防止多彈。
這是全局開關，設置后對集群內所有相關負載生效。
##在metrics-server的啟動參數中加入以下選項。 --enable-hpa-rolling-update-skipped=true工作負載維度配置。如果只想對指定的工作負載開啟防止多彈，您可以使用以下兩種方法防止多彈。
方法一：通過在指定工作負載的模板中添加以下Annotation，可以在滾動發布時臨時暫停HPA的判斷生效。
##工作負載的spec.template.metadata.annotations加入Annotation，滾動發布時臨時暫停HPA的判斷生效。 HPARollingUpdateSkipped: "true"示例如下。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment-basic labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx annotations: HPARollingUpdateSkipped: "true" # 跳過滾動發布時的HPA的效果。 spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80方法二：通過在指定工作負載的模板中添加以下Annotation，可以在應用發布開始階段跳過設定的預熱時間段。
##工作負載的spec.template.metadata.annotations加入Annotation,在應用發布開始階段跳過設定的預熱的時間段。 HPAScaleUpDelay: 3m # 3m僅為示例，具體時間段請按需設置示例如下。
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment-basic labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx annotations: HPAScaleUpDelay: 3m # m代表分鐘，表示HPA在Pod創建3分鐘后開始生效，可選單位為[s（秒），m（分）]。 spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
HPA到達閾值為何不進行擴縮容？
HPA的擴縮容的觸發條件不僅是CPU使用率或內存使用率超過閾值與低于閾值，需要額外考慮的是如果擴容或者縮容后，是否會再次觸發縮容或者擴容，減少震蕩的場景。
例如當您的擴容閾值設置為80%，如果有兩個Pod的CPU目前使用率都是70%，這種情況下就不會縮容。因為縮容后可能單個Pod的CPU使用率高于80%，就會觸發擴容，這樣就會來回擴縮容出現震蕩。
HPA采集周期如何配置？
對版本號大于v0.2.1-b46d98c-aliyun的metric-server，在metric-server的啟動參數中設置--metric-resolution，例如--metric-resolution=15s即可。
CronHPA是否兼容HPA？
CronHPA可以兼容HPA。阿里云容器服務ACK將CronHPA中的scaleTargetRef設置為HPA對象，然后通過HPA對象來尋找真實的scaleTargetRef，從而讓CronHPA感知HPA的當前狀態。CronHPA不會直接調整Deployment的副本數目，而是通過HPA來操作Deployment，這樣可以避免HPA和CronHPA的沖突問題。關于CronHPA兼容HPA的更多信息，請參見容器定時伸縮（CronHPA）。
如何解決HPA啟動時CPU或內存飆高造成擴容出多余Pod的多彈現象？
對于Java等需要預熱的語言與框架而言，在容器剛啟動的時候，有可能會出現分鐘級別的CPU、內存飆高，其可能會造成HPA的誤觸發。您可以通過升級ACK提供的最新版metrics-server組件，并在Pod的Annotation上增加開關防止誤觸發。關于如何升級metrics-server組件，請參見升級Kubernetes集群的metrics-server組件。
增加開關防止誤觸發部署示例YAML如下。
## 以Deployment為例
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-basic
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
annotations:
HPAScaleUpDelay: 3m # m代表分鐘，表示HPA在Pod創建3分鐘后開始生效，可選單位為[s(秒),m(分)]。
spec:
containers:
- name: nginx
image: nginx:1.7.9 # Replace it with your exactly <image_name:tags>.
ports:
- containerPort: 80 常見問題
為什么節點自動伸縮組件無法彈出節點？
請檢查是否存在如下幾種場景：
配置伸縮組的實例類型無法滿足Pod的資源申請（Request）。ECS實例規格給出的資源大小是實例的售賣規格，實際運行時請考慮以下資源預留。
在創建實例的過程中因為虛擬化、OS占用掉一部分。詳細信息，請參見購買實例后查看內存大小，為什么和購買時的實例規格定義不一致？。
需要占用一定的節點資源來運行相關組件（例如kubelet、kube-proxy、Terway、Container Runtime等）。詳細信息，請參見節點資源預留策略。
默認節點會安裝系統組件，Pod的申請資源要小于實例的規格。
對可用區有約束的Pod，無法觸發配置了多可用區的節點池擴容。
是否完整按照步驟執行了授權操作。授權操作是集群維度的，需要每個集群操作一次。關于授權，請參見彈性伸縮FAQ。
開啟自動伸縮的節點池中出現如下異常情況。
實例未加入到集群且超時。
節點未ready且超時。
為保證后續擴縮準確性，彈性組件以阻尼方式處理異常情況，在處理完異常情況節點前，不進行擴縮容。
為什么節點自動伸縮組件無法縮容節點？
請檢查是否存在如下幾種場景：
節點Pod的資源申請（Request）閾值高于設置的縮容閾值。
節點上運行kube-system命名空間的Pod。
節點上的Pod包含強制的調度策略，導致其他節點無法運行此Pod。
節點上的Pod擁有PodDisruptionBudget，且到達了PodDisruptionBudget的最小值。
您可以在開源社區得到更多關于節點自動伸縮組件的常見問題與解答。
多個伸縮組在彈性伸縮的時候是如何被選擇的？
在Pod處在無法調度時，會觸發彈性伸縮組件的模擬調度邏輯，會根據伸縮組配置的標簽和污點以及實例規格等信息進行判斷。當配置的伸縮組可以模擬調度Pod的時候，就會被選擇進行節點彈出。當同時有多個伸縮組滿足模擬調度條件的時候，默認采用的是最少浪費原則，即根據模擬彈出后節點上剩余的資源最小為原則進行抉擇。
什么類型的Pod可以阻止CA移除節點？
cluster-autoscaler使用了哪些調度策略來判斷不可調度Pod能否調度到開啟自動伸縮節點池？
使用的調度策略如下所示。
如果您的業務場景中有自動伸縮需求的Pod依賴的調度策略超出以下策略，請通過聆聽平臺提需求，待支持后再使用，否則可能導致誤彈。
PodFitsResources
GeneralPredicates
PodToleratesNodeTaints
MaxGCEPDVolumeCount
NoDiskConflict
CheckNodeCondition
CheckNodeDiskPressure
CheckNodeMemoryPressure
CheckNodePIDPressure
CheckVolumeBinding
MaxAzureDiskVolumeCount
MaxEBSVolumeCount
ready
MatchInterPodAffinity
NoVolumeZoneConflict
基于阿里云組件指標的容器水平伸縮常見問題
問：如果執行
kubectl get hpa后發現target一欄為<unknow>怎么辦？答：請按照以下操作解決。
執行
kubectl describe hpa <hpa_name>，確認HPA失效的原因。如果Conditions字段提示AbleToScale為False，請確認Deployment是否正常部署。
如果Conditions字段提示ScalingActive為False，請繼續下一步。
執行
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/"。如果返回為Error from server (NotFound): the server could not find the requested resource，請確認alibaba-cloud-metrics-adapter的啟動狀態。如果確認alibaba-cloud-metrics-adapter狀態正常，請確認HPA指標是否是Ingress相關指標。如果是Ingress相關指標，您需要提前部署日志服務組件。更多信息，請參見Nginx Ingress訪問日志分析與監控。
確認HPA指標填寫正確。sls.ingress.route的值格式為
<namespace>-<svc>-<port>。namespace為Ingress所在的命名空間。
svc是Ingress對應的Service名稱。
port是Ingress對應Service的端口名稱。
問：如何查找HPA支持的指標名稱？
答：請參見阿里云HPA指標， 以下列舉為常用指標。
指標名稱
描述
附加參數
sls_ingress_qps
指定的IngressRoute每秒查詢率
sls.ingress.route
sls_alb_ingress_qps
ALB數據的IngressRoute每秒查詢率
sls.ingress.route
sls_ingress_latency_avg
所有請求的延遲
sls.ingress.route
sls_ingress_latency_p50
50%請求的延遲
sls.ingress.route
sls_ingress_latency_p95
95%請求的延遲
sls.ingress.route
sls_ingress_latency_p99
99%請求的延遲
sls.ingress.route
sls_ingress_latency_p9999
99.99%請求的延遲
sls.ingress.route
sls_ingress_inflow
Ingress的流入帶寬
sls.ingress.route
問：當用戶自定義了Nginx Ingress日志格式，如何進行適配操作？
答：本文介紹的使用SLS Ingress指標進行容器水平伸縮，需要您開啟并正確配置集群中Nginx Ingress日志接入阿里云日志服務。
在創建集群時，日志服務是默認開啟的。當您保持默認值不變，集群創建成功后，您可以在阿里云日志服務SLS控制臺查看Nginx Ingress的訪問日志分析報表和監控Nginx Ingress實時狀態。
在創建集群時，若您手動關閉了日志服務，集群創建完成后，如果想要使用SLS Ingress指標進行容器水平伸縮，您需要重新開啟或配置日志服務。詳細信息，請參見Nginx Ingress訪問日志分析與監控。
當您需要自定義Nginx Ingress日志格式時，由于集群中初次開啟日志服務部署AliyunLogConfig的CRD只針對ACK默認Ingress Controller中的日志格式生效，若您修改過Ingress Controller的訪問日志格式，請修改CRD配置中的正則表達式提取
processor_regex部分。具體操作，請參見通過DaemonSet-CRD方式采集容器日志。
為什么Pod無法調度到節點自動伸縮組件彈出節點？
受底層資源占用計算精度約束，自動伸縮組件估算的節點可調度資源可能大于實際節點的可調度資源。關于底層資源占用計算精度約束的更多信息，請參見購買實例后查看內存大小，為什么和購買時的實例規格定義不一致？。當Pod資源申請占用較大時（建議超過節點資源70%時），需要用戶使用彈性前Pod確認是否可調度到同實例規格的節點。
彈性組件在判斷節點的資源是否滿足時，僅考慮Pending Pods和Daemonset Pods的資源，如果節點上有非Daemonset的Static Pods，請您預先為此類Pod預留資源。
如何通過指定Pod控制節點被Cluster Autoscaler縮容？
您可以指定Pod阻止或不阻止節點被Cluster Autoscaler縮容。
阻止節點被Cluster Autoscaler縮容：為Pod添加Annotation
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"。不阻止節點被Cluster Autoscaler縮容：為Pod添加Annotation
"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"。
如何啟用或禁用特定DaemonSet的驅逐？
Cluster Autoscaler會根據是否開啟daemonset pod排水配置（如下圖所示）決定是否逐出DaemonSet Pods，這些配置是集群維度的，對集群中的DaemonSet Pods通用。如果想要對某個DaemonSet Pod指定是否需要被驅逐，可以對這個DaemonSet Pod添加Annotation"cluster-autoscaler.kubernetes.io/enable-ds-eviction"："true"。
類似的，DaemonSet Pod的Annotation中如果有"cluster-autoscaler.kubernetes.io/enable-ds-eviction"："false"，則會顯示禁止Cluster Autoscaler驅逐這個DaemonSet Pod。
如果未開啟DaemonSet Pod排水，此Annotation僅對非空節點的DaemonSet Pods有效。如果想開啟空節點DaemonSet Pods，需要先開啟DaemonSet Pod排水。
此Annotation需要在DaemonSet Pod上指定，而不是DaemonSet對象本身。
此Annotation對不屬于任何DaemonSet的Pod沒有影響。
默認情況下，Cluster Autoscaler對DaemonSet Pod驅逐是非阻塞模式的，即不等待DaemonSet Pod驅逐掉，就會執行后續流程。如需要Cluster Autoscaler等待指定DaemonSet Pod驅逐掉后，再執行后續縮容流程，除以上啟用配置外，請為相應Pod添加Annotation "cluster-autoscaler.kubernetes.io/wait-until-evicted":"true"。
為什么HPA審計日志數值未達閾值但擴縮了？
問題原因
Pod水平自動擴縮控制器根據當前指標和期望指標來計算擴縮比例，期望副本數 = ceil（當前副本數 × （當前指標 / 期望指標））。
從這個公式可以看出，期望副本數的準確度，是由當前副本數、當前指標和期望指標的準確度來保證的。以HPA中應用廣泛的資源指標為例，HPA獲取當前副本數時，是先獲取scaleTargetRef所定義的對象的scale子資源（subResources），然后將scale的status的Selector的值轉化為labelselecor，以此作為條件去匹配獲取Pod的。如果某個時刻，用這個條件獲取到的Pod并不完全屬于scaleTargetRef中定義的對象，那以此計算出的期望副本數就很可能不符合預期（比如實時指標低于閾值卻擴容了）。
常見可能導致匹配Pod數目不準確的原因：
滾動發布。
給其他不屬于scaleTargetRef中對象的Pod打標了相同Label。
解決方案
針對滾動發布。解決方案，請參見為何HPA在滾動發布時出現擴容多余Pod？。
針對給其他不屬于scaleTargetRef中對象的Pod打標了相同Label。定位出這類Pod，如果還需要使用則更換為不同Label，如果不再需要，執行如下命令刪除即可。
kubectl get pods -n {命名空間名字} -l {scale子資源的status.Selector的值}
如何指定節點不被cluster-autoscaler縮容？
為目標節點配置Node Annotation "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"，使其不被cluster-autoscaler縮容。添加Annotation的命令示例如下。
kubectlannotatenode<nodename>cluster-autoscaler.kubernetes.io/scale-down-disabled=true如何延遲cluster-autoscaler對不可調度Pod的擴容反應時間？
可以通過cluster-autoscaler.kubernetes.io/pod-scale-up-delay注釋為每個Pod設置延遲擴容時間。 如果K8s沒有在該延遲結束時調度它們，那么CA可能會考慮對它們進行擴展。注釋示例如下：“cluster-autoscaler.kubernetes.io/pod-scale-up-delay”：“600s”。
開啟彈性的節點池如何配置自定義資源？
通過為開啟彈性的節點池配置如下固定前綴的ECS標簽（Tag），可以讓彈性組件識別到已開啟彈性的節點池中可供給的自定義資源，或者識別到指定的某些資源的精確值。
k8s.io/cluster-autoscaler/node-template/resource/{資源名}:{資源大小}示例
k8s.io/cluster-autoscaler/node-template/resource/hugepages-1Gi:2Gi哪些操作會觸發Cluster Autoscaler自動更新？
為保證Cluster Autoscaler配置實時性、版本與集群的兼容性，以下操作會觸發Cluster Autoscaler自動更新：
更新自動伸縮配置
創建、刪除、更新開啟彈性節點池
成功升級集群
如果一個伸縮組內配置了多資源類型的實例規格，彈性伸縮時如何計算這個伸縮組的資源呢？
對于配置了多個實例規格的伸縮組，彈性伸縮組件以資源維度在各個實例規格中取最小值，作為資源計算的基準。
例如，如果一個伸縮組內配置了兩種實例規格，一個是CPU 4核內存32 GB，另一個是CPU 8核內存16 GB。彈性伸縮組件認為這個伸縮組能保證的擴容出的CPU是4核內存16 GB的實例資源。因此如果狀態為pending的Pods的requests資源超出4核或者16 GB，則不會進行擴容。
配置了多實例規格依然需要考慮資源預留，詳見為什么節點自動伸縮組件無法彈出節點？。