摘要：是運(yùn)行服務(wù)的基礎(chǔ)，那我們?nèi)绾蝸砉芾砟?，下面我們就來聊一聊。所以即使只有一個也應(yīng)該使用來進(jìn)行管理?，F(xiàn)在回到最開始的問題，如何通過修改副本數(shù)量。

這是在微信群分享的文章，也貼在這里。

在本次分享開始前，讓我們先回想下Pod。Pod直譯是豆莢，可以把容器想像成豆莢里的豆子，把一個或多個關(guān)系緊密的豆子包在一起就是豆莢（一個Pod）。在k8s中我們不會直接操作容器，而是把容器包裝成Pod再進(jìn)行管理（關(guān)于Pod，大家可以參考第十期的分享“談?wù)凱od在微服務(wù)中的運(yùn)用”）。Pod是運(yùn)行服務(wù)的基礎(chǔ)，那我們?nèi)绾蝸砉芾鞵od呢，下面我們就來聊一聊。分為這三個部分：

使用Replication Controller 來部署、升級Pod

Replica Set – 下一代Replication Controller

Deployment – 更加方便的管理Pod和Replica Set

先舉個例子,假設(shè)我們有一個Pod在提供線上服務(wù)，現(xiàn)在有如下幾個場景，大家想想如何應(yīng)對：

節(jié)日活動，網(wǎng)站訪問量突增

遭到攻擊，網(wǎng)站訪問量突增

運(yùn)行Pod的節(jié)點(diǎn)發(fā)生故障

第1種情況，活動前預(yù)先多啟動幾個Pod，活動結(jié)束后再結(jié)束掉多余的，雖然要啟動和結(jié)束的Pod有點(diǎn)多，但也能有條不紊按計(jì)劃進(jìn)行
第2種情況，正在睡覺突然手機(jī)響了說網(wǎng)站反應(yīng)特慢卡得要死，趕緊爬起來邊擴(kuò)容邊查找攻擊模式、封IP等等……
第3種情況，正在休假突然手機(jī)又響了說網(wǎng)站上不去，趕緊打開電腦查看原因，啟動新的Pod

Pod需要手動管理，好累……
能否在Pod發(fā)生問題時自動恢復(fù)呢，我們先來看下Replication Controller（以下簡稱RC）

先說RC是什么。RC保證在同一時間能夠運(yùn)行指定數(shù)量的Pod副本，保證Pod總是可用。如果實(shí)際Pod數(shù)量比指定的多就結(jié)束掉多余的，如果實(shí)際數(shù)量比指定的少就啟動缺少的。當(dāng)Pod失敗、被刪除或被終結(jié)時RC會自動創(chuàng)建新的Pod來保證副本數(shù)量。所以即使只有一個Pod也應(yīng)該使用RC來進(jìn)行管理。

接下來我們看下如何創(chuàng)建RC，看這個定義文件rc.yaml

這個文件定義了RC的屬性，我們先關(guān)注如下字段：
spec.replicas：副本數(shù)量3
spec.selector：RC通過spec.selector來篩選要控制的Pod
spec.template：這里寫Pod的定義（但不需要apiVersion和kind）
spec.template.metadata.labels：Pod的label，可以看到這個label與spec.selector相同

這個文件的意思是定義了一個RC對象，它的名字是hello-rc（metadata.name:hello-rc），保證有3個Pod運(yùn)行（spec.replicas:3），Pod的鏡像是index.tenxcloud.com/tailnode/hello:v1.0（spec.template.spec.containers.image: index.tenxcloud.com/tailnode/hello:v1.0）
關(guān)鍵在于spec.selector與spec.template.metadata.labels，這兩個字段必須相同，否則下一步創(chuàng)建RC會失敗。（也可以不寫spec.selector，這樣默認(rèn)與spec.template.metadata.labels相同）

現(xiàn)在通過kubectl來創(chuàng)建RC：

查看結(jié)果可以看到當(dāng)前RC的狀態(tài)：指定了需要3個Pod、當(dāng)前實(shí)際有3個Pod、3個Pod都在運(yùn)行中（圖片較大只截取部分）：

如果使用的鏡像較大查看狀態(tài)可能是Waiting，這是因?yàn)檎谙螺d鏡像，等待一段時間就好。

上面說過RC會自動管理Pod保證指定數(shù)量副本運(yùn)行，我們來實(shí)驗(yàn)一下，看下圖：

1.查看當(dāng)前Pod，（注意NAME和AGE列）
2.刪除hello-rc-5crgq
3.再次查看Pod，發(fā)現(xiàn)新的Pod啟動了（注意NAME和AGE列）

到這里我們對RC有了基本的認(rèn)識，并進(jìn)行了簡單的使用。

現(xiàn)在回到最開始的問題，如何通過RC修改Pod副本數(shù)量。其實(shí)非常簡單，只需要修改yaml文件spec.replicas字段成想要的值，然后執(zhí)行kubectl replace命令（或者使用kubect edit replicationcontroller hello-rc直接修改）
執(zhí)行結(jié)果看下圖：

當(dāng)我們有新功能發(fā)布或修復(fù)BUG時使用滾動升級是不錯的選擇，可以使用工具kubectl rolling-update完成這個任務(wù)。對照下圖我們來看下是如何進(jìn)行的
使用命令kubectl rolling-update hello-rc –image=index.tenxcloud.com/tailnode/hello:v2.0

在另一個窗口查看RC

對照兩張截圖，我們能夠看出升級步驟如下：

創(chuàng)建一個使用新版本Pod的RC，hello-rc-4f7ed44b6db1e20aa1bc681c81d63caf

依次增加新RC的副本數(shù)量、減少舊RC的副本數(shù)量

當(dāng)升級成功后，刪除舊RC

重命名新RC為hello-rc

當(dāng)Pod中只有一個容器時通過--image參數(shù)指定新的Tag，如果有多個容器或其他字段的修改時，需要使用kubectl rolling-update NAME -f FILE指定文件

如果在升級過程中出現(xiàn)問題（比如長時間無響應(yīng)），可以CTRL+C結(jié)束再使用kubectl rolling-update hello-rc –-rollback進(jìn)行回滾，但如果升級完成后出現(xiàn)問題（比如新版本程序出core），此命令無能為力，需要使用同樣方法“升級”為舊版本

在時速云平臺我們能夠非常方便的使用彈性伸縮功能來調(diào)整Pod副本數(shù)量，還是舉例說明：

啟動一個能夠輸出Pod主機(jī)名和版本號的服務(wù)，看下圖當(dāng)前只有一個Pod副本運(yùn)行

點(diǎn)擊彈性伸縮，修改數(shù)量為3，同時使用下面的命令測試，從輸出結(jié)果可以看出提供服務(wù)的Pod數(shù)量變成了3個：

下面再來測試下灰度升級功能，修改目標(biāo)版本為v2.0（之前是v1.0，為了便于查看效果新建有2個Pod的服務(wù)），然后查看Pod變化
第一個新Pod hello-v2.0-ywcc2已經(jīng)啟動

第二個新Pod hello-v2.0-whtvh正在啟動

最后一個舊Pod hello-41ee8正在停止

升級完成，只有兩個新Pod提供服務(wù)

同時使用命令查看服務(wù)的響應(yīng)如下：

k8s是一個高速發(fā)展的項(xiàng)目，在新的版本中官方推薦使用Replica Set和Deployment來代替RC。
那么它們優(yōu)勢在哪里，我們來看一看：

RC只支持基于等式的selector（env=dev或environment!=qa）但Replica Set還支持新的基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），這對復(fù)雜的運(yùn)維管理帶來很大方便

使用Deployment升級Pod只需要定義Pod的最終狀態(tài)，k8s會為你執(zhí)行必要的操作，雖然能夠使用命令kubectl rolling-update完成升級，但它是在客戶端與服務(wù)端多次交互控制RC完成的，所以REST API中并沒有rolling-update的接口，這為定制自己的管理系統(tǒng)帶來了一些麻煩。

Deployment擁有更加靈活強(qiáng)大的升級、回滾功能

Replica Set目前與RC的區(qū)別只是支持的selector不同，后續(xù)肯定會加入更多功能。Deployment使用了Replica Set，是更高一層的概念。除非需要自定義升級功能或根本不需要升級Pod，所以推薦使用Deployment而不直接使用Replica Set。
下面我們繼續(xù)來看Deployment的定義文件，與RC的定義文件基本相同（注意apiVersion還是beta版），所以不再詳細(xì)解釋各字段意思

與創(chuàng)建RC相同，使用命令kubectl create -f deployment.yaml –record創(chuàng)建Deployment，注意–record參數(shù)，使用此參數(shù)將記錄后續(xù)對創(chuàng)建的對象的操作，方便管理與問題追溯

使用kubectl edit deployment hello-deployment修改spec.replicas/spec.template.spec.container.image字段來完成擴(kuò)容縮容與滾動升級（比kubectl rolling-update速度快很多）
修改image字段為新版本鏡像后查看Pod，在STATUS列看到正在執(zhí)行升級的Pod：

使用kubectl rollout history命令查看Deployment的歷史信息

上面提到過kubectl rolling-update升級成功后不能直接回滾，不是很方便，那使用Deployment可以嗎，答案是肯定的。
首先在上面的命令加上–revision參數(shù)，查看改動詳細(xì)信息如下：

然后使用kubctl rollout undo deployment hello-deployment回滾至前一版本（使用--to-revision參數(shù)指定版本）即可。

命令kubectl describe deployment hello-deployment查看詳細(xì)信息，在Message一列看到回滾如下，詳細(xì)的信息記錄對于問題發(fā)生后的原因查找有很大幫助：

通過對比RC、Replica Set與Deployment，可以看出新的Replica Set與Deployment比RC要強(qiáng)大易用很多，但因?yàn)楝F(xiàn)在還是beta版本所以不建議在生產(chǎn)環(huán)境使用，不過相信不久的將來我們就能使用上。