雲架構師進階攻略（2）
此文已由作者劉超授權網易雲社區發佈。
歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。
八、基於OpenStack瞭解雲平臺
當有了虛擬機，並且虛擬機能夠上網了之後，接下來就是搭建雲平臺的時候了。
雲是基於計算，網絡，存儲虛擬化技術的，雲和虛擬化的主要區別在於，管理員的管理模式不同，用戶的使用模式也不同。
虛擬化平臺沒有多層次的豐富的租戶管理，沒有靈活quota配額的限制，沒有靈活的QoS的限制，多采用虛擬網絡和物理網絡打平的橋接模式，虛擬機直接使用機房網絡，沒有虛擬子網VPC的概念，虛擬網絡的管理和隔離不能和租戶隔離完全映射起來。對於存儲也是，公司採購了統一的存儲，也不能和租戶的隔離完全映射起來。
使用虛擬化平臺的特點是，對於這個平臺的操作完全由運維部門統一管理，而不能將權限下放給業務部門自己進行操作。因爲一旦允許不同的部門自己操作，大家都用機房網絡，在沒有統一管控的情況下，很容易網段衝突了。如果業務部門向申請虛擬機，需要通過工單向運維部門統一的申請。當然這個運維部門很適應這種方式，因爲原來物理機就是這樣管理的。
但是公有云，例如aws就沒辦法這樣，租戶千千萬萬，只能他們自己操作。在私有云裏面，隨着服務化甚至微服務化的進行，服務數目越來越多，迭代速度越來越快，業務部門需要更加頻繁的創建和消耗虛擬機，如果還是由運維部統一審批，統一操作，會使得運維部門壓力非常大，而且極大限制了迭代速度，因而要引入 租戶管理，運維部靈活配置每個租戶的配額quota和QoS，在這個配額裏面，業務部門隨時可以按照自己的需要，創建和刪除虛擬機，無需知會運維部門。每個部門都可以創建自己的虛擬網絡VPC，不同租戶的VPC之前完全隔離，所以網段可以衝突，每個業務部門自己規劃自己的網絡架構，只有少數的機器需要被外網或者機房訪問的時候，需要少數的機房IP，這個也是和租戶映射起來的，可以分配給業務部門機房網IP的個數範圍內，自由的使用。這樣每個部門自主操作，迭代速度就能夠加快了。
雲平臺中的開源軟件的代表是OpenStack，建議大家研究OpenStack的設計機制，是在雲裏面通用的，瞭解了OpenStack，對於公有云，容器雲，都能發現相似的概念和機制。
沿着OpenStack創建虛擬機的過程，我總結了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的編排，同時也能跑各種大數據應用。
在容器領域，基於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
相關閱讀：
網易雲計算基礎服務深度整合了 IaaS、PaaS 及容器技術，提供彈性計算、DevOps 工具鏈及微服務基礎設施等服務，幫助企業解決 IT、架構及運維等問題，使企業更聚焦於業務，是新一代的雲計算平臺，點擊可免費試用。
相關文章：
【推薦】 真屏實據丨數據大屏設計實戰—揭祕企業級數據大屏設計過程
【推薦】 Google準實時數據倉庫Mesa（一）
【推薦】 實現自己的前端模板輕量級框架