記 K8s 集群中 Flannel 遇到的兩個(gè)問題

自建的 K8s 集群的坑不少, 尤其是到了 Node 數(shù)量越來越多之后, 問題也逐漸顯露了出來, 博客主要介紹我們使用flannel之后遇到的兩個(gè)問題以及解決方案, 問題其實(shí)不嚴(yán)重, 只是涉及到了底層的結(jié)構(gòu), 改動時(shí)候要小心.

問題 1 flannel 的 OOM 問題

官方給出的配置

下面這張圖是官方的配置, 可以看到, 默認(rèn)的資源設(shè)置僅給定了 50M 內(nèi)存

kubectl?-n?kube-system?describe?ds?kube-flannel-ds-amd64
????Limits:
??????cpu:?????100m
??????memory:??50Mi
????Requests:
??????cpu:?????100m
??????memory:??50Mi

我們遇到的問題

當(dāng)我們的機(jī)器數(shù)量超過 100 個(gè)以后, flannel 會以 OOM 的形式一直掛掉..

Feb??9?04:52:44??kernel:?[37630249.323630]?Memory?cgroup?out?of?memory:?Kill?process?33838?(flanneld)?score?1653?or?sacrifice?child

通過Prometheus采集到的數(shù)據(jù)也可以看到, 容器的內(nèi)存使用情況很不樂觀:

也沒什么好的解決方案, 只能調(diào)整資源限制了.

問題 2 flannel 指定網(wǎng)卡問題

問題背景

因?yàn)槲覀兪褂玫臋C(jī)器比較混雜, 機(jī)器的網(wǎng)卡也各不相同, 在開始搭建集群時(shí)就遇到了下面的問題.

>?我們虛擬機(jī)中的網(wǎng)卡,?僅有`10`開頭的內(nèi)網(wǎng)地址
1:?lo:??mtu?65536?qdisc?noqueue?state?UNKNOWN?group?default?qlen?1
????link/loopback?00:00:00:00:00:00?brd?00:00:00:00:00:00
????inet?127.0.0.1/8?scope?host?lo
???????valid_lft?forever?preferred_lft?forever
2:?eth0:??mtu?1400?qdisc?pfifo_fast?state?UP?group?default?qlen?1000
????link/ether?52:xx:xx:xx:77:0c?brd?ff:ff:ff:ff:ff:ff
????inet?10.xxx.xxx.xxx/26?brd?10.xxx.xxx.xxx?scope?global?eth0
???????valid_lft?forever?preferred_lft?forever

>?物理機(jī)中的網(wǎng)卡,?既有`59`開頭的公網(wǎng)地址,?也有`10`開頭的內(nèi)網(wǎng)地址,?并且網(wǎng)卡名為eth1
1:?lo:??mtu?65536?qdisc?noqueue?state?UNKNOWN?group?default?qlen?1
????link/loopback?00:00:00:00:00:00?brd?00:00:00:00:00:00
????inet?127.0.0.1/8?scope?host?lo
???????valid_lft?forever?preferred_lft?forever
2:?eth0:??mtu?1500?qdisc?mq?state?UP?group?default?qlen?1000
????link/ether?8c:xx:xx:xx:xx:xx?brd?ff:ff:ff:ff:ff:ff
????inet?59.xxx.xxx.xxx/24?brd?59.xxx.xxx.xx?scope?global?eth0
???????valid_lft?forever?preferred_lft?forever
3:?eth1:??mtu?1500?qdisc?mq?state?UP?group?default?qlen?1000
????link/ether?8c:xx:xx:xx:xx:38?brd?ff:ff:ff:ff:ff:ff
????inet?10.xxx.xxx.xxx/24?brd?10.xxx.xxx.xxx?scope?global?eth1
???????valid_lft?forever?preferred_lft?forever

這樣帶來的問題就是 flannel 通信問題, 如果多個(gè)網(wǎng)卡, 且啟動時(shí)未指定, flannel 會找一個(gè)缺省的網(wǎng)卡, 對于虛擬機(jī)來講沒有關(guān)系, 但是對于物理機(jī), flannel 會找到 eth0 這個(gè)外網(wǎng)網(wǎng)卡, flannel 使用錯(cuò)誤的網(wǎng)卡發(fā)送數(shù)據(jù), 抓包的數(shù)據(jù)可以看出 flannel 使用了公網(wǎng)的網(wǎng)卡發(fā)送內(nèi)網(wǎng)數(shù)據(jù), 會被交換機(jī)丟棄, 具體圖片就不貼了, IP 屬于公司機(jī)密.

具體的修改方法是確保 flannel 使用了正確的網(wǎng)卡, 需要在啟動時(shí)指定參數(shù)--iface與--iface-regex: 我們的虛擬機(jī)數(shù)量少, 物理機(jī)數(shù)量多. 除了eth1, 還有bond1這種網(wǎng)卡名, 因此針對虛擬機(jī), 統(tǒng)一將其eth0改名變成eth1, 而后指定了-iface-regex=eth1|bond1這樣的配置, 對于后續(xù)增加物理機(jī)更友好.

問題到這里似乎就結(jié)束了, 但是隨著 flannel 經(jīng)常發(fā)生 OOM 重啟, 暴露了我們的設(shè)置問題.

我們發(fā)現(xiàn) flannel OOM 后無法正常重啟

NAME????????????????????????????????????????????????????READY???STATUS?????????????RESTARTS???AGE?????IP???????????????NODE?????????????????????????????????NOMINATED?NODE???READINESS?GATES
kube-flannel-ds-amd64-54c5p?????????????????????????????0/1?????CrashLoopBackOff???1604???????516d????10.xx.xx.xx?xxxxx????????????????????
kube-flannel-ds-amd64-cmczh?????????????????????????????0/1?????CrashLoopBackOff???89?????????388d????10.xx.xx.xx?yyyyy????????????????????

為什么一開始沒出現(xiàn), 但是重啟又會發(fā)生呢, 問題出在了正則表達(dá)式上. K8s 在機(jī)器上啟動容器時(shí), 會創(chuàng)建虛擬的網(wǎng)卡. 這些網(wǎng)卡的名字類似veth17f90f70@if3, 這樣網(wǎng)卡名稱的也會被正則表達(dá)式匹配到, 導(dǎo)致 flannel 無法啟動, 臨時(shí)的解決方案就是把機(jī)器上的容器移走, vethxxx網(wǎng)卡會自動刪除, flannel 也就自動恢復(fù)了.

當(dāng)然根本的解決方案是修改正則配置: - -iface-regex="^(bond1|eth1)$" 使 flannel 更加精準(zhǔn)的匹配網(wǎng)卡名稱.

flannel 配置更新與驗(yàn)證

更新準(zhǔn)備

因?yàn)椴惶私?flannel 是否處理流量, 更新 flannel 時(shí)有點(diǎn)害怕, 直到看到了這里的架構(gòu).

flannel 的功能主要是負(fù)責(zé)機(jī)器上路由表的修改, 也就是說, 只要不增刪機(jī)器, flannel 掛掉也沒關(guān)系, 因?yàn)槁酚杀聿恍枰薷?

更新

我們有 100 多臺節(jié)點(diǎn), 整個(gè)集群更新過程大概持續(xù)了 1 個(gè)多小時(shí), 更新過程中服務(wù)完全正常.

驗(yàn)證可用性

內(nèi)存使用情況:

為了驗(yàn)證 flannel 是否可用, 我們將一臺 node 刪除, 觀察到其他機(jī)器上的路由表也同步進(jìn)行了修改.

總結(jié)

1. 問題出現(xiàn)不可怕, 重要的是加好監(jiān)控及時(shí)報(bào)警, 我們之前一直對 kube-system 的監(jiān)控沒有做到很好, flannel 一直啟動不成功的問題是我檢查時(shí)發(fā)現(xiàn)的,
2. 使用別人提供的 yaml 文件前, 要注意下資源設(shè)置的, 類似 Prometheus 也有這種問題的, 它對內(nèi)存的要求很高
3. 預(yù)算充足就不要自建集群了, 有不少運(yùn)維問題的, 萬一出現(xiàn)一個(gè)解決不了的就很麻煩, 類似上次那篇文章: 記一次 Kubernetes 機(jī)器內(nèi)核問題排查^[1]

希望我們的經(jīng)驗(yàn)?zāi)軒椭绞褂?K8s 的各位讀者.

引用鏈接

你可能還喜歡

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

云原生是一種信仰???

關(guān)注公眾號

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