在開始動手設計ews（即tae3.0）之時, 我們參考了諸如swarm, kubernetes, mesos, yarn等衆多與容器叢集管理相關的系統或者設計思路, 當然最為**驚豔**的莫過于kubernetes了.考慮到曆史資料及公司特有的網絡, 運維環境, ews不可能完全抛棄原有的資料模型而使用全新的設計或者說直接建立在諸如kubernetes上(感謝上帝我做了一個非常明确的決定!)。
時至今日, kubernetes也剛剛釋出了1.2版本, 一大波特性襲來. 在簡單了解了一番之後, 回頭再看看ews在這段時間内的變化, 覺得還是應該記錄一下, 也分享一下我對于tae模型設計方面的了解.
ews的模型設計是由paas時代變遷過來的. 當時比較流程的解決方案有heroku, gae, sae等等。比較常見的元件就是一個7層負載接入層, 一個邏輯路由層以及用于運作使用者app的主機(grid)。
在tae1.0時期, 我們使用過基于javaweb的運作環境, 後期使用了基于lxc的輕量級linux隔離環境, 在tae2.0時期我們開始使用docker作為容器虛拟化環境。下表是tae2.0時期的主要應用模型, 命名上, 當時更多的是參考了阿裡的運維系統。
與最新的kubernetes版本支援的多分區不同, ews從一開始就支援了多分區的容器叢集管理能力。下邊兩幅圖分别簡單描述了ews與kubernetes在部署結構上的不同。
通過上兩圖的對比, ews将使用者運作的環境認為是受控區, 而每個受控區會對應一個管控區, 而中心管控節點(controllercenter)與各個管控區通信, 負責指令的下發與管理. 對于kubernetes而言, 其所有的node都是直接與master進行互動的(目前ubernetes實作多分區的思路是基于label機制, 在構架本質上并沒有發生明顯的變化)。
總結一下ews目前的核心設計（與kubernetes對比）
目前主要支援的是商家事業部的聚石塔業務-ews。對于商家, 對于isv開發者來說, 我們把管控單元, 主機分區等等包裝成了region, zone, app等概念, 明确了運維和開發兩種不同的關注點。
ews與kukernetes功能對比：
ews在排程層面，container為主，node為輔
将模型分為運維段和開發段，引入region,zone,app概念，比對現有業務模型
ews 不強調塊存儲，但強調存有狀态業務服務化，即使用rds,oss,ocs等服務化存儲
在起初看到pod, replication controller, label等等概念時, 我就暗自心想不愧是打着谷歌光環的容器叢集管理系統. 下表記錄了一些我認為kubernetes較為核心的模型概念.
pod由container組成并且運作在node之上。
pod的關鍵特性是其内的容器共享一組資源:
pid命名空間: pod中的不同應用程式可以看到其他應用程式的程序id.
網絡命名空間: pod中的多個容器能夠通路同一個ip和端口範圍.
ipc命名空間: pod中的多個容器能夠使用systemv ipc或者posix消息隊列進行通信.
uts命名空間: pod中的多個容器共享一個主機名
volumes: pod中的各個容器可以通路在pod級别定義的volumes.
pod是kubernetes中一個很重要也特有的模型概念, tae中存在叫做節點的概念與之對應, 但是不具備容器共享一組資源的能力.
從tae2.0時期開始, 當時我們使用docker運作諸如wordpress的做法是将apache2, php, mysql運作在一個容器中. 而如果按照kubernetes的做法, 是應該将apache2, php, mysql都運作在獨立的容器中, 一起封裝成一個pod.
why not just run multiple programs in a single (docker) container?1 transparency. making the containers within the pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. this facilitates a number of conveniences for users.2 decoupling software dependencies. the individual containers may be versioned, rebuilt and redeployed independently. kubernetes may even support live updates of individual containers someday.3 ease of use. users don’t need to run their own process managers, worry about signal and exit-code propagation, etc.4 efficiency. because the infrastructure takes on more responsibility, containers can be lighter weight.
以上是kubernetes官方對于為何不要在一個容器中運作多個程序的理由.另外, 值得一提的是如果pod内的容器異常退出時, kubernetes将會如何處理?
在pod的配置檔案中有restartpolicy這個參數, 可選值是always|never|onfailure.如果設定為onfailure, kubernetes将會在發現容器出現問題時, 嘗試重新開機.
在我看來, pod更多的展現的是一種思想及規範; 而為了實作這個規範, 容器叢集管理系統, 包括docker本身則需要付出較大的代價.
在我看來, kubernetes使用replication controller(rc)概念, 向使用者統一抽象了關于排程的幾個重要問題:
排程的機關: pod.
排程的結果: 最終叢集中運作多少個pod副本.
排程模式: 重新排程, 彈性伸縮, 滾動更新.
排程算法: 通過algorithmprovider來提供.
label是我認為kubernetes中最為精彩的模型, 功能設計. kubernetes中所有的模型幾乎都是通過label來互相關聯.通過對pod, node打上标簽, 即可以通過類似sql語句來進行篩選或過濾.
在ews中, 也使用了label機制來進行對主機, 鏡像, 容器等等進行劃分和挑選.
在kubernetes中, service是用于解決pod通路問題的. 目前kubernetes提供了nodeport和loadbalancer兩種方式.
在kubernetes中, namespace可以用于對pod, rc, service等等進行邏輯劃分. 預設情況下, 這些對象都是被配置設定到"default"分組中的.
在ews中, 由于提供了使用者及主機分組的概念, 是以并沒有提供namespace概念.
ews的模型不是一蹴而就的, 在經曆了tae1.0, tae2.0并參考了衆多優秀的架構,系統設計, 目前從完整性, 功能性, 擴充性上來看已經不落後于任何已有的系統.
後續, ews會在動态排程, 彈性縮容, 災備恢複等場景能力上繼續發力.