Download as PDF, PPTX
![[至った お気持ち]仕様や実装はコントロールできない。あくまで貢献の結果である。変化は利点のトレードオフとして受け入れる。リスクの回避と緩和は戦略的に。](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fdiehardinthek8sworld-181218074622%2f75%2fin-the-Kubernetes-world-9-2048.jpg&f=jpg&w=240)
![[至った お気持ち]仕様や実装はコントロールできない。あくまで貢献の結果である。変化は利点のトレードオフとして受け入れる。リスクの回避と緩和は戦略的に。](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fdiehardinthek8sworld-181218074622%2f75%2fin-the-Kubernetes-world-10-2048.jpg&f=jpg&w=240)
![[補足]ネットワーク分断/kubeletクラッシュ対策は後ほどMasterNodekubeletPodNICや経路上でなんらかの問題 Kubeletのクラッシュだが動くMasterNode AkubeletPodNode BkubeletPodだが動くNode A ダウンNode BでPod再作成誰かVolumeをつかんでない？](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2fdiehardinthek8sworld-181218074622%2f75%2fin-the-Kubernetes-world-17-2048.jpg&f=jpg&w=240)
Recommended
![[Japan Tech summit 2017] DEP 005](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2ftechsummit2017pdfdep005-171116035106-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Similar to ダイ・ハード in the Kubernetes world
More from Toru Makabe
ダイ・ハード in the Kubernetes world
- 1.ダイ・ハードin the Kubernetesworld真壁 徹クラウドソリューションアーキテクト日本マイクロソフト株式会社2018/12/18Container Xmas PartyしぶといKubernetes使いになろう
- 2.自己紹介{“名前” : “真壁徹(まかべ とおる)”,“所属” : “日本マイクロソフト株式会社”,“役割” : “クラウド ソリューションアーキテクト”,“経歴” : “大和総研 → HP Enterprise”,“特技” : “クラウド & オープンソース”,“資格” : “CNCF Certified Kubernetes Admin.”,“Twitter” : “@tmak_tw”}https://phippy.io/好きなキャラクター:Captain Kube
- 3.
- 4.お品書きOpenStackとKubernetesの類似点と現状Kubernetesの壊れ方しぶといKubernetes使いになるための ご参考戦略・実装# 実装例としてAzureKubernetes Serviceを取り上げますが、基本的にKubernetes共通の話をします# 「Kubernetesを少しでも触ったことがある」技術者を参加者像として想定しています
- 5.
- 6.
- 7.OpenStackとKubernetes 似ているところレイヤーは異なれど、さまざまなアプリを動かす”基盤”である扱う技術が幅広い (OSカーネル、ネットワーク、ストレージ、etc)ソフトウェアで構成要素を制御する、いわゆるSoftwareDefined世界中のユーザーやベンダーが多様なアイデアやニーズを持ち込むコミュニティが短期間で巨大化し、ブームに挑戦的なオープンソースプロジェクト
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.Master VM/Server(主にコントロールプレーン系機能が動く)Node VM/Server(主にユーザーコンテナーが動く)Clusterstatestore(etcd)SchedulerKubeletContainerRuntimeAPI ServerAPIsController ManagerControllersPod(Container)Client(kubectlなど)Kubernetes アーキテクチャー主要コンポーネントの関係
- 14.Failure Mode (壊れ方)公式ドキュメントよりTroubleshootClusters - 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クラッシュ対策は後ほどMasterNodekubeletPodNICや経路上でなんらかの問題 Kubeletのクラッシュだが動くMasterNode AkubeletPodNodeBkubeletPodだが動く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.MasterAPI ServeretcdロードバランサーControllerManager(A)Scheduler(A)MasterAPI ServeretcdControllerManager(S)Scheduler(S)MasterAPIServeretcdControllerManager(S)Scheduler(S)NodeNodeNodeClient(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の中に持たない、バッチなら処理単位を小さく刻む、etcStatefulSetsを検討する孤立PodのVolumeつかみっぱ問題を回避する基本戦略に加えて
- 21.
- 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 MasterNode Node Node
- 25.バージョンアップ戦略 (ブルーグリーン)本番の裏に新クラスターを作りテスト、切り替える期待本番の裏で新バージョンをテストできるテスト済みのクラスターを本番化できる失敗したときの戻しが楽バージョンアップ中に縮退しない考慮点新クラスターと周辺環境を作るのが面倒(構成管理ツールがないと つらすぎる)バージョンアップ期間は設備が倍に別途トラフィック制御の仕組みが要る裏でテストしスパっと切り替えるMasterMaster MasterNode Node NodeMaster Master MasterNode Node NodeTrafficController
- 26.バージョンアップ戦略の比較どちらがいいかは ひとそれぞれインプレース ブルーグリーン作業量小 構成管理によるリスク 大 小事前テスト可否と手段 現用クラスターでは不可テスト用の別クラスターで実施テスト済みクラスターを本番化リソースコスト (※) 一定(同等環境でテストするなら一時的に倍)一時的に倍縮退 有(程度はツールによる)無(※)リソースが従量課金のサービスか購入資産かで事情は異なる
- 27.
- 28.$ kubeerctl configget-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACEAle-dev-context1 Ale-Cluster-dev Ale-adminAle-stage-context1 Ale-Cluster-stage Ale-adminAle-prod-context1 Ale-Cluster-prod Ale-admin* IPA-dev-context1 IPA-Cluster-dev IPA-userIPA-dev-context2 IPA-Cluster-dev IPA-adminIPA-prod-context1 IPA-Cluster-prod IPA-adminIPA-stage-context1 IPA-Cluster-stage IPA-adminStout-dev-context1 Stout-Cluster-dev Stout-adminStout-dev-context2 Stout-Cluster-dev Stout-userStout-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のクラッシュ 上記と同じクラスター操作者のミス すべてを壊しうる
- 30.
- 31.
- 32.Replicationご参考実装AKS & Terraformを活用したブルーグリーンバージョンアップ& マルチジオ災害対策AKSCosmosDBTrafficManagerAKSAKS(※)CosmosDBAKS (※)User Traffic他(※※) 他(※※)アプリCI/CDRegion ARegion BTerraformGreen GroupTerraformBlue GroupTerraformShared GrouptfstateDeploy& TestPriorityControl(※) 有事にゼロから作ればいいというアイデアもある RTO次第(※※) ユーザーRole定義、Monitor設定など
- 33.ご参考実装のポイントクラスターもImmutableにしてしまうTerraformで、まるっと環境を作成するクラスターだけでなく周辺要素も (Cosmos DB、TrafficManager、ユーザーRole定義、Monitor設定など)リソース間で構成情報を共有する (Cosmos DBの接続文字列、Traffic Managerのエンドポイントなど)ライフサイクル、リスクプロファイルの異なるグループで分割する (ひとつにまとめてしまうと変化に弱い)ライフサイクルが異なれば、あえてDRY/Module化しない (バージョンが変われば書き方も変わる)データストアをKubernetesクラスター外部に持つクラスターのバージョンアップ切り替え時にデータ移行しなくてよいマネージドサービスで楽をする (構築維持の負担軽減、複製機能の活用など)要らなくなったらまるっと破棄するバージョンアップや方式変更が落ち着いたらブルー/グリーンのどちらかは廃棄なにかあったらTerraformで再現
- 34.
- 35.従来とりにくかった戦略いまのKubernetesとエコシステムだと できるアプリがコンテナー前提なのでデプロイが楽アプリはレジストリで、あなたのPullを待っているアプリの実行条件をコード(マニフェスト)にできるアプリを楽に再デプロイできる →クラスターをImmutableにしやすいオンデマンドで使えるサービスの存在ブルーグリーンバージョンアップ戦略のコストを最適化する「使った分だけ課金」なサービスKubernetesのマネージドサービスは複数の選択肢があるKubernetesディストリビューション + 従量制 IaaS という手も (ディストリのコストを動的にできるかは要考慮)試して/壊して経験を積みやすい環境が整ってきたシステムを支えるのは人であり、人の思考と判断を支えるのは経験オンデマンドで使えるサービスなどを活用し、どんどん試して/壊して経験を積もう
- 36.
- 37.「しくみがわかる Kubernetes」翔泳社より 2019/1/23発売•広範なKubernetesの機能から大事なところをピックアップ• 「なぜこの機能が必要か」「どのようなしくみで動いているのか」を大事に• 実践編では運用も考慮した解説を (わたしが書きました)
- 38.
- 39.
- 40.© Copyright MicrosoftCorporation. All rights reserved.