一、k8s架構圖
二、k8s架構模式:
master(cluster)/worker(node)架構
master組件:
1.kube-apiserver:
提供restful接口指令供客戶端或者其他組件調用，客戶端指的是kubectl命令行工具，其他通信組件包括controller和scheduler2.etcd:
負責存儲集羣狀態3.controller
管理並實現k8s的的各種流程,使用k8s管理容器，而不是直接使用容器，目的就是爲容器提供統一編排，爲用戶提供聲明式的調用，k8s維護着用戶的期望,用戶只要告訴k8s需要幾個服務，需要什麼配置就可以了，不需要關心底層k8s怎麼實現的,但是k8s除了正常的創建管理，還伴隨着異常情況的發生，比如容器掛掉,網絡不通等，這時候需要controller監控資源狀態等信息並更新到etcd，controller相當於運維工程師的角色.
k8s把各種操作都認爲是某種類型的某個方法,從而將不同的操作分給不同的方法執行,k8s認爲一切皆資源,繁複的內容抽象成不同的資源放到不同的方法上執行4.Scheduler
資源調度，根據系統資源的使用情況，將pod合理分配到相應的node節點,並通過apiserve告知etcd更新數據庫worker組件:
1.kubelet
controller如何監控不通資源信息，Scheduler如何給pod分配資源，實際的操作都是交給kubelet來完成的，例如，創建pod，刪除pod，創建數據卷等2.kube-proxy
按照用戶的期望創建好環境，pod容器怎麼才能對外提供服務?
pod生成是會自動分配一個ip,但這個ip是動態生成的，並不固定，這時就需要一個固定ip代理pod來對外提供服務，這個就是service資源,扮演者服務發現和負載均衡的功能。
但是service怎麼代理到pod上呢?
這時就需要core-dns,爲新創建的pod註冊動態DNS。給pod的service添加iptables/ipvs規則，用於服務發現和負載均衡，所有網絡相關的請求響應都有kube-proxy代理完成3.container runtime
負責容器運行三、工作流程
1.創建pod
- apiserver接收到用戶創建pod的請求，會根據用戶提交的參數值創建pod對象,apiserver檢測用戶提交的參數，參數不合規則創建失敗
- pod對象創建成功後，etcd會持久化這個對象,測試pod處於pending狀態
- Scheduler會通過list-watch機制 調用apiserver監聽etcd數據變化,如果發現有個pod未bind到node上，就會讀取etcd存儲的pod信息,根據策略算法，將pod調度到相應的node上
- 此時各node也會通過kubectl調用apiserver接口監聽etcd對象狀態變化，被分配到的node發現當前的node狀態，和用戶期望的狀態有個pod不一致，他就會創建pod(包括掛載數據卷，創建pause容器接管應用容器網絡),創建成功後，會將信息通過apiserver更新到etcd中.
2.controller創建pod
第1步成功之後，需要controller接手監控工作
用戶期望pod副本數是3，但此時宕掉一個pod, controller loop 監測到 etcd 中存儲的對象狀態有些與系統 current state 不一致(此例例⼦子中就 是那個宕掉的容器器導致的), replicationController, replicaSet, deployment 等等定義必須有 3 個容器, 然⽽目前系統只有 2 個 running, 然後通過對應的⽤用戶定義時存儲在 etcd 的對象類 型, 相應的controller 會去響應, 發現少了了 1 個容器器, 需要創建 1 個新容器器時, 由該 controller 請求 api server 創建新容器,接下來跟第一步相同
總結:
- etcd 僅能通過 api server 訪問
- etcd 中通過 api server 來保證存儲數據是結構化的
- controller, scheduler, kubelet, kube-proxy 這些組件都是實質上都是通過 watch etcd 中存儲的對象狀態來進⾏行行對應⼯工作的, 但是必須通過 api server; 他們之間是沒有調度的 上下級關係的, ⽽而是通過 etcd 對象狀態的變化來觸發對應的 event 處理理
- k8s 內部⼯工作的機制實質是維持⽤用戶提交的期望 (存儲在 etcd) 與系統當前狀態⼀一致
- k8s 中有個 control loop ⼀一直循環監控着系統狀態