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

高效擴充套件:當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)

分享創造快樂