クラスター自動スケーリング機能のデバッグ

クラスター自動スケーリング機能をデバッグして障害の根本原因を見つけるために取り得る方法について説明します。

ステップ 1: バージョンの確認

クラスタ・オートスケーラー・アドオンがインストールされ、使用可能な状態になっていることを確認してください。

ibmcloud oc cluster addon ls --cluster CLUSTER_NAME

出力例

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

クラスターで実行されているバージョンを、クラスター自動スケーリング機能アドオンの変更ログの最新バージョンと比較します。
ご使用のバージョンが古い場合は、最新のクラスター自動スケーリング機能のバージョンをクラスターにデプロイします。

ステップ 2: 構成の確認

クラスター自動スケーリング機能が正しく構成されていることを確認します。

クラスター自動スケーリング機能の構成マップの YAML 構成ファイルを取得します。
```
oc get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml
```
data.workerPoolsConfig.json フィールドで、ワーカー・プールごとの最大サイズと最小サイズを指定して、正しいワーカー・プールが有効にされていることを確認します。
- "name": "<worker_pool_name>": 構成マップ内のワーカー・プールの名前は、クラスター内のワーカー・プールの名前とまったく同じでなければなりません。複数のワーカー・プールはコンマで区切る必要があります。クラスター・ワーカー・プールの名前を確認するには、ibmcloud oc worker-pool ls -c <cluster_name_or_ID> を実行します。
- "minSize": 2: 一般に、minSize は 2 以上でなければなりません。
- "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: クラスター自動スケーリング機能の状況を確認する

クラスター自動スケーリング機能の状況を確認します。

oc 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: クラスター自動スケーリング機能のポッドを確認する

クラスター自動スケーリング機能のポッドの正常性を確認します。

クラスター自動スケーリング機能のポッドを表示します。状況が「Running」でない場合は、そのポッドの詳細を表示します。
```
oc get pods -n kube-system | grep ibm-iks-cluster-autoscaler
```
クラスター自動スケーリング機能のポッドの詳細を表示します。「Events」セクションに、詳しいトラブルシューティング情報がないか確認します。
```
oc describe pod -n kube-system <pod_name>
```

**「Command」**セクションを参照して、クラスター自動スケーリング機能のカスタム構成 (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: ポッドのログを検索する

クラスターオートスケーラーのポッドのログを検索し、「 lastScaleDownFailTime 」や「 Final scale-up plan 」といった障害メッセージ、あるいはクラスターオートスケーラーのイベントなど、関連するメッセージを探してください。

クラスタのオートスケーラーのポッドが正常な状態ではなく、ログをストリーミングできない場合は、 IBM Cloud Logs インスタンスでポッドのログを確認してください。クラスター管理者がクラスターの IBM Cloud Logs を有効にしていない場合は、参照できるログが存在しない可能性があります。

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

手順 6: ポッドを再起動する

障害またはエラー・メッセージが見つからず、既にロギングを有効にしている場合は、クラスター自動スケーリング機能ポッドを再始動します。デプロイメントによってポッドが再作成されます。

oc delete pod -n kube-system <pod_name>

ステップ 6: 無効にしてからもう一度有効にする

オプション: デバッグ手順を実行してもクラスターがスケーリングされない場合は、構成マップを編集して、自動スケーリング機能を無効にしてからもう一度有効にします。

iks-ca-configmap を編集します。

oc 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 に設定し、変更を保存します。
```
oc edit cm iks-ca-configmap -n kube-system
```
クラスターの自動スケーリング機能を無効にしてからもう一度有効にしても、クラスターがスケーリングされない場合は、minSize の maxSize パラメーターまたは iks-ca-configmap パラメーターを編集します。場合によっては、minSize および maxSize ワーカー・パラメーターを編集すると、クラスター自動スケーリング機能が正常に再始動されます。
```
oc edit cm iks-ca-configmap -n kube-system
```
minSize パラメーターまたは maxSize パラメーターを編集し、変更を保存します。

手順 7：問題が解決したかどうかを確認する

クラスター内のクラスター自動スケーリング機能のアクティビティーをモニターして、問題が解決されたかどうかを確認します。まだ問題が発生する場合は、フィードバック、質問、およびサポートを参照してください。