在不同的公有雲上運作大規模視訊音頻編解碼平台是非常有挑戰的。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、配置版本的支援。
本文轉自中文社群-
視音頻解碼服務商Bitmovin是如何采用Kubernetes進行多級應用部署