Resilience Engineering on Kubernetes

思い出すシリーズ

Transcript

1. Resilience Engineering on Kubernetes ワンターレンの夜明け 真壁 徹 日本マイクロソフト株式会社 2020/06/13 KubeFest Tokyo 2020
2. 自己紹介 apiVersion: selfIntroduction/v1 name: “真壁 徹(まかべ とおる)” company: name: “日本マイクロソフト株式会社” role: “クラウド ソリューションアーキテクト” education: name: “国立大学法人 北陸先端科学技術大学 院大学 先端科学技術研究科 先端科学技術専攻 情報科学系 セキュリティ・ネットワーク領域 博士前期 課程 東京社会人コース (在学中)” displayName: “JAIST M2 篠田研”
3. お伝えしたいこと Kubernetesはもっと強い子だと思っていたが 急所がある Kubernetesを安全性分析して 急所を洗い出してみよう 急所を理解したうえで 回復性の高いシステムを作ろう 宣言的構成管理する分散基盤の先行者から 一般化できる特徴を探る
4. 情報量多めです もし関心が湧いたら、後からスライドを見返して 再度味わっていただければ 幸せです
5. 自己回復 (Self-healing) Kubernetesの特徴として語られるもの
6. Why you need Kubernetes and what it can do Self-healing Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve. What is Kubernetes? – kubernetes.io
7. だがしかし Kubernetes Failure Stories
8. What Kubernetes is not Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems. What is Kubernetes? – kubernetes.io
9. Kubernetesはその上で動くコンテナーが自己回復でき るよう、様々な仕組みを提供するが Kubernetes自身の「包括的な」自己回復機能までは提 供しない
10. Kubernetesの上で動かすアプリはCloud Nativeに作ろ う！回復性は重要だね！と みなが言う ではKubernetes自身はどれだけCloud Nativeなのか
11. この調査の背景と動機 Kubernetesを活用したシステムの回復性を考えるために 急所を知る 壊れ方や急所を知ることで、回避や緩和の方針、手段を検討できる 私には仕事でのKubernetesの技術支援を通じ、知識や経験がある 急所を避ける使い方も分かってきた そして大学院での研究テーマは「分散基盤の/における回復性」 これは暗黙知を形式知として整理するいい機会ではないか アカデミックな手法を使って自分の知識や認識のバイアスを弱めたい
12. ところで 王大人(ワン ターレン)とは 漫画「魁!!男塾」の名物キャラ 男塾塾長代理 ラーメン大好き 中国三千年の秘を修めた医術と幻術の使い手 男たちの命を懸けた闘いの立会人を務める 有名なセリフ:「死亡確認」 人間の急所を熟知している
13. どうやって洗い出すか Kubernetesの壊れ方や急所を
14. Chaos Engineering 「ランダムに障害を注入して何かを発見する」手法？ Random strategies waste resources testing “uninteresting” faults, while programmer-guided approaches are only as good as the intuition of a programmer and only scale with human effort. Automating Failure Testing Research at Internet Scale. Alvaro, P et al. ACM Conference Proceedings 2016 pp: 17-28
15. 1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior. 2. Hypothesize that this steady state will continue in both the control group and the experimental group. 3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc. 4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group. CHAOS IN PRACTICE - PRINCIPLES OF CHAOS
16. 発見的手法だけでは効率が悪い 理解の浅いブラックボックスに対してランダムに障害を注入しても網羅性は低い 気づかない 全ての壊れ方 ツールと 思い付きの 限界 全ての壊れ方 構造から洗い出す (トップダウン分析) 発見的手法で トップダウン分析 を補完する 事前分析や仮説なし ランダム、思い付き 障害注入ツールの提供機能が網羅の限界 トップダウン分析、仮説検証 ランダムな障害注入で補完 分析とツールの限界を意識している 発見の積み上げには 時間がかかる
17. トップダウン分析の必要性 構造を理解し、起きうる障害を洗い出す 守る対象の構造、特徴を理解することから逃げていいのか 複雑なシステムは「理解できない」ではなく「できない部分もある」 Chaos Engineeringを提唱するNetflixはトップダウン分析とテストケー スの絞り込み(*)にも取り組んでいる トップダウン分析で壊れ方、急所を洗い出した上で、その注入にツー ルを活用するのは、あり (*) Linage-Driven Fault Injection - Automating Failure Testing Research at Internet Scale. Alvaro, P et al. ACM Conference Proceedings 2016 pp: 17-28
18. STPA(System-Theoretic Process Analysis)
19. STPAとは システム理論にもとづく分析手法 MITのNancy Leveson教授が提唱する安全性分析手法 従来の手法は個々のコンポーネントの信頼性分析と合成が主流 だがシステムは個々が正常でも組み合わせによって不具合が発生する STPAはコンポーネントの相互作用、創発特性に注目する (イベントチェーンなど) STAMP(System-Theoretic Accident Model and Processes)という事故 因果関係モデルを基礎理論とする
20. Control Plane App/Data Plane on Node State store (etcd) Scheduler kubelet Container Runtime API Server APIs Controller Manager Controllers Infrastructure API Node Features/ Configs kube-proxy Developer/ Admin (**)DaemonSetなど上位オブジェクトの表現は割愛 Admission Webhook(*) (*)Podに配置されることもある Kubernetes High-Level Architecture Pods(**)
21. Kubernetesの安全性分析に有用なのでは
22. STPAの流れ 1. 分析の目的を定義する 2. コントロールストラクチャーをモデル化する 3. 非安全なコントロールアクションを識別する 4. ハザードシナリオを識別する
23. 分析の目的を定義する STPA Step1
24. アクシデントとハザード、境界、安全制約を定義する アクシデント ハザード 境界 安全制約 顧客満足を失う H-1: 高遅延 Kubernetes クラスタ SC-1: Podが必要とする機能を提供、維持しなければならない (ConfigMap、Secret、名前解決など) [H-1, H-2, H-3] H-2: タイムアウト SC-2: Podに適切な量の資源を提供、維持しなければならない(CPU、 メモリ、ディスク性能など) [H-1, H-2, H-3] H-3: エラー応答 SC-3: Podがサービス提供するのに必要なクラスタ内ネットワーク経 路を提供、維持しなければならない [H-1, H-2, H-3] • アクシデント: 利害関係者にとって受け入れられない損失 • 人命への影響、設備の損失、ビジネスインパクトなど • この分析では一般的なビジネス用途を想定し、顧客満足の損失をアクシデントとする • ハザード: 一組の最悪ケースの環境条件で、損失につながるようなシステム状態、または一組の条件のこと • 顧客満足を得る、維持するために必要なサービスレベルを満たせていない状態 • サービスレベルの指標は、レスポンスタイムやHTTP応答のステータスコード正常率など • この分析では具体的な指標と目標の定義は割愛 • 境界 • 分析対象はKubernetesクラスタとし、環境構築や運用のためのツールは対象外とする（kubeadmなど） • 安全制約: ハザードを防ぐために満たす必要があるシステムの条件や動作 • この分析はKubernetesがアプリケーションPodを安全に動かすために守るべき制約にフォーカスする
25. コントロールストラクチャー をモデル化する STPA Step2
26. STPA Control Structure Controller Controller Controlled Process Control Algorithm Process Model Control Algorithm Process Model Control Action Feedback Control Action Feedback 権 限 高 低 Control Algorithm Process Model コントローラの意思決定プロセス (プログラムのロジックなど) コントローラが信じていること (被コントロールプロセスの状態など)
27. コントロールストラクチャーの例（自動車の定速走行・車間距離制御） STPA Handbook March 2018 日本語版v0.2
28. 何がハザードにつながるか？ Controller Controller Controlled Process Control Algorithm Process Model Control Algorithm Process Model Control Action Feedback Control Action Feedback 非安全なコントロールアク ション 不適切なプロセスモデル • コントロールアクションが 与えられない • 不適切なコントロールアク ションが与えられる • コントロールアクションが 早すぎる、遅すぎる、順序 が不適切 • (連続的な)コントロールアク ションが長く続き過ぎる、 停止が早すぎる • 間違ったフィードバックを 受け取る • フィードバックを受け取る が解釈を誤る、無視する • フィードバックを受け取ら ない（遅れる、または全く 受け取らない） • 必要なフィードバックが存 在しない コントローラの 故障 アルゴリズムの 不具合、バグ
29. Kubernetes Reconciliation Loop (突合せループ) 取得 照合 実行 API Serverへ 問い合わせ あるべき姿と現状を 突合せ 差分があれば 埋める
30. STPA High-Level Control Structure for Kubernetes API Server Controllers (Control Plane) Controlled Process Process Model Control Algorithm Control Action (CA) Controllers (App/Data Plane) Control Algorithm List & Watch (LW) 主にプロセスモデルの操作 を行う (例: Deployment Controller、Scheduler) プロセスモデルはAPI Serverに集約されている (実体はetcd) Podやノード設定などアプ リに必要な操作を行う (例: kubelet、kube-proxy) • 「不適切なフィードバッ ク」が原因で起こるハザー ドの多くを解決できる • プロセスモデルは集約され、 宣言した”望む状態”と現状 が格納される • 定期的にList & Watchするこ とでプロセスモデルは現状 を更新する • プロセスモデルの更新が一 時的に失敗してもいずれ追 いつく • 信頼できるプロセスモデル をもとに、宣言と現状の差 分を埋めるコントロールア クションを実行する Process Model (Cache) Process Model (Cache) 権 限 高 低 CA Feedback (*) CA LW (*)フィードバックの方法は被コントロールプロセスによる。 この分析ではclient-goを使ったAPI Serverへの継続的な問 い合わせのみをList & Watchとする。
31. 非安全なコントロールアク ションを識別する STPA Step3
32. 非安全なコントロールアクションを識別する前に 分析の前提条件 コンポーネント間の相互作用と構造上の安全性分析にフォーカス 各コンポーネントは冗長化され、単一故障に耐えると仮定 (複数サーバーへの配置、負荷分散装置の利用など) 各コンポーネントのコントロールアルゴリズムは適切と仮定 (十分なテストを行ったとする、また、バグはいずれ修正される) ハザードへ直接的に影響したコントロールアクションを識別 (トレーサビリティがあるので、原因は後からたどればいい) コンポーネント間に複数の操作がある場合、1つの識別子にまとめる (簡単のため)
33. きっと複雑なので サブシステムに分割しておく Control Plane Subsystem App/Data Plane Subsystem Developer/Admin CA API Server Controllers (Control Plane) Controlled Process CA Controllers (App/Data Plane) LW CA F CA LW F
34. App/Data Plane Subsystem Developer/ Admin API Server CA1 F1 kube-proxy kubelet Container Runtime Node Features / Configs Pods (Incl. System Pods. e. g. DaemonSet, Operator) CA2 F2 CA3 F3 CA9 F9 CA10 F10 CA6 LW6 CA7 F7 CA5 LW5 CA12 LW12 CA8 F8 CA4 F4 Infra. API CA11 F11
35. 非安全なコントロールアクション(Unsafe Control Action)の識別 コントロール アクション 与えられないと ハザード 与えられると ハザード 早すぎ、遅過ぎ、 誤順序 早すぎる停止、 長すぎる適用 CA-3 (kubelet to Container Runtime) • UCA-1: Podが正常に動作して いるが、relist処理の遅延など で、そう判断されない。結果、 ノードがNotReady状態と判断 され、サービス提供に必要な リソースが減少する[H-1] • UCA-2: ImagePullPolicy=Always設定 で短時間に大量のコンテ ナーを作成する。ネット ワーク帯域の圧迫だけでな く、レジストリに拒否され Podが作成できない[H-1] CA-4 (kubelet to Pod) • UCA-3: 敏感過ぎるliveness Probe設定によりPod再作成 が頻発し、サービス提供能 力が低下する[H-1] • UCA-4: Readiness Probeの不備で準 備不十分なPodへ トラフィックが 転送される[H-3] CA-5 (kubelet to API Server) • UCA-5: ノードが正常な状態に も関わらず、API Serverに伝 わらない。経路が問題の場合 はクラスター全体に影響が及 ぶ。例えば、ノード自動修復 機能がノード作成と削除をク ラスター全体で繰り返す [H-1, H-2, H-3] • UCA-6: 十分なAPI Server呼び 出しレートが設定されていな い[H-1, H-2, H-3] • UCA-7: API Serverが過剰に 呼び出され、API Serverが過 負荷状態に陥る[H-1, H-2, H-3]
36. 非安全なコントロールアクション(Unsafe Control Action)の識別 コントロール アクション 与えられないと ハザード 与えられると ハザード 早すぎ、遅過ぎ、 誤順序 早すぎる停止、 長すぎる適用 CA-7 (kube-proxy to Node Features/Configs) • UCA-8: iptables、conntrackな どIP転送に関する更新が行わ れない[H-3] • UCA-9: IP転送に 関する更新がコ ンポーネント間 で同期しない (IngressとPodの Endpointなど)[H- 3] CA-8 (Container Runtime to Node Features/Configs) • UCA-10: サービス提供に必要 なPodに十分なノードのリ ソースや優先度が割り当てら れない。リソース利用率が高 まると強制終了される[H-1, H-2, H-3] • UCA-11: 適切なSNATアルゴリ ズムなどサービスレベル遵守 に必要な設定が行われない [H-1] • UCA-12: サービス提供に貢 献度の低いPodに過剰な ノードのリソースや高い優 先度が割り当てられる。リ ソース利用率が高まると サービス提供に必要なPod やノードのプロセスが強制 終了される[H-1, H-2, H-3] • UCA-13: カーネルの監査ロ グ有効化などノード単位で 影響する負荷の高い設定が 行われる。Podに十分なリ ソースが割り当てられない [H-1]
37. 非安全なコントロールアクション(Unsafe Control Action)の識別 コントロール アクション 与えられないと ハザード 与えられると ハザード 早すぎ、遅過ぎ、 誤順序 早すぎる停止、 長すぎる適用 CA-9 (Container Runtime to Pod) • UCA-14: 過剰なDNS問い合 わせを行うよう設定される。 例えば既定のndots: 5設定を 見直していない[H-1, H-2, H-3] CA-11 (Pod to Infrastructure API) • UCA-15: Cluster Autoscalerに よるノードやボリューム追加 などにおいて、サービスレベ ル遵守に必要なインフラリ ソースの作成指示が行われな い[H-1] • UCA-16: Podに割り当てられ ない、別データセンターで のボリューム作成など、不 整合のあるリソースの作成 指示が行われる[H-1, H-2, H-3] • UCA-17: Cluster Autoscalerによる ノード削除など において、リ ソースの削除や 割当解除の指示 が早すぎる。設 定した猶予時間 が短すぎる[H-1, H-3] CA-12 (Pod to API Server) • UCA-18: サービスメッシュの Operatorなどシステム全体に 影響の大きなPodからのコン トロールアクションが行われ ない。関連する変更操作が停 止する[H-1, H-2, H-3] • UCA-19: API Serverが過剰に 呼び出され、API Serverが過 負荷状態に陥る[H-1, H-2, H-3]
38. Control Plane Subsystem Developer/Admin API Server kube-controller manager & kube-scheduler CA14 LW14 Admission Webhook CA17 F17 CA13 F13 cloud-controller manager(*) CA15 LW15 Infra. API CA16 F16 (*)プロセスモデルの操作にとどまらないが、 Kubernetesの慣習上Control Planeに位置付ける
39. 非安全なコントロールアクション(Unsafe Control Action)の識別 コントロール アクション 与えられないと ハザード 与えられると ハザード 早すぎ、遅過ぎ、 誤順序 早すぎる停止、 長すぎる適用 CA-13 (Developer/Admin to API Server) • UCA-20: ConfigMapや SecretはPod作成 のタイミングで 読み込まれるた め、変更後に意 図的に再作成し ないとPod間で設 定の不一致が生 じる[H-3] CA-14 (kube-controller manager/kube- scheduler to API Server) • UCA-21: リソース作成のイベ ント(チェーン)が発生しない、 もしくは途切れ、新規Podが 作成されない[H-1, H-2, H-3] • UCA-22: Podのスケジューリ ング結果が登録されず、新規 Podが作成されない[H-1] • UCA-23: Tolerationの指定漏 れなどスケジュールできない PodやCronJobが大量に要求 される。Pending状態の大量 のPodがスケジューリング負 荷の増大を招く[H-1] CA-15 (cloud-controller manager to API Server) • UCA-24: 作成したインフラリ ソースの情報が登録されず、 利用可能と認識されない。処 理量の増加に対応できない [H-1]
40. 非安全なコントロールアクション(Unsafe Control Action)の識別 コントロール アクション 与えられないと ハザード 与えられると ハザード 早すぎ、遅過ぎ、 誤順序 早すぎる停止、 長すぎる適用 CA-16 (cloud-controller manager to infra. API) • UCA-25: 要求したインフラリ ソースが作成されない[H-1, H-2, H-3] • UCA-26: 必要なインフラリ ソースが削除される[H-1, H- 2, H-3] • UCA-27: 利用可能量や制約、 権限を超えたインフラリ ソースの作成が指示され、 失敗する[H-1] CA-17 (API Server to Admission Webhook) • UCA-28: Webhookが実行され ず、Sidecarコンテナーなどア プリの依存するリソースが Podに注入されない[H-2, H-3] • UCA-29: Admission Control の定義やポリシーに適合し ないリソースが要求され、 失敗する[H-2, H-3] • UCA-30: Webhook呼び出 し先が準備でき ていない状態で 実行される[H-2, H-3]
41. ハザードシナリオを識別する STPA Step4
42. ハザードにつながるシナリオ(要因)を識別する 以下の視点で整理する なぜ、非安全なコントロールアクションが起こるのか • コントローラの故障 • 不適切なコントロールアルゴリズムと実装 • 非安全なコントロール入力 • 不十分、不適切なプロセスモデル/フィードバック なぜ、コントロールアクションは不適切に実行される、または実行さ れずハザードに至るのか • コントロール経路の問題 • 被コントロールプロセスの問題
43. ハザードシナリオの識別 視点 識別子 ハザードシナリオ UCA 非安全なコントロール入力 HS-1 Developer/Adminが、Podに適切なリソース要求(Request)と制限 (Limit)、優先度設定(Priority Class)、分離やノード特性に応じた設定 (Taint/Toleration、Affinity/Anti Affinity)を行っていない。また、それ を未然に防ぐ仕組みがない。 10, 12, 23 HS-2 Developer/Adminが、(HS-1に含まれない)Kubernetesコンポーネン トの仕様や挙動、制約、状態、サイズを加味した設定や入力を行っ ていない。また、それを未然に防ぐ仕組みがない。 2, 3, 4, 6 ,9, 11, 13, 14, 16, 17, 20, 23, 29, 30 HS-3 Developer/Adminが、(HS-1, 2に含まれない)ノードやインフラリ ソース、外部依存先の仕様や挙動、制約、状態、サイズを加味した 設定や入力を行っていない。また、それを未然に防ぐ仕組みがない。 2, 11, 13, 16, 27, 30 HS-4 Developer/Adminが、サービス提供に必要なリソースを削除してし まう。また、それを未然に防ぐ仕組みがない。 26 不十分、不適切なプロセスモデル /フィードバック - - - Thanks, reconciliation loops!! (だがしかし 次ページのシナリオに依存する)
44. ハザードシナリオの識別 視点 識別子 ハザードシナリオ UCA コントロール経路の問題 HS-5 App/Data PlaneからAPI Serverへの経路が失われる、疎通できない 5, 8, 18 HS-6 Control PlaneからAPI Serverへの経路が失われる、疎通できない 21, 22, 24 HS-7 App/Data PlaneからInfra. APIへの経路が失われる、疎通できない 15 HS-8 Control PlaneからInfra. APIへの経路が失われる、疎通できない 25 HS-9 Control PlaneからPodやAdmission Webhookへの経路が失われる、 疎通できない 28 被コントロールプロセスの問題 HS-10 被コントロールプロセスが長時間応答しない（過負荷によるフリー ズやインフラ変更の待ち時間など） 1 HS-11 App/Data PlaneからAPI Serverへ過剰な数の要求が行われる(API Serverの能力とノード数のバランスにもよる) 7, 19
45. このハザードシナリオは 妥当か？ 検証
46. CAST(Causal Analysis using System Theory) STPAは事前、CASTは事後 STAMP (System-Theoretic Accident Model and Processes) STPA (System-Theoretic Process Analysis) CAST (Causal Analysis using System Theory) 基礎理論 方法論 構造からハザードシナリオを分析 (事前) 事故から原因を分析 (事後)
47. CASTで事例を分析し STPAで識別したハザードシナリオを検証しよう
48. (間に合いませんでした)
49. 急ぎ 俺流で検証しました 検証の流れ Kubernetes Failure Stories から、直接的な原因が特定できている事例 を抽出する(33事例。ひとつの事例に複数の原因がある場合も) 説明や根拠が不十分な原因を取り除く 事例横断で同じ原因をまとめる(40件) この分析で定義した境界に入るものを抽出(26件) 識別したハザードシナリオで網羅できているか確認(26件) -> OK!
50. Story # タイトル 1DNS issues in Kubernetes. Public postmortem #1 2CPU limits and aggressive throttling in Kubernetes 3When GKE ran out of IP addresses 4Sailing with the Istio through the shallow water 5Kubernetes made my latency 10x higher 6A Kubernetes crime story 7New K8s workers unable to join cluster 8How a simple admission webhook lead to a cluster outage 9Post Mortem: Kubernetes Node OOM 10Kubernetes' dirty endpoint secret and Ingress 11How a Production Outage Was Caused Using Kubernetes Pod Priorities 12Moving to Kubernetes: the Bad and the Ugly 13Kubernetes Failure Stories, or: How to Crash Your Cluster 14Build Errors of Continuous Delivery Platform 1510 ways to shoot yourself in the foot with kubernetes 16Keynote How Spotify Accidentally Deleted All its Kube Clusters with No User Impact 17Oh Sh*t! The Config Changed! 18Misunderstanding the behaviour of one templating line — and the pain it caused our k8s clusters 19How to kill the Algolia dashboard during Black Friday 20Outage post-mortem 21The shipwreck of GKE Cluster Upgrade 22Breaking Kubernetes: How We Broke and Fixed our K8s Cluster 23Maximize learnings from a Kubernetes cluster failure 24Kubernetes Load Balancer Configuration – Beware when draining nodes 25On Infrastructure at Scale: A Cascading Failure of Distributed System 26A Perfect DNS Storm 27Kubernetes and the Menace ELB, the tale of an outage 28Moving the entire stack to k8s within a year – lessons learned 29Anatomy of a Production Kubernetes Outage 30“Break and Recover” Kubernetes Cluster 31101 Ways to Crash Your Cluster 32Search and Reporting Outage 33SaleMove US System Issue
51. Cause # 直接的な原因 分析の境界内？ ハザードシナリオ Story # 1Podのリソース利用量にLimitを設定しておらずOOM Killやクラッシュが発生した Yes 1 9, 13, 20, 23, 30, 31 2Priority Classの設定ミスで重要度の高いPodのPriorityが低く再作成対象となった Yes 1 11, 15 3kube2iamのメモリ利用量過多によるOOM Killと大量のリスタートが発生、API Serverへの問い合わせが急増した Yes 1 15 4大量のDNS問い合わせによる名前解決の遅延、DNS稼働ノードの過負荷、問い合わせ元ノードのアウトバウンド通信過負荷 Yes 2 1, 13, 15, 26, 28, 30 5CronJob、Jobの設定ミスで大量のJobを実行、大量のPending Podによるスケジューリング過負荷、再実行ループ Yes 2 13, 15, 19, 22, 32 6Endpointの削除に時間がかかり、Ingressが削除済みのPodにトラフィックを送ってしまう Yes 2 10, 12 7kubeletのAPI Server問い合わせレート制限が低過ぎ、IAMクレデンシャルの取得ができない Yes 2 13, 14 8アップグレード時にOPAがAPI Serverを起動できないポリシーを適用してしまい、API Serverが起動しない Yes 2 8 9API Serverが利用できない状態でノード自動修復が機能し、ノード再作成が連鎖した Yes 2 8 10DaemonSetで監査ログを有効にしたところ大量のログがDisk I/Oを圧迫した Yes 2 15 11イメージプルが多すぎてレジストリから拒否された(ImagePullPolicy=Alwaysを意識せず設定していた） Yes 2 15 12HPAとDeploymentでレプリカ数設定に不一致があり、意図したレプリカ数にならなかった Yes 2 15 13ConfigMap/Secretの変更後にPodを明示的に再作成せず、複数あるPodが異なる設定で動作した Yes 2 17 14Node Pool移行時に旧Node PoolにEndpointが残る(CordonしたがDrain漏れ） Yes 2 24 15Pod Disruption Budgetを設定せずにPodが一斉に再作成される Yes 2 29 16敏感すぎるliveness proveでPodが頻繁に再作成される Yes 2 29 17Cluster Autoscalerのスケールイン猶予時間が短過ぎで、急激にノード数が減少する Yes 2 31 18アウトバウンド通信過多でconntrackテーブルが飽和、競合した Yes 3 6, 12, 15 19CPU Limitを設定していたが、CFSスケジューラの特性を理解できておらず想定以上のスロットリングが発生、CPUリソースを活かせない Yes 3 2 20Node、Podともにオートスケール設定をしていたが、VPCでのPod IP仕様理解不足によりIPアドレス割り当てできず、スケールに失敗した Yes 3 3 21VPC CNIのSNAT設定に関する情報が不十分であり、割り当てられるポートが不足した Yes 3 6 22PVが存在しない/別AZにありPodを起動できない Yes 3 15 23起動コンテナーが多すぎてファイルディスクリプタが枯渇した Yes 3 28 24kubeletからAPI Serverへのハートビート実装が考慮不足で、間のLBがTCPコネクションを定期的に切ってしまい、ノードがNotReadyとなる Yes 5 31 25Pod Lifecycle Event Generator relistなどコンテナーランタイムの処理がタイムアウトしNodeがNotReadyになる（過負荷、バグなど) Yes 10 12, 13, 25 26多ノード環境におけるDaemonSetのからAPI Serverへの問い合わせ過負荷 Yes 11 22 27設定ツールのバグでELBに不適切な設定を行い、API Serverが見えなくなる No - 27, 33 28conntrackテーブルの更新に失敗し、存在しないPodにアクセスし続けた（バグの疑い） No - 1 29Istioが未成熟 No - 4 30EC2のインスタンスメタデータを取得するKIAMの証明書有効期限が短過ぎ、問い合わせのたびに更新していた No - 5 31新規Node設定時にrpmファイルをダウンロードできなかった（URLに変更があったが、ハードコードしていた） No - 7 32PodがSIGTERMを受けてもGraceful Shutdownしない No - 10 33EC2のメンテナンスでetcdへの接続が切断する No - 13 34.kube下など大量の設定ファイルを定期的にスキャンするJobがDisk I/Oを圧迫 No - 15 35クラスターデプロイメントスクリプトのバグと不十分なドキュメントにより、クラスターを消失 No - 16 36HAProxy Ingressの使い方を誤解 No - 18 37管理ツールでマスターやNode Poolのアップグレードが止まる、もしくは長時間を要する（eviction条件など様々な要因） No - 21 38etcdのgRPCクライアントのバグ No - 29 39Linkerdのバグ No - 29 40etcdクラスターにスプリットが発生し、あらゆる動作が不適切に(当時はquorum readが既定ではなかった) No - 31
52. 突かれた急所 Top5 Podのリソース利用量にLimitを設定しておらずOOM Killやクラッシュが発生した 大量のDNS問い合わせによる名前解決の遅延、DNS稼働ノードの過負荷、問い合 わせ元ノードのアウトバウンド通信過負荷 CronJob、Jobの設定ミスで大量のJobを実行、大量のPending Podによるスケ ジューリング過負荷、再実行ループ アウトバウンド通信過多でconntrackテーブルが飽和、競合した Pod Lifecycle Event Generator relistなどでコンテナーランタイムの処理がタイムア ウトしNodeがNotReadyになる(過負荷、バグなど)
53. Kubernetesの構造と仕様の理解、動かすアプリが必要 とするリソースの検証、設計、レビュー、アドミッ ションコントローラー、ポリシーで多くは防げます (事例を公開してくれた みなに感謝しましょう)
54. 自由度を低くすれば、より安全になるのでは？ そうかもしれない でも、良さが失われる https://twitter.com/kelseyhightower/status/935252923721793536 Kubernetesはプラットフォームを作る人のためのプラットフォーム ガードレールの塩梅は、それぞれのプラットフォーム提供者が考える
55. 一般化できる特徴はないか 宣言的構成管理を行う分散基盤の先行者から
56. Infrastructure as Data Zhang Lei, Staff Engineer of Alibaba Cloud, CNCF Ambassador, Co- chair of CNCF SIG App Delivery, and maintainer of Kubernetes. Fundamentals of Declarative Application Management in Kubernetes
57. KubernetesのAPI Serverを核にした Infrastructure as Data Resource Custom Resource Validation/Mutation Trigger Desired State Current State Validating Webhook Mutating Webhook Controller App/Data Plane Agent Developer/ Admin API Server + etcd Pods
58. 分散基盤として 物理配置を意識すると Validation/Mutation Trigger Validating Webhook Mutating Webhook Controller App/Data Plane Agent Developer/ Admin Validating Webhook Mutating Webhook Controller / Operator Node Master API Server + etcd Pods (Incl. Critical) Resource Custom Resource Desired State Current State
59. 主な急所 Validation/Mutation Trigger Validating Webhook Mutating Webhook Controller App/Data Plane Agent Developer/ Admin Validating Webhook Mutating Webhook Controller / Operator Node Master API Server + etcd Pods (Incl. Critical) Resource Custom Resource Desired State Current State
60. Kubernetesの安全性分析を通じて見えたもの これから宣言的構成管理を目指す分散システムで議論したいポイント 当然ながら、あるべき姿(Desired State)を宣言、格納するDBが核 DBを更新維持するのはDB自身？周辺のコンポーネントに散らす？ Kubernetesは周辺コンポーネントとし、ノードへの分散配置を認めた マスターに意識が向きがちだが、急所はノードに多い しかしノードを”Pet”にすべきではない、いかに”Cattle”にできるか また、Cattleの群れから発する様々な “Storm”をいかに制御するか
61. まとめ
62. Future Work 1. CASTによる事例分析とSTPAで識別したハザードシナリオの検証 2. 実機検証 ぼくのかんがえた さいきょうの Cloud Nativeアプリ vs 冷酷なハザードシナリオ注入 3. 宣言的構成管理に関する、さらなる一般化 4. 論文
63. ところで ワンターレンに死亡確認されたキャラは 全て生き返っています みんなも Kubernetes サーガの ワンターレンに なってみないか
64. The rise of ワンターレン Enjoy Kubernetes!!
65. © Copyright Microsoft Corporation. All rights reserved.