【導讀】：Netflix架構師在使用Kubernetes一年后，回顧了團隊遷移到Kubernetes的好與壞，取與舍。

2015年時，我們的團隊在亞馬遜EC2部署服務已經有幾年了。這時我所在的團隊接到一項任務，要創建所有研發團隊都可以使用的全新部署平臺。這些年以來基于AWS的平臺的新版本發布雖然已經足夠流暢，但如果要用定制化腳本或工具做自動化部署，對于非運維團隊人員來說就不那么易用了。對于沒資源學習所有定制化工具和腳本細節的小團隊尤其困難。主要問題是，AWS沒有模塊化部署，而沒有模塊化部署研發和運維之間就存在一定隔閡。容器化正是要解決這個隔閡的，而且容器化是趨勢。

如果你們還沒在生產中使用Docker和kubernetes，看看我們團隊是怎么吃螃蟹的。我們已經在生產環境使用kubernetes有一年多了。

首先從容器和容器編排工具入手

我認為，容器是未來的部署格式。使用容器，非常方便用服務所需的基礎層進行打包。Docker這類工具雖然提供了容器，我們也需要管理副本和做故障轉移的工具和API，有了這些才能自動化部署多臺機器。

Kubernetes和docker swarm這類工具在2015年還很不成熟，只有一些早期的可用于生產環境的版本。我們還是決定從docker swarm開始用起。

一開始我們用docker swarmd來管理網絡。我們用“大使模式"和一堆腳本，達到部署自動化的目的。這有多困難呢？這是我們趟的第一個坑：容器集群、網絡、部署自動化是非常難處理的

我們很快意識到了這點，這時決定嘗試另一個工具，kubernetes。kubernetes看起來是最好的選擇，因為它有來自google、紅帽、Core OS等確切了解大規模部署的組織的技術支撐。

kubernetes做負載均衡

譯注：翻譯本文時ingress已經可用了, 負載均衡相關的內容可以直接跳過。關于ingress、負載均衡、clusterIP和NodePort之間的區別參考下文中《Ingress vs. ClusterIP vs. NodePort vs. LoadBalancer 》部分 https://www.ibm.com/cloud/blog/kubernetes-ingress

用kubernetes工作，就要非常熟悉它的概念，比如pod、service、replication controller等。如果你還沒對這些概念非常了解，可以讀讀kubernetes文檔。kubernetes官網為初學者提供了很多文檔。

http://kubernetes.io/docs/whatisk8s/

只要有一個在運行的kubernetes集群，就可以用kubectl部署一個服務了。kubectl是kuberntes的命令行接口。但很快就遇到了自動化部署的瓶頸。但在自動化部署前還要解決不能通過網絡請求部署服務的問題。

部署接口是有一個服務，但是這個服務的IP地址在集群內部。也就是部署應用的服務根本不暴露給網絡請求！在Google Cloud Engine上可以通過配置一個負載均衡來訪問kubernetes服務。但如果不是在GCE用kubernetes，就需要額外做一些事情讓kubecctl可以通過網絡訪問。

通過kubernetes宿主機網絡和端口直接暴露服務接口，這個解決辦法比較容易，很多人都是這么做的。但如果我們的服務依賴著宿主機的端口，部署多個應用時就會產生端口沖突。這也讓擴展集群或替換掉宿主機變得很麻煩。

兩步搭建負載均衡

在kubernetes集群前端配置如HAProxy和NGINX這類負載均衡服務是比較方便的解決方案。我們在AWS上用VPN訪問kubernetes集群，用AWS的Elastic Load Balancer把外部流量接入集群內的HAProxy。HAProxy給每個Kubernetes服務都配置了一個接口，這個接口把流量分發給每個pod。

這個兩步搭建負載均衡是為了繞過AWS ELB的限制做的。ELB不能處理多個虛機，這也是我們用HAProxy的原因。只使用HAProxy不用ELB也可以，但這樣就要想辦法在DNS層繞過動態AWS IP地址。

圖1：兩步負載均衡的工作原理

當前kubernetes正在開發ingress的功能。這個功能會允許直接從kubernetes內部定義外部負載均衡。當前這個功能還沒實現完，去年我們是用api和一些開源工具做的可配置的負載均衡。https://kubernetes.io/docs/concepts/services-networking/ingress/

配置負載均衡

首先我們需要一個存儲負載均衡配置的地方。這個配置可以放在任何地方，但既然已經有etcd了，我們就決定把數據存到etcd。我們用confd這個工具監聽etcd中配置的變化，基于模板生成新HAProxy配置文件。新服務添加到Kubernetes中時，在etcd中增加一個配置，這就會觸發新HAProxy文件的生成。

Kubernetes越來越成熟

Kubernetes依然存在很多未解決問題，就像負載均衡那樣問題多多。很多問題會被社區識別后寫出設計文檔，文檔中討論可以解決問題的新功能。但是產出通用的解決方案需要消耗大量時間，也就是說這些文檔里討論的功能可能需要很久才能發布到新版本里。這是件好事，長期來看設計新功能時省事有害無益。

雖然發布新功能耗時不短，Kubernetes并沒有被限制住。使用kubernetes API幾乎可以做到任何你想做的事。一旦社區發布了解決方案，我們就用標準方案替換我們定制化開發的方案。

定制化開發了負載均衡結局方案，下一個挑戰是實現一個特別重要的部署能力：藍綠發布。

Kubernetes內做藍綠發布

藍綠發布的服務是在發布過程中沒有任何服務不可用時段的。和滾動發布相比，藍綠發布是通過創建一個新集群副本，上面跑著新版本的服務，老版本的服務依然存在、而且在接收事實流量。只有新副本完全部署好、已經運行起來，這時負載均衡會把流量切給新版本的服務。

這種發布方式的好處是同一時刻，只有一個版本的服務在工作，不需要考慮版本兼容的問題。藍綠發布對于實例數量少的副本更友好。

圖2：藍綠發布的工作原理

圖2里有一個組件叫Deployer，它負責調度整個發布流程。你的團隊可以創建這個組件，我們已經把我們的實現作為Amdatu項目的一部分、使用Apache協議開源了。這個組件還有可以配置部署的web界面。

https://bitbucket.org/amdatulabs/amdatu-kubernetes-deployer

https://bitbucket.org/account/user/amdatulabs/projects/INFRA

重新配置負載均衡前，需要對每個pod做健康檢查，這個機制在藍綠發布里非常重要。我們希望每個我們部署的組件都提供一個監控檢查功能。我們通常會給每個程序添加一個HTTP健康檢查服務。

自動化部署

有了Deployer，就能把部署綁定到某個pipeline上了。打鏡像成功后，構建服務器就會把新的docker鏡像推到鏡像服務器上。比如推給Docker Hub。然后構建服務器觸發Deployer，自動部署新版本到test環境。同樣一個鏡像可以被推到生產環境，只需觸發生產環境的Deployer即可進行部署。

圖3：自動化容器部署流水線

了解資源限制

用Kubernetes就必須了解資源限制機制。可以配置每個pod的請求數和CPU、內存的限制，也可以控制給定資源數和突發資源數的限制。

https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

這些配置對同時、高效運行多個容器很重要，如果沒有正確地配置，容器可能會因為沒有被分配足夠內存而經常崩潰。

早早開始配置并測試容器的資源限制，沒有資源限制的集群依然會運行，不過一旦給某些容器真正的流量，就會出大問題。

怎么給k8s做監控

基本部署好k8s之后，我們很快意識到監控和日志對這種動態環境來說非常重要。如果你面對著數量眾多的副本和節點，登陸一臺服務器看日志文件這件事就不再可行。一旦開始用kubernetes，就需要規劃集中式的日志和監控了。

日志

日志有數量眾多的開源工具可供選擇。日志管理工具Graylog，從容器中采集和消費數據用Kafka消息隊列。容器發送日志到kafka，kafka把日志交給graylog建索引。我們讓容器自己發日志到Kafka，這樣處理日志就很容易。還有其他一些方案可以從外部取容器內的日志、把日志發到日志管理系統的方案的做法，參考：https://www.loggly.com/blog/top-5-docker-logging-methods-to-fit-your-container-deployment-strategy/

監控

kubernetes在容器掛掉后恢復做的非常好。當容器由于某種原因崩潰，kubernetes會做容器重啟。如果Kubernetes里運行著一個副本，終端用戶可能無法注意到程序重啟了。Kubernetes的恢復做的太好，以至于我們遇到過一組容器由于內存泄露，一天重啟了好多次但沒人知道重啟動這種情況。

盡管從kubernetes的角度看沒問題，但我們開發和維護人員還是需要知道是否程序存在問題的。我們用一個定制化的健康檢查大盤，監控所有kubernetes節點、每個pod和其他如數據存儲之類的服務。每個pod的健康檢查是使用了對當前某個服務的檢查。要實現這樣一個大盤，kubernetes api又一次變得十分重要。

度量負載、吞吐量、程序錯誤等數據也很重要，這時候就要使用開源工具了。我們的應用組件把數據發送到InfluxDB這個時序數據庫里。存儲在InfluxDB內的數據可以通過Grafana做可視化，Grafana是開源數據大盤管理系統。除了influxdb + grafana之外還有很多其他可選項，任意解決方案都可以提升系統問題的可觀測性。

kubernetes和數據存儲

很多新k8s用戶問，“我該怎么用kubernetes處理數據存儲呢？”

用MongoDB和MySQL這類數據存儲，一般都要把數據持久化地存儲起來。容器重啟時會丟失上次的數據，這對無狀態的組件沒什么問題，但是對于持久化數據存儲，這樣非常不好。kubernetes對持久化數據有volumn這個概念。

一個volume可以有多種底層實現，包括存儲在宿主機的文件、AWS EBS、NFS等。雖然volume算是個好解決方案，但是對我們運行著的數據存儲來說不是一個好方案。

副本問題

多數deployment中，數據存儲都會以復制的方式運行。典型就是Mongodb里的replica set、mysql以主副節點模式運行。這引入了一些新問題，首先是每個節點的數據存儲集群都可能是不同的系統。寫入同一個卷可能導致數據不可用。另一個問題是多數數據存儲都需要準確的用來啟動集群的配置參數，自動發現、自動配置節點并不常見常用。

一臺運行著數據存儲的機器要為負載做特殊的配置，比如配置更高IOPS。這樣一來，對于數據存儲，使用k8s做增加刪除節點的成本會大大增加。這些特性與k8s部署的動態特性適配性不好。

不在生產環境中使用Kubernetes存儲數據

我們認為在Kubernetes中做數據存儲收益有限。在K8S中啟動數據存儲比大多數kubernetes deployment都復雜。

鑒于此，我們決定把生產數據存儲到kubernetes節點中。我們在其他機器上手動部署集群，使用必要的手段優化特定數據存儲。運行在Kubernetes中的服務和訪問其他服務一樣連接并訪問存儲節點。不是有Kubernetes了就一定要把所有東西都部署上去。除了數據存儲和HAProxy服務器，其他在kubernetes內運行，包括日志和監控。

為什么我們對明年kubernets的表現非常期待

看看我們部署的系統，kubernetes已經非常強大了。kubernetes API是做自動化和部署pipeline的極好的工具。deployment又快又可靠，我們也不再跟虛擬機打交道了。我們的構建和部署因為測試、維護容器更容易也變得更可靠了。

可見，采取這種部署方式對于想跟上業界其他頻繁部署應用、而且要降低部署開銷的團隊的步伐也是非常必要的。

計算成本

看下成本。跑kubernetes需要一個etcd集群和一個master節點，運行這些花費不高，但是對于部署規模不大的集群來說可能成本占比會更高。對于部署規模小的部署，使用Google的容器化服務解決方案可能是更好的選擇。

對于大規模部署來說，這可以節省很多在服務方面的開銷。這時運行etcd和一個master節點不會是顯著的消耗了。kubernetes可以在同一臺機器上要運行很多容器、并最大限度地使用資源。這減少了所需的服務器數量，進而更省錢。盡管使用K8s聽起來很好，但是對于運維這種大集群來說就不那么好做了，有許多托管服務需要考慮，包括我的團隊正在研究的云RTI。

Kubernetes的光明未來

用預發布版本的kubernetes非常有挑戰，跟進新版本更新有時候幾乎是不可能的。近一年來，kubernetes的開發一直以來都在飛快地進行，社區已經變成了開發人才們的發電站。社區一年時間的進展可能是難以估算的。

責任編輯：lq