Container Service for Kubernetes:ワークロードスケーリングのよくある質問

HPA モニタリングデータの current フィールドが unknown と表示される場合、kube-controller-manager がモニタリングデータソースにアクセスして必要なデータを取得できないことを意味します。その結果、HPA のスケーリングは失敗します。

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 コマンドを実行してデータが返されるか確認します。どの Pod からもデータが返されない場合は、kubectl get apiservice を実行して、リソースメトリックを提供するデータソースのステータスを確認します。以下は出力例です。

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

apiVersion: apiregistration.k8s.io/v1
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 コンポーネントがインストールされていることを確認します。詳細については、「metrics-server」をご参照ください。

原因 2：ローリングデプロイまたはスケールアウト中にデータが取得できない

metrics-server のデフォルトのデータ収集期間は 1 分です。スケールアウトまたはアップデート後、短時間の間は metrics-server がモニタリングデータを取得できません。スケールアウトまたはアップデートから約 2 分後にもう一度確認してください。

原因 3：request フィールドが設定されていない

デフォルトでは、HPA は数式 実使用量/リクエスト を使用して使用率を計算します。Pod の resource フィールドに request フィールドが含まれているか確認してください。

原因 4：メトリック名が正しくない

大文字小文字を含め、メトリック名が正しいか確認してください。例えば、HPA がサポートするメトリック cpu を CPU と誤って入力した場合、モニタリングデータの current フィールドは unknown と表示されます。

ローリングデプロイ中、コミュニティの Controller Manager はデータのない Pod のモニタリングデータにゼロを埋め込みます。これにより、HPA が余分な Pod をスケールアウトさせることがあり、これはスケーリングジッターとして知られる問題です。この問題を回避するには、以下の構成を使用します。

クラスターレベルの構成

# metrics-server の起動パラメーターに以下のオプションを追加します。
--enable-hpa-rolling-update-skipped=true  

ワークロードレベルの構成

特定のワークロードに対してのみスケーリングジッターを防ぎたい場合は、以下の 2 つの方法のいずれかを使用できます。

• 方法 1：指定されたワークロードのテンプレートに以下のアノテーションを追加して、ローリングデプロイ中に HPA の評価を一時的に停止します。

  # このアノテーションをワークロードの spec.template.metadata.annotations に追加して、ローリングデプロイ中に HPA の評価を一時的に停止します。
  HPARollingUpdateSkipped: "true"

  サンプルコードを表示

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment-basic
    labels:
      app: nginx
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: nginx
    template: 
      metadata:
        labels:
          app: nginx
        annotations:
          HPARollingUpdateSkipped: "true"  # ローリングデプロイ中に HPA の効果をスキップします。
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
          - containerPort: 80

• 方法 2：指定されたワークロードのテンプレートに以下のアノテーションを追加して、アプリケーションのデプロイ開始時に指定された起動期間をスキップします。

  # このアノテーションをワークロードの spec.template.metadata.annotations に追加して、アプリケーションのデプロイ開始時に指定された起動期間をスキップします。
  HPAScaleUpDelay: 3m # 3m は一例です。必要に応じて期間を設定してください。

  サンプルコードを表示

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: nginx-deployment-basic
    labels:
      app: nginx
  spec:
    replicas: 2
    selector:
      matchLabels:
        app: nginx
    template: 
      metadata:
        labels:
          app: nginx
        annotations:
          HPAScaleUpDelay: 3m  # m は分を表します。これは、Pod が作成されてから 3 分後に HPA が有効になることを意味します。有効な単位は [s (秒), m (分)] です。
      spec:
        containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
          - containerPort: 80

以下は、誤ったトリガーを防ぐためのアノテーションを含むデプロイメントのサンプル YAML ファイルです。

## デプロイメントの例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-basic
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        HPAScaleUpDelay: 3m # m は分を表します。これは、Pod が作成されてから 3 分後に HPA が有効になることを意味します。有効な単位は [s (秒), m (分)] です。
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9 # ご利用の正確な <image_name:tags> に置き換えてください。
        ports:
        - containerPort: 80 

一致する Pod の数が不正確になる一般的な理由には、次のようなものがあります。

• ローリングデプロイ。

• scaleTargetRef のオブジェクトに属さない Pod に同じラベルが適用されている。次のコマンドを実行して、このラベルを持つ他の Pod が存在するかどうかを判断できます。

  kubectl get pods -n {namespace_name} -l {value_of_status.Selector_for_scale_subresource}