摘要：本文整理自時速云線上微信群分享第十二期在本次分享開始前，讓我們先回想下。但目前時速云平臺還不支持這種。問時速云是怎么保持的高可用的答高可用目前是官方推薦的多方式，以及我們自己的監(jiān)管方式。

本文整理自【時速云線上微信群分享】第十二期

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

1. 使用Replication Controller 來部署、升級Pod

2. Replica Set – 下一代Replication Controller

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

假設我們有一個Pod在提供線上服務，現(xiàn)在有如下幾個場景，大家想想如何應對：

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

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

運行Pod的節(jié)點發(fā)生故障

第1種情況， 活動前預先多啟動幾個Pod，活動結(jié)束后再結(jié)束掉多余的，雖然要啟動和結(jié)束的Pod有點多，但也能有條不紊按計劃進行

第2種情況， 正在睡覺突然手機響了說網(wǎng)站反應特慢卡得要死，趕緊爬起來邊擴容邊查找攻擊模式、封IP等等……

第3種情況， 正在休假突然手機又響了說網(wǎng)站上不去，趕緊打開電腦查看原因，啟動
新的Pod

Pod需要手動管理，好累……

能否在Pod發(fā)生問題時自動恢復呢，我們先來看下Replication Controller（以下簡稱RC）

先說RC 是什么。RC保證在同一時間能夠運行指定數(shù)量的Pod副本，保證Pod總是可用。如果實際Pod數(shù)量比指定的多就結(jié)束掉多余的，如果實際數(shù)量比指定的少就啟動缺少的。當Pod失敗、被刪除或被終結(jié)時RC會自動創(chuàng)建新的Pod來保證副本數(shù)量。

所以即使只有一個Pod也應該使用RC來進行管理。

接下來我們看下如何創(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運行（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，這樣默認與spec.template.metadata.labels相同）

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

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

如果使用的鏡像較大查看狀態(tài)可能是Waiting，這是因為正在下載鏡像，等待一段時間就好。

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

1.查看當前Pod，（注意NAME和AGE列）

2.刪除hello-rc-5crgq

3.再次查看Pod，發(fā)現(xiàn)新的Pod啟動了（注意NAME和AGE列）

到這里我們對RC有了基本的認識，并進行了簡單的使用。

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

執(zhí)行結(jié)果看下圖：

當我們有新功能發(fā)布或修復BUG時使用滾動升級是不錯的選擇，可以使用工具kubectl rolling-update完成這個任務。對照下圖我們來看下是如何進行的

使用命令kubectl rolling-update hello-rc –image=index.tenxcloud.com/tailnode/hello:v2.0

在另一個窗口查看RC

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

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

3.當升級成功后，刪除舊RC

4.重命名新RC為hello-rc

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

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

啟動一個能夠輸出Pod主機名和版本號的服務，看下圖當前只有一個Pod副本運行

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

下面再來測試下灰度升級功能，修改目標版本為v2.0（之前是v1.0，為了便于查看效果新建有2個Pod的服務），然后查看Pod變化

第一個新Pod hello-v2.0-ywcc2已經(jīng)啟動

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

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

升級完成，只有兩個新Pod提供服務

同時使用命令查看服務的響應如下：

k8s是一個高速發(fā)展的項目，在新的版本中官方推薦使用Replica Set和Deployment來代替RC。

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

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

Deployment擁有更加靈活強大的升級、回滾功能

Replica Set目前與RC的區(qū)別只是支持的selector不同，后續(xù)肯定會加入更多功能。Deployment使用了Replica Set，是更高一層的概念。除非需要自定義升級功能或根本不需要升級Pod，所以推薦使用Deployment而不直接使用Replica Set。

下面我們繼續(xù)來看Deployment的定義文件，與RC的定義文件基本相同（注意apiVersion還是beta版），所以不再詳細解釋各字段意思

與創(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字段來完成擴容縮容與滾動升級（比kubectl rolling-update速度快很多）

修改image字段為新版本鏡像后查看Pod，在STATUS列看到正在執(zhí)行升級的Pod：

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

上面提到過kubectl rolling-update升級成功后不能直接回滾，不是很方便，那使用Deployment可以嗎，答案是肯定的。

首先在上面的命令加上–revision參數(shù)，查看改動詳細信息如下：

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

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

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

問：灰度發(fā)布， 可以指定新舊版共存么， 怎么整？
答：可以像上面說的那樣，使用命令行工具創(chuàng)建新舊兩個RC，然后分別指定需要的Pod數(shù)量。但目前時速云平臺還不支持這種。

問：時速云是怎么保持k8s master的高可用的？
答：高可用目前是官方推薦的多master standby方式，以及我們自己的agent監(jiān)管方式。

問：Pod 之間通信是不是也是用的flannel？
答：pod和pod之間，可以采用官方推薦的各種網(wǎng)絡解決方案，目前我們主要關(guān)注 flannel(vxlan）和 Calico

問：flannel以及calico，你們選其一還是兩個方案都在用？有測試報告嗎？
答：兩個方案都在用，測試報告以前分享過幾種方案的網(wǎng)絡性能比較，這里有一個Calico的，可以參考：https://www.projectcalico.org/ ... ance/

問：Replica Set 這個有demo的例子么？
答：因為一般Replica Set不會直接使用，而是通過Deployment來控制它，所以本次沒有寫出Replica Set的demo

問：Deployment現(xiàn)在是沒有rest api修改Pod數(shù)量么？
答：有的，PUT /apis/extensions/v1beta1/namespaces/{namespace}/deployments/{name}

問：由于k8s嚴重依賴etcd中的數(shù)據(jù)，一旦etcd的數(shù)據(jù)紊亂，可能造成業(yè)務故障。這個問題在大量業(yè)務接入的時候可能有幾率出現(xiàn)，時速云有解決方案嗎？
答：這個問題，目前還沒有碰到，不過我們會將服務信息同時存放到另外的存儲中，也會對etcd進行備份，這樣在出現(xiàn)故障時也可以很容易恢復或者遷移整個集群。

問：時速云用的是原生k8s嗎，都做了哪些優(yōu)化？
答：優(yōu)化是有一些的，包括部署方式、網(wǎng)絡、存儲、以及一些用戶體驗上的優(yōu)化為主，以便充分發(fā)揮 k8s 的一些優(yōu)勢。

問：Docker 1.12版本開始集成了Swarm到Docker Engine中，Swarm功能也變得越來越強大，那么時速云怎么看這個問題？以后考不考慮用高版本Docker，用k8s管理集成Swarm的Docker，會不會性能浪費？
答：我們目前主要關(guān)注swarm，swarmkit這些docker原生的工具，會去了解他們的主要特性，可以看到swarmkit正在向 k8s 方向邁進。

問：再問個問題，有狀態(tài)服務的pod，掛載個數(shù)據(jù)卷（比如rbd）。用rc或者deployment管理的pod重啟或者升級以后，數(shù)據(jù)卷重新掛載到新的pod上會有什么問題么？
答：沒有遇到過問題，理論上也不應該會有問題的。

問：能不能介紹一下怎么做用戶隔離的，公有云的話，安全對大家很重要
答：可以參考 Calico 的網(wǎng)絡隔離和 k8s 的服務、api訪問控制，以及一些用戶角色上的設計，k8s在安全上還是考慮了不少東西的。

問：容器飄移和虛擬機飄移一樣嗎？
答：還是不太一樣的，虛擬機可以支持熱遷移，目前容器還不行。

如何參與線上分享？

添加微信號：時速云小助手(tenxcloud6)，我們即可拉您進群