11：可觀測(cè)性、監(jiān)控和日志
1）需求來(lái)源
當(dāng)把應(yīng)用遷移到kubernetes之后，如何保障應(yīng)用的健康和穩(wěn)定？
- 1 提高應(yīng)用的可觀測(cè)性
- 2 提高應(yīng)用的可恢復(fù)能力
具體方法：
- 1 可以實(shí)時(shí)觀測(cè)應(yīng)用的健康狀態(tài)
- 2 可以獲取應(yīng)用的資源使用情況
- 3 可以拿到應(yīng)用的實(shí)時(shí)日志，進(jìn)行問(wèn)題的診斷與分析
2）應(yīng)用健康狀態(tài)-Liveness與Readiness
| Liveness(存活指針) | Readness(就緒指針) | |
|---|---|---|
| 介紹 | 用于判斷容器是否存活，即Pod狀態(tài)是否為Running，如果Liveness探針判斷容器不健康，則會(huì)觸發(fā)kubelet殺掉容器，并根據(jù)配置的策略判斷是否重啟容器，如果默認(rèn)不配置Liveness探針，則認(rèn)為返回值默認(rèn)為成功 | 用于判斷容器是否啟動(dòng)完成，即Pod的Condition是否為Ready，如果探測(cè)結(jié)果不成功，則會(huì)將Pod從Endpoint中移除，直至下一次判斷成功，再將Pod掛回到Endpoint上 |
| 檢測(cè)失敗 | 殺掉Pod | 切斷上層流量到Pod |
| 適用場(chǎng)景 | 支持重新拉起的應(yīng)用 | 啟動(dòng)后無(wú)法立即對(duì)外服務(wù)的應(yīng)用 |
| Liveness與Readiness | |
|---|---|
| 注意事項(xiàng) | 不論是Liveness還是Readness探針，選擇合適的探測(cè)方式可以防止被誤操作：1、調(diào)大判斷的超時(shí)閾值，防止在容器壓力較高的情況下出現(xiàn)偶發(fā)超時(shí)；2、調(diào)整判斷的次數(shù)閾值，3次的默認(rèn)值在短周期下不一定是最佳實(shí)踐；3、exec如果執(zhí)行的是shell腳本判斷，在容器中可能調(diào)用時(shí)間會(huì)非常長(zhǎng)；4、使用tcpSocket的方式遇到TLS的場(chǎng)景，需要業(yè)務(wù)層判斷是否有影響 |
3）問(wèn)題診斷
應(yīng)用故障排查-常見(jiàn)應(yīng)用異常
- Pod停留在Pending：Pending表示調(diào)度器沒(méi)有介入，可以通過(guò)kubectl describe pod，查看事件排查，通常和資源使用相關(guān)
- Pod停留在waiting：一般表示Pod的鏡像沒(méi)有正常拉取，通?？赡芎退接戌R像拉取，鏡像地址不存在，鏡像公網(wǎng)拉取相關(guān)
- Pod不斷被拉起且可以看到crashing：通常表示Pod已經(jīng)完成調(diào)度并啟動(dòng)，但是啟動(dòng)失敗，通常是由于配置、權(quán)限造成，需要查看Pod日志
- Pod處在Running但是沒(méi)有正常工作：通常是由于部分字段拼寫(xiě)錯(cuò)誤造成的，可以通過(guò)校驗(yàn)部署來(lái)排查，例如：Kubectl apply -validate -f pod.yaml
- Service無(wú)法正常工作：在排除網(wǎng)絡(luò)插件自身的問(wèn)題之外，最可能的是label配置有問(wèn)題，可以通過(guò)查看endpoint的方式進(jìn)行檢查
應(yīng)用問(wèn)題診斷的三個(gè)步驟：
- 1 通過(guò)describe查看狀態(tài)，通過(guò)狀態(tài)判斷排查方向
- 2 查看對(duì)象的event事件，獲取更詳細(xì)的信息
- 3 查看Pod的日志，確定應(yīng)用自身的情況
12：可觀測(cè)性：監(jiān)控和日志
1）背景
監(jiān)控和日志是大型分布式系統(tǒng)的重要基礎(chǔ)設(shè)施，監(jiān)控可以幫助開(kāi)發(fā)者查看系統(tǒng)的運(yùn)行狀態(tài)，日志可以協(xié)助問(wèn)題的排查。
Kubernetes 定義了介入的接口標(biāo)準(zhǔn)和規(guī)范，任何符合接口標(biāo)準(zhǔn)的監(jiān)控和日志組件都可以快速集成。
2）監(jiān)控
監(jiān)控類型
- 1 資源監(jiān)控：CPU、內(nèi)存、網(wǎng)絡(luò)等資源類的指標(biāo)，常以數(shù)值、百分比為單位進(jìn)行統(tǒng)計(jì)，是最常見(jiàn)的資源監(jiān)控方式
- 2 性能監(jiān)控：應(yīng)用的內(nèi)部監(jiān)控，通常通過(guò)Hook的機(jī)制在虛擬機(jī)層、字節(jié)碼執(zhí)行層隱式回調(diào)，或者在應(yīng)用層顯示注入，獲取更深層次的監(jiān)控指標(biāo)，常用來(lái)應(yīng)用診斷與調(diào)優(yōu)
- 3 安全監(jiān)控：針對(duì)安全進(jìn)行一系列監(jiān)控策略，例如越權(quán)管理、安全漏洞掃描等
- 4 事件監(jiān)控：k8s中一種另類的監(jiān)控方式，緊密貼合k8s的設(shè)計(jì)理念，補(bǔ)充常規(guī)方案的缺欠與弊端
Prometheus-開(kāi)源社區(qū)的監(jiān)控”標(biāo)準(zhǔn)“
- 簡(jiǎn)潔強(qiáng)大的接入標(biāo)準(zhǔn)
- 多種數(shù)據(jù)采集、離線方式
- k8s的兼容
- 豐富的插件機(jī)制與生態(tài)
- Prometheus Operator的助力
3）日志
日志的場(chǎng)景
- 主機(jī)內(nèi)核的日志：主機(jī)內(nèi)核日志可以協(xié)助開(kāi)發(fā)者診斷，例如：網(wǎng)絡(luò)棧異常、驅(qū)動(dòng)異常、文件系統(tǒng)異常，影響節(jié)點(diǎn)（內(nèi)核）穩(wěn)定的異常
- Runtime的日志：最常見(jiàn)的運(yùn)行是Docker，可以通過(guò)Docker的日志排查，例如Pod Hang等問(wèn)題
- 核心組件的日志：APIServer日志可以用來(lái)審計(jì)，Scheduler日志可以診斷調(diào)度，etcd日志可以查看存儲(chǔ)狀態(tài)，Ingress日志可以分析接入層流量
- 部署應(yīng)用的日志：可以通過(guò)應(yīng)用日志分析查看業(yè)務(wù)層的狀態(tài)，診斷異常
13：Kubernetes網(wǎng)絡(luò)概念及策略控制
1）Kubernetes基本網(wǎng)絡(luò)模型
基本法：約法三章+四大目標(biāo)
Kubernetes對(duì)于Pod間的網(wǎng)絡(luò)沒(méi)有任何限制，只需要滿足如下[三個(gè)基本條件]：
- 所有Pod可以與其他Pod直接通信，無(wú)需顯式使用NAT(Network Address Translation)
- 所有Pod可以與所有Pod直接通信，無(wú)需顯式使用NAT
- Pod可見(jiàn)的IP地址為其他Pod與其通信時(shí)所用，無(wú)需顯式轉(zhuǎn)換
基于以上準(zhǔn)入條件，我們?cè)趯徱曇粋€(gè)網(wǎng)絡(luò)方案的時(shí)候，需要考慮如下[四大目標(biāo)]：
- 容器與容器間的通信
- Pod與Pod之間的通信
- Pod與Service之間的通信
- 外部世界與Service間的通信
2) Netns探秘
Network namespace是實(shí)現(xiàn)網(wǎng)絡(luò)虛擬化的內(nèi)核基礎(chǔ)，創(chuàng)建了隔離的網(wǎng)絡(luò)空間
- 擁有獨(dú)立的附屬網(wǎng)絡(luò)設(shè)備（Io、veth等虛設(shè)備/物理網(wǎng)卡）
- 獨(dú)立的協(xié)議棧，IP地址和路由表
- iptables規(guī)則
- ipvs等
Pod和Netns的關(guān)系
每個(gè)Pod擁有獨(dú)立的Netns空間，Pod內(nèi)的Container共享該空間，可通過(guò)Loopback接口實(shí)現(xiàn)通信，或通過(guò)共享的Pod-IP對(duì)外提供服務(wù)。別忘記，宿主機(jī)上還有一個(gè)Root Netns，可以看做一個(gè)特殊的容器空間
3）典型網(wǎng)絡(luò)容器解決方案
容器網(wǎng)絡(luò)是K8S鄰域最百花齊放的一個(gè)領(lǐng)域，依照IaaS層的配置、外部物理網(wǎng)絡(luò)的設(shè)備、性能or靈活優(yōu)先，可以有不同的實(shí)現(xiàn)：
- Flannel:最為普遍，提供多種網(wǎng)絡(luò)backend實(shí)現(xiàn)，覆蓋多種場(chǎng)景
- Calico:采用BGP提供網(wǎng)絡(luò)直連，功能豐富，對(duì)底層網(wǎng)絡(luò)有要求
- Canal:(Flannel for network + Calico for firewalling)，嫁接型創(chuàng)新項(xiàng)目
- Cilium: 基于eBPF和XDP的高性能Overlay網(wǎng)絡(luò)方案
- Kube-router:同樣采用BGP提供網(wǎng)絡(luò)直連，集成基于LVS的負(fù)載均衡能力
- Romana: 采用BGP or OSPF提供網(wǎng)絡(luò)直連能力的方案
- WeaveNet：采用UDP封裝實(shí)現(xiàn)L2 Overlay，支持用戶態(tài)（慢，可加密）/內(nèi)核態(tài)（快，不能加密）兩種實(shí)現(xiàn)
4)Network Policy基本概念
Network Policy提供了基于策略的網(wǎng)絡(luò)控制，用于隔離應(yīng)用并減少攻擊面。它使用標(biāo)簽選擇器模擬傳統(tǒng)的分段網(wǎng)絡(luò)，并通過(guò)策略控制它們之間的流量以及來(lái)自外部的流量
5）小結(jié)
- 1 Pod在容器網(wǎng)絡(luò)中的核心概念是IP，每個(gè)Pod必須有內(nèi)外視角一致的獨(dú)立IP地址
- 2 影響容器網(wǎng)絡(luò)性能的關(guān)鍵是拓?fù)湓O(shè)計(jì)，也就是數(shù)據(jù)包端到端的路徑設(shè)計(jì)
- 3 牢記Overlay/Underlay下各種網(wǎng)絡(luò)方案的設(shè)計(jì)選擇，如果不知道，可以這樣選：普適性最強(qiáng)Flannel-VxLan，2層可直連Calico/Flannel-Hostgw
- 4 Network Policy是個(gè)強(qiáng)大的工具，可以實(shí)現(xiàn)Ingress的流量精確控制，關(guān)鍵是選擇好Pod Selector
14：Kubernetes Services
1)需求來(lái)源
Kubernetes應(yīng)用應(yīng)如何相互調(diào)用？
- Pod生命周期短暫，IP地址隨時(shí)變化
- Deployment等的Pod組需要統(tǒng)一訪問(wèn)入口和做負(fù)載均衡
- 應(yīng)用間在不同環(huán)境部署時(shí)保持同樣的部署拓?fù)浜驮L問(wèn)方式
Services ：Kubernetes中的服務(wù)發(fā)現(xiàn)與負(fù)載均衡
15：深入剖析Linux容器
以Docker為例的容器：cgroup+namespace+docker image
怎么保證這個(gè)進(jìn)程所用到的資源是被隔離和被限制住的，在 Linux 內(nèi)核上面是由 cgroup 和 namespace 這兩個(gè)技術(shù)來(lái)保證的.
1)資源隔離和限制
| 隔離方式 | 用途 |
|---|---|
| mount | 保證容器看到的文件系統(tǒng)的視圖，是容器鏡像提供的一個(gè)文件系統(tǒng)，也就是說(shuō)它看不見(jiàn)宿主機(jī)上的其他文件，除了通過(guò) -v 參數(shù) bound 的那種模式，是可以把宿主機(jī)上面的一些目錄和文件，讓它在容器里面可見(jiàn)的 |
| uts | 隔離了 hostname 和 domain |
| pid | 保證了容器的 init 進(jìn)程是以 1 號(hào)進(jìn)程來(lái)啟動(dòng)的 |
| network | 網(wǎng)絡(luò) namespace，除了容器用 host 網(wǎng)絡(luò)這種模式之外，其他所有的網(wǎng)絡(luò)模式都有一個(gè)自己的 network namespace 的文件 |
| user | 控制用戶 UID 和 GID 在容器內(nèi)部和宿主機(jī)上的一個(gè)映射，不過(guò)這個(gè) namespace 用的比較少 |
| ipc | 控制了進(jìn)程兼通信的一些東西，比方說(shuō)信號(hào)量 |
| cgroup | 用 cgroup namespace 帶來(lái)的一個(gè)好處是容器中看到的 cgroup 視圖是以根的形式來(lái)呈現(xiàn)的，這樣的話就和宿主機(jī)上面進(jìn)程看到的 cgroup namespace 的一個(gè)視圖方式是相同的。另外一個(gè)好處是讓容器內(nèi)部使用 cgroup 會(huì)變得更安全 |
兩種cgroup驅(qū)動(dòng)
| 驅(qū)動(dòng) | 作用 |
|---|---|
| cytemd cgroup driver | 限制內(nèi)存是多少，要用 CPU share 為多少，其實(shí)直接把 pid 寫(xiě)入對(duì)應(yīng)的一個(gè) cgroup 文件，然后把對(duì)應(yīng)需要限制的資源也寫(xiě)入相應(yīng)的 memory cgroup 文件和 CPU 的 cgroup 文件就可以了 |
| cgroupfs cgroup driver | systemd 本身可以提供一個(gè) cgroup 管理方式。所以如果用 systemd 做 cgroup 驅(qū)動(dòng)的話，所有的寫(xiě) cgroup 操作都必須通過(guò) systemd 的接口來(lái)完成，不能手動(dòng)更改 cgroup 的文件 |
容器中常用的cgroup
| cgroup | 作用 |
|---|---|
| cpu cpuset cpuacct | CPU 一般會(huì)去設(shè)置 cpu share 和 cupset，控制 CPU 的使用率 |
| memory | 控制進(jìn)程內(nèi)存的使用量 |
| device | device 控制了你可以在容器中看到的 device 設(shè)備 |
| freezer、device | 當(dāng)你停止容器的時(shí)候，freezer 會(huì)把當(dāng)前的進(jìn)程全部都寫(xiě)入 cgroup，然后把所有的進(jìn)程都凍結(jié)掉，這樣做的目的是，防止你在停止的時(shí)候，有進(jìn)程會(huì)去做 fork。這樣的話就相當(dāng)于防止進(jìn)程逃逸到宿主機(jī)上面去，是為安全考慮 |
| blkio | 限制容器用到的磁盤的一些 IOPS 還有 bps 的速率限制 |
| pid | pid cgroup 限制的是容器里面可以用到的最大進(jìn)程數(shù)量 |
2)容器鏡像
以docker images為例：
- 基于聯(lián)合文件系統(tǒng)
- 不同的層可以被其他鏡像復(fù)用
- 容器的可寫(xiě)層可以做成鏡像新的一層
以overlay文件系統(tǒng)為例：
| 組件 | 介紹 |
|---|---|
| merged | 整合了ower層和upper讀寫(xiě)層顯示出來(lái)的視圖 |
| upper | 容器讀寫(xiě)層 |
| workdir | 類似中間層，對(duì)upper層的寫(xiě)入，先寫(xiě)入workdir，再移入upper層 |
| lower | 鏡像層，只讀層 |
文件操作：
- 讀：如果upper層沒(méi)有副本，數(shù)據(jù)都從lower讀上來(lái)
- 寫(xiě)：容器創(chuàng)建出來(lái)時(shí)，upper層是空的，只有對(duì)文件進(jìn)行寫(xiě)操作時(shí)，才會(huì)從lower層拷貝文件上來(lái)，對(duì)副本進(jìn)行操作
- 刪：刪除操作不影響lower層，刪除操作通過(guò)對(duì)文件進(jìn)行標(biāo)記，使文件無(wú)法顯示
3）容器引擎
上圖如果把它分成左右兩邊的話，可以認(rèn)為 containerd 提供了兩大功能。
第一個(gè)是對(duì)于 runtime，也就是對(duì)于容器生命周期的管理，左邊 storage 的部分其實(shí)是對(duì)一個(gè)鏡像存儲(chǔ)的管理。containerd 會(huì)負(fù)責(zé)鏡像的拉取、鏡像的存儲(chǔ)。
按照水平層次來(lái)看的話:
第一層是 GRPC，containerd 對(duì)于上層來(lái)說(shuō)是通過(guò) GRPC serve 的形式來(lái)對(duì)上層提供服務(wù)的。Metrics 這個(gè)部分主要是提供 cgroup Metrics 的一些內(nèi)容。
下面這層的左邊是容器鏡像的一個(gè)存儲(chǔ)，中線 images、containers 下面是 Metadata，這部分 Matadata 是通過(guò) bootfs 存儲(chǔ)在磁盤上面的。右邊的 Tasks 是管理容器的容器結(jié)構(gòu)，Events 是對(duì)容器的一些操作都會(huì)有一個(gè) Event 向上層發(fā)出，然后上層可以去訂閱這個(gè) Event，由此知道容器狀態(tài)發(fā)生什么變化。
最下層是 Runtimes 層，這個(gè) Runtimes 可以從類型區(qū)分，比如說(shuō) runC 或者是安全容器之類的。
16：深入理解etcd-基本原理解析
1）基本介紹
etcd誕生于CoreOS公司，最初用于解決集群管理系統(tǒng)中的OS升級(jí)的分布式并發(fā)控制以及配置文件的存儲(chǔ)與分發(fā)等問(wèn)題?；诖?，etcd被設(shè)計(jì)為提供高可用、強(qiáng)一致的小型KeyValue數(shù)據(jù)存儲(chǔ)服務(wù)。項(xiàng)目當(dāng)前隸屬于CNCF基金會(huì)，被包括AWS、Google、Microsoft、Alibaba等大型互聯(lián)網(wǎng)公司廣泛使用。
2）架構(gòu)及內(nèi)部機(jī)制解析
一個(gè) etcd 集群，通常會(huì)由 3 個(gè)或者 5 個(gè)節(jié)點(diǎn)組成，多個(gè)節(jié)點(diǎn)之間，通過(guò)一個(gè)叫做 Raft 一致性算法的方式完成分布式一致性協(xié)同，算法會(huì)選舉出一個(gè)主節(jié)點(diǎn)作為 leader，由 leader 負(fù)責(zé)數(shù)據(jù)的同步與數(shù)據(jù)的分發(fā)，當(dāng) leader 出現(xiàn)故障后，系統(tǒng)會(huì)自動(dòng)地選取另一個(gè)節(jié)點(diǎn)成為 leader，并重新完成數(shù)據(jù)的同步與分發(fā)?？蛻舳嗽诒姸嗟?leader 中，僅需要選擇其中的一個(gè)就可以完成數(shù)據(jù)的讀寫(xiě)。
這里面有一個(gè)關(guān)鍵點(diǎn)，它基于一個(gè)前提：任意兩個(gè) quorum 的成員之間一定會(huì)有一個(gè)交集，也就是說(shuō)只要有任意一個(gè) quorum 存活，其中一定存在某一個(gè)節(jié)點(diǎn)，它包含著集群中最新的數(shù)據(jù)。正是基于這個(gè)假設(shè)，這個(gè)一致性算法就可以在一個(gè) quorum 之間采用這份最新的數(shù)據(jù)去完成數(shù)據(jù)的同步，從而保證整個(gè)集群向前衍進(jìn)的過(guò)程中其數(shù)據(jù)保持一致。
etcd API接口
| 接口 | 功能 |
|---|---|
| Put(key, value)/Delete(key) | put 與 delete 的操作都非常簡(jiǎn)單，只需要提供一個(gè) key 和一個(gè) value，就可以向集群中寫(xiě)入數(shù)據(jù)了，那么在刪除數(shù)據(jù)的時(shí)候，只需要提供 key 就可以了 |
| Get(key)/Get(keyFrom,keyEnd) | 查詢操作。查詢操作 etcd 支持兩種類型的查詢：第一種是指定單個(gè) key 的查詢，第二種是指定的一個(gè) key 的范圍 |
| Watch(key/keyPrefix) | etcd 啟動(dòng)了 Watch 的機(jī)制，也就是我們前面提到的用于實(shí)現(xiàn)增量的數(shù)據(jù)更新，watch 也是有兩種使用方法，第一種是指定單個(gè) key 的 Watch，另一種是指定一個(gè) key 的前綴。在實(shí)際應(yīng)用場(chǎng)景的使用過(guò)程中，經(jīng)常采用第二種 |
| Transactions(if/then/else ops).Commit() | API 是 etcd 提供的一個(gè)事務(wù)操作，可以通過(guò)指定某些條件，當(dāng)條件成立的時(shí)候執(zhí)行一組操作。當(dāng)條件不成立的時(shí)候執(zhí)行另外一組操作 |
| Leases:Grant/Revoke/KeepAlive | Leases 接口是分布式系統(tǒng)中常用的一種設(shè)計(jì)模式 |
3)典型的應(yīng)用場(chǎng)景
| 場(chǎng)景 | 功能 |
|---|---|
| 元數(shù)據(jù)存儲(chǔ)-Kubernetes | 元數(shù)據(jù)高可用，無(wú)單點(diǎn)故障；系統(tǒng)無(wú)狀態(tài)，故障修復(fù)方案簡(jiǎn)單；系統(tǒng)可水平擴(kuò)展，提高性能及容量；簡(jiǎn)化架構(gòu)實(shí)現(xiàn)，降低系統(tǒng)工程的復(fù)雜度 |
| Service Discovery(Nameing Service-名字服務(wù)) | 資源注冊(cè)；存活性檢測(cè)；API gateway無(wú)狀態(tài)，可水平擴(kuò)展；支持上萬(wàn)個(gè)進(jìn)程的規(guī)模 |
| Distributed Coordination: leader election | 將其中的一個(gè) Master 選主成 Leader，負(fù)責(zé)控制整個(gè)集群中所有 Slave 的狀態(tài)。被選主的 Leader 可以將自己的 IP 注冊(cè)到 etcd 中，使得 Slave 節(jié)點(diǎn)能夠及時(shí)獲取到當(dāng)前組件的地址，從而使得系統(tǒng)按照之前單個(gè) Master 節(jié)點(diǎn)的方式繼續(xù)工作。當(dāng) Leader 節(jié)點(diǎn)發(fā)生異常之后，通過(guò) etcd 能夠選取出一個(gè)新的節(jié)點(diǎn)成為主節(jié)點(diǎn)，并且注冊(cè)新的 IP 之后，Slave 又能夠拉取新的主節(jié)點(diǎn)的 IP，從而會(huì)繼續(xù)恢復(fù)服務(wù) |
| Distributed Coordination-分布式系統(tǒng)并發(fā)控制 | 分布式信號(hào)量；自動(dòng)踢出故障節(jié)點(diǎn)；存儲(chǔ)進(jìn)程的執(zhí)行狀態(tài) |
17：深入理解etcd：etcd性能優(yōu)化實(shí)踐
- Raft 層，Raft 需要通過(guò)網(wǎng)絡(luò)同步數(shù)據(jù)，網(wǎng)絡(luò) IO 節(jié)點(diǎn)之間的 RTT 和 / 帶寬會(huì)影響 etcd 的性能。除此之外，WAL 也受到磁盤 IO 寫(xiě)入速度影響.
- 再來(lái)看 Storage 層，磁盤 IO fdatasync 延遲會(huì)影響 etcd 性能，索引層鎖的 block 也會(huì)影響 etcd 的性能。除此之外，boltdb Tx 的鎖以及 boltdb 本身的性能也將大大影響 etcd 的性能。
- 從其他方面來(lái)看，etcd 所在宿主機(jī)的內(nèi)核參數(shù)和 grpc api 層的延遲，也將影響 etcd 的性能。
18：Kubernetes調(diào)度過(guò)程
1） Kubenetes基礎(chǔ)調(diào)度能力
資源調(diào)度-滿足Pod資源要求
- Resources：CPU/Memory/Storage/GPU/FGPA
- QoS：Guaranteed(敏感型、需要保障業(yè)務(wù))/Burstable(次敏感型、需要彈性業(yè)務(wù))/BestEffort(可容忍型業(yè)務(wù))
- Resource Quota（為每個(gè)NameSpace配置ResourceQuota來(lái)防止過(guò)量使用，保障他人的資源可用）
關(guān)系調(diào)度-滿足Pod/Node的特殊關(guān)系、條件要求
- PodAffinity(Pod親和調(diào)度)/PodAntiAffinity(Pod反親和調(diào)度):Pod和Pod之間的關(guān)系
- NodeSelector/NodeAffinity:由Pod決定適合自己的Node
- Taint/Tolerations：限制調(diào)度到某些Node，給Pods配置容忍標(biāo)記
Kubernetes高級(jí)調(diào)度能力-如何做到集群資源合理利用？
- 創(chuàng)建自定義的一些優(yōu)先級(jí)類別（PriprityClass）
- 給不同類型Pods配置不同的優(yōu)先級(jí)（PriorityClassName）
- 通過(guò)組合不同類型Pods運(yùn)行和優(yōu)先級(jí)搶占讓集群資源和調(diào)度彈性起來(lái)
19：調(diào)度器的調(diào)度流程和算法介紹
- preFilter：對(duì)Pod的請(qǐng)求做預(yù)處理
- Filter：自定義Filter邏輯
- PostFilter：可以用于logs/metircs，或者對(duì)Score之前做數(shù)據(jù)預(yù)處理
- Score：自定義的Score邏輯
- Reserve：有狀態(tài)的plugin可以對(duì)資源做內(nèi)存記賬
- Permit：wait, deny, approve，可以作為gang的插入點(diǎn)
- PreBind：在真正bind node之前，執(zhí)行一些操作，例如：云盤掛載到Node上
- Bind：一個(gè)Pod只會(huì)被一個(gè)BindPlugin處理
- PostBind：bind成功之后執(zhí)行的邏輯
- Unreserve：在permit到Bind這幾個(gè)階段只要報(bào)錯(cuò)就回退
20：GPU管理和Device Plugin工作機(jī)制
為什么要用Kubernetes管理以GPU為代表的異構(gòu)資源？
- 加速部署：通過(guò)容器構(gòu)建避免重復(fù)部署機(jī)器學(xué)習(xí)復(fù)雜環(huán)境
- 提升集群資源使用率：統(tǒng)一調(diào)度和分配集群資源
- 保障資源獨(dú)享：利用容器隔離異構(gòu)設(shè)備，避免相互影響
- 第一步是 Device Plugin 的注冊(cè)，需要 Kubernetes 知道要跟哪個(gè) Device Plugin 進(jìn)行交互。這是因?yàn)橐粋€(gè)節(jié)點(diǎn)上可能有多個(gè)設(shè)備，需要 Device Plugin 以客戶端的身份向 Kubelet 匯報(bào)三件事情。
- 第二步是服務(wù)啟動(dòng)，Device Plugin 會(huì)啟動(dòng)一個(gè) GRPC 的 server。在此之后 Device Plugin 一直以這個(gè)服務(wù)器的身份提供服務(wù)讓 kubelet 來(lái)訪問(wèn)，而監(jiān)聽(tīng)地址和提供 API 的版本就已經(jīng)在第一步完成了；
- 第三步，當(dāng)該 GRPC server 啟動(dòng)之后，kubelet 會(huì)建立一個(gè)到 Device Plugin 的 ListAndWatch 的長(zhǎng)連接， 用來(lái)發(fā)現(xiàn)設(shè)備 ID 以及設(shè)備的健康狀態(tài)。當(dāng) Device Plugin 檢測(cè)到某個(gè)設(shè)備不健康的時(shí)候，就會(huì)主動(dòng)通知 kubelet。而此時(shí)如果這個(gè)設(shè)備處于空閑狀態(tài)，kubelet 會(huì)將其移除可分配的列表。但是當(dāng)這個(gè)設(shè)備已經(jīng)被某個(gè) Pod 所使用的時(shí)候，kubelet 就不會(huì)做任何事情，如果此時(shí)殺掉這個(gè) Pod 是一個(gè)很危險(xiǎn)的操作。
- 第四步，kubelet 會(huì)將這些設(shè)備暴露到 Node 節(jié)點(diǎn)的狀態(tài)中，把設(shè)備數(shù)量發(fā)送到 Kubernetes 的 api-server 中。后續(xù)調(diào)度器可以根據(jù)這些信息進(jìn)行調(diào)度。
