架構模型爲master/nodes(work)
可以理解master爲蜂后，nodes爲工蜂(幹活的)
- master爲集羣唯一入口，需要做高可用。
- 每一個node節點都提供一部分計算能力和存儲能力。(運行容器的節點)
請求過程：
客戶端請求(創建啓動容器)首先發往master，master當中有一個調度器，會去分析各node節點的資源狀態，找一個最佳適配運行用戶所請求的容器的節點，並把它調度上去，由這個node的docker或是其他容器引擎來負責把這個容器啓動起來。啓動容器時檢查本地是否有鏡像，如果沒有需要從鏡像倉庫中pull來啓動(鏡像倉庫可以是雲上的，也可以是自檢的私有倉庫，也可以以容器運行在node節點上)。
Master
- API Server 接收並處理用戶請求
- Scheduler 調度容器創建的請求
- controller-manager 確保已創建的容器處於健康狀態
控制器管理器是確保控制器健康的，控制器是用來確保容器健康的。
etcd 所有的組建的狀態保存
再K8s上運行的最小單元不是容器，而是pod
- kubernets並不直接調度容器，而是調度pod,pod是對容器的一層封裝。
- pod裏可以有多個容器，他們共享同一網絡協議棧，存儲卷
- 一般一個pod只有一個容器
- label selector 可以通過控制器給pod打標籤，之後控制器可以根據tag來識別出pod
Node
- kubelet 與apiserver交互運行的
- docker 運行pod中的容器
- kube-proxy 與apiserver進行通信，每一個pod發生變化，結果是需要保存到apiserver中，apiserver會生成一個通知事件，該事件可以被任何關聯的組建所接收到， 管理service，service的創建及變動是依靠kube-proxy在iptables上創建出規則
Pod
- 自主式Pod
自我管理，創建後仍然要提交給apiserver，由apiserver將其調度至指定的node的節點，由node啓動此pod，如果一個pod中的容器出現故障，需要重啓容器，需要又kubelet來完成。但是，如果節點故障了，該容器就消失了。無法實現全局進行調度。
- 控制管理的Pod
正是有控制器機制的引入使得pod成爲有生命週期的對象，而後由調度器將其調度至集羣中的某節點運行以後，有一些任務作爲守護進程運行爲pod或容器，要確保它們隨時處於運行狀態，一旦發生故障，要隨時重啓它或者替代它。
- Replication Controller
- 多退少補，必須精確符合人定義的期望
- 滾動更新
- 回滾
- ReplicaSet
- Deployment 只能管理無狀態應用
- StatefulSet 管理有狀態的應用
- DaemonSet 每個node上運行一個副本，而不是隨意運行
- Job,Cronjob 作業
- HPA(HorizontalPodAutoscaler) 自動分析添加或減少pod