k8s架構(gòu)原理

一、k8s架構(gòu)圖

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

master組件:
1.kube-apiserver:

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

2.etcd:

負(fù)責(zé)存儲集群狀態(tài)

3.controller

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

4.Scheduler

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

worker組件:
1.kubelet

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

2.kube-proxy

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

3.container runtime

負(fù)責(zé)容器運(yùn)行

三、工作流程

1.創(chuàng)建pod

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

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

總結(jié):

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