Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
•
93 likes•38,051 views
Rakuten Tech Conference 2018 at 札幌
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
- 1. Kubernetesのしくみ 真壁 徹 日本マイクロソフト株式会社 2018/10/27 やさしく学ぶ 内部構造とアーキテクチャー Rakuten Technology Conference 2018 Sapporo
- 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “資格” : “CNCF Certified Kubernetes Admin.”, “Twitter” : “@tmak_tw” }
- 3. Kubernetesの使い方 -> 情報増えてきた Kubernetesの中身 -> 動くし、まあいっか
- 5. おつたえしたいこと 本日のお品書き Kubernetesの思想と設計原則 Kubernetesのアーキテクチャー 使い手視点でしくみを学ぶ (可用性/拡張性などを向上するしくみ) # 実装例としてAzure Kubernetes Serviceを取り上げますが、基本的にKubernetes共通の話をします # 「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を中心に、各コンポーネントは突合せループを回す 取得 照合 実行 取得 照合 実行 取得 照合 実行
- 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として動く)
- 26. でも、深く理解したいときは あえて手作業でやってみる手も 大抵はクラウドの提供機能やkubeadmなどツールを使うでしょう ですが、学習のためにあえて手作業でクラスターを作るもよし “Kubernetes the hard way” (つらいやりかた) Google社のKelsey Hightower氏がGCP向けを公開、フォークあり GCP向け Azure向け
- 27. Kubernetesがクラウドを操作することも AKSの例 (パブリックIPアドレス、Azure Load Balancer作成など) (*)Azure、GCP などクラウド APIの違いを吸 収する
- 28. 可用性 使い手視点で特徴を学ぶ
- 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が同時に複数回ると、そ れぞれがあるべき姿に使づけ ようとリソースを増減してし まうため
- 34. Blast Radiusを意識した配置 1つのカゴに全部のタマゴを盛らない 故障、災害の発生確率とインパクトを考慮し、どのBlast Radiusまで耐 えるかを決める 物理サーバー、ラック、データセンター、地域 同じBlast Radiusに同じ役割を配置しないように 利用するサービスやツールがそれを意識して配置できるかを確認する 論理的なBlast Radiusも忘れない (オペレーションミス、ソフトウェア のバグ)
- 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を割り当てら れる
- 50. 60分におさまりませんでした
- 52. Q&A いかがでしたか？
- 53. © Copyright Microsoft Corporation. All rights reserved.