在不同的公有云上运行大规模视频音频编解码平台是非常有挑战的。Bitmoving在过去的平台运维中积累了很多经验，但是也有不少困难。所以，kubernetes首先吸引我们的就是它对底层公有云平台的抽象，并且提供了定义完好的API接口。更为重要的是，kubernetes不只是提供了一种一般程度上的抽象，它是把运行容器平台所需要的工具和概念进行了全面的整合抽象，并且能够无缝的对接各种公有云的基础设施。
在我们的初始测试阶段，我们已经相当熟悉kubernetes的API调用了，当 我们的服务不仅需要部署到公有云中，而且需要部署到客户的私有数据中心中时，我们迅速决定利用kubernetes来完成我们从公有云服务到私有云服务的在技术上的统一。
这个就是我们后来推出的bitmovin Managed On-Premise encoding服务。因为kuberenets对用户来说屏蔽了底层基础设施的不同，我们可以采用一套API来驱动公有云服务或者私有云服务。当然如果要达成这样的目标，我们就无法采用像LoadBalancer Service这样的的组件，因为对企业用户来说，他们通常不愿意把内部端口暴露出去，而且一般情况下，企业进行平台部署时也不会存在已经和kubernetes整合完好的外部LoadBalancer。为了解决这个问题，我们开发了BitmovinAgent组件，它运行在客户环境的集群中，不需要任何网络上的配置，这个组件查询需要运行的encoding job, 获取本地认证信息，然后通过kubernetes API调用运行这些job.。虽然不是一个完全的整合，但是kubernetes API提供各种任务调度，健康检查，监控服务都使我们更加专注于本身的业务开发，而不需要花时间在如何驱动底层的基础设施上。
金丝雀部署
我们在四个月前把应用移植部署到了kubernetes平台。这个平台上我们跑着很多容器。为了能够做好从开发到生产的不间断快速迭代，我们需要满足以下几个要求：
1、对于用户来说，应用从不中断。
2、每次新版本的发布，能够快速从开发到生产不间断部署。
3、保证应用部署的高质量。
我们可以看到要同时做到第二点和第三点是很有挑战的。为了应对这样的挑战，我们对于每一个需要上线的微服务采用了一种四个阶段的金丝雀部署pipeline。直到我们认为新的应用版本升级是安全的，我们才会在生产环境中进行大规模部署。
首先，当新版本发布后，我们会部署到我们的内部环境中进行测试，当测试通过后，我们会将应用部署到免费客户平台中，这意味着有5%的免费用户会访问我们新版本的应用。接着，我们会将新应用部署到5%的付费用户中。只有在前面三个平台上表现良好，我们才会在生产上大规模采用新版本的应用。
根据图一的部署，我们可以来看看系统中的pod数量和分类。一般来说，我们给每个微服务分配2个internal pod、4个free pod、4个paid pod和10个productionpod，还要加上4个haproxy的pod，请见下表：
一个典型的service yaml文件如下：
apiVersion: v1 kind: Service metadata: name: account-service-production labels: app: account-service-production tier: service lb: private spec: ports: - port: 8080 name: http targetPort: 8080 protocol: TCP selector: app: account-service tier: service track: production
在kubernetes service前端，我们部署了小型HAProxy集群。HAProxy pod从ConfigMaps中拿到haproxy.cfg配置。见下图：
frontend http-in bind *:80 log 127.0.0.1 local2 debug acl traffic_internal hdr(X-Traffic-Group) -m str -i INTERNAL acl traffic_free hdr(X-Traffic-Group) -m str -i FREE acl traffic_enterprise hdr(X-Traffic-Group) -m str -i ENTERPRISE use_backend internal if traffic_internal use_backend canary if traffic_free use_backend enterprise if traffic_enterprise default_backend paid backend internal balance roundrobin server internal-lb user-resource-service-internal:8080 resolvers dns check inter 2000 backend canary balance roundrobin server canary-lb user-resource-service-canary:8080 resolvers dns check inter 2000 weight 5 server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 95 backend paid balance roundrobin server canary-paid-lb user-resource-service-paid:8080 resolvers dns check inter 2000 weight 5 server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 95 backend enterprise balance roundrobin server production-lb user-resource-service-production:8080 resolvers dns check inter 2000 weight 100
我们系统中的API网关会为每个用户请求头部分配一个X-Traffic-Group的标识，HAProxy根据这个标识来路由用户请求到不同的金丝雀部署环境中。
当生产规模进行扩展时，采用kubectl有时候不能有效跟踪各个部署的状态，各个pod的副本数是过多还是过少。我们用go并且调用kubernetes client-go库编写了自己的工具来对系统中运行的各个部署状态进行有效的监控和管理。
值得一提的是，我们还开发了一个健康检查工具。这个工具查找所有包含tier:service的selector, 检查和这个service相关的HAProxy是否健康，并且检查每种Pod包含4个副本。它还会检查HAProxy后面的四种部署（internal, free, paid，production）最少存在两个有效的endpoints. 如果有任何错误发生，这个工具会发邮件或者Slack通知。
Kubernetes的资源配置说明resource specifications能让我们为集群中的specifications建立git库。这样每当我们对集群做出了改变，我们都能进行版本管理和追溯。
最后我们总结一下采用了kubernetes进行多级应用部署后的好处：
1、持续不间断的应用部署。完美一致的用户体验。
2、使我们能够很快的发布新的版本上线。
3、多层次的测试发布能够保证应用最大限度的稳定。
4、全面整合公有云和私有云的部署。
5、完善的资源调度和健康检查。
6、采用工具对系统的健康稳定性做全局的检测。
7、配置版本的支持。
