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

前言

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

容器是什么

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

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

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

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

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

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

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

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

青云QingCloud 容器解決方案

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

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

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

Kuberneteson QingCloud AppCenter

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

QingCloud支持用戶一鍵部署 Kubernetes 集群，不僅解決了用戶很大的痛點(diǎn)，同時(shí)也驗(yàn)證了 AppCenter 支持應(yīng)用的廣泛性。

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

接下來整體介紹一下 Kubernetes。

Kubernetes 概覽

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

Master 有三個(gè)主要的組件：

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

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

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

如圖有兩個(gè) Node，其上的 Kubelet 是節(jié)點(diǎn)的守護(hù)進(jìn)程，用以管理 Node 上的所有 Pod。

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

1. 為了和 Docker 解耦。Docker 啟動(dòng)時(shí)會先初始化網(wǎng)絡(luò)，然后再啟動(dòng)容器進(jìn)程，因?yàn)楹芏鄳?yīng)用啟動(dòng)后如果沒有網(wǎng)絡(luò)就會報(bào)錯(cuò)。但 Kubernetes 想用自己的網(wǎng)絡(luò)方案，就必須是先啟動(dòng)容器，再創(chuàng)建網(wǎng)絡(luò)。

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

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

Kubernetes 抽象概念

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

Kubernetes 網(wǎng)絡(luò)設(shè)計(jì)

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

Kubernetes 網(wǎng)絡(luò)之 Cluster IP

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

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

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

Kubernetes 之 Flannel

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

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

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

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

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

Kubernetes 網(wǎng)絡(luò)之 QingCloud

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

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

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

Kubernetes 存儲

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

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

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

Kubernetes 存儲之 QingCloudStore

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

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

Kubernetes 負(fù)載均衡器

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

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

如果負(fù)載均衡器能感知到容器的網(wǎng)絡(luò)，就可以直接透傳請求到容器中。我們的負(fù)載均衡器后面直接掛在的是容器網(wǎng)卡，這樣就省去了幾層轉(zhuǎn)發(fā)。同時(shí)我們的支持公網(wǎng)和私網(wǎng)兩種 Load Balancer。因?yàn)橐话悴豢赡馨阉械姆?wù)遷到 Kubernetes，有一部分遷進(jìn)去了，有一部分服務(wù)可能在外面。這種情況下外部服務(wù)訪問不了Kubernetes Service 的 Cluster IP 和 DNS ，這個(gè)時(shí)候需要私網(wǎng)的 Load Balancer 去轉(zhuǎn)發(fā)這種請求。

Kubernetes 自動(dòng)伸縮

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

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

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

報(bào)名請掃描下方二維碼哦