Recommended
More Related Content
What's hot
What's hot (20)
Similar to ダイ・ハード in the Kubernetes world
Similar to ダイ・ハード in the Kubernetes world (20)
More from Toru Makabe
More from Toru Makabe (12)
ダイ・ハード in the Kubernetes world
- 1. ダイ・ハード in the Kubernetes world 真壁 徹 クラウドソリューションアーキテクト 日本マイクロソフト株式会社 2018/12/18 Container Xmas Party しぶといKubernetes使いになろう
- 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “資格” : “CNCF Certified Kubernetes Admin.”, “Twitter” : “@tmak_tw” } https://phippy.io/ 好きなキャラクター: Captain Kube
- 4. お品書き OpenStackとKubernetesの類似点と現状 Kubernetesの壊れ方 しぶといKubernetes使いになるための ご参考戦略・実装 # 実装例としてAzure Kubernetes Serviceを取り上げますが、基本的にKubernetes共通の話をします # 「Kubernetesを少しでも触ったことがある」技術者を参加者像として想定しています
- 7. OpenStackとKubernetes 似ているところ レイヤーは異なれど、さまざまなアプリを動かす”基盤”である 扱う技術が幅広い (OSカーネル、ネットワーク、ストレージ、etc) ソフトウェアで構成要素を制御する、いわゆるSoftware Defined 世界中のユーザーやベンダーが多様なアイデアやニーズを持ち込む コミュニティが短期間で巨大化し、ブームに 挑戦的なオープンソースプロジェクト
- 13. Master VM/Server (主にコントロールプレーン系機能が 動く) Node VM/Server (主にユーザーコンテナー が動く) Cluster state store (etcd) Scheduler Kubelet Container Runtime API Server APIs Controller Manager Controllers Pod (Container) Client (kubectlなど) Kubernetes アーキテクチャー 主要コンポーネントの関係
- 14. Failure Mode (壊れ方) 公式ドキュメントより Troubleshoot Clusters - A general overview of cluster failure modes 網羅性や詳細度はそれほど高くありませんが、ざっと把握したり、考 えるきっかけに良いです 以降、誤解をおそれずに意訳していきます
- 15. Root causes (根本原因) 公式ドキュメントより VMのクラッシュ ネットワーク分断 (クラスター内、クラスター/ユーザー間) Kubernetesソフトウェアのクラッシュ データ消失、ストレージが使えない オペレーションミス (Kubernetesソフトウェアや関連アプリケーショ ンの構成誤り)
- 16. Specific scenarios (ちょい具体的に) 公式ドキュメントより 壊れ方 影響 API Serverやそれが動くVMがクラッシュ コントロールプレーン系機能は操作不能に Kubernetes APIに依存しないPodやServiceは動き続 ける API Serverのデータストア(etcd)が消失 上記と同じだが、データの回復が必要 他コントロールプレーン機能やそれが動くVMがク ラッシュ 該当＆依存する機能は操作不能に 依存しないPodやServiceは動き続ける ノードVMのクラッシュ 該当VMで動くPodは利用不能に Master/Node間ネットワーク分断 コントロールプレーンはNodeが利用不能と判断 Node(Kubelet)はAPI Serverを利用不能と判断 該当NodeのPodは動き続ける Kubeletのクラッシュ 上記と同じ クラスター操作者のミス すべてを壊しうる
- 17. [補足]ネットワーク分断/kubeletクラッシュ 対策は後ほど Master Node kubelet Pod NICや経路上で なんらかの問題 Kubeletのクラッシュ だが 動く Master Node A kubelet Pod Node B kubelet Pod だが 動く Node A ダウン Node BでPod再作成 誰かVolumeを つかんでない？
- 18. Mitigations (緩和策) 公式ドキュメントより 緩和策 何に効く IaaSの持つVMのリスタート機能を使う 予期せぬVMのクラッシュ IaaSの持つ信頼性の高いストレージを使う/バック アップする etcdおよびユーザーボリュームの予期せぬ消失 ReplicaSetsやServiceを使う 予期せぬノードVM/Kubeletのクラッシュ Pod再作成の可能性を加味してアプリを作る 予期せぬノードVM/Kubeletのクラッシュ 独立した複数のクラスターで構成する 上記すべて これだけだとちょっと物足りないですね、まとめるとこういうことです • Kubernetesの土台にあるインフラを活かす/意識して設計する • Kubernetesらしいアプリの作りにする • Blast Radiusを限定/分離する
- 19. Master API Server etcd ロードバランサー Controller Manager(A) Scheduler(A) Master API Server etcd Controller Manager(S) Scheduler(S) Master API Server etcd Controller Manager(S) Scheduler(S) Node Node Node Client (kubectlなど) 基本戦略 VM/Serverを冗長化してロードバランサーで散らす ロードバランサー アプリケーション トラフィック
- 20. その他のポイント 同じ役割を「離す」 せっかく冗長化したVMを同じ物理サーバーに置かない (同じ役割のVMは別の物理サーバーへ) 耐えたいレベルに応じてVMを離す度合いを上げていく (物理サーバー/ラック/データセンター) 離す時は遅延に注意 (特にetcdは遅延に敏感) etcd間の遅延を2～3ms以内に抑えるとすると、広域で1つのクラスターは難しい (Azureの専用バックボーンで も東西リージョンで10msくらい) 現状、広域災害はマルチクラスターで保護する (Cosmos DB etcd API for k8sなど限界突破の取り組みはある) アプリは躊躇なくRe-Runできる作りに、また、処理を小さく Podが孤立しても、新たに作られたPodでやりなおせるように ステートはPodの中に持たない、バッチなら処理単位を小さく刻む、etc StatefulSetsを検討する 孤立PodのVolumeつかみっぱ問題を回避する 基本戦略に加えて
- 22. どこかがおかしくなりました インフラは壊れてなさそうだけど 突然kube-dnsが黙る Ingressが404しか返さなくなる バージョンを上げたらHPAが動かない (heapster -> Metrics Server) 認証方法を変更したらCluster Autoscalerがクラッシュ などなど
- 23. 基本戦略 Kubernetesは進化の真っただ中で 自由度も高いから、手は打っておく 常にバージョンは上げられるように GitHubのIssueを探す→だいたい見つかる バージョンアップで解決することが多い リソース不足、奪い合いを防ぐ 大事なコンポーネントはPriorityを高く Namespaceを分けてLimitRangeやQuotaでコントロールする マニフェストのレビュー (RequestsとLimitsを定義しているか、その値は妥当か、Node増設が必要か) とにかくテストと観測 バージョンアップや方式変更前には必ずテストする すべてを机上で把握するのは 無理だから メトリックとログはとりましょう (そしてどこかにためておく Podが消えたあとでも見られるように)
- 24. バージョンアップ戦略 (インプレース) 動いているクラスターをバージョンアップする 期待 ツールやサービスによってはボタンを押すだけ クラスターを作り直さなくていい アプリを再導入しなくていい 周辺機能を再作成・再連携しなくていい 余剰設備が要らない (バッファは考える) 考慮点 テストできない 一発勝負 (ツールの作り手は、あなたの構成&あなたのアプ リをのせてのテストはしていない) バージョンアップ中は縮退する じわじわアップデートする Master Master Master Node Node Node
- 25. バージョンアップ戦略 (ブルーグリーン) 本番の裏に新クラスターを作りテスト、切り替える 期待 本番の裏で新バージョンをテストできる テスト済みのクラスターを本番化できる 失敗したときの戻しが楽 バージョンアップ中に縮退しない 考慮点 新クラスターと周辺環境を作るのが面倒 (構成管理ツールがないと つらすぎる) バージョンアップ期間は設備が倍に 別途トラフィック制御の仕組みが要る 裏でテストしスパっと切り替える Master Master Master Node Node Node Master Master Master Node Node Node Traffic Controller
- 26. バージョンアップ戦略の比較 どちらがいいかは ひとそれぞれ インプレース ブルーグリーン 作業量 小 構成管理による リスク 大 小 事前テスト可否と手段 現用クラスターでは不可 テスト用の別クラスターで実施 テスト済みクラスターを本番化 リソースコスト (※) 一定 (同等環境でテストするなら 一時的に倍) 一時的に倍 縮退 有 (程度はツールによる) 無 (※)リソースが従量課金のサービスか購入資産かで事情は異なる
- 28. $ kubeerctl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE Ale-dev-context1 Ale-Cluster-dev Ale-admin Ale-stage-context1 Ale-Cluster-stage Ale-admin Ale-prod-context1 Ale-Cluster-prod Ale-admin * IPA-dev-context1 IPA-Cluster-dev IPA-user IPA-dev-context2 IPA-Cluster-dev IPA-admin IPA-prod-context1 IPA-Cluster-prod IPA-admin IPA-stage-context1 IPA-Cluster-stage IPA-admin Stout-dev-context1 Stout-Cluster-dev Stout-admin Stout-dev-context2 Stout-Cluster-dev Stout-user Stout-prod-context1 Stout-Cluster-prod Stout-admin
- 29. Failure Mode 再掲 公式ドキュメントより 壊れ方 影響 API Serverやそれが動くVMがクラッシュ コントロールプレーン系機能は操作不能に Kubernetes APIに依存しないPodやServiceは動き続 ける API Serverのデータストア(etcd)が消失 上記と同じだが、データの回復が必要 他コントロールプレーン機能やそれが動くVMがク ラッシュ 該当＆依存する機能は操作不能に 依存しないPodやServiceは動き続ける ノードVMのクラッシュ 該当VMで動くPodは利用不能に Master/Node間ネットワーク分断 コントロールプレーンはNodeが利用不能と判断 Node(Kubelet)はAPI Serverを利用不能と判断 該当NodeのPodは動き続ける Kubeletのクラッシュ 上記と同じ クラスター操作者のミス すべてを壊しうる
- 32. Replication ご参考実装 AKS & Terraformを活用したブルーグリーンバージョンアップ & マルチジオ災害対策 AKS Cosmos DB Traffic Manager AKS AKS(※) Cosmos DB AKS (※) User Traffic 他(※※) 他(※※) アプリ CI/CDRegion A Region B Terraform Green Group Terraform Blue Group Terraform Shared Grouptfstate Deploy & Test Priority Control (※) 有事にゼロから作ればいいというアイデアもある RTO次第 (※※) ユーザーRole定義、Monitor設定など
- 33. ご参考実装のポイント クラスターもImmutableにしてしまう Terraformで、まるっと環境を作成する クラスターだけでなく周辺要素も (Cosmos DB、Traffic Manager、ユーザーRole定義、Monitor設定など) リソース間で構成情報を共有する (Cosmos DBの接続文字列、Traffic Managerのエンドポイントなど) ライフサイクル、リスクプロファイルの異なるグループで分割する (ひとつにまとめてしまうと変化に弱い) ライフサイクルが異なれば、あえてDRY/Module化しない (バージョンが変われば書き方も変わる) データストアをKubernetesクラスター外部に持つ クラスターのバージョンアップ切り替え時にデータ移行しなくてよい マネージドサービスで楽をする (構築維持の負担軽減、複製機能の活用など) 要らなくなったらまるっと破棄する バージョンアップや方式変更が落ち着いたらブルー/グリーンのどちらかは廃棄 なにかあったらTerraformで再現
- 34. Demo
- 35. 従来とりにくかった戦略 いまのKubernetesとエコシステムだと できる アプリがコンテナー前提なのでデプロイが楽 アプリはレジストリで、あなたのPullを待っている アプリの実行条件をコード(マニフェスト)にできる アプリを楽に再デプロイできる → クラスターをImmutableにしやすい オンデマンドで使えるサービスの存在 ブルーグリーンバージョンアップ戦略のコストを最適化する「使った分だけ課金」なサービス Kubernetesのマネージドサービスは複数の選択肢がある Kubernetesディストリビューション + 従量制 IaaS という手も (ディストリのコストを動的にできるかは要考慮) 試して/壊して経験を積みやすい環境が整ってきた システムを支えるのは人であり、人の思考と判断を支えるのは経験 オンデマンドで使えるサービスなどを活用し、どんどん試して/壊して経験を積もう
- 36. もっと詳しく？
- 37. 「しくみがわかる Kubernetes」 翔泳社より 2019/1/23発売 • 広範なKubernetesの機能から大 事なところをピックアップ • 「なぜこの機能が必要か」「ど のようなしくみで動いているの か」を大事に • 実践編では運用も考慮した解説 を (わたしが書きました)
- 39. Q&A いかがでしたか？
- 40. © Copyright Microsoft Corporation. All rights reserved.