クラスター自動スケーリング機能のデバッグ
クラスター自動スケーリング機能をデバッグして障害の根本原因を見つけるために取り得る方法について説明します。
始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
ステップ 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 構成ファイルを取得します。
kubectl get cm iks-ca-configmap -n kube-system -o yaml > iks-ca-configmap.yaml -
data.workerPoolsConfig.jsonフィールドで、ワーカー・プールごとの最大サイズと最小サイズを指定して、正しいワーカー・プールが有効にされていることを確認します。"name": "<worker_pool_name>": 構成マップ内のワーカー・プールの名前は、クラスター内のワーカー・プールの名前とまったく同じでなければなりません。 複数のワーカー・プールはコンマで区切る必要があります。 クラスター・ワーカー・プールの名前を確認するには、ibmcloud ks worker-pool ls -c <cluster_name_or_ID>を実行します。"minSize": 2: 一般に、minSizeは2以上でなければなりません。minSize値に0は設定できないこと、またminSizeを 1 に設定できるのはパブリック ALB を無効にした場合に限られることに注意してください。"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: クラスター自動スケーリング機能のポッドを確認する
クラスター自動スケーリング機能のポッドの正常性を確認します。
-
クラスター自動スケーリング機能のポッドを表示します。 状況が「Running」でない場合は、そのポッドの詳細を表示します。
kubectl get pods -n kube-system | grep ibm-iks-cluster-autoscaler -
クラスター自動スケーリング機能のポッドの詳細を表示します。 「Events」セクションに、詳しいトラブルシューティング情報がないか確認します。
kubectl 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 を有効にしていない場合は、参照できるログが存在しない可能性があります。
kubectl logs -n kube-system <pod_name> > logs.txt
ステップ 5: ポッドを再始動する
障害またはエラー・メッセージが見つからず、既にロギングを有効にしている場合は、クラスター自動スケーリング機能ポッドを再始動します。 デプロイメントによってポッドが再作成されます。
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 -
クラスターの自動スケーリング機能を無効にしてからもう一度有効にしても、クラスターがスケーリングされない場合は、
minSizeのmaxSizeパラメーターまたはiks-ca-configmapパラメーターを編集します。 場合によっては、minSizeおよびmaxSizeワーカー・パラメーターを編集すると、クラスター自動スケーリング機能が正常に再始動されます。kubectl edit cm iks-ca-configmap -n kube-system -
minSizeパラメーターまたはmaxSizeパラメーターを編集し、変更を保存します。
ステップ 8: 問題が解決されたかどうかを確認する
クラスター内のクラスター自動スケーリング機能のアクティビティーをモニターして、問題が解決されたかどうかを確認します。 まだ問題が発生する場合は、フィードバック、質問、およびサポートを参照してください。