摘要：其次，青云的負載均衡器能感知到容器網(wǎng)絡，而傳統(tǒng)的方案在內(nèi)部還需要再做一層虛擬網(wǎng)絡，層的負載均衡器無法感知容器網(wǎng)絡。

前言

容器技術目前的市場現(xiàn)狀是一家獨大、百花齊放。 關于容器技術，看看青云QingCloud 王淵命（老王）是如何看待它的，本文來自他在青云QingCloud 深圳站實踐課堂的演講。全文 2780字，閱讀時長約為 11 分鐘。

容器是什么

容器的概念外延比較廣，討論的時候容易產(chǎn)生分歧，雖然大家都在說容器，但各自的角度不同，表達的具體內(nèi)容也完全不一樣?？偨Y來看容器有兩個視角，一是資源，二是應用。

一是從資源隔離的角度。容器技術經(jīng)常被拿來跟虛擬化技術作對比，從技術角度來說，容器是一種跟VM 類似的資源隔離技術，它比 VM 的資源損耗小，但隔離性和安全性不如 VM ，等等。

二是從應用封裝的角度。Docker 之所以興起，原因在于其重點關注應用的標準化，而不是資源的隔離。Docker 的鏡像機制提供了一種更高級的通用的應用制品包，也就是大家說的集裝箱能力。原來各種操作系統(tǒng)或編程語言都有各自己的制品機制，各自的依賴管理，制品庫都不相同。應用從源碼打包，分發(fā)到制品庫，再部署到服務器，很難抽象出一種通用的流程和機制。

而有了 Docker 的鏡像以及鏡像倉庫標準之后，這個流程終于可以標準化了。同時Docker 將進程的管理，比如啟動停止也標準化了。類似杯子、筐、集裝箱都是容器，它們的共同特點是能把雜物打包，標準化，方便運輸和定價。在此之上，容器可以做更高級的邏輯分裝和調(diào)度。

容器生態(tài)圈現(xiàn)狀

容器技術目前的市場現(xiàn)狀是一家獨大、百花齊放。容器的解決方案非常多，以 Docker 為首占據(jù)了大部分的市場，此外還有各種解決方案如 Rocket、Mesos Universal container、LXC、Hyper Container 等。

容器主流的調(diào)度系統(tǒng) Kubernetes、Mesos和 Docker Swarm 是三足鼎立的狀態(tài)，他們各有優(yōu)勢。Kubernetes 偏重于應用的抽象和規(guī)范的定義，Mesos關注可擴展性及資源混合部署，Swarm 關注于開發(fā)環(huán)境和線上環(huán)境的一體化，更方便使用。

可以看出，容器市場的競爭現(xiàn)已上升到調(diào)度層，這也是為什么 Docker 把 Swarm 嵌在內(nèi)部，使得Docker 不再是一個單機容器，而變成了調(diào)度系統(tǒng)的解決方案。

青云QingCloud 容器解決方案

從資源視角和應用視角分析一下青云QingCloud 提供的容器解決方案。

就資源視角來說，用戶希望 VM 能像 Docker 一樣，可對標準進程進行封裝，使得 VM 也是一個完整的操作系統(tǒng)。為延續(xù)用戶對VM 的操作體驗，青云QingCloud 在統(tǒng)一的 IaaS平臺上同時支持 VM（Virtual Machine 虛擬主機）與 CM（Container Machine 容器主機），使得用戶對虛擬化的部署習慣得以沿襲，同時還可享受容器資源輕量隔離的特點。

就應用視角來說，青云QingCloud 支持容器編排系統(tǒng)，體現(xiàn)在兩方面：一是AppCenter 應用支持 Docker 鏡像，二是容器編排系統(tǒng)可以作為一個應用放在AppCenter 上。容器可以在 VM 之上部署集群，Mesos、Kubernetes、Swarm 也可以作為云應用放在 AppCenter 之上，讓用戶可以自主選擇。

Kuberneteson QingCloud AppCenter

我們第一步做的是在 AppCenter 上部署 Kubernetes。為什么選擇 Kubernetes 呢？主要是因為 Kubernetes 部署比較復雜，如果最為復雜的 Kubernetes 能夠在青云QingCloud AppCenter 上運行，其他集群也一樣可以部署到 AppCenter 上。

QingCloud支持用戶一鍵部署 Kubernetes 集群，不僅解決了用戶很大的痛點，同時也驗證了 AppCenter 支持應用的廣泛性。

為此，我們解決了四大難題：容器調(diào)度系統(tǒng)的網(wǎng)絡、數(shù)據(jù)本地存儲的讀取、容器平臺與負載均衡器集成以及實現(xiàn) Kubernetes 應用的彈性伸縮能力。

接下來整體介紹一下 Kubernetes。

Kubernetes 概覽

Kubernetes 集群包含兩種角色，一是 master， 二是 node，相當于 worker 或者 slave。

Master 有三個主要的組件：

一是 API Server（APIs），其底層是分布式存儲（etcd），存儲集群所有的數(shù)據(jù)；

二是 Controller Manager，承擔了 master 的主要職能，管控所有的節(jié)點以及 Kubernetes 之上的 pod，service 等；

三是調(diào)度器 Scheduler，可以根據(jù)調(diào)度規(guī)則來分配節(jié)點最適合部署的位置。

如圖有兩個 Node，其上的 Kubelet 是節(jié)點的守護進程，用以管理 Node 上的所有 Pod。

Kubernetes 的 Pod 和 Docker Container 有點區(qū)別，這里特殊說明下，Pod 里包含多個 Container。Kubernetes 這樣設計主要有兩方面原因：

1. 為了和 Docker 解耦。Docker 啟動時會先初始化網(wǎng)絡，然后再啟動容器進程，因為很多應用啟動后如果沒有網(wǎng)絡就會報錯。但 Kubernetes 想用自己的網(wǎng)絡方案，就必須是先啟動容器，再創(chuàng)建網(wǎng)絡。

于是 Kubernetes 會先啟動一個空進程（pause進程，啟動后就一直 sleep），占據(jù)容器的一個命名空間，在網(wǎng)絡、存儲創(chuàng)建出來后掛載到這個空容器上，然后才啟動用戶定義的容器，而這個容器直接復用 pause 容器的網(wǎng)絡和存儲。

2. 通過 Pod 打包多個 Container，使之共享同一個生命周期。這樣的解決方案也非常有利于多個容器有強依賴關系的場景，比如 nginx 和 php-fpm 進程，比如 Kubernetes 的內(nèi)置 dns 的多個組件，kube-dns 負責監(jiān)聽 Kubernetes 的 service 變更，然后轉(zhuǎn)換成 dns 記錄，寫入到 dnsmasq 中。這種場景下，任何一個組件獨立存活都是沒有意義的。

Kubernetes 抽象概念

Kubernetes 的目標在于制定一個標準和規(guī)范，可以讓你來描述集群的架構，定義服務的最終狀態(tài)，它來幫助你的系統(tǒng)達到和維持在這個狀態(tài)。這個其實和 Puppet/Ansible 等配置管理工具的目的是一致的，只是配置管理工具只能做達到某個狀態(tài)，沒法實現(xiàn)維持到這個狀態(tài)（因為沒有動態(tài)的伸縮以及故障遷移等調(diào)度能力）。所以 Kubernetes 提出了許多抽象的概念，用來實現(xiàn)這種描述能力。如 Service、Job、ReplicaSet、Deployment等。

Kubernetes 網(wǎng)絡設計

Kubernetes 對于網(wǎng)絡有三點要求：一是容器之間可以直接互通，不需要 NAT；二是節(jié)點可以和容器直接互通，不需 NAT；三是容器看到自己的 IP 應該和其他容器看到的是一致的，即中間不能做IP轉(zhuǎn)換，避免復雜的分布式架構應用節(jié)點之間的連接復雜問題。

Kubernetes 網(wǎng)絡之 Cluster IP

Kubernetes 的 Service 概念大概是，一組服務有多個容器，通過一樣的端口運行，暴露出來的 IP 都是一樣的。通過一個松耦合的選擇器把后面的容器或者 Pod 全部歸納在這個 Service 之下。

Cluster IP 是一個虛IP，可以自動分配，也可以指定。當用戶向這個 IP 的service port (比如例子中是 80) 發(fā)送數(shù)據(jù)的時候，iptables 會攔截這個數(shù)據(jù)包，然后把數(shù)據(jù)包隨機分發(fā)至其中一個 Pod。這相當于是內(nèi)部的一種負載均衡器，但它是自動的，即定義Service 的時候，會自動創(chuàng)建一個輕量的負載均衡器。

同時，Kubernetes 內(nèi)置了 dns 服務，每個 service 都會有一個和 service name 一樣的 dns 記錄，解析到 service 的 Cluster IP 上。這樣一來，就實現(xiàn)了服務之間依賴的解耦。當請求一個服務的時候，不需要知道服務后面 Pod 的真實 IP 是多少，只需要請求 Cluster IP 或者 DNS。

Kubernetes 之 Flannel

先想象一下，如果我們要自行實現(xiàn)一個容器的網(wǎng)絡，每個主機上有一個 Docker 容器，并自行分配一個 DockerBridge 的 IP。這樣一來，如果在多個主機上啟動Docker 就會發(fā)現(xiàn)：

第一，它會產(chǎn)生 IP 沖突，怎么解決這個 IP 沖突呢？首先得有一個機制協(xié)調(diào)，協(xié)調(diào)每個主機分別用什么 IP。

第二，從某個主機里的容器發(fā)出來的數(shù)據(jù)包，它需要有一種轉(zhuǎn)發(fā)機制，確定這個包應該如何轉(zhuǎn)發(fā)到另外一個容器所在的主機上。

為了解決 IP 沖突，它首先需要 IP 分配策略，通過共享的 etcd 存儲。也就是說，F(xiàn)lannel 會給每個主機分配一個 IP 段，把它捆到 etcd 里，使得每一個主機都知道另外主機的 IP 段是多少。這樣就能確保 IP 不會沖突，使某個容器發(fā)出的數(shù)據(jù)能夠準確傳給對應主機的目標容器上，并且是通過 Kubernetes 分配 IP 的規(guī)則。

怎么去轉(zhuǎn)發(fā)數(shù)據(jù)包呢？一種方法是通過 etcd 隧道，創(chuàng)建一個鏈接直接轉(zhuǎn)發(fā)數(shù)據(jù)包；還有一種方法是通過云服務提供的路由規(guī)則，修改路由表即可。

Kubernetes 網(wǎng)絡之 QingCloud

Kubernetes 的網(wǎng)絡是如何發(fā)揮青云QingCloud IaaS 層網(wǎng)絡的優(yōu)勢以及 SDN Passthrough（網(wǎng)絡直通）的特性呢？

首先，一個主機可掛多個網(wǎng)卡，將一個網(wǎng)卡給這個主機，其他的網(wǎng)卡直接綁到容器里，使得在 VPC 環(huán)境中每個容器的 IP 和對應主機的 IP 是對等的。這樣一來，主機之間、主機和容器之間、容器之間可以實現(xiàn)互通，同時省去了 Flannel 解決方案的損耗。

其次，青云QingCloud 的負載均衡器能感知到容器網(wǎng)絡，而傳統(tǒng)的方案在內(nèi)部還需要再做一層虛擬網(wǎng)絡，IaaS 層的負載均衡器無法感知容器網(wǎng)絡。

Kubernetes 存儲

容器的存儲解決方案是影射一個本地硬盤到容器中，本地硬盤的生命周期和容器是脫離的，容器刪了之后數(shù)據(jù)還在。但是當我們用調(diào)度系統(tǒng)的時候會發(fā)現(xiàn)，如果把容器從這個節(jié)點遷移到這個節(jié)點的時候，如果直接把本地硬盤路徑掛上去之后，數(shù)據(jù)就沒了，說明它的數(shù)據(jù)是遷移不過來的。

為此，Kubernetes 采用了分布式的存儲，比如 nfs、ceph、glusterfs，PersistentVolume plugin。

此外，Kubernetes 還提供了存儲插件，支持谷歌、AWS，以及青云QingCloud（QingCloudStore） 。有了這些插件，用戶可以在主機上掛載一個硬盤，再將硬盤映射到容器。當容器從一個節(jié)點遷到另外一個節(jié)點的時候，這個硬盤也跟著遷過來，使得容器的數(shù)據(jù)實現(xiàn)遷移。

Kubernetes 存儲之 QingCloudStore

Kubernetes 有一個抽象的配置文件，配置文件標明 QingCloudStore，它可以關聯(lián)一個 volumeID。這種方式的缺點在于配置文件和資源是綁定的、強關聯(lián)的，配置文件用一次之后就不能用了，使得測試環(huán)境和現(xiàn)場環(huán)境不一樣。所以，為解決這個問題，需要在 Kubernetes 中聲明需要多大的空間、是否讀寫、什么權限、提供方是誰，再加上 StorageClass 的配置。

有了這樣的聲明之后有什么好處呢？使得環(huán)境和具體的資源不綁定了，當集群發(fā)現(xiàn)該聲明還沒有滿足的情況下，它會自動創(chuàng)建一個盤，關聯(lián)到你的 Pod 上。當 Pod 刪除的時候，它會回收資源。這樣，實現(xiàn)了解耦。

Kubernetes 負載均衡器

Kubernetes 本身的負載均衡器提供了一種插件，讓云服務商實現(xiàn)插件和 IaaS 層整合。因為最終用戶暴露的時候需要一個公網(wǎng) IP，這個實現(xiàn)和各云廠商的服務是息息相關的，而 Kubernetes 自己比較難直接提供這樣的服務，所以它就提供插件讓云服務商去實現(xiàn)。

但是云廠商的負載均衡器只能感知到節(jié)點主機這一層，對主機里面的容器是無感的，所以大多數(shù)情況下只能把 Kubernetes 集群下所有的節(jié)點都掛載到 LoadBalancer之后。前面講到 Service 時說到，Kubernetes 為每一個 Service 都在所有主機上監(jiān)聽一個隨機的端口，也就是 NodePort，這個請求會轉(zhuǎn)發(fā)到主機的隨機端口上，由隨機端口轉(zhuǎn)發(fā)到 ClusterIP 上，再由 ClusterIP 轉(zhuǎn)發(fā)到后面的容器，可以看出，這樣就多了幾層轉(zhuǎn)發(fā)。

如果負載均衡器能感知到容器的網(wǎng)絡，就可以直接透傳請求到容器中。我們的負載均衡器后面直接掛在的是容器網(wǎng)卡，這樣就省去了幾層轉(zhuǎn)發(fā)。同時我們的支持公網(wǎng)和私網(wǎng)兩種 Load Balancer。因為一般不可能把所有的服務遷到 Kubernetes，有一部分遷進去了，有一部分服務可能在外面。這種情況下外部服務訪問不了Kubernetes Service 的 Cluster IP 和 DNS ，這個時候需要私網(wǎng)的 Load Balancer 去轉(zhuǎn)發(fā)這種請求。

Kubernetes 自動伸縮

Kubernetes 提供了本身一種機制，通過相應命令可自動增加 Pod 的節(jié)點數(shù)。但光有這一層伸縮是不夠的，部署 Kubernetes 集群的時候，節(jié)點數(shù)是提前規(guī)劃好的。當自動伸縮使 Kubernetes 容量達到上限的時候，就無法伸縮了。這個時候集群本身需要有自動伸縮的功能，當前只有谷歌云實現(xiàn)了集群的伸縮能力。

當 Kubernetes 集群的資源不夠了，它會觸發(fā)一個事件，IaaS 層監(jiān)聽這個事件，收到事件請求之后增加集群的節(jié)點。這樣就實現(xiàn)了業(yè)務應用層的自動伸縮以及 Kubernetes 資源池的伸縮。

『充電時間』上海、杭州、重慶、成都，讓你們久等了！實踐課堂馬上與你見面，還不報名？本次課程內(nèi)容仍以技術實踐為主，以用戶場景為切入，主要圍繞QingCloud 的技術理念、功能特性和使用技巧展開，話題將涵蓋如何高效構建原生云應用，云端容器部署，微服務架構，應用感知，自動化運維等業(yè)內(nèi)熱點話題。

報名請掃描下方二維碼哦