視音訊解碼服務商Bitmovin是如何採用Kubernetes進行多級應用部署_Kubernetes中文社群
注：Bitmovin是一家視訊音訊編解碼服務商，這篇文章是由公司平臺架構師Daniel Hoelbling-Inzko分享他們在kubernetes進行應用部署的經驗。由有容雲翻譯。
在不同的公有云上執行大規模視訊音訊編解碼平臺是非常有挑戰的。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、配置版本的支援。