使用kubernetes一年以後的思考

本文首發於個人blog

從去年10月份第一次接觸kubernetes，到年初系統學習，而後到上個月接手來運維kubernetes集羣，也算是對kubernetes有一些瞭解了。在學習一個技術的時候，對技術的使用場景和發展趨勢應該有本身的見解，這樣才知道如何結合團隊狀況和公司的發展合理的採用一個技術。因此這裏我宏觀上談一下我對kubernetes技術的一些思考。

kubernetes背景和誕生目的

kubernetes誕生的背景是由於Docker和Paas，對於稍微複雜的業務是不能直接用Docker的，由於Docker提供的能力實在有限，複雜的業務上雲通常須要一些平臺層面的能力，也就是Paas。kubernetes就是這個背景誕生的，擊敗了Mesos等競爭對手，成爲容器編排領域事實上的標準。

因此按照技術的誕生背景來講，kubernetes的目的就是要作Paas，因此要玩好kubernetes必須對Paas有個大局觀，下圖是左耳朵耗子梳理的Paas結構圖，我以爲挺全面了：

基於kubernetes構建Paas的緣由在於：

1. kubernetes自己提供了一些核心的能力好比服務發現，statefulset，負載均衡，服務狀態檢查而且自動重啓等等；
2. kubernetes提供了一些插件化的機制（CRD，動態准入控制等等）使得DIY，或者加強kubernetes的能力變得簡單；
3. kubernetes社區很是活躍，誕生了很是多的高質量項目，好比Prometheus，Rook等等；

由於這幾個緣由，基於kubernetes構建Paas變得更加簡單。

入手難度

kubernetes入手確實有一些難度，尤爲是運維kubernetes集羣，不只須要懂kubernetes的知識，還須要懂公有云的使用。基於此，不少公有云廠商推出了kubernetes託管服務，不只下降了kubernetes運維成本，也更好的和已有的服務結合起來（好比阿里雲的kubernetes託管服務，再也不須要本身搭建ELK了，可使用阿里雲的日誌系統）。

可是使用託管服務的時候不要以爲用了託管服務了本身的學習成本就下降了，對於kubernetes運維人員仍是須要了解kubernetes的各個組件，瞭解雲供應商各類產品使用。只有這樣，才知道如何規劃集羣的網絡，容量，存儲等等，才知道業務如何改造才能上kubernetes。

業務如何上kubernetes

這裏提三點。

1. 服務須要設置合理的存活探針和就緒探針，這樣kubernetes才知道何時殺掉Pod啓動一個新的，何時把流量交給Pod。
2. 設置合理的資源request和limit，通常request設置一個應用平均的資源利用值，limit設置一個稍高一些的值。
3. 在線業務和離線業務混部須要額外注意，防止離線業務佔用太多node資源致使node資源緊張從而殺掉在線業務。若是作不到這一點就不要作混部，利用nodeselector和toleraions來把在線和離線業務的pod分別部署到對應的node上去。

收益

這大半年用kubernetes的收益是：

• 資源高度彈性。離線業務來的時候申請spot實例，計算完畢以後就會自動回收spot實例，因此離線計算消耗的計算資源價格很是低；
• 更加敏捷。不用找運維申請物理機了，直接部署pod就行了，若是集羣的資源不夠，會自動擴容，徹底不用擔憂計算資源不夠的問題；
• 能力複用，尤爲是監控的能力，把metric所有導入Prometheus，藉助Prometheus+Grafana，整個監控體系很是簡單；
• 提升資源利用率，尤爲是能夠作到業務混部；