歡迎光臨
每天分享高質量文章

高效擴展:當Kubernetes遇到Celery

這是一個關於擴展性和使用痛點的軟體架構故事,和其他好的技術故事一樣,也是從點滴開始的。
在Panorays,我們幫助大量企業用戶衡量供應商的安全地位,但是我更願意看到集中式第三方安全管理。我們先從架構和流程開始。
開始時候,管理虛機都是通過Bash進行的,使用大量的腳本。
  • 每個公司都有一個獨特的虛機實體

  • 每個虛機串行執行很多作業模擬黑客的業務

  • 並行作業是通過啟動更多虛機完成

  • 採用Cron和Bash創建內部編排功能

問題在於:
  • 併發在於公司層面而不是作業層面

  • 行程不透明

  • 服務器利用率太低

  • 手工觸發

興起

這樣的問題引發了Transport工具的興起,Transport是一個動態工作流引擎,將工作流當做Kubernetes的作業調度。基於容器架構使得Transport靈活配置工作,又能有效擴展。根據工作流依存度,可能時提供最佳併發性,並提供完整RESTAPI實現自動管道管理。
當有新公司進入平臺後,Transport的API會自動被觸發,根據實現定義好的工作流情況,Transport將並行或串行將作業提交給Kubernetes執行。

Transport初始版根據如下規則運行:

作用
Transport的作用就是用戶定義工作流,Transport確保發生。但是定義工作流前又需要先定義作業。
我們的例子中,作業等同於運行Docker容器;一組作業叫做階段,可以是串行或者並行;工作流是階段的序列。在新環境下,我們可以在某些規則定義下,實現並行。

不要做無法實現的承諾
Transport調度一個分佈式任務佇列架構,架構中Transport把任務放入佇列中,workers則從佇列中取出任務並執行。此架構支持任務重試、設置超時、設置優先級和定時調度任務。任務開始、成功或者失敗,Transport會往工作流中發送通知。

揭秘
現在可以揭秘了,Transport提供服務端點來操作工作流,工作流被轉譯成Celery任務,我們使用celery鏈和組設置依賴性,Transport根據依賴性將任務轉發到佇列;另外celery workers則從佇列中提取任務,並部署相應的Kubernetes任務。這樣一個工作流根據作業依存性得以完成。
也可以添加為workers提供易用性的服務端點。同時運行worker數量設置了同時可以運行的作業數量。

不要打開打包容器

新部署流程包括安全創建和將docker images推上Google Cloud Registry。
Transport將作業根據工作流轉化成相關作業,而ConfigMap則定義作業版本。
Kubernetes則提供Docker容器底層運行引擎。

命名
開始時我們用與初始作業一樣的名字命名Kubernetes作業,他們有同一個唯一號。

這樣我們發現了一些Kubernetes的命名限制:

第一個正則運算式用於確認名字只由字母和下劃線及橫杠構成,我們發現了第二個最長字符限制。


框架

我們也調研過一些框架方案:
  • Airflow:這是一個很棒的方案,將Python檔案渲染成代表工作流的DAGs。如果有一個運行前確定狀態的靜態工作流,推薦使用Airflow。Airflow的問題在於動態工作流,stackoverflow里有很多如何正確創建動態工作流的方法。因為改變了RESTAPI的請求方法,我們不需要生成動態工作流。

  • Google Pub/Sub:是谷歌pub/sub方案,因為需要在“作業端”修改大量的代碼因此我們也沒有採用它。

  • 可以從更多的任務佇列中找到替換項。

下一步

UI:添加UI來對正在運行和完成工作流進行監控和排錯。
Generify : 如果想使Transport更加普適化,可以將其開源。

原文鏈接:https://hackernoon.com/https-medium-com-talperetz24-scaling-effectively-when-kubernetes-met-celery-e6abd7ce4fed

基於Kubernetes的DevOps實踐培訓

基於Kubernetes的DevOps實踐培訓將於2018年8月24日在北京開課,3天時間帶你系統掌握Kubernetes本次培訓包括:容器特性、鏡像、網絡;Kubernetes架構、核心組件、基本功能;Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則;Kubernetes的資料庫、運行時、網絡、插件已經落地經驗;微服務架構、組件、監控方案等,點擊下方圖片查看詳情。
赞(0)

分享創造快樂