[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス
Seu SlideShare está sendo baixado.
×
Confira estes a seguir
Recomendadas
Mais Conteúdo rRelacionado
Diapositivos para si (20)
Semelhante a Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー (20)
Mais de Toru Makabe (20)
Mais recentes (20)
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
- 1. Kubernetesのしくみ 真壁 徹 日本マイクロソフト株式会社 2018/10/27 やさしく学ぶ 内部構造とアーキテクチャー Rakuten Technology Conference 2018 Sapporo
- 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “資格” : “CNCF Certified Kubernetes Admin.”, “Twitter” : “@tmak_tw” }
- 3. Kubernetesの使い方 -> 情報増えてきた Kubernetesの中身 -> 動くし、まあいっか
- 4. 知識は荷物になりません あなたを守る懐刀
- 5. おつたえしたいこと 本日のお品書き Kubernetesの思想と設計原則 Kubernetesのアーキテクチャー 使い手視点でしくみを学ぶ (可用性/拡張性などを向上するしくみ) # 実装例としてAzure Kubernetes Serviceを取り上げますが、基本的にKubernetes共通の話をします # 「Kubernetesを少しでも触ったことがある」技術者を参加者像として想定しています
- 6. 大事なとこだけ！ (詳細はバッサリ省きます)
- 7. 思想と設計原則、 アーキテクチャー Kubernetesの
- 8. Kubernetesの特徴 3行で Immutable Infrastructure (変更を積み重ねず、都度作る/作り直す) 宣言的設定 (あるべき姿を宣言し、その姿に収束させる) 自己修復 (どこかが壊れても、人を介さずに修復する)
- 9. $ kubectl get all -n default NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 53d $ kubectl create deployment --image=nginx nginx -n default deployment.apps/nginx created はじめに: KubernetesのDeploymentを作る Namespace defaultは空っぽ (service/kubernetesのみ) NGINXのDeploymentを作り ます
- 10. $ kubectl get all -n default NAME READY STATUS RESTARTS AGE pod/nginx-56f766d96f-zc49x 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 53d NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deployment.apps/nginx 1 1 1 1 22s NAME DESIRED CURRENT READY AGE replicaset.apps/nginx-56f766d96f 1 1 1 22s うわ！なんかいっぱい増えた
- 11. なんだかすごそうな仕組み なにが起こったか APIを呼んだら、3種類のオブジェクトができた kubectl API Deployment ReplicaSet Pod (NGINX Container) ReplicaSetをバージョニングする バージョンアップ/戻しが楽に Podのレプリカを作る 可用性の向上や負荷分散を実現 コンテナーの実行単位 複数のコンテナーをまとめられる kubectl create deployment
- 12. Master Node Cluster state store (etcd) Scheduler Kubelet Container Runtime API Server APIs Controller Manager Controllers Pod (Container) Client (kubectlなど) Kubernetes アーキテクチャー 主要コンポーネントの関係
- 13. Reconciliation Loop (突合せループ) 取得 照合 実行 API Serverへ 問い合わせ あるべき姿と現状を 突合せ 差分があれば 埋める
- 14. Master Node Cluster state store (etcd) Scheduler Kubelet Container Runtime API Server APIs Controller Manager Controllers Pod (Container) Client (kubectlなど) Kubernetes アーキテクチャー 再び API Serverを中心に、各コンポーネントは突合せループを回す 取得 照合 実行 取得 照合 実行 取得 照合 実行
- 15. Kubernetesの設計原則 (1/2) Design Principles から抜き出し、意訳 API Serverのみがクラスター状態を管理するデータストア(etcd)を扱う 部分的なサーバー障害がクラスター全体のダウンにつながらないよう にする 各コンポーネントへの指示が失われても、直近の指示にもとづいて処 理を継続できるようにする
- 16. Kubernetesの設計原則 (2/2) Design Principles から抜き出し、意訳 各コンポーネントは関連する設定や状態をメモリに持つが、永続化は API Serverを通じてデータストア(etcd)へ行う ユーザーや他のコンポーネントがオブジェクトを変化させたことを検 知できるよう、コンポーネントはAPI Serverをウォッチする
- 17. Master Node Cluster state store (etcd) Scheduler Kubelet Container Runtime API Server APIs Controller Manager Controllers Pod (Container) Client (kubectlなど) Kubernetes アーキテクチャー 再び API Serverを中心に、各コンポーネントは突合せループを回す 取得 照合 実行 取得 照合 実行 取得 照合 実行
- 18. Kubernetes課 専門家が自分の仕事に集中できる API Server課長 依頼や調整を一手に 引き受けるやり手 etcdさん 課長が信頼する 記録担当 Deployment Controllerさん 優れた大局観を持つ ReplicaSet Controllerさん 案件の横展開が得意 Schedulerさん 予算のやりくりは任せて Kubeletさん 客先に強い 記録 依頼・報告 ・確認 依頼・報告 ・確認 依頼・報告 ・確認 依頼・報告 ・確認
- 19. API Server課長はメンバーの状態を常に把握 メンバー同士は直接話をしない 効率重視な職場です
- 20. イベントチェーン Deployment作成の例 Master Nodeetcd Scheduler Kubelet Container Runtime API Server Deployment API ReplicaSet API Pod API Controller Manager Deployment Controller ReplicaSet Controller Pod (Container) ウォッチ 作成/割り当て kubectl
- 21. イベントチェーンの流れ Deployment作成の例 クライアントがDeployment APIを呼ぶ Deployment Controllerが検知し、ReplicaSet APIを呼ぶ ReplicaSet Controllerが検知し、Pod APIを呼ぶ Schedulerが検知し、配置先Nodeを決定し、Pod APIを呼ぶ Kubeletが検知し、Pod(Container)を作成 (各Controller、Scheduler、Kubeletは、常にそれぞれがReconciliation Loopを回している)
- 22. 物理/論理配置 AKSの例 Node Node Master (物理サーバー、仮想マシン) Node (物理サーバー、仮想マシン) API Server etcd ロードバランサー ロードバランサー Controller Manager Scheduler kubelet kube-proxy(*) Container Runtime アドオンコン ポーネント(**) (*) Nodeのネットワークを制御 (iptables操作など) (**) DNS、Metrics Serverなど (Podとして動く)
- 23. Kubernetesを支える周辺機能 AKSの例
- 24. Kubernetesクラスター作成に必要な作業 やること多すぎ etcdの起動 Kubernetes設定ファイルの作成と配布 Kubernetesコンポーネント(バイナリー) の配布 Kubernetesコンポーネントの起動 Kubernetesアドオンコンポーネントの作 成 などなど Node間ネットワークの作成 Masterサーバーの作成 Masterサーバー向けロードバランサーの 作成 Nodeサーバーの作成 Pod間ネットワークの作成 証明書の作成と配布 etcd設定ファイルの作成と配布
- 25. Cluster Bootstrapping AKSの例 Deployment Engine
- 26. でも、深く理解したいときは あえて手作業でやってみる手も 大抵はクラウドの提供機能やkubeadmなどツールを使うでしょう ですが、学習のためにあえて手作業でクラスターを作るもよし “Kubernetes the hard way” (つらいやりかた) Google社のKelsey Hightower氏がGCP向けを公開、フォークあり GCP向け Azure向け
- 27. Kubernetesがクラウドを操作することも AKSの例 (パブリックIPアドレス、Azure Load Balancer作成など) (*)Azure、GCP などクラウド APIの違いを吸 収する
- 28. 可用性 使い手視点で特徴を学ぶ
- 29. 可用性を確保するには 基本的に複数サーバー構成にすればOK 複数の物理サーバー、仮想マシンで構成する 1つの物理サーバー、仮想マシンに同じ役割のコンポーネントを 複数載せないようにする 障害の影響範囲 (Blast Radius)を意識する
- 30. 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など) 全Active構成が基本だが、例外あり Controller ManagerとSchedulerはActive/Standby Controller Managerと SchedulerのReconciliation Loopが同時に複数回ると、そ れぞれがあるべき姿に使づけ ようとリソースを増減してし まうため
- 31. Kubernetes課 登場の期待を感じますが 表現が過酷であるため自粛します
- 32. 台数は？ Master、Nodeともに3台以上がおすすめ Masterサーバーにetcdを同居させる場合、おすすめは3台以上で奇数 etcdの障害時、処理継続ノードの決定基準が過半数であるため Nodeサーバーは2台以上、必要なリソース量に応じて増やす Nodeサーバーが2台構成だと障害時に使えるリソースが一気に半減す るため、3台以上とするケースが多い
- 33. Blast Radiusを意識する 障害、災害の影響範囲を意識し、MasterやNodeを分散配置する 地域ラック物理サーバー 仮想マシン 仮想マシン 物理サーバー 物理サーバー 物理サーバー ネットワーク 装置 配電装置 データセンター ラック ラック ラック ネットワーク 装置 配電/発電 装置 空調 単一障害点/ 障害の原因 広域災害 データ センター データ センター データ センター
- 34. Blast Radiusを意識した配置 1つのカゴに全部のタマゴを盛らない 故障、災害の発生確率とインパクトを考慮し、どのBlast Radiusまで耐 えるかを決める 物理サーバー、ラック、データセンター、地域 同じBlast Radiusに同じ役割を配置しないように 利用するサービスやツールがそれを意識して配置できるかを確認する 論理的なBlast Radiusも忘れない (オペレーションミス、ソフトウェア のバグ)
- 35. 例: ラック障害までは耐えると決めたら 役割を意識し、複数のラックに分散配置する ラック(のいずれかの物理サーバー) Master ラック(のいずれかの物理サーバー) Master ラック(のいずれかの物理サーバー) Master Node Node Node Node Node Node 各Master、Nodeを仮想マシン とした場合
- 36. 1つのクラスターはどのくらいまで広げられる？ 東阪で1つのクラスターは難しいか 複数のデータセンターに分散配置する場合、制約条件は遅延 etcdの死活確認、性能の観点から2～3msに抑えるのが一般的 Azureのバックボーンでも東阪は10ms程度かかる 1つのクラスターは1つの都市圏で構成するのが現実的 広域災害対策は1つのクラスターではなく、複数のクラスターで
- 37. AKSの広域災害対策構成例 AKS クラスター リージョンA リージョンB Traffic Manager Azure RM Template、 Terraformなど Cosmos DB データ複製 Service External IP(s) Kubernetes & Azure APIエンドポイント AKS クラスター Cosmos DB Service External IP(s) Kubernetes & Azure APIエンドポイント マルチリージョン トラフィック制御 構成管理
- 38. 拡張性 使い手視点で特徴を学ぶ
- 39. Kubernetesのリソース拡張手段 AKSでの選択肢 自動/手動 水平/垂直(*) Pod/Node HPA (Horizontal Pod Autoscaler) 自動 水平 Pod VPA (Vertical Pod Autoscaler) 自動 垂直 Pod CA (Cluster Autoscaler) 自動 水平 Node Azure CLI (az aks scale) 手動 水平 Node (*)水平 = Pod、Node数を増減する (サイズは同じ) 垂直 = Podのサイズを変更する
- 40. spec: containers: - name: hoge image: fuga resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" 重要: Podのリソース定義 (RequestsとLimits) Requests “これくらい欲しい” Limits “これ以上は割り当てない” ポイント • Requestsは実際にリソースをどのくら い使っているかと関係しない • SchedulerがどのNodeへPodを割り当て るかの判断に使う • コンテナー個別に指定できる
- 41. Requestsを満たすようスケジューリングする 空きがない場合はPendingとなる Node (割り当て可能メモリ 3Gi) Pod A: Requests 1Gi Memory Pod B: Requests 1Gi Memory Pod C: Requests 1Gi Memory Pod D: Requests 1Gi Memory Scheduler うーむ Pod Dを割り当てる 空きがないのう Pending 実際のメモリ利用 量は見ていない
- 42. HPA(Horizontal Pod Autoscaler)の仕組み 実際の利用量を見て、Podのレプリカを増減する Node Node (***) Pod(Replica3) Pod(Replica1) Pod(Replica2) Scheduler API Server HPA (**) Metrics Server (*) 実際の利用量を 集めてくるよ 定義に合わせて Podの数を 増減するよ (*)以前はHeapsterが使われていました Heapsterは廃止予定です (**)カスタムメトリックも使えます (Prometheusなど) (***)Node上でcAdvisorがメトリックを集め、 kubelet経由でMetrics Serverに集約します
- 43. HPAの定義例 たとえば、全レプリカのCPU利用率をもとに判断する Replica 1: 50% (Requests: 100m, Usage: 50m) Replica 2: 50% (Requests: 100m, Usage: 50m) Replica 3: 50% (Requests: 100m, Usage: 50m) 50% 50% + 50% + 50% ターゲットの利用 率を定義 ターゲットの利用率を50%とし、すべてのレプリカの利用率が50%だったら(奇跡) = 3 レプリカ数は 3のままでOK
- 44. HPAの定義例 たとえば、全レプリカのCPU利用率をもとに判断する Replica 1: 90% (Requests: 100m, Usage: 90m) Replica 2: 50% (Requests: 100m, Usage: 50m) Replica 3: 70% (Requests: 100m, Usage: 70m) 50% 90% + 50% + 70% ターゲットの利用 率を定義 レプリカ数を増やす必要がある場合 = 5 レプリカ数を 3から5に変更
- 45. HPA(Horizontal Pod Autoscaler)の仕組み 実際の利用量を見て、Podのレプリカを増減する Node Node Pod(Replica3) Pod(Replica1) Pod(Replica2) Scheduler API Server HPA Metrics Server 実際の利用量を 集めてくるよ 定義に合わせて、 レプリカ数は5にす るよ Pod(Replica4) Pod(Replica5) おう おう
- 46. Nodeに空きリソースがなかったら？ Cluster Autoscalerの出番です PendingのPodがある = 空きリソースがない Cluster Autoscalerは、Pending状態のPodの有無でNode追加を判断 Cluster Autoscalerは、インフラのAPIを呼び出してNodeを追加 (AKSでは、Azure APIを呼んでいる)
- 47. CA(Cluster Autoscaler) Pending状態のPodがあれば、Nodeを追加する Cluster Autoscaler Node Node Pod(Running) Pod(Running) Pod(Running) Pod(Running) Pod(Running) Pod(Running) Scheduler インフラAPI Pod(Pending) API Server Node PendingのPodを発見、 Nodeを増やすぞ おう Readyになったら Schedulerから Podを割り当てら れる
- 48. HPAとCAの共演 それぞれ自律的に自分の仕事に集中し、結果的に連動する Cluster Autoscaler Node Node Pod(Running) Pod(Running) Pod(Running) Pod(Running) Pod(Running) Pod(Running) Scheduler インフラAPI Pod(Pending) API Server Node HPA Metrics ServerHPAの定義を守るよ う集中 PendingのPodの有無 に集中(※) (※)Nodeを減らす判断は Nodeのリソース割り当て状 況を見ている (詳細は割愛) Readyになったら Schedulerから Podを割り当てら れる
- 49. 保守性、リソース保護、 可観測性… 使い手視点で特徴を学ぶ
- 50. 60分におさまりませんでした
- 51. (仮)しくみでわかる Kubernetes 翔泳社から発売予定 (たぶん年明け) Kubernetesの主要機能を、動きやしくみを交え、やさしく解説 網羅性はあきらめ、大事な機能の解説にフォーカス Kubernetesの「どうなってるの～」という疑問におこたえする本 後半の実践編は、わたしが担当 アップグレード、ID管理、監視などなど運用に効く話題も 本日の内容をより詳しく、小ネタを交え解説
- 52. Q&A いかがでしたか？
- 53. © Copyright Microsoft Corporation. All rights reserved.
