Oracle Cloud Hangout Cafe Season 4 #5「Kubernetesのオートスケーリング」(2021年8月4日開催)
2024年5月29日(水)
第2弾の連載第6回では、2021年8月4日に開催された「Oracle Cloud Hangout Cafe Season4 #5『Kubernetesのオートスケーリング』」の発表内容に基づいて紹介していきます。
PodやContainerのCPUやメモリ利用率以外でのスケール
ここまでの例では、PodのCPUやメモリの利用状況でのスケールでしたが、他にも4つのメトリクスを利用できます*2。
種別 | メトリクス | 収集元 | スケールロジック |
---|---|---|---|
Resource | CPU利用率 メモリ利用率 |
metrics-serverがkubeletから取得した値 | PodのCPU/メモリ利用率で評価 |
ContainerResource | CPU利用率 メモリ利用率 |
metrics-serverがkubeletから取得した値 | ContainerのCPU/メモリ利用率で評価 |
Pods | Podの任意のメトリクス | API Aggregation Layerから取得した任意のエンドポイント | 値での評価(≠率) |
Object | 任意のメトリクス(Pod/Container以外のKubernetesオブジェクト) | API Aggregation Layerから取得した任意のエンドポイント | 単一の値と目標値の比較 |
External | 任意のメトリクス(Kubernetesオブジェクト以外) | API Aggregation Layerから取得した任意のエンドポイント | 単一の値と目標値の比較 |
ここで登場したAPI Aggregation Layer
について補足します。API Aggregation Layerとは、広く利用されているOperatorを利用したCRD(カスタムリソース)での拡張とは異なる手法でkube-apiserverに新しい種類のオブジェクトを認識させる仕組みです。kube-apiserverのフラグでAggregation Layerを有効に設定する必要があり、拡張APIサーバとなるPodを実行し、APIServiceオブジェクトを登録することで利用できます。
CRD(カスタムリソース)よりも詳細なAPIを定義でき、apiserver-builder(OperatorでのKubebuilder相当)を利用して実装できます。
PodもしくはContainerのCPU/メモリ利用率以外をスケール時のメトリクスとして利用する場合はmetrics serverを利用しないため、下図のような処理フローになります。
PodやContainerのCPUやメモリ利用率以外でのスケールでのHPAリソース定義例を示します。
*2: セッション当時はHPAリソースをapiVersion: autoscaling/v2beta2として解説しましたが、この記事では最新のapiVersion: autoscaling/v2を用います。そのため、セッション資料とは異なるフィールドや値が存在します・type:Podsの場合
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 metrics: - type: Pods pods: metric: name: packets-per-second target: type: AverageValue averageValue: 1k
.spec.metrics.metrics[].type
にPodsを指定すると、任意のPodメトリクスをスケール条件に利用できます。例えば、上記のケースではpackets-per-second
というメトリクスの平均値が1000になるようにレプリカ数が調整されます。任意のPodのメトリクスを利用する場合は平均値
(≠率
)での判定になります。
・type:Objectの場合
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 metrics: - type: Object object: metric: name: requests-per-second describedObject: apiVersion: networking.k8s.io/v1 kind: Ingress name: main-route target: type: Value value: 2k
.spec.metrics.metrics[].type
にObjectを指定すると、同一Namespace内のPod以外の任意のメトリクスをスケール条件に利用できます。例えば、上記のケースではmain-route
という名前のIngressリソースにおけるrequests-per-second
というメトリクスの値が2000になるようにレプリカ数が調整されます。Pod以外の任意のメトリクスを利用する場合は値か平均値
(≠率
)での判定になります。
・type:Externalの場合
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 metrics: - type: External external: metric: name: kafka_consumergroup_sum target: type: AverageValue averageValue: 30
.spec.metrics.metrics[].type
にExternalを指定すると、Kubernetesクラスタ外の任意のメトリクスをスケール条件に利用できます。例えば、上記のケースではkafka_consumergroup_sum
というメトリクスの平均値が30になるようにレプリカ数を調整します。Kubernetesクラスタ外の任意のメトリクスを利用する場合は実値か平均値
(≠率
)での判定になります。
・複数のスケール条件
ここまでは、単一のスケール条件で説明をしてきましたが、HPAでは複数のスケール条件を定義できます。
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: php-apache spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 - type: Object object: metric: name: requests-per-second describedObject: apiVersion: networking.k8s.io/v1 kind: Ingress name: main-route target: type: Value value: 2k - type: Pods pods: metric: name: packets-per-second target: type: AverageValue averageValue: 1k
例えば、上記のケースでは、以下すべての条件下でのレプリカ数を算出し、最もレプリカ数が大きい結果が適用されます。
各PodのCPU使用率50%
になるレプリカ数main-route
という名前のIngressリソースにおけるrequests-per-second
というメトリクスの値が2000になるレプリカ数packets-per-second
というPodメトリクスの平均値が1000になるレプリカ数
HPAのデモ
当日のセッションでは、HPAのデモを実施しています。詳細はセッション動画をご確認ください。
連載バックナンバー
Think ITメルマガ会員登録受付中
Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。
全文検索エンジンによるおすすめ記事
- Kubernetesにおけるオートスケーリングの概要
- Podのリソース割り当ての推奨値を提案するKRR(Kubernetes Resource Recommender)
- ドメインを考慮した柔軟なPodの配置を実現する「Balancer」
- Kubernetesアプリケーションのモニタリングことはじめ
- OpenShift:アプリケーションの構成と運用
- kustomizeで復数環境のマニフェストファイルを簡単整理
- Kubernetesの基礎
- 「K8sGPT」の未来と生成AIを用いたKubernetes運用の最前線
- 「kwok」でKubernetesクラスターをシュミレーションする
- kustomizeやSecretを利用してJavaアプリケーションをデプロイする