🧰
【GKE/GCE】メンテナンスイベント（ライブマイグレーション）が発生したどうかを確認する方法
結論
- GCP ConsoleのCloudLoggingページを開く
- ログの検索フィールドに以下の二つを追加
- resource.type="gce_instance"
- operation.producer="compute.instances.migrateOnHostMaintenance"
- ログを検索する
※ライブマイグレーションが発生したイベントログの取得方法になります。可用性ポリシーをデフォルトの設定から変更した場合は、メンテナンスイベントで異なるイベントログが出力される場合があります。
背景
GKEに構築したアプリケーションへのAPIリクエストがタイムアウトしました。
ログを追いかけていくと、Datastoreからデータをフェッチするのに数分かかっている様子だったので、GCPに問合せしたところ、Datastoreのフェッチに時間がかかっていたわけではないことがわかりました。
その後さらに調査をし、GKEのノードとして利用しているVMインスタンスのメンテナンスイベントがAPIリクエストと同じタイミングで発生していたことがわかりました。
VMインスタンスのメンテナンスイベントでは、ライブマイグレーションが実行されるため、処理中のpodが数分間スリープしてしまったことが原因でした。
解説
ライブマイグレーションとは
- 実行しているVMインスタンスの実行を継続したまま、別のホストへ移行するための仕組み
- 移行の際、Nodeの中身(メモリ、ディスク、ネットワーク)をまるごとスナップショットを取り、移行先のホストにコピーする
- 中身の初回コピーが終わったら、移行元のNodeはフリーズになり、中身の差分を移行先にコピーする
- フリーズが発生することによって、ネットワークを遅延させるなどの影響がある
メンテナンスイベントについて
- メンテナンスイベントでは、ハードウェアとソフトウェアを更新される
-
ホストメンテナンスと簡易メンテナンスの2種類がある -
ホストメンテナンスでは新しいホストへのライブ マイグレーションが必要 - メンテナンスイベントのスケジューリングは、自動で管理されているので、タイミングを指定することはできない
メンテナンスイベントでの動作設定（可用性ポリシー）
- メンテナンスイベントの動作を変更するには可用性ポリシーの設定を行います
- 設定できる可用性ポリシーは以下の2種類
- メンテナンスイベントでライブマイグレーションを行うか、VMインスタンスを停止するか
- VMインスタンスが停止した時に、再起動するか、しないか
- なので、メンテナンスイベントでは次の3種類の動作のいずれか行うことができます
- ライブマイグレーションする（スリープが発生するが、インスタンスはずっと実行したまま）
- いったん停止して、再起動する
- 停止したまま
GKEとメンテナンスイベントの設定
- GKEのノードとして利用しているVMインスタンスでもメンテナンスイベントは発生する
- GKEのノードして利用しているVMインスタンスのライブマイグレーションの設定を変更するこはできない
- なので、GKEでライブマイグレーションが発生することは避けられない
- GKE Autopilotでも同じくライブマイグレーションが発生することは避けられない
- ユーザーから機能追加のリクエストがきてはいるが、採用されるかはわからない
※公式ドキュメントに記載は見つけられませんでしたが、GCPの技術サポートに問い合わせて確認した内容です
GKEとライブマイグレーション
- ライブマイグレーションによりノードは移行先のホストに退避される
- Podは親であるNodeと共に、移行先のホストへ引っ越す
- ライブマイグレーションではPodは停止もしなければ新しく作成もされない
- イメージ
- 移行前: HostA( NodeX(PodY)) )
- 移行後: HostB( NodeX(PodY)) )
- 移行している間、フリーズが発生することによって、ネットワークを遅延させるなどの影響がある
※公式ドキュメントに記載は見つけられませんでしたが、GCPの技術サポートに問い合わせて確認した内容です
ライブマイグレーションが発生したログを取得する
- GCP ConsoleのCloudLoggingページを開く
- ログの検索フィールドに以下の二つを追加
- resource.type="gce_instance"
- operation.producer="compute.instances.migrateOnHostMaintenance"
- ログを検索する
Discussion