一、現(xiàn)有平臺(tái)面臨的挑戰(zhàn)

不同企業(yè)開始往容器方向發(fā)展的初衷是不一樣的，有些企業(yè)是因?yàn)闆]有運(yùn)維工程師或運(yùn)維團(tuán)隊(duì)，而想要借助某個(gè)平臺(tái)實(shí)現(xiàn)運(yùn)維自動(dòng)化。

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

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

[[238633]]

二、為什么選擇Kubernetes

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

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

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

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

三、向容器云平臺(tái)遷移前的準(zhǔn)備工作

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

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

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

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

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

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

1. 容器鏡像封裝的基本原則

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

• 盡可能設(shè)計(jì)成無狀態(tài)服務(wù)，它帶來的好處就是能夠非常容易的做水平擴(kuò)展
• 盡可能消除不必要的運(yùn)行環(huán)境依賴，如果容器內(nèi)業(yè)務(wù)依賴太多水平擴(kuò)展就會(huì)變的非常困難，在傳統(tǒng)的部署形式下，無論是虛擬機(jī)部署還是物理機(jī)部署都經(jīng)常會(huì)產(chǎn)生各種各樣沒必要的依賴，對(duì)于有一定歷史的企業(yè)這個(gè)問題就會(huì)非常嚴(yán)重
• 需要持久化的數(shù)據(jù)寫入到分布式存儲(chǔ)卷
• 盡可能保證業(yè)務(wù)單一性，這樣能夠讓分布式應(yīng)用很容易擴(kuò)展，同樣它也是微服務(wù)架構(gòu)中的設(shè)計(jì)原則
• 控制輸出到stdout和stderr的日志寫入量
• 配置與容器鏡像內(nèi)容分離
• 容器中使用K8S內(nèi)部dns代替ip地址配置形式
• 日志采用集中化處理方案(EFk)
• 采用獨(dú)立的容器處理定時(shí)任務(wù)

2. NameSpace的使用

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

3. Service的命名規(guī)范

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

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

應(yīng)用健康檢查規(guī)范是實(shí)現(xiàn)自動(dòng)化運(yùn)維的重要組成部分，也是系統(tǒng)故障自動(dòng)發(fā)現(xiàn)和自我恢復(fù)的重要手段。目前有兩種健康檢查方式，分別是進(jìn)程級(jí)和業(yè)務(wù)級(jí)。

進(jìn)程級(jí)健康檢查是Kubernetes本身具備的，它用來檢驗(yàn)容器進(jìn)程是否存活，是默認(rèn)開啟的。

業(yè)務(wù)級(jí)的健康檢查由我們自己實(shí)現(xiàn)，它有三點(diǎn)要求，一是必須要檢查自身核心業(yè)務(wù)是否正常，二是健康檢查程序執(zhí)行時(shí)間要小于健康檢查周期，三是健康檢查程序消耗資源要合理控制，避免出現(xiàn)服務(wù)抖動(dòng)。

健康檢查程序在不同環(huán)境下有著不同的實(shí)現(xiàn)：

• web服務(wù)下采用HTTPGET方式進(jìn)行健康檢查，需要實(shí)現(xiàn)一個(gè)“/healthz”URL，這個(gè)URL對(duì)應(yīng)的程序需要檢查所有核心服務(wù)是否正常，健康檢查程序還應(yīng)該在異常情況下輸出每一個(gè)檢查項(xiàng)的狀態(tài)明細(xì)。
• 其他網(wǎng)絡(luò)服務(wù)下可以采用探查容器指定端口狀態(tài)來判斷容器健康狀態(tài)。
• 非網(wǎng)絡(luò)服務(wù)下需要在容器內(nèi)部執(zhí)行特定命令，根據(jù)退出碼判斷容器健康狀態(tài)。

5. Yaml中Image tag配置規(guī)范

部署容器鏡像時(shí)應(yīng)該避免使用latest tag形式，否則一旦出現(xiàn)問題就難以跟蹤到當(dāng)前運(yùn)行的Image版本，也難以進(jìn)行回滾操作。所以建議每個(gè)容器Image的tag應(yīng)該用版本號(hào)來標(biāo)識(shí)。

6. 使用ConfigMap實(shí)現(xiàn)應(yīng)用平滑遷移

早期的1.0版本配置信息都是寫在配置文件中的，要做遷移就需要改很多東西，當(dāng)時(shí)就只有幾種方法可以傳遞配置信息，其中一種是通過環(huán)境變量傳遞，然后內(nèi)部還要有一個(gè)對(duì)應(yīng)機(jī)制進(jìn)行轉(zhuǎn)化，這其實(shí)是非常麻煩的過程。但是現(xiàn)在有了ConfigMap之后，就只需要將原先的配置文件導(dǎo)入到ConfigMap中就行了。

五、遷移中遇到的其他問題

1. 關(guān)于CI/CD

我們?cè)谧鲞w移的時(shí)候采用的是Jenkins來實(shí)現(xiàn)CI/CD的，然后通過Helm來實(shí)現(xiàn)軟件包管理，Helm是Kubernetes的官方子項(xiàng)目，作為企業(yè)內(nèi)部的應(yīng)用管理是非常方便的，它使得開發(fā)者不用再去關(guān)注Kubernetes本身而只需要專注于應(yīng)用開發(fā)就夠了。

2. 時(shí)區(qū)的配置問題

從官方下載的鏡像都會(huì)有默認(rèn)時(shí)區(qū)，一般我們使用的時(shí)候都需要更改時(shí)區(qū)，更改時(shí)區(qū)的方式有多種，這里簡(jiǎn)單說兩種。一是將容器鏡像的/etc/loacltime根據(jù)需要設(shè)置為對(duì)應(yīng)的時(shí)區(qū)，二是采用配置文件中的volume掛載宿主機(jī)對(duì)應(yīng)的localtime文件的方式。推薦采用第二種方式。

3. 外部網(wǎng)絡(luò)訪問Service

在沒有Ingress的時(shí)候我們是使用內(nèi)建Nginx容器來轉(zhuǎn)發(fā)集群內(nèi)部服務(wù)，現(xiàn)在則是通過Ingress轉(zhuǎn)發(fā)集群內(nèi)部服務(wù)，Ingress通過NodePort方式暴露給外網(wǎng)。

***組合

上圖展示的是Kubernetes的***組合，它以DevOps作為基礎(chǔ)，上層是k8s加上Containers，頂層構(gòu)筑的是微服務(wù)應(yīng)用。這樣的組合帶來的不僅是一個(gè)容器云，更多的是改變了研發(fā)流程和組織結(jié)構(gòu)，這主要是受微服務(wù)的架構(gòu)思想影響。

過去完成一個(gè)應(yīng)用的版本發(fā)布可能要多人協(xié)同，一旦有緊急發(fā)布的時(shí)候就會(huì)發(fā)現(xiàn)這其實(shí)是非常笨重的。但是如果是基于微服務(wù)架構(gòu)做的應(yīng)用，往往一到兩個(gè)人就可以維護(hù)一個(gè)微服務(wù)，他們自己就可以決定這個(gè)微服務(wù)是否獨(dú)立部署上線。

關(guān)于微服務(wù)和Kubernetes還有一個(gè)優(yōu)勢(shì)必須要強(qiáng)調(diào)，配合CI/CD開發(fā)人員終于可以不再考慮部署環(huán)境的細(xì)節(jié)了。