Scheduling Profile が実現する Pod 配置戦略の最前線 #InfraStudy / Infra Study Meetup 2nd

Scheduling Profile が実現する Pod 配置戦略の最前線 #InfraStudy / Infra Study Meetup 2nd

Infra Study Meetup #2 で使用したスライドです。

イベント概要:https://forkwell.connpass.com/event/173289/
録画:https://youtu.be/9YpN9-RCwWE?t=4817

332f89cc697355902a817506b6995f2b?s=128

y_taka_23

May 20, 2020
Tweet

Transcript

  1. 5.

    決め打ちの時代 • サーバーを直接、指定してデプロイ ◦ IP アドレスやドメイン名を設定として直書き • 古くから、それなりに最近までのスタンダート ◦ scp

    や rsync のようなアップロードコマンド ◦ Ansible のような構成管理ツールの流用 ◦ Capistrano のようなデプロイ用ツール • サーバとアプリの静的な対応が把握可能 ◦ サーバスペックやネットワークを固定できる Server Server Server Server Deployer
  2. 8.

    オーケストレーションの時代 • 複数のサーバをクラスタとして抽象化 ◦ クラスタ全体を大きなリソースプールとみなす ◦ アプリは「クラスタのどこか」にデプロイ ◦ Kubernetes の他、ECS

    や Docker Swarm • 具体的な配置については手を出さない ◦ kube-scheduler コンポーネントが実際の配置を決定 ◦ サーバの動的な変化に対応できる Server Server Server Cluster Deployer Server kube-scheduler
  3. 9.

    !? IO-Heavy な Pod は特定の Node で実行したい 重要な Pod と他の

    Pod とは一緒にしたくない Web サーバは出来るだけ分散させて可用性を上げたい バッチは出来るだけ詰めてリソース効率を上げたい
  4. 12.

    戦略的スケジューリングの時代 • Pod の配置を明示的にコントロール ◦ 各 Pod の性質に応じて差をつける必要性 ◦ 配置に関して不可知だとそもそも指定できない

    • 大きく分けて設定する場所は二箇所 ◦ Pod 側の設定として配置を指定するもの ◦ スケジューラのアルゴリズムを変更するもの Server Server Server Cluster Deployer Server kube-scheduler
  5. 13.

    Pod に与える配置の制約 • Pod 内に制約を記載 ◦ 実用上は Deployment 単位で共通の設定になる •

    与える制約とユースケースの例 ◦ Node Selector : デプロイ可能な Node を指定 ◦ Pod Affinity : 組にして配置したい Pod を指定 ◦ Taint / Toleration : Node を 特定の Pod 専用に ◦ Topology Spread : ラックや Zone 単位で分散 apiVersion: v1 Kind: Pod metadata: name: mypod labels: foo: bar spec: containers: ... topologySpreadConstraints: - topologyKey: rack maxSkew: 1 labelSelector: matchLabels: foo: bar whenUnsatisfiable: DoNotSchedule Rack 単位での分散の設定の例
  6. 14.

    スケジューラのアルゴリズム変更 • Scheduling Policy の指定 ◦ kube-scheduler 起動時の設定ファイル ◦ 起動時には一種類の

    Policy のみ指定できる • Policy として記述できる例 ◦ Predicate, Prioritize : Node の選択基準を指定 ◦ Extender : 外部サーバの Webhook で処理を挟む { "apiVersion": "v1", "kind": "Policy", "predicates": [ { "Name": "PodFitHostResources", } ], "priorities": [ { "name": "MostRequestedPriority", "weight": 10 } ], ... } 一つの Node に出来るだけ詰める例
  7. 15.

    Topology Spread WebA Pod Topology Spread WebB Pod Batch Pod

    kube-scheduler Batch Policy Topology Spread WebA Pod Topology Spread WebB Pod Deployer Batch Pod Web アプリ A • kind: Deployment • Rack 間で分散 • 可用性重視 Web アプリ B • kind: Deployment • Rack 間で分散 • 可用性重視 バッチ • kind: Job • リソース効率重視 kube-scheduler Web Policy
  8. 19.

    Scheduling Profile の時代 • kube-scheduler に複数の Profile を指定 ◦ Scheduler

    を個別管理せずに済む • Pod 側の設定も移行可能 ◦ 分散していた設定が Profile として集約できる ◦ 異なる種類の Pod に共通の戦略を指定可能 ◦ Pod と配置戦略を疎結合にできる apiVersion: kubescheduler.config.k8s.io/v1alpha2 kind: KubeSchedulerConfiguration profiles: - schedulerName: web-scheduler pluginConfig: - name: PodTopologySpread args: defaultConstraints: - topologyKey: zone ... - schedulerName: batch-scheduler plugins: score: enabled: - name: NodeResourceMostAllocated weight: 10 - ... Web サーバ用、バッチ用の両設定を Profile 化した例
  9. 20.

    Topology Spread WebA Pod Topology Spread WebB Pod Batch Pod

    kube-scheduler Batch Policy Topology Spread WebA Pod Topology Spread WebB Pod Deployer Batch Pod Web アプリ A • kind: Deployment • Rack 間で分散 • 可用性重視 Web アプリ B • kind: Deployment • Rack 間で分散 • 可用性重視 バッチ • kind: Job • リソース効率重視 kube-scheduler Web Policy
  10. 21.

    Batch Pod kube-scheduler Batch Policy Deployer Batch Pod Web アプリ

    A • kind: Deployment • Rack 間で分散 • 可用性重視 Web アプリ B • kind: Deployment • Rack 間で分散 • 可用性重視 バッチ • kind: Job • リソース効率重視 kube-scheduler Web Profile Topology Spread Web B Pod Web B Pod Web A Pod Web A Pod
  11. 22.

    Batch Pod Batch Profile Deployer Batch Pod Web アプリ A

    • kind: Deployment • Rack 間で分散 • 可用性重視 Web アプリ B • kind: Deployment • Rack 間で分散 • 可用性重視 バッチ • kind: Job • リソース効率重視 kube-scheduler Web Profile Topology Spread Web B Pod Web B Pod Web A Pod Web A Pod
  12. 23.

    まとめ • Kubernetes によるオーケストレーション ◦ 抽象化されたクラスタ上の「どこか」にデプロイ ◦ 位置の不可知性と引き換えに動的なサーバに対応 • 戦略的なスケジューリングの必要性

    ◦ Heterogeneous なアプリ群のデプロイ ◦ しかし Pod ごとに加えて Scheduler にも個別設定が必要 • Scheduler Profile の導入 ◦ Pod とその配置戦略の疎結合化と管理容易性