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 いかがでしたか？

Kubernetesのしくみやさしく学ぶ内部構造とアーキテクチャー

Kubernetesのしくみやさしく学ぶ内部構造とアーキテクチャー

Recommended

More Related Content

What's hot

What's hot(20)

Similar to Kubernetesのしくみやさしく学ぶ内部構造とアーキテクチャー

Similar to Kubernetesのしくみやさしく学ぶ内部構造とアーキテクチャー(20)

More from Toru Makabe

More from Toru Makabe(20)

Recently uploaded

Recently uploaded(14)