現(xiàn)有平臺面臨的挑戰(zhàn)

不同企業(yè)開始往容器方向發(fā)展的初衷是不一樣的，有些企業(yè)是因為沒有運維工程師或運維團隊，而想要借助某個平臺實現(xiàn)運維自動化。

有些企業(yè)可能是由于計算資源的利用率比較低。雖然一些大型的互聯(lián)網(wǎng)公司都是動輒擁有成千上萬臺服務(wù)器，但實際上以我個人的經(jīng)歷來看計算資源的利用率都不高，這里有很多歷史的原因，其中之一就是為了獲得更好的隔離性，而實現(xiàn)隔離最好的辦法就是采用從物理機到基于虛擬的私有云技術(shù)。

對于有著比較長歷史的公司，應(yīng)用部署往往會和本地的運行環(huán)境強相關(guān)，使得遷移變得非常困難，這時也需要有一個好的解決方案來解耦。另外業(yè)務(wù)總量的繁多，也會帶來管理的復(fù)雜度的提高。

為什么選擇Kubernetes

上面提到的這些問題在我們的生產(chǎn)實踐中都有不同程度的遇到，雖然有很多的解決方案，但是我們最終還是選擇了Kubernetes。

Kubernetes首要解決了計算資源利用率低下的問題，得益于此我們的服務(wù)器數(shù)量減少了一半。容器化解決了計算資源利用率問題。

業(yè)務(wù)容器鏡像一次構(gòu)建，就能夠運行在多種環(huán)境上，這種方式減少了對運行環(huán)境的以來，給運維平臺帶來了足夠的靈活性，解決了服務(wù)商鎖定的問題，我們當(dāng)時考慮的是如果某個IDC服務(wù)商不滿足服務(wù)要求如何做到快速遷移，一般來說大批量的服務(wù)遷移代價非常高，需要很長時間，容器化之后業(yè)務(wù)遷移時間只需要30分鐘左右。

通過Kubernetes的架構(gòu)設(shè)計思想我們還可以規(guī)范網(wǎng)站系統(tǒng)的架構(gòu)設(shè)計。最后還有一點就是它實現(xiàn)了運維自動化。

向容器云平臺遷移前的準(zhǔn)備工作

要想向容器云遷移，企業(yè)內(nèi)部需要一定的運維能力，如果企業(yè)的規(guī)模還不夠大，也可以考慮一些國內(nèi)的容器云服務(wù)提供商。下面來說下我們自己所做的一些準(zhǔn)備工作。

首先自然是搭建Kubernetes集群，私有Docker鏡像倉庫構(gòu)建采用的是harbor，然后是獨立出來的集群監(jiān)控，CI/CD基礎(chǔ)設(shè)置使用的是Jenkins和helm，分布式存儲解決方案用的是Glusterfs。

業(yè)務(wù)遷移中使用的規(guī)范

從2015年底1.0版到之后的1.2、1.3版Kubernetes中的問題還是比較多的，企業(yè)要使用它是需要一定勇氣的。但現(xiàn)在基本上趨于成熟，對于大部分應(yīng)用不用太多的改造也可以跑的很好。

即使是這樣，也不是所有的應(yīng)用都可以遷移到容器云中，如果應(yīng)用能夠很好的符合云原生的設(shè)計原則當(dāng)然可以遷移進(jìn)來，但是大部分的應(yīng)用并不是按照這樣的設(shè)計原則設(shè)計的。這個時候最好的辦法是先將業(yè)務(wù)遷移進(jìn)來，然后再逐步演進(jìn)成微服務(wù)架構(gòu)。

在這個過程中我們剛開始其實也沒有任何規(guī)范，之后才陸續(xù)制定了相關(guān)規(guī)范，下面來具體看下遷移規(guī)范。

容器鏡像封裝的基本原則

早期很多系統(tǒng)架構(gòu)師都將Docker當(dāng)做輕量級的虛擬機在使用，但這并不是最佳實踐，要想正確的使用Docker需要符合以下基本原則：

- 盡可能設(shè)計成無狀態(tài)服務(wù)，它帶來的好處就是能夠非常容易的做水平擴展

- 盡可能消除不必要的運行環(huán)境依賴，如果容器內(nèi)業(yè)務(wù)依賴太多水平擴展就會變的非常困難，在傳統(tǒng)的部署形式下，無論是虛擬機部署還是物理機部署都經(jīng)常會產(chǎn)生各種各樣沒必要的依賴，對于有一定歷史的企業(yè)這個問題就會非常嚴(yán)重

- 需要持久化的數(shù)據(jù)寫入到分布式存儲卷

- 盡可能保證業(yè)務(wù)單一性，這樣能夠讓分布式應(yīng)用很容易擴展，免備案主機，同樣它也是微服務(wù)架構(gòu)中的設(shè)計原則

- 控制輸出到stdout和stderr的日志寫入量

- 配置與容器鏡像內(nèi)容分離

- 容器中使用K8S內(nèi)部dns代替ip地址配置形式

- 日志采用集中化處理方案（EFk）

- 采用獨立的容器處理定時任務(wù)

NameSpace的使用

由于考慮到測試環(huán)境和staging等運行環(huán)境的資源利用率并不高，所以就想在一個集群內(nèi)部同時運行開發(fā)、測試、staging、生產(chǎn)環(huán)境。通過NameSpace實現(xiàn)不同運行環(huán)境的隔離，同時應(yīng)用軟件在不同的運行環(huán)境之間也不會產(chǎn)生命名沖突。

Service的命名規(guī)范

在v1.5版之前Service的命名不能超過24個字符，v1.5版之后最多63個字符。另外還需要滿足正則regex[a-z]([-a-z0-9]*[a-z0-9])?的要求，這意味著首字母必須是a-z的字母，末字母不能是-，其他部分可以是字母數(shù)字和-符號。一般來說命名方式都是使用“業(yè)務(wù)名-應(yīng)用服務(wù)器類型-其他標(biāo)識”的形式，如book-tomcat-n1、book-mysql-m1等。

應(yīng)用健康檢查規(guī)范