调试集群自动缩放器

查看用于调试群集自动升级程序的选项，找出故障的根本原因。

步骤 1：检查版本

验证集群自动缩放器附加组件是否已安装并就绪。

ibmcloud oc cluster addon ls --cluster <CLUSTER_NAME>

示例输出

Name                 Version   Health State   Health Status   
cluster-autoscaler   1.0.4     normal         Addon Ready

将集群中运行的版本与集群自动缩放器附加组件更改日志中的最新版本进行比较。
如果您的版本已过时，请将最新的集群自动缩放器版本部署到集群。

步骤 2: 检查配置

请检查是否正确配置了集群自动缩放器。

获取集群自动缩放器 ConfigMap的 YAML 配置文件。

kubectl get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml

在 data.workerPoolsConfig.json 字段中，检查是否使用每个工作程序池的最小和最大大小启用了正确的工作程序池。
- "name": "<worker_pool_name>": ConfigMap 中工作程序池的名称必须与集群中工作程序池的名称完全相同。多个工作程序池必须以逗号分隔。要检查集群工作程序池的名称，请运行 ibmcloud ks worker-pool ls -c <cluster_name_or_ID>。
- "minSize": 2: 通常，minSize 必须是 2 或更大的值。请记住，minSize 值不能为 0，并且只有在禁用公共 ALB 时才能具有 minSize 值 1。
- "maxSize": 3: maxSize 必须等于或大于 minSize。
- "enabled": true: 将值设置为 true 以启用自动缩放工作程序池。
```
data:
    workerPoolsConfig.json: |
        [{"name": "default", "minSize": 2, "maxSize": 3, "enabled": true }]
```

在 metadata.annotations.workerPoolsConfigStatus 字段中，检查 FAILED CODE 错误消息。遵循错误消息中的任何恢复步骤。例如，您可能会收到类似于以下的消息，在此消息中，您必须对集群所在的资源组具有正确的许可权。

annotations:
    workerPoolsConfigStatus: '{"1:3:default":"FAILED CODE: 400
    ...
    \"description\":\"Unable
    to validate the request with resource group manager.\",\"type\":\"Authentication\\"recoveryCLI\":\"To
    list available resource groups, run ''ibmcloud resource groups''. Make sure
    that your cluster and the other IBM Cloud resources that you are trying to use
    are in the same resource group. Verify that you have permissions to work with
    the resource group. If you think that the resource group is set up correctly
    and you still can't use it, contact IBM Cloud support.\"}"}'

步骤 3: 查看集群自动缩放器状态

查看集群自动缩放器的状态。

kubectl describe cm -n kube-system cluster-autoscaler-status

status: 查看状态消息以获取更多故障诊断信息 (如果有)。
Health: 查看集群自动缩放器的总体运行状况，以了解是否存在任何错误或故障。
ScaleUp: 查看向上扩展活动的状态。通常，如果已就绪且已注册的工作程序节点数匹配，那么向上扩展将具有 NoActivity，因为工作程序池具有足够的工作程序节点。
ScaleDown: 查看缩减活动的状态。如果集群自动缩放器标识 NoCandidates，那么不会缩减工作程序池，因为无法除去任何工作程序节点，而不会从工作负载中获取请求的资源。
Events: 查看事件以获取更多故障诊断信息 (如果有)。

正常集群自动缩放器状态的示例

Data
====
status:
----
Cluster-autoscaler status at 2020-02-04 19:51:50.326683568 +0000 UTC:
Cluster-wide:
Health:      Healthy (ready=2 unready=0 notStarted=0 longNotStarted=0 registered=2longUnregistered=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleUp:     NoActivity (ready=2 registered=2)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
ScaleDown:   NoCandidates (candidates=0)
            LastProbeTime:      2020-02-04 19:51:50.324437686 +0000 UTC m=+9022588.836540262
            LastTransitionTime: 2019-10-23 09:36:25.741087445 +0000 UTC m=+64.253190008
Events:  none

步骤 4: 检查集群自动缩放器 pod

检查集群自动缩放器 pod 的运行状况。

获取群集自动分隔器 pod。如果状态不是运行， 请描述 pod。
```
kubectl get pods -n kube-system | grep ibm-iks-cluster-autoscaler
```
描述集群自动缩放器 pod。查看事件部分以获取更多故障诊断信息。
```
kubectl describe pod -n kube-system <pod_name>
```

查看命令部分以检查定制集群自动缩放器配置是否与您期望的值 (例如 scale-down-delay-after-add 值) 匹配。

Command:
    ./cluster-autoscaler
    --v=4
    --balance-similar-node-groups=true
    --alsologtostderr=true
    --stderrthreshold=info
    --cloud-provider=IKS
    --skip-nodes-with-local-storage=true
    --skip-nodes-with-system-pods=true
    --scale-down-unneeded-time=10m
    --scale-down-delay-after-add=10m
    --scale-down-delay-after-delete=10m
    --scale-down-utilization-threshold=0.5
    --scan-interval=1m
    --expander=random
    --leader-elect=false
    --max-node-provision-time=120m

步骤 5: 搜索 pod 日志

在集群自动缩放器 pod 的日志中搜索相关消息，例如 lastScaleDownFailTime，Final scale-up plan 或集群自动缩放器事件之类的故障消息。

如果您的群集 autoscaler pod 不健康，无法流式传输日志，请检查 IBM Cloud Logs 实例中的 pod 日志。请注意，如果您的集群管理员没有为您的集群启用 IBM Cloud Logs，您可能没有任何日志可供查看。

kubectl logs -n kube-system <pod_name> -c ibm-iks-cluster-autoscaler > logs.txt

步骤 6：重新启动 pod

如果找不到任何故障或错误消息，并且已启用日志记录，请重新启动集群自动缩放器 pod。部署将重新创建 pod。

kubectl delete pod -n kube-system <pod_name>

步骤 6: 禁用并重新启用

可选: 如果已完成调试步骤，并且集群仍未缩放，那么可以通过编辑配置映射来禁用和重新启用自动缩放器。

编辑 iks-ca-configmap。

kubectl edit cm iks-ca-configmap -n kube-system

示例输出：

apiVersion: v1
data:
workerPoolsConfig.json: |
    [{"name": "default", "minSize": 2, "maxSize": 5, "enabled": true }]
kind: ConfigMap
metadata:
annotations:
    workerPoolsConfigStatus: '{"2:5:default":"SUCCESS"}'
creationTimestamp: "2020-03-24T17:44:35Z"
name: iks-ca-configmap
namespace: kube-system
resourceVersion: "40964517"
selfLink: /api/v1/namespaces/kube-system/configmaps/iks-ca-configmap
uid: 11a1111a-aaaa-1a11-aaa1-aa1aaaa11111

将 enabled 参数设置为 false 并保存更改。
再次编辑 iks-ca-configmap。将 enabled 参数设置为 true 并保存更改。
```
kubectl edit cm iks-ca-configmap -n kube-system
```
如果在禁用并重新启用集群自动缩放器后集群仍未缩放，那么可以在 iks-ca-configmap 中编辑 minSize 或 maxSize 参数。有时，编辑 minSize 和 maxSize 工作程序参数会成功重新启动集群自动缩放器。
```
kubectl edit cm iks-ca-configmap -n kube-system
```
编辑 minSize 或 maxSize 参数并保存更改。

步骤 7：检查问题是否已解决

监视集群中的集群自动缩放器活动，以查看问题是否已解决。如果您仍迂到问题，请参阅反馈，问题和支持。