Kubernetes已經成為容器編排系統的事實標準，是現在主流的跨云容器化應用操作系統。
但是，Kubernetes的目標并不是容器本身，而是承載其上的應用，本質上是為了解決（容器化）應用上云這個難題。
容器和K8s的出現, 提供了一套統一的抽象核心，使得圍繞他們實現多云業務成為可能。
那么，非容器化應用怎么辦？
本篇將告訴你，K8s不管的，我們怎么管：
容器化應用怎么跑多云？
我們從K8s學到了三個大招
非容器化應用怎么跑多云？
多云環境下，如果某些云出現不可抗拒性故障時，對上層企業應用有多少影響？
非容器化應用，即不支持容器化的應用，既包括了Legacy APP，也包括那些因為商業原因不支持容器化的應用，比如很多傳統HPC應用。我們面向的像生命科學/半導體/汽車制造這些行業用戶很多時候使用的就是非容器化應用。
基于本地+多云的系統架構，大致分為以下四個層面：應用層，業務調度層，資源配置層，云提供商層。
云提供商提供的是底層基礎設施和資源。
資源配置層是把云提供商的資源進行集群化管理，再進一步池化，抽象，變成一個動態的池子。
因為我們的用戶的需求不是一個恒定的值，是有波動的，有時候短期內會有很大的需求，但除了這些時間之外，大部分時候沒有那么大需求，所以我們需要動態管理/動態申請云資源的抽象。
業務調度層解決的問題是怎么把應用把跑在我們抽象好的這些資源上面，跑在哪里，怎么跑，這些問題。
1
容器化應用怎么跑多云
對于容器化應用來說：
K8s解決了業務調度這一層，怎么把應用跑在我們配置的環境上面，容器化應用提供了統一的調度對象。因為K8s有一個統一的抽象了，所以你可以把K8s部署在不同的云上面，通過統一的管理方式，實現多云的工作負載分配。
但是K8s沒有解決的問題是，怎么構建各個云上的K8s集群。
雖然說CNCF（云原生計算基金會）社區里有很多各種各樣的工具，比如說像terraform，可以幫助用戶構建集群，但是畢竟它是一個獨立的工具，難免會增加用戶的學習成本。而且，你如果想要控制某一個workload，動態地申請這些資源，就得自己去開發定制這些額外的東西。
對用戶來說，這些都是實現多云的阻礙。
2
我們從K8s學到了三個大招
統一的抽象層
通過抽象統一的控制界面（API），可以屏蔽掉底層的區別，來管理不同的云上類似的資源。用戶不需要直接接觸使用底層的資源，我們可以根據這個抽象來提供更可擴展的stack。
聲明式的基礎架構描述方式
利用抽象出來的控制界面，統一描述云上互相關聯的計算資源，而這同一套描述可以應用在不同的云上。
K8s描述的是一個狀態，我們覺得這是一個很好的東西。為什么呢？
因為聲明式的構架描述的是狀態，所以把怎么樣達到這個狀態這件事情，交給了平臺本身，我們就可以根據現在平臺的狀態以及這些資源的狀態，比如說價格這些方面來調配我們怎么樣去達到這個狀態。
自動化管理
利用API，大多數的業務流程可以實現自動化，減少維護人員負擔。
例如根據業務的規模和用戶指定的策略，動態地伸縮集群規模，實現最大化地利用資源。對于一些可被替換的計算實例，同時可實現自動化替換和計算恢復等。
3
非容器化應用怎么跑多云？
我們要解決的核心需求是：對于不適合容器化的應用，我們也可以采用聲明的方式定義資源需求和運行方式，在不改變應用內部邏輯的情況下，將應用運行在多云的環境中。
用戶在使用這些應用的時候會有一個順序，比如說先跑某個應用，然后產生了一些中間數據，中間數據會被喂給下一級的應用，被下一級的應用消耗，以這樣的工作流達到最終他要的目的。這個流程就變成我們用來調度和抽象，分配這些應用的點。
我們的系統里面設計了五個主要的組件：
云服務抽象Serverless層
統一集群描述系統
智能策略調度系統
工作流引擎
分布式文件緩存系統
云服務抽象Serverless層
云抽象層把每個云上面常用的一些組件，比如說像instance虛機，網絡，鏡像，子網、防火墻，對這些常見的功能我們做了抽象。將所有的云資源，不管是本地還是公有的，變為一個大的資源池。并且能夠把功能和資源拆分開，利用下層的異構的多云的計算資源，動態地為用戶提供服務。對于每種資源的操作，轉換為對應云提供商API的操作。
這個抽象層還可以幫助我們實現一些有的云有，有的云沒有的功能。
比如AWS現在有一個Spot Fleet的功能，你可以告訴它我需要多少臺機器，什么樣的機器，然后你可以在一個范圍里去選擇。這個功能我們在阿里云或者其他云上沒有見到，現在我們可以通過抽象來自己實現這樣一個功能。
很可惜，不是所有的云資源都能通過這樣統一的抽象，特別是一些高端的資源，比如AWS Lambda這種我們就沒法抽象。因為它是利用了底層資源做了一個更高級別的優化，或者說是更高級別的簡化而形成的，在不同的云上是不一樣的，有些云可能沒有。
統一集群描述系統
我們學習了K8s，在這個基礎上提供了一個統一的基礎架構描述系統，通過聲明式描述來定義基礎架構。簡單來說，你要的這些虛機或者是這些虛機之間的關系是怎么樣去定義的。
像Hashicorp提供的terraform就提出“infrastructure as code”，架構即代碼。我們也用了這個理念，好處是你能夠明確看到你的架構是什么樣的，并且你可以描述這個狀態。比如說你在一個云上面定義并實現了這樣一個架構，你就可以把它搬到另一個云上去，而且不會出錯。
實現“Write once, run anywhere”的跨云浮動。
智能策略調度系統
有了前面兩個作為基礎，我們就可以實現根據用戶偏好的智能調度。
前面我們提過我們的集群是一個動態的集群，是可以根據某種策略或者云上的狀態來決定這些業務跑在哪里的一個過程，所以我們有一個智能調度策略系統，它會根據用戶的輸入，這個數據有多大，用戶的偏好是什么來進行調度。
如果用戶偏好是成本，可以接受一定程度上的慢。我們就可以找一些便宜的資源，比如像AWS的Spot instance（spot是我們可以以很低的價格來使用的資源），但這種資源并不保證一直都有。如果用戶選擇了這樣的偏好，我們系統會在一定程度上去等這個資源，當這個資源有的時候我們去跑，可以在晚上，或者有資源的時候再跑這個任務。如果用戶非常希望很快地把結果算出來，我們可以調動云上我們可以申請得到的最快的資源來幫用戶把這個事情給計算出來。
工作流引擎
通常，用戶在使用他們的應用的時候會有一個工作流程。比如第一步使用什么程序，第二步使用什么程序。我們在系統里集成了一個工作流引擎，用戶可以通過圖形化的方式來編輯這個工作流。而且系統里已經預裝了一些常見的流程，支持順序地執行任務。
不同的步驟有不同的特點。比如有些步驟可能需要很多節點同時來執行一些任務，并發量比較大，有些步驟可能沒有那么大。我們可以根據這個工作流來調整我們的集群規模，這樣也可以幫用戶節省成本。
分布式文件緩存系統
這是一個比較重要的點：數據訪問。
一個程序或者一個應用是不能單獨完成工作的，肯定需要數據。傳統應用大部分是設計在Linux/UNIX上面的，用戶可以直接通過文件的方式訪問這些數據的。
所以我們需要兩點：
一、有一個直接訪問數據的方式，并且把數據訪問構建在多云上面。
二、用戶的數據可能已經存在現有的一些存儲系統上，比如S3/OSS/NFS。我們覺得應該直接去利用用戶現有的這些數據，而不是再復制一遍，做一個新的存儲系統。一種常見方式是：把集群建立起來，建立一個臨時的數據倉庫，把數據從原來的地方復制到這個數據倉庫里使用，使用完了之后再復制回去。我們想建立這樣的一個緩存系統來避免這種復制，這樣可以節省用戶集群構建的時間。很多時候用戶都是把數據放在一個很大的集合里，原來那種方式很難避免把不需要用的數據也復制過來。比如說我們有一個分布式計算，這個計算中不需要使用的數據我們也要把它復制出來。考慮到這一點，我們只把需要使用的那個部分緩存到現有系統里來，計算完后再寫回到目標的存儲系統里面。
而且這個設計是一個scale out架構，當性能達不到用戶要求的時候，可以通過增加節點的方式來擴展性能。
我們還支持不同的緩存策略。可以有多個不同的data server，數據服務器可以在不同的云上，這樣的話就把數據緩存在了計算真正需要的地方，可以加速數據訪問。比如說我的計算是在這個云上面，算完之后，希望把它寫回到某個目標的存儲上面。
支持自動預取和手動預取。意思是說，我們在做計算的時候知道應用放在哪里，所以我們可以告訴我們的緩存系統，需要把數據先遷移到哪里去，這樣就避免了不必要的拷貝，在訪問的時候能夠很快地去使用數據。
4
多云環境下，如果某些云出現不可抗拒性故障，對上層企業應用有多少影響？
具體的影響需要看具體的部署方式和應用本身來分析。
我們采用的是雙層調度的概念：
第一層調度分配業務位置，解決的問題是我要把資源放在哪里。
第二層調度分配業務內部工作負載。
我已經決定把工作負載放在這個云上的時候，我會在這個云上建立一個集群。任務的一部分就會在這個集群里運行，我們在整個過程都是在監控的，如果某種原因某個地方被停掉了，發生障礙，上層調度會發現這件事情，我們會自動把任務調度到另外一個地方去，或者另一個云上。一般調度時, 業務整體會被分配到一個云上。如果由于某種原因整個云上資源不可訪問時，第一層調度會把業務調度到另外的云上。
所以我們才能支持使用spot這種可被搶占的資源，可以及時調度到另外的地方去。
- END -
關于我們：
速石科技專為有高算力需求的企業級用戶提供一站式算力運營解決方案，幫助用戶提升10-20倍業務運算效率，降低成本達到75%以上，加快市場響應速度。目前主要應用領域包括藥物研發、基因測序分析、半導體行業的EDA仿真及電路設計、汽車行業的自動駕駛開發、虛擬碰撞試驗以及AI人工智能。
想了解更多，可添加小F微信（ID：imfastone）
文章推薦：
>>AWS、阿里云、Azure、Google Cloud、華為云、騰訊云 各種云服務器價格收費對比（上）
