Scheduling Profile が実現する Pod 配置戦略の最前線 チェシャ猫 (@y_taka_23) Infra Study Meetup #2 20th May 2020 #InfraStudy

スケジューリング クラスタ上の Pod の配置をコントロールすること

1. 決め打ちの時代 2. オーケストレーションの時代 3. 戦略的スケジューリングの時代 4. Scheduling Profile の時代 具体・個別的 抽象・総体的

1. 決め打ちの時代 2. オーケストレーションの時代 3. 戦略的スケジューリングの時代 4. Scheduling Profile の時代 具体・個別的 抽象・総体的

決め打ちの時代 ● サーバーを直接、指定してデプロイ ○ IP アドレスやドメイン名を設定として直書き ● 古くから、それなりに最近までのスタンダート ○ scp や rsync のようなアップロードコマンド ○ Ansible のような構成管理ツールの流用 ○ Capistrano のようなデプロイ用ツール ● サーバとアプリの静的な対応が把握可能 ○ サーバスペックやネットワークを固定できる Server Server Server Server Deployer

!? サーバが落ちたらアプリも減る サーバが増えてもアプリが増えない

1. 決め打ちの時代 2. オーケストレーションの時代 3. 戦略的スケジューリングの時代 4. Scheduling Profile の時代 具体・個別的 抽象・総体的

オーケストレーションの時代 ● 複数のサーバをクラスタとして抽象化 ○ クラスタ全体を大きなリソースプールとみなす ○ アプリは「クラスタのどこか」にデプロイ ○ Kubernetes の他、ECS や Docker Swarm ● 具体的な配置については手を出さない ○ kube-scheduler コンポーネントが実際の配置を決定 ○ サーバの動的な変化に対応できる Server Server Server Cluster Deployer Server kube-scheduler

!? IO-Heavy な Pod は特定の Node で実行したい 重要な Pod と他の Pod とは一緒にしたくない Web サーバは出来るだけ分散させて可用性を上げたい バッチは出来るだけ詰めてリソース効率を上げたい

Heterogeneity クラスタ上で複数の性質が異なる Pod を実行すること

1. 決め打ちの時代 2. オーケストレーションの時代 3. 戦略的スケジューリングの時代 4. Scheduling Profile の時代 具体・個別的 抽象・総体的

戦略的スケジューリングの時代 ● Pod の配置を明示的にコントロール ○ 各 Pod の性質に応じて差をつける必要性 ○ 配置に関して不可知だとそもそも指定できない ● 大きく分けて設定する場所は二箇所 ○ Pod 側の設定として配置を指定するもの ○ スケジューラのアルゴリズムを変更するもの Server Server Server Cluster Deployer Server kube-scheduler

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 単位での分散の設定の例

スケジューラのアルゴリズム変更 ● Scheduling Policy の指定 ○ kube-scheduler 起動時の設定ファイル ○ 起動時には一種類の Policy のみ指定できる ● Policy として記述できる例 ○ Predicate, Prioritize : Node の選択基準を指定 ○ Extender : 外部サーバの Webhook で処理を挟む { "apiVersion": "v1", "kind": "Policy", "predicates": [ { "Name": "PodFitHostResources", } ], "priorities": [ { "name": "MostRequestedPriority", "weight": 10 } ], ... } 一つの Node に出来るだけ詰める例

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

!? 複数の Web サーバに同じ設定書きたくない kube-scheduler ばっかり何個も管理したくない

Scheduling Profiles Kubernetes v1.18 の Alpha 機能

1. 決め打ちの時代 2. オーケストレーションの時代 3. 戦略的スケジューリングの時代 4. Scheduling Profile の時代 具体・個別的 抽象・総体的

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 化した例

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

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

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

まとめ ● Kubernetes によるオーケストレーション ○ 抽象化されたクラスタ上の「どこか」にデプロイ ○ 位置の不可知性と引き換えに動的なサーバに対応 ● 戦略的なスケジューリングの必要性 ○ Heterogeneous なアプリ群のデプロイ ○ しかし Pod ごとに加えて Scheduler にも個別設定が必要 ● Scheduler Profile の導入 ○ Pod とその配置戦略の疎結合化と管理容易性

Have a Nice Scheduling! チェシャ猫 (@y_taka_23) Infra Study Meetup #2 20th May 2020