Kubernetes実践トラブルシューティング

以下イベントの発表資料です。
https://k8sjp.connpass.com/event/218143/

Transcript

1. Kubernetes 実践トラブルシューティング Aug. 26th, 2021 sat@サイボウズ ストレージチーム 1
2. はじめに ▌サイボウズのインフラ基盤はKubernetesクラスタ ▌ストレージもK8sクラスタ上に構築 ⚫Rook/Ceph(後述)によって分散ストレージを提供 ▌ストレージ開発中に発生した問題を例にトラブル シューティングのノウハウを共有 ⚫ストレージ、Rook/Cephについての前提知識は不要 2
3. このセッションで学べること ▌実際に起きた問題のトラブルシューティングの流れ ▌なぜその調査をしたのか、という思考プロセス ▌ログやメトリクスの重要性 3
4. もくじ ▌Rook/Ceph概要 ▌サイボウズのRook/Cephクラスタと監視/ログ基盤 ▌トラブル解析事例 ▌まとめ 4
5. Rook/Ceph概要 5
6. Cephとは ▌OSSのスケーラブルな分散ストレージ ⚫多くの種類のストレージを提供可能(後述) ⚫ペタバイトスケールのデータを扱える ▌20年以上にわたって幅広く使われてきた ⚫CERN, NASA ▌主な開発元はRed Hat ⚫Red Hat Ceph Storageなどの製品を提供 6
7. 提供するストレージの種類 ▌S3互換オブジェクトストレージRGW ⚫今日取り扱うのはこれ ▌ブロックデバイスRBD ▌分散ファイルシステムCephFS 7
8. アーキテクチャ 8 アプリ ストレージプール Ceph node node node … RBD RGW ブロックデバイス オブジェクト ブロックデバイス ブロックデバイス オブジェクト オブジェクトストレージ CephFS ブロックデバイス ブロックデバイス 分散ファイルシステム
9. ▌RGWが提供するendpointにアプリがアクセス オブジェクトストレージの使い方 9 Rook/Cephクラスタ アプリ RGW daemon
10. Rookとは ▌Kubernetes上で動作するCephのオーケストレータ ⚫CNCFのgraduated Project ▌主な開発元 ⚫Red Hat, サイボウズ ▌製品 ⚫Red Hat OpenShift Container Storage 10
11. Rook/Ceph関連コンポーネント 11 K8sクラスタ Rook/Cephクラスタ オブジェクト ストレージ ブロック ストレージ HDD node HDD アプリ Rook/Cephオペレータ CephCluster CR 操作 参照
12. オブジェクトストレージの使い方 12 K8sクラスタ Rook/Cephクラスタ アプリのPod RGW Pod
13. サイボウズの Rook/Cephクラスタと監視/ログ基盤 13
14. なぜRook/Cephなのか ▌商用製品はできれば避けたい ⚫ユーザデータは極めて重要 ⚫データ消失するとお客様もサイボウズも大ダメージ ⚫無いものは無い。取り返しがつかない ⚫商用製品には勝手に手を入れられない ⚫トラブル発生時にとれる手段が減る ▌OSSの自前運用が有力な選択肢 ⚫Rook/Cephが要件を満たしていた 14
15. サイボウズのRook/Cephクラスタ 15 K8sクラスタ Rook/Cephクラスタ (HDD) オブジェクト ストレージ ブロック ストレージ HDD node node SSD HDD HDD SSD NVMe SSD アプリ Rook/Cephクラスタ (NVMe SSD) ブロック ストレージ
16. 開発/運用プロセス 1. 検証&構築&実機上で運用 2. 課題が見つかる ⚫基本はupstreamで修正&次回の新版を使う ⚫マージまで一時的に独自版運用 and/or パラメタ設定で回避 ⚫マージ不可能ならば上記の運用を続けることも許容 3. 1に戻る 16
17. 監視/ログ基盤 17 Rook/Cephクラスタ Loki (ログ基盤) VictoriaMetrics (監視基盤) オブジェクト ストレージ ブロック ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard アプリ監視用 Rook/Ceph監視用
18. 監視/ログ基盤の使い方(1/4) 18 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ①メトリクス収集 ①ログ収集
19. 監視/ログ基盤の使い方(2/4) 19 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ②通知
20. 監視/ログ基盤の使い方(3/4) 20 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ③操作
21. 監視/ログ基盤の使い方(4/4) 21 Rook/Cephクラスタ Loki (ログ基盤) オブジェクト ストレージ HDD node node SSD HDD HDD SSD NVMe SSD VictoriaMetrics (監視基盤) Grafana Dashboard ④クエリ発行
22. 監視/ログ基盤の嬉しさ ▌システムのログやメトリクスを一か所に保存できる ▌システム全体の長期的な挙動がわかる ⚫ 「正常なときと異常なときと何が違うか」など ⚫ クエリ言語(PromQL, LogQL)により一括して情報を取得可能 ▌システムにおかしなことがあれば技術者に通知できる ⚫ 技術者が常にダッシュボードを監視していなくてよい 22
23. トラブル解析事例 23
24. 発生した問題 ▌RGW podが落ちたというAlertが数十秒に1回飛んできた ▌考えられる可能性 ⚫ Pod内でエラーが起きて死んでいる ⚫ {liveness,readiness}Probeで死んでいる ▌可能性は五分五分なので上から順番に 24 Rook/Cephクラスタ(HDD) RGW Pod
25. Pod内で死んでいるかどうかの確認 ▌ログを見る ⚫DashboardからLokiのログを確認 ▌以下のようなログが繰り返し出力されていた ▌“…lock failed”というメッセージは問題ないとわかった ▌しかし自ら強制終了した形跡はない - NOTICE: resharding operation on bucket index detected, blocking - RGWReshardLock::lock failed to acquire lock on loki-bucket-XXX ret=-16 25
26. {liveness,readiness}Probeの発生有無を確認 ▌Podに起きたイベントを確認 ▌livenessProbeで殺され続けていた ▌Next action ⚫livenessProbeで何をチェックしているか確認 $ kubectl –n ceph-hdd describe pod rook-ceph-rgw-XXX … Events: … spec.containers{rgw} Warning Unhealthy Liveness probe failed:… 26
27. livenessProbeの設定を確認 ▌RGW Podの定義を見る ▌Endpointは”swift/healthcheck” ▌Next action ⚫上記endpointの意味を調べる $ kubectl get pod rook-ceph-rgw-XXX –o yaml … livenessProbe: … httpGet: path: /swift/healthcheck … 27
28. /swift/healthcheckの意味を調査 1. Web検索&ソース調査 2. RGWのサービスが生きていれば成功するとわかった 3. ダッシュボードからRGWのオブジェクト数を確認 28 オブジェクト数→ 時間→ • 全然増えていない • 普段はLokiが作るオブジェクトが 定期的に増える
29. 状況の整理 ▌明らかになったこと 1. RGWのサービスが停止している 2. livenessProbeの使い方を間違えている ⚫ livenessProbe: Podの正常動作可否を確認 ⚫ readinessProbe: サービス提供可否を確認 ▌Next action ⚫重要度が高い①を先に調査 29
30. なぜサービスが停止するのかを調査 ▌RGW podのログを再び確認 ▌Dynamic resharding(後述)という処理が繰り返し動いている 0 block_while_resharding ERROR: bucket is still resharding, please retry 0 check_bucket_shards: resharding needed: … 0 check_bucket_shards: resharding needed: … … 0 NOTICE: resharding operation on bucket index detected, blocking 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000009 ret=-16 1 RGWRados::check_bucket_shards bucket loki-bucket-XXX needs resharding; … 30
31. Dynamic reshardingとは ▌resharding ⚫1つのbucketに対して1つindexが存在 ⚫ オブジェクト名からオブジェクトの場所を引く ⚫Indexは複数の領域にshardされている ⚫オブジェクト数増加にって検索速度が劣化 ⚫速度の劣化はreshardによって防げる ▌Dynamic resharding ⚫オブジェクト数が増えてくると自動的にreshardする機能 31
32. 仮説 ▌以下のようにreshard処理が永久に終わらない 1. オブジェクト数が増えたためdynamic resharding発動 2. Reshard中は/swift/healthcheckを叩くと失敗 3. ゆえにRGW PodのlivenessProbeが失敗 4. Podが殺される 5. Reshard処理が中断 6. 1に戻る ▌Next Action ⚫実際にそうなっているか確認 32
33. Reshardのstatusを確認 ▌Reshard処理の進捗を確認 ▌定期的にreshard処理が失敗し続けていた ⚫ 仮説は裏付けられた $ radosgw-admin reshard status --bucket=loki-bucket-XXX [ { "reshard_status": "in-progress", "new_bucket_instance_id": “YYY", "num_shards": 419 }, { "reshard_status": "in-progress", "new_bucket_instance_id": “YYY", "num_shards": 419 }, … 33
34. 対策を考える ▌短期対策 ⚫今まさにオブジェクトストレージが使えない問題を解決 ▌中長期対策 ⚫次回以降問題を起きなくする ⚫短期対策の後で考える 34
35. 短期対策 ▌livenessProbeを無効化してreshardを実行 ▌手順 1. operatorを一時停止(deploymentのreplica数を0に) ⚫ 以下操作の後にoperatorがDeploymentを再度書き換えるのを防ぐ 2. RGWのDeploymentからlivenessProbeを削除 3. 手動でreshard処理を起動 4. reshard終わったらoperatorを再度動かす 35
36. 結果 ▌数十分後に無事終了 36 オブジェクト数→ 時間→ reshard開始 Reshard終了
37. 中期対策 ▌考えられる案 1. dynamic reshardingを無効化 2. 最初からshardの数を十分に増やしておく ▌ひとまず上記対処は見送り ⚫次に起きるのは数か月後 ⚫現状このストレージは可用性の保証がない ⚫他に優先すべきタスクがある 37
38. 長期対策 1. まずは過去事例調査 ⚫Rookにほぼ同じissueが報告されていた 2. Issueにコメントして議論開始 3. 長期対策向けの方針を決定 ⚫最新版のCephで再現させ、再現するならreshard処理中にサービス停 止をしなくするよう活動(自分でPR投げるかも) ⚫RookのlivenessProbeのありかたについて議論 38
39. 得られたもの ▌今後同じ問題を回避できるようになった ▌技術者の経験値が上がった ⚫今後の類似トラブル調査に当たりがつくようになった 39
40. その他トラシュー用のTIPS ▌システムに対して「いつ」「何をしたか」を常に記録 ⚫何か起きたときに発生契機を突き止めるためのヒントになる ▌調査中のログも可能な限り残す ⚫今後の調査に役立つ ▌最後にwikiなどにまとめる ⚫色々なところに情報が散らばっていると後から追いにくい ⚫そのうち記憶が無くなる 40
41. まとめ 41
42. 学んだこと ▌実際に起きた問題のトラブルシューティングの流れ ▌なぜその調査をしたのか、という思考プロセス ▌ログやメトリクスの重要性 42
43. 今後について ▌やること ⚫性能チューニング&可用性を高める ⚫技術者を育てる ⚫機能追加 ⚫ リモートレプリケーション ⚫ バックアップ/リストア ⚫既存データの移行 ▌一緒に働いてくれるかたを募集中! 43
44. 44 おわり