Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

ダイ・ハード in the Kubernetes world

7 934 vues

Publié le

Container Xmas party 発表資料

Publié dans : Technologie
  • Soyez le premier à commenter

ダイ・ハード in the Kubernetes world

  1. 1. ダイ・ハード in the Kubernetes world 真壁 徹 クラウドソリューションアーキテクト 日本マイクロソフト株式会社 2018/12/18 Container Xmas Party しぶといKubernetes使いになろう
  2. 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “資格” : “CNCF Certified Kubernetes Admin.”, “Twitter” : “@tmak_tw” } https://phippy.io/ 好きなキャラクター: Captain Kube
  3. 3. しぶといヤツ “ダイ・ハード”
  4. 4. お品書き OpenStackとKubernetesの類似点と現状 Kubernetesの壊れ方 しぶといKubernetes使いになるための ご参考戦略・実装 # 実装例としてAzure Kubernetes Serviceを取り上げますが、基本的にKubernetes共通の話をします # 「Kubernetesを少しでも触ったことがある」技術者を参加者像として想定しています
  5. 5. 最近のKubernetesを取り巻く環境は ちょっと前のOpenStackと似ている 最近SNSなどで話題になっていましたが
  6. 6. お断り わたしとOpenStack 前職で深く関わっていましたが、知識は3年前で止まっています すでに解決していることもあると思います わたしはいまだにOpenStackが目指した世界に共感しています OpenStackコミュニティの仲間はズッ友です
  7. 7. OpenStackとKubernetes 似ているところ レイヤーは異なれど、さまざまなアプリを動かす”基盤”である 扱う技術が幅広い (OSカーネル、ネットワーク、ストレージ、etc) ソフトウェアで構成要素を制御する、いわゆるSoftware Defined 世界中のユーザーやベンダーが多様なアイデアやニーズを持ち込む コミュニティが短期間で巨大化し、ブームに 挑戦的なオープンソースプロジェクト
  8. 8. わたしが苦労したこと 何かあったときの影響範囲が大きい Software Definedな基盤のBlast Radius(問題発生時の影響範囲)は、クラスター全体 バグ、オペレーションミス、アップデーターの不具合/考慮漏れ、etc アイデアやニーズ、コードが常に受け入れられるわけではない 目の前で困っているユーザーのニーズ、改善案や作ったパッチが、コミュニティで受け入れられる保証はない 独自に手を入れるとアップストリームから乖離し、エコシステムから離れていく アップデートが頻繁 OpenStackは6か月ごとにバージョンアップしていた イノベーティブな新機能は、たいてい破壊的 くまなく理解し、知識を維持し続けるのは困難 多様なインフラ技術が融合しており、かつそれぞれが先進的で、頻繁に変わる そしていまKubernetesで(以下略
  9. 9. [至った お気持ち] 仕様や実装はコントロールできない。 あくまで貢献の結果である。 変化は利点のトレードオフとして受け入れる。 リスクの回避と緩和は戦略的に。
  10. 10. [至った お気持ち] 仕様や実装はコントロールできない。 あくまで貢献の結果である。 変化は利点のトレードオフとして受け入れる。 リスクの回避と緩和は戦略的に。
  11. 11. マネージドサービスや商用ディストリビューション・サポー トで、負担は大きく軽減できます ですが、使い始めてしまうと小手先、後付けでは対応できな いこともあります どんなことが起こりうるかを把握し、事前に戦略を立ててお きましょう
  12. 12. Kubernetesの 壊れ方 (故障・災害編) しぶといKubernetes使いの基礎知識
  13. 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. 14. Failure Mode (壊れ方) 公式ドキュメントより Troubleshoot Clusters - A general overview of cluster failure modes 網羅性や詳細度はそれほど高くありませんが、ざっと把握したり、考 えるきっかけに良いです 以降、誤解をおそれずに意訳していきます
  15. 15. Root causes (根本原因) 公式ドキュメントより VMのクラッシュ ネットワーク分断 (クラスター内、クラスター/ユーザー間) Kubernetesソフトウェアのクラッシュ データ消失、ストレージが使えない オペレーションミス (Kubernetesソフトウェアや関連アプリケーショ ンの構成誤り)
  16. 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. 17. [補足]ネットワーク分断/kubeletクラッシュ 対策は後ほど Master Node kubelet Pod NICや経路上で なんらかの問題 Kubeletのクラッシュ だが 動く Master Node A kubelet Pod Node B kubelet Pod だが 動く Node A ダウン Node BでPod再作成 誰かVolumeを つかんでない?
  18. 18. Mitigations (緩和策) 公式ドキュメントより 緩和策 何に効く IaaSの持つVMのリスタート機能を使う 予期せぬVMのクラッシュ IaaSの持つ信頼性の高いストレージを使う/バック アップする etcdおよびユーザーボリュームの予期せぬ消失 ReplicaSetsやServiceを使う 予期せぬノードVM/Kubeletのクラッシュ Pod再作成の可能性を加味してアプリを作る 予期せぬノードVM/Kubeletのクラッシュ 独立した複数のクラスターで構成する 上記すべて これだけだとちょっと物足りないですね、まとめるとこういうことです • Kubernetesの土台にあるインフラを活かす/意識して設計する • Kubernetesらしいアプリの作りにする • Blast Radiusを限定/分離する
  19. 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. 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つかみっぱ問題を回避する 基本戦略に加えて
  21. 21. Kubernetesの 壊れ方 (不具合編) しぶとい技術者の基礎知識
  22. 22. どこかがおかしくなりました インフラは壊れてなさそうだけど 突然kube-dnsが黙る Ingressが404しか返さなくなる バージョンを上げたらHPAが動かない (heapster -> Metrics Server) 認証方法を変更したらCluster Autoscalerがクラッシュ などなど
  23. 23. 基本戦略 Kubernetesは進化の真っただ中で 自由度も高いから、手は打っておく 常にバージョンは上げられるように GitHubのIssueを探す→だいたい見つかる バージョンアップで解決することが多い リソース不足、奪い合いを防ぐ 大事なコンポーネントはPriorityを高く Namespaceを分けてLimitRangeやQuotaでコントロールする マニフェストのレビュー (RequestsとLimitsを定義しているか、その値は妥当か、Node増設が必要か) とにかくテストと観測 バージョンアップや方式変更前には必ずテストする すべてを机上で把握するのは 無理だから メトリックとログはとりましょう (そしてどこかにためておく Podが消えたあとでも見られるように)
  24. 24. バージョンアップ戦略 (インプレース) 動いているクラスターをバージョンアップする 期待 ツールやサービスによってはボタンを押すだけ クラスターを作り直さなくていい アプリを再導入しなくていい 周辺機能を再作成・再連携しなくていい 余剰設備が要らない (バッファは考える) 考慮点 テストできない 一発勝負 (ツールの作り手は、あなたの構成&あなたのアプ リをのせてのテストはしていない) バージョンアップ中は縮退する じわじわアップデートする Master Master Master Node Node Node
  25. 25. バージョンアップ戦略 (ブルーグリーン) 本番の裏に新クラスターを作りテスト、切り替える 期待 本番の裏で新バージョンをテストできる テスト済みのクラスターを本番化できる 失敗したときの戻しが楽 バージョンアップ中に縮退しない 考慮点 新クラスターと周辺環境を作るのが面倒 (構成管理ツールがないと つらすぎる) バージョンアップ期間は設備が倍に 別途トラフィック制御の仕組みが要る 裏でテストしスパっと切り替える Master Master Master Node Node Node Master Master Master Node Node Node Traffic Controller
  26. 26. バージョンアップ戦略の比較 どちらがいいかは ひとそれぞれ インプレース ブルーグリーン 作業量 小 構成管理による リスク 大 小 事前テスト可否と手段 現用クラスターでは不可 テスト用の別クラスターで実施 テスト済みクラスターを本番化 リソースコスト (※) 一定 (同等環境でテストするなら 一時的に倍) 一時的に倍 縮退 有 (程度はツールによる) 無 (※)リソースが従量課金のサービスか購入資産かで事情は異なる
  27. 27. Kubernetesの 壊れ方 (操作ミス編) しぶとい技術者の基礎知識
  28. 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. 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のクラッシュ 上記と同じ クラスター操作者のミス すべてを壊しうる
  30. 30. 基本戦略 Adminは選ばれし人のみに みんなにkubectlが必要かを考える アプリ開発者にはCI/CDパイプラインからのデプロイを強制する、など GitOpsは考えたいテーマ クラスターやNamespaceを分離する かつRBAC、LimitRange/Quotaを 拾ってきたマニフェストを試すクラスターは分ける いつでも作り直せるように 構成管理ツールは、あなたを守ります
  31. 31. ご参考実装 しぶといKubernetes使いになるための
  32. 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. 33. ご参考実装のポイント クラスターもImmutableにしてしまう Terraformで、まるっと環境を作成する クラスターだけでなく周辺要素も (Cosmos DB、Traffic Manager、ユーザーRole定義、Monitor設定など) リソース間で構成情報を共有する (Cosmos DBの接続文字列、Traffic Managerのエンドポイントなど) ライフサイクル、リスクプロファイルの異なるグループで分割する (ひとつにまとめてしまうと変化に弱い) ライフサイクルが異なれば、あえてDRY/Module化しない (バージョンが変われば書き方も変わる) データストアをKubernetesクラスター外部に持つ クラスターのバージョンアップ切り替え時にデータ移行しなくてよい マネージドサービスで楽をする (構築維持の負担軽減、複製機能の活用など) 要らなくなったらまるっと破棄する バージョンアップや方式変更が落ち着いたらブルー/グリーンのどちらかは廃棄 なにかあったらTerraformで再現
  34. 34. Demo
  35. 35. 従来とりにくかった戦略 いまのKubernetesとエコシステムだと できる アプリがコンテナー前提なのでデプロイが楽 アプリはレジストリで、あなたのPullを待っている アプリの実行条件をコード(マニフェスト)にできる アプリを楽に再デプロイできる → クラスターをImmutableにしやすい オンデマンドで使えるサービスの存在 ブルーグリーンバージョンアップ戦略のコストを最適化する「使った分だけ課金」なサービス Kubernetesのマネージドサービスは複数の選択肢がある Kubernetesディストリビューション + 従量制 IaaS という手も (ディストリのコストを動的にできるかは要考慮) 試して/壊して経験を積みやすい環境が整ってきた システムを支えるのは人であり、人の思考と判断を支えるのは経験 オンデマンドで使えるサービスなどを活用し、どんどん試して/壊して経験を積もう
  36. 36. もっと詳しく?
  37. 37. 「しくみがわかる Kubernetes」 翔泳社より 2019/1/23発売 • 広範なKubernetesの機能から大 事なところをピックアップ • 「なぜこの機能が必要か」「ど のようなしくみで動いているの か」を大事に • 実践編では運用も考慮した解説 を (わたしが書きました)
  38. 38. 進化とエコシステムが魅力のKubernetes 変化への追従はそのトレードオフ リスクは戦略的に回避・緩和しよう
  39. 39. Q&A いかがでしたか?
  40. 40. © Copyright Microsoft Corporation. All rights reserved.

×