自習周報: 從容器大會到運維大會

01-29

在寫周報第一期的時候我說不會介紹容器相關的技術，主要因為現在太多和容器相關的技術文章寫得比較水，都是想蹭容器的熱度或者來做營銷，質量就可想而知了。我自己現在周末如果參加技術的線下分享，一看是容器都都會選擇忽略掉。記得兩年之前容器大會上還經常能看到一些比較新奇的東西，大家都有著自己創意性的黑魔法，而最近都是換湯不換藥的持續構建，持續部署，微服務化這樣的老東西，甚至在一些付費的會上還能看到有人講什麼是容器，什麼是鏡像，介紹 Kubernetes 的基礎概念這樣的事情，作為圈裡的人我自己臉上都掛不住。

這不，去年的 CNUTCon 大會還叫全球容器大會，今年就改叫全球運維技術大會了，估計主辦方也發現只講容器大概撐不起一場大會了。儘管這個大會上依然有我說的那些問題，不過還是有幾個不錯的乾貨分享值得仔細的看一下，另外擴充了運維的東西也可以看看運維方面的一些新東西。下面就摘幾篇我覺得不錯的推薦給大家。（可惜我廠容器這塊的黑魔法現在不能說出來，不然的話絕對能帶來一些全新的思路）

https://share.weiyun.com/70421d5590127467b265c09ddc57ad4c

是一個好心人上傳的 CNUTCon 17 的全部 ppt，包括我下面要重點介紹的（本來還想列一下哪些就不要浪費時間看的，然而怕被噴就算了，你們也知道容器這個圈子有多亂）。

1. Kubernetes在大規模場景下的 service 性能優化實戰

這是一篇華為做的關於 service 利用 iptables 和 IPVS 兩種不同實現方式的性能測量。我們都知道 iptables 在性能上有很大的劣勢，但是 kubernetes 大概是因為歷史原因默認使用了這種方式，小規模還好，但是當存在大量 service 的時候對 iptable 的壓力肯定是特別大的。但是這個影響究竟有多大，華為的工程師做了細緻的測試，包含了大量的測試數據。隨便舉量個，在 5k service 的情況下，新加一個 service 刷新 iptable 要 11 分鐘，內存花費 1.9G，CPU 消耗 50%~85%。而當有 25k 個 service 的時候帶寬就降到 0 了。至於為什麼會有這麼大的影響以及 IPVS 的性能如何，都可以通過 PPT 仔細的去看下，等待著 IPVS 的 service 實現早日合到主分支。

2. 華為使用Docker支持系統容器的優化實踐

依然是來自華為的一篇分享，介紹的是一類之前被提及比較少的容器使用場景——系統容器。一般容器的使用場景劃分是有狀態無狀態，但系統容器會特殊一些，比如需要把 LVS 容器化，LVM 容器化，在容器里管理宿主機的硬體設備，操作 systemd 等等這樣一些操控宿主機的操作，如果想容器化會碰到一些意想不到的問題，包括許可權，udev, namespace，cgroup 的種種坑。儘管碰到的機會可能不多，但碰到就足夠喝一壺的，作者介紹了很多 hack 和 workaround 方法，值得 mark 一下，碰到問題後來借鑒一下。

3. 百度大規模時序指標自動異常檢測實戰

最近不知道為什麼又火了一個詞叫 AIOps，儘管這個分享沒有蹭這個熱詞，但是從分享的技術層面上確實是使用了大量統計分析的知識來解決自動化設置監控閾值進行報警的功能。在我當運維的時候加監控報警的時候最頭疼的就是該如何設置閾值，有的業務每天是有波動的不是一直在平穩狀態，沒法設置一個固定值又不能不設，有的業務是隨著時間各種指標都會發生變化，之前加的不一定準確，總之加上去的報警不是沒有問題誤報就是出了問題沒報出來，作者提供了最實際可行的通過數據分析的方法來改善當前監控報警不準確，不能動態變化，需要人憑藉經驗來設置閾值的情況，可以很大的改善監控的情況。

周末愉快！