前言
一直以來霞掺，知道K8S具有滾動更新的策略，能支持我們發(fā)布的應(yīng)用實(shí)時(shí)切換上線其做，不用停機(jī)發(fā)布，這個(gè)本身也是趨勢赁还，但是沒有好好的了解過K8S是怎么去實(shí)現(xiàn)的妖泄，今天正好有人問了我這個(gè)問題，所以趁著有時(shí)間了解了一下秽浇。
常用的部署方式
在了解Rolling Update之前浮庐，先說下我們的部署方式甚负，在通常情況下柬焕，我們不會直接創(chuàng)建一個(gè)Pod或者一個(gè)Replica Set，而是通過Deployment去發(fā)布一個(gè)應(yīng)用梭域，雖然Deployment跟RS的主要職責(zé)是一樣的斑举，都是保證Pod的數(shù)量和監(jiān)控，二者大部分功能都是完全一致的病涨，可以把Deployment看成是一個(gè)升級版的RS富玷，官方也推薦使用Deployment來管理Pod。具體的區(qū)別如下既穆。
- Replication Controller全部功能：Deployment繼承了上面描述的Replication Controller全部功能赎懦。
- 事件和狀態(tài)查看：可以查看Deployment的升級詳細(xì)進(jìn)度和狀態(tài)。
- 回滾：當(dāng)升級pod鏡像或者相關(guān)參數(shù)的時(shí)候發(fā)現(xiàn)問題幻工，可以使用回滾操作回滾到上一個(gè)穩(wěn)定的版本或者指定的版本励两。
- 版本記錄: 每一次對Deployment的操作，都能保存下來囊颅，給予后續(xù)可能的回滾使用当悔。
- 暫停和啟動：對于每一次升級，都能夠隨時(shí)暫停和啟動踢代。
- 多種升級方案：Recreate：刪除所有已存在的pod,重新創(chuàng)建新的; RollingUpdate：滾動升級盲憎，逐步替換的策略，同時(shí)滾動升級時(shí)胳挎，支持更多的附加參數(shù)饼疙，例如設(shè)置最大不可用pod數(shù)量，最小升級間隔時(shí)間等等慕爬。
Rolling Update
本身Rolling Update是支持RS和Deployment宏多，這里以Deployment Rolling Update為例儿惫，當(dāng)我們更新了Deployment中的應(yīng)用鏡像號后，滾動更新是如何工作的呢伸但？我們可以嘗試用命令 $ kubectl get rs -w -n namespace |grep Replica Set Name 來監(jiān)控整個(gè)過程肾请，如下圖：
可以看到執(zhí)行新的部署后，Deployment會創(chuàng)建一個(gè)新的RS（每個(gè)RS具有一個(gè)hash Id ）更胖，上圖中的New RS是：7bbc459bdb 铛铁，Old RS是：777458cb8d。從監(jiān)控過程中看到却妨，一開始創(chuàng)建的時(shí)候New RS的Pod副本數(shù)是0 饵逐，當(dāng)RS創(chuàng)建完畢后，會更新成Pod數(shù)量為1彪标，當(dāng)創(chuàng)建的pod ready后倍权，在更新Old
RS的Pod副本數(shù)量量為1，隨后更新New RS Pod副本數(shù)量為2捞烟，最后在更新Old RS pod數(shù)量為0薄声。 這樣就實(shí)現(xiàn)了Rolling Update策略（rolling update 可以設(shè)置滾動升級百分比）。
那么题画，每個(gè)Replica Set 是怎么知道哪些Pod是由自己去控制的呢默辨？
這個(gè)就要說到強(qiáng)大的標(biāo)簽管理了，在創(chuàng)建Pod時(shí)苍息，有一個(gè)pod-template-hash缩幸，通過當(dāng)前RS創(chuàng)建的Pod，這個(gè)hash值是一樣的竞思，這樣就可以分辨新舊版本的Pod表谊，不會出無法分辨的情況了。至此盖喷，相信大家已經(jīng)搞明白Rolling Update是如何工作了爆办。
PS：另外在K8S中 RS的會默認(rèn)保存10個(gè)歷史記錄加上一個(gè)當(dāng)前的RS，總共11個(gè)RS記錄（可以調(diào)整）方便我們?nèi)プ龌貪L传蹈。例如押逼，order service的RS的數(shù)量如下。
