當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

当SRS遇到K8s：如何实现高可用、回滚与灰度发布？

發(fā)布時(shí)間：2024/4/11 编程问答 84 豆豆

生活随笔收集整理的這篇文章主要介紹了当SRS遇到K8s：如何实现高可用、回滚与灰度发布？小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

Photo by?Luis Quintero?from?Pexels

本文來自流媒體直播集群SRS的官方wiki（https://github.com/ossrs/srs/wiki/v4_CN_K8s），由SRS的創(chuàng)始作者楊成立授權(quán)發(fā)布。

文 / 楊成立

相關(guān)文章：

當(dāng)SRS遇到K8s：快速構(gòu)建高并發(fā)直播集群

當(dāng)SRS遇到K8s：如何構(gòu)建海量推流源站？

服務(wù)的更新、回滾和灰度，是個(gè)簡(jiǎn)單的問題，如果加上一個(gè)條件"不中斷服務(wù)的前提下"，那么就是一個(gè)難題，如果再加上"大規(guī)模"，那么就是K8S要解決的核心問題之一。壞消息是這個(gè)難搞的問題還真是流媒體服務(wù)的核心的、關(guān)鍵的、不可忽視的關(guān)鍵能力之一，好消息是K8S和云計(jì)算讓這個(gè)難題稍微好一點(diǎn)點(diǎn)了。

我們?cè)谑裁磮?chǎng)景下會(huì)遇到更新、回滾和灰度的問題：

SRS需要升級(jí)新版本，如何知道升級(jí)后對(duì)現(xiàn)有業(yè)務(wù)沒有影響？如果選擇業(yè)務(wù)量小升級(jí)，那一般常態(tài)會(huì)是半夜三更、凌晨三四點(diǎn)，還要不要頭發(fā)了呢？
改進(jìn)了新的功能或優(yōu)化，根據(jù)業(yè)務(wù)定制了新的東西（完全直接使用SRS也得有自己的業(yè)務(wù)服務(wù)器），如何只在一部分機(jī)器發(fā)布，看看效果有沒有達(dá)到預(yù)期？
更新新版本后，如果發(fā)現(xiàn)有問題，影響了用戶服務(wù)，如何在最短時(shí)間內(nèi)回滾到之前的版本？問題出現(xiàn)時(shí)首先是要確認(rèn)問題后(若由升級(jí)引起則)回滾，而不是很費(fèi)時(shí)間的找Bug。

在這個(gè)場(chǎng)景下，對(duì)比K8S和傳統(tǒng)部署方式的差異：

對(duì)比項(xiàng)	ECS	K8S	說明
部署	安裝包	鏡像	Docker鏡像可回滾，開發(fā)和生產(chǎn)環(huán)境一致，可Cache，高效率和高密度，高可移植性，資源隔離可預(yù)測(cè)程序性能
看門狗	手動(dòng)	自動(dòng)	SRS異常退出由看門狗重新拉起，非K8S需要手動(dòng)安裝，K8S自動(dòng)管理和拉起服務(wù)
更新	手動(dòng)	自動(dòng)	傳統(tǒng)方式用腳本下載和更新二進(jìn)制，人工分批更新，K8S自動(dòng)Rolling Update，自動(dòng)下載鏡像和分批更新
灰度	手動(dòng)	自動(dòng)	傳統(tǒng)方式手動(dòng)操作SLB決定切量比例，K8S通過Replicas控制比例，自動(dòng)切量
回滾	手動(dòng)	自動(dòng)	傳統(tǒng)方式手動(dòng)回滾，K8S有版本管理和回滾機(jī)制

Note:平滑更新的關(guān)鍵是平滑退出，重點(diǎn)是邊緣集群的更新，對(duì)于源站集群我們可以選擇直接重啟，因?yàn)橐话銜?huì)有邊緣集群作為代理，源站斷開后邊緣會(huì)重試，不影響用戶，參考#1579（https://github.com/ossrs/srs/issues/1579#issuecomment-587233844）。

我們重點(diǎn)關(guān)注邊緣集群的平滑退出，SRS邊緣屬于長(zhǎng)連接無狀態(tài)服務(wù)。和Nginx一樣，SRS使用SIGQUIT作為信號(hào)，同時(shí)配置force_grace_quit認(rèn)為SIGTERM也是平滑退出，收到SIGQUIT信號(hào)后，會(huì)等待grace_start_wait指定的時(shí)間，然后關(guān)閉Listeners新的連接不會(huì)分配到這個(gè)服務(wù)器，然后開始清理并等待現(xiàn)有連接退出，所有連接退出后還會(huì)等待grace_final_wait指定的時(shí)間，才會(huì)退出。

以之前部署的SRS源站和邊緣集群為例，參考SRS Origin Cluster for a Large Number of Streams，SRS邊緣的Pod的配置，需要指定平滑退出的參數(shù)，例如：

cat <<EOF | kubectl apply -f -

apiVersion: v1

kind: ConfigMap

metadata:

?name: srs-edge-config

data:

?srs.conf: |-

???listen????????????? 1935;

???max_connections???? 1000;

???daemon????????????? off;

???grace_start_wait??? 700;

???grace_final_wait??? 800;

???force_grace_quit??? on;

???http_api {

???????enabled???????? on;

???????listen????????? 1985;

??? }

???http_server {

???????enabled???????? on;

???????listen????????? 8080;

??? }

???vhost __defaultVhost__ {

???????cluster {

???????????mode??????????? remote;

???????????origin????????? srs-origin-0.socssrs-origin-1.socs srs-origin2.socs;

???????}

???????http_remux {

???????????enabled???? on;

???????}

??? }

EOF

Remark:一定要開啟force_grace_quit，不開啟(默認(rèn))將使用暴力更新，直接斷開現(xiàn)有的連接，參考#1579（https://github.com/ossrs/srs/issues/1579#issuecomment-587233844）。

Note:在K8S中開始刪除Pod時(shí)，會(huì)快速從Service刪除Pod，所以我們將grace_start_wait和grace_final_wait設(shè)置時(shí)間短一些，只需要幾百毫秒就足夠了。

SRS邊緣的配置，也需要在lifecycle.preStop事件時(shí)啟動(dòng)平滑退出，并設(shè)置terminationGracePeriodSeconds等待時(shí)間，例如：

cat <<EOF | kubectl apply --record -f -

apiVersion: apps/v1

kind: Deployment

metadata:

?name: srs-edge-deploy

?labels:

???app: srs-edge

spec:

?replicas: 2

?revisionHistoryLimit: 10

?selector:

???matchLabels:

?????app: srs-edge

?template:

???metadata:

?????labels:

???????app: srs-edge

???spec:

?????volumes:

?????- name: config-volume

???????configMap:

?????????name: srs-edge-config

?????containers:

?????- name: srs

???????image: ossrs/srs:v4.0.5

???????imagePullPolicy: IfNotPresent

???????ports:

???????- containerPort: 1935

???????- containerPort: 1985

???????- containerPort: 8080

???????volumeMounts:

???????- name: config-volume

?????????mountPath: /usr/local/srs/conf

???????lifecycle:

?????????preStop:

???????????exec:

????????????? command:["/usr/local/srs/etc/init.d/srs", "grace"]

?????terminationGracePeriodSeconds: 120

EOF

Note:?kubectl apply增加了一個(gè)參數(shù)--record，后面回滾會(huì)用到。

Note:?terminationGracePeriodSeconds等待退出時(shí)間我們?cè)O(shè)置2分鐘，線上服務(wù)可以設(shè)置更長(zhǎng)，比如12小時(shí)。

Remark:為了更好體現(xiàn)平滑更新的邏輯，我們?cè)O(shè)置Replicas=2可以更容易演示。

Remark:我們使用SRS4演示，例如v4.0.5，實(shí)際上SRS3也可以的比如v3.0-b1等。

我們停掉了之前srs-demo-deploy推的兩個(gè)DEMO流，采用手動(dòng)推流到Edge，方便演示升級(jí)時(shí)有長(zhǎng)連接需要服務(wù)的情況：

ffmpeg -re -i ./doc/source.200kbps.768x320.flv-c copy \

??? -fflv rtmp://28.170.32.118/live/livestream

Note:請(qǐng)將上面的EIP換成你自己的，可用命令kubectlget svc/srs-edge-service查看你的EIP。

咱們可以看到目前啟動(dòng)了2個(gè)Edge，可以看下它的版本，是通過Pod(z9gbm)推流：

kubectl get po|grep edge

srs-edge-deploy-58d9999b7c-pnr2f?????? 1/1????Running?? 0????????? 16s

srs-edge-deploy-58d9999b7c-z9gbm?????? 1/1????Running?? 0????????? 16s

kubectl exec srs-edge-deploy-58d9999b7c-pnr2f-- ./objs/srs -v

4.0.5

kubectl exec srs-edge-deploy-58d9999b7c-pnr2f-- yum install -y net-tools

kubectl exec srs-edge-deploy-58d9999b7c-pnr2f-- netstat -anp|grep 1935

tcp???????0????? 0 0.0.0.0:1935??????????? 0.0.0.0:*?????????????? LISTEN????? 1/./objs/srs

kubectl exec srs-edge-deploy-58d9999b7c-z9gbm-- ./objs/srs -v

4.0.5

kubectl exec srs-edge-deploy-58d9999b7c-z9gbm-- yum install -y net-tools

kubectl exec srs-edge-deploy-58d9999b7c-z9gbm-- netstat -anp|grep 1935

tcp???????0????? 0 0.0.0.0:1935??????????? 0.0.0.0:*?????????????? LISTEN????? 1/./objs/srs

tcp???????0????? 0 172.20.0.62:46482?????? 172.20.0.41:1935??????? ESTABLISHED 1/./objs/srs

tcp???????0????? 0 172.20.0.62:1935??????? 172.20.0.1:12066??????? ESTABLISHED 1/./objs/srs

Note:我們只推流一個(gè)流，會(huì)有兩個(gè)連接，一個(gè)是客戶端到Edge的連接，一個(gè)是Edge回源到Origin的連接。

下面我們會(huì)分幾個(gè)部分，看發(fā)布中遇到的問題：

SRS Cluster Rolling Update: 在平滑退出基礎(chǔ)上的滾動(dòng)更新，集群更新的基礎(chǔ)機(jī)制。

SRS Cluster Rolling Back: 在平滑退出基礎(chǔ)上的發(fā)布回滾，發(fā)布遇到問題首先考慮回滾。

SRS Cluster Canary Release: 金絲雀升級(jí)，可精確控制的流量控制和回滾。

SRS Cluster Rolling Update

K8S的更新是Rolling Update，也就是修改和更新Pods時(shí)，會(huì)分批次執(zhí)行。比如，上面的例子中SRS邊緣的版本是v4.0.5，若我們現(xiàn)在需要更新到4.0.6，鏡像已經(jīng)打好了ossrs/srs:v4.0.6，那么我們可以用命令更新：

kubectl set image deploy/srs-edge-deploy srs=ossrs/srs:v4.0.6 --record

可以看這兩個(gè)Pod的日志，沒有連接的Pod很快就退出了，而有連接的Pod經(jīng)過了一定的時(shí)間才退出(若客戶端連接主動(dòng)斷開會(huì)更快退出)：

kubectl exec srs-edge-deploy-58d9999b7c-pnr2f -- tail -f objs/srs.log

[2020-02-19 11:07:20.818][Trace][1][937]sig=3, user start gracefully quit

[2020-02-19 11:07:20.960][Trace][1][937]force gracefully quit, signo=15

[2020-02-19 11:07:21.772][Trace][1][932]cleanup for quitsignal fast=0, grace=1

[2020-02-19 11:07:21.772][Warn][1][932][11]main cycle terminated, system quit normally.

commandterminated with exit code137

kubectl exec srs-edge-deploy-58d9999b7c-z9gbm -- tail -f objs/srs.log

[2020-02-19 11:07:23.095][Trace][1][1009]sig=3, user start gracefully quit

[2020-02-19 11:07:23.316][Trace][1][1009]force gracefully quit, signo=15

[2020-02-19 11:07:23.784][Trace][1][1004]cleanup for quitsignal fast=0, grace=1

[2020-02-1911:07:23.784][Warn][1][1004][11] main cycle terminated, system quit normally.

[2020-02-19 11:07:24.784][Trace][1][1004] waitfor 1 conns to quit

[2020-02-19 11:07:26.968][Trace][1][1010] <- CPB time=120041497, okbps=0,0,0,ikbps=252,277,0, mr=0/350, p1stpt=20000, pnt=5000

[2020-02-19 11:08:26.791][Trace][1][1004] waitfor 1 conns to quit

[2020-02-19 11:08:52.602][Trace][1][1010]edge change from 200 to state 0 (init).

[2020-02-19 11:08:52.792][Trace][1][1004] waitfor 0 conns to quit

commandterminated with exit code137

kubectl get po |grep edge

NAME?????????????????????????????????? READY?? STATUS???????RESTARTS?? AGE

srs-edge-deploy-58d9999b7c-z9gbm?????? 0/1????Terminating?? 0????????? 3m52s

srs-edge-deploy-76fcbfb848-z5rmn?????? 1/1????Running?????? 0????????? 104s

srs-edge-deploy-76fcbfb848-zt4wv?????? 1/1????Running?????? 0????????? 106s

Remark:注意我們現(xiàn)在是有一個(gè)Pod有客戶端在推流的。同樣，我們指定了參數(shù)--record，會(huì)在后面回滾時(shí)用得著。

若RollingUpdate期間，我們需要暫停更新，可以用kubectl rollout暫停和恢復(fù)：

kubectl rollout pausedeploy/srs-edge-deploy

kubectl rollout resumedeploy/srs-edge-deploy

SRS Cluster Rolling Back

每次發(fā)布K8S都會(huì)記錄一個(gè)Revision，若我們傳遞了--record參數(shù)(正如前面我們做的)，則會(huì)記錄更詳細(xì)的CHANGE-CAUSE，比如：

kubectl rollout history deploy/srs-edge-deploy

REVISION?CHANGE-CAUSE

1????????kubectl apply --record=true --filename=-

2 ?????? kubectl set imagedeploy/srs-edge-deploy srs=ossrs/srs:v4.0.6 --record=true

Note:默認(rèn)ACK只保留10個(gè)Revision，可以通過設(shè)置revisionHistoryLimit增加可回滾的版本。

若出現(xiàn)異常，可以回滾到之前的版本，例如：

kubectl rollout undo deploy/srs-edge-deploy--to-revision=1

實(shí)際上回滾的過程也是Rolling Update的過程，只是不用指定修改什么配置，而是指定的哪個(gè)歷史版本的配置。回滾后，新增了一個(gè)版本3，和1是一樣的：

REVISION?CHANGE-CAUSE

1????????kubectl apply --record=true --filename=-

2 ?????? kubectl set image deploy/srs-edge-deploy srs=ossrs/srs:v4.0.6--record=true

3????????kubectl apply --record=true --filename=-

Note:可以在阿里云控制臺(tái)來選擇回滾到哪個(gè)版本。

SRS Cluster Canary Release

Canary是金絲雀發(fā)布，指試探性的發(fā)布一些版本，沒有問題就繼續(xù)擴(kuò)大比例。由于涉及到具體的發(fā)布比例，所以我們要在RollingUpdate基礎(chǔ)上，能控制新老Pods的數(shù)目，這就需要使用SLB了，參考Kubernetes集群中使用阿里云 SLB 實(shí)現(xiàn)四層金絲雀發(fā)布。

Note:關(guān)于金絲雀發(fā)布，最初發(fā)布的版本就好比金絲雀，在以前煤礦中會(huì)把金絲雀先送下去，如果缺氧雀兒就掛了。

以上面的Edge集群為例，假設(shè)目前版本是v4.0.5，有三個(gè)Edge Pod在運(yùn)行，通過SLB對(duì)外提供服務(wù)：

cat <<EOF | kubectl apply --record -f -

apiVersion: apps/v1

kind: Deployment

metadata:

?name: srs-edge-r5-deploy

?labels:

???run: srs-edge-r5

spec:

?replicas: 3

?selector:

???matchLabels:

?????run: srs-edge-r5

?template:

???metadata:

?????labels:

???????run: srs-edge-r5

???????app: srs-edge

???spec:

?????volumes:

?????- name: config-volume

???????configMap:

?????????name: srs-edge-config

?????containers:

?????- name: srs

???????image: ossrs/srs:v4.0.5

???????imagePullPolicy: IfNotPresent

???????ports:

???????- containerPort: 1935

???????- containerPort: 1985

???????- containerPort: 8080

???????volumeMounts:

???????- name: config-volume

?????????mountPath: /usr/local/srs/conf

???????lifecycle:

?????????preStop:

???????????exec:

????????????? command:["/usr/local/srs/etc/init.d/srs", "grace"]

?????terminationGracePeriodSeconds: 120

EOF

Remark:注意Pod的labels有兩個(gè)，一個(gè)是run:srs-edge-r5是這個(gè)應(yīng)用所使用的，另外一個(gè)是app: srs-edge是Service用的，新老的SRS都有這個(gè)標(biāo)簽這樣Service就可以都轉(zhuǎn)發(fā)了。

執(zhí)行命令后，可以看到三個(gè)Pod在運(yùn)行：

kubectl get po

NAME?????????????????????????????????? READY?? STATUS???RESTARTS?? AGE

srs-edge-r5-deploy-6c84cdc77b-q2j97??? 1/1????Running?? 0????????? 3m15s

srs-edge-r5-deploy-6c84cdc77b-s6pzh??? 1/1????Running?? 0????????? 3m15s

srs-edge-r5-deploy-6c84cdc77b-wjdtl??? 1/1????Running?? 0????????? 3m15s

如果我們要升級(jí)到v4.0.6，但是只想先升級(jí)一臺(tái)，這臺(tái)就是金絲雀了。我們可以創(chuàng)建另外一個(gè)Deployment，他們的name不一樣，但使用同樣的Service：

cat <<EOF | kubectl apply --record -f -

apiVersion: apps/v1

kind: Deployment

metadata:

?name: srs-edge-r6-deploy

?labels:

???run: srs-edge-r6

spec:

?replicas: 1

?selector:

???matchLabels:

?????run: srs-edge-r6

?template:

???metadata:

?????labels:

???????run: srs-edge-r6

???????app: srs-edge

???spec:

?????volumes:

?????- name: config-volume

???????configMap:

?????????name: srs-edge-config

?????containers:

?????- name: srs

???????image: ossrs/srs:v4.0.6

???????imagePullPolicy: IfNotPresent

???????ports:

???????- containerPort: 1935

???????- containerPort: 1985

???????- containerPort: 8080

???????volumeMounts:

???????- name: config-volume

?????????mountPath: /usr/local/srs/conf

???????lifecycle:

?????????preStop:

???????????exec:

????????????? command:["/usr/local/srs/etc/init.d/srs", "grace"]

?????terminationGracePeriodSeconds: 120

EOF

Remark:注意Pod的labels有兩個(gè)，一個(gè)是run:srs-edge-r6是這個(gè)應(yīng)用所使用的，另外一個(gè)是app: srs-edge是Service用的，和之前的老版本是一樣的，這樣Service就可以都轉(zhuǎn)發(fā)了。

執(zhí)行命令后，可以看到四個(gè)Pod在運(yùn)行，三個(gè)老的，一個(gè)新的，這樣就灰度了25%的流量到了新版本：

kubectl get po

NAME?????????????????????????????????? READY?? STATUS???RESTARTS?? AGE

srs-edge-r5-deploy-6c84cdc77b-q2j97??? 1/1????Running?? 0????????? 3m30s

srs-edge-r5-deploy-6c84cdc77b-s6pzh??? 1/1????Running?? 0????????? 3m30s

srs-edge-r5-deploy-6c84cdc77b-wjdtl??? 1/1????Running?? 0????????? 3m30s

srs-edge-r6-deploy-598f4698d-kkfnb???? 1/1????Running?? 0????????? 6s

whiletrue;do ffmpeg -f flv -irtmp://r.ossrs.net/live/livestream 2>&1|grep server_version; sleep 1;done

???server_version? : 4.0.5

???server_version? : 4.0.6 # 這是新版本

???server_version? : 4.0.5

???server_version? : 4.0.6 # 這是新版本

那么接下來，只需要調(diào)整新老的Deployment的Replicas，就能調(diào)整流量的比例了，比如我們?cè)黾有掳姹颈戎?#xff0c;只留一臺(tái)老的：

kubectl scale --replicas=3deploy/srs-edge-r6-deploy

kubectl scale --replicas=1deploy/srs-edge-r5-deploy

可以看到經(jīng)過Gracefully Quit平滑升級(jí)和退出，最終變成了我們聲明的那個(gè)樣子，對(duì)業(yè)務(wù)不影響：

kubectl get po

NAME?????????????????????????????????? READY?? STATUS???RESTARTS?? AGE

nginx-origin-deploy-85f4695685-gn2df?? 3/3????Running?? 0????????? 5h31m

srs-edge-r5-deploy-6c84cdc77b-s6pzh??? 1/1????Running?? 0????????? 25m

srs-edge-r6-deploy-f6b59c6c6-ddgxw???? 1/1????Running?? 0????????? 2m59s

srs-edge-r6-deploy-f6b59c6c6-gvnd8???? 1/1????Running?? 0????????? 2m54s

srs-edge-r6-deploy-f6b59c6c6-j46b5???? 1/1????Running?? 0????????? 2m58s

whiletrue;do ffmpeg -f flv -irtmp://r.ossrs.net/live/livestream 2>&1|grep server_version; sleep 1;done

?? ?server_version?: 4.0.6

???server_version? : 4.0.6

???server_version? : 4.0.5 # 這是老版本

???server_version? : 4.0.6

???server_version? : 4.0.5 # 這是老版本

???server_version? : 4.0.6

最終我們只要把老的Replicas設(shè)為0，然后就可以刪除老的應(yīng)用srs-edge-r5-deploy了，系統(tǒng)全部變成新的版本了，如下圖所示：

親，爽嗎？干凈利落，談笑間，強(qiáng)擼灰飛湮滅啦。

LiveVideoStackCon 2020

上海/北京/舊金山講師招募

2020年LiveVideoStackCon將持續(xù)迭代，LiveVideoStackCon將分別在上海（6月13-14日），北京（9月11-12日）和舊金山（11月）舉行。歡迎將你的技術(shù)實(shí)踐、踩坑與填坑經(jīng)歷、技術(shù)與商業(yè)創(chuàng)業(yè)的思考分享出來，獨(dú)樂不如眾樂。請(qǐng)將個(gè)人資料和話題信息郵件到 speaker@livevideostack.com 或點(diǎn)擊【閱讀原文】了解成為L(zhǎng)iveVideoStackCon講師的權(quán)益與義務(wù)，我們會(huì)在48小時(shí)內(nèi)回復(fù)。

超強(qiáng)干貨來襲云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的当SRS遇到K8s：如何实现高可用、回滚与灰度发布？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：实时远程医学影像服务质量保障与网络优化
下一篇：音视频技术开发周刊 | 132（FFmp