這是一個關於擴充套件性和使用痛點的軟體架構故事，和其他好的技術故事一樣，也是從點滴開始的。
在Panorays，我們幫助大量企業使用者衡量供應商的安全地位，但是我更願意看到集中式第三方安全管理。我們先從架構和流程開始。
開始時候，管理虛機都是透過Bash進行的，使用大量的指令碼。
-
每個公司都有一個獨特的虛機實體
-
每個虛機序列執行很多作業模擬駭客的業務
-
並行作業是透過啟動更多虛機完成
-
採用Cron和Bash建立內部編排功能
-
併發在於公司層面而不是作業層面
-
行程不透明
-
伺服器利用率太低
-
手工觸發
這樣的問題引發了Transport工具的興起，Transport是一個動態工作流引擎，將工作流當做Kubernetes的作業排程。基於容器架構使得Transport靈活配置工作，又能有效擴充套件。根據工作流依存度，可能時提供最佳併發性，並提供完整RESTAPI實現自動管道管理。
當有新公司進入平臺後，Transport的API會自動被觸發，根據實現定義好的工作流情況，Transport將並行或序列將作業提交給Kubernetes執行。
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實踐培訓將於2018年8月24日在北京開課，3天時間帶你係統掌握Kubernetes。本次培訓包括：容器特性、映象、網路；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的資料庫、執行時、網路、外掛已經落地經驗；微服務架構、元件、監控方案等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
