Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Kubernetes では通常、Pod が配置される Node は Scheduler によって自動的に選択されるため、ユーザが意識する必要がありません。しかし、ひとつのクラスタに様々な性質を持つ Pod を同時にデプロイすることを考えると、Pod の配置を Node や他の Pod との関連でもっと精密に指定したいユースケースが増えてきます。

このような需要に応えるため、Scheduler には Node を選択するためのアルゴリズムをカスタマイズ可能にする仕組みが備わっています。本スライドで紹介する Scheduling Profile はそれをさらに効果的に運用するための仕組みです。従来はアルゴリズムごとに Scheduler が必要でしたが、現在ではアルゴリズムを Profile としてまとめ、さらにひとつの Scheduler に複数の Profile が指定できるようになっています。

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

y_taka_23

May 20, 2020
Tweet

More Decks by y_taka_23

Other Decks in Technology

Transcript

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

    や rsync のようなアップロードコマンド ◦ Ansible のような構成管理ツールの流用 ◦ Capistrano のようなデプロイ用ツール • サーバとアプリの静的な対応が把握可能 ◦ サーバスペックやネットワークを固定できる Server Server Server Server Deployer
  2. オーケストレーションの時代 • 複数のサーバをクラスタとして抽象化 ◦ クラスタ全体を大きなリソースプールとみなす ◦ アプリは「クラスタのどこか」にデプロイ ◦ Kubernetes の他、ECS

    や Docker Swarm • 具体的な配置については手を出さない ◦ kube-scheduler コンポーネントが実際の配置を決定 ◦ サーバの動的な変化に対応できる Server Server Server Cluster Deployer Server kube-scheduler
  3. !? IO-Heavy な Pod は特定の Node で実行したい 重要な Pod と他の

    Pod とは一緒にしたくない Web サーバは出来るだけ分散させて可用性を上げたい バッチは出来るだけ詰めてリソース効率を上げたい
  4. 戦略的スケジューリングの時代 • Pod の配置を明示的にコントロール ◦ 各 Pod の性質に応じて差をつける必要性 ◦ 配置に関して不可知だとそもそも指定できない

    • 大きく分けて設定する場所は二箇所 ◦ Pod 側の設定として配置を指定するもの ◦ スケジューラのアルゴリズムを変更するもの Server Server Server Cluster Deployer Server kube-scheduler
  5. 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. スケジューラのアルゴリズム変更 • 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. 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. 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. 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. 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. 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. まとめ • Kubernetes によるオーケストレーション ◦ 抽象化されたクラスタ上の「どこか」にデプロイ ◦ 位置の不可知性と引き換えに動的なサーバに対応 • 戦略的なスケジューリングの必要性

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