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

Photo by Luis Quintero from Pexels

本文来自流媒体直播集群SRS的官方wiki（https://github.com/ossrs/srs/wiki/v4_CN_K8s），由SRS的创始作者杨成立授权发布。

文 / 杨成立

相关文章：

当SRS遇到K8s：快速构建高并发直播集群

当SRS遇到K8s：如何构建海量推流源站？

 

服务的更新、回滚和灰度，是个简单的问题，如果加上一个条件"不中断服务的前提下"，那么就是一个难题，如果再加上"大规模"，那么就是K8S要解决的核心问题之一。坏消息是这个难搞的问题还真是流媒体服务的核心的、关键的、不可忽视的关键能力之一，好消息是K8S和云计算让这个难题稍微好一点点了。

我们在什么场景下会遇到更新、回滚和灰度的问题：

• SRS需要升级新版本，如何知道升级后对现有业务没有影响？如果选择业务量小升级，那一般常态会是半夜三更、凌晨三四点，还要不要头发了呢？

• 改进了新的功能或优化，根据业务定制了新的东西（完全直接使用SRS也得有自己的业务服务器），如何只在一部分机器发布，看看效果有没有达到预期？

• 更新新版本后，如果发现有问题，影响了用户服务，如何在最短时间内回滚到之前的版本？问题出现时首先是要确认问题后(若由升级引起则)回滚，而不是很费时间的找Bug。

在这个场景下，对比K8S和传统部署方式的差异：

对比项	ECS	K8S	说明
部署	安装包	镜像	Docker镜像可回滚，开发和生产环境一致，可Cache，高效率和高密度，高可移植性，资源隔离可预测程序性能
看门狗	手动	自动	SRS异常退出由看门狗重新拉起，非K8S需要手动安装，K8S自动管理和拉起服务
更新	手动	自动	传统方式用脚本下载和更新二进制，人工分批更新，K8S自动Rolling Update，自动下载镜像和分批更新
灰度	手动	自动	传统方式手动操作SLB决定切量比例，K8S通过Replicas控制比例，自动切量
回滚	手动	自动	传统方式手动回滚，K8S有版本管理和回滚机制

Note:平滑更新的关键是平滑退出，重点是边缘集群的更新，对于源站集群我们可以选择直接重启，因为一般会有边缘集群作为代理，源站断开后边缘会重试，不影响用户，参考#1579（https://github.com/ossrs/srs/issues/1579#issuecomment-587233844）。

我们重点关注边缘集群的平滑退出，SRS边缘属于长连接无状态服务。和Nginx一样，SRS使用SIGQUIT作为信号，同时配置force_grace_quit认为SIGTERM也是平滑退出，收到SIGQUIT信号后，会等待grace_start_wait指定的时间，然后关闭Listeners新的连接不会分配到这个服务器，然后开始清理并等待现有连接退出，所有连接退出后还会等待grace_final_wait指定的时间，才会退出。

以之前部署的SRS源站和边缘集群为例，参考SRS Origin Cluster for a Large Number of Streams，SRS边缘的Pod的配置，需要指定平滑退出的参数，例如：

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;