本文介绍容器服务ACK弹性伸缩的常见问题及解决办法。
当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所对应的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如果非上述问题，请参见相关文档metric-server的问题诊断部分。
- 原因二：滚动发布或者扩容时无法获取数据。
默认metrics-server的采集周期是1秒。刚扩容或更新完成后，metric-server会有一段时间无法获取监控数据。请于扩容或更新后2秒左右进行查看。
- 原因三：缺少
request 字段设置。HPA默认是通过
usage/request作为利用率的数值，因此可以检查Pod的Resource字段中是否包含Request字段。
社区的Controller Manager会在滚动发布的时候，对于没有监控数据的Pod，进行监控数据的补零操作，从而有一定的概率出现扩容出多余的Pod现象（多弹现象）。您可以通过升级ACK提供的最新版Metrics Server，并在Metrics Server的启动参数上开启开关防止多弹。
##在Metrics Server的启动参数中加入以下选项。 --enable-hpa-rolling-update-skipped=true
HPA的扩缩容的触发条件不是严格超过阈值与地域阈值，需要额外考虑的是如果扩容或者缩容后，是否会再次触发缩容或者扩容，减少震荡的场景。
对版本号大于v0.2.1-b46d98c-aliyun的metric-server启动参数设置
--metric-resolution，例如--metric-resolution=15s即可。
当CPU扩容后，Memory会触发缩容，建议配置到一个HPA中。
当两个metrics触发弹性的个数不同的时候，会根据稳定性第一的原则，优先弹出更多的副本或者在缩容时保留更多的副本。