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

OCHaCafe Season4 #5の資料です．

Transcript

1. Kubernetesのオートスケーリング Oracle Cloud Hangout Cafe 4 #5 Takuya Niita Oracle Corporation Japan Aug 4, 2021 Kubernetesのスケールの仕組みを抑えよう！！
2. 2 Copyright © 2021, Oracle and/or its affiliates. 1. スケールの復習とKubernetesにおけるスケールの概要 2. Podの⽔平スケール 3. Podの垂直スケール 4. Nodeの⽔平スケール 5. まとめ アジェンダ デモもやります！！
3. • 仁井⽥ 拓也 • ⽇本オラクル株式会社 • ソリューション・アーキテクト本部 • 前職は某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
4. スケールの復習とKubernetesにおけるスケールの概要 Takuya Niita Oracle Corporation Japan Aug 4, 2021 Copyright © 2021, Oracle and/or its affiliates. 4 Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング
5. ⽔平スケール(スケールアウト) • アプリケーションが稼働する環境の数を増や すことによって、システムの処理能⼒を向上 させる⼿法 • 処理を並列稼働させることによるスケール • 縮⼩させる場合は「スケールイン」 ⼀般的なスケールの⼿法 Copyright © 2021, Oracle and/or its affiliates. 5 ・・・ サーバ (BM/VM/コンテナ) サーバ (BM/VM/コンテナ) 垂直スケール(スケールアップ) • アプリケーションが稼働する環境のリソース やスペックを向上させることによって、シス テムの処理能⼒を向上させる⼿法 • 処理を捌ける量を増やすことによるスケール • 縮⼩させる場合は「スケールダウン」
6. ⽔平スケール(スケールアウト) • Pros • システムの可⽤性が⾼まる • Cons • 密結合なリソースに注意が必要 • メンテナンスが煩雑になる可能性 • ユースケース • Webアプリケーション(Web/APサーバ) • 科学技術計算サーバ(HPCなど) 垂直スケール(スケールアップ) • Pros • システム構成に変更がない • 分散化に不向きなシステムでも対応可能 • Cons • サーバが故障した際のリスク • ユースケース • データベースサーバ • ストレージサーバ それぞれのスケール⼿法のPros-Cons/ユースケース Copyright © 2021, Oracle and/or its affiliates. 6
7. • Webアプリケーションなどの⼀般的なワーク ロードに適する⽔平スケール(スケールアウト) • データベースなどの密結合なリソースに適す る垂直スケール(スケールアップ) 実際には・・・ Copyright © 2021, Oracle and/or its affiliates. 7 システム全体では適材適所で 組み合わせて利用 Webサーバ データベース サーバ
8. 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におけるスケールの種類 Copyright © 2021, Oracle and/or its affiliates. 8
9. 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におけるスケールの種類 Copyright © 2021, Oracle and/or its affiliates. 9 Kubernetesとして提供するスケール手法 & 本日のセッション範囲
10. Podの⽔平スケール Takuya Niita Oracle Corporation Japan Aug 4, 2021 Copyright © 2021, Oracle and/or its affiliates. 10 Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング
11. Horizontal Pod Autoscaler(HPA) • コンテナアプリケーション環境(Pod)を⽔平ス ケール(スケールアウト/イン)する仕組み • 正確にはDeployment(ReplicaSet)のレプリカ 数をスケール • スケール定義はHorizontalPodAutoscalerリ ソースに • Controller Managerのひとつである HorizontalPodAutoscalerControllerが管理を実施 • デフォルトでは30秒間隔で周期 • HPAリソースに定義したターゲット値に近 づくようにPodの数を調整 • 基本はPodの平均CPU/メモリ使⽤率を利⽤ するが、カスタムメトリクスも利⽤可能 HPA(Horizontal Pod Autoscaler) Copyright © 2021, Oracle and/or its affiliates. 11 ・・・ Replica数を 変更 Replica数に応 じてスケール HorizontalPod AutoscalerController
12. HPAのスケールの仕組み(CPU/メモリ使⽤率を利⽤する場合) Copyright © 2021, Oracle and/or its affiliates. 12 ・ ・ ・ HorizontalPod AutoscalerController metrics server ①HPAリソース取得 ③メトリクス取得 ⑤スケール指⽰ ②メトリクス取得 ④スケール量算出 ⑥スケール
13. (参考)metrics server Copyright © 2021, Oracle and/or its affiliates. 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)
14. 以下の計算式で必要レプリカ数を算出 • 具体例) • 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を例に) Copyright © 2021, Oracle and/or its affiliates. 14 必要なレプリカ数 = 現在のレプリカ数 * ( Podの平均CPU使用率 / ターゲットのCPU使用率 )
15. 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 Copyright © 2021, Oracle and/or its affiliates. 15 各種スケールを利用す る場合は必ず指定！！
16. (参考) QoS Class Copyright © 2021, Oracle and/or its affiliates. 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をもとに決定
17. HPA利用時のDeployment(Pod)側の定義 Copyright © 2021, Oracle and/or its affiliates. 17 この部分の数値をCPU利用率100%と見る Resource RequestsとResource Limitsの書き方 • CPU 200m=0.2(core) • メモリ 100Mi ≒ 0.1Gi ≒ 104MB • CPU 1(core)=1000m • メモリ 1Gi = 1024Mi ≒ 1074MB
18. HPA(Horizontal Pod Autoscaler) Manifest例(1) Copyright © 2021, Oracle and/or its affiliates. 18 項番 項目 内容 1 スケール対象 スケール対象のapiVersion/kind/name を指定。 基本的にはapiVersion: apps/v1、 kind: Deploymentを指定。 2 スケール範囲 スケールする際のPodのレプリカ数の 最⼩値、最⼤値を指定。 この範囲内のスケールの振る舞いは behaviorフィールド(次スライド)に よって決定。 3 スケール条件と するメトリクス スケール条件に利⽤するメトリクス を指定。 CPU/メモリの他にカスタムメトリク スも指定可能。
19. HPA(Horizontal Pod Autoscaler) Manifest例(2) Copyright © 2021, Oracle and/or its affiliates. 19 項 番 項目 種別 内容 4 スケール時 の振る舞い (デフォルト) スケール アウト 即時スケール(リードタイム無) 以下のうち、追加レプリカ数が 多い⽅を採⽤ • 15秒で稼働中のレプリカ数 分を追加 • 15秒で4つのPodを追加 スケール イン リードタイム300秒(5分) 15秒で必要レプリカ数まで削減
20. スケール時に指定可能な振る舞い(単⼀の場合) • Ex)現レプリカ数:3から必要レプリカ:10までスケールアウトする場合 • type: Percent • type: Pods HPA(Horizontal Pod Autoscaler)におけるスケール時の振る舞い(1) Copyright © 2021, Oracle and/or its affiliates. 20 レプリカ数分、必要レプリカ数までスケールアウト レプリカ(Pod)を4個(value:4)ずつスケールアウト 15秒 15秒 periodSeconds 15秒 +3 +4 +3 +4 15秒
21. スケール時に指定可能な振る舞い(複数の場合) • Ex)現レプリカ数:80から必要レプリカ:10までスケールインする場合 HPA(Horizontal Pod Autoscaler)におけるスケール時の振る舞い(2) Copyright © 2021, Oracle and/or its affiliates. 21 指定したtypeのうち、 多い方(Max)を採用 少ない方(Min)も指定可能 80個 72個 40個 ・・・ 36個 32個 10個 Percent Percent Percent Pods Pods 60秒 60秒 60秒 ・・・ スケールごとに再計算 を⾏い、”selectPolicy” に基づいてポリシーを 選択
22. 種別 メトリクス 収集元 スケールロジック Resource CPU使⽤率 メモリ使⽤率 metrics serverがkubeletから取得 した値 PodのCPU/メモリ使⽤率を利⽤ して評価 Pods Podに関する任意のメ トリクス API Aggregation Layerから取得 した任意のエンドポイント ”率”ではなく、⽣値で評価を実 施 Object 任意のメトリクス (Pod以外のk8sオブ ジェクト) API Aggregation Layerから取得 した任意のエンドポイント 単⼀の値で、⽬標値と⽐較を⾏ い、評価を実施 External 任意のメトリクス(k8s オブジェクト以外) API Aggregation Layerから取得 した任意のエンドポイント 単⼀の値で、⽬標値と⽐較を⾏ い、評価を実施 HPA Controllerが利⽤するメトリクス Copyright © 2021, Oracle and/or its affiliates. 22 カスタムメトリクス
23. (参考)API Aggregation Layer Copyright © 2021, Oracle and/or its affiliates. 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)を 利⽤して実装可能
24. HPAのスケールの仕組み(カスタムメトリクスを利⽤する場合) Copyright © 2021, Oracle and/or its affiliates. 24 ・ ・ ・ HorizontalPod AutoscalerController custom metrics (Pod) ①HPAリソース取得 ③メトリクス取得 ⑤スケール指⽰ ②メトリクス取得 ④スケール量算出 ⑥スケール custom metrics (Object) custom metrics (External) metrics serverは利用しない
25. カスタムメトリクス (type:Podsの場合) Copyright © 2021, Oracle and/or its affiliates. 25 “type:Pods”を指定することで任意のPodメトリクスをス ケール条件に利⽤可能 “type:Pods”の場合は、target.typeは”AverageValue”固定 対象メトリクスは”packets-per-second” スケール条件には、平均CPU/メモリ”使⽤率”ではなく、 平均CPU/メモリ”使⽤値”(⽣の値)を利⽤
26. カスタムメトリクス (type:Objectの場合) Copyright © 2021, Oracle and/or its affiliates. 26 “type:Object”を指定することで、同⼀Namespace 内のPod以外のk8s内の任意のメトリクスをスケー ル条件に利⽤可能 この場合は、”main-route”というIngressを スケール条件の対象Objectとして指定 対象メトリクスは”requests-per-second” target.typeは”Value”または”AverageValue”
27. カスタムメトリクス (type:Externalの場合) Copyright © 2021, Oracle and/or its affiliates. 27 “type:External”を指定することで、k8s外の任意の メトリクスをスケール条件に利⽤可能 例えば、PrometheusでKafkaなどの「未処理のキュー (queue=worker_tasks)」を⽰すメトリクスを収集してい る場合、そのメトリクスをスケール判定に利⽤可能 target.typeは”Value”または”AverageValue”
28. 複数のメトリクス Copyright © 2021, Oracle and/or its affiliates. 28 HPAは各条件の積(and条件)を維持 この場合は以下の条件 • 各PodのCPU使⽤率50% • 各Podが送信するパケットが1000パケット • main-route Ingressのバックエンドにある全てのPodが送信す るパケットが2000リクエスト/秒 各メトリクスの必要レプリカ数を算出し、最も多い結果を採⽤ スケールイン/スケールアウトにより、算出した最も多い結果 に対してPod数を近づける
29. 環境 • 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デモ Copyright © 2021, Oracle and/or its affiliates. 29 CRI-Oを使ってます!!
30. Podの垂直スケール Takuya Niita Oracle Corporation Japan Aug 4, 2021 Copyright © 2021, Oracle and/or its affiliates. 30 Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング
31. Vertical Pod Autoscaler(VPA) • コンテナアプリケーション環境(Pod)を垂直ス ケール(スケールアップ/ダウン)する仕組み • Podに要求されるCPU/メモリを調整 (Resource Requestsを上書き) • スケール定義はVPA(VerticalPodAutoscaler)リ ソースとして定義 • 複数のControllerの組み合わせで管理(HPAとは 異なる) • 主にUpdater、Admission Controller、 Recommenderが連携して動作 • 原則としてスケール時にはPodの再起動が 発⽣(Resource Requestsを適⽤させるため) • 起動中のままのスケールは未実装 VPA(Vertical Pod Autoscaler) Copyright © 2021, Oracle and/or its affiliates. 31 CPU：0.5 CPU Memory：200Mi CPU：1.0 CPU Memory：750Mi Updater Admission Controller Recommender
32. VPA(Vertical Pod Autoscaler) Manifest例 Copyright © 2021, Oracle and/or its affiliates. 32 項番 項目 内容 1 スケール対象 スケール対象の apiVersion/kind/nameを指定。 基本的にはapiVersion: apps/v1、 kind: Deploymentを指定。 2 アップデート ポリシー Auto、Recreate、Initial、Off • Auto(Default):再起動によるスケール アップ(将来的にはin-place?) • Recreate:再起動によるスケールアッ プ • Initial:Pod作成時にスケールアップ (evictしない) • Off:スケール値の算出だけ(スケール アップしない)
33. VPA利用時のDeployment(Pod)側の定義 Copyright © 2021, Oracle and/or its affiliates. 33 ここ部分を上書きすることで スケールアップ！！
34. 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の場合) Copyright © 2021, Oracle and/or its affiliates. 34
35. VPAのスケールの仕組み(updateMode:Auto/Recreateの場合) Copyright © 2021, Oracle and/or its affiliates. 35 Updater Admission Controller Recommender ⑤Resource Requestsの推奨値と 現在のResource Requestsの⽐較 ⑥Podのevict ③Resource Requestsの推奨値算出 ④Resource Requestsの推奨値を登録 ①VPAリソースを読み込み ② Podのメトリクス取得 metrics server ⑦ Resource Requestsの 推奨値取得 ⑧Podのspecを上書き VPAリソース
36. 実は・・・ CPU/メモリ使⽤率によるHPA/VPAでは・・・ (参考) HPAとVPAの併⽤ Copyright © 2021, Oracle and/or its affiliates. 36 CPUとメモリをスケール条件にしたHPAとVPAの併用は禁止！！ VPA VPAによってスケールされたPodに対してHPAでのスケール を適⽤すると、Pod毎のResource Requestsが煩雑になり、想 定通りのスケール挙動にならない可能性が⾼い ※HPAが実施された結果、オーバスケールだったり、ス ケール不⾜になることも…
37. HPA(Podの数が増減するスケール⽅式) • Podが使⽤しているリソースとResource Requestsをもとに⽔平スケール • スケールの範囲や振る舞いをユーザ側で定義する必要性 • アプリケーション(Pod)にかかる負荷の傾向を把握 • コスト(経済/リソース)を考慮しながらスケール範囲の⾒極め • アプリケーションの特性や運⽤、サービス指標(SLA/SLOも含む)などを考慮し、スケールの振る舞 いを定義 VPA(Podのspec(Resource Requests)をスケール⽅式) • Podが使⽤しているリソース(CPU/メモリ)をもとに垂直スケール • 実際のリソース使⽤量を把握できていなくもよしなにスケール(実績値との乖離を防⽌) • 実際にスケールさせなくても、算出された推奨値を確認するだけという利⽤⽅法も • クラスタ全体のリソースを有効活⽤可能 • 現時点では、原則としてはPodの再起動が必要(in-placeは未実装) ここまでのまとめ： HPAとVPA Copyright © 2021, Oracle and/or its affiliates. 37
38. 環境 • 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 スケール対象のアプリケーション • アプリケーション • ベースイメージ：ubuntu • command：while true; do timeout 0.5s yes >/dev/null; sleep 0.5s; done’ # 少しだけリソース消費 VPAデモ Copyright © 2021, Oracle and/or its affiliates. 38
39. シナリオ • VPAの各コンポーネント(Updater/Admission Controller/Recommender)をインストール • スケール対象のアプリケーションをデプロイ • アプリケーションのResource Requestsの初期値を確認 • Recommenderによる推奨値算出の確認 • アプリケーション(Pod)のResource Requestsが上書きされることを確認 VPAデモ Copyright © 2021, Oracle and/or its affiliates. 39 HPAはDeploymentがスケール対象でした。 VPAでは、Pod⾃体がスケール対象であることを意識してデモをご覧ください！
40. Nodeの⽔平スケール Takuya Niita Oracle Corporation Japan Aug 4, 2021 Copyright © 2021, Oracle and/or its affiliates. 40 Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング
41. Cluster Autoscaler(CA) • Kubernetesクラスタ内のNode数を⽔平スケール (スケールアウト/イン)する仕組み • 原則としてResource Requestsの値をベース にクラスタ内のリソースの過不⾜を判断し、 Node数を増減 • IaaSに依存するため、特にクラウド・プロ バイダに関しては仕様や利⽤⽅法に違いが ある • ⼀つのDeployment(Pod)によって動作 • 基本的にMaster Nodeに配置することを推奨 (Worker Nodeでも可) • Kubernetes API Server を通してクラスタのリ ソース使⽤状況を監視し、Node数を操作 CA(Cluster Autoscaler) Copyright © 2021, Oracle and/or its affiliates. 41 Cluster Autosaler Deployment ・・・ ・・・ スケール指⽰ Nodeをプロビジョニング
42. CA Manifest例(OKEの場合) Copyright © 2021, Oracle and/or its affiliates. 42 スクリプトの引数にスケール動作の挙動 を指定 重要なのは スケール範囲(最大Node数/最小Node数) Cluster Autoscalerを動作させる コンポーネントはDeployment
43. CA利用時のDeployment(Pod)側の定義 Copyright © 2021, Oracle and/or its affiliates. 43 この値をベースに、各Podのリソースが既存Node を超過した場合にスケールが発生
44. CAのスケールの仕組み Copyright © 2021, Oracle and/or its affiliates. 44 Cluster Autosaler Deployment metrics server ・ ・ ・ スケジュール できないPod ①メトリクス取得 ②リソース不⾜分の Node数をスケール スケジュール できないPodを検知 Nodeのスケール後に スケジュール スケールインは、原則「Resource Requestsの合計がノードのリソース空き領域の 50% を下回る状態」が 10 分を超えて継続し、かつ、引越し先のノードに充分な空きがある場合に実施(細かい条件あり)
45. (参考)CA利用時の留意事項(OKEの場合) Copyright © 2021, Oracle and/or its affiliates. 45 オートスケー ル対象外 オートスケー ル対象 Worker Node クラスタ ノード・プール スケール対象外の ノード・プールを 最低1つは用意！ 他のマネージドKubernetesサービスについても、 それぞれの条件(推奨構成や注意事項)を確認する必要性あり！！ スケール対象の ノード・プールは 手動スケール厳禁！ ・ ・ ・ オートスケー ル対象(複数可) “Ready”状態(Podがスケジュー ル可能)になるまで通常12〜15 分必要
46. • 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利⽤時の留意事項 Copyright © 2021, Oracle and/or its affiliates. 46 ・・・
47. PodDisruptionBudget(PDB) • ⾃発的な中断(Cluster Autoscalerによるスケールイン時や”kubectl drain”実⾏時)が発⽣した場合に同時に ダウン(再スケジューリング)されるレプリカを制限する仕組み • PodDisruptionBudget(PDB)リソースを利⽤し、最低限稼働しておくべきレプリカ数を定義 (参考)PodDisruptionBudget Copyright © 2021, Oracle and/or its affiliates. 47 項番 項目 内容 1 最低限動作しておく べきレプリカ数 minAvailable/maxUnavailable で定義 2 セレクタ 対象Podをセレクタで定義
48. PriorityClass • スケジュール時にリソースを確保できない場合(通常であれば“Pending”状態)に優先的に起動できるよ うにする仕組み • PriorityClassリソースを利⽤して定義 (参考) PriorityClass Copyright © 2021, Oracle and/or its affiliates. 48 項番 項目 内容 1 優先度 10億以下の整数 値が⼤きいほど優先度⾼ 2 グローバル 適⽤要否 priorityClassNameが付与されていない Podにも適⽤するか trueの場合はクラスタに⼀つだけ適⽤ 可能 意図的に「優先度低の 待機⽤ Pod」を利⽤し てノードを多めに起動 しておく⼿法も・・・
49. 環境 • 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) • metrics server：v0.5.0 • 2ノード・プール • ⼀つはスケール対象、もう⼀⽅はスケール対象外 • ノード・プールのスケール範囲：最⼩1/最⼤5 アプリケーション • アプリケーション • ベースイメージ：nginx • ‘kubectl scale’コマンドでレプリカ数を200に設定すると・・・ CAのデモ Copyright © 2021, Oracle and/or its affiliates. 49
50. 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の各スケール⼿法のまとめ Copyright © 2021, Oracle and/or its affiliates. 50
51. まとめ Takuya Niita Oracle Corporation Japan Aug 4, 2021 Copyright © 2021, Oracle and/or its affiliates. 51 Oracle Cloud Hangout Cafe 4 #5 – Kubernetesのオートスケーリング
52. Kubernetesにおけるスケールの種類 • Podの⽔平/垂直スケールとNodeの⽔平スケールを提供 HPA(Podの⽔平スケール) • Podや任意のメトリクスをもとにPodを⽔平スケールさせる仕組み • Kubernetesリソースやオブジェクトだけでなく、外部の任意のメトリクスも利⽤可能 VPA(Podの垂直スケール) • Resource RequestsをもとにPodを垂直スケールさせる仕組み • スケールとしての機能はもちろんだが、Resource Requestsの推奨値も算出する機能としても有⽤ CA(Nodeの⽔平スケール) • Resource RequestsをもとにNodeを⽔平スケールさせる仕組み • HPA利⽤時のクラスタリソース不⾜時の補強役として有⽤ まとめ(1) Copyright © 2021, Oracle and/or its affiliates. 52
53. 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) Copyright © 2021, Oracle and/or its affiliates. 53
54. 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!! Copyright © 2021, Oracle and/or its affiliates. 54
55. 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 参考情報&Special Thanks!! Copyright © 2021, Oracle and/or its affiliates. 55
56. 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 参考情報&Special Thanks!! Copyright © 2021, Oracle and/or its affiliates. 56
57. Thank you 57 Copyright © 2021, Oracle and/or its affiliates.