Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

CNDT 2022 登壇資料.pdf

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 104 Anzeige

Weitere Verwandte Inhalte

Aktuellste (20)

Anzeige

CNDT 2022 登壇資料.pdf

  1. 1. GKE の Spot VM / Preemptible VM 利用者を救う! インフラコストを削減しながら可用性を維持できるソフトウェア『 Panope』 From 7knot.Co 1
  2. 2. 2 自己紹介 ・名前: 山本浩平 ・twitter: @yamagai_0919 ・所属: 株式会社7knot 代表 某ソシャゲのサーバーチーム (2022年入社) ・一言: 97年生まれです おうち Kubernetes 楽しいです
  3. 3. このセッションで話すこと 1. GCP の Preemptible VM / Spot VM とは 2. Preemptible VM / Spot VM のメリットとデメリット 3. Panope とは 4. Panope の仕組み・機能 5. その他 Preempt への対処法 6. ...etc 3
  4. 4. Preemptible VM / Spot VM とは 4
  5. 5. 5 Preemptible VM とは (出典: https://cloud.google.com/compute/docs/instances/preemptible)
  6. 6. 6 Preemptible VM とは ・GCP において、標準 VM よりもはるかに低価格で利用できる VM → 60%〜91%割引! (出典: https://cloud.google.com/compute/docs/instances/preemptible)
  7. 7. 7 Preemptible VM とは ・24時間に一度、強制的にインスタンスが停止 (Preepmt)される ・GCP において、標準 VM よりもはるかに低価格で利用できる VM → 60%〜91%割引! (出典: https://cloud.google.com/compute/docs/instances/preemptible)
  8. 8. 8 Spot VM とは (出典: https://cloud.google.com/compute/docs/instances/spot)
  9. 9. 9 Spot VM とは ・GCP において、標準 VM よりもはるかに低価格で利用できる VM → 60%〜91%割引!料金体系は Preemptible VM と同じ (出典: https://cloud.google.com/compute/docs/instances/spot)
  10. 10. 10 ・24時間に一度、強制的にインスタンスが停止 (Preepmt)される制限は無い ただし、予期せぬタイミングで Preempt される Spot VM とは ・GCP において、標準 VM よりもはるかに低価格で利用できる VM → 60%〜91%割引!料金体系は Preemptible VM と同じ (出典: https://cloud.google.com/compute/docs/instances/spot)
  11. 11. 11 ・24時間に一度、強制的にインスタンスが停止 (Preepmt)される制限は無い ただし、予期せぬタイミングで Preempt される Spot VM とは ・GCP において、標準 VM よりもはるかに低価格で利用できる VM → 60%〜91%割引!料金体系は Preemptible VM と同じ ・Preemptible VM に取って代わる存在 (GKE クラスタ作成時には Spot VM しか使えない) (出典: https://cloud.google.com/compute/docs/instances/spot)
  12. 12. Preemptible VM / Spot VM の メリット・デメリット 12
  13. 13. 13 Preemptible VM / Spot VM のメリット・デメリット Preemptible VM Spot VM メリット デメリット
  14. 14. 14 Preemptible VM / Spot VM のメリット・デメリット Preemptible VM Spot VM メリット ・金銭的コストがかなり低い ・金銭的コストがかなり低い デメリット
  15. 15. 15 Preemptible VM / Spot VM のメリット・デメリット Preemptible VM Spot VM メリット ・金銭的コストがかなり低い ・金銭的コストがかなり低い デメリット ・24時間に一度 Preempt される ・予期せぬタイミングで Preempt される
  16. 16. 16 Preemptible VM / Spot VM のメリット・デメリット Preemptible VM Spot VM メリット ・金銭的コストがかなり低い ・金銭的コストがかなり低い デメリット ・24時間に一度 Preempt される → 1. 可用性の低下 ・予期せぬタイミングで Preempt される → 1. 可用性の低下
  17. 17. 17 Preemptible VM / Spot VM のメリット・デメリット Preemptible VM Spot VM メリット ・金銭的コストがかなり低い ・金銭的コストがかなり低い デメリット ・24時間に一度 Preempt される → 1. 可用性の低下 → 2. 運用コストの増加 ・予期せぬタイミングで Preempt される → 1. 可用性の低下 → 2. 運用コストの増加
  18. 18. 18 デメリット①(可用性の低下) 可用性低下の原因 1 Preempt 時に突如いっぺんに Pod が終了されてしまう → PodDisruptionBudget が効かないため、動いて欲しい replica 数が保証できない(一定のレプ リカ数を最低でも必要とするようなアプリケーションだと特に影響が大きい → Kubernetes v1.20 以降で有効化された kubelet graceful node shutdown により、Node, Pod の終了は graceful に行われる → ちなみに Kubernetes v1.20 よりも前のバージョンだと、kubernetes からは Node, Pod が突 如使用不能になったように見え、 graceful shutdown することもない
  19. 19. 19 デメリット①(可用性の低下) 可用性低下の原因 2 terminationGracePeriodSeconds が最大でも 25 秒になってしまう → Preempt により Node が強制的にシャットダウンされるため、Pod の終了処理開始からコンテ ナの強制終了までの時間が最大でも(約) 25 秒になってしまう → リクエストが集中した場合や、処理に時間がかかった場合などに、graceful shutdown が完了 する前にコンテナが強制終了され、処理が中断されることがある
  20. 20. 20 デメリット①(可用性の低下) 可用性低下の原因 3 Node が複数同時に再起動された場合 → いっぺんに Pod がスケジュールし直され起動しようとすると、Node のリソースを奪い合ってし まい、起動までに時間がかかることがある → Liveness Probe の設定によっては、無限に再起動されるようになってしまう場合もありうる → その間、Pod は処理を行うことができないため可用性低下に繋がる
  21. 21. 21 デメリット②(運用コストの増加) 運用コストが増えてしまうケース
  22. 22. 22 デメリット②(運用コストの増加) 運用コストが増えてしまうケース 1. リソースを節約している場合 → Node 数と replica 数、resource request の設定によっては、Pending な Pod が残り続けてし まいマニフェストに設定した replica 数よりも少ない Pod しか動かないことがある → Cluster Autoscaler などを利用していない場合、Node Pool のサイズを上げて Pod をスケ ジュールさせてから drain して.... など手作業が必要となりうる
  23. 23. 23 デメリット②(運用コストの増加) 運用コストが増えてしまうケース 1. リソースを節約している場合 → Node 数と replica 数、resource request の設定によっては、Pending な Pod が残り続けてし まいマニフェストに設定した replica 数よりも少ない Pod しか動かないことがある → Cluster Autoscaler などを利用していない場合、Node Pool のサイズを上げて Pod をスケ ジュールさせてから drain して.... など手作業が必要となりうる 2. Node が複数同時に再起動された場合 → いっぺんに Pod がスケジュールし直され起動しようとすると、Node のリソースを奪い合ってし まい、起動までに時間がかかることがある → この場合、Pod を手作業で削除して別 Node にスケジュールされるようにするなどの手作業 が必要となりうる
  24. 24. 24 デメリットまとめ 要するに....
  25. 25. 25 デメリットまとめ 要するに.... ・こういう用途なら使えるかな?と思っても意外と用途が限定される
  26. 26. 26 デメリットまとめ 要するに.... ・こういう用途なら使えるかな?と思っても意外と用途が限定される ・条件を気にしてお守りをしないといけないので、インフラ実費は節約できても 結局人的コストが高く付いてしまう 😕😕
  27. 27. Preemptible VM / Spot VM で金銭的コストを抑えつつ、 これらのデメリットを無くせないか...? 27
  28. 28. Preemptible VM / Spot VM で金銭的コストを抑えつつ、 これらのデメリットを無くせないか...? 28 作っちゃおう!
  29. 29. Panope とは 29
  30. 30. 30 Panope とは 『インフラコストを削減しながら可用性を維持できるソフトウェア』 もう少し詳しく言うと...
  31. 31. 『インフラコストを削減しながら可用性を維持できるソフトウェア』 もう少し詳しく言うと... 『GKE において Node のシャットダウンのタイミングを制御し、 Preemptible VM / Spot VM でも可用性を保って運用できるよう処理するこ とで全自動でコストを抑えてくれるソフトウェア』 31 Panope とは
  32. 32. Panope を使ってみた結果 32
  33. 33. 33 本番環境に導入してみた ・株式会社 WESEEK の GROWI.cloud というサービスに本番導入 ・GROWI.cloud は Markdown Wiki サービスを提供する SaaS ・GROWI.cloud の個人向けプランでは、サービスを安価に提供する代わりに 法人 向けプランと比較してSLOをやや妥協しつつもPreemptible VM での運用をしてい た
  34. 34. 34 Panope を使ってみた結果 GROWI.cloud に導入してみた結果...(6/10 に導入開始) 冗長化していないPod (シングルレプリカ)の可用性の1日間平均 99.52%
  35. 35. 35 Panope を使ってみた結果 GROWI.cloud に導入してみた結果...(6/10 に導入開始) 冗長化していないPod (シングルレプリカ)の可用性の1日間平均 99.97% 99.52% 99.5%台だった可用性 が 99.9%後半に UP!
  36. 36. 36 Panope を使ってみた結果 冗長化していないPod (シングルレプリカ)の可用性の7日間平均 99.59%
  37. 37. 37 Panope を使ってみた結果 冗長化していないPod (シングルレプリカ)の可用性の7日間平均 99.97% 99.59% 99.5%台だった可用性 が 99.9%後半に UP!
  38. 38. 38 Panope を使ってみた結果 冗長化しているPod (複数レプリカ)の可用性の7日間平均 99.95%
  39. 39. 39 Panope を使ってみた結果 冗長化しているPod (複数レプリカ)の可用性の7日間平均 99.98% 99.95% 99.95% だった可用性 が 99.98% に UP!
  40. 40. 40 Panope をおすすめしたい対象 Panope は特に以下のような考えを持つ組織におすすめです ・すでに Preemptible VM, Spot VM を使って GKE を運用しているが、可用性の維持や運 用コストに悩んでいる ・本番環境や開発環境用の GKE を安く使いたいけど、それによって人的コストが増えるの は嫌 ・フロントとサーバーなどチームが完全に分離しており、開発環境が止まると影響範囲が 大きく、開発環境の可用性もある程度担保したいものの、金銭的コストも抑えたい
  41. 41. Panope の基本機能とアーキテクチャ 41
  42. 42. 1. Preemptible VM / Spot VM を Preempt される前に graceful shutdown → GCE により Preempt される前に Panope のタイミングでシャットダウンすることで、必要数の Pod を 残しながら安全に Node を入れ替える 2. シャットダウンする Node の代わりとなる Node を事前にプロビジョニングし、Pod を退避さ せる → スペック不足でスケジュールされない Pod をケア 3. 事前に Node を cordon してから 1replica の Deployment のみ Rollout → 1replica かつ strategy: RollingUpdate な Deployment についてもダウンタイムが発生しないように 42 Panope の基本機能
  43. 43. 1. Preemptible VM / Spot VM を Preempt される前に graceful shutdown → GCE により Preempt される前に Panope のタイミングでシャットダウンすることで、必要数の Pod を 残しながら安全に Node を入れ替える 2. シャットダウンする Node の代わりとなる Node を事前にプロビジョニングし、Pod を退避さ せる → スペック不足でスケジュールされない Pod をケア 3. 事前に Node を cordon してから 1replica の Deployment のみ Rollout → 1replica かつ strategy: RollingUpdate な Deployment についてもダウンタイムが発生しないように 43 Panope の基本機能
  44. 44. 1. Preemptible VM / Spot VM を Preempt される前に graceful shutdown → GCE により Preempt される前に Panope のタイミングでシャットダウンすることで、必要数の Pod を 残しながら安全に Node を入れ替える 2. シャットダウンする Node の代わりとなる Node を事前にプロビジョニングし、Pod を退避さ せる → スペック不足でスケジュールされない Pod をケア 3. 事前に Node を cordon してから 1replica の Deployment のみ Rollout → 1replica かつ strategy: RollingUpdate な Deployment についてもダウンタイムが発生しないように 44 Panope の基本機能
  45. 45. 1. Preemptible VM / Spot VM を Preempt される前に graceful shutdown → GCE により Preempt される前に Panope のタイミングでシャットダウンすることで、必要数の Pod を 残しながら安全に Node を入れ替える 2. シャットダウンする Node の代わりとなる Node を事前にプロビジョニングし、Pod を退避さ せる → スペック不足でスケジュールされない Pod をケア 3. 事前に Node を cordon してから 1replica の Deployment のみ rollout → 1replica かつ strategy: RollingUpdate な Deployment についてもダウンタイムが発生しないように 45 Panope の基本機能
  46. 46. controller… agent へ GKE クラスタ内の Spot / Preemptible VM に対する操作内容を命令するコンポーネン ト。7knot 側のクラスタで管理している。 agent… controller からの命令を実行するコンポーネン ト。サービス利用者側の GKE クラスタにインストールする。 インストールには helm chart を用いる。 observer... Panope が処理を開始するために必要な annotation の操作など、Spot / Preemptible VMごとに必要 な処理を行うコンポーネント。agent と同様に、サービス利用 者側の GKE クラスタにインストールする。agent と同じ helm chart でインストールされる。 46 Panope のアーキテクチャ Panope helm chart: https://github.com/7knot/helm-charts
  47. 47. controller… agent へ GKE クラスタ内の Spot / Preemptible VM に対する操作内容を命令するコンポーネン ト。7knot 側のクラスタで管理している。 agent… controller からの命令を実行するコンポーネン ト。サービス利用者側の GKE クラスタにインストールする。 インストールには helm chart を用いる。 observer... Panope が処理を開始するために必要な annotation の操作など、Spot / Preemptible VM ごとに必要 な処理を行うコンポーネント。agent と同様に、サービス利用 者側の GKE クラスタにインストールする。agent と同じ helm chart でインストールされる。 47 Panope のアーキテクチャ Panope helm chart: https://github.com/7knot/helm-charts
  48. 48. controller… agent へ GKE クラスタ内の Spot/ Preemptible VM に対する操作内容を命令するコンポーネン ト。7knot 側のクラスタで管理している。 agent… controller からの命令を実行するコンポーネン ト。サービス利用者側の GKE クラスタにインストールする。 インストールには helm chart を用いる。 observer... Panope が処理を開始するために必要な annotation の操作など、Spot / Preemptible VM ごとに必要 な処理を行うコンポーネント。agent と同様に、サービス利用 者側の GKE クラスタにインストールする。agent と同じ helm chart でインストールされる。 48 Panope のアーキテクチャ Panope helm chart: https://github.com/7knot/helm-charts
  49. 49. controller… agent へ GKE クラスタ内の Spot / Preemptible VM に対する操作内容を命令するコンポーネン ト。7knot 側のクラスタで管理している。 agent… controller からの命令を実行するコンポーネン ト。サービス利用者側の GKE クラスタにインストールする。 インストールには helm chart を用いる。 observer... Panope が処理を開始するために必要な annotation の操作など、Spot / Preemptible VM ごとに必要 な処理を行うコンポーネント。agent と同様に、サービス利用 者側の GKE クラスタにインストールする。agent と同じ helm chart でインストールされる。 49 Panope のアーキテクチャ Panope helm chart: https://github.com/7knot/helm-charts
  50. 50. Panope の仕組み 50
  51. 51. agent controller 51 Panope の仕組み
  52. 52. agent controller 1. クラスタ内の全 Spot / Preemptible VM の情 報を送ってくるように命令 52 Panope の仕組み
  53. 53. agent controller 1. クラスタ内の全 Spot / Preemptible VM の情 報を送ってくるように命令 2. 全 Spot / Preemptible VM の情 報取得 53 Panope の仕組み
  54. 54. agent controller 1. クラスタ内の全 Spot / Preemptible VM の情 報を送ってくるように命令 2. 全 Spot / Preemptible VM の情 報取得 3. クラスタ内の全 Spot / Preemptible VM の情報を返す 54 Panope の仕組み
  55. 55. agent controller 1. クラスタ内の全 Spot / Preemptible VM の情 報を送ってくるように命令 2. 全 Spot / Preemptible VM の情 報取得 3. クラスタ内の全 Spot / Preemptible VM の情報を返す 4. 全 Spot / Preemptible VM の情報を元に各 Spot / Preemptible VM に必要な 処理を思考 55 Panope の仕組み
  56. 56. agent controller 1. クラスタ内の全 Spot / Preemptible VM の情 報を送ってくるように命令 2. 全 Spot / Preemptible VM の情 報取得 3. クラスタ内の全 Spot / Preemptible VM の情報を返す 4. 全 Spot / Preemptible VM の情報を元に各 Spot / Preemptible VM に必要な 処理を思考 5. 必要な処理を Spot / Preemptible VM ごとに送信 56 Panope の仕組み
  57. 57. 1. UpdateAnnotations 2. CordonNode 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 57 処理の流れ
  58. 58. 1. UpdateAnnotations 2. CordonNode 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 58 処理の流れ
  59. 59. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 59 処理の流れ
  60. 60. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 60 処理の流れ
  61. 61. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 61 処理の流れ
  62. 62. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 62 処理の流れ
  63. 63. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 63 処理の流れ
  64. 64. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment 5. DrainNode 6. DeleteNode 64 処理の流れ
  65. 65. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode 6. DeleteNode 65 処理の流れ
  66. 66. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode 6. DeleteNode 66 処理の流れ
  67. 67. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode : Node から Pod を退避させる 6. DeleteNode 67 処理の流れ
  68. 68. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode : Node から Pod を退避させる 6. DeleteNode 68 処理の流れ
  69. 69. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode : Node から Pod を退避させる 6. DeleteNode : 空っぽになった Node を削除 69 処理の流れ
  70. 70. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode : Node から Pod を退避させる 6. DeleteNode : 空っぽになった Node を削除 70 処理の流れ
  71. 71. 1. UpdateAnnotations : Node の削除処理を開始する時間を annotation で付与 2. CordonNode : annotation を元に対象の Node を cordon 3. CreateNode : Pod の evict 先となる新 Node をプロビジョニング 4. RollingUpdateSingleReplicaDeployment : 1replica の Deployment をケア 5. DrainNode : Node から Pod を退避させる 6. DeleteNode : 空っぽになった Node を削除 71 処理の流れ この一連の動作を Panope draining と呼んでいます
  72. 72. annotations: panope.net/boot-time: "2022-02-08T19:49:09Z" panope.net/time-to-kill-node: "2022-02-09T07:08:09Z" annotations: panope.net/boot-time: "2022-02-08T18:00:59Z" panope.net/time-to-kill-node: "2022-02-09T04:12:59Z" boot-time に一定の時間を加算した時刻を time-to-kill-node として annotation に付与 (処理のタイミングが被らないように 3分以上の間隔を開けるようにしている ) Observer Observer Node1 Node2 72 処理の流れ①(UpdateAnnotations)
  73. 73. Spec: Unschedulable: true 2022-02-09T05:12:59Z(Annotation の時刻+1h) Node1 Node2 73 Observer Observer 処理する際の時刻が time-to-kill-node の時刻を過ぎていた場合、 Node を cordon し Pod がスケジュールできないようにする 処理の流れ②(CordonNode) annotations: panope.net/boot-time: "2022-02-08T18:00:59Z" panope.net/time-to-kill-node: "2022-02-09T04:12:59Z" annotations: panope.net/boot-time: "2022-02-08T19:49:09Z" panope.net/time-to-kill-node: "2022-02-09T07:08:09Z"
  74. 74. annotations: panope.net/need-to-create-node: "true” agent が Google Cloud API を使って Node をプロビジョニング need-to-create-node の annotation があった場合、新 Node をプロビジョニング Node2 Node3 Node1 74 Observer Observer Observer 処理の流れ③(CreateNode)
  75. 75. cordon した Node 上に 1Pod の Deployment がいた場合、rollout する Node2 Node3 Node1 75 Observer Observer Observer SingleReplica Deployment 1Pod で strategy: RollingUpdate な Deployment を rollout rollout した Deployment の新 Replicaset の Pod が作成される 処理の流れ④(RollingUpdateSingleReplicaDeployment)
  76. 76. 『Daemonset に属する Pod』 と 『kube-system namespace の kube-dns 以外の Pod を除く Pod 』を全て drain の対象として、対象の Node に載るそれらの Pod を drain する Node2 Node3 Node1 76 Observer Observer Observer evict すべき Pod が存在したらそれらを evict Pod が evict されてくる 処理の流れ⑤(DrainNode)
  77. 77. drain が完了したら cordon されていた Node を削除 Node2 Node3 Node1 77 Observer Observer Observer agent が Google Cloud API を使って Node をシャットダウン 処理の流れ⑤(DeleteNode)
  78. 78. Observer Observer Node2 Node3 78 古い Preemptible VM / Spot VM (Node1) が 24h 立つ前に削除され、 新たな Preemptible VM / Spot VM (Node3) で Pod が動く 1周が終わると...
  79. 79. その他 Preempt への対処法 79
  80. 80. 80 その他 Preempt への対処法① → Pod の終了開始時点で存在するコネクションをいきなり中断させることのないよ う、処理し終わるまで終了を待つような実装を行うことで、処理が中断されてしまうリ クエストを減らす Graceful shutdown の導入
  81. 81. 81 その他 Preempt への対処法② spec: containers: - name: web image: nginx:latest ports: - containerPort: 80 name: web lifecycle: preStop: exec: command: ["sh", "-c", "sleep 5"] preStop の設定 ・コンテナが終了する直前に呼び出されるフックのこと → SIGTERM は preStop 終了後に送られる ・exec / httpGet / tcpSocket の 3 種類から選択できる ・このフックが失敗した場合、コンテナは強制終了する preStop とは?
  82. 82. 82 その他 Preempt への対処法② → Pod の終了時には、非同期で コンテナのシャットダウン ・endpoint からの除外・Owner からの解放 が行われる → その際、endpoint からの除外 よりも先に コンテナのシャットダウン が行われてしまう と、リクエストを処理できない Pod にリクエストが転送されてしまう → これを防ぐために、preStop で一定の時間 sleep させるなどして kubelet からの SIGTERM を遅らせることで、先に endpoint からの除外 を完了させる → また、preStop でアプリに通知して Readiness Probe を失敗させることで SIGTERM が 送られる前に endpoint から除外させることも可能 preStop の設定
  83. 83. その他の悩み... 83
  84. 84. 84 その他の悩み Kubernetes 運用する中で手間がかかる作業って...?
  85. 85. 85 その他の悩み Kubernetes 運用する中で手間がかかる作業って...? Kubernetes クラスタのバージョンアップ!!!
  86. 86. 86 その他の悩み Kubernetes 運用する中で手間がかかる作業って...? Kubernetes クラスタのバージョンアップ!!! ・ダウンタイムを作りたくない (複数クラスタあればなぁ ... ・全体のリソースを減らしたくない (スケジュールされない Pod が出るかも... ・時間をかけたくない (作業時間取られるし自動化できたらなぁ ...
  87. 87. 87 その他の悩み Kubernetes 運用する中で手間がかかる作業って...? Kubernetes クラスタのバージョンアップ!!! ・ダウンタイムを作りたくない (複数クラスタあればなぁ ... ・全体のリソースを減らしたくない (スケジュールされない Pod が出るかも... ・時間をかけたくない (作業時間取られるし自動化できたらなぁ ... 気にしないといけないことが多い!!!
  88. 88. Panope のその他の機能 88
  89. 89. 89 Panope のその他の機能① Kubernetes バージョンオートアップグレード機能
  90. 90. 90 Panope のその他の機能① Kubernetes バージョンオートアップグレード機能 → Node Pool に panope.net/auto-upgrade-kubernetes-enabled のラベルを付与すること で有効化できる → メンテナンスウィンドウの設定や、アップデートするバージョンの幅 (パッチ・マイナー など) も設定できる → アップデート時には、 Panope が以下の処理を順に行う 1. Node Pool を新設する 2. 旧 Node Pool の Panope draining を行う 3. 旧 Node Pool を削除する
  91. 91. 91 Panope のその他の機能① Kubernetes バージョンオートアップグレード機能 → Node Pool に panope.net/auto-upgrade-kubernetes-enabled のラベルを付与すること で有効化できる → メンテナンスウィンドウの設定や、アップデートするバージョンの幅 (パッチ・マイナー など) も設定できる → アップデート時には、 Panope が以下の処理を順に行う 1. Node Pool を新設する 2. 旧 Node Pool の Panope draining を行う 3. 旧 Node Pool を削除する ダウンタイム無し・リソースの減少無し・全自動!!
  92. 92. 92 Panope のその他の機能② 在庫枯渇時の failover
  93. 93. 93 Panope のその他の機能② 在庫枯渇時の failover → Preemptible VM / Spot VM には GCE 側の在庫枯渇により、新規に Preemptible VM / Spot VM をプロビジョニングできないことが起こりうる
  94. 94. 94 Panope のその他の機能② 在庫枯渇時の failover → Preemptible VM / Spot VM には GCE 側の在庫枯渇により、新規に Preemptible VM / Spot VM をプロビジョニングできないことが起こりうる → この在庫枯渇は、時間の経過に伴って GCE 側のリソースに空きが出ると解消され る
  95. 95. 95 Panope のその他の機能② 在庫枯渇時の failover → Preemptible VM / Spot VM には GCE 側の在庫枯渇により、新規に Preemptible VM / Spot VM をプロビジョニングできないことが起こりうる → この在庫枯渇は、時間の経過に伴って GCE 側のリソースに空きが出ると解消され る → 在庫枯渇が起きた場合、 Panope draining のうち、CreateNode が正常に完了しな い
  96. 96. 96 Panope のその他の機能② 在庫枯渇時の failover → Preemptible VM / Spot VM には GCE 側の在庫枯渇により、新規に Preemptible VM / Spot VM をプロビジョニングできないことが起こりうる → この在庫枯渇は、時間の経過に伴って GCE 側のリソースに空きが出ると解消され る → 在庫枯渇が起きた場合、 Panope draining のうち、CreateNode が正常に完了しな い → 『在庫枯渇が発生した際には標準 VM の Node Pool を一時的に作成し、在庫枯渇 が終了してから Preemptible VM / Spot VM をプロビジョニングする』 という機能により 在庫枯渇の影響を回避する
  97. 97. ここまでのまとめ 97
  98. 98. 98 ここまでのまとめ 1. Preemptible VM / Spot VM にはいくつかデメリットがある → 可用性の低下、運用コストの増加 2. 上記のデメリットへの対策として Panope を作成 → Panope は、Panope draining という一連の処理によって可用性を維持しつつ Preemptible VM / Spot VM での運用を可能にする 3. Panope に加えて可用性を低下させない方法もある → preStop の設定、graceful shutdown の実装などで可用性の低下防止が見込める 4. Panope には付随機能もある → Kubernetes バージョンオートアップグレード機能や在庫枯渇時の failover 機能などがある
  99. 99. Panope のこれから 99
  100. 100. 100 Panope のこれから 1. GKE 以外のパブリッククラウドへの対応 → EKS, AKS などにも対応することで利便性を上げる 2. Spot VM に対しても Preempt のタイミングを予測 → Spot VM に対して、Panope による Node の処理開始をもっとストリクトにやることでさらなる 節約を狙うことができる 3. Kubernetes や GKE の新機能に追従していく → Kubernetes 本体や GKE から新機能が出ることで、さらに可用性を高める工夫の幅が広がる ので随時 Panope のアップデートを行っていく
  101. 101. appendix 101
  102. 102. annotations: panope.net/boot-time: "2022-02-08T18:00:59Z" panope.net/time-to-kill-node: "2022-02-09T04:12:59Z" Observer Node1 102 ・現状、Preemptible VM に最適化しているため Spot VM への最適化はこれからの課題 ・ただし、基本的には Preemptible VM よりも Spot VM の生存期間の方が長いため、 Spot VM でも有 用性はある time-to-kill-node の時刻について ・boot-time に一定の時間を加算した時刻を time-to-kill-node として annotation に付与
  103. 103. 103 ・Drain が完了しプロビジョニングされた Node が利用されるタイミングでその annotation を外すことで、Cluster Autoscaler からの保護が必要な場合以外は Node が Cluster Autoscaler による管理対象となるような仕組み ・Panope が特定の Node の cordon / drain を行う際に、事前にプロビジョニン グしたばかりの Node には専用のannotation (cluster-autoscaler.kubernetes.io/scale-down-disabled)を付与することで Cluster Autoscaler による削除を防ぐ Cluster Autoscaler との共存について ・Panope は Cluster Autoscaler との共存が可能
  104. 104. 104 最後に コロナウイルスの影響もありオフラインイベントでの登壇が初めてなので、 こういった機会をご用意していただきとても嬉しいです 👏👏 今日は弊社の CTO (@mugiokax) やメンバーもみんな来ているので、みなさま是非是 非この後でもいつでもお話ししましょう! 「こういうケースでも Panope 採用できそう?」などといった相談にも乗れますし、 技術の話や、おうち Kubernetes の話もぜひぜひ🙈

×