本文介绍容器服务ACK弹性伸缩的常见问题及解决办法。
问题一：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秒。刚扩容或更新完成后，metric-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的metric-server启动参数设置--metric-resolution，例如--metric-resolution=15s即可。
问题五：两个HPA，一个设置CPU规则，一个设置Memorey规则。当CPU扩容后，Memory会触发缩容吗？
当CPU扩容后，Memory会触发缩容，建议配置到一个HPA中。
问题六：当CPU规则和Memory规则配置在同一个HPA时，这时需要同时满足CPU规则和Memory规则，还是只需要满足一个规则就会扩容？
当两个metrics触发弹性的个数不同的时候，会根据稳定性第一的原则，优先弹出更多的副本或者在缩容时保留更多的副本。