Kubernetesのオートスケール/Kubernetes Autoscale Deep Dive

Kubernetesのオートスケーリング
Oracle Cloud Hangout Cafe 4 #5
Takuya Niita
Oracle Corporation Japan
Aug 4, 2021
Kubernetesのスケールの仕組みを抑えよう！！

View Slide

2 Copyright © 2021, Oracle and/or its affiliates.
1. スケールの復習とKubernetesにおけるスケールの概要
2. Podの⽔平スケール
3. Podの垂直スケール
4. Nodeの⽔平スケール
5. まとめ
アジェンダ
デモもやります！！

View Slide

• 仁井⽥拓也
• ⽇本オラクル株式会社
• ソリューション・アーキテクト本部
• 前職は某SIer
• Oracle歴：2年4か⽉
• Cloud Native歴：2年ちょっと
• Kubernetesもここ2年で触り始めました
• ジブリ⼤好き
• OCHaCafeは6回⽬の登壇(R:5回/P:1回)
⾃⼰紹介
Copyright © 2021, Oracle and/or its affiliates.
3
@takuya_0301

View Slide

スケールの復習とKubernetesにおけるスケールの概要
Takuya Niita
Aug 4, 2021
4
Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング

View Slide

⽔平スケール(スケールアウト)
• アプリケーションが稼働する環境の数を増や
すことによって、システムの処理能⼒を向上
させる⼿法
• 処理を並列稼働させることによるスケール
• 縮⼩させる場合は「スケールイン」
⼀般的なスケールの⼿法
5
・・・
サーバ
(BM/VM/コンテナ)
サーバ
(BM/VM/コンテナ)
垂直スケール(スケールアップ)
• アプリケーションが稼働する環境のリソース
やスペックを向上させることによって、シス
テムの処理能⼒を向上させる⼿法
• 処理を捌ける量を増やすことによるスケール
• 縮⼩させる場合は「スケールダウン」

View Slide

⽔平スケール(スケールアウト)
• Pros
• システムの可⽤性が⾼まる
• Cons
• 密結合なリソースに注意が必要
• メンテナンスが煩雑になる可能性
• ユースケース
• Webアプリケーション(Web/APサーバ)
• 科学技術計算サーバ(HPCなど)
垂直スケール(スケールアップ)
• Pros
• システム構成に変更がない
• 分散化に不向きなシステムでも対応可能
• Cons
• サーバが故障した際のリスク
• ユースケース
• データベースサーバ
• ストレージサーバ
それぞれのスケール⼿法のPros-Cons/ユースケース
6

View Slide

• Webアプリケーションなどの⼀般的なワーク
ロードに適する⽔平スケール(スケールアウト)
• データベースなどの密結合なリソースに適す
る垂直スケール(スケールアップ)
実際には・・・
7
システム全体では適材適所で
組み合わせて利用
Webサーバ
データベース
サーバ

View Slide

Podの⽔平スケール(Horizontal Pod Autoscaler)
• Podの数を増やすことによって処理性能を向上させるスケール⼿法
• CPUやメモリをはじめとして、ユーザ独⾃のメトリクスなども判断材料に利⽤可能
Podの垂直スケール(Vertical Pod Autoscaler)
• Podが利⽤可能なリソースを増強することによって処理性能を向上させるスケール⼿法
• 主にCPUとメモリを判断材料に利⽤
Nodeの⽔平スケール(Cluster Autoscaler)
• Worker Nodeの台数を増やすことによって処理性能を向上させるスケール⼿法
• Podの⽔平スケールと連携することも
Nodeの垂直スケール
• Kubernetesの機能としては未実装
• クラウドベンダーなどが提供するAPIなどを利⽤してNodeのリソース増強は可能・・・
• 現時点(2021/8)時点では、各ベンダーでComputeのスペックをオンラインで変更する仕組みはない
Kubernetesにおけるスケールの種類
8

View Slide

Podの⽔平スケール(Horizontal Pod Autoscaler)
• Podの数を増やすことによって処理性能を向上させるスケール⼿法
• CPUやメモリをはじめとして、ユーザ独⾃のメトリクスなども判断材料に利⽤可能
Podの垂直スケール(Vertical Pod Autoscaler)
• Podが利⽤可能なリソースを増強することによって処理性能を向上させるスケール⼿法
• 主にCPUとメモリを判断材料に利⽤
Nodeの⽔平スケール(Cluster Autoscaler)
• Worker Nodeの台数を増やすことによって処理性能を向上させるスケール⼿法
• Podの⽔平スケールと連携することも
Nodeの垂直スケール
• Kubernetesの機能としては未実装
• クラウドベンダーなどが提供するAPIなどを利⽤してNodeのリソース増強は可能・・・
• 現時点(2021/8)時点では、各ベンダーでComputeのスペックをオンラインで変更する仕組みはない
9
Kubernetesとして提供するスケール手法
&
本日のセッション範囲

View Slide

Podの⽔平スケール
Takuya Niita
Aug 4, 2021
10

View Slide

Horizontal Pod Autoscaler(HPA)
• コンテナアプリケーション環境(Pod)を⽔平ス
ケール(スケールアウト/イン)する仕組み
• 正確にはDeployment(ReplicaSet)のレプリカ
数をスケール
• スケール定義はHorizontalPodAutoscalerリ
ソースに
• Controller Managerのひとつである
HorizontalPodAutoscalerControllerが管理を実施
• デフォルトでは30秒間隔で周期
• HPAリソースに定義したターゲット値に近
づくようにPodの数を調整
• 基本はPodの平均CPU/メモリ使⽤率を利⽤
するが、カスタムメトリクスも利⽤可能
HPA(Horizontal Pod Autoscaler)
11
・・・
Replica数を
変更
Replica数に応
じてスケール
HorizontalPod
AutoscalerController

View Slide

HPAのスケールの仕組み(CPU/メモリ使⽤率を利⽤する場合)
12
・
・
・
HorizontalPod
metrics server
①HPAリソース取得
③メトリクス取得
⑤スケール指⽰
②メトリクス取得
④スケール量算出
⑥スケール

View Slide

(参考)metrics server
13
metrics server
• https://github.com/kubernetes-sigs/metrics-server
• 最新v0.5.0(2021/8現在)
• Kubernetesサービスによってデフォルトでインストールされている場合も別途インストールする必
要がある場合もある
• metrics server⾃体は単⼀のDeployment
• kubeletからリソースのメトリクスを収集し、api-serverのMetrics APIを利⽤して公開
• 公開されたメトリクスは”kubectl top”コマンドでも確認可能
• HPA/VPA/CAで利⽤する⽬的なので、監視サーバへのメトリクスソースとしての利⽤は禁⽌
• 利⽤する場合は、kubeletの”/metrics/resource“エンドポイントから直接収集
• metrics serverが提供する機能
• 15秒ごとにメトリクスを収集
• CPU/メモリを利⽤した⽔平スケール(HPA)
• コンテナに必要なリソースの⾃動的な調整(VPA)

View Slide

以下の計算式で必要レプリカ数を算出
• 具体例)
• Pod(現レプリカ数:5)の平均CPU使⽤率の合計が90%、ターゲットのCPU使⽤率が70%の場合
• 必要なレプリカ数＝ 5 * (90(%) / 70(%)) = 6.42・・・
• 7個のレプリカが必要(2個のレプリカが追加)
• Pod(現レプリカ数:5)の平均CPU使⽤率の合計が50%、ターゲットのCPU使⽤率が70%の場合
• 必要なレプリカ数＝ 5 * (50 (%) / 70 (%)) = 3.57・・・
• 4個のレプリカが必要(1個のレプリカを削減)
考慮事項
• ⼩数点切り上げ
• 「Podの平均CPU使⽤率」は、各Podの過去1分間のCPU使⽤率
HPAのスケールロジック(CPUを例に)
14
必要なレプリカ数 = 現在のレプリカ数 * ( Podの平均CPU使用率 / ターゲットのCPU使用率 )

View Slide

Resource Requests
• Podをデプロイする際に必要とするリソース(メモリ/CPU)を指定可能な仕組み
• Podがスケジューリングされる際にはResource Requestsに定義されたリソースを確保
• スケジューリング時にNodeにResource Requests分のリソースが空いているかをチェック
• Nodeにリソースに空きがない場合、Podの状態が“Pending”に
• PodはResource Requestsを超過してリソースを利⽤することが可能
Resource Limits
• Podが最⼤で利⽤可能なリソース(メモリ/CPU)を制限する仕組み
• 制限しない場合は無制限(Nodeの空きリソース分)にリソースを利⽤可能
• Resource Limitsを超過した場合は、それぞれ以下の挙動
• メモリ：OOM killもしくは再起動
• CPU：強制終了はされない。場合によってはCPUスロットリングが発⽣
• Nodeがもつキャパシティよりも⼤きな数値で指定することも可能
(参考)Resource RequestsとResource Limits
15
各種スケールを利用す
る場合は必ず指定！！

View Slide

(参考) QoS Class
16
QoS(Quality of Service) Class
• スケジューリングやevict(削除)される際にPodへのリソース割り当ての振る舞いを決定する仕組み
• 例えば、リソース不⾜の場合にどのコンテナをevictするかをQoS Classにより決定
• Guaranteed/BestEffort/BurstableからKubernetesが付与(.statusフィールドに存在)
項番 QoS 割当条件
1 Guaranteed(優先度⾼) CPU/メモリいずれも以下を満たす場合
• 全PodにResource RequestsとResource Limitsが指定済み
• Resource RequestsとResource Limitsの値が同⼀
2 BestEffort(優先度低) CPU/メモリいずれも以下を満たす場合
• 全PodにResource RequestsとResource Limitsが未指定
3 Burstable Guaranteed/BestEffortいずれも該当しない場合
Ex1) Resource Requestsしか設定されていない場合
Ex2) Resource RequestsとResource Limitsそれぞれの値が異なっている場合
(参考)QoS Classが同⼀の場合は、OutOfMemory (OOM) scoreをもとに決定

View Slide

HPA利用時のDeployment(Pod)側の定義
17
この部分の数値をCPU利用率100%と見る
Resource RequestsとResource Limitsの書き方
• CPU
200m=0.2(core)
• メモリ
100Mi ≒ 0.1Gi ≒ 104MB
• CPU
1(core)=1000m
• メモリ
1Gi = 1024Mi ≒ 1074MB

View Slide

HPA(Horizontal Pod Autoscaler) Manifest例(1)
18
項番項目内容
1 スケール対象スケール対象のapiVersion/kind/name
を指定。
基本的にはapiVersion: apps/v1、
kind: Deploymentを指定。
2 スケール範囲スケールする際のPodのレプリカ数の
最⼩値、最⼤値を指定。
この範囲内のスケールの振る舞いは
behaviorフィールド(次スライド)に
よって決定。
3 スケール条件と
するメトリクス
スケール条件に利⽤するメトリクス
を指定。
CPU/メモリの他にカスタムメトリク
スも指定可能。

View Slide

HPA(Horizontal Pod Autoscaler) Manifest例(2)
19
項
番
項目種別内容
4 スケール時
の振る舞い
(デフォルト)
スケール
アウト
即時スケール(リードタイム無)
以下のうち、追加レプリカ数が
多い⽅を採⽤
• 15秒で稼働中のレプリカ数
分を追加
• 15秒で4つのPodを追加
スケール
イン
リードタイム300秒(5分)
15秒で必要レプリカ数まで削減

View Slide

スケール時に指定可能な振る舞い(単⼀の場合)
• Ex)現レプリカ数:3から必要レプリカ:10までスケールアウトする場合
• type: Percent
• type: Pods
HPA(Horizontal Pod Autoscaler)におけるスケール時の振る舞い(1)
20
レプリカ数分、必要レプリカ数までスケールアウト
レプリカ(Pod)を4個(value:4)ずつスケールアウト
15秒
15秒
periodSeconds
15秒
+3
+4 +3
+4
15秒

View Slide

スケール時に指定可能な振る舞い(複数の場合)
• Ex)現レプリカ数:80から必要レプリカ:10までスケールインする場合
HPA(Horizontal Pod Autoscaler)におけるスケール時の振る舞い(2)
21
指定したtypeのうち、
多い方(Max)を採用
少ない方(Min)も指定可能
80個 72個 40個
・・・
36個
32個 10個
Percent Percent Percent
Pods
Pods
60秒 60秒
60秒
・・・スケールごとに再計算
を⾏い、”selectPolicy”
に基づいてポリシーを
選択

View Slide

種別メトリクス収集元スケールロジック
Resource CPU使⽤率
メモリ使⽤率
metrics serverがkubeletから取得
した値
PodのCPU/メモリ使⽤率を利⽤
して評価
Pods Podに関する任意のメ
トリクス
API Aggregation Layerから取得
した任意のエンドポイント
”率”ではなく、⽣値で評価を実
施
Object 任意のメトリクス
(Pod以外のk8sオブ
ジェクト)
単⼀の値で、⽬標値と⽐較を⾏
い、評価を実施
External 任意のメトリクス(k8s
オブジェクト以外)
単⼀の値で、⽬標値と⽐較を⾏
い、評価を実施
HPA Controllerが利⽤するメトリクス
22
カスタムメトリクス

View Slide

(参考)API Aggregation Layer
23
https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/
API Aggregation Layer
• カスタムリソース(CRD)とは異なり、kube-
apiserverに新しい種類のオブジェクトを認識さ
せる仕組み(kube-apiserverを拡張)
• kube-apiserverのフラグでAggregation Layerを有
効に設定することが必要
• 拡張APIの登録
• 拡張APIサーバをPodとして実⾏
• APIServiceオブジェクトを登録
• Aggregation Layerが任意のAPIエンドポイン
トへのアクセスをAPIServiceにプロキシ
• CRDよりも詳細なAPIを定義することが可能
• apiserver-builder(Controllerでいうkubebuilder)を
利⽤して実装可能

View Slide

HPAのスケールの仕組み(カスタムメトリクスを利⽤する場合)
24
・
・
・
HorizontalPod
custom metrics
(Pod)
①HPAリソース取得
③メトリクス取得
⑤スケール指⽰
②メトリクス取得
④スケール量算出
⑥スケール
custom metrics
(Object)
custom metrics
(External)
metrics serverは利用しない

View Slide

カスタムメトリクス (type:Podsの場合)
25
“type:Pods”を指定することで任意のPodメトリクスをス
ケール条件に利⽤可能
“type:Pods”の場合は、target.typeは”AverageValue”固定
対象メトリクスは”packets-per-second”
スケール条件には、平均CPU/メモリ”使⽤率”ではなく、
平均CPU/メモリ”使⽤値”(⽣の値)を利⽤

View Slide

カスタムメトリクス (type:Objectの場合)
26
“type:Object”を指定することで、同⼀Namespace
内のPod以外のk8s内の任意のメトリクスをスケー
ル条件に利⽤可能
この場合は、”main-route”というIngressを
スケール条件の対象Objectとして指定
対象メトリクスは”requests-per-second”
target.typeは”Value”または”AverageValue”

View Slide

カスタムメトリクス (type:Externalの場合)
27
“type:External”を指定することで、k8s外の任意の
メトリクスをスケール条件に利⽤可能
例えば、PrometheusでKafkaなどの「未処理のキュー
(queue=worker_tasks)」を⽰すメトリクスを収集してい
る場合、そのメトリクスをスケール判定に利⽤可能
target.typeは”Value”または”AverageValue”

View Slide

複数のメトリクス
28
HPAは各条件の積(and条件)を維持
この場合は以下の条件
• 各PodのCPU使⽤率50%
• 各Podが送信するパケットが1000パケット
• main-route Ingressのバックエンドにある全てのPodが送信す
るパケットが2000リクエスト/秒
各メトリクスの必要レプリカ数を算出し、最も多い結果を採⽤
スケールイン/スケールアウトにより、算出した最も多い結果
に対してPod数を近づける

View Slide

環境
• Oracle Container Engine for Kubernetes(OKE)：v1.20.8
• kubectl：v1.20.8
• VM.Standard.E4.Flex(1oCPU/メモリ8GB) × 5(Node)
• metrics server：v0.5.0
スケール対象のアプリケーション
• アプリケーション
• ベースイメージ：busybox
• command：’dd if=/dev/zero of=/dev/null’ # CPUを100%にするため
スケール条件
• ターゲットのCPU利⽤率：50％
• スケール範囲：最⼩1/最⼤5
HPAデモ
29
CRI-Oを使ってます!!

View Slide

Podの垂直スケール
Takuya Niita
Aug 4, 2021
30

View Slide

Vertical Pod Autoscaler(VPA)
• コンテナアプリケーション環境(Pod)を垂直ス
ケール(スケールアップ/ダウン)する仕組み
• Podに要求されるCPU/メモリを調整
(Resource Requestsを上書き)
• スケール定義はVPA(VerticalPodAutoscaler)リ
ソースとして定義
• 複数のControllerの組み合わせで管理(HPAとは
異なる)
• 主にUpdater、Admission Controller、
Recommenderが連携して動作
• 原則としてスケール時にはPodの再起動が
発⽣(Resource Requestsを適⽤させるため)
• 起動中のままのスケールは未実装
VPA(Vertical Pod Autoscaler)
31
CPU：0.5 CPU
Memory：200Mi
CPU：1.0 CPU
Memory：750Mi
Updater
Admission
Controller
Recommender

View Slide

VPA(Vertical Pod Autoscaler) Manifest例
32
項番項目内容
1 スケール対象スケール対象の
apiVersion/kind/nameを指定。
基本的にはapiVersion: apps/v1、
kind: Deploymentを指定。
2 アップデート
ポリシー
Auto、Recreate、Initial、Off
• Auto(Default):再起動によるスケール
アップ(将来的にはin-place?)
• Recreate:再起動によるスケールアッ
プ
• Initial:Pod作成時にスケールアップ
(evictしない)
• Off:スケール値の算出だけ(スケール
アップしない)

View Slide

VPA利用時のDeployment(Pod)側の定義
33
ここ部分を上書きすることで
スケールアップ！！

View Slide

Recommender
• metrics serverからPodのメトリクスを取得し、リソースの実績を判断
• Resource Requestsの推奨値(下限/⽬標値/上限)を判断
• 推奨値の算出アルゴリズムは少し複雑・・・
• kubernetes/autoscaler/vertical-pod-autoscaler/pkg/recommender/logic/estimator.goにロジックが抽象化
Updater
• RecommenderがVPAリソースに書き込んだ推奨値と動作中のPodのResource Requestsの値を⽐較
• 推奨値の範囲から外れている場合はそのPodを排除
Admission Controller
• Updaderにより排除されたPodを再作成する際にAPI ServerのPodリクエストに割り込み
• Resource Requestの値を書き換え(上書き)
VPAを実現するController群(updatePolicy:Recreateの場合)
34

View Slide

VPAのスケールの仕組み(updateMode:Auto/Recreateの場合)
35
Updater
Admission
Controller
Recommender
⑤Resource Requestsの推奨値と
現在のResource Requestsの⽐較 ⑥Podのevict
③Resource Requestsの推奨値算出
④Resource Requestsの推奨値を登録
①VPAリソースを読み込み
② Podのメトリクス取得
metrics
server
⑦ Resource Requestsの
推奨値取得 ⑧Podのspecを上書き
VPAリソース

View Slide

実は・・・
CPU/メモリ使⽤率によるHPA/VPAでは・・・
(参考) HPAとVPAの併⽤
36
CPUとメモリをスケール条件にしたHPAとVPAの併用は禁止！！
VPA
VPAによってスケールされたPodに対してHPAでのスケール
を適⽤すると、Pod毎のResource Requestsが煩雑になり、想
定通りのスケール挙動にならない可能性が⾼い
※HPAが実施された結果、オーバスケールだったり、ス
ケール不⾜になることも…

View Slide

HPA(Podの数が増減するスケール⽅式)
• Podが使⽤しているリソースとResource Requestsをもとに⽔平スケール
• スケールの範囲や振る舞いをユーザ側で定義する必要性
• アプリケーション(Pod)にかかる負荷の傾向を把握
• コスト(経済/リソース)を考慮しながらスケール範囲の⾒極め
• アプリケーションの特性や運⽤、サービス指標(SLA/SLOも含む)などを考慮し、スケールの振る舞
いを定義
VPA(Podのspec(Resource Requests)をスケール⽅式)
• Podが使⽤しているリソース(CPU/メモリ)をもとに垂直スケール
• 実際のリソース使⽤量を把握できていなくもよしなにスケール(実績値との乖離を防⽌)
• 実際にスケールさせなくても、算出された推奨値を確認するだけという利⽤⽅法も
• クラスタ全体のリソースを有効活⽤可能
• 現時点では、原則としてはPodの再起動が必要(in-placeは未実装)
ここまでのまとめ： HPAとVPA
37

View Slide

環境
• Oracle Container Engine for Kubernetes(OKE)： v1.20.8
• kubectl：v1.20.8
• VM.Standard.E4.Flex(1oCPU/メモリ8GB) × 5(Node)
スケール対象のアプリケーション
• ベースイメージ：ubuntu
• command：while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done’ # 少しだけリソース消費
VPAデモ
38

View Slide

シナリオ
• VPAの各コンポーネント(Updater/Admission Controller/Recommender)をインストール
• スケール対象のアプリケーションをデプロイ
• アプリケーションのResource Requestsの初期値を確認
• Recommenderによる推奨値算出の確認
• アプリケーション(Pod)のResource Requestsが上書きされることを確認
VPAデモ
39
HPAはDeploymentがスケール対象でした。
VPAでは、Pod⾃体がスケール対象であることを意識してデモをご覧ください！

View Slide

Nodeの⽔平スケール
Takuya Niita
Aug 4, 2021
40

View Slide

Cluster Autoscaler(CA)
• Kubernetesクラスタ内のNode数を⽔平スケール
(スケールアウト/イン)する仕組み
• 原則としてResource Requestsの値をベース
にクラスタ内のリソースの過不⾜を判断し、
Node数を増減
• IaaSに依存するため、特にクラウド・プロ
バイダに関しては仕様や利⽤⽅法に違いが
ある
• ⼀つのDeployment(Pod)によって動作
• 基本的にMaster Nodeに配置することを推奨
(Worker Nodeでも可)
• Kubernetes API Server を通してクラスタのリ
ソース使⽤状況を監視し、Node数を操作
CA(Cluster Autoscaler)
41
Cluster Autosaler Deployment
・・・
・・・
スケール指⽰
Nodeをプロビジョニング

View Slide

CA Manifest例(OKEの場合)
42
スクリプトの引数にスケール動作の挙動
を指定
重要なのは
スケール範囲(最大Node数/最小Node数)
Cluster Autoscalerを動作させる
コンポーネントはDeployment

View Slide

CA利用時のDeployment(Pod)側の定義
43
この値をベースに、各Podのリソースが既存Node
を超過した場合にスケールが発生

View Slide

CAのスケールの仕組み
44
Cluster Autosaler Deployment
metrics server
・
・
・
スケジュール
できないPod
①メトリクス取得
②リソース不⾜分の
Node数をスケール
スケジュール
できないPodを検知
Nodeのスケール後に
スケジュール
スケールインは、原則「Resource Requestsの合計がノードのリソース空き領域の 50% を下回る状態」が 10
分を超えて継続し、かつ、引越し先のノードに充分な空きがある場合に実施(細かい条件あり)

View Slide

(参考)CA利用時の留意事項(OKEの場合)
45
オートスケー
ル対象外
オートスケー
ル対象
Worker Node
クラスタ
ノード・プール
スケール対象外の
ノード・プールを
最低1つは用意！
他のマネージドKubernetesサービスについても、
それぞれの条件(推奨構成や注意事項)を確認する必要性あり！！
スケール対象の
ノード・プールは
手動スケール厳禁！
・
・
・
オートスケー
ル対象(複数可)
“Ready”状態(Podがスケジュー
ル可能)になるまで通常12〜15
分必要

View Slide

• Nodeのスケールイン(削除)に対する考慮
• Nodeがスケールイン(削除)されると、対象のNodeで動作していたPodに対して再スケジューリング
(kubectl drain node→evict)が発⽣
• PodDisruptionBudget (PDB)を設定することで、なるべくGraceful shutdownが実施されるように設定
を実施するのがベスト
• 以下の場合(⼀部)は、Nodeが削除されないことも
• kube-system namespaceで実⾏されているシステムコンポーネント関連のPod
• PodDisruptionBudget(PDB)により制限されている Pod
• コントローラによって管理されていないPod(Deployment/ReplicaSet/Job/StatefulSetでないPod)
• NodeAffinity/NodeSelectorによりスケジュールされているPod
• アノテーションに"cluster-autoscaler.kubernetes.io/safe-to-evict": "false" が設定されている Pod
CA利⽤時の留意事項
46
・・・

View Slide

PodDisruptionBudget(PDB)
• ⾃発的な中断(Cluster Autoscalerによるスケールイン時や”kubectl drain”実⾏時)が発⽣した場合に同時に
ダウン(再スケジューリング)されるレプリカを制限する仕組み
• PodDisruptionBudget(PDB)リソースを利⽤し、最低限稼働しておくべきレプリカ数を定義
(参考)PodDisruptionBudget
47
項番項目内容
1 最低限動作しておく
べきレプリカ数
minAvailable/maxUnavailable
で定義
2 セレクタ対象Podをセレクタで定義

View Slide

PriorityClass
• スケジュール時にリソースを確保できない場合(通常であれば“Pending”状態)に優先的に起動できるよ
うにする仕組み
• PriorityClassリソースを利⽤して定義
(参考) PriorityClass
48
項番項目内容
1 優先度 10億以下の整数
値が⼤きいほど優先度⾼
2 グローバル
適⽤要否
priorityClassNameが付与されていない
Podにも適⽤するか
trueの場合はクラスタに⼀つだけ適⽤
可能
意図的に「優先度低の
待機⽤ Pod」を利⽤し
てノードを多めに起動
しておく⼿法も・・・

View Slide

環境
• Oracle Container Engine for Kubernetes(OKE)： v1.20.8
• kubectl： v1.20.8
• スケール対象：VM.Standard.E4.Flex(1oCPU/メモリ8GB) × 3(Node)
• スケール対象外：VM.Standard.E4.Flex(1oCPU/メモリ8GB) × 2(Node)
• 2ノード・プール
• ⼀つはスケール対象、もう⼀⽅はスケール対象外
• ノード・プールのスケール範囲：最⼩1/最⼤5
アプリケーション
• ベースイメージ：nginx
• ‘kubectl scale’コマンドでレプリカ数を200に設定すると・・・
CAのデモ
49

View Slide

HPA VPA CA
スケール対象 Deployment(ReplicaSet) Pod Node(Worker Node)
スケール⼿法⽔平スケール垂直スケール⽔平スケール
追加コンポーネント metrics serverのみ • metrics server
• Updater
• Admission Controller
• Recommender
• metrics server
• Cluster Autoscaler
Deployment
スケールメトリクス Podや任意のリソース Resource Requests Resource Requests
スケール時の即応性⾼(スケールの振る舞い
はカスタマイズ可能)
低(in-placeは未実装) 低
スケール時の
ダウンタイム
なしあり(in-placeは未実装) あり(PDB等より⼀部制
御可能)
Kubernetesの各スケール⼿法のまとめ
50

View Slide

まとめ
Takuya Niita
Aug 4, 2021
51

View Slide

• Podの⽔平/垂直スケールとNodeの⽔平スケールを提供
HPA(Podの⽔平スケール)
• Podや任意のメトリクスをもとにPodを⽔平スケールさせる仕組み
• Kubernetesリソースやオブジェクトだけでなく、外部の任意のメトリクスも利⽤可能
VPA(Podの垂直スケール)
• Resource RequestsをもとにPodを垂直スケールさせる仕組み
• スケールとしての機能はもちろんだが、Resource Requestsの推奨値も算出する機能としても有⽤
CA(Nodeの⽔平スケール)
• Resource RequestsをもとにNodeを⽔平スケールさせる仕組み
• HPA利⽤時のクラスタリソース不⾜時の補強役として有⽤
まとめ(1)
52

View Slide

Kubernetesのオートスケールにおける(現実的な?)ユースケース
1. Resource Requestsの決定
• VPAの仕組みを利⽤して、Resource Requestsの最適値を確認
• Resource Limitはアプリケーションの特性やNodeのリソースに応じて定義
2. アプリケーションの特性やサービス指標に応じて、Podの⽔平スケール範囲を決定
3. 2.で定義したPodの⽔平スケールにおいて、Nodeのリソース不⾜に備えてCluster Autoscaleを定義
• 定常時のNode数を考慮しつつ、2.で定義したスケール範囲で不⾜すると想定されるリソース分の
Node数を判断
• PodDisruptionBudget(PDB)やPriorityClassを利⽤しながら、Nodeのスケールインによる意図しない
サービスダウンの防⽌、スケールアウト時のNodeプロビジョニングによるリードタイムの短縮を
計画
まとめ(2)
53

View Slide

Kubernetes公式ドキュメント
• HPA
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• HPAウォークスルー
https://kubernetes.io/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
• アグリゲーションレイヤーを使ったKubernetes APIの拡張
https://kubernetes.io/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
• コンテナのリソース管理(Resource Requests/Resource Limit)
https://kubernetes.io/ja/docs/concepts/configuration/manage-resources-containers/
• PodにQuality of Serviceを設定する
https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/
• Podの優先度とプリエンプション
https://kubernetes.io/ja/docs/concepts/configuration/pod-priority-preemption/
• Specifying a Disruption Budget for your Application
https://kubernetes.io/docs/tasks/run-application/configure-pdb/
参考情報&Special Thanks!!
54

View Slide

GitHub
• Kubernetes Autoscaler
https://github.com/kubernetes/autoscaler
• FAQ
https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/FAQ.md
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md
参考記事/スライド
• Kubernetes水平オートスケーリング実践入門 by @hhiroshell
https://speakerdeck.com/hhiroshell/a-practical-guide-to-horizontal-autoscaling-in-kubernetes
• 猫でもわかるVertical Pod Autoscaler by @ytaka23(チェシャ猫さん)
https://speakerdeck.com/ytaka23/kubernetes-meetup-tokyo-13th
https://ccvanishing.hateblo.jp/entry/2018/10/02/203205
• CPU/memoryベースのHPAとVPAはなぜ併用できないのか? by @Ladicle
https://qiita.com/Ladicle/items/812c7cbee51c7ae8ccac
55

View Slide

Oracle Container Engine for Kubernetes(OKE)ドキュメント
• 概要
https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Concepts/contengoverview.htm
• Kubernetesクラスタの自動スケール
https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/contengautoscalingclusters.htm
• Kubernetes Cluster Autoscalerの使用
https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/contengusingclusterautoscaler.htm
56

View Slide

Kubernetesのオートスケール/Kubernetes Autoscale Deep Dive

Kubernetesのオートスケール/Kubernetes Autoscale Deep Dive

oracle4engineer
PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

Kubernetesのオートスケール/Kubernetes Autoscale Deep Dive

Kubernetesのオートスケール/Kubernetes Autoscale Deep Dive

oracle4engineer PRO

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript

oracle4engineer
PRO