使用kubernetes一年之後的思考
本文首發於我的blog
從去年10月份第一次接觸kubernetes，到年初系統學習，然後到上個月接手來運維kubernetes叢集，也算是對kubernetes有一些瞭解了。在學習一個技術的時候，對技術的使用場景和發展趨勢應該有自己的看法，這樣才知道如何結合團隊情況和公司的發展合理的採用一個技術。所以這裡我巨集觀上談一下我對kubernetes技術的一些思考。
kubernetes背景和誕生目的
kubernetes誕生的背景是因為Docker和Paas，對於稍微複雜的業務是不能直接用Docker的，因為Docker提供的能力實在有限，複雜的業務上雲一般需要一些平臺層面的能力，也就是Paas。kubernetes就是這個背景誕生的，擊敗了Mesos等競爭對手，成為容器編排領域事實上的標準。
所以按照技術的誕生背景來說，kubernetes的目的就是要做Paas，所以要玩好kubernetes必須對Paas有個大局觀，下圖是左耳朵耗子梳理的Paas結構圖，我覺得挺全面了：
基於kubernetes構建Paas的原因在於：
- kubernetes本身提供了一些核心的能力比如服務發現，statefulset，負載均衡，服務狀態檢查並且自動重啟等等；
- kubernetes提供了一些外掛化的機制（CRD，動態准入控制等等）使得DIY，或者增強kubernetes的能力變得簡單；
- kubernetes社群非常活躍，誕生了非常多的高質量專案，比如Prometheus，Rook等等；
因為這幾個原因，基於kubernetes構建Paas變得更加簡單。
入手難度
kubernetes入手確實有一些難度，尤其是運維kubernetes叢集，不僅需要懂kubernetes的知識，還需要懂公有云的使用。基於此，很多公有云廠商推出了kubernetes託管服務，不僅降低了kubernetes運維成本，也更好的和已有的服務結合起來（比如阿里雲的kubernetes託管服務，不再需要自己搭建ELK了，可以使用阿里雲的日誌系統）。
但是使用託管服務的時候不要覺得用了託管服務了自己的學習成本就降低了，對於kubernetes運維人員還是需要了解kubernetes的各個元件，瞭解雲供應商各種產品使用。只有這樣，才知道如何規劃叢集的網路，容量，儲存等等，才知道業務如何改造才能上kubernetes。
業務如何上kubernetes
這裡提三點。
- 服務需要設定合理的存活探針和就緒探針，這樣kubernetes才知道什麼時候殺掉Pod啟動一個新的，什麼時候把流量交給Pod。
- 設定合理的資源request和limit，一般request設定一個應用平均的資源利用值，limit設定一個稍高一些的值。
- 線上業務和離線業務混部需要額外注意，防止離線業務佔用太多node資源導致node資源緊張從而殺掉線上業務。如果做不到這一點就不要做混部，利用nodeselector和toleraions來把線上和離線業務的pod分別部署到對應的node上去。
收益
這大半年用kubernetes的收益是：
- 資源高度彈性。離線業務來的時候申請spot例項，計算完畢之後就會自動回收spot例項，所以離線計算消耗的計算資源價格非常低；
- 更加敏捷。不用找運維申請物理機了，直接部署pod就好了，如果叢集的資源不夠，會自動擴容，完全不用擔心計算資源不夠的問題；
- 能力複用，尤其是監控的能力，把metric全部匯入Prometheus，藉助Prometheus+Grafana，整個監控體系非常簡單；
- 提高資源利用率，尤其是可以做到業務混部；