Kubernetes 中一種細(xì)力度控制 Pod 部署的方案

問題背景

并不是所有的 Kubernetes 集群都有很大數(shù)量的機(jī)器, 一個(gè) Pod 也有可能占用幾十 G 內(nèi)存, 希望讀者能在閱讀前就了解這樣的現(xiàn)實(shí).

在我管控的集群中, 有個(gè)集群機(jī)器數(shù)量比較少(大概 7~8 個(gè)計(jì)算節(jié)點(diǎn)), 配置也一般(本文按照64核, 128G這樣的配置來說明, 未來有可能有更好或者更差的機(jī)器), 集群的擁有者會(huì)希望他的機(jī)器資源能夠被有效的利用, 最好在 80%左右, 作為管理員的我就需要考慮下這個(gè)問題.

默認(rèn)部署策略的使用

該集群中有幾個(gè)應(yīng)用的內(nèi)存使用率很高, 每個(gè) Pod 啟動(dòng)后內(nèi)存會(huì)逐漸上升, 我們能接受的范圍大概在 20G 左右. 對(duì)于這種大應(yīng)用, 資源申請(qǐng)不能過高或者過低, 因此程序中的資源配置如下, requests 與 limits 相同.

requests:
  cpu: "10000m"
  memory: "21474836480"
limits:
  cpu: "10000m"
  memory: "21474836480"

以 128G 的節(jié)點(diǎn)為例, 每個(gè)節(jié)點(diǎn)我們期望部署 4/5 個(gè) Pod, 有以下原因:

1. 如果部署 6 個(gè), 內(nèi)存超過 90%的使用率, 監(jiān)控會(huì)報(bào)警;
2. 如果所有節(jié)點(diǎn)都部署 5 個(gè), 那么每次滾動(dòng)更新時(shí)就會(huì)有可能報(bào)警;

比較理想的方案是某些節(jié)點(diǎn) 4 個(gè) Pod, 某些節(jié)點(diǎn) 5 個(gè) Pod, 滾動(dòng)更新時(shí), 從 4 個(gè) Pod 的節(jié)點(diǎn)開始, 逐步替換 Pod.

但是這就帶來了一個(gè)問題, Kuberntes 的默認(rèn)節(jié)點(diǎn)選擇策略是比較自由的, 如果一臺(tái)機(jī)器有資源, 那么它有一定可能被選擇部署.

5 個(gè) Pod 總共 100G mem 的請(qǐng)求資源, 就存在這么一種可能性, 某個(gè)節(jié)點(diǎn)的 Pod 有 6 個(gè), 某個(gè)節(jié)點(diǎn)的 Pod 有 3 個(gè), 默認(rèn)的分配策略是有這種可能性的.

我們?cè)谑褂媚J(rèn)策略時(shí)遇到了好多次這樣的部署結(jié)果, 只能用kubectl delete pod手動(dòng)來進(jìn)行修整. 用同事的話來講就是蛋碎了.

一個(gè)比較簡(jiǎn)單的控制策略

kubernetes 中針對(duì)節(jié)點(diǎn)的可分配資源是可以定義的, 我們限制節(jié)點(diǎn)保留 10%的資源, 用 ansible 生成的 kubelet 參數(shù)可以這么加

--system-reserved=memory={{(ansible_memtotal_mb * 0.1) | int}}Mi

那么, 會(huì)保證不發(fā)生報(bào)警, 但是各個(gè)機(jī)器之間的負(fù)載還是有可能不均衡, 只能部分解決問題.

精細(xì)控制 Pod 分布

因?yàn)槲覀儾恢共渴鹆艘粋€(gè)應(yīng)用, 而且有些應(yīng)用需要特殊的對(duì)待, 肯定不能完全寄希望于自動(dòng)的分配策略. 機(jī)器本身較少, 而且想要實(shí)現(xiàn)較高的利用率時(shí), 支持用戶手工調(diào)整 Pod 數(shù)量是有必要的.

有關(guān)精細(xì)控制節(jié)點(diǎn)中的 Pod 數(shù)量, 我們調(diào)研了幾種方案:

Pod 拓?fù)浞植技s束^[1]

該方案實(shí)現(xiàn)較為復(fù)雜, 它引入了域的概念, 將節(jié)點(diǎn)分組, 每個(gè)組為一個(gè)域, 針對(duì)各個(gè)域中部署的 Pod 數(shù)量進(jìn)行限制, 比如兩個(gè)域之間的 Pod 數(shù)量不能相差 1. 如果用這個(gè)方案解決負(fù)載不均衡的問題, 那么會(huì)引入新的問題: 如果我們?cè)黾恿诵碌臋C(jī)器, 而新機(jī)器的性能配置都較好, 那么 Pod 數(shù)量不能相差 1, 那么新機(jī)器的性能不能被充分利用.

說真的, 我想不到這個(gè)方案應(yīng)用的場(chǎng)景, 如果大家有合適的運(yùn)用場(chǎng)景及思路可以在評(píng)論里面告訴我, 我也學(xué)習(xí)下.

節(jié)點(diǎn)增加拓展資源^[2]

我個(gè)人認(rèn)為這個(gè)方案是一種折衷方案, 配置不太復(fù)雜也能達(dá)到想要的效果. 具體的實(shí)現(xiàn)是增加新的資源限制

書寫控制策略時(shí)配合 cpu 以及 mem 來使用:

用戶可以手動(dòng)修改節(jié)點(diǎn)的資源限制, 也可以針對(duì)某幾個(gè)應(yīng)用來設(shè)置。當(dāng)我們有了不同配置的新機(jī)器后, 可以針對(duì)新機(jī)器修改該選項(xiàng)到合適的值。

我認(rèn)為這個(gè)方案(自動(dòng)選擇+手工配置)已經(jīng)基本解決了我們的問題. 不過有個(gè)小缺點(diǎn)就是: 每次添加新的機(jī)器都需要設(shè)置資源, 否則設(shè)置會(huì)導(dǎo)致 Pod 無法分配到新節(jié)點(diǎn)中.

總結(jié)

我們?cè)诮鉀Q手動(dòng)部署問題時(shí)也討論了一下 Kubernetes 更加適合的場(chǎng)景: 擁有大量的服務(wù)器; 服務(wù)器中運(yùn)行微小服務(wù)的情況; 并且該集群最好能控制資源利用率在 80%以下, 這樣遇到了突發(fā)的流量可以做到有空余時(shí)間去擴(kuò)容.

這篇文章中, 我提到了三個(gè)處理方案, 大家可以針對(duì)自己的情況自己去選擇:

1. 在建立集群時(shí)就考慮下, 給每個(gè)節(jié)點(diǎn)預(yù)留資源,
2. Pod 的拓?fù)浞植技s束我暫時(shí)沒想到合適的場(chǎng)景
3. 對(duì)于某些機(jī)器較少的集群, 用戶想要實(shí)現(xiàn)細(xì)力度的控制, 我還是推薦使用擴(kuò)展資源來限制.

參考資料

你可能還喜歡

點(diǎn)擊下方圖片即可閱讀

云原生是一種信仰 ??

關(guān)注公眾號(hào)

后臺(tái)回復(fù)?k8s?獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不需要！