我先假定今晚的聽眾至少小范圍的鋪開 docker 容器化技術(shù)在線上了，至少熟悉 docker 的工作原理和 remote api。所以我不會(huì)對(duì)簡單的 docker 操作和使用做太多的分享，主要是分享集群化容器線上管理這塊中的日志管理和網(wǎng)絡(luò)管理。
在早期 docker 實(shí)現(xiàn)中，日志這塊一直都很喪失，所有容器內(nèi)的標(biāo)準(zhǔn)輸出和錯(cuò)誤都會(huì)寫入到 /var/lib/docker/containers/{$cid}/{$cid}-log.json 中。因?yàn)闆]有日志自動(dòng)分卷以及和容器綁定，所以一旦上到線上就會(huì)出現(xiàn)瞬間磁盤打滿的情況。這個(gè)文件同時(shí)又是 docker logs api 的 data source，加之 docker 1.6 引入的 log-driver 參數(shù)，因此對(duì)于線上日志的收集管理我們目前有這么幾個(gè)方法。
- 監(jiān)控這個(gè)文件，通過管道把數(shù)據(jù)轉(zhuǎn)出。這種方案最大的問題是日志文件和容器是綁定的，因此需要有一個(gè) agent 的角色來做這件事，變相的增加了開發(fā)成本，還要考慮管道的可靠性問題。另外 CentOS 6系和7系日志地址不一樣，如果硬編碼則擴(kuò)展性不佳，如果讀取系統(tǒng)配置，那么要考慮跨系統(tǒng)之間的路徑問題。
- 通過 docker logs api 來遠(yuǎn)程重定向日志，這種方法最大的問題是你避免不了還是得有 agent 去清理日志這么個(gè)操作，否則的話依然磁盤會(huì)被打滿，當(dāng)然也可以配合 logrotate 來做這事，不過增加了運(yùn)維成本。如果是遠(yuǎn)端調(diào)用這個(gè) API 的話，要考慮連接可靠性，一旦出現(xiàn)重連，那么顯而易見的是要做日志回溯，否則會(huì)丟失一部分日志。
- 容器內(nèi)進(jìn)程自己把日志寫出
a. 進(jìn)程直接寫出，控制權(quán)交給了業(yè)務(wù)方，對(duì)業(yè)務(wù)不透明，可控性降低，畢竟是集群環(huán)境。這樣一來也要暴露集群結(jié)構(gòu)給上層。
b. 映射日志設(shè)備（/dev/log）進(jìn)容器，容器內(nèi)進(jìn)程直接寫設(shè)備，隔離性減弱，單點(diǎn)問題追蹤會(huì)很麻煩，因?yàn)檫@時(shí)候 stdout 和 stderr 是沒有內(nèi)容的，也就是 docker log 命令無任何輸出。
3.a 的話我們?cè)囘^，不過要讓業(yè)務(wù)方來改代碼整體推進(jìn)進(jìn)度就不太號(hào)控制了。另外暴露了遠(yuǎn)端日志服務(wù)器地址，無論是網(wǎng)絡(luò)上還是安全上都是有問題的。舉個(gè)栗子一旦介入 SDN 等管理網(wǎng)絡(luò)的方式，那么等于就是破壞了整體的隔離性。3.b 就是定位問題 container 比較麻煩，而且還是要涉及到跟業(yè)務(wù)方溝通。 - 使用新版的 log-driver 參數(shù)，其中包含支持 syslog，看似很美好，但是在集群環(huán)境下要考慮 syslog 單點(diǎn)問題。一般來說會(huì)有多個(gè) syslog 或者支持 syslog 協(xié)議的遠(yuǎn)端 server （logstash）。如果使用遠(yuǎn)程 syslog 接受日志，大量 containers 日志輸出并不平均，從而會(huì)產(chǎn)生性能熱點(diǎn)和流量熱點(diǎn)。如果走單機(jī) syslog 再匯總，就跟3.b 沒多大區(qū)別了，跟蹤問題比較麻煩。我覺得目前這個(gè)實(shí)現(xiàn)更多的是方便了之前使用 syslog 方案的。
- attach 方法截獲容器輸出流重定向，需要 agent 支持，有一定開發(fā)要求。目前我們采用這種方案，通過一個(gè)模塊實(shí)現(xiàn)了 consistent hash 把日志流量打到遠(yuǎn)端收集服務(wù)器上。這個(gè)方案只需要讓業(yè)務(wù)把日志輸出到 stdout/stderr 中即可，并不會(huì)增加開發(fā)成本。同時(shí) 1.6 docker 可以指定日志驅(qū)動(dòng)為 none，避免了 logs 文件的產(chǎn)生。另外一方面可以把 container 自己的 meta info 給附加到日志流里面，從而實(shí)現(xiàn)遠(yuǎn)端的日志檢索分類聚合等操作。這個(gè)方案最大的問題是開發(fā)力量的投入，不同個(gè) dockeclient 實(shí)現(xiàn)質(zhì)量也不一樣，當(dāng)然好處也是很明顯的，靈活可控，日志流向和分配都在自己受傷。
所以日志方面，從目前 docker 實(shí)現(xiàn)來看，如果開發(fā)力量跟得上，agent + attach 方案是靈活性和可控性是最高的。目前 log-driver 對(duì)于上規(guī)模的集群來說還是不太好用，理想狀態(tài)下我希望是可以指定多個(gè) log-drivers，通過 hash 方案打到遠(yuǎn)端。當(dāng)然具體方案的選取就得看各自公司本身的基礎(chǔ)設(shè)施和設(shè)計(jì)目標(biāo)了。
說完日志來說下網(wǎng)絡(luò)，目前 docker 的網(wǎng)絡(luò)方案主要有這么幾個(gè)，當(dāng)然現(xiàn)在大家都在等 1.7，不過我認(rèn)為對(duì)于生產(chǎn)系統(tǒng)而言，已有 SDN 方案的不會(huì)太過于在乎 libnetwork，可能會(huì)研究下其和 docker 是怎樣通過 plugin 方式結(jié)合的。因?yàn)槠渌桨改壳岸际?Hook 方式去做的。
- 默認(rèn) NAT/BR/HOST，NAT 有性能損失，BR 有網(wǎng)絡(luò)閃斷，HOST 流控不好做，端口沖突靠業(yè)務(wù)保證沒法做到透明。
- 網(wǎng)絡(luò)層方案
a. 隧道方案
I. OVS，主要是有性能方面的損失，基于 VxLAN 和 GRE 協(xié)議，類似的方案還有 Kubernetes/Socketplane 的實(shí)現(xiàn)
II. Weave，UDP 廣播，本機(jī)建立新的 BR，通過 PCAP 互通
III. Flannel，UDP 廣播，VxLan
隧道方案非常靈活，但是因?yàn)樘^于靈活，出了網(wǎng)絡(luò)問題（A-B 鏈路抖動(dòng)）跟蹤起來比較麻煩，大規(guī)模集群情況下這是需要考慮的一個(gè)點(diǎn)，畢竟即便是內(nèi)網(wǎng)也不一定風(fēng)平浪靜。
b. 路由方案
I. Pipework，對(duì)于 Docker BR 本身的擴(kuò)展，當(dāng)然也支持 OVS macvlan 等方案的結(jié)合?，F(xiàn)在 libnetwork 出來變相的是廢了這個(gè)項(xiàng)目了，長遠(yuǎn)來看后繼無人，因此它不是一個(gè)很好的選擇。
II. Calico，基于 BGP 協(xié)議的路由方案，支持很細(xì)致的 ACL 控制，對(duì)于隔離要求比較嚴(yán)格的場景比較適合，對(duì)混合云親和度比較高，因?yàn)樗簧婕暗蕉拥闹С帧?
III. Macvlan，從邏輯和 Kernel 層來看隔離性和性能最優(yōu)的方案，基于二層隔離，所以需要二層路由器支持，大多數(shù)云服務(wù)商不支持，所以混合云上比較難以實(shí)現(xiàn)。
路由方案沒那么靈活，大多數(shù)情況下需要有一個(gè) agent 在 container host 上去操作，一般是從 3 層或者 2 層實(shí)現(xiàn)隔離和跨機(jī) container 互通的，出了問題也很容易排查。但是路由方案對(duì)本身物理網(wǎng)絡(luò)依賴會(huì)比隧道方案要重。另外 hook 的話畢竟還是不太優(yōu)美，所以得看看 libnetwork 是怎樣和 docker 結(jié)合的。
目前我們選取的是 macvlan 的方案實(shí)現(xiàn)的二層隔離，說輕量主要是對(duì) container 而言，可以完全當(dāng) container 為一臺(tái)虛擬機(jī)。說重量，是因?yàn)槠鋵?duì)物理網(wǎng)絡(luò)基礎(chǔ)設(shè)施依賴程度最高。
Q&A
Q. macvlan 是怎么做的
A. linux 內(nèi)核支持，直接用 agent 在 host 上生成設(shè)備塞入到 container 的 namespace 中。
Q. 為何不直接打日志
A. 容器內(nèi)的話得考慮 docker 本身存儲(chǔ)性能問題，如果是容器外得考慮卷管理問問題，如果是遠(yuǎn)端，得考慮和業(yè)務(wù)結(jié)合的問題
Q. 網(wǎng)絡(luò)層比較成熟的選擇
A. macvlan 進(jìn)了內(nèi)核，Calico 做了十來年了，這2者都會(huì)比較成熟，weave 比較簡單和方便
Q. 日志丟失問題
A. 盡可能的不讓業(yè)務(wù)層去控制日志輸出，即便是 socket 文件或者設(shè)備都有可能被刪除從而導(dǎo)致日志丟失，因此盡量從平臺(tái)層面控制
Q. 二進(jìn)制服務(wù)跑在 docker 里面的問題
A. 目前我們也在做類似的事情，把 redis 跑入。但是因?yàn)?container 本身沒有 init 進(jìn)程，因此內(nèi)核參數(shù)都是默認(rèn)的，有些 binary 應(yīng)用在這方面會(huì)比較敏感。我們目前也沒找到比較優(yōu)美的方法解決。docker 官方 github 有不少類似的 issue
本站僅提供存儲(chǔ)服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)
點(diǎn)擊舉報(bào)。
