一、k8s架構圖

雨花網(wǎng)站建設公司創(chuàng)新互聯(lián)公司,雨花網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為雨花上千余家提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設公司要多少錢，請找那個售后服務好的雨花做網(wǎng)站的公司定做！

二、k8s架構模式:
master(cluster)/worker(node)架構

master組件:
1.kube-apiserver:

提供restful接口指令供客戶端或者其他組件調用，客戶端指的是kubectl命令行工具，其他通信組件包括controller和scheduler

2.etcd:

負責存儲集群狀態(tài)

3.controller

管理并實現(xiàn)k8s的的各種流程,使用k8s管理容器，而不是直接使用容器，目的就是為容器提供統(tǒng)一編排，為用戶提供聲明式的調用，k8s維護著用戶的期望,用戶只要告訴k8s需要幾個服務，需要什么配置就可以了，不需要關心底層k8s怎么實現(xiàn)的,但是k8s除了正常的創(chuàng)建管理，還伴隨著異常情況的發(fā)生，比如容器掛掉,網(wǎng)絡不通等，這時候需要controller監(jiān)控資源狀態(tài)等信息并更新到etcd，controller相當于運維工程師的角色.
k8s把各種操作都認為是某種類型的某個方法,從而將不同的操作分給不同的方法執(zhí)行,k8s認為一切皆資源,繁復的內(nèi)容抽象成不同的資源放到不同的方法上執(zhí)行

4.Scheduler

資源調度，根據(jù)系統(tǒng)資源的使用情況，將pod合理分配到相應的node節(jié)點,并通過apiserve告知etcd更新數(shù)據(jù)庫

worker組件:
1.kubelet

controller如何監(jiān)控不通資源信息，Scheduler如何給pod分配資源，實際的操作都是交給kubelet來完成的，例如，創(chuàng)建pod，刪除pod，創(chuàng)建數(shù)據(jù)卷等

2.kube-proxy

按照用戶的期望創(chuàng)建好環(huán)境，pod容器怎么才能對外提供服務?
    pod生成是會自動分配一個ip,但這個ip是動態(tài)生成的，并不固定，這時就需要一個固定ip代理pod來對外提供服務，這個就是service資源,扮演者服務發(fā)現(xiàn)和負載均衡的功能。
但是service怎么代理到pod上呢?
這時就需要core-DNS,為新創(chuàng)建的pod注冊動態(tài)DNS。給pod的service添加iptables/ipvs規(guī)則，用于服務發(fā)現(xiàn)和負載均衡，所有網(wǎng)絡相關的請求響應都有kube-proxy代理完成

3.container runtime

負責容器運行

三、工作流程

1.創(chuàng)建pod

• apiserver接收到用戶創(chuàng)建pod的請求，會根據(jù)用戶提交的參數(shù)值創(chuàng)建pod對象,apiserver檢測用戶提交的參數(shù)，參數(shù)不合規(guī)則創(chuàng)建失敗
• pod對象創(chuàng)建成功后，etcd會持久化這個對象,測試pod處于pending狀態(tài)
• Scheduler會通過list-watch機制 調用apiserver監(jiān)聽etcd數(shù)據(jù)變化,如果發(fā)現(xiàn)有個pod未bind到node上，就會讀取etcd存儲的pod信息,根據(jù)策略算法，將pod調度到相應的node上
• 此時各node也會通過kubectl調用apiserver接口監(jiān)聽etcd對象狀態(tài)變化，被分配到的node發(fā)現(xiàn)當前的node狀態(tài)，和用戶期望的狀態(tài)有個pod不一致，他就會創(chuàng)建pod(包括掛載數(shù)據(jù)卷，創(chuàng)建pause容器接管應用容器網(wǎng)絡),創(chuàng)建成功后，會將信息通過apiserver更新到etcd中.

2.controller創(chuàng)建pod
第1步成功之后，需要controller接手監(jiān)控工作
用戶期望pod副本數(shù)是3，但此時宕掉一個pod, controller loop 監(jiān)測到 etcd 中存儲的對象狀態(tài)有些與系統(tǒng) current state 不一致(此例例?子中就 是那個宕掉的容器?導致的), replicationController, replicaSet, deployment 等等定義必須有 3 個容?, 然?目前系統(tǒng)只有 2 個 running, 然后通過對應的?用戶定義時存儲在 etcd 的對象類 型, 相應的controller 會去響應, 發(fā)現(xiàn)少了了 1 個容器?, 需要創(chuàng)建 1 個新容器?時, 由該 controller 請求 api server 創(chuàng)建新容器,接下來跟第一步相同

總結:

1. etcd 僅能通過 api server 訪問
2. etcd 中通過 api server 來保證存儲數(shù)據(jù)是結構化的
3. controller, scheduler, kubelet, kube-proxy 這些組件都是實質上都是通過 watch etcd 中存儲的對象狀態(tài)來進?行行對應?工作的, 但是必須通過 api server; 他們之間是沒有調度的 上下級關系的, ?而是通過 etcd 對象狀態(tài)的變化來觸發(fā)對應的 event 處理理
4. k8s 內(nèi)部?工作的機制實質是維持?用戶提交的期望 (存儲在 etcd) 與系統(tǒng)當前狀態(tài)?一致
5. k8s 中有個 control loop ?一直循環(huán)監(jiān)控著系統(tǒng)狀態(tài)