このトピックでは、ノードオートスケーリングに関するよくある質問に対する回答を提供します。
問題1: HPAがリソースメトリクスの収集に失敗した場合、どうすればよいですか。
次の返された水平ポッドオートスケーラー (HPA) 条件に示すように、FailedGetResourceMetric警告がイベントセクションで返された場合、Cloud Controller Manager (CCM) は監視対象リソースからリソースメトリクスを収集できません。
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)考えられる原因：
原因1: リソースメトリックが収集されるデータソースが利用できない。
kubectl top podコマンドを実行して、監視対象のポッドのメトリックデータが返されているかどうかを確認します。 メトリックデータが返されない場合は、kubectl get apiserviceコマンドを実行して、metrics-serverコンポーネントが使用可能かどうかを確認します。次の出力は、返されるデータの例を示します。
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 29hv1beta1.metrics.k8s.ioのSERVICEがkube-system/metrics-serverでない場合は、metrics-serverがPrometheus Operatorによって上書きされているかどうかを確認してください。 metrics-serverがPrometheus Operatorによって上書きされた場合、次のYAMLテンプレートを使用してmetrics-serverを再デプロイします。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上記のチェックを実行してもエラーが見つからない場合は、metrics-serverの関連トピックのトラブルシューティングのセクションを参照してください。
原因2: ローリング更新またはスケールアウトアクティビティ中にメトリックを収集できません。
デフォルトでは、metrics-serverは1秒間隔でメトリクスを収集します。 ただし、metrics-serverは、ローリング更新またはスケールアウトアクティビティを実行した後、メトリクスを収集するまで数秒待つ必要があります。 ローリング更新またはスケールアウトアクティビティの2秒後にメトリクスを更新することを推奨します。
原因3: リクエストフィールドがありません。
HPAは、ポッドの
使用済みリソース /要求されたリソースの値を計算することによって、CPUまたはメモリの使用率を自動的に取得します。 要求されたリソースがポッド設定で指定されていない場合、HPAはリソース使用量を計算できません。 したがって、要求フィールドがポッド構成で指定されていることを確認する必要があります。
問題2: ローリングアップデート中にHPAによって過剰な数のポッドが追加されます
ローリング更新中、kube-controller-managerは、モニタリングデータを収集できないポッドに対してゼロ充填を実行します。 これにより、HPAが過剰な数のポッドを追加する可能性があります。 metrics-serverが最新バージョンに更新されているかどうかを確認し、metrics-serverがデプロイされているポッドに次の起動設定を構成します。
# Add the following configuration to the startup settings.
--enable-hpa-rolling-update-skipped=true問題3: スケーリングしきい値に達したときにHPAがポッドをスケーリングしない場合はどうすればよいですか?
HPAのスケーリング条件は、厳密には閾値を超えるか又は下回ることに基づくものではない。 HPAは、ポッドをスケーリングするときに他の要因も考慮に入れます。 たとえば、現在のスケールアウトイベントがスケールインアクティビティをトリガーするか、スケールインイベントがスケールアウトアクティビティをトリガーするかを確認します。 これにより、スケーリングの繰り返しを回避し、不要なリソース消費を防ぎます。
問題4: HPAのデータ収集間隔を設定するにはどうすればよいですか?
メトリクスサーバーのバージョンが0.2.1 b46d98c-aliyun以降の場合は、スタートアップ設定で -- metric-resolutionパラメーターを指定します。 例: -- metric-resolution=15s
問題5: CPU HPAとメモリHPAを設定しました。 CPU HPAがスケールアウトアクティビティをトリガーした後、メモリHPAはスケールインアクティビティをトリガーできますか?
はい、できます。 CPU HPAがスケールアウトアクティビティをトリガした後、メモリHPAはスケールインアクティビティをトリガする。 同じHPAを使用してCPUとメモリの使用率を監視することを推奨します。
問題6: 同じHPAを使用してCPUとメモリの使用率を監視する場合、CPU使用率とメモリ使用率の両方がしきい値を超えてスケールアウトアクティビティをトリガーする必要がありますか?
CPU使用率とメモリ使用率に基づいてスケールアウトするポッドの数は異なる場合があります。 ワークロードの安定性を保証するために、システムは、CPU使用率とメモリ使用率の両方がスケールアウト活動をトリガするときに、より多くのポッドを追加するスケールイン活動を実行することが好ましい。 同じルールがスケールインアクティビティにも適用されます。 システムは、CPU使用およびメモリ使用の両方がスケールインアクティビティをトリガするときに、より多くのポッドを予約するスケールインアクティビティを実行することが好ましい。