Kubernetes水平オートスケーリング実践入門 / A Practical Guide to Horizontal Autoscaling in Kubernetes

Cloud Native Developers JP
Kubernetes ⽔平オートスケーリング
実践⼊⾨
@hhiroshell
1

View Slide

宣伝
• 感染対策をしっかりやって遊舎⼯房に⾏きましょう
2
遊舎⼯房さんの店舗はこちら→
↓現在の@hhiroshellのキーボード #crkbd
⾃⼰紹介
@hhiroshell
早川博
（はやかわひろし）
• Cloud Nativeなインフラを開
発するエンジニア。
Yahoo Japan Corporation 所属
• エンジニアコミュニティ
「Cloud Native Developers
JP」オーガナイザー
• Developers Summit 2018
Japan Container Days 12.18
CloudNative Days Tokyo 2019
登壇
• ⾃作キーボード沼

View Slide

⽬次
1. イントロダクション
2. ⽔平オートスケーリングの課題と現実解
3. Kubernetesの⽔平オートスケーリングの仕組み
4. ケーススタディ
3

View Slide

⽬次
4

View Slide

Cloud Native Developers JP 5
Kubernetesとオートスケーリングに対する期待
たくさん負荷がきてもいい感じに
さばけるようにしてくれ。
くーばねてすなら簡単なんでしょ？
※ 丸投げのイラスト

View Slide

このセッションのゴール
• オートスケールで⾃動で負荷をさばけたらかっこいい。ロマンある。
• だが、現実は…。
• まずはKubernetesで地に⾜のついた⽔平オートスケーリングの設計が
できることを⽬指そう。
• 以下のような内容を話します。
– ⼀般的なオートスケーリングの課題と考慮事項
– Kubernetesでの⽔平オートスケーリングの実現⽅法
– ケーススタディ
6

View Slide

⽬次
2. オートスケーリングの課題と現実解
3. Kubernetesの⽔平オートスケーリング仕組み
7

View Slide

オートスケーリングとは
1. 「⼀定の条件をトリガーに」
– 何らかのメトリクスを元に条件判定をおこなう
2. 「必要なリソースを必要分」
– 所定のロジックに従って、増強 / 縮退するリソースの種類と量を
決定する
3. 「⾃動的に増強 / 縮退する」
– プラットフォームのAPIを呼ぶなどしてスケーリングを実⾏する
⼀定の条件をトリガーに、必要なリソースを必要分、⾃動的に増強/縮退する機能
8
繰り返し
1
2
3

View Slide

• スケーリングが間に合わない！
– スケーリングのトリガーが遅い
– リソースの払い出しが遅い
• スケールしても効果がない！
– ボトルネックの箇所に効いていない
– リソースを追加したのに期待ほどの戦⼒に
なっていない
9
• スケールし過ぎ／⾜りない！
– 負荷の変動に追従できていない
– IaaSの契約の上限に当たってしまいそれ以
上増強できない
• スケールアウトしたのに戻っちゃっ
た！
– 負荷の減少に対して感度が良すぎる
実際にはいろいろな問題が起こります…。
これらすべてのパターンに⼀度に対処するのは現実的ではない
※ 頭を抱えて悩んでいる人のイラスト（男性）

View Slide

オートスケーリングの設計の出発点
• 負荷の変動の傾向を調べることから始める
• 傾向がつかめた負荷のうちコストに⾒合うもの⾒極めて⾃動化する
すべてを⾃動化しようとしせず、できるところから
10
予測可能
な負荷
⾃動化して
対処するもの
⾃動化は
避けるもの
負荷のパターンの全体
どこまで
やろうかな…？
※ 将来のことを考える人のイラスト（男性）

View Slide

– スケーリングのトリガーが遅かった
– リソースの払い出しが遅かった
– ボトルネックの箇所に効いていなかった
– リソースを追加しても期待ほどの戦⼒にな
らなっていなかった
11
– 負荷の変動においついていなかった
上増強できなかった
た！
– 負荷の減少に対して感度が良すぎた
相⼿（負荷）を知ったら対策を打ちやすくなります
マトを絞って対策を打てる
※ 踊るお殿様のイラスト

View Slide

12
た！
⼰(=Kubernetes)を知るとやれることの限界がわかります
Kubernetesの機能だけではできないこともある
Safe Harbor Statement
実はがついていない箇所はKubernetes単体の機能ではあまりできる対策がありません

View Slide

オートスケーリングを正しく活⽤した世界
• 起こりうる負荷変動に対して、オートスケーリングの適⽤範囲を⾒
極められている
• 低コストでSLAを達成するための道具と捉え、活⽤できている
– 運⽤オペレーションのコスト削減
– ダウンタイムの削減
– 平常時のリソース利⽤量の最適化
⽬標を達成するための⼿段の1つと捉えて賢く使おう
13

View Slide

⽬次
14

View Slide

Kubernetes
API Server
kube-controller-manager
Kubernetesの⽔平オートスケーリングの仕組み
15
Horizontal Pod Autoscaler
Custom Metrics API Server
(Pod, Object)
metrics-server
app pod
app pod
app pod
kubelet
(External)
metrics source
metrics source
HPAリソースをウォッチ
メトリクス取得
Deploymentなどの
リソースを操作
HorizontalPodAutoscalerリソース
API Serviceリソース

View Slide

Kubernetes
API Server
16
(Pod, Object)
metrics-server
app pod
app pod
app pod
kubelet
(External)
metrics source
metrics source
Deploymentなどの
CPU, Mem

View Slide

Kubernetes
API Server
17
(Pod, Object)
metrics-server
app pod
app pod
app pod
kubelet
(External)
metrics source
metrics source
Deploymentなどの
スケール量を決定

View Slide

• ⽔平オートスケーリングの振る舞いを定義するリソース
• minRepricas / maxRepricas
– 最⼩／最⼤ replica 数
• scaleTargetRef
– スケールを⾏うWorkloadリソースの指定
• metrics
– スケーリングの条件判定に利⽤する
メトリクスを指定
• behavior
– 1回のスケーリングでのリソースの増減幅の指定
18
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
minReplicas: 1
maxReplicas: 10
scaleTargetRef:
(...snip...)
metrics:
(...snip...)
behavior:
(...snip...)
1
2
3
4
5
6
7
8
9
10
11
12
13

View Slide

HPAリソースのtargetフィールド
• スケーリングを⾏う対象を指定するフィールド
• 以下のリソース種別のみが指定でき、これらの
replicas がHPAによって調整される
– Deployment
– ReplicaSet
– ReplicationController
19
HorizontalPodAutoscaler では Podの増減しかできないため、他の箇所のボトルネックには
対処できません
!
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
1
2
3
4

View Slide

HPAリソースのmetricsフィールド
• スケーリングで使うメトリクスを指定する領域
• type:
– メトリクス種別の指定（後述）
• Resource / Pods / Object / External:
– metric:
• メトリクスを識別するための情報
– target:
• スケーリングをトリガーする閾値
– describedObject:
• メトリクスに紐づくK8sリソースの指定
（type=Object のみ）
20
metrics:
type: Object
object:
metric:
name: requests-per-second
target:
type: Value
value: 2k
describedObject:
apiVerion: networking.k8s.io/v1beta1
kind: Ingress
name: my-app-route
1
2
3
4
5
6
7
8
9
10
11
12

View Slide

メトリクス種別による違い
”type” メトリクスメトリクスの収集源 Kubernetesリソースとの
関連
評価ロジック
Resources CPU使⽤量、
Memory使⽤量
metrics-serverがkubelet
から収集した値を利⽤
Podリソースに紐づいた
メトリクスとして扱う
個々のPod毎に値が収集さ
れる前提で、それ⽤の評価
ロジックが採⽤される
Pods 任意 Aggregation Layerで追加
した任意のEndpoint
Podリソースに紐づいた
メトリクスとして扱う
個々のPod毎に値が収集さ
れる前提で、それ⽤の評価
ロジックが採⽤される
Object 任意 Aggregation Layerで追加
任意のKubernetesリソー
スと紐付いたメトリク
スとして扱う
単⼀の値を使った評価ロ
ジックとなる
External 任意 Aggregation Layerで追加
Kubernetes外から取得し
た値を利⽤する
単⼀の値を使った評価ロ
ジックとなる
21

View Slide

【参考】merticsフィールドとAPIパスの関係
• HorizontalPodAutoscalerはAPI Serverからメトリクスを取得している
• メトリクスを取得しにいくPathはHPAリソースのmetricsフィールドに
よって決まる。カスタムメトリクスEndpointはこのPathへのリクエス
ト対してメトリクスを返す必要がある
• 例）Serviceオブジェクトに対応するメトリクスの場合
– /apis/custom.metrics.k8s.io/v1beta2/namespaces/my-ns/...
... services/my-app-svc/my-app-metric
• 詳しい仕様はDesign Proposalsを参照(-> Appendix.)
22
APIバージョン namespace
k8sオブジェクトメトリクス名
metrics:
type: Object
object:
metric:
name: my-app-metric
describedObject:
apiVerion: v1
kind: Service
name: my-app-svc

View Slide

カスタムメトリクスの実装
• kubernetes/metricリポジトリ配下にCustom Metric API Serverのいくつ
かの実装が紹介されている。
– https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md
• Prometheus Adapter
– PrometheusのメトリクスをCustom Metric API Serverとして利⽤可能にするアダプター
• Kube Metrics Adapter
– Prometheusの他、Kubernetes外のメトリクス供給源にも対応したアダプター
• Custom Metrics Adapter Server Boilerplate
– Custom Metrics API Serverを実装するためのライブラリ
23

View Slide

HPAリソースのbehaviorフィールド
• 1回のスケーリングでのリソースの増減
幅を指定するフィールド
– 注: v1.18.x 〜から追加
• scaleDown:
– stabilizationWindowSeconds:
• Podの増減の後そのreplicasの値を必ず維持する時間
– policies:
• 指定の時間幅の中で増減可能な最⼤Pod数を指定する
– selectPolicy:
• 複数のPolicyを設定した場合にどれが採⽤されるかを指
定する
• scaleup:
– 配下のフィールドはscaleDownと同じ
24
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 100
periodSeconds: 15
scaleup:
policies:
- type: Percent
value: 100
periodSeconds: 15
- type: Pods
value: 4
periodSeconds: 15
selectPolicy: Max
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

View Slide

HPAによる⽔平オートスケーリング挙動まとめ
[要求レプリカ数] = [現在のレプリカ数] * ([メトリクス値] / [要求メトリクス値]) （切り上げ）
replica 数
要求レプリカ数
実際のレプリカ数
bahavior で指定
された増加幅
bahavior で指定された減少幅
bahaviorで指定された
1回の増加にかける時間
bahaviorで指定された
1回の減少にかける時間
bahaviorで
指定された
待機時間

View Slide

26
た！
もう⼀度オートスケーリングの課題を確認…。
Kubernetesの機能だけではできないこともある
Safe Harbor Statement
実はがついていない箇所はKubernetes単体の機能ではあまりできる対策がありません

View Slide

⽬次
27

View Slide

ここでとり扱うケース
• アプリケーション
– REST APIサーバー
– CPUバウンドな処理特性
– Kubernetes上にDeploymentとして展開
• 想定する負荷変動
– 突発的なアクセス増（スパイク）を想定
– 平常時から 3 分程度でピーク値 (1000[rps]) までリクエスト数が増加。その後
3分経過した後に平常に戻る
• 検証環境を作るためのmanifest: https://github.com/hhiroshell/k8s-hpa-experiment
28
検証環境のためあまり⼤規模な実験ではありませんので、適宜整数倍するなどして補正
をお願いします m(_ _)m
!

View Slide

システム構成
Gatling
（負荷⽣成器）
Nginx Ingress Controller
API Server
kube-metrics-adaptor
metrics-server
Prometheus
app pod
app pod
app pod
kubelet
Kubernetes クラスター
kubectl で
メトリクスを観察
ロードバランサー
メトリクス(rps)取得
メトリクス
（CPU,メモリ）取得
• メトリクス
(rps, CPU, mem) 取得
• スケーリング実⾏

View Slide

⽔平オートスケーリングを設定するまでの流れ
• Pod以外のボトルネックをチェックする
• 平常時、ピーク時のPod数を決める
• オートスケーリングで使うメトリクスを選ぶ
• オートスケーリングの感度を調整する
30
1
2
3
4

View Slide

Pod以外のボトルネックをチェックする
• HPAではPod数しか⾃動調整できないため、それ以外のボトルネック
が先に顕在化しない構成になっていることを確認する
– Pod数を⼗分⼤きめにして負荷をかけ、エラーや⼤きな遅延なくトラフィック
が捌けるかどうかをみる
– 今回のケースではNginx Ingress Controllerの処理能⼒が不⾜していたため、
replicas: 1 -> 2 に増強
31
Gatling
Nginx Ingress Controller app pod
app pod
app pod
Kubernetes クラスター
1

View Slide

平常時、ピーク時に必要なPod数を決める
• 平常時、ピーク時に相当する負荷をかけ、安定してトラフィックを
処理できるPod数を決定する
• ここで決めた値をHPAリソースの
minReplicas, masReplicasに設定する
32
2
!
• PodのresourceLimits, resourceRequestsも忘れずに設定しましょう
– これによりreplicas数をもって処理性能を調整するという前提が整う
– 処理特性に応じてCPU, Memory利⽤量のバランスも合わせて調整する
(...snip...)
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: cowweb
minReplicas: 2
maxReplicas: 10
(...snip...)
1
2
3
4
5
6
7
8
9

View Slide

オートスケーリングで使うメトリクスを選ぶ
• 監視で使う⼀般的なメトリクスから候補を決める
• リソースレベルのメトリクス:
– Utilization: CPU、メモリ使⽤量
– Saturation: 飽和度。キューに詰まっている量（e.g. ロードアベレージ）
• アプリケーションレベルのメトリクス:
– Rate: スループット、秒間リクエスト数
– Duration: レスポンス時間パーセンタイル、サービス時間
– Error Rate : エラー率
– Queue Length: アプリケーションが処理すべきジョブキューのジョブ数
33
3

View Slide

• 対象とする負荷に確実
に反応する
• 負荷が反映されるまで
のタイムラグが短い
34
• ⽬的の負荷以外のノイ
ズが少ない
オートスケーリングに適したメトリクスの特性
• 必要なリソース量を⾒
積もりやすい
• 収集する仕組みを作り
やすい
• 安定して収集できる
※ 走る作業員のイラスト（男性）
※ 豆腐メンタルのイラスト ※ 耳栓をつけた人のイラスト
※ そろばんを使う男の子のイラスト ※ 工事現場のイラスト ※ バケツリレーイラスト（荷物）

View Slide

負荷をかけながらメトリクスの推移を⾒た結果
35
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
0.0
200.0
400.0
600.0
800.0
1000.0
1200.0
23:58:59
23:59:08
23:59:17
23:59:26
23:59:35
23:59:44
23:59:53
0:00:02
0:00:11
0:00:20
0:00:29
0:00:38
0:00:47
0:00:56
0:01:05
0:01:14
0:01:23
0:01:32
0:01:41
0:01:50
0:01:59
0:02:08
0:02:17
0:02:26
0:02:35
0:02:44
0:02:53
0:03:02
0:03:11
0:03:20
0:03:29
0:03:38
0:03:47
0:03:56
0:04:05
0:04:14
0:04:23
0:04:32
0:04:41
0:04:50
0:04:59
0:05:08
0:05:17
0:05:26
0:05:35
0:05:44
0:05:53
0:06:02
0:06:11
0:06:20
0:06:29
0:06:38
0:06:47
0:06:56
0:07:05
0:07:14
0:07:23
0:07:32
0:07:41
0:07:50
0:07:59
0:08:08
0:08:17
0:08:26
0:08:35
0:08:44
0:08:53
0:09:02
0:09:11
0:09:20
0:09:29
0:09:38
0:09:47
0:09:56
0:10:05
rps cpu
[rps] [Milisec / Pod]
• CPU使⽤量はリクエスト量（実際の負荷の量）によく追従している
• リクエスト量はCPU使⽤量に⽐べて2倍の頻度で値が更新されている
（これの理由は後述）

View Slide

負荷をかけながらメトリクスの推移を⾒た結果
36
0
5,000
10,000
15,000
20,000
25,000
30,000
23:58:59
23:59:08
23:59:17
23:59:26
23:59:35
23:59:44
23:59:53
0:00:02
0:00:11
0:00:20
0:00:29
0:00:38
0:00:47
0:00:56
0:01:05
0:01:14
0:01:23
0:01:32
0:01:41
0:01:50
0:01:59
0:02:08
0:02:17
0:02:26
0:02:35
0:02:44
0:02:53
0:03:02
0:03:11
0:03:20
0:03:29
0:03:38
0:03:47
0:03:56
0:04:05
0:04:14
0:04:23
0:04:32
0:04:41
0:04:50
0:04:59
0:05:08
0:05:17
0:05:26
0:05:35
0:05:44
0:05:53
0:06:02
0:06:11
0:06:20
0:06:29
0:06:38
0:06:47
0:06:56
0:07:05
0:07:14
0:07:23
0:07:32
0:07:41
0:07:50
0:07:59
0:08:08
0:08:17
0:08:26
0:08:35
0:08:44
0:08:53
0:09:02
0:09:11
0:09:20
0:09:29
0:09:38
0:09:47
0:09:56
0:10:05
メモリ使用量（Podごとの平均）
• メモリ使⽤量は負荷が増えてもほとんど変化しない
[KiB]

View Slide

リソースレベルのメトリクスの⽋点 1/2
• リソースレベルのメトリクスは、過負荷になったときに値が取れな
くなるリスクが⾼い
– スケーリングの対象（負荷がかかる対象）が値の供給源となっている
37
Gatling
API Server
metrics-server
Prometheus
app pod
app pod
app pod
kubelet
メトリクス

View Slide

過負荷状態でのCPU利⽤量
• 過負荷状態に伴ってOOMKillなどによるPodの再起動が発⽣すると、
NotReadyかつメトリクス値として0が取得されるPodが出てくる
• HPAの仕様によりこのようなPodはスケール量を抑える⽅向に作⽤す
るため、⼀刻も早くPodを増やしたい状況では都合が悪い
※ https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details
38
0
50
100
150
200
250
1:38:31
1:38:41
1:38:52
1:39:03
1:39:14
1:39:24
1:39:35
1:39:45
1:39:56
1:40:07
1:40:18
1:40:29
1:40:39
1:40:55
1:41:06
1:41:17
1:41:27
1:41:37
1:41:48
1:41:58
1:42:09
1:42:19
1:42:30
1:42:40
1:42:51
1:43:01
1:43:17
1:43:27
1:43:38
1:43:48
1:43:59
1:44:09
1:44:20
1:44:31
1:44:42
1:44:52
1:45:03
1:45:13
1:45:24
1:45:34
1:45:45
1:45:56
1:46:06
1:46:17
1:46:28
1:46:38
1:46:49
1:46:59
1:47:10
1:47:20
1:47:30
1:47:41
1:47:51
1:48:02
1:48:12
1:48:23
1:48:33
1:48:44
1:48:55
1:49:05
1:49:17
1:49:32
1:49:43
1:49:53
PodのCPU使用量の平均 CPU使⽤量の平均値が低く評価され、
スケール量が抑えられてしまう

View Slide

リソースレベルのメトリクスの⽋点 2/2
• マネージドサービスを利⽤する場合、metrics-serverのパラメータや
デプロイ構成の⾃由が効かない（ことが多い）
– メトリクスの更新頻度を上げたり、可⽤性構成をとったりすることが難しい
39
Gatling
API Server
metrics-server
Prometheus
app pod
app pod
app pod
kubelet
メトリクス

View Slide

メトリクスをrpsにするHPA設定
• kube-metrics-adapterの使い⽅に
沿って、PromQLで取得した値を利
⽤するように設定
40
(...snip...)
metadata:
annotations:
metric-config.external.
prometheus-query.prometheus/rps: |
sum by (job) (rate(nginx_ingress_
controller_nginx_process_requests_
total[1m])
(...snip...)
spec:
(...snip...)
metrics:
- type: External
external:
metric:
name: prometheus-query
selector:
matchLabels:
query-name: rps
target:
type: Value
averageValue: ”100"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
• metadata.annotations.metric-config.external.[ph]:
– Prometheusに対するクエリを指定する
– Nginx Ingress Controllerで観測されたrps値を取得している
• spec.metrics.external:
– anntotationsに記述したクエリと、target（利⽤するメトリク
スの指定）を対応づける設定を記述
• spec.metrics.target:
– Prometheusから取得したメトリクスをPod数で割った値が
100を超えないようにスケーリングをおこなう

View Slide

最後は要件に合わせてメトリクスを決定
• 急激な負荷がかかる状況において安定したスケーリングしたいこと
から、リクエスト量[rps]を採⽤
41
メトリクス負荷に確実
に反応する
タイムラグノイズの
影響
必要リソースの
⾒積もりやすさ
収集する仕組み
の構築しやすさ
メトリクス収集
の安定性
CPU使⽤量
[Milisec per pod]
○ ○ ? ○ ○ ×
メモリ使⽤量
[KiB per Pod]
× N/A ? N/A ○ ×
リクエスト量
[rps]
○ ○ ○ × × ○
(...snip...)

View Slide

オートスケーリングの感度を調整する
• ピーク時は安定しているが、負荷増加時にスケールが間に合わずエ
ラーとなっている
• 負荷の増加に対して早めにスケールするよう調整が必要
42
4
負荷の増加に replica 数が追いつ
かず、エラーとなっている状態
replica 数が最⼤値に調整され、
処理が安定した状態

View Slide

スケーリングの感度を決めるHPA設定
• spec.behavorで感度を上げる
– やりすぎると無⽤なリソースを消費しやすくなる
ので注意
• 平常時のPod数（待機Pod数）を上げる
• スケールダウンでは感度を落としてオシ
レーションを防⽌する
43
spec:
(...snip...)
minReplicas: 4
metrics:
- type: External
external:
metric:
name: prometheus-query
selector:
matchLabels:
query-name: rps
target:
type: Value
averageValue: "70”
behavior:
scaleUp:
policies:
- type: Pods
value: 4
periodSeconds: 5
scaleDown:
(...snip...)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
• spec.metris.external.target.averageValue:
– Podあたりのrps値が70を超えた時点でスケールを開始
• spec.behavior.scaleup.stabilizationWindowSeconds:
– 前回のスケール後、間を置かず次のスケーリングを実⾏
• spec.behavior.scaleup.policies:
– 5秒以内に最⼤4Pod追加

View Slide

Congrats !
• 無事にスパイクに対処できる設定ができました！
44

View Slide

まとめ
• この絵を再掲してまとめとしたく。
• ご利⽤は計画的に…。Happy Autoscaling !!
45
予測可能
な負荷
⾃動化して
対処するもの
⾃動化は
避けるもの
負荷のパターンの全体
どこまで
やろうかな…？
※ 将来のことを考える人のイラスト（男性）

View Slide

Fin.
46

View Slide

Appendix.
参考⽂献
47

View Slide

【参考⽂献】
• Kubermetes公式ドキュメント
– Horizontal Pod Autoscaler
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
– Horizontal Pod Autoscaler Walkthrough
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
– Extending the Kubernetes API with the aggregation layer
• https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
– Configure the Aggregation Layer
• https://kubernetes.io/docs/tasks/access-kubernetes-api/configure-aggregation-layer
– Resource metrics pipeline
• https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/
– kube-controller-manager （オプションの参照先）
• https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/
• Kubernetes APIリファレンス
– HorizontalPodAutoscaler v2beta2 autoscaling:
• https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#horizontalpodautoscaler-v2beta2-autoscaling
48

View Slide

【参考⽂献】
• GitHubリポジトリ上のドキュメント
– Repository top
• https://github.com/kubernetes/metrics
– Implementations
• https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md
– Metrics Server
• https://github.com/kubernetes-sigs/metrics-server
– Design Proposals
• https://github.com/kubernetes/community/tree/master/contributors/design-proposals/instrumentation
– Custom Metrics API 仕様
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-
api.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-
api.md
49

View Slide

【参考⽂献】
• Custom Metrics API Serverの実装
– Custom Metrics Adapter Server Boilerplate
• https://github.com/kubernetes-sigs/custom-metrics-apiserver
– kube-metrics-adapter
• https://github.com/zalando-incubator/kube-metrics-adapter
– Prometheus Adapter for Kubernetes Metrics APIs
• https://github.com/directxman12/k8s-prometheus-adapter
• 論⽂
– Auto-Scaling Web Applications in Clouds: A Taxonomy and Survey
• https://dl.acm.org/doi/abs/10.1145/3148149
• コミュニティや有志の資料
– 監視って何だっけ？/@ryota¥_hnk
• https://docs.google.com/presentation/d/1jc0voGfNCpDumTCTna1aqyV1NARxLKXS0LUYEfGOroY
– 【暫定版】 Kubernetesの性能監視で必要なメトリクス⼀覧とPrometheusでのHowTo
• https://kashionki38.hatenablog.com/entry/2020/08/06/011420
50

View Slide

Kubernetes水平オートスケーリング実践入門 / A Practical Guide to Horizontal Autoscaling in Kubernetes

Kubernetes水平オートスケーリング実践入門 / A Practical Guide to Horizontal Autoscaling in Kubernetes

hhiroshell

More Decks by hhiroshell

Other Decks in Technology

Featured

Transcript