1. 程式人生 > >雲架構師進階攻略(2)

雲架構師進階攻略(2)

ria docker 環境 圖片 ace -i art 名稱 機制

此文已由作者劉超授權網易雲社區發布。

歡迎訪問網易雲社區,了解更多網易技術產品運營經驗。


八、基於OpenStack了解雲平臺

當有了虛擬機,並且虛擬機能夠上網了之後,接下來就是搭建雲平臺的時候了。

雲是基於計算,網絡,存儲虛擬化技術的,雲和虛擬化的主要區別在於,管理員的管理模式不同,用戶的使用模式也不同。

虛擬化平臺沒有多層次的豐富的租戶管理,沒有靈活quota配額的限制,沒有靈活的QoS的限制,多采用虛擬網絡和物理網絡打平的橋接模式,虛擬機直接使用機房網絡,沒有虛擬子網VPC的概念,虛擬網絡的管理和隔離不能和租戶隔離完全映射起來。對於存儲也是,公司采購了統一的存儲,也不能和租戶的隔離完全映射起來。

使用虛擬化平臺的特點是,對於這個平臺的操作完全由運維部門統一管理,而不能將權限下放給業務部門自己進行操作。因為一旦允許不同的部門自己操作,大家都用機房網絡,在沒有統一管控的情況下,很容易網段沖突了。如果業務部門向申請虛擬機,需要通過工單向運維部門統一的申請。當然這個運維部門很適應這種方式,因為原來物理機就是這樣管理的。

但是公有雲,例如aws就沒辦法這樣,租戶千千萬萬,只能他們自己操作。在私有雲裏面,隨著服務化甚至微服務化的進行,服務數目越來越多,叠代速度越來越快,業務部門需要更加頻繁的創建和消耗虛擬機,如果還是由運維部統一審批,統一操作,會使得運維部門壓力非常大,而且極大限制了叠代速度,因而要引入 租戶管理,運維部靈活配置每個租戶的配額quota和QoS,在這個配額裏面,業務部門隨時可以按照自己的需要,創建和刪除虛擬機,無需知會運維部門。每個部門都可以創建自己的虛擬網絡VPC,不同租戶的VPC之前完全隔離,所以網段可以沖突,每個業務部門自己規劃自己的網絡架構,只有少數的機器需要被外網或者機房訪問的時候,需要少數的機房IP,這個也是和租戶映射起來的,可以分配給業務部門機房網IP的個數範圍內,自由的使用。這樣每個部門自主操作,叠代速度就能夠加快了。

雲平臺中的開源軟件的代表是OpenStack,建議大家研究OpenStack的設計機制,是在雲裏面通用的,了解了OpenStack,對於公有雲,容器雲,都能發現相似的概念和機制。


沿著OpenStack創建虛擬機的過程,我總結了100個知識點,寫下了下面的文章。

OpenStack虛擬機創建的50個步驟和100個知識點

用OpenStack界面輕松創建虛擬機的你,看得懂虛擬機啟動的這24個參數麽?

覺得OpenStack的網絡復雜?其實你家裏就有同樣一個網絡

當發現你的OpenStack虛擬機網絡有問題,不妨先試一下這16個步驟

手動用KVM模擬OpenStack Cinder掛載iSCSI卷

不僅Docker會使用Control Group,KVM也會使用Cgroup來控制資源分配

通過我們研究OpenStack,我們會發現很多非常好的雲平臺設計模式。


第一:基於PKI Token的認證模式

如果我們要實現一個Restful API,希望有個統一的認證中心的話,Keystone的三角形工作模式是常用的。

當我們要訪問一個資源,通過用戶名密碼或者AK/SK登錄之後,如果認證通過,接下來對於資源的訪問,不應該總帶著用戶名密碼,而是登錄的時候形成一個Token,然後訪問資源的時候帶著Token,服務端通過Token去認證中心進行驗證即可。

技術分享圖片

如果每次驗證都去認證中心,效率比較差,後來就有了PKI Token,也即Token解密出來是一個有詳細租戶信息的字符串,這樣本地就可以進行認證和鑒權。

技術分享圖片??

??

第二:基於Role Based Access Control的鑒權模式

對於權限控制,我們學會比較通用的Role Based Access Control的權限控制模式, 形成“用戶-角色-權限”的授權模型。在這種模型中,用戶與角色之間,角色與權限之間,一般者是多對多的關系,可以非常靈活的控制權限。

技術分享圖片

第三:基於Quota的配額管理

可以通過設置計算,網絡,存儲的quota,設置某個租戶自己可以自主操作的資源量。

第四:基於預選和優選兩階段的Scheduler機制

當需要從一個資源池裏面,選擇一個節點,使用這個節點上的資源的時候,一個通用的Scheduler機制是:

· 首先進行預選,也即通過Filter,將不滿足條件的過濾掉。

· 然後進行優選,也即對於過濾後,滿足條件的候選人,通過計算權重,選擇其中最優的。

技術分享圖片

第五:基於獨立虛擬子網的網絡模式

為了每個租戶可以獨立操作,因而虛擬網絡應該是獨立於物理網絡的,這樣不同的租戶可以進行獨立的網絡規劃而互不影響,也不影響物理網絡,當需要跨租戶訪問,或者要訪問物理網絡的時候,需要通過路由器。

技術分享圖片

第六:基於Copy on Write的鏡像機制

有時候我們在虛擬機裏面做了一些操作以後,希望能夠把這個時候的鏡像保存下來,好隨時恢復到這個時間點,一個最最簡單的方法就是完全復制一份,但是由於鏡像太大了,這樣效率很差。因而采取Copy on write的機制,當打鏡像的時刻,並沒有新的存儲消耗,而是當寫入新的東西的時候,將原來的數據找一個地方復制保存下來,這就是Copy on Write。

對於Openstack,有一種鏡像qcow2就是采取的這樣的機制。

技術分享圖片

這樣鏡像就像分層一樣,一層一層的羅上去。

第七:基於namespace和cgroup的隔離和Qos機制

在OpenStack裏面,網絡節點的路由器是由network namespace來隔離的。

技術分享圖片

KVM的占用的CPU和內存,使用Cgroup來隔離的。

技術分享圖片

網絡的QoS使用TC來隔離的。

技術分享圖片

第八:基於iptables的安全機制

有時候,我們希望網絡中的節點之間不能相互訪問,作為最簡單的防火墻,iptables起到了很重要的作用,以後實現ACL機制的,都可以考慮使用iptables。

技術分享圖片

九、基於Mesos和Kubernetes了解容器平臺

搭建完畢虛擬化層和雲平臺層,接下來就是容器層了。

Docker有幾個核心技術,一個是鏡像,一個是運行時,運行時又分看起來隔離的namespace和用起來隔離的cgroup。

Docker的鏡像也是一種Copy on Write的鏡像格式,下面的層級是只讀的,所有的寫入都在最上層。

技術分享圖片

對於運行時,Docker使用的namespace除了network namespace外,還有很多,如下表格所示。

技術分享圖片

Docker對於cgroup的使用是在運行Docker的時候,在路徑/sys/fs/cgroup/cpu/docker/下面控制容器運行使用的資源。

可見容器並沒有使用更新的技術,而是一種新型的交付方式,也即應用的交付應該是一容器鏡像的方式交付,容器一旦啟動起來,就不應該進入容器做各種修改,這就是不可改變基礎設施。

由於容器的鏡像不包含操作系統內核,因而小的多,可以進行跨環境的遷移和彈性伸縮。


我寫下了下面的文章,總結了幾點容器的正確使用姿勢。

容器化的本質?基於鏡像的跨環境遷移

有關容器的六大誤區和八大正確場景

有了容器之後,接下來就是容器平臺的選型,其實swarm, mesos, kubernetes各有優勢,也可以在不同的階段,選擇使用不同的容器平臺。

Docker, Kubernetes, DCOS 不談信仰談技術

容器平臺選型的十大模式:Docker、DC/OS、K8S誰與當先?

基於Mesos的DCOS更像是一個數據中心管理平臺,而非僅僅容器管理平臺,他可以兼容Kubernetes的編排,同時也能跑各種大數據應用。

DC/OS的基本思想——為什麽說他是數據中心操作系統

號稱了解mesos雙層調度的你,先來回答下面這五個問題!

DC/OS的容器功能

DC/OS的網絡功能

DC/OS的存儲功能

DC/OS的服務發現與負載均衡功能

在容器領域,基於Kubernetes的容器編排已經成為事實標準。

技術分享圖片

基於萬節點Kubernetes支撐大規模雲應用實踐

支撐大規模公有雲的Kubernetes改進與優化 (1)

支撐大規模公有雲的Kubernetes改進與優化 (2)

支撐大規模公有雲的Kubernetes改進與優化 (3)

為支撐高並發應用的 Kubernetes 的性能優化

當我們深入分析Kubernetes管理容器模式的時候,我們也能看到熟悉的面孔。

在Kubernetes裏面,租戶之間靠namespace進行隔離,這個不是Docker的namespace,而是Kubernetes的概念。

API Server的鑒權,也是基於Role Based Access Control模式。

Kubernetes對於namespace,也有Quota配置,使用ResourceQuota。

技術分享圖片

當Kubernetes想選擇一個節點運行pod的時候,選擇的過程也是通過預選和優選兩個階段。

· 預選(Filtering)

§ PodFitsResources滿足資源

§ PodSelectorMatches符合標簽

§ PodFitsHost符合節點名稱

· 優選(Weighting)

§ LeastRequestedPriority資源消耗最小

§ BalancedResourceAllocation資源使用最均衡

Kubernetes規定了以下的網絡模型定義。

· 所有的容器都可以在不使用NAT的情況下同別的容器通信

· 所有的節點都可以在不使用NAT的情況下同所有的容器通信

· 容器的地址和別人看到的地址一樣

也即容器平臺應該有自己的私有子網,常用的有Flannel, Calico, Openvswitch都是可以的。

既可以使用Overlay的方式,如圖flannel.

技術分享圖片

也可以使用BGP的方式,如圖Calico


相關閱讀:

雲架構師進階攻略(1)

雲架構師進階攻略(3)


網易雲計算基礎服務深度整合了 IaaSPaaS 及容器技術,提供彈性計算、DevOps 工具鏈及微服務基礎設施等服務,幫助企業解決 IT、架構及運維等問題,使企業更聚焦於業務,是新一代的雲計算平臺,點擊可免費試用


相關文章:
【推薦】 使用窮人版profiler定位調試MySQL
【推薦】 如何搭建SBT編譯Scala開發的Android工程
【推薦】 如何用GO實現一個tail -f功能以及相應的思維發散

雲架構師進階攻略(2)