GKE Custom Compute Classesの紹介&機能をOperaterによる自作で再現した話

Transcript

1. GKE Custom Compute Classes の紹介&機能をOperaterによる自作で再現 した話 Kubernetes MeetUp Tokyo #69 竜 鶴吉
2. 自己紹介 > 竜 鶴吉 / Tsuruyoshi Ryu > 早稲田大学基幹理工学部 情報通信学科4年(春から修士1年) > 株式会社3-shakeでインターン中 → GKEの比較的新しい機能である Custom Compute Classesに 関する技術検証
3. 今日話すこと > Custom Compute Classesの機能について簡単に紹介 > 同様の機能をKubernetes Operatorを用いて実装し再現した話 ドキュメント: https://cloud.google.com/kubernetes-engine/docs/concepts/about-custom-compute-classes
4. Custom Compute Classesについて > Nodeがオートスケールする際の 優先順位ルールをカスタ ムリソースで定義できる > 「優先的に◯◯のSpot VMを使用し、中断等により利用で きない場合は◯◯のOn-Demandを使用する」といった形の ルールを定義 > 在庫が再び戻った際には再度最優先のルールを適用しス ケジューリングを行う ※公式ドキュメントに全ての機能が記載されているわけではない ので、CRDを確認することをオススメします！
5. 今日話すこと > Custom Compute Classesの機能について簡単に紹介 > 同様の機能をKubernetes Operatorを用いて実装し再現した話
6. どう実装したか > Kubernetes Operatorを開発するためのフレームワークである、 Kubebuilder を利用し実装 > GKEのCluster AutoScalerと組み合わせる形で機能を再現 (Cluster AutoScalerによるスケジューリングをKubebuilderで制御しながら理想 のスケジューリング要件を満たすようにする )
7. 実装した機能 ① カスタムルールを定義し、スケール時に 最優先として定義 したマシンのNodeにPodをスケジューリングする(特定のラ ベルが付与されたPodのみ対象・利用したいインスタンスの Node Poolがなければ自動作成) ② カスタムルールの内容に応じて Spot VMを利用 ③ Podの状態をリアルタイムで監視し、フォールバック時に2 番目のルールを適用
8. 実装方針 > Mutating Admission Webhooksにより、Pod/Node起動 時に以下処理を追加 - 各Nodeに、そのNodeのマシン(N2, E2など)をValue としたTaintを付与 - Podに対しては、最優先で利用したいNodeに付与 されているTaintを許容するTolerationを付与→そ のNodeのみがスケジューリング対象に - ラベルが付与されていない、カスタムルールを適用し たくないPodに対してはValueを指定しない形で全て のTaintsを許容するようにすることで影響を受けなく なる Taints/Tolerationsの例
9. カスタムルールに基づく Spot VMの利用 > Spot VMを使用したい時(カスタムリソースでspot: true) → NodeSelectorを自動付与し、Spotに関するラベルの付与されたNodeへのスケジューリングを試みる > On-Demandを利用したい時(カスタムリソースでspot: false) → NodeAffinityを自動付与し、Spotに関するラベルの付与されていないNodeをスケジューリング対象とする Mutating Admission Webhooksを利用
10. 動作確認 > n2 Spot VMを最優先、中断時にはn2d spot VMを利用するとい うカスタムルール > 起動しているNodeとそのNode Poolを確認するとn2 Spotが多く 起動できていることがわかる
11. フォールバックについて > イベント駆動でPodの状態変化(ex. Running→Pending)をリ アルタイムで検知する >Spot中断等により最優先ルールが適用できずTaintsにより Pending状態となったPodがある場合、そのPodに対して2番 目の優先度ルールを満たすような Tolerationを付与する(別 の理由で一瞬PendingとなっているだけのPodに対し処理をし ないように、一定以上Pending状態が続いたPodのみ対象と する) > 最優先ルールが適用できず PendingだったPodが2番目の カスタムルールを満たすようスケジューリングされるようにな る Reconcile Loopはリソースの理想状態を維 持するが、Podの状態変化による処理の実 行には向いていない →Informerを用いてPodの状態変化を検知 し、Runnableにより処理を実行する
12. フォールバック時のイメージ ・N2を最優先、N2Dを2番目で優先度を定 義 ・N2 Nodeが中断した場合の挙動
13. 動作確認 > n2のSpot NodePoolを手動で削除し、Spot中断時 の状況を再現 > 一瞬Pendingとなるが、それを検知し2番目の優先 度であるn2dのTolerationが自動付与されることで 再度スケジューリングが行われ Runningに コントローラのログ(PendingのPodをリアルタイムで検知→一定時間以上Pendingなら追加のTolerationを付与)
14. まとめ > GKEの新しい機能である、 Custom Compute Classesの紹介 > Cluster AutoScalerとKubebuilderを組み合わせる形でのスケジューリングに関する紹介 - 定義した最優先のInstanceに関するNode利用、フォールバック時に 2番目のルール適用、 Spot VM利用 など - カスタムリソース適用時、必要に応じて NodePoolを自動で起動 - Nodeに付与したTaintsに対し、カスタムリソースで定義したルールに基づいて適切な TolerationsをPod に付与していくことで、スケジューリングの制御を行う - Podの状態をInformerによりリアルタイムで検知し、フォールバック時の Toleration追加処理を実現 > より詳しい内容はブログに記載しています！ (詰まった点とその解消方法や、他に考えたが採用しなかった方 針なども書いています )
15. ご静聴ありがとうございました！