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

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

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

使用Replication Controller 來(lái)部署、升級(jí)Pod

Replica Set – 下一代Replication Controller

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

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

節(jié)日活動(dòng)，網(wǎng)站訪(fǎng)問(wèn)量突增

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

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

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

Pod需要手動(dòng)管理，好累……
能否在Pod發(fā)生問(wèn)題時(shí)自動(dòng)恢復(fù)呢，我們先來(lái)看下Replication Controller（以下簡(jiǎn)稱(chēng)RC）

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

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

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

這個(gè)文件的意思是定義了一個(gè)RC對(duì)象，它的名字是hello-rc（metadata.name:hello-rc），保證有3個(gè)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，這兩個(gè)字段必須相同，否則下一步創(chuàng)建RC會(huì)失敗。（也可以不寫(xiě)spec.selector，這樣默認(rèn)與spec.template.metadata.labels相同）

現(xiàn)在通過(guò)kubectl來(lái)創(chuàng)建RC：

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

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

上面說(shuō)過(guò)RC會(huì)自動(dòng)管理Pod保證指定數(shù)量副本運(yùn)行，我們來(lái)實(shí)驗(yàn)一下，看下圖：

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

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

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

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

在另一個(gè)窗口查看RC

對(duì)照兩張截圖，我們能夠看出升級(jí)步驟如下：

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

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

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

重命名新RC為hello-rc

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

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

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

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

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

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

第二個(gè)新Pod hello-v2.0-whtvh正在啟動(dòng)

最后一個(gè)舊Pod hello-41ee8正在停止

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

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

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

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

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

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

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

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

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

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

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

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

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

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