通過三個概念看 Kubernetes 的另一面
之前對容器圈一直不太感冒，一直以傳統 VM 的角度去思考容器的作用和使用，在最近的交流中發現還是有較大的誤區。正好 Ceph 社區要在容器世界里占坑，作者就存儲在容器世界里的作用和使用方式做了一番深入了解，認為容器的使用的確是一種新的的 IT 架構方式，不敢說是不是下一代，但是絕對是另一個顛覆。簡單說它就是以應用為中心的生產模式，這里容器這個詞的本身(LXC, Solaris Zone, FreeBSD Jail) 不是核心，核心是圍繞 Image 產生的應用打包和部署方式。而 LXC 這類 Namespace 技術帶來的高速、簡潔并不是容器技術的殺手锏，實際上利用 kvm/xen 這類虛擬化技術經過一定優化仍然能達到較快的啟動速度，比如 DVM。
在容器的生態圈里，Docker 的確是名副其實的始祖，貢獻了 Docker Image 這套基礎，而后面的 CoreOS，Redhat 的 Atomic 作為 Host OS 提供了較好的容器環境，*** Kubernetes 和 Mesos 以及更多的集群管理添上了***一環。如果是僅僅這樣的體系可能感覺只是一套新的輪子罷了，通過對 Kubernetes 的設計理解結合本人對云的認識，感覺”容器”是一個非常好的云平臺基石。本文就跳過對容器技術的基本介紹，簡單列出 Kubernetes 的概念，然后詳述 Kubernetes 在現在云背景下的角色和能力。
Kubernetes 基礎
Kubernetes 是 Google 開源的容器集群管理平臺，用于應用的部署、維護和擴展。Google 內部一直是容器技術的重度使用者，Kubernetes 是一套經過多年容器技術使用和管理而重新設計及實現的項目。因此，在其中我們可以得到非常多 Google 對于容器技術的理解和使用。首先 Kubernetes 定義了幾個非常重要的概念:
Pod: 一組 Container 實例加上共享目錄的組合。因為一個應用服務往往有多個進程組成，容器化往往要求細粒度，因此一個服務往往可能由多個容器組成，細粒度又造成服務內部的松耦合帶來的不便，因此 Pod 為這類困難提出了解決方案，單個 Pod 內多類資源可見，這個約束條件使得一個 Pod 內所有容器只能存在通一個 Host 上。
復制控制器: 管理 Pod 的生命周期，確保足夠的 Pod 存在于集群內來保證應用和高可用需求。
服務: 其實就是用來標識一組 Pod 的地址，換句話就是負載均衡，但實際上它額外引申出的能力才是 Kubernetes 的核心。
以上三個概念是 Kubernetes 的主要承載，下面我們看看 Kubernetes 有哪些在目前云時代的亮點。
Kubernetes 服務
我們知道在應用生產環境，在對外服務往往是需要地址的，而負載均衡實際上就承擔了大部分的服務注冊并分發作用。因此，Kubernetes 服務就是一個負載均衡，而實現是每一個 Node 上都有有一個 proxy 進程，通過對注冊服務對象的檢測，動態在 Node 上綁定新的 IP:Port 地址，完成對于一組 Pod 的連接，因為一組 Pod 實際上是有一個固定(User defined) 的 IP:Port，而 Proxy 會在 Node 上隨機分配一個 IP:Port 然后與 Pod 的相關聯。這樣解決了應用間可能的地址沖突問題。第二方面也在這一層實現了負載均衡的邏輯 Policy。
這時，我們可以注意到 Kubernetes 作為一個管理框架將自己的服務嵌入到了數據流中，這是***的差異。大部分管理框架往往將自己定位在控制器，的確能減少對于性能和復雜度的影響，但是大大減小了其活動空間，Kubernetes 實現的負載均衡可能不能在大規模平臺中承受壓力，實際上它不也是這么用的。
這時候我們需要引入另外一個背景，在目前的公有云、私有云和混合云的分類下，對于云基礎設施之上的顛覆性變化實際上只能發生在私有云，一個廠商的公有云是無法改變用戶的架構，更談不上整個應用平臺。那么 Google 在公有云追不上 AWS 的情況下推出了一個完全以社區方式運作開發的項目實際上是意味深遠的(之前這樣的項目就是 Andriod 和 Chromium)。Google 仍然希望能在用戶端撬動變革來改變 VM 中心化這個現實，那么 GCE 作為這個變革的云端產物，自然能四兩撥千斤的改變公有云的格局。
回到 Kubernetes 本身，傳統 IAAS 以 VM 為核心作為一個物理服務器的兼容，在靈活的應用業務變遷上存在一定無力。如果在涉及到私有云和混合云甚至不同云平臺之間的聯合，方案會非常復雜，這也是其 VM 本質決定了。那么 Kubernetes 最重要的事情就是打通不同平臺、集群和利舊。因此這里的服務就充當了本地應用平臺的邊緣，不管是將本地應用拓展到云端，還是云端業務利用傳統負載均衡分發到本地，又或者是傳統應用在保持不變的情況下與 Kubernetes 打通。這些方式都是以應用為中心的方案，而不是傳統的 VM 的業務遷移。
另外，云平臺的多集群設計實際上是以 vm 為中心的應用多集群很難在基礎設施平臺做到的，Kubernetes 這里的多集群仍然跟傳統 VM 方式思路不同，不僅僅是控制層面的聯合，也是業務應用層面的聯合。在業務的多集群化上解決本地區域 Overflow 問題，實際上也是混合云最核心的問題。本地私有云在大部分情況下都只會存儲核心甚至機密數據，跟遠端云平臺或者跟業務需要相比都有一定差距，另外多集群對于避免 vendor lockin 也有極大幫助，因此最重要的就是實現跨集群的調度策略、location affinity、服務發現和自動遷移問題。
#p#
Kubernetes 存儲
目前 Kubernetes 以 Docker 作為計算運行后端的情況下，存儲方案以只能基于 LXC 的實現，也就是共享目錄的方式。但是 Kubernetes 比原生 Docker 已經邁進了一步，它在原有的 EmptyDir(默認的讀寫目錄) 和 HostDir(readonly)情況下，增加了對 NFS、iSCSI、GlusterFS 的支持。另外 GCE 和塊存儲和 AWS 的 EBS 也在支持之列。實際上 Kubernetes 在具備集群 Host 管理上也用于更大的存儲釋放空間，比如 Docker 使用 NAT 方式方式 iSCSI Target 使得網絡會成為瓶頸，而 Kubernetes 采用 Host 端掛載的方式。
圖來自參考[6]
而 Ceph RBD 和 CephFS 后端目前也在 Review 過程中，相信較短時間內就可以被 Merge 到主線，而 CephFS 作為 Ceph 的 Posix 接口實際上被寄予了厚望，在容器方案中文件接口實際上比塊接口更合適，在強調業務無縫遷移、整合、擴張的實現上，一個沒有語意的塊接口面臨很大的局限性。因此，CephFS 納入 Kubernetes 并成為繼 OpenStack & RBD 之后的另一個強力組合也理所當然成為 Ceph 社區的目標。另一方面，容器的 LXC 技術在文件接口上的優勢就在于在 Host 端完成了 Automount，而傳統 VM 在 mount 自動化上有很大的難處。
小結
在 Kubernetes 試圖改變應用架構本身的努力上仍然有許多路要走，目前聚焦的是簡單但常用的 Web server，緩存服務，應用服務等等，一些核心的數據庫服務、大數據處理服務仍然需要一定時間去解決。
本文簡單介紹了 Kubernetes 在脫離傳統 VM 的思路下如何將容器技術真正作為用戶轉身云平臺的利器，其完全脫離傳統云對于控制層面的掌握，加強了數據層面的介入，并利用以應用為中心的鏡像機制實現了更強的云平臺基礎設施能力。
如果本文對于容器或者 Kubernetes 的理解有誤還請多多指正!
參考
Kubernetes(https://github.com/GoogleCloudPlatform/kubernetes)
Kubernetes Service(https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md)
Kubernetes Ceph RBD Driver(https://github.com/GoogleCloudPlatform/kubernetes/pull/6578)
Kubernetes Storage(https://github.com/GoogleCloudPlatform/kubernetes/issues/5129)
Kubernetes CephFS Driver(https://github.com/GoogleCloudPlatform/kubernetes/pull/6649)
iSCSI as on-premise Persistent Storage for Kubernetes and Docker Container(https://huaminchen.wordpress.com/2015/03/05/5/)
